По умолчанию, когда и tcp_tw_reuse, и tcp_tw_recycle отключены, ядро ​​будет следить за тем, чтобы сокеты в состоянии TIME_WAIT оставались в этом состоянии достаточно долго -- достаточно долго, чтобы быть уверенным, что пакеты, принадлежащие будущим соединениям, не будут ошибочно приняты за поздние пакеты старая связь.

Когда вы включаете tcp_tw_reuse, сокеты в состоянии TIME_WAIT можно использовать до истечения срока их действия, и ядро ​​попытается убедиться, что нет конфликтов относительно порядковых номеров TCP. Если вы включите tcp_timestamps (он же PAWS, для защиты от упакованных порядковых номеров), это гарантирует, что эти коллизии не могут произойти. Однако вам нужно включить временные метки TCP на обоих концах (по крайней мере, я так понимаю). Подробнее см. в определении tcp_twsk_unique.

Когда вы включаете tcp_tw_recycle, ядро ​​становится гораздо более агрессивным и будет делать предположения относительно временных меток, используемых удаленными хостами. Он будет отслеживать последнюю отметку времени, используемую каждым удаленным хостом, имеющим соединение в состоянии TIME_WAIT, и позволит повторно использовать сокет, если отметка времени правильно увеличилась. Однако, если отметка времени, используемая хостом, изменится (т. е. вернется назад во времени), пакет SYN будет молча удален, и соединение не будет установлено (вы увидите ошибку, похожую на «время ожидания соединения»). Если вы хотите погрузиться в код ядра, вам может подойти определение tcp_timewait_state_process. отправная точка.

Теперь временные метки никогда не должны возвращаться во времени; пока не:

• хост перезагружается (но затем, к тому времени, когда он вернется, срок действия сокета TIME_WAIT, вероятно, истечет, так что это не будет проблемой);
• IP-адрес быстро повторно используется чем-то другим (соединения TIME_WAIT немного останутся, но другие соединения, вероятно, будут сброшены TCP RST, и это освободит место);
• преобразование сетевых адресов (или умный брандмауэр) задействовано в середине соединения.

В последнем случае у вас может быть несколько хостов за одним и тем же IP-адресом и, следовательно, разные последовательности временных меток (или указанные временные метки рандомизируются брандмауэром при каждом соединении). В этом случае некоторые хосты случайно не смогут подключиться, потому что они сопоставлены с портом, для которого сегмент TIME_WAIT сервера имеет более новую отметку времени. Вот почему в документах говорится, что «устройства NAT или балансировщики нагрузки могут запускать пропуск кадров из-за настройки».

Некоторые рекомендуют оставить tcp_tw_recycle в покое, но включить tcp_tw_reuse и понизить tcp_fin_timeout. Я согласен :-)