本文已参与「新人创作礼」活动，一起开启掘金创作之路。
问题背景
用户反馈关于数据延迟的两个问题，一个是服务器没有足够快的发送数据，一个是客户端的延迟确认所造成的大延迟。主要的疑问及讨论在于服务器或应用的发送行为、客户端确认行为等层面，因为数据包的世界总是错综复杂的，很难说有一个固定的模式，数据该怎么收或发。
问题分析
数据包文件已经用户做过一定删减，因不存在丢包所产生的重传、乱序问题，可重点关注 数据帧时间增量 ，从大到小排序如下
确实很明显的来自于客户端 10.99.27.175 约 0.98s 的传输延迟，以及来自于客户端 10.99.27.175 的 延迟确认 ACK ， 约 218 ms ，包括 200 ms + 18 ms 左右的 RTT 。
再返回正常数据包排序，看看上述延时发生的情况，以及是否存在一定规律。
浏览整个数据包文件，初步分析如下：
- 数据包交互有一定的规律，数据包 1-21 为一次完整的数据请求和响应过程；
- 响应数据包（长度 16432 字节），分成了 12 个 TCP 分段；
- 在收到第一个分段（数据包 3）后，客户端进行了 Delayed ACK（数据包 4 ，未等到第二个分段及时到来）；随后每收到两个 MSS 分段，客户端发送 ACK；
- 在收到最后一个分段（数据包 19），因服务器实际上已经无数据可发送，客户端又陷入了 Delayed ACK（数据包21）；
- 在经过接近 1s 后（981ms）后，客户端才进行下一次请求。
如果把客户端延迟 ACK 以及客户端发出请求的延迟所有加起来，近乎 11.34s ，相当大的延迟。
问题总结
在数据传输过程中，一头一尾有两次单个数据包传输的问题，造成了两次 Delayed ACK，如果调整服务器的发送行为，那么 12 个 TCP 分段也就可以分 6 次传输，这样不会造成延时确认。
另外，也有人提到 TCP 慢启动、Nagle 算法等可能的问题，但从数据包分析的结果来看，个人认为现象并不符合。
