背景引入
首先不要一听到上面的概念就害怕的不行，心里面犯怵。
慢慢整理思路，这两个策略都是TCP层的故事。
我们知道一个网络包，IP报文的头部有20字节、TCP报文的头部最少有20字节。在通信的时候，如果应用层的数据比较小，就有点得不偿失，传输效率有点低。类似用大车拉小东西，高射炮打蚊子，杀猪焉用牛刀...
概念介绍
承接上文的问题。
我们就是要提高传输的效率。
为了提高传输效率，可以从两个方面来讲。
第一、发送数据的时候，尽量多带一些数据
第二、尽量减少单纯的ACK包（ACK包有上述说的最少40字节的数据是头部，更让人难受的是不携带任何负载数据）
好了，这两个方面引出来Nagle算法与ACK延迟确认两个机制。
Nagle算法是尽量解决第一点，也就是发送数据时尽量多带一些数据。
ACK延迟确认机制尽量解决第二点，也就是尽量减少单纯的ACK包。
Nagle算法
1、如果没有『未确认的包』，立马发送当前包。这是首要原则
2、否则累积缓冲区的数据，直到没有『未确认的包』|| 累积的数据达到『MSS』的大小，立马发送数据
ps：||表示或者
总之重点就是不要一有数据就发送，我们要尽量的积攒一些数据然后发送。
ACK延迟确认
1、收到数据包之后不急着给ack，而是等待
2、如果一直收不到其他的数据包，等待一个『最大等待时间』，然后发送ack包
3、如果在等待的过程中，收到了其他数据包，立马发送ack包。
4、如果在等待的过程中，自己也有数据要发送给对方，那么顺便发送
总之重点就是不要一收到数据就发送确认，我们要尽量减少单纯的确认包。
Nagle算法与ACK延迟确认一起使用的问题
比如发送方采用Nagle算法、接收方使用ACK确认机制。
1、发送方发一个小包，然后等待确认，开始累积数据
2、接收方收到数据，等待，期待收到其他数据包，结果没有等到，一直持续『最大等待时间』，此时发送ack确认包
3、发送方这时终于收到了ack包，将累积起来的数据一股脑发送过去
4、接收方收到数据，等待，......，等不到了，发送确认包
5、发送方收到了确认包
这里面有什么问题吗？问题大了，发送方等待了两个延迟时间啊！
是可忍孰不可忍。
这就是典型的出发点都是好的，最后确实以悲剧收尾的故事示例！
参考资料
林沛满《Wireshark网络分析的艺术》