《TCP/IP详解卷3：TCP事务协议、HTTP、NNTP和UNIX域协议》 —3.7 向后兼容性

3.7   向后兼容性

我们还需要研究一下如果客户用T/TCP协议给一台不支持T/TCP协议的主机发送数据会发生什么情况。

图3-10显示的就是主机bsdi上的T/TCP客户程序向主机svr4(一个运行System V 版本4的主机，不支持T/TCP)上的TCP服务器发起事务时，它们二者之间分组交换的情况。

图3-10   T/TCP客户程序向TCP服务器发起事务

客户端的TCP程序发出的第1个报文段中包含了SYN、FIN和PSH标志，还包含了300字节数据。由于客户端的TCP协议在其TAO高速缓存中还没有该服务器主机svr4的连接计数(CC)值，因而它发出的报文段中带上了CCnew选项。图中第2行就是服务器对该报文段的响应，这是标准三次握手过程中的第2个报文段；而客户端在第3行中对该响应做出了确认。注意，第3行中没有重传数据。

服务器端收到第3行的报文段后，立即确认了客户一开始发过来的300字节数据和FIN标志(如卷2第791页所示，对FIN的确认从不推迟)。服务器端TCP将上述数据保存在队列中，直至三次握手过程结束才将其交给服务进程。

第5行显示的是服务器给出的响应(400字节数据)，客户端在第6行中立刻对此做出了确认。第7行显示的是服务器发出的FIN报文段，客户端同样也迅速地做出了确认。注意，服务器进程无法把第5行的数据和第7行的FIN结合在一起发送。

如果我们还是在这一对客户和服务器之间再发起一次事务，则报文段交换的顺序与上一次完全相同。由于在图3-10中服务器端并没有发回一个CCecho选项，因此客户端仍然无法向svr4主机发出带有CC选项的报文段，从而客户端发出的第1个报文段(即初始化报文段)仍然带有CCnew选项，其值为11。支持T/TCP的客户端总是发出CCnew选项的原因是，对不支持T/TCP的服务器，它从来不会更新在其单机高速缓存中的相关表项，因而tao_ccsent值总是0(未定义)。

在下面的例子(图3-11)中，服务器主机运行Solaris 2.4，这也是一个基于SVR4的系统(与图3-10中的服务器一样)，但二者的TCP/IP协议栈实现却完全不同。

第1~3行与图3-10中的相同：带有SYN、FIN、PSH标志和300字节数据的报文段，接着是服务器的SYN/ACK报文段，然后是客户的ACK报文段。这是一次正常的三次握手过程。同样，由于不知道该服务器的CC值，客户端TCP发出的是一个带有CCnew选项的报文段。

Solaris主机发出的每个报文段中携带的“不分段”标志(DF)，用于路径最大传输单元发现(RFC 1191 [Mogul and Deering 1990])。

图3-11   T/TCP客户向Solaris 2.4上的TCP服务器发送事务请求

不幸的是，我们在Solaris的TCP/IP实现中遇到了一个bug。因为这个bug，服务器端TCP把第1行中的数据部分扔掉了(第2个报文段中没有对该数据做确认)，造成客户端的TCP超时，并在第4行重传了数据，同时也重传了FIN。接着，服务器端确认了客户端发来的数据和FIN(第5行)，然后服务器端在第6行发出应答。客户端在第7行对应答给出确认，紧接着是服务器发出FIN报文段(第8行)，最后是客户端的确认(第9行)。

RFC 793 [Postel 1981b]的第30页中指出：“尽管这些例子并不证明采用附带数据的报文段也能实现连接同步，但这样处理也完全是合法的，接收端的TCP只有在搞清楚了数据是正确的以后才能将数据交付给用户(即，接收端对数据进行缓存，等到连接状态进入ESTABLISHED以后才能交付给用户)。”该RFC的第66页还说，在LISTEN状态处理接收到的SYN时，“任何其他控制信息和正文数据都要先放入队列待以后处理”。

有一个评论者声称，把上述现象叫作“bug”是不对的，因为RFC中并没有强制要求服务器在处理SYN的同时接受其中附带的数据。声明中还说，Solaris的实现是正确的，因为还没有向客户端通告接收窗口，这时服务器完全可以丢弃已到达的数据，因为这些数据都落在窗口之外。不管你如何评价这个特点(作者仍然称它们为bug，SUN公司也已经为这个问题分配了一个Bug ID 1222490，因此也将会在今后的版本中进行修正)，处理这样的情况还要符合健壮性原则，该原则在RFC 791 [Postel 1981a]中首次提出：“你有自由去决定接受什么，但你发送什么却必须遵守规定。”