嵌入式学习之TCP和UDP基础理解

2019-07-13 06:03发布

鸡汤:若有一个柠檬,那就做成柠檬水。

学习梳理目录:

1. 传输层的作用 2. 端口的理解 3. UDP学习 4. TCP学习 5. UDP首部学习 6. TCP首部学习

传输层的作用

首先应说明的是TCP/IP有两个典型的传输层协议TCP和UDP,TCP是可靠的通讯协议,UDP常被用于将广播和细节控制交给应用的通讯传输。

传输层定义

我们知道每个连网络的系统都有一个由网关分配的IP号,而IP号的首部中有一个协议字段,用来标示网络层(IP)的上一层采用了哪一种传输层协议。根据这个字段的协议号来识别传输数据部分是TCP的内容,还是UDP内容。 ——-以邮寄包裹为例,邮递员(网络层或IP层)根据收件人(目标IP地址)向目的地家庭地址(计算机)邮递明信片(IP数据报)。包裹到达目的地以后由对方(传输层协议)根据包裹收件人(端口)判断最终的接收人(应用程序)。 图1 ——-如果在包裹上只写家庭地址(目标IP地址),那可以想象,当邮递员将包裹送到你家的时候,你完全没法辨别这是寄给谁的。同样如果只在邮寄包裹上写收件人(端口),那你这份包裹基本死在邮局里,连派送的机会都没有(可以想象世界这么大,和你名字一样的多的去了!,注意网络的地址也具有层次性,这和一个地区分很多地域类似,具体描述见博文:汇文嵌入式学习之网络原理基础)。 (PS:来一发标准的邮寄信息:XXX省XXX市XXX县XXX镇XXXX村门牌号 张三 (收) 门牌号意味着指定的那户人家,这里的地址就是传说中的IP,张三是相应端口的应用程序) ----这里要注意以上加黑部分“家庭地址(目标IP地址)”和“收件人(端口)”这两点无论在搭建服务器构建客户端的精粹所在。

通讯处理

——再分析下传输层的协议工作机制,以图1所示为例,图中提到的“应用程序”其实就是用来进行TCP/IP应用协议的处理,而“具体识别包裹是寄给这户人家哪个人的”就可以被理解为应用协议 这里还需要有对“客户端”和“服务端”的理解,什么是客户端?什么是服务端?顾名思义,服务端是用来提供服务的,是请求的处理端,而客户端是用来请求服务的,是请求的发起端。而且要有客户,必先得有服务的人,所以其中的启动的先后顺序也很好理解了。 图2 如图2,服务端的程序在linux中被称为守护进程,如HTTP的服务端程序是httpd(HTTP守护进程),而ssh的服务程序sshd(SSH守护进程)

端口号的理解

数据链路和IP(网络层)中的地址,分别指的是MAC地址和IP地址,前者用来识别同一链路中不同的计算机,后者用来识别TCP/IP网络中互联的主机和路由器。在传输层中端口号也类似于上述MAC地址和IP地址,端口号用来识别同一台计算机中进行通讯的不同应用程序,同时端口号也被称为程序地址。

根据端口号识别应用

——-一台电脑上可以识别多个应用程序。例如接收WWE服务的的Web服务,电邮客户端都可以同时运行,这一点传输层协议正是利用这些端口识别本机中正在运行的应用程序,并把数据传输。

通过IP地址、端口号、协议号进行通讯识别

下图3描述:①和②的通信是在两台计算机上进行的。它们的目标端口号相同,都是80,例如打开两个Web浏览器,同时访问两个服务器上不同的页面,就会在这个浏览器跟服务器之间产生类似前面的两个通信。在这种情况下也必须严格区分。因此可以根据端口号加以区分。 图3 而③跟①的目标端口号完全相同,但是他们各自的源IP地址不同。此外,还有一种情况上图中并未列出,那就是IP地址和端口全都一样,只是协议号不同(这样的协议号是最上层应用层应用程序自己使用的协议产生的编号),在这种情况下,也是两个不同的通信。 ——-所以在TCP/IP和UDP/IP通信中通常采用5个信息来识别一个通信。分别为:①源IP地址、②目标IP地址、③协议号、④源端口号、⑤目标端口号。这五个信息中其中一项不同,则被认为是其他通信。

端口号如何确定

确定端口的方法有两种1、标准既定的端口号 2、时序分配法
①、标准既定的端口
——-这种方法也叫静态方法。这种方法是指每个应用程序都有其指定的端口号。并且这种端口号的选用有一定的标准。
例如HTTP、FTP等广为使用的应用协议中使用的端口号就是固定的,HTTP的固定端口号为 80FTP的固定端口号为 21,这些知名的端口号一般在由0至1023的数字之间。
固定端口号的使用情况可参考:
http://www.iana.org/assignments/port-numbers
②、时序分配法
——-这种方法也叫时序分配法或动态分配法。此时,服务端有必要确定监听端口号,但是接受服务的客户端没必要确定端口号。客服端可以完全不用设置端口号,并将为每个应用程序分配互不冲突的端口号的任务交给操作系统。 注意:动态端口号的取值范围在49152到65535之间。

端口号与协议

关于端口号的选用,还有一点影响因素即:传输层本身的协议决定,即不同的传输协议可以使用相同的端口号。比如:我们最熟悉的TCP和UDP就可以使用同一个端口号,但使用的目的各不同,这是因为端口号上的处理是根据每个传输协议的不同而进行的。 数据到达IP层或网络层后,会检查IP首部中的协议号,再传给相应协议的模块。如果是TCP则传给TCP模块,如果是UDP则传给UDP模块去做端口号的处理,即使是同一个端口号,由于传输协议是各自独立地进行处理,因此相互之间不会受到影响。 下图为一些TCP和UDP的标准既定端口号的使用情况:
TCP端口号:
TCPport
TCPport
UDP端口号:
UDPport
UDPport

UDP的学习

UDP是User Datagram Protocol 的缩写 中式英语直译:用户 数据电报 协议 ——-UDP是一种没有控制机制,利用IP提供面向无连接的通信服务,即使是出现网络拥堵的情况下,UDP也无法进行流量控制等避免网络拥塞的行为。换句话说,它将部分控制转移给应用程序去处理,自己提供传输层协议的最基本功能。
——-另外一点由于UDP面向无连接,它可以随时发送数据,而且UDP本身的处理既简单又高效,因此经常用于以下几个方面: 1.包总量较少的通信(DNS、SNMP等) 2.视频、音频等多媒体通信(即时通信) 3.限定于LAN等特定网络中的应用通信 4.广播通信(广播、多播)

TCP的学习

TCP是Transmission Control Protocol的缩写,“人如其名”,TCP可以说是对“传输、发送、通信”进行“控制”的“协议”

TCP的特点

——-相比于UDP,TCP充分实现了数据传输时的各种控制功能:①可以进行丢包时的重发控制,②可以对次序乱掉的分包进行顺序控制。另外TCP是面向有连接的协议即:只有在通信对端存在是才会发送数据,从而可以控制通信流量的浪费。

TCP可靠性传输的实现

1.通过序列号与确认应答提高可靠性

在TCP中,当发送端的数据到达接收主机时,接收端主机会返回一个已收到消息的通知。这个消息叫做确认应答(ACK) ——-通常,两个人对话时,在谈话的停顿处可以点头或询问以确认谈话内容。如果对方迟迟没有任何反馈,说话的一方还可以再重复一遍以保证对方确实听到。因此,对方是否理解了此次对话内容,对方是否完全听到了对话的内容,都要靠对方的反应来判断。网络中的“确认应答”就是类似这样的一个概念。当对方听懂对话内容时会说“嗯”,这就相当于返回了一个确认应答(ACK)。而当对方没有理解对话内容或没有听清时会问一句“你说什么?”这好比一个否定确认应答(NACK)。
应答机制
TCP通过肯定的确认应答(ACK)实现可靠的数据传输。 那么问题来了,若主机A一直收不到主机B的应答,那主机A会一直干等着吗? 解决方法:定时重发机制,即主机A在一定时间内没有等到确认应答,发送就可以认为数据已经丢失,并进行重发。由此即使产生了丢包,仍然能够保证数据能够到达对端,实现可靠传输。
带定时重发机制 那么问题又来了,定时重发功能能解决目标主机B长时间未应答的情况,然而未收到确认应答并不意味着数据一定丢失。也有可能是数据对方已经收到了,只是返回的确认在途中丢失。这种情况会触发发送端的定时重发功能,这也就导致接收端收到重复的信息。
超时并中途丢应答 类似上一个问题,也有可能因为一些其他原因导致确认应答延迟到达,在源主机重发数据以后才到达的情况也是很多的。此时,对于源主机只要安排“定时重发机制”重发数据即可,但是对于目标主机来说,这会是一种“灾难”,它会重复收到相同的数据。然而这堆重复的数据对于上一层应用层的程序来说并没有什么卵用!这就导致了错误。 解决方法:加入一种能够识别是否已经接收数据,又能识别是否需要接收的机制。这可以通过序列号实现,序列号是按顺序给发送数据的每一个字节都标上号码的编号。接收端查询接收数据TCP首部中的序列号和数据的长度,将自己下一步应该接收的序号职位确认应答返送回去。就这样,通过序列号和确认应答号来实现TCP的可靠传输。
带序列号

2.连接管理

——-之前提到过,UDP是面向无连接的通信协议,而TCP不同,它是面向有连接的通信协议,它会在数据通信之前,通过TCP首部发送一个SYN(同步)包作为建立连接的请求并等待确认应答。如果对端发来确认应答,则认为可以进行数据通信。如果对端的确认应答未能到达,就不会进行数据通信。此外,在通信结束时会进行断开连接的处理(FIN包)。
7步通连

3.TCP以段为单位发送数据

——-TCP连接后,确定发送数据包的单位,这被称为“最大消息长度”(MSS:Maximum Segment Size)。关于MSS的选取,最理想的情况为在IP中不会被分片处理的最大数据长度。TCP在传送大量数据是,是以MSS的大小将数据进行分割发送。进行重发是也是以MSS为单位。 MSS是在三次握手的时候,在两端主机之间被计算得出。两端的主机在发出建立连接的请求时,会在TCP首部中写入MSS选项,告诉对方自己的接口能够适应的MSS的大小。然后会在两者之间选择一个较小的值投入使用。 MSS

4.利用窗口提高速度

TCP若以段为单位,每发一段进行一次确认应答的处理,这样的传输方式有一个缺点,即包往返时间越长通信性能就越低。 为解决这个问题,TCP使用了窗口的概念,确认应答不再是以每个分段,而是以更大的单位进行确认,这样会使转发的时间大幅的缩减,发送端在发送一个端一个不必要一直等待确认应答,而可以继续发送。
窗口
——-收到确认应答的情况下,将窗口滑动到确认应答中的序列号的位置。这样可以顺序地将多个段同时发送提高通信性能。这种机制被称为滑动窗口控制
滑动窗口控制

5.窗口控制与重发控制

首先,我们可能会想“在使用窗口控制中,如果出现段丢失该肿么办?
情况一、确认应答未能返回的情况。在这种情况下,数据已经到达对端,是不需要再进行重发的。然而,在没有使用窗口控制的时候,没有收到确认应答的数据都会被重发,而使用了窗口控制。
窗口重发
情况二、其中某报文段丢失的情况,接收主机如果收到一个自己应该接收的序号以外的数据是,会针对当前为止收到数据返回确认应答。
如下图,如果某一段报文段丢失后,发送端会一直收到序号为1001的确认应答,这个确认应答好像在提醒发送端“我想接收的是从1001开始的数据”。因此在窗口比较大,又出现报文段丢失的情况下,同一序号的确认应答将会被重复不断地返回。而发送端主机如果连续3次收到同一个确认应答,就会将其所对应的数据进行重发。这种机制比之前提到的超时重发机制更加高效,因此被称为高速重发控制
高速重发机制

6.流控制

TCP为何需要流控制
——-情况是这样的,发送端根据自己的实际情况发送数据。但是,接收端可能收到的是一个毫无关系的数据包又可能会在处理其他问题上花费一些时间,甚至在高负荷的情况下无法接收任何数据。如此一来,如果接收端本应该接收的数据丢弃的话,就又会触发重发机制,从而导致网络流量的无端浪费。为了防止这种现象的发生,TCP提供一种机制可以让发送端根据接收端的实际接收能力发送的数据量。这就是流控制,它的具体操作位,接收端主机向发送端主机通知自己可以接收数据的大小,于是发送端发送不超过这个限度的数据。该大小限度就被称为窗口大小
——-TCP首部中,专门有一个字段用来通知窗口的大小。接收主机将自己可以接收的缓冲区放入这个字段中通知给发送端。这个字段越大,说明网络的吞吐量越高。而且接收端的缓冲区在面临数据溢出时,窗口大小的值也会随之被设置为一个更小的值通知发送端。
流控制

拥塞控制

拥塞情况描述:在使用TCP窗口控制,收发主机之间即使不再以一个数据段为单位发送确认,但有时也能够连续发送大量数据包。然而,网络是一个共享的环境,一对收发主机之间通信刚开始发送大量数据而出现拥堵情况,也会有可能导致整个网络的瘫痪。
——-TCP为了防止这问题的出现,在通信一开始使用“慢启动”的算法来对数据量进行控制。
拥堵控制 ——-为了在发送端调节所要发送的数据的量,定义了一个叫做“拥塞窗口”的概念,在慢启动的时候,将这个拥塞的窗口大小设置为1个数据段(MSS)发送数据,之后没收到一次确认应答(ACK),拥塞窗口的值就加1。在发送数据包时,将拥塞窗口的大小和接收端主机通知的窗口大小做比较,然后按照它们当中较小那个值,发送比其还要小的数据量。
不过,随着包的每次往返,拥塞窗口也会议1、2、4等指数增长,这也会导致拥堵状况激增甚至导致网络拥塞的发生,为了防止这种情况,引入了慢启动阈值的概念
只要拥塞窗口的值超出这个阈值,在每收到一次确认应答,只允许一下比例放大拥塞窗口:
慢启动

UDP首部

UDP数据报

源端口号

表示发送端端口号,字段长16位。该字段是可选项,有时候可能不会设置源端口号。没有源端口号的时候该字段的值设置为0。可用于不需要返回的通信中。

目标端口号

表示接收端端口,字段长16位。

包长度

该字段保存了UDP首部的长度根数据的长度之和。单位为字节(8位字节)

校验和

校验和是检验UDP数据报中数据的正确性,它是为了提供可靠的UDP首部和数据而设计的。如下图,附加在UDP伪首部和UDP数据报之前。通过在最后一位增加一个“0”将全长增加16倍。此时将UDP首部的校验和字段设置为“0”。然后以16比特为单位进行1的补码和,并将所得到的1的补码和写入校验和字段。 校验和

TCP首部

TCP首部
与UDP的首部相比,TCP中没有表示包长度和数据长度的字段。可由IP层获知TCP的包长,TCP的包长可知数据的长度。

源端口号

表示发送端端口号,字段长16位。

目标端口号

表示接收端端口号,字段长16位。

序列号

字段长32位,序列号是指发送数据的位置。每发送一次数据,就累加一次该数据字节数的大小。

确认应答号

确认应答号字段长度为32位,是只下一次应该收到的数据的序列号。

数据偏移

该字段表示TCP所传输的数据部分应该从TCP包的哪个为开始计算,当然也可以把它看作TCP首部的长度。

保留位

该字段主要是为了以后扩展时使用,其长度为4位。一般设置为0。

控制位

控制位
CWR
congestion Window Reduced
CWR标志与后面的ECE标志都用于IP首部的ECN字段。ECE标志为1时,则通知对方已将拥塞窗口缩小。
ECE
ECN-Echo。置为1会通知对方,从对方到这边的网络有拥塞。
URG
Urgent Flag
该位为1,表示包中有需要紧急处理的数据。
ACK
Aknowledgement Flag
该位为1,表示确认应答的字段变为有效,TCP规定除了最初建立连接时的SYN包之外该位必须设置为1。
PSH#####、
push Flag
该位为1,表示需要将受到的数据立刻传给上层协议。PSH为0时,则不需要立即传而是先进行缓存。
RST
Reset Falg
该位为1时表示TCP连接中出现异常必须强制断开连接。
SYN
Synchronize Flag
用于建立连接。SYN为1表示希望接力连接,并在其序列号的字段进行序列号初始值的设定。
FIN
Fin Flag
该位为1,表示今后不会再有数据发送。

窗口大小

Window Size
该字段为16位。用于通知从相同TCP首部的确认应答号所指位置开始能够接收的数据大小。

校验和

TCP的校验和与UDP相似,区别在于TCP的校验和无法关闭。

紧急指针

该字段为16位。只有在URG控制位为1时有效。该字段的数值表示本报文段中紧急数据的指针。

选项

选项字段用于提高TCP的传输性能。
选项