糊涂窗口综合症
(1) 什么是糊涂窗口综合症？
当发送端应用进程产生数据很慢、或接收端应用进程处理接收缓冲区数据很慢，或二者兼而有之；就会使应用进程间传送的报文段很小，特别是有效载荷很小。 极端情况下，有效载荷可能只有1个字节；而传输开销有40字节(20字节的IP头+20字节的TCP头) 这种现象就叫糊涂窗口综合症
(2) 糊涂窗口综合症类别
1) 发送端引起的糊涂窗口综合症，象Telnet应用；
2) 接收端引起的糊涂窗口综合症
(3) 解决措施
1) 发送端避免在每个数据段中只传送少量数据。
2) 接收端避免发送小容量的窗口通告
(1) 窗口通告
接收端使用确认数据段的 WINDOW 字段来对发送端告知目前有多少可用的缓冲区。
(2) 问题：糊涂窗口综合症 (silly window syndrome) 每一确认只告知少量的可用空间，且每一数据段携带很小的数据量。
(3) 举例说明
若接收端的接收缓冲区已满，窗口通告 WINDOW = 0。 若接收端进程从缓冲区取走1个字节，则窗口通告 WINDOW = 1。 则发送端可能会传送拥有一个字节的数据段。 传送小数据段会浪费网络带宽、产生不必要的计算开销 接收端有2种的方法：
(1) 延迟通告 (Delayed Advertisement)—Clark法 TCP对到达的数据报立即做出确认。 在送出一个窗口大小为0通告之后，至少需要等待缓冲区的可用空间达到其全部的 50% 或是达到最大尺寸的数据段 (maximum sized segment，MSS)再发通告。
(2) 推迟确认 (Delayed Acknowledgement) 标准建议使用「推迟确认」 TCP 推迟传送确认消息，直到窗口大小达到一定的量才通告窗口的可用量。 优点：降低数据量、 提高吞吐率 缺点：不必要的重传、 造成估算往返时间的的混淆 解决办法 推迟确认的时限 (500ms). 至少每隔一个数据段就应该确认。
(1) 目标 避免传送小数据段
(2) 组块技术 (Clumping) 发送端TCP在数据段发送之前必须延迟，直到聚集了足够的数据。
问题： TCP应该等待多久才能发送数据？ 若太久—-高延迟 若太短—-小数据段、低效率
解决办法：
1) 固定延迟 不能区分传送按键和传送数据这两种情况？ 非最佳化
2) 自适应，Nagle算法
(3) Nagle算法：
自适应延迟
1) 发送端TCP将从应用进程接收到的第一数据块立即发送，不管其大小，哪怕只有一个字节
2) 发送端输出第一块数据后开始收集数据，并等待确认；
3) 在确认未达到时，若收集数据达到窗口的一半或达到一个MSS段，立即发送
3′确认到达，把缓冲区中的数据组成一个TCP段，然后发送
Nagle算法的特点：
1）很小的计算开销
2）不需对不同的连接维持不同的计时器
3）生成数据时不需检查时钟
4）可适应任意的网络延迟、最大数据段尺寸、和应用进程的组合情况
举例（Nagle)
(1) 生成快于网络(大数据量传送情况)
1) 第一个数据被传送后
2) 发送端收集数据、按MSS段或数据达到窗口大小一半时的条件传送。 此时，数据较多 。可能没收到确认，就传送了好几个数据段,收到的确认可能是对几个段的累计确认。
(2) 生成慢于网络(按键应用)
1) 第一个键被传送后
2) 发送端收集后面的按键、确认到达后就传送后续数据。 此时，数据较少 报文段较短、延迟小