UDP
UPD的特点及其目的
UDP不提供复杂的控制机制,利用IP提供面向无连接的通信服务。并且它是将应用程序发来的数据在收到的那一刻,立即按照原样发送到网络上的一种机制。
即使是出现网络拥堵的情况下,UDP无无法进行流量控制等避免网络拥塞的行为。此外,传输途中即使出现丢包,UDP也不负责重发。甚至当出现包的到达顺序乱掉时也没有纠正的功能。
由于UDP面向无连接,它随时可以发送数据。再加上UDP本身的处理既简单又高效,因此经常用于以下几个方面:
- 包总量较少的通信(DNS、SNMP等)
- 视频、音频等多媒体通信(即时通信)
- 限定于LAN等特定网络中的应用通信
- 广播通信(广播、多播)
TCP
TCP的特点及其目的
TCP通过校验和、序列号、确认应答、重发控制、连接管理以及窗口控制等机制实现可靠性传输。
一、通过序列号和确认应答提高可靠性
在TCP中,当发送端的数据到达接收主机时,接收端主机会返回一个已收到消息的通知。这个消息叫做确认应答(ACK)。
确认应答处理、重发控制以及重复控制等功能都可以通过序列号实现。序列号是按顺序给发送数据的每一个字节都标上号码的编号。接收端查询接收数据TCP首部中的序列号和数据
的长度,将自己下一步应该接收的序号作为确认应答返送回去。
二、重发超时如何确定
重发超时是指在重发数据之前,等待确认应答到来的那个特定时间间隔。
最理想的是,找到一个最小时间,它能保证“确认应答一定能在这个时间内返回”。然而这个时间长短随着数据包途径的网络环境的不同而有所变化。
TCP要求无论身处何种网络环境下都要提供高性能通信,并且无论网络拥堵情况发生何种变化,都必须保持这一特性。为此,它在每次发包时都会计算往返时间及其偏差。将这个往返时间和偏差相加,重发超时的时间,就是比这个总和稍大一点的值。
在BSD的Unix以及Windows系统中,超时都以0.5秒为单位进行控制,因此重发超时都是0.5s的整数倍。不过,由于最初的数据包还不知道往返时间,所以其重发超时一般设置为6s左右。
数据重发之后若还是收不到确认应答,则进行再次发送。此时,等待确认应答的时间将会以2倍、4倍的指数函数延长。
达到一定重发次数之后,如果仍没有任何确认应答返回,就会判断为网络或对端主机发生了异常,强制关闭连接,并且通知应用通信异常强行终止。
三、连接管理(三次握手、四次挥手)待扩展
TCP提供面向连接的通信传输。
四、TCP以段为单位发送数据
在建立TCP连接的同时,也可以确定发送数据包的单位(MSS),最理想的情况是,最大消息长度正好是IP中不会被分片处理的最大数据长度。
TCP在传输大量数据时,是以MSS的大小将数据进行分割发送。进行重发时也是以MSS为单位。
五、利用窗口控制提高速度
确认应答不再是以每个分段,而是以更大的单位进行确认时,转发时间将会被大幅度缩短。
窗口大小就是指无需等待确认应答而可以继续发送数据的最大值。
这个机制实现了使用大量的缓冲区,通过对多个段同时进行确认应答的功能。
收到确认应答的情况下,将窗口滑动到确认应答中的序列号的位置。这样可以顺序地将多个段同时发送提高通信性能。这种机制也称为滑动窗口机制。
六、窗口控制与重发控制
假设序列号1-1000发送成功,1001-2000发送过程中报文丢失:
当该报文段丢失后,发送端会一直收到序号为1001的确认应答。在窗口比较大,又出现报文段丢失的情况下,同一个序号的确认应答将会被重复不断的返回。而发送端主机连续3次收到同一个确认应答,
就会将其所对应的数据进行重发。这种机制比之前提到的超时管理更加高效,称作高速重发控制。
七、流控制
发送端根据自己的实际情况发送数据。但是,接收端可能收到的是一个毫无关系的数据包,又可能在处理其他问题上耗费一些时间。因此在为这个数据包做其他处理时会耗费一些时间,甚至在高负荷的情况下无法接收任何数据。如此一来,如果接收端本应该接收的数据丢弃的话,就又会触发重发机制,从而导致网络流量的无端浪费。
为了防止这种现象的发生,TCP提供一种机制可以让发送端根据接收端的实际接收能力控制发送的数据量,即流控制。它的具体控制是,接收端主机向发送端主机通知自己可以接收数据的大小,于是发送端会发送不超过这个限度的数据。该大小限度就被称作窗口大小。
TCP首部中,专门有一个字段用来通知窗口大小。接收主机将自己可以接收的缓冲区大小放入这个字段中通知给发送端。这个字段的值越大,说明网络的吞吐量越高。
当接收端缓冲区即满,不得不暂停接收数据。之后,在收到发送窗口更新通知后通信才得以继续进行。如果这个窗口的更新通知在传送途中丢失,可能会导致无法继续通信。为避免此类问题的发生,发送端主机会时不时的发送一个叫做窗口探测的数据段,此数据段仅含一个字节以获取最新的窗口大小信息。
八、拥塞控制
有了TCP的窗口控制,收发主机之间即使不再以一个数据段为单位发送确认应答,也能够连续发送大量数据包。然而,如果在通信刚开始时就发送大量数据,也可能引发其他问题。
一般来说,计算机网络都处于一个共享的环境中。因此可能会因为其他主机之间的通信使得网络拥堵。在网络出现拥堵时,如果突然发送一个较大量的数据,极有可能会导致整个网络的瘫痪。
TCP为了防止该问题的出现,在通信一开始时就会通过一个叫做慢启动的算法得出的数值,对发送数据量进行控制。
首先,为了在发送端调节所要发送数据的量,定义了一个叫做“拥塞窗口”的概念。于是在慢启动的时候,将这个拥塞窗口的大小设置为1个数据段(1MSS)发送数据,之后每收到一次确认应答(ACK),拥塞窗口的值就加1。在发送数据包时,将拥塞窗口的大小与接收端主机通知的窗口大小做比较,然后按照他们当中较小的那个值,发送比其还要小的数据量。
如果重发采用超时机制,那么拥塞窗口的初始值可以设置为1以后再进行慢启动修正。有了上述这些机制,就可以有效地减少通信开始时连续发包导致的网络拥堵,还可以避免网络拥塞情况的发生。
不过,随着包的每次往返,拥塞窗口也会以1、2、4等指数函数的增长,拥堵状况激增甚至导致网络拥塞的发生。为了防止这些,引入了慢启动阈值的概念。只要拥塞窗口的值超出这个阈值,在每收到一次确认应答时,只允许以下面这种比例方法拥塞窗口:
1MSS/拥塞窗口字节数×1MSS
TCP的通信开始时,并没有设置相应的慢启动阈值。而是在超时重发时,才会设置为当时拥塞窗口一半的大小。
由重复确认应答而触发的高速重发与超时重发机制的处理多少有点不同。因为前者要求至少3次的确认应答数据段到达对方主机后才会触发,相比后者网络的拥堵要轻一些。
而由重复确认应答进行高速重发控制时,慢启动阈值的大小被设置为当时窗口大小的一半。然后将窗口的大小设置为该慢启动阈值+3MSS。
UDP首部格式
源端口号(16位) | 目标端口号(16位) |
包长度(16位) | 校验和(16位) |
数据部分 |
- 源端口号:表示发送端端口号。该字段是可选项。没有源端口号的时候该字段的值被设置为0。可用于不需要返回的通信中。
- 目标端口号:表示接收端端口号。
- 包长度:该字段保存了UDP首部的长度跟数据的长度之和。
- 校验和:校验和是为了提供可靠的UDP首部和数据而设计。
校验和计算中计算UDP伪首部的理由
源IP地址 | ||
目标IP地址 | ||
填充0 | 协议号17 | UDP包长度 |
TCP/IP中识别一个进行通信的应用需要5大要素,它们分别是“源IP地址”、“目标IP地址”、“源端口”、“目标端口”、“协议号”。然而,在UDP的首部中只包含其中两项,余下3项都包含在IP首部里。
假定其他3项的信息被破坏会产生什么样的后果?这极有可能导致应该收包的应用收不到包,不该收到包的应用却收到了包。
为了避免此类问题,有必要验证一个通信过程中必要的5项识别码是否正确。为此,在校验和的计算中就引入了伪首部的概念。
此外,IPv6中的IP首部没有校验和字段。TCP或UDP通过伪首部,得以对5项数字进行校验,从而实现即时在IP首部并不可靠的情况下仍然能够提供可靠的通信传输。