【计算机网络系列（四）】TCP 与 UDP 详解

UDP协议

　　UDP协议存在的必要性，网络层的IP协议中并没有端口(port)的概念，IP协议进行的是IP地址到IP地址的传输，计算机和计算机之间的对话。但每台计算机中需要有多个通信通道，并将多个通信通道分配给不同的进程使用。一个端口就代表了这样的一个通信通道。UDP正是为了端到端的通信而存在的。

　　UDP协议看作IP协议暴露在传输层的一个接口，尽管UDP协议非常简单，但它的产生晚于更加复杂的TCP协议。对于一些简单的通信，有时候只需要UDP这样简单的协议就足够了。

UDP协议的特点　

UDP协议在IP协议上增加了复用、分用和差错检测功能。UDP的特点：

　　a. 是无连接的。相比于TCP协议，UDP协议在传送数据前不需要建立连接，当然也就没有释放连接。

　　b.是尽最大努力交付的。也就是说UDP协议无法保证数据能够准确的交付到目的主机。也不需要对接收到的UDP报文进行确认。

　　c.是面向报文的。也就是说UDP协议将应用层传输下来的数据封装在一个UDP包中，不进行拆分或合并。因此，运输层在收到对方的UDP包后，会去掉首部后，将数据原封不动的交给应用进程。

　　d.没有拥塞控制。因此UDP协议的发送速率不受网络的拥塞度影响。

　　e.UDP支持一对一、一对多、多对一和多对多的交互通信。

　　f.UDP的头部占用较小，只占用8个字节。

　　

UDP协议的格式　

　　UDP协议分为首部字段和数据字段，其中首部字段只占用8个字节，分别是个占用两个字节的源端口、目的端口、长度和检验和。

　　


　　长度：UDP报文的整个大小，最小为8个字节（仅为首部）。

　　检验和：在进行检验和计算时，会添加一个伪首部一起进行运算。伪首部（占用12个字节）为：4个字节的源IP地址、4个字节的目的IP地址、1个字节的0、一个字节的数字17、以及占用2个字节UDP长度。

　　UDP计算校验和的方法和计算IP数据报首部校验和的方法相似。 但不同的是：IP数据报的校验和只检验IP数据报的首部，但UDP的校验和是将首部和数据部分一起都检验。 在发送端，首先是将全零放入检验和字段。再将伪首部以及UDP用户数据报看成是由许多16bit的字串接起来。 若UDP用户数据报的数据部分不是偶数个字节，则要填入一个全零字节(即：最后一个基数字节应是16位数的高字节而低字节填0)。 然后按二进制反码计算出这些16bit字的和(两个数进行二进制反码求和的运算的规则是：从低位到高位逐列进行计算。 0和0相加是0，0和1相加是1，1和1相加是0但要产生一个进位1，加到下一列。若最高位相加后产生进位，则最后得到的结果要加1)。 将此和的二进制反码写入校验和字段后，发送此UDP用户数据报。 在接收端，将收到的UDP用户数据报连同伪首部(以及可能的填充全零字节)一起，按二进制反码求这些16bit字的和。 当无差错时其结果应全为1。否则就表明有差错出现， 接收端就应将此UDP用户数据报丢弃(也可以上交给应用层，但附上出现了差错的警告)。

TCP协议

　　TCP(Transportation Control Protocol)协议与IP协议是一同产生的。事实上，两者最初是一个协议，后来才被分拆成网络层的IP和传输层的TCP。我们已经在UDP协议中介绍过，UDP协议是IP协议在传输层的“傀儡”，用来实现数据包形式的通信。而TCP协议则实现了“流”形式的通信。

　　

＂流＂通信

　　计算机数据的本质是有序的0/1序列 (如果以byte为单位，就叫做文本流)。计算机的功能就是储存和处理文本流。IP协议(参考协议森林03, 05)和UDP协议采用的是数据包的方式传送，后发出的数据包可能早到，我们并不能保证数据到达的次序。TCP协议确保了数据到达的顺序与文本流顺序相符。当计算机从TCP协议的接口读取数据时，这些数据已经是排列好顺序的“流”了。比如我们有一个大文件要从本地主机发送到远程主机，如果是按照“流”接收到的话，我们可以一边接收，一边将文本流存入文件系统。这样，等到“流”接收完了，硬盘写入操作也已经完成。如果采取UDP的传输方式，我们需要等到所有的数据到达后，进行排序，才能组装成大的文件。这种情况下，我们不得不使用大量的计算机资源来存储已经到达的数据，直到所有数据都达到了，才能开始处理。

　　如果一个文本流很长的话，我们不可能将整个文本流放入到一个IP数据包中，那样有可能会超过MTU。所以，TCP协议封装到IP包的不是整个文本流，而是TCP协议所规定的片段(segment)。与之前的一个IP或者UDP数据包类似，一个TCP片段同样分为头部(header)和数据(payload)两部分, TCP片段的头部(header)会存有该片段的序号(sequence number)。这样，接收的计算机就可以知道接收到的片段在原文本流中的顺序了，也可以知道自己下一步需要接收哪个片段以形成流。比如已经接收到了片段1，片段2，片段3，那么接收主机就开始期待片段4。如果接收到不符合顺序的数据包(比如片段8)，接收方的TCP模块可以拒绝接收，从而保证呈现给接收主机的信息是符合次序的“流”。

可靠性

　　片段编号这个初步的想法并不能解决我们所有的问题。IP协议是不可靠的，所以IP数据包可能在传输过程中发生错误或者丢失。而IP传输是”Best Effort” 式的，如果发生异常情况，我们的IP数据包就会被轻易的丢弃掉。另一方面，如果乱序(out-of-order)片段到达，根据我们上面说的，接收主机不会接收。这样，错误片段、丢失片段和被拒片段的联手破坏之下，接收主机只可能收到一个充满“漏洞”的文本流。

　　TCP的补救方法是，在每收到一个正确的、符合次序的片段之后，就向发送方(也就是连接的另一段)发送一个特殊的TCP片段，用来知会(ACK，acknowledge)发送方：我已经收到那个片段了。这个特殊的TCP片段叫做ACK回复。如果一个片段序号为L，对应ACK回复有回复号L+1，也就是接收方期待接收的下一个发送片段的序号。如果发送方在一定时间等待之后，还是没有收到ACK回复，那么它推断之前发送的片段一定发生了异常。发送方会重复发送(retransmit)那个出现异常的片段，等待ACK回复，如果还没有收到，那么再重复发送原片段… 直到收到该片段对应的ACK回复(回复号为L+1的ACK)。

　　　

滑窗

　　上面的工作方式中，发送方保持发送->等待ACK->发送->等待ACK…的单线工作方式，这样的工作方式叫做stop-and-wait。stop-and-wait虽然实现了TCP通信的可靠性，但同时牺牲了网络通信的效率。在等待ACK的时间段内，我们的网络都处于闲置(idle)状态。我们希望有一种方式，可以同时发送出多个片段。然而如果同时发出多个片段，那么由于IP包传送是无次序的，有可能会生成乱序片段(out-of-order)。

　　滑窗(sliding window)被同时应用于接收方和发送方，以解决以上问题。就是一个缓存技术。

　　以大小为3的窗口为例：

　　



　　

TCP协议格式

先关注下面几点：

一个TCP头部需要包含出发端口(source port)和目的地端口(destination port)。这些与IP头中的两个IP地址共同确定了连接。

每个TCP片段都有序号(sequence number)。这些序号最终将数据部分的文本片段整理成为文本流。

ACK是一位(bit)。只有ACK位设定的时候，回复号(Acknowledgement number)才有效。ACK回复号说明了接收方期待接收的下一个片段，所以ACK回复号为最后接收到的片段序号加1。

很多时候，ACK回复“附着”在发送的数据片段中。TCP协议是双向的。比如A和B两个电脑。ACK回复是接收方回复给发送方 (比如A发送给B， B回复A)。但同时，B也可以是发送方，B有可能有数据发送给A，所以B就把ACK回复附着在它要发送给A的数据片段的头部。这样可以减少ACK所占用的交通流量。一个片段可以只包含ACK回复。一个纯粹的ACK回复片段不传送文本流，所以不消耗序列号。如果有下一个正常的数据片段，它的序号将与纯粹ACK回复片段的序号相同。

(ACK回复还可以“附着”在SYN片段和FIN片段)

ACK后面还有SYN和FIN，它们也各占据一位(bit)。我将在后面说明这两位。

拥塞控制　

　　拥塞控制就是防止过多的数据注入网络中，这样可以使网络中的路由器或链路不致过载。拥塞控制是一个全局性的过程，和流量控制不同，流量控制指点对点通信量的控制。

慢启动与拥塞避免

　　发送方维持一个叫做拥塞窗口cwnd（congestion window）的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。发送方让自己的发送窗口等于拥塞窗口，另外考虑到接受方的接收能力，发送窗口可能小于拥塞窗口。

慢启动算法的思路就是，不要一开始就发送大量的数据，先探测一下网络的拥塞程度，也就是说由小到大逐渐增加拥塞窗口的大小。

实时拥塞窗口大小是以字节为单位的。

示例以数据包个数方便说明，示例如下图：



　　当收到确认后拥塞窗口就加倍，和后面的拥塞避免算法的加法增长比较，其实慢启动并不慢。

　　为了防止cwnd增长过大引起网络拥塞，还需设置一个慢开始门限ssthresh状态变量。ssthresh的用法如下：

　　当cwnd < ssthresh时，使用慢启动算法。

　　当cwnd > ssthresh时，改用拥塞避免算法。

　　当cwnd = ssthresh时，慢开始与拥塞避免算法任意。

　　拥塞避免算法让拥塞窗口缓慢增长，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍。这样拥塞窗口按线性规律缓慢增长。

　　无论是在慢启动阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（其根据就是没有收到确认，虽然没有收到确认可能是其他原因的分组丢失，但是因为无法判定，所以都当做拥塞来处理），就把慢开始门限设置为出现拥塞时的发送窗口大小的一半。然后把拥塞窗口设置为1，执行慢开始算法。如下图：

　　


说明：这里只是为了讨论方便而将拥塞窗口大小的单位改为数据报的个数，实际上应当是字节。

快速重传和快速恢复

　　快速重传要求接收方在收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等到自己发送数据时捎带确认。快重传算法规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。如下图：

　　


　　快速重传配合使用的还有快速恢复算法，有以下两个要点:

　　①当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把ssthresh门限减半。

　　②考虑到如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢启动算法，而是将cwnd设置为ssthresh的大小，然后执行拥塞避免算法。如下图：

　　

随机早期检测RED

　　以上的拥塞避免算法并没有和网络层联系起来，实际上网络层的策略对拥塞避免算法影响最大的就是路由器的丢弃策略。在简单的情况下路由器通常按照先进先出的策略处理到来的分组。当路由器的缓存装不下分组的时候就丢弃到来的分组，这叫做尾部丢弃策略。这样就会导致分组丢失，发送方认为网络产生拥塞。更为严重的是网络中存在很多的TCP连接，这些连接中的报文段通常是复用路由路径。若发生路由器的尾部丢弃，可能影响到很多条TCP连接，结果就是这许多的TCP连接在同一时间进入慢开始状态。这在术语中称为全局同步。全局同步会使得网络的通信量突然下降很多，而在网络恢复正常之后，其通信量又突然增大很多。为避免发生网路中的全局同步现象，路由器采用随机早期检测(RED:randomearly detection)。

　　使路由器的队列维持两个参数，即队列长队最小门限min和最大门限max，每当一个分组到达的时候，RED就计算平均队列长度。然后分情况对待到来的分组：

①平均队列长度小于最小门限——把新到达的分组放入队列排队。

②平均队列长度在最小门限与最大门限之间——则按照某一概率将分组丢弃。

③平均队列长度大于最大门限——丢弃新到达的分组。



　　以概率p随机丢弃分组，让拥塞控制只在个别的TCP连接上执行，因而避免全局性的拥塞控制。

　　RED的关键就是选择三个参数最小门限、最大门限、丢弃概率和计算平均队列长度。平均队列长度采用加权平均的方法计算平均队列长度，这和往返时间（RTT）的计算策略是一样的。