又见MTU问题导致页面加载缓慢

问题描述：

管理后台无法正常打开，如图所示，其他的同事一直处于这个状态，但其中一个同事可以正常打开。

加载的进度卡在一个JS的文件上，URL为：

https://prod-a5b3f5w2d3-xxxx.go.akamai-access.com/static/js/chunk-libs.72e86335.js

该JS的大小为994k, 非常大， 每次加载都不完全。

解决问题:

出于对EAA尿性的了解(也无权限去深入去追查)，觉得文件太大，会导致文件下载缓慢，或者造成stalled, 因此第一反应就是去减少文件的大小（增加gzip压缩）。

从请求头，响应头中，看到确实开启了gzip, 但是大小并没有减少，通过命令行curl 带上压缩的请求头去请求，经过验证，请求的文件并没有压缩。

检查openresty的配置文件，果然缺少对application/javascript的支持。

调整如下配置后：（前端、后端的openresty调整配置）

然后再次请求，问题解决。

深入分析：

但是通过这种绕行的方式确实解决了问题，但是问题的根本原因还不清楚，否则后面可能会出现类似或者由此导致的其他的问题。于是继续跟踪下去。

访问ops-web的路径为：

EAA-client -----> akamai EAA cloud ---> EAA agent ---> Endpoint service ----> NLB ---> openresty

路径较长，无法确定问题在哪个环节，经询问，同事告诉在openresty上下载文件，无问题，于是在

openresty服务器上tcpdump抓包。

异常的时候：

1. 接收端提示滑动window已经满

2. 发送端 ack=1004, 说明接收端(浏览器端) 只收到1004字节。

3. 三次握手的时候，MSS两端不一致(一个为8645,一个8961)。

考虑公有云，ICMP的差错报文被禁止（无法捕获协议栈的差错报文），因此PMTU的机制无法运作。

基于以上条件的判断，openresty的前面链路中的MTU 不匹配导致问题【MTU小于 openresty，导致openresty响应报文在分片后的在NLB端无法有效组装TCP分片).

由于openresty的上游是NLB，因此问题出现在 终端节点 -----》 终端节点服务(NLB) 环节，

经过查找AWS相关文档：

根因分析到此结束。

问题展望：

联想到增加发生过的问题（特别是历史遗留下来的）：

1. 曾经开发同学，反馈git clone 代码时而正常，时而异常， 甚至git clone出来的某些文件是不完整的，他们的相同点：git的访问链路 和 当前的 访问链路 一样，是否需要做同样的优化调整？, 类似场景的配置都需要重点排查。

2. 终端节点在大量使用的场景下，网络层的精细化监控需要补齐