wireshark-记一次tcp优化传输从50s+降到1s内

现象描述

外网用户点开某个页面发现1m以上的要js文件加载需要50s+。通过F12如下图

原因分析

因为公网用户，可以通过ping大概看看延迟情况，发现时间是很不稳定的，大概可以猜测是因为公网不稳定，导致系统使用体验差

同时去查看内网响应情况，简化的请求链路为：公网pc–F5–前端–后端，
在F5上，发现纯内网，请求到达前端，前端对该接口响应也需要耗时7s。说明该接口内部存在慢的问题，但是这是开发问题，只能让开发去查，前端到后端是否有多个查询接口，数据库是否存在慢SQL问题。
但当务之急我们先解决传输50s的问题

解决方法

公网传输，大量时间消耗在ack上面，这里想起曾经用过的Nagle’s algorithm。该算法详细描述不做阐述，可自行百度，在F5上可直接把响应选项勾上即可，注意调整对应的buffer值。
做完优化后，效果直接起飞，延迟直接降到1s内：

当然遗留的开发问题，还是存在。

该解决方案存在冲突机制，不是适用所有场景，比如：

Nagle指出Nagle算法与Delay ACK机制有共存的情况下会出现死循环，比如举一个场景：PC1和PC2进行通信，PC1发数据给PC2，PC1使用Nagle算法，PC2有delay ACK机制

1. PC1发送一个数据包给PC2，PC2会先不回应，delay ACK

2. PC1再次调用send函数发送小于MSS的数据，这些数据会被保存到Buffer中，等待ACK，才能再次被发送

从上面的描述看，显然已经死锁了，PC1在等待ACK，PC2在delay ACK，那么解锁的代价就是Delay ACK的Timer到期，至少40ms[40ms~500ms不等]，也就是2种算法在通信的时候，会产生不必要的延时！