[转帖]T/TCP状态变迁

billjock

大多数状态变迁图都把状态变迁时发送的报文段标在变迁线的边上。例如，从CLOSED 状态到SYN_SENT状态的变迁就标明发送了一个SYN报文段。每个状态中标出处于该状态时

要发送的报文段类型。例如：当处于SYN_RECV状态时，要发出一个带有SYN的报文段，其中还包括对所收到SYN的确认（ACK）。而当处于CLOSE_WAIT状态时，要发出对所收到FIN的

确认（ACK）。
   
    我们之所以要这样做是因为，在T/TCP协议中我们经常需要处理可能造成多次状态变迁的报文段。于是在处理一个报文段时，重要的是处理完报文段后连接所处的最终状态，因

为它决定了应答的内容。而如果不使用T/TCP协议，每收到一个报文段通常至多只引起一次状态变迁，只有在收到SYN/ACK报文段时才是例外。
   
    1)、RFC 793的状态变迁图中，当应用程序发送数据时，会有从LISTEN状态到SYN_SENT状态的变迁。但实际上典型的API很少提供这种功能。


    2)、RFC 1122中描绘了一个直接从FIN_WAIT_1状态到TIME_WAIT状态的变迁，这发生在收到了一个带有FIN和对所发FIN的确认（ACK)的报文段时。但是当收到这样一个报文段时

，通常都是先处理ACK使状态变迁到FIN_WAIT_2，接着再处理FIN，并变迁到TIME_WAIT状态。
   
    3)、除了SYN_SENT之外的所有状态都发送ACK（处于LISTEN这个末梢状态时，则什么也不发送）。这是因为发送ACK是不受条件限制的：标准TCP报文段的首部总是留有ACK的位

置。因此，TCP总是确认已接收到的报文段最高序列号（加1），只有在处理主动打开(SYN_SENT)的SYN报文段和一些重建(RST)报文段时才是例外。

                                                        
               文章来源于>>TCP/IP协议分析博客   需转载请注明：Toad的博客