Хотя NAT не увеличивает размер пакетов (или, точнее, уменьшает максимальный размер полезной нагрузки на пакет), PPoE и другие протоколы туннелирования часто делают это.
Однако в большинстве современных операционных систем реализовано обнаружение Path MTU, описанное в RFC1191, которое оптимально адаптирует исходящие пакеты к пакетам самого маленького MTU любого из каналов между отправляющим хостом и пунктом назначения. Он делает это, устанавливая DF bit (не фрагментировать) в больших исходящих пакетах и ищет ошибку ICMP Fragmentation Needed .
В MacOS и других Unix-подобных операционных системах утилита ping имеет несколько коммутаторов, которые могут устанавливать DF bit , устанавливать размер полезной нагрузки и даже выполнять поиск в диапазоне размеров, эффективно определяя MTU между исходным хостом и местом назначения. Есть 8 байт накладных расходов в запросе ICMP Echo Request ping посылает и 20 байт служебной информации в пакете IP, что делает максимальную полезную нагрузку 1472 для пакета пинг с установленным DF bit на 1500 байт интерфейса MTU.
Вы могли бы установить свой MTU ниже, чтобы оптимизировать, каким-то очень маленьким способом, этот конкретный путь, в обмен на немного меньший оптимальный размер пакета для каждого другого потока пакетов, в котором участвует хост.
Поэтому, если у вас нет проблем с остановкой передачи файлов, лучше всего, чтобы операционная система автоматически обрабатывала MTU.
[nevin-mac-mini:~] nevin% ping -c 1 -D -s 1472 192.168.2.1
PING 192.168.2.1 (192.168.2.1): 1472 data bytes
1480 bytes from 192.168.2.1: icmp_seq=0 ttl=64 time=0.667 ms
--- 192.168.2.1 ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.667/0.667/0.667/0.000 ms
[nevin-mac-mini:~] nevin% ping -c 1 -D -s 1473 192.168.2.1
PING 192.168.2.1 (192.168.2.1): 1473 data bytes
ping: sendto: Message too long
--- 192.168.2.1 ping statistics ---
1 packets transmitted, 0 packets received, 100.0% packet loss
