Как ограничить максимальный размер сегмента tcp mss

Размер tcp-заголовка - 20 байт по RFC793, размер ip-заголовка - 20 байт по RFC791. Максимальный размер сегмента (MSS) в tcp равен MTU за вычетом заголовков:

MSS = MTU - 20 - 20

Бывают включения, когда на каком-то участке MTU меньше, чем 1500, например, за счет использования разных туннелей: gre, ipip, pptp, pppoe, l2tp, ipsec. За счет заголовков протоколов происходит уменьшение MTU для ip-пакетов пользователей. В случае использования SOHO маршрутизаторов при организации туннелей на маршрутизаторе выставляется параметр tcp mss, который вносит изменения в tcp-заголовок первого tcp-пакета (syn), отправляемого клиентом в сторону сервера для установки соединения. Это правильно, так как не всегда оборудование оператора поддерживает такую функцию.

установка tcp-сессии: syn, syn-ack, ack

В свое время Яндекс на своих серверах или маршрутизаторах выставил tcp mss равным 1400. Поэтому некоторые проблемы с tcp mss для интернет пользователей выглядят как доступные ресурсы Яндекса и недоступные прочие ресурсы. Такая ситуация возможна, когда вместо SOHO маршрутизатора используется мелкая Cisco, к примеру. В случае подключения по pppoe в настройках интерфейса Dialer необходимо задать tcp mss командой:

 ip tcp adjust-mss <значение>

Другим примером проблемы с MTU и tcp-mss может быть невозможность скачивания приложений из google play на телефоне.

Проверка MTU

Заголовок icmp занимает 8 байт, поэтому если MTU канала стандартное и равно 1500 байт, то за вычетом еще заголовка ip надо выставить размер пакета 1472.

windows>ping 999.99.9.1 -l 1472 -f -n 2

Обмен пакетами с 999.99.9.1 по с 1472 байтами данных:
Ответ от 999.99.9.1: число байт=1472 время=3мс TTL=254
Ответ от 999.99.9.1: число байт=1472 время=3мс TTL=254

Статистика Ping для 999.99.9.1:
    Пакетов: отправлено = 2, получено = 2, потеряно = 0
    (0% потерь)
Приблизительное время приема-передачи в мс:
    Минимальное = 3мсек, Максимальное = 3 мсек, Среднее = 3 мсек

windows>ping 999.99.9.1 -l 1473 -f -n 2

Обмен пакетами с 999.99.9.1 по с 1473 байтами данных:
Требуется фрагментация пакета, но установлен запрещающий флаг.
Требуется фрагментация пакета, но установлен запрещающий флаг.

Статистика Ping для 999.99.9.1:
    Пакетов: отправлено = 2, получено = 0, потеряно = 2
    (100% потерь)

linux$ ping -s 1472 -M do -c 2 999.99.9.1 
PING 999.99.9.1 (999.99.9.1) 1472(1500) bytes of data.
1480 bytes from 999.99.9.1: icmp_seq=1 ttl=253 time=2.12 ms
1480 bytes from 999.99.9.1: icmp_seq=2 ttl=253 time=1.93 ms

--- 999.99.9.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 1.935/2.027/2.120/0.102 ms
linux$ ping -s 1473 -M do -c 2 999.99.9.1 
PING 999.99.9.1 (999.99.9.1) 1473(1501) bytes of data.
ping: local error: Message too long, mtu=1500
ping: local error: Message too long, mtu=1500

--- 999.99.9.1 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1000ms

freebsd$ ping -D -s 1472 -c 2 999.99.9.1
PING 999.99.9.1 (999.99.9.1): 1472 data bytes
1480 bytes from 999.99.9.1: icmp_seq=0 ttl=253 time=1.163 ms
1480 bytes from 999.99.9.1: icmp_seq=1 ttl=253 time=0.696 ms

--- 999.99.9.1 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.696/0.929/1.163/0.234 ms

freebsd$ ping -D -s 1473 -c 2 999.99.9.1
PING 999.99.9.1 (999.99.9.1): 1473 data bytes
ping: sendto: Message too long
ping: sendto: Message too long
^C
--- 999.99.9.1 ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss

Если пакеты размером 1472 не проходят, то это может говорить об использовании туннелей на пути до удаленного хоста, либо о некорректных настройках MTU на коммутаторах, где настроено QinQ, если проходит на 4 байта меньше.