So for our microservice, the request and response path is:
request -> akamai -> public ALB -> Kong -> ECS container (runs on EC2) And we have used AWS traffic mirror feature, which copies network received from EC2 to another monitor service. We are printing the length or each packet. What we noticed at monitor service is, for requests, MTU is 1522, but for response MTU could be much higher like more than 8000.
My assumption is since request is from client, the MTU is depending on client's device. But for response, since AWS EC2 is sending back to Kong container, which is within the same VPC, so AWS could use jumbo frame which support much bigger MTU. But is that correct? Then when reponse is finally passed to client, will the response be split somewhere to fit the client's MTU?
Tried to seach some doc on Internet, but no clear answer
This isn't a direct answer to your question, but may help you in finding your solution: With TCP, in the SYN and SYN/ACK packets between client and server, TCP Maximum Segment Size is negotiated. This lets each side now the largest segment size it can send to the opposite end.
Devices in the path can perform "TCP MSS Clamping", modifying this valued own as they see fit (some rules apply).
If you look at this in Wireshark, you might see something confusing from time to time - giant packets that are significantly larger than the negotiated MSS. Wireshark has the ability to reassemble out of order segments and do other magic - but even disabling those features (preferences/protocols/tcp) you'll still see these giant packets for some reason.
That's due to the assumption that you're seeing exactly what's on the wire. There's modern features like GRO/GSO that are optimizations which combine multiple packets into a single one for efficiencies. This happens prior to your vantage point in an on-machine packet capture.
One way to identify this happening: If you look at the IP Identifier (which are typically sequential) you'll find missing numbers. IE: Packet with IP ID #100 from server, Packet #101 from server, then a bigger packet from server #105. It's effectively the combined packets #102-105.