总结：TCP／IP 详解（卷1: 协议）－－第十五章 TCP 数据流与窗口管理

第十五章  TCP 数据流与窗口管理

        交互式数据传输的报文段通常小于 SMSS。接收方收到这些分组时可能会采取延时确认的方法，希望能将这些 ACK 与需要发送给对方的数据一起捎带传输。这种方法可以减少传输报文段的数目，特别是在交互式流量传输中，服务器需要对客户端的每个按键都返回响应。然而，延时确认也会引入额外的延时。

        对于 RTT 相对较大的连接，如 WAN ，通常使用 Nagle算法来减少较小报文段数目。该算法限制发送端在任意时刻发送单个小数据包。这样会减少较小数据包在网络连接中的数目，从而减小传输资源开销，但同时也可能引人上层应用无法接受的延时。另外，延时 ACK 和 Nagle 算法的互相作用可能导致短暂的死锁。基于上述原因，有的应用可能禁用 Nagle 算法，而大多数交互式应用都使用该功能。

        TCP 通过在其发送每个 ACK 中包含一个窗口通告来实现流量控制。该窗口告诉对方自己还有多少缓存空间。当没有使用 TCP 窗口缩放选项时，最大通告窗口为 65 535 字节。否则最大窗口值可以更大。

        通告窗口值可能为 0，表明接收端缓存已满。这时发送端停止发送，并以一定间隔不断地发送窗口探测，发送间隔类似于超时重传，直到收到 ACK 表明窗口变大，或收到接收端主动发送的窗口通告表明有可用缓存空间。这种以一定间隔连续发送的行为可能被用于资源耗尽攻击。

        随着 TCP 的不断发展，出现了一种奇怪的现象。当通告窗口较小时，发送端会立即发送数据填满该窗口，这样在连接中就会出现大量高耗费的小数据包。这种现象被称为 “糊涂窗口综合征”。针对这一问题，在 TCP发送端和接收端都有相应的策略。对发送端来说，若通告窗口较小则避免发送小数据包；接收端则尽量避免通告小窗口。

        接收端窗口大小受限于其缓存大小。一般来说，如果上层应用没有设置其接收缓存大小，就会为其分配一个相对较小的空间，这样即使在高带宽的传输路径上，传输延时仍旧很大，导致网络吞吐性能变差。在较新的操作系统中不会出现上述问题，采用自动调优的方法可以高效地自动分配缓存大小。

        希望我的总结可以帮助大家，感谢阅读我的博客！