Удаление соединений с помощью tcp_tw_recycle

краткое изложение проблемы

У нас есть настройка, в которой много (от 800 до 2400 в секунду (входящих подключений к ящику Linux), и у нас есть NAT-устройство между клиентом и сервером. поэтому в системе осталось столько гнезд TIME_WAIT. Чтобы преодолеть это, мы установили tcp_tw_recycle в 1, но это привело к падению входящих соединений. после просмотра через сеть мы нашли ссылки для того, почему происходит падение кадров с помощью tcp_tw_recycle и устройства NAT.

разрешена попытка

Затем мы попытались установить tcp_tw_reuse на 1, он работал нормально, без каких-либо проблем с одинаковой настройкой и конфигурацией.

Однако в документации указано, что tcp_tw_recycle и tcp_tw_reuse не должны использоваться, когда соединения, проходящие через узлы, поддерживающие TCP, например брандмауэры, устройства NAT или балансировки нагрузки, могут видеть отброшенные кадры. Чем больше подключений, тем больше вероятность того, что вы увидите эту проблему.

Запросы

1) Может ли tcp_tw_reuse использоваться в сценариях такого типа? 2) если нет, какая часть кода Linux предотвращает использование tcp_tw_reuse для такого сценария? 3) вообще в чем разница между tcp_tw_recycle и tcp_tw_reuse?

Ответы

Ответ 1

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

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

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

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

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

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

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