《TCP/IP详解卷3：TCP事务协议、HTTP、NNTP和UNIX域协议》 —1.7 应用

1.7   应用

T/TCP给所有TCP上的应用程序带来的第一个好处就是可以缩短TIME_WAIT状态的持续时间。这样，一般情况下协议必须处理的控制块也跟着少了。4.4节详细介绍了T/TCP协议的这个特性。现在可以这样说：对于连接时间很短(典型值为小于2分钟)的所有TCP应用程序，如果通信双方的主机都支持T/TCP，它们都将因使用该协议而获益。

使用T/TCP的最大好处或许在于避免了三次握手过程，对于那些交换的数据量比较小的应用程序，T/TCP减少的时延将给它们带来好处。我们将给出几个例子来说明这一点(附录B谈到了利用T/TCP来避免三次握手过程要对应用程序做怎样的修改)。

1. WWW：超文本传输协议

WWW及其所依赖的HTTP协议(将在第13章介绍该协议)将可能大大地受益于T/TCP协议。参考书[Mogul 1995b]中指出：“然而，构成Web应用传输时延的主要因素是网络通信……即便无法提高光的传播速度，但我们至少应该想办法减少一次交互过程中的往返传输次数。当前Web网中使用的超文本传输协议(HTTP)实际上造成了大量不必要的往返传输”。

比如，[Mogul 1995b]中对随机抽取的200 000个HTTP请求的统计发现，应答长度的中值为1770字节(通常使用中值而不使用均值，是因为很少出现的大文件会使均值变大)。Mogul 还引用了另一个例子。该例随机抽样了大约150万个请求，其应答的长度中值为958字节。客户的请求一般很短：在100~300字节之间。

典型的HTTP客户-服务器事务和图1-8所示的很相似。客户端主动打开，向服务器发出很短的请求，服务器收到请求后发出应答，然后服务器关闭连接。这种情况非常适于使用T/TCP协议，把客户端的SYN和客户的请求合并在一起传送以省去三次握手中的往返时间。这还会减少网络上的分组数，对于已经非常巨大的Web通信量来说也是很有意义的。

2. FTP数据连接

FTP数据连接也会从使用T/TCP协议中获益。从一项对Internet通信量的统计调查中，[Paxson 1994b]发现平均每个FTP数据连接所传输的数据量约为3000字节。卷1的第323页给出了FTP数据连接的一个例子。虽然例子中的数据流是单向的，但其传输过程还是与图1-12所示的十分相似。采用T/TCP后，图中的8个报文段减少到了3个。

3. 域名服务系统(DNS)

DNS客户的查询请求是用UDP传送到DNS服务器的。服务器仍然用UDP发送给客户的应答。但如果应答超过512字节，那么只有前512字节会在应答中返回给客户，同时在应答中有“truncated”(截断)标志，表示还有信息要传给客户。于是客户用TCP向服务器重新发送查询请求，而后服务器用TCP向客户传送完整的应答。

采用这项技术的原因是不能保证特定的主机能够重组长度超过576字节的IP数据报(实际上，许多UDP应用程序都把用户数据的长度限定在512字节以内，以保证不超过576字节的限制)。由于TCP是一个字节流协议，应答数据量再大也不会有问题。发送方TCP会根据连接建立时对等端声明的报文段最大长度(MSS)限制，把应用程序的应答数据分割成适当长度的报文段发给对方。接收方TCP会把这些报文段拼接起来，并以应用程序读取时指定的数据长度交给接收的应用程序。

DNS的客户和服务器可以利用T/TCP，既达到UDP的请求-应答速度，又具有TCP的所有好处。

4. 远程过程调用(RPC)

在所有论述将传输协议用于事务的论文中，无不将RPC作为一个候选的应用协议。RPC中客户要向载有待执行程序的服务器发送请求，请求中带有客户给定的参数；服务器的应答中包括过程执行后所返回的结果。参考书[Stevens 1994]的29.2节中讨论了Sun RPC。

RPC的数据包往往非常大，必须给RPC协议增加可靠性，使其能在像UDP这样不保证可靠性的协议上运行，同时还要避免TCP的三次握手。使用T/TCP协议就能实现这一目标，既有TCP的可靠性，又没有三次握手的开销。

所有建立在RPC基础上的应用程序，比如网络文件系统(NFS)等都可以采用T/TCP协议。