TCP协议的部分解析

ZDNET网络频道 09月20日 综合消息：本文以TCP的发展历程解析容易引起混淆，误会的方方面面，大多数是以文字形式描述，我相信文字看起来是要比代码更轻松的。针对对象：对TCP已经有了全面了解的人。因为本文不会解析TCP头里面的每一个字段或者3次握手的细节，也不会解释慢启动和快速重传的定义

1.网络协议设计

ISO提出了OSI分层网络模型，这种分层模型是理论上的，TCP/IP最终实现了一个分层的协议模型，每一个层次对应一组网络协议完成一组特定的功能，该组网络协议被其下的层次复用和解复用。这就是分层模型的本质，最终所有的逻辑被编码到线缆或者电磁波。

分层模型是很好理解的，然而对于每一层的协议设计却不是那么容易。TCP/IP的漂亮之处在于：协议越往上层越复杂。我们把网络定义为互相连接在一 起的设备，网络的本质作用还是“端到端”的通信，然而希望互相通信的设备并不一定要“直接”连接在一起，因此必然需要一些中间的设备负责转发数据，因此就 把连接这些中间设备的线缆上跑的协议定义为链路层协议，实际上所谓链路其实就是始发与一个设备，通过一根线，终止于另一个设备。我们把一条链路称为“一 跳”。因此一个端到端的网络包含了“很多跳”。

2.TCP和IP协议

终止于IP协议，我们已经可以完成一个端到端的通信，为何还需要TCP协议?这是一个问题，理解了这个问题，我们就能理解TCP协议为何成了现在这个样子，为何如此“复杂”，为何又如此简单。

正如其名字所展示的那样，TCP的作用是传输控制，也就是控制端到端的传输，那为何这种控制不在IP协议中实现的。答案很简单，那就是这会增加IP协议的复杂性，而IP协议需要的就是简单。这是什么原因造成的呢?

首先我们认识一下为何IP协议是沙漏的细腰部分。它的下层是繁多的链路层协议，这些链路提供了相互截然不同且相差很远的语义，为了互联这些异构的网 络，我们需要一个网络层协议起码要提供一些适配的功能，另外它必然不能提供太多的“保证性服务”，因为上层的保证性依赖下层的约束性更强的保证性，你永远 无法在一个100M吞吐量的链路之上实现的IP协议保证1000M的吞吐量...

IP协议设计为分组转发协议，每一跳都要经过一个中间节点，路由的设计是TCP/IP网络的另一大创举，这样，IP协议就无需方向性，路由信息和协 议本身不再强关联，它们仅仅通过IP地址来关联，因此，IP协议更加简单。路由器作为中间节点也不能太复杂，这涉及到成本问题，因此路由器只负责选路以及 转发数据包。

因此传输控制协议必然需要在端点实现。在我们详谈TCP协议之前，首先要看一下它不能做什么，由于IP协议不提供保证，TCP也不能提供依赖于IP 下层链路的这种保证，比如带宽，比如时延，这些都是链路层决定的，既然IP协议无法修补，TCP也不能，然而它却能修正始于IP层的一些“不可保证性 质”，这些性质包括IP层的不可靠，IP层的不按顺序，IP层的无方向/无连接。

将该小节总结一下，TCP/IP 模型从下往上，功能增加，需要实现的设备减少，然而设备的复杂性却在增加，这样保证了成本的最小化，至于性能或者因素，靠软件来调节吧，TCP协议就是这 样的软件，实际上最开始的时候，TCP并不考虑性能，效率，公平性，正是考虑了这些，TCP协议才复杂了起来。

3.TCP协议

这是一个纯软件协议，为何将其设计上两个端点，参见上一小节，本节详述TCP协议，中间也穿插一些简短的论述。

3.1.TCP协议

确切的说，TCP协议有两重身份，作为网络协议，它弥补了IP协议尽力而为服务的不足，实现了有连接，可靠传输，报文按序到达。作为一个主机软件， 它和 UDP以及左右的传输层协议隔离了主机服务和网络，它们可以被看做是一个多路复用/解复用器，将诸多的主机进程数据复用/解复用到IP层。可以看出，不管 从哪个角度，TCP都作为一个接口存在，作为网络协议，它和对端的TCP接口，实现TCP的控制逻辑，作为多路复用/解复用器，它和下层IP 协议接口，实现协议栈的功能，而这正是分层网络协议模型的基本定义(两类接口，一类和下层接口，另一类和对等层接口)。

我们习惯于将TCP作为协议栈的最顶端，而不把应用层协议当成协议栈的一部分，这部分是因为应用层被TCP/UDP解复用了之后，呈现出了一种太复 杂的局面，应用层协议用一种不同截然不同的方式被解释，应用层协议习惯于用类似ASN.1标准来封装，这正体现了TCP协议作为多路复用/解复用器的重要 性，由于直接和应用接口，它可以很容易直接被应用控制，实现不同的传输控制策略，这也是TCP被设计到离应用不太远的地方的原因之一。

总之，TCP要点有四，一曰有连接，二曰可靠传输，三曰数据按照到达，四曰端到端流量控制。注意，TCP被设计时只保证这四点，此时它虽然也有些问 题，然而很简单，然而更大的问题很快呈现出来，使之不得不考虑和IP网络相关的东西，比如公平性，效率，因此增加了拥塞控制，这样TCP就成了现在这个样 子。

3.2.有连接，可靠传输，数据按序到达的TCP

IP 协议是没有方向的，数据报传输能到达对端全靠路由，因此它是一跳一跳地到达对端的，只要有一跳没有到达对端的路由，那么数据传输将失败，其实路由也是互联 网的核心之一，实际上IP层提供的核心基本功能有两点，第一点是地址管理，第二点就是路由选路。TCP利用了IP路由这个简单的功能，因此TCP不必考虑 选路，这又一个它被设计成端到端协议的原因。

既然IP已经能尽力让单独的数据报到达对端，那么TCP就可以在这种尽力而为的网络上实现其它的更加严格的控制功能。TCP给无连接的IP网络通信增加了连接性，确认了已经发送出去的数据的状态，并且保证了数据的顺序。

3.2.1.有连接

这是TCP的基本，因为后续的传输的可靠性以及数据顺序性都依赖于一条连接，这是最简单的实现方式，因此TCP被设计成一种基于流的协议，既然TCP需要事先建立连接，之后传输多少数据就无所谓了，只要是同一连接的数据能识别出来即可。

疑难杂症1：3次握手和4次挥手

TCP 使用3次握手建立一条连接，该握手初始化了传输可靠性以及数据顺序性必要的信息，这些信息包括两个方向的初始序列号，确认号由初始序列号生成，使用3次握 手是因为3次握手已经准备好了传输可靠性以及数据顺序性所必要的信息，该握手的第3次实际上并不是需要单独传输的，完全可以和数据一起传输。

TCP使用4次挥手拆除一条连接，为何需要4次呢?因为TCP是一个全双工协议，必须单独拆除每一条信道。注意，4次挥手和3次握手的意义是不同 的，很多人都会问为何建立连接是3次握手，而拆除连接是4次挥手。3次握手的目的很简单，就是分配资源，初始化序列号，这时还不涉及数据传输，3次就足够 做到这个了，而 4次挥手的目的是终止数据传输，并回收资源，此时两个端点两个方向的序列号已经没有了任何关系，必须等待两方向都没有数据传输时才能拆除虚链路，不像初始 化时那么简单，发现SYN标志就初始化一个序列号并确认SYN的序列号。因此必须单独分别在一个方向上终止该方向的数据传输。

疑难杂症2：TIME_WAIT状态

为何要有这个状态，原因很简单，那就是每次建立连接的时候序列号都是随机产生的，并且这个序列号是32位的，会回绕。现在我来解释这和TIME_WAIT有什么关系。

任何的TCP分段都要在尽力而为的IP网络上传输，中间的路由器可能会随意的缓存任何的IP数据报，它并不管这个IP数据报上被承载的是什么数据， 然而根据经验和互联网的大小，一个IP数据报最多存活MSL(这是根据地球表面积，电磁波在各种介质中的传输速率以及IP协议的TTL等综合推算出来的， 如果在火星上，这个MSL会大得多...)。

现在我们考虑终止连接时的被动方发送了一个FIN，然后主动方回复了一个ACK，然而这个ACK可能会丢失，这会造成被动方重发FIN，这个FIN可能会在互联网上存活MSL。

如果没有TIME_WAIT的话，假设连接1已经断开，然而其被动方最后重发的那个FIN(或者FIN之前发送的任何TCP分段)还在网络上，然而 连接2 重用了连接1的所有的5元素(源IP，目的IP，TCP，源端口，目的端口)，刚刚将建立好连接，连接1迟到的FIN到达了，这个FIN将以比较低但是确 实可能的概率终止掉连接2.

为何说是概率比较低呢?这涉及到一个匹配问题，迟到的FIN分段的序列号必须落在连接2的一方的期望序列号范围之内。虽然这种巧合很少发生，但确实 会发生，毕竟初始序列号是随机产生了。因此终止连接的主动方必须在接受了被动方且回复了ACK之后等待2*MSL时间才能进入CLOSE状态，之所以乘以 2是因为这是保守的算法，最坏情况下，针对被动方的ACK在以最长路线(经历一个MSL)经过互联网马上到达被动方时丢失。

为了应对这个问题，RFC793对初始序列号的生成有个建议，那就是设定一个基准，在这个基准之上搞随机，这个基准就是时间，我们知道时间是单调递 增的。然而这仍然有问题，那就是回绕问题，如果发生回绕，那么新的序列号将会落到一个很低的值。因此最好的办法就是避开“重叠”，其含义就是基准之上的随 机要设定一个范围。

要知道，很多人很不喜欢看到服务器上出现大量的TIME_WAIT状态的连接，因此他们将TIME_WAIT的值设置的很低，这虽然在大多数情况下可行，然而确实也是一种冒险行为。最好的方式就是，不要重用一个连接。

疑难杂症3：重用一个连接和重用一个套接字

这是根本不同的，单独重用一个套接字一般不会有任何问题，因为TCP是基于连接的。比如在服务器端出现了一个TIME_WAIT连接，那么该连接标 识了一个五元素，只要客户端不使用相同的源端口，连接服务器是没有问题的，因为迟到的FIN永远不会到达这个连接。记住，一个五元素标识了一个连接，而不 是一个套接字(当然，对于BSD套接字而言，服务端的accept套接字确实标识了一个连接)。

3.2.2.传输可靠性

基本上传输可靠性是靠确认号实现的，也就是说，每发送一个分段，接下来接收端必然要发送一个确认，发送端收到确认后才可以发送下一个字节。这个原则 最简单不过了，教科书上的“停止-等待”协议就是这个原则的字节版本，只是TCP使用了滑动窗口机制使得每次不一定发送一个字节，但是这是后话，本节仅仅 谈一下确认的超时机制。

怎么知道数据到达对端呢?那就是对端发送一个确认，但是如果一直收不到对端的确认，发送端等多久呢?如果一直等下去，那么将无法发现数据的丢失，协议将不可用，如果等待时间过短，可能确认还在路上，因此等待时间是个问题，另外如何去管理这个超时时间也是一个问题。

疑难杂症4：超时时间的计算

绝对不能随意去揣测超时的时间，而应该给出一个精确的算法去计算。毫无疑问，一个TCP分段的回复到达的时间就是一个数据报往返的时间，因此标准定 义了一个新的名词RTT，代表一个TCP分段的往返时间。然而我们知道，IP网络是尽力而为的，并且路由是动态的，且路由器会毫无先兆的缓存或者丢弃任何 的数据报，因此这个RTT是需要动态测量的，也就是说起码每隔一段时间就要测量一次，如果每次都一样，万事大吉，然而世界并非如你所愿，因此我们需要找到 的恰恰的一个“平均值”，而不是一个准确值。

这个平均值如果仅仅直接通过计算多次测量值取算术平均，那是不恰当的，因为对于数据传输延时，我们必须考虑的路径延迟的瞬间抖动，否则如果两次测量 值分别为2和98，那么超时值将是50，这个值对于2而言，太大了，结果造成了数据的延迟过大(本该重传的等待了好久才重传)，然而对于98而言，太小 了，结果造成了过度重传(路途遥远，本该很慢，结果大量重传已经正确确认但是迟到的TCP分段)。

因此，除了考虑每两次测量值的偏差之外，其变化率也应该考虑在内，如果变化率过大，则通过以变化率为自变量的函数为主计算RTT(如果陡然增大，则 取值为比较大的正数，如果陡然减小，则取值为比较小的负数，然后和平均值加权求和)，反之如果变化率很小，则取测量平均值。这是不言而喻的，这个算法至今 仍然工作的很好。

疑难杂症5：超时计时器的管理-每连接单一计时器

很显然，对每一个TCP分段都生成一个计时器是最直接的方式，每个计时器在RTT时间后到期，如果没有收到确认，则重传。然而这只是理论上的合理， 对于大多数操作系统而言，这将带来巨大的内存开销和调度开销，因此采取每一个TCP连接单一计时器的设计则成了一个默认的选择。可是单一的计时器怎么管理 如此多的发出去的TCP分段呢?又该如何来设计单一的计时器呢。

设计单一计时器有两个原则：1.每一个报文在长期收不到确认都必须可以超时;2.这个长期收不到中长期不能和测量的RTT相隔太远。因此RFC2988定义一套很简单的原则：

a.发送TCP分段时，如果还没有重传定时器开启，那么开启它。

b.发送TCP分段时，如果已经有重传定时器开启，不再开启它。

c.收到一个非冗余ACK时，如果有数据在传输中，重新开启重传定时器。

d.收到一个非冗余ACK时，如果没有数据在传输中，则关闭重传定时器。

我们看看这4条规则是如何做到以上两点的，根据a和c(在c中，注意到ACK是非冗余的)，任何TCP分段只要不被确认，超时定时器总会超时的。然 而为何需要c呢?只有规则a存在的话，也可以做到原则1。实际上确实是这样的，但是为了不会出现过早重传，才添加了规则c，如果没有规则c，那么万一在重 传定时器到期前，发送了一些数据，这样在定时器到期后，除了很早发送的数据能收到ACK外，其它稍晚些发送的数据的ACK都将不会到来，因此这些数据都将 被重传。有了规则c之后，只要有分段ACK到来，则重置重传定时器，这很合理，因此大多数正常情况下，从数据的发出到ACK的到来这段时间以及计算得到的 RTT以及重传定时器超时的时间这三者相差并不大，一个ACK到来后重置定时器可以保护后发的数据不被过早重传。

这里面还有一些细节需要说明。一个ACK到来了，说明后续的ACK很可能会依次到来，也就是说丢失的可能性并不大，另外，即使真的有后发的TCP分 段丢失现象发生，也会在最多2倍定时器超时时间的范围内被重传(假设该报文是第一个报文发出启动定时器之后马上发出的，丢失了，第一个报文的ACK到来后 又重启了定时器，又经过了一个超时时间才会被重传)。虽然这里还没有涉及拥塞控制，但是可见网络拥塞会引起丢包，丢包会引起重传，过度重传反过来加重网络 拥塞，设置规则c的结果可以缓解过多的重传，毕竟将启动定时器之后发送的数据的重传超时时间拉长了最多一倍左右。最多一倍左右的超时偏差做到了原则2，即 “这个长期收不到中长期不能和测量的RTT相隔太远”。

还有一点，如果是一个发送序列的最后一个分段丢失了，后面就不会收到冗余ACK，这样就只能等到超时了，并且超时时间几乎是肯定会比定时器超时时间更长。如果这个分段是在发送序列的靠后的时间发送的且和前面的发送时间相隔时间较远，则其超时时间不会很大，反之就会比较大。

疑难杂症6：何时测量RTT

目前很多TCP实现了时间戳，这样就方便多了，发送端再也不需要保存发送分段的时间了，只需要将其放入协议头的时间戳字段，然后接收端将其回显在ACK即可，然后发送端收到ACK后，取出时间戳，和当前时间做算术差，即可完成一次RTT的测量。

3.2.3.数据顺序性

基本上传输可靠性是靠序列号实现的。

疑难杂症7：确认号和超时重传

确认号是一个很诡异的东西，因为TCP的发送端对于发送出去的一个数据序列，它只要收到一个确认号就认为确认号前面的数据都被收到了，即使前面的某 个确认号丢失了，也就是说，发送端只认最后一个确认号。这是合理的，因为确认号是接收端发出的，接收端只确认按序到达的最后一个TCP分段。

另外，发送端重发了一个TCP报文并且接收到该TCP分段的确认号，并不能说明这个重发的报文被接收了，也可能是数据早就被接收了，只是由于其 ACK丢失或者其ACK延迟到达导致了超时。值得说明的是，接收端会丢弃任何重复的数据，即使丢弃了重复的数据，其ACK还是会照发不误的。

标准的早期TCP实现为，只要一个TCP分段丢失，即使后面的TCP分段都被完整收到，发送端还是会重传从丢失分段开始的所有报文，这就会导致一个 问题，那就是重传风暴，一个分段丢失，引起大量的重传。这种风暴实则不必要的，因为大多数的TCP实现中，接收端已经缓存了乱序的分段，这些被重传的丢失 分段之后的分段到达接收端之后，很大的可能性是被丢弃。关于这一点在拥塞控制被引入之后还会提及(问题先述为快：本来报文丢失导致超时就说明网络很可能已 然拥塞，重传风暴只能加重其拥塞程度)。

疑难杂症8：乱序数据缓存以及选择确认

TCP 是保证数据顺序的，但是并不意味着它总是会丢弃乱序的TCP分段，具体会不会丢弃是和具体实现相关的，RFC建议如果内存允许，还是要缓存这些乱序到来的 分段，然后实现一种机制等到可以拼接成一个按序序列的时候将缓存的分段拼接，这就类似于IP协议中的分片一样，但是由于IP数据报是不确认的，因此IP协 议的实现必须缓存收到的任何分片而不能将其丢弃，因为丢弃了一个IP分片，它就再也不会到来了。

现在，TCP实现了一种称为选择确认的方式，接收端会显式告诉发送端需要重传哪些分段而不需要重传哪些分段。这无疑避免了重传风暴。

疑难杂症9：TCP序列号的回绕的问题

TCP 的序列号回绕会引起很多的问题，比如序列号为s的分段发出之后，m秒后，序列号比s小的序列号为j的分段发出，只不过此时的j比上一个s多了一圈，这就是 回绕问题，那么如果这后一个分段到达接收端，这就会引发彻底乱序-本来j该在s后面，结果反而到达前面了，这种乱序是TCP协议检查不出来的。我们仔细想 一下，这种情况确实会发生，数据分段并不是一个字节一个字节发送出去的，如果存在一个速率为1Gbps的网络，TCP发送端1秒会发送125MB的数 据，32位的序列号空间能传输2的32次方个字节，也就是说32秒左右就会发生回绕，我们知道这个值远小于MSL值，因此会发生的。

有个细节可能会引起误会，那就是TCP的窗口大小空间是序列号空间的一半，这样恰好在满载情况下，数据能填满发送窗口和接收窗口，序列号空间正好够 用。然而事实上，TCP的初始序列号并不是从0开始的，而是随机产生的(当然要辅助一些更精妙的算法)，因此如果初始序列号比较接近2的32次方，那么很 快就会回绕。

当然，如今可以用时间戳选项来辅助作为序列号的一个识别的部分，接收端遇到回绕的情况，需要比较时间戳，我们知道，时间戳是单调递增的，虽然也会回 绕，然而回绕时间却要长很多。这只是一种策略，在此不详谈。还有一个很现实的问题，理论上序列号会回绕，但是实际上，有多少TCP的端点主机直接架设在 1G的网络线缆两端并且接收方和发送方的窗口还能恰好被同时填满。另外，就算发生了回绕，也不是一件特别的事情，回绕在计算机里面太常见了，只需要能识别 出来即可解决，对于TCP的序列号而言，在高速网络(点对点网络或者以太网)的两端，数据发生乱序的可能性很小，因此当收到一个序列号突然变为0或者终止 序列号小于起始序列号的情况后，很容易辨别出来，只需要和前一个确认的分段比较即可，如果在一个经过路由器的网络两端，会引发IP数据报的顺序重排，对于 TCP而言，虽然还会发生回绕，也会慢得多，且考虑到拥塞窗口(目前还没有引入)一般不会太大，窗口也很难被填满到65536。

3.2.4.端到端的流量控制

端到端的流量控制使用滑动窗口来实现。滑动窗口的原理非常简单，基本就是一个生产者/消费者模型

疑难杂症10：流量控制的真实意义

很多人以为流量控制会很有效的协调两端的流量匹配，确实是这样，但是如果你考虑到网络的利用率问题，TCP的流量控制机制就不那么完美了，造成这种 局面的原因在于，滑动窗口只是限制了最大发送的数据，却没有限制最小发送的数据，结果导致一些很小的数据被封装成TCP分段，报文协议头所占的比例过于 大，造成网络利用率下降，这就引出了接下来的内容，那就是端到端意义的TCP协议效率。