Различные рабочие станции, находящиеся за брандмауэром преобразования сетевых адресов (NAT) на стороне клиента, отправляют на наш сервер информацию о временных метках TCP-пакета. Пакеты со многих рабочих станций приходят с нестандартными отметками времени из-за устройства NAT. Когда они прибывают на наш сервер - в некоторых случаях на один и тот же порт - сервер не может отличить эти пакеты от других, приходящих на тот же порт и с того же IP-адреса клиента (устройства NAT).
Сервер интерпретирует пакеты с нестандартными временными метками как принадлежащие уже завершенному соединению, после чего пакет игнорируется - но в этом случае этого не должно быть. Это законные пакеты с рабочих станций за устройством NAT. Отбрасывание пакетов со старыми значениями меток времени является конструктивной функцией TCP, называемой PAWS (http://www.ietf.org/rfc/rfc1323.txt, Protect Against Wrapped Sequences) - сервер просто предполагает, что пакет старый, и он уже обработал соединение.
Чтобы обойти эту проблему, мы отключили настройки отметок времени на наших серверах. НО - что лучше всего подходит для этой ситуации? Следует ли на всех серверах отключить поддержку временных меток? Или все устройства NAT должны удалить или переписать значения отметок времени? Или?
Исходный порт является дополнительной функцией идентификации для TCP-соединения, и никаким двум соединениям за устройством NAT не должен быть назначен один и тот же исходный порт - клиенты никогда не будут мешать соединениям друг друга, если им не будет предоставлен один и тот же исходный порт из-за плохого устройства NAT. .
PAWS не должен отбрасывать необходимые пакеты, а только дубликаты от повторной отправки - доставка вне очереди не обновляет минимальное значение отметки времени. Значение времени копируется из последнего сегмента последовательности; пакет с более высоким порядковым номером (т. е. тот, который необходим) всегда должен иметь более высокую отметку времени, чем пакет с более низким порядковым номером.
Если он в правильной последовательности, но имеет более низкую временную метку, то это неправильно ведет себя TCP-клиент - и если по какой-то странности PAWS выбрасывает хорошие, идущие по порядку пакеты, то клиент должен повторно отправлять с новой временной меткой, восстанавливаясь после любого проблемы, вызванные сбросом.
Какое поведение вы наблюдаете, что привело вас к этой проблеме?
В моем случае следующая команда устранила проблему с отсутствующими ответами 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.