У меня есть TCP-сервер, который прослушивает компьютер («сервер») под управлением Ubuntu 12.04.3 (ядро 3.8.0-31-generic). Он принимает соединения с 2 разных клиентских машин. Машина A работает под управлением Ubuntu 12.04.4 (3.11.0-17-generic), а машина B работает под управлением Ubuntu 11.10 (3.0.0-32-server).
Если на сервере включены временные метки 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), но вместо этого игнорирует свои SYN. Пакеты с 18 по 27 - еще один успех.
Я подозреваю, что это проблема, аналогичная описанной в "Почему сервер не отправляет пакет SYN / ACK в ответ на пакет SYN"и хотя отключение меток времени - это обходной путь, я хотел бы понять, что происходит. Это просто ошибка?
Локальный брандмауэр не запущен. Сервер обрабатывает довольно много TCP-соединений (около 32 КБ одновременно), но имеет много свободной памяти / процессора. Во время теста, показанного в pcap, других TCP-соединений между машиной A и сервером не было. Нет никаких признаков того, что очередь приема серверного приложения внезапно заполняется (кроме того, я полагаю, это должно повлиять на обоих клиентов). Поскольку пакеты выглядят нормально в pcap, принятом на сервере, не похоже, что вмешивающееся сетевое устройство что-то ломает.
Изначально я разместил это на форумах ubuntu, но, оглядываясь назад, может быть более подходящим местом. Надеюсь на получение подсказки.
В моем случае следующая команда устранила проблему с отсутствующими ответами SYN / ACK с сервера Linux:
sysctl -w net.ipv4.tcp_tw_recycle=0
Я думаю, что это более правильно, чем отключать временные метки TCP, поскольку временные метки TCP все-таки полезны (PAWS, масштабирование окна и т. Д.).
Документация по tcp_tw_recycle прямо заявляет, что не рекомендуется включать его, так как многие маршрутизаторы NAT сохраняют метки времени и, следовательно, ЛАПЫ срабатывает, поскольку временные метки с одного и того же 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.