AWS请求与响应MTU差异原因及响应分片机制咨询

关于请求/响应MTU差异的假设验证 #

• 请求MTU为1522的原因：公网链路普遍采用1500字节标准MTU，你在EC2上捕获到的1522字节是包含VLAN标签（802.1Q，22字节）的完整帧大小。客户端设备的MTU确实会影响初始请求，但一旦进入公网链路（Akamai、公网ALB段），超过1500字节的包会被分片或调整，最终到达EC2的请求帧会适配公网链路+VLAN的1522大小——所以你的假设不完全准确，客户端MTU是起点，但公网链路的MTU限制才是最终决定EC2接收请求帧大小的关键。
• 响应MTU远超8000的原因：你的假设是正确的。AWS VPC内部默认支持9001字节的巨帧（Jumbo Frames），当Kong与EC2处于同一VPC时，内部网络传输可以直接使用巨帧，无需分片，所以你捕获到的响应包会远大于公网MTU。

响应传递到客户端时的分片逻辑 #

响应最终到客户端时，一定会在公网出口环节被分片或调整：

• 当响应从VPC内部的巨帧包发送到公网ALB时，ALB会自动将超过公网MTU（1500字节）的包分片，或者通过路径MTU发现（PMTUd）机制调整包大小，确保符合公网链路的MTU要求。
• 后续经过Akamai等CDN节点时，也会根据链路情况进一步适配，最终到达客户端的包会适配客户端所在网络的MTU（如果客户端MTU小于1500，还会在最后一公里再次分片）。

内容的提问来源于stack exchange，提问作者jakiewoo1