TCP交互过程（小包的响应性）

（保留版权，欢迎转载。请保留出处，注明原始链接！谢谢。）

TCP小包传输——在保证响应和避免拥塞之间的权衡。

1。经受时延的ACK：

原理：端点收到数据包，并不立刻回ACK，直到有数据包发送或定时器超时再捎带上ACK。

应用：TCP小包传输的一般方法。【总是独立于Nagle和其他算法存在，LInux实现是200ms。】

2。Nagle算法：

原理：在TCP连接上，仅允许有一个未被确认和未完成的数据包；在端点上，搜集将要发送的多个数据包，直到ACK到达时或拼接的数据包足够大时一起发出。【例外情况：当对端发出多个包时（如1个ACK和1个数据包），端点可针对性的发出两个包。】

应用：在慢速广域网上，避免大量小包引起拥塞，降低网络开销。

禁止：当要传输的多个连续小包有组合意义时，如X Windows的功能键，Nagle算法会造成明显的响应延迟。【具体原因：接收方对收到的单个小包无法解析并生成响应，只好继续等待后续数据包，而发送方却仍等待已发数据包的ACK，结果方相互停等，直至任何经受时延的ACK触发，才破解死锁状态。】（TCP_NODELAY套接口选项）

3。CORK算法：

与Nagle相似，都会拼包；不同之处：Nagle算法见ACK来就发新数据包，而Cork则可持续缓存拼接未来的新数据包。（当然经受时延的ACK仍然起作用。当计时器超时，拼接的数据包或仅ACK都立刻发出。）

4。其他参考：

a. 网络编程中Nagle算法和Delayed ACK的测试

http://www.blogjava.net/killme2008/archive/2011/06/30/353441.html

（描述了除X Window 组合键外的另一种连续小包的组合意义：发送请求头部 -> 发请求主体 -> 接收响应）

b. 动手实现TCP的Nagle算法，提高网络应用程序的性能

http://blog.csdn.net/windcsn/article/details/428166

（深入分析Nagle的实现机制）（也有经受时延的ACK？怎么回事？）

c. 糊涂窗口综合症和Nagle算法

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

（澄清TCP详解卷一的相关细节）（也有经受时延的ACK？怎么回事？）

d. TCP的Nagle算法和Delayed ACK机制导致从Windows Azure Table Service获取小数据记录的高延时

http://www.cnblogs.com/polymorphism/archive/2012/12/10/High_Latency_for_Small_Size_Entities_in_Table_Service.html

（发端的Nagle与收端的Delayed ACK相互作用导致延迟的另外一例）

e. Nagle的算法

http://en.wikipedia.org/wiki/Nagle's_algorithm

（原始协议）

f. Nagle算法

http://blog.csdn.net/igame/article/details/1801860

（泛泛概念）

g. Boost socket performance on Linux

http://www.ibm.com/developerworks/linux/library/l-hisock/index.html

（TCP几种常规调试方法）

h. TCP delayed acknowledgment
http://en.wikipedia.org/wiki/TCP_delayed_acknowledgment

（经受时延的ACK）

i. 再探Linux下的TCP延迟确认机制
http://pananq.com/index.php/tag/delayed-ack/

（结合实例分析详细）