《TCP/IP详解卷3：TCP事务协议、HTTP、NNTP和UNIX域协议》 —2.4 状态变迁图

2.4   状态变迁图

TCP协议的工作过程可以用图2-6所示的状态变迁图来描述。大多数状态变迁图都把状态变迁时发送的报文段标在变迁线的边上。例如，从CLOSED状态到SYN_SENT状态的变迁就标明发送了一个SYN报文段。在图2-6中则没有采用这种标记方法，而是在每个状态框中标出处于该状态时要发送的报文段类型。例如，当处于SYN_RECV状态时，要发出一个带有SYN的报文段，其中还包括对所收到SYN的确认(ACK)。而当处于CLOSE_WAIT状态时，要发出对所收到FIN的确认(ACK)。

我们之所以要这样做，是因为在T/TCP协议中我们经常需要处理可能造成多次状态变迁的报文段。于是在处理一个报文段时，重要的是处理完报文段后连接所处的最终状态，因为它决定了应答的内容。而如果不使用T/TCP协议，每收到一个报文段通常至多只引起一次状态变迁，只有在收到SYN/ACK报文段时才是例外，很快我们就要讨论这个问题。

与RFC 793 [Postel 1981b]中的TCP协议状态变迁图相比，图2-6还有另外一些不同之处。

在RFC 793的状态变迁图中，当应用程序发送数据时，会有从LISTEN状态到SYN_SENT状态的变迁。但实际上典型的API很少提供这种功能。

RFC 1122 [Braden 1989]中描绘了一个直接从FIN_WAIT_1状态到TIME_WAIT状态的变迁，这发生在收到了一个带有FIN和对所发FIN的确认(ACK)的报文段时。但是当收到这样一个报文段时，通常都是先处理ACK使状态变迁到FIN_WAIT_2，接着再处理FIN，并变迁到TIME_WAIT状态。因此，图2-6也能正确处理这样的报文段。这就是收到一个报文段导致两次状态变迁的例子。

除了SYN_SENT之外的所有状态都发送ACK(端点处于LISTEN状态时，则什么也不发送)。这是因为发送ACK是不受条件限制的：标准TCP报文段的首部总是留有ACK的位置。因此，TCP总是确认已接收到的报文段最高序列号(加1)，只有在处理主动打开(SYN_SENT)的SYN报文段和一些重建(RST)报文段时才例外。

TCP输入的处理顺序

TCP协议收到报文段时，对其中所携带的各种控制信息(SYN、FIN、ACK、URG和RST标志，还可能有数据和选项)的处理顺序不是随意的，也不是各种实现可以自行决定的。RFC 793中对处理顺序有明确的规定。图11-1对这些步骤做了一个小结，该小结同时也用黑体标明了T/TCP中所做的改动。

例如，当T/TCP客户收到一个携带有SYN、数据、FIN和ACK的报文段时，协议首先处理的是SYN(因为此时的插口还处于SYN_SENT状态)，接着是ACK标志，再接着是数据，最后才是FIN。三个标志中的任何一个都有可能引起相应插口的连接状态改变。

图2-6   TCP的状态变迁图