应用程序生成数据缓慢时，tcp传播就会出现问题，当用户输入时，ssh和telnet才生成数据。比如当用户使用Telnet连接到远程服务器时，每一次击键操作就会产生1个字节数据，进而发送出去一个数据包。
只有在发送方的send buffer里面还有space时候，TCP才会向send buffer发送数据。用户每按下键盘，就发送一个packet。
TCP header + IP 报头 + frame header—>发送一个字节导致开销大。如果我们的应用程序一次产生1个字节的数据，而这个1个字节数据又以网络数据包的形式发送到远端服务器，那么就很容易导致网络由于太多的数据包而过载
Nagle算法：1. Sending TCP发送接收到的第一个 data（不论大小）
2. 在buffer里积累data 等待以下
--数据已经积累到buffer的最大尺寸||Receiving TCP 发送 ACK
（需要快速交互而且发送的包较小时关闭该算法）
MSS：是一个参数，它指定一个远程主机发送的单个IP数据报中的最大数量的数据
MTU：是一个参数，指定通信协议或系统可以传递的最大数量的数据。例如，标准(例如以太网)可以修复MTU的大小，或者系统(例如点对点的串行链接)可以在连接时设置MTU
通常设置为TCP可以发送的最大段的大小，而不会造成本地IP的碎片。MSS被设置为直接连接网络的最大传输单元(MTU)，减去TCP和IP header的大小。
MSS = MTU –IP header size –TCP header
（1）如果包长度达到MSS，则允许发送；
（2）如果该包含有FIN，则允许发送；
（3）设置了TCP_NODELAY选项，则允许发送；
（4）未设置TCP_CORK选项时，若所有发出去的小数据包（包长度小于MSS）均被确认，则允许发送；
（5）上述条件都未满足，但发生了超时（一般为200ms），则立即发送。
![]()
nagle算法Nagle算法的改进在于：如果发送端欲多次发送包含少量字符的数据包（一般情况下，后面统一称长度小于MSS的数据包为小包，与此相对，称长度等于MSS的数据包为大包，为了某些对比说明，还有中包，即长度比小包长，但又不足一个MSS的包），则发送端会先将第一个小包发送出去，而将后面到达的少量字符数据都缓存起来而不立即发送，直到收到接收端对前一个数据包报文段的ACK确认、或当前字符属于紧急数据，或者积攒到了一定数量的数据（比如缓存的字符数据已经达到数据包报文段的最大长度）等多种情况才将其组成一个较大的数据包发送出去。
糊涂窗口综合症：在典型情况下，传送一个只拥有1个字节有效数据的数据包，却要发费40个字节长包头（即ip头20字节+tcp头20字节）的额外开销，这种有效载荷（payload）利用率极其低下的情况被统称之为愚蠢窗口症候群（Silly Window Syndrome）。可以看到，这种情况对于轻负载的网络来说，可能还可以接受，但是对于重负载的网络而言，就极有可能承载不了而轻易的发生拥塞瘫痪。
出现在当TCP系统被迫发送非常小的packet时 出现两种情况：
1.Sender 产生数据极慢
2.Receiver 处理数据极慢：从完整的接受buffer中删除单个byte或小number。
Sender 被告知有机会发送少量bytes，并立即发送填充缓冲区。
sender端：如果有数据发送，但是窗口大小小于MSS，如果Nagle算法运行，就发出指令，如果没有任何ACK或者关闭Nagle，就发送数据
Receiver端：通过保存记录，并等待窗口大小足够，以便发送方发送合理数量的数据，避免对很小的窗口进行广告。
参考：http://blog.csdn.net/yuan1125/article/details/51536490
https://baike.baidu.com/item/Nagle算法/5645172?fr=aladdin
