Нет ответа на некоторые пакеты SYN, когда включены временные метки

У меня есть TCP-сервер, прослушивающий машину ("сервер") под управлением Ubuntu 12.04.3 (ядро 3.8.0-31-generic). Он получает соединения от 2 разных клиентских машин. На машине A установлена ​​Ubuntu 12.04.4 (универсальная версия 3.11.0-17), а на машине B установлена ​​Ubuntu 11.10 (сервер 3.0.0-32).

Если на сервере включены временные метки TCP (sysctl net.ipv4.tcp_timestamps=1), то иногда SYN-пакеты с компьютера A "игнорируются". Используя tcpdump на сервере (в не смешанном режиме), я вижу, что SYN приходят нормально и с правильными контрольными суммами - просто нет ответа - нет SYN/ACK и нет RST. Машина A повторно передает SYN несколько раз, прежде чем сдаться. Клиентское программное обеспечение, работающее на компьютере A (в данном случае, wget), немедленно повторяет попытку с новым подключением и успешно, получая мгновенный SYN/ACK.

На машине B нет проблем с тем же сервером, и трафик выглядит нормально - он использует те же параметры TCP, что и машина A (из того, что я вижу из файлов захвата). Отключение меток времени TCP на сервере заставляет все работать как надо.

Тем не менее, временные метки в игнорируемых пакетах SYN кажутся мне действительными, поэтому я не уверен, почему они вызывают проблемы или вообще являются их основной причиной.

Я поместил анонимный pcap здесь https://www.dropbox.com/s/onimdkbyx9lim70/server-machineA.pcap. Он был сделан на сервере (10.76.0.74), показывая, что машина A (10.4.0.76) успешно выполняет HTTP GET (пакеты с 1 по 10), а затем через 1 секунду пытается снова получить тот же URL-адрес (пакеты с 11 по 17), но вместо этого его SYNs игнорируются. Пакеты с 18 по 27 - это еще один успех.

Я подозреваю, что это проблема, аналогичная той, которая описана в разделе " Почему сервер не отправляет пакет SYN/ACK в ответ на пакет SYN ", и, хотя отключение меток времени - это обходной путь, я хотел бы понять, что происходит. Это просто ошибка?

Не работает локальный брандмауэр. Сервер обрабатывает довольно много TCP-соединений (около 32 Кбайт одновременно), но имеет много свободной памяти / ЦП. Во время теста, показанного в pcap, не было никаких других соединений TCP между машиной A и сервером. Нет никаких признаков того, что очередь приема серверного приложения внезапно заполняется (кроме того, это должно повлиять на обоих клиентов, я бы предположил). Поскольку пакеты выглядят нормально в pcap, взятом на сервере, не похоже, что вмешивающееся сетевое устройство ломает вещи.

Я первоначально разместил это на форумах Ubuntu, но в ретроспективе это может быть более подходящее место. Надеясь на заем ключа.

1 ответ

В моем случае следующая команда устранила проблему с отсутствующими ответами SYN/ACK с сервера Linux:

sysctl -w net.ipv4.tcp_tw_recycle=0

Я думаю, что это более правильно, чем отключение меток времени TCP, так как метки времени TCP полезны (PAWS, масштабирование окна и т. Д.).

Документация на tcp_tw_recycle в явном виде заявляет, что не рекомендуется его включать, так как многие маршрутизаторы NAT сохраняют временные метки и, следовательно, запускается PAWS, поскольку временные метки с одного и того же IP не согласованы.

   tcp_tw_recycle (Boolean; default: disabled; since Linux 2.4)
          Enable fast recycling of TIME_WAIT sockets.  Enabling this
          option is not recommended for devices communicating with the
          general Internet or using NAT (Network Address Translation).
          Since some NAT gateways pass through IP timestamp values, one
          IP can appear to have non-increasing timestamps.  See RFC 1323
          (PAWS), RFC 6191.
Другие вопросы по тегам