TCP-IP详解之TCP的交互数据流2

TCP的交互数据流目录章节
1.交互式输入
2.经受时延的确认
3.Nagle算法

4.窗口大小通告

前言

如果按照分组数量计算，约有一半的T C P报文段包含成块数据（如 F T P、电子邮件和 U s e n e t新闻） ，另一半则包含交互数据（如Te l n e t和R l o g i n） 。如果按字节计算，则成块数据与交互数据的比例约为 9 0 %和1 0 %。这是因为成块数据的报文段基本上都是满长度（ f u l l - s i z e d）的（通常为5 1 2字节的用户数据） ，而交互数据则小得多（上述研究表明 Te l n e t和R l o g i n分组中通常约9 0 %左右的用户数据小于1 0个字节） 。

交互式输入

首先来观察在一个R l o g i n连接上键入一个交互命令时所产生的数据流。许多 T C P / I P的初学者很吃惊地发现通常每一个交互按键都会产生一个数据分组，也就是说，每次从客户传到服务器的是一个字节的按键（而不是每次一行） 。而且，R l o g i n需要远程系统（服务器）回显我们（客户）键入的字符。这样就会产生4个报文段： （1）来自客户的交互按键；（2）来自服务器的按键确认；（3）来自服务器的按键回显；（ 4）来自客户的按键回显确认。图1 9 - 1表示了这个数据流。
然而，我们一般可以将报文段 2和3进行合并—按键确认与按键回显一起发送。下一节将描述这种合并的技术（称为经受时延的确认） 。

经受时延的确认

把从b s d i发送到s r v 4的7个A C K标记为经受时延的A C K。通常T C P在接收到数据时并不立即发送A C K；相反，它推迟发送，以便将 A C K与需要沿该方向发送的数据一起发送（有时称这种现象为数据捎带A C K） 。绝大多数实现采用的时延为200 ms，也就是说，T C P将以最大200 ms的时延等待是否有数据一起发送。

Nagle算法

该算法要求一个T C P连接上最多只能有一个未被确认的未完成的小分组，在该分组的确认到达之前不能发送其他的小分组。相反， T C P收集这些少量的分组，并在确认到来时以一个分组的方式发出去。该算法的优越之处在于它是自适应的：确认到达得越快，数据也就发送得越快。而在希望减少微小分组数目的低速广域网上，则会发送更少的分组 。

 窗口大小通告

在图1 9 - 4中，我们可以观察到s l i p通告窗口大小为4 0 9 6字节，而v a n g o g h通告其窗口大小为8 1 9 2个字节。该图中的大多数报文段都包含这两个值中的一个。
然而，报文段5通告的窗口大小为4 0 9 5个字节，这意味着在T C P的缓冲区中仍然有一个字节等待应用程序（ R l o g i n客户）读取。同样，来自客户的下一个报文段声明其窗口大小为4 0 9 4个字节，这说明仍有两个字节等待读取。
服务器通常通告窗口大小为 8 1 9 2个字节，这是因为服务器在读取并回显接收到的数据之前，其T C P没有数据发送。当服务器已经读取了来自客户的输入后，来自服务器的数据将被发送。
然而，在A C K到来时，客户的T C P总是有数据需要发送。这是因为它在等待 A C K的过程中缓存接收到的字符。当客户T C P发送缓存的数据时，R l o g i n客户没有机会读取来自服务器的数据，因此，客户通告的窗口大小总是小于 4 0 9 6。