http://www.cnblogs.com/zhaoyl/archive/2012/09/20/2695799.html

这个症状指的是： 这个问题可以归结为小包的问题，就是由于发送端和接收端上的处理不一致，导致网络上产生很多的小包，之前也介绍过避免网络上产生过多小包的措施，比如Nagle算法。在滑动窗口机制下，如果发送端和接收端速率很不一致，也会产生这种比较犯傻的状态：发送方发送的数据，只要一个大大的头部，携带数据很少。 对于接收端来讲，如果接收很慢，一次接收1个字节或者几个字节，这个时候接收端 缓冲区很快就会被填满，然后窗口通告为0字节，这个时候发送端停止发送，应用程序收上去1个字节后，发出窗口通告为1字节，发送方收到通告之后，发出1个字节的数据，这样周而复始，传输效率会非常低。 同时如果发送端程序一次发送一个字节，虽然窗口足够大，但是发送仍是一个字节一个字节的传输，效率很低

解决办法： nagle算法 TCP/IP协议中，无论发送多少数据，总是要在数据前面加上协议头，同时，对方接收到数据，也需要发送ACK表示确认。为了尽可能的利用网络带宽，TCP总是希望尽可能的发送足够大的数据。（一个连接会设置MSS参数，因此，TCP/IP希望每次都能够以MSS尺寸的数据块来发送数据）。Nagle算法就是为了尽可能发送大块数据，避免网络中充斥着许多小数据块。 Nagle算法的基本定义是任意时刻，最多只能有一个未被确认的小段。 所谓“小段”，指的是小于MSS尺寸的数据块，所谓“未被确认”，是指一个数据块发送出去后，没有收到对方发送的ACK确认该数据已收到。