Asymmetric client/server MTU

[dktapps]

Due to various bugs, the Minecraft client must be limited at 1400 MTU in common cases, because of edge cases on some devices and older routers. In these cases, the MTU probe in OpenConnectionRequest/Reply1 yields a higher MTU than is actually realistically available.

However, reducing max MTU is sub-optimal for server bandwidth, because it increases total bandwidth usage by packet headers from 4.0% to 4.3%. This doesn't sound like much, but it can make a difference on large servers.

We can avoid this by capping the client to a fixed MTU of 1400 (the client rarely sends huge packets anyway) and having the server dynamically probe the connection after the initial sequence to find out where the real MTU limit is by figuring out where packets actually get lost, and limiting its output to that instead. This way, only players with dodgy hardware experience reduced MTU, and everyone else will be unaffected.

This idea was suggested by @MCMrARM.

[GameParrot]

I implemented sending OpenConnectionReply2 with padding to test the actual MTU, and resending it with less padding every 2 seconds until ConnectionRequest is received

Also the ipv6 header is 40 bytes and not 20 bytes which can cause fragmentation