TCP的交互数据流

      由于网络上，如果按照分组数量计算，约有一半的 T C P报文段包含成块数据（如 F T P 、电子邮件和 U s e n e t新闻） ，另一半则包含交互数据（如Te l n e t和R l o g i n） 。

      本次需要介绍交互数据流的处理方式。

      经受延时的确定：通常T C P在接收到数据时并不立即发送A C K；相反，它推迟发送，以便将 A C K与需要沿该方

向发送的数据一起发送（有时称这种现象为数据捎带 A C K） 。绝大多数实现采用的时延为 200 ms，也就是说， T CP将以最大200 ms 的时延等待是否有数据一起发送。

     对于这种情况，200ms由一个定时器确定的。由于将要确认的数据是随机到达的（在时刻 16.4, 474.3, 831.1 等） ，T C P在内核的 200 ms 定时器的下一次溢出时得到通知。这有可能是将来1~200 ms 中的任何一刻。

下面举例子介绍：

通常TCP在接收到数据时并不立即发送ACK，相反，它推迟发送，以便将ACK与需要沿该方向发送的数据一起发送（有时称这种现象为数据捎带ACK），这样做的目的是尽量减少发往网络的报文，以提高传输的效率，节省网络资源。

经受时延的确认工作过程

      下图清晰的展示了Delay ACK的工作过程：

       我们一起来看一个实际环境中的Delay ACK实例： 

     

          在局域网上，这些小分组（被称为微小分组（ t i n y g r a m ） ）通常不会引起麻烦，因为局域网一般不会出现拥塞。但在广域网上，这些小分组则会增加拥塞出现的可能。一种简单和好的方法就是采用RFC 896 [Nagle 1984]中所建议的 N a g l e算法。

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

     

    但是，小消息（鼠标移动）必须无时延地发送，以便为进行某种操作的交互用户提供实时的反馈。

    插口API用户可以使用T C P _ N O D E L A Y选项来关闭Nagle算法。