Thanks to Impacket I now
have a bit of fascinating news: most of my blog readers have an MTU of
1500 bytes. The Maximum Transfer Unit is the size of a TCP packet. You
want this to be as big as possible. 1500 is
generally the limit on the Internet (it's the Ethernet limit), but
smaller sizes may be better depending on your net connection.
Here are the top 10 packet sizes my blog has served with percentages. Left column is SYN and ACK packets, right column is data packets.
1500 byte packets are about 75% of my data traffic. That's good. I'm not positive why a 1400 MTU is second most popular, except that many webpages recommend this setting, particularly for AOL users. It is a conservative setting that's likely to work anywhere. 1492 is for PPPoE users, 576 is common for dialup and X.25, and 1420 and 1460 are probably various IP-in-IP tunnelling setups. The ACK packet distribution surprised me. 40 vs. 60 bytes isn't going to make a big difference, but why is there so much variance? Turns out it's TCP options. 40 bytes is the minimum size of a TCP packet, no options. These are usually ACKs or RSTs. 52 byte packets are ACKs that include timestamps. 48 byte packets are SYN packets setting up a connection; they are requesting a specific MTU and usually selective acknowledgement. Finally, the 60 byte packets are SYNs with some combination of previous options, often with a window scale option as well. What can we conclude? 1500 bytes still works as an MTU on the Internet, but not as much as you'd hope. TCP options really are useful, with many TCP stacks taking advantage of them to tune the connection. I'm surprised to see all the timestamps flying around. They're useful for measuring round trip time, but that's overkill for short lived HTTP connections. This analysis is deeply geeky. I really admire how TCP/IP works. It's one of the most beautiful engineering achievements of the whole Internet. And despite some shortcomings, it's served us well for 22 years. Two unanswered trivia questions. TCP headers have to be a multiple of 4 bytes. Why are they always padded with NOPs rather than using TCP's padding field? And why 52 and 60 byte packets, but no 56? |