剖析TCP和UDP协议

TCP和UDP是TCP/IP协议中的两个传输层协议，它们使用IP路由功能把数据包发送到目的地，从而为应用程序及应用层协议（包括：HTTP、SMTP、SNMP、FTP和Telnet）提供网络服务。TCP提供的是面向连接的、可靠的数据流传输，而UDP提供的是非面向连接的、不可靠的数据流传输。面向连接的协议在任何数据传输前就建立好了点到点的连接。ATM和帧中继是面向连接的协议，但它们工作在数据链路层，而不是在传输层。普通的音频电话也是面向连接的。

可靠的传输协议可避免数据传输错误。其实现方式是：在构造数据包时在其中设置校验码，到达目的地后再采用一定的算法重新计算校验码，通过比较二者，就可以找出被破坏了的数据。因为需要重发被破坏了的和已经丢失的数据，所以在需要重发数据时协议必须能够使目的地给出源头的一个确认信号。有些数据包不一定按照顺序到达，所以协议必须能够探测出乱序的包，暂存起来，然后把它们按正确的次序送到应用层中去。另外，协议还必须能够找出并丢弃重复发送的数据。一组定时器可以限制针对不同确认的等待时间，这样就可以开始重新发送或重新建立连接。

数据流传输协议不支持位传输。TCP不能在一个包内以字节或位为单位构造数据，它只负责传输未经构造的8位字符串。

非面向连接的传输协议在数据传输之前不建立连接，而是在每个中间节点对非面向连接的包和数据包进行路由。没有点到点的连接，非面向连接的协议，如UDP，是不可靠的连接。当一个UDP数据包在网络中移动时，发送过程并不知道它是否到达了目的地，除非应用层已经确认了它已到达的事实。非面向连接的协议也不能探测重复的和乱序的包。标准的专业术语用“不可靠”来描述UDP。在现代网络中，UDP并不易于导致传输失败，但是你也不能肯定地说它是可靠的。

TCP工作流程

现在让我们一起来看看TCP段的各个域，在IP包中它们紧跟在IP头部信息之后。第一个16位确认了源端口，第二个16位确认了目的端口。端口的划分使IP主机之间可用单个的IP地址实现不同类型的并发连接。在绝大多数现代操作系统中，采用32位IP地址和16位端口地址的组合来确认一个接口。源接口和目的接口的组合就定义了一个连接。有216或65536个可能的端口。最低的1024个端口是常用的，它们是系统为特定的应用层协议所保留的默认设置。如：默认状态下，HTTP使用端口80，而POP3使用端口110。其它的应用可以使用编号更高的端口。

在接下来的两个域中，序列号和确认号是TCP实现可靠连接的关键。当建立一个TCP连接时，发送方主机发出一个随机的初始化序列号给初始化器，初始化器将其加1后送回确认域的起始器，这意味着下一个字节可以发送了。一旦数据开始流动，序列号和确认号将跟踪已发送了那些数据，那些数据已被确认。因为每个域都是32位，总共可以有232个值，所以每个域的范围是：0～4294967295，当超过上限时回到0。

4位的偏移量代表TCP头部一共有多少个32位的信息。这个信息是必不可少的，因为有可选的头部区域，偏移量标识了头部的结束和数据的开始。

TCP的设计者保留了接下来的6位，以防万一将来要对其进行扩展。实际上，自从RFC793（传输控制协议）1981年发布以来，还没人有恰当的理由使用这些位，在这一点上，Jon Postel和他的同事一定是过分谨慎了。

随后的6位每个都是一个标志。若UNG标志位的值为1，意味着远在头部紧急指针区域的数据是有效的；若ACK标志位的值为1，则意味着确认号区域中的数据是有效的。（注意：一个SYN包有一个有意义的序列号，但它的确认号是无意义的，因为它并不确认任何事件）PSH标志位使数据不必等待发送和等待接收。RST标志位将断开一个连接。SYN（同步）标志位意味着序列号是有效的，FIN（结束）标志位将指出发送方已经发完了数据。

16位长的窗口区域表示了“滑动窗口”的大小，也就是告诉发送方它已经准备好接收多少个字的数据。TCP通过调整窗口的大小来控制数据的流量。一个值为0的窗口意味着通告发送方：如果没有进一步的通知，接收器已满，不能再接收更多的数据了。大的窗口可以确保在任何给定的时间传输多达65536个未经确认的字节，但是，当重发定时器超时且又没有得到接收确认时，窗口将减半，从而有效地降低传输速率。

16位的校验码区域保证了数据的完整性，保护了TCP头部和IP头部的各个区域。发送方计算校验值并把它插入这个区域，接收方根据收到的包重新计算该值并比较二者，如果它们是匹配的，则认为数据是完整无损的。

当设置紧急标志位时，紧急指针是一个16位的偏移量，它代表必须加快的最后一个字。选择区域可以容纳0或多个32位字，可扩展TCP的性能。大多数常用的选择区域支持大于65536字节的窗口，从而缩短了等待确认的时间，尤其是在高传输率时。

TCP的传输机构有多个定时器。当一个包发送时，重发定时器开始计数；当收到确认信号后，重发定时器停止计数。如果超过设定时间段还没有收到确认信号，就重发该包。一个比较棘手的问题是如何设置该时间段。如果太长，当网络传输错误增加时将导致不必要的等待时间；如果太短，就会产生过多的重复包从而降低网络的反应时间。现代TCP协议根据实际情况对重发定时器进行动态设定。

持续定时器对于避免死锁是必不可少的。如果网络收到了一个大小为0的窗口确认并且丢失了随后的重发数据的确认，持续定时器将超时并发送一个探针。探针的回应将指出窗口的大小（也许仍为0）。保持定时器在本端没有任何活动后，将检查在连接的另一端是否还有运行的进程。如果没有任何回应，该定时器将断开连接。

当断开一个连接时，断开连接定时器将包的最大生命期加倍。该定时器在连接断开之前确保流量最大。

不管重发过程执行得多么有效，很少的丢失包就能严重地降低TCP连接的流量。每个未收到的包或包的片段只会在重发定时器超时的时候才会丢失。在数据重发时，接收过程一直在递送这些重发的数据，这样就使总体的数据传输陷于停顿，直到丢失的数据被取代为止。这些重发过程导致基于TCP的连接有时处于不稳定状态。

TCP与UDP的选择

如果比较UDP包和TCP包的结构，很明显UDP包不具备TCP包复杂的可靠性与控制机制。与TCP协议相同，UDP的源端口数和目的端口数也都支持一台主机上的多个应用。一个16位的UDP包包含了一个字节长的头部和数据的长度，校验码域使其可以进行整体校验。（许多应用只支持UDP，如：多媒体数据流，不产生任何额外的数据，即使知道有破坏的包也不进行重发。）

很明显，当数据传输的性能必须让位于数据传输的完整性、可控制性和可靠性时，TCP协议是当然的选择。当强调传输性能而不是传输的完整性时，如：音频和多媒体应用，UDP是最好的选择。在数据传输时间很短，以至于此前的连接过程成为整个流量主体的情况下，UDP也是一个好的选择，如：DNS交换。把SNMP建立在UDP上的部分原因是设计者认为当发生网络阻塞时，UDP较低的开销使其有更好的机会去传送管理数据。TCP丰富的功能有时会导致不可预料的性能低下，但是我们相信在不远的将来，TCP可靠的点对点连接将会用于绝大多数的网络应用。