有关数据的传输
- 按照分组数据计算，约有一半的TCP报文包含成块数据(eg:FTP、电子邮件、Usenet新闻) ， 另一半包含交互数据(eg:Telnet、 Rlogin)
- 按照字节计算， 成块数据与交互数据的比例约为90% 和10% 。 因为成块数据的报文段基本上是满长度的(full-sized)的(通常为512字节 的用户数据)，而交互数据则小得多。
今天主要讨论的是交互数据， 以Rlogin为例， 揭示时延的去人是如何工作的以及Nagle算法怎么减少了通过广域网络传输的小分组的数目
交互式输入
一种数据流的交互回显
- 通常每个交互的按键都会产生一个数据分组
- 上面的例子，就会产生了4个报文段：《1》来自客户端的交互按键 《2》来自服务器的按键确认 《3》来自服务器的按键回显 《4》来自客户的按键回显确认。
PS: 发现传输的有效数据是非常小的， 传输的效率相对较低， 上面的例子，后来一般2、3会进行一次合并一起的传输—— 【经受时延的确认】。
经受时延的确认【delay ack】
- 通常TCP在接收到数据时，并不立即发送ACK， 相反， 它推迟发送， 以便将ACK与需要沿该方向发送的数据一起发送(有时称这种现象数据捎带ACK)。绝大多数实现采用的时延为200ms， 也就是说， TCP将以
最大的200ms的时延等待是否有数据一起发送。
Nagle算法
- 该算法要求一个TCP连接上最多只能有一个未被去人的未完成的小分组， 在改分组的去人到达之前不能发送其他的小分组。 相反， TCP收集这些少量的分组， 并在确认到来时以一个分组的方式发出去。 该算法的优越之处在于它是自适应的： 确认到达得越快， 数据也就发送得越快。 而在希望减少微小分组数目的低速广域网上， 则会发送更少的分组。
- 注意到从左到右边大司法数据长度是不同的，分别是： 1、1、2、1、2、2、3、1 和3个字节。 这是因为客户只有接收到前一个数据的确认后才发送已经收集的数据。 通过使用Nagle算法，为发送16字节的数据客户只需要使用9个报文段， 而不再是16个。 —— 比较自适应网络的方法
- 有时， 我们需要关闭Nagle算法，一个线性的例子是X窗口系统服务器： 小消息(鼠标移动)必须无时延地发送， 以便为进行某种操作的交互用户提供实时的反馈。 —— Nagle算法增加了时延，所以要求严格时延的场景时必须关闭Nagle算法的
另外一个场景：在一个交互注册过程中，键入终端的一个特殊功能键。 这个功能通常可以产生多个字符序列， 经常从ASCII码转义(escape)字符开始。 如果TCP每次得到一个字符，它很可能会发送序列中的第一个字符(ASCII 嘛的ESC)， 然后缓存其他字符并等待对改字符的确认。 但服务器接收到该字符后， 它并不发送确认，而是继续等待接收序列中的其他字符。 这就会经常触发服务器的经受时延的确认算法， 表示剩下的字符没有在200ms内发送。 对交互用户而言，这将产生明显的时延。
关闭nagle算法
窗口大小通告
- Nagle 算法中， 报文段5通告窗口大小是4095字节，这意味着TCP的缓冲区中仍然有一个字节等待应用程序（Rlogin）读取。同样，来自客户的下一个报文段声明其窗口大小为4094个字节。 这说明仍然有2个字节等待读取。
- 服务器通常通告窗口大小为8912个字节，这是因为服务器在读取并回显接收到的数据之前，其TCP没有数据发送。
- 然而， 在ACK到来时， 客户的TCP总是有数据需要发送。 这是因为它再等待ACK的过程中缓存接收到的字符。当客户TCP发送缓存的数据时， Rlogin客户没有机会读取来自服务器的数据，因此客户通告的窗口大小总是小于4096。
