【TCP/IP详解卷一：协议】第十九章 TCP的交互数据流-CSDN博客

19.1 引言

前一章我们介绍了TCP连接的建立与释放：三握四挥，以及状态转移图。
TCP报文段分为：交互数据，以及成块数据(下一章介绍)。
交互数据：例如telnet，ssh，这种类型的协议在大多数情况下只是做小流量的数据交换，比如说按一下键盘，回显一些文字等等。

一些关于通信量的研究发现：
按分组数量计算：一半的TCP报文段包含成块数据(FTP，电子邮件，Usenet新闻)，另外一半则包含交互数据(Telnet和Rlogin)。
按字节计算：90% ： 10%。这是因为成块数据基本上都是满长度的(full-sized)，一般为512字节的用户数据。而交互数据小的多(约90%的交互数据小于10字节)。

对于交互性要求比较高的应用，TCP给出两个策略来提高发送效率和减低网络负担：
(1)捎带ACK。
(2)Nagle算法（一次尽量多的发数据）。

19.2 交互式输入以 Rlogin 为例

我们来观察在一个 Rlogin连接上键入一个交互命令的时候产生的数据流。每一个交互按键都会产生一个数据分组。
一般有四个报文段：

(1)来自客户的交互数据键
(2)来自服务器的按键确认
(3)来自服务器的按键回显
(4)来自客户的回显确认

一般来说，上述的四个报文段中的第二个和第三个是一起发送的，称为 经受时延的确认。

19.3 经受时延的确认或者说捎带ack

TCP在收到数据的时候，一般不立刻进行ack的发送，相反，它推迟ack的发送，以便将 ack 与沿该方向传送的数据一起发送。这种现象也称为数据捎带ack。
大多数实现采用的时延为200ms，也就是说 TCP 将以200ms的时延等待是否有数据一起发送：采用了一个200ms的定时器，这个定时器以相对内核引导的200ms固定时间溢出。

19.4 Nagle 算法

Rlogin连接上客户一般每次发送一个字节到服务器，这就产生了一些 41字节长的分组(20字节的IP首部，20字节的TCP首部，1字节数据)，在局域网上(LAN)，这些微小分组(tinygram)通常不会引起麻烦，因为局域网一般不会出现网络拥塞。但是在广域网上，这些小分组则会增加拥塞出现的可能。一种好的方法：采用 Nagle算法。

Nagle算法要求 TCP连接上 最多只能有一个未被确认的未完成的小分组。在该分组确认到达之前不能发送其他的小分组，如果在分组确认到达之前有分组准备好了，TCP收集了放入缓存中，然后在确认到来的时候一起发送出去。
该算法的优越地方在于：自适应。确认到达的越快，发送的也越快。而在希望减小微小分组的广域网上，则会发送更少的分组。

在局域网上两个主机之间发送数据的时候很少使用这个算法。

简单的来说，这个算法的目的，是减少在广域网上的小包的数量，以避免网络拥塞。利用的原理是，在发送出去的包确认到达之前，把准备好的包存储起来，等到确认到来的时候，以一个大包的形式发送出去。

TCP可以在应用读取并处理数据前发送所接收数据的确认。这个TCP确认仅仅只是表明 TCP已经正确接收了数据。

19.4.1 关闭 Nagle算法

但是我们有时候也需要关闭 Nagle 算法，比如 X窗口服务系统：小消息(鼠标移动)必须无时延的发送，以便进行某种操作的交互用户进行及时反馈。
插口API用户可以使用 TCP_NODELAY套接字 选项来关闭 Nagle 算法。

RFC 声明，TCP必须实现 Nagle算法，但是必须为应用提供关闭在某个连接上的 Nagle算法的方法。

窗口大小通告 8192/4096

服务器通常的通告窗口大小为8192字节。这是因为服务器在读取并回显接收到的数据之前，TCP没有数据发送。
但是，在ACK到来的时候，客户的TCP总是有数据需要发送，这是因为在等待ACK 的过程中，积累了数据字符。当客户发送缓存的数据的时候，客户并没有时间读取来自服务器的数据，因此，客户通告的窗口大小总小于 4096.