что значит порт time wait

Что значит порт time wait

В этом разделе рассказывается о том, что такое состояние TIME-WAIT в протоколе TCP, для чего оно служит и почему не следует пытаться обойти его.

Поскольку состояние TIME-WAIT запрятано глубоко в недрах конечного автомата, управляющего работой TCP, многие программисты только подозреваю о его существовании и смутно представляют себе назначение и важность этого с стояния. Писать приложения TCP/IP можно, ничего не зная о состоянии ТIME-WAIT, но необходимо разобраться в странном, на первый взгляд, поведении приложения (указание 23). Это позволит избежать непредвиденных последствий.

Рассмотрим состояние TIME-WAIT и определим, каково его место в работе TCP-соединения. Затем будет рассказано о назначении этого состояния и его важности, а также, почему и каким образом некоторые программисты пытаются обойти это состояние. В конце дано правильное решение этой задачи.

Что это такое

Состояние TIME-WAIT наступает в ходе разрыва соединения. Помните (указание 7), что для разрыва TCP-соединения нужно обычно обменяться четырьмя сегментами, как показано на рис. 3.8.

Рис. 3.8. Разрыв соединения

В этот момент хост 2 окончательно закрывает соединение и освобождает ресурсы. С точки зрения хоста 2, соединения больше не существует. Однако хост 1 закрывает соединение, а переходит в состояние TIME-WAIT и остается в нем в течение двух максимальных продолжительностей существования сегмента (2MSL maximum segment lifetime).

Прождав время 2MSL, хост 1 также закрывает соединение и освобождает ресурсы.

Относительно состояния TIME-WAIT следует помнить следующее:

Примечание: Под активным закрытием понимается отправка первого FIN. Считается, что вторая сторона при этом выполняет пассивное закрытие. Возможно также одновременное закрытие, когда обе стороны закрывают соединение примерно в одно время, поэтому посланные ими FIN одновременно находятся в сети. В этом случае активное закрытие выполняют обе стороны, так что обе переходят в состояние TIME- WAIT.

Зачем нужно состояние TIME- WAIT

Состояние TIME-WAIT служит двум целям:

Рассмотрим каждую из этих причин. В момент, когда сторона, выполняющая активное закрытие, готова подтвердить посланный другой стороной FIN, все данные, отправленные другой стороной, уже получены. Однако последний АСК может потеряться. Если это произойдет, то сторона, выполняющая пассивное закрытие, обнаружит тайм-аут и пошлет свой FIN повторно (так как не получила АСК на последний порядковый номер).

А теперь посмотрим, что случится, если активная сторона не перейдет в состояние TIME-WAIT, а просто закроет соединение. Когда прибывает повторно переданный FIN, у TCP уже нет информации о соединении, поэтому он посылает в ответ RST (сброс), что для другой стороны служит признаком ошибки, а не нормального закрытия соединения. Но, так как сторона, пославшая последний АСК, все-таки перешла в состояние TIME-WAIT, информация о соединении еще хранится, так что она может корректно ответить на повторно отправленный FIN.

Этим объясняется и то, почему 2МSL-таймер перезапускается, если в состоянии TIME-WAIT приходит новый сегмент. Если последний АСК потерян, и другая сторона повторно послала FIN, то сторона, находящаяся в состоянии TIME-WAIT, еще раз подтвердит его и перезапустит таймер на случай, если и этот АСК будет потерян.

Второе назначение состояния TIME-WAIT более важно. Поскольку IР-дата-граммы могут теряться или задерживаться в глобальной сети, TCP использует механизм подтверждений для своевременной повторной передачи неподтвержден­ных сегментов (указание 1). Если датаграмма просто задержалась в пути, но не потеряна, или потерян подтверждающий ее сегмент АСК, то после прибытия исходных данных могут поступить также и повторно переданные. TCP в этом случае определяет, что порядковые номера поступивших данных находятся вне текущего окна приема, и отбрасывает их.

Состояние TIME-WAIT предотвращает такую ситуацию, гарантируя, что два прежних сокета (два IP-адреса и соответствующие им номера портов) повторно не используются, пока все сегменты, оставшиеся от старого соединения, не будут уничтожены. Таким образом, вы видите, что состояние TIME-WAIT играет важную роль в обеспечении надежности протокола TCP. Без него TCP не мог бы гарантировать доставку данных по порядку и без искажений (указание 9).

Принудительная отмена состояния TIME-WAIT

К сожалению, иногда можно досрочно выйти из состояния TIM Е-WAIT. Это называется принудительной отменой (TIME-WAIT assassination) и бывает случай но или намеренно.

Эта ситуация описана в RFC 1337 [Braden 1992b], где также рассматриваются трудности, сопряженные с принудительной отменой состояния TIME-WAIT. Опасность состоит в возможности «воскрешения» старого соединения (то есть появления соединения с теми же двумя сокетами), что может привести к подтверждению старых данных, десинхронизации соединения с входом в бесконечный цикл и к ошибочному завершению нового соединения.

Это легко предотвратить, изменив протокол TCP так, чтобы в состоянии TIME-WAIT было разрешено игнорировать RST Хотя такое изменение, рекомендованное в RFC 1337, официально не одобрено, тем не менее в некоторых стеках оно реализовано.

Принудительно отменить состояние TIME-WAIT можно и намеренно. С помощью опции сокета SO_LINGER программист требует немедленного закрытия соединения даже в том случае, когда приложение выполняет «активное закрытие. Этот сомнительный прием иногда рекомендуют применять, чтобы вывести «упавший» сервер из состояния TIME-WAIT и запустить его заново. Подробнее об этой проблеме и более правильном способе ее решения будет рассказано в указании 23. Корректно написанное приложение никогда не должно манипулировать состоянием TIME-WAIT, поскольку это неотъемлемая часть механизма обеспечения надежности TCP.

Обычно, когда приложение закрывает соединение, вызов close или closesocket возвращается немедленно, даже если в буфере передачи еще есть данные. Разумеется, TCP будет пытаться доставить эти данные, но приложение не имеет информации, удалось ли это. Чтобы решить эту проблему, можно установить опцию сокета SO_LINGER. Для этого следует заполнить структуру linger и вызывать setsockopt с параметром SO_LINGER.

В большинстве UNIX-систем структура linger определена в заголовочном файле /usr/include/sys/socket.h. В системе Windows она находится в файле winsock2.h. В любом случае она выглядит так:

int l_onoff; /*Включить/выключить опцию.*/

int l_linger; /*Время задержки.*/

Если к моменту завершения ожидания данные еще не доставлены, то close или closesocket возвращает код EWOULDBLOCK, и недоставленные данные могут быть потеряны. Если все данные уже доставлены, то оба вызова возвращают нуль.

Примечание: К сожалению, семантика поля l_linger зависит от реализации. В Windows и некоторых реализациях UNIX это число секунд, на которое следует задержать закрытие сокета. В системах, производных от BSD, это число тактов таймера (хотя в документации сказано, что это число секунд).

Если поле l_linger равно нулю, то соединение разрывается. Это означает, что хосту на другом конце посылается RST, и соединение закрывается немедленно, не переходя в состояние TIME-WAIT. Это преднамеренная принудительная отмена состояния TIME-WAIT, о которой упоминалось выше. Как было сказано, это опасный прием, который в обычном приложении применять не следует.

Резюме

Источник

2.7. Состояние TIME_WAIT

2.7. Состояние TIME_WAIT

Без сомнений, самым сложным для понимания аспектом TCP в отношении сетевого программирования является состояние TIME_WAIT (время ожидания). На рис. 2.4 мы видим, что узел, выполняющий активное закрытие, проходит это состояние. Продолжительность этого состояния равна двум MSL (maximum segment lifetime — максимальное время жизни сегмента), иногда этот период называется 2MSL.

В каждой реализации TCP выбирается какое-то значение MSL. Рекомендуемое значение, приведенное в документе RFC 1122 [10], равно 2 мин, хотя Беркли-реализации традиционно использовали значение 30 с. Это означает, что продолжительность состояния TIME_WAIT — от 1 до 4 мин. MSL — это максимальное количество времени, в течение которого дейтаграмма IP может оставаться в сети. Это время ограничено, поскольку каждая дейтаграмма содержит 8-разрядное поле предельного количества прыжков (hop limit) (поле TTL IPv4 на рис. А.1 и поле «Предельное количество транзитных узлов» IPv6 на рис. А.2), максимальное значение которого равно 255. Хотя этот предел ограничивает количество транзитных узлов, а не время пребывания пакета в сети, считается, что пакет с максимальным значением этого предела (которое равно 255) не может существовать в сети более MSL секунд.

Пакеты в объединенных сетях обычно теряются в результате различных аномалий. Маршрутизатор отключается, или нарушается связь между двумя маршрутизаторами, и им требуются секунды или минуты для стабилизации и нахождения альтернативного пути. В течение этого периода времени могут возникать петли маршрутизации (маршрутизатор А отправляет пакеты маршрутизатору В, а маршрутизатор В отправляет их обратно маршрутизатору А), и пакеты теряются в этих петлях. В этот момент, если потерянный пакет — это сегмент TCP, истекает установленное время ожидания отправляющего узла, и он снова передает пакет, и этот заново переданный пакет доходит до конечного места назначения по некоему альтернативному пути. Но если спустя некоторое время (не превосходящее количества секунд MSL после начала передачи потерянного пакета) петля маршрутизации исправляется, пакет, потерянный в петле, отправляется к конечному месту назначения. Начальный пакет называется потерянной копией или дубликатом (lost duplicate), а также блуждающей копией или дубликатом (wandering duplicate). TCP должен обрабатывать эти дублированные пакеты.

Есть две причины существования состояния TIME_WAIT:

? необходимо обеспечить надежность разрыва двустороннего соединения TCP;

? необходимо подождать, когда истечет время жизни в сети старых дублированных сегментов.

Первую причину можно объяснить, рассматривая рис. 2.5 в предположении, что последний сегмент ACK потерян. Сервер еще раз отправит свой последний сегмент FIN, поэтому клиент должен сохранять информацию о своем состоянии, чтобы отправить завершающее подтверждение ACK повторно. Если бы клиент не сохранял информацию о состоянии, он ответил бы серверу сегментом RST (еще один вид сегмента TCP), что сервер интерпретировал бы как ошибку. Если ответственность за корректное завершение двустороннего соединения в обоих направлениях ложится на TCP, он должен правильно обрабатывать потерю любого из четырех сегментов. Этот пример объясняет, почему в состоянии TIME_WAIT остается узел, выполняющий активное закрытие: именно этому узлу может потребоваться повторно передать подтверждение.

Чтобы понять вторую причину, по которой необходимо состояние TIME_WAIT, давайте считать, что у нас имеется соединение между IP-адресом 12.106.32.254, порт 1500 и IP-адресом 206.168.112.219, порт 21. Это соединение закрывается, и спустя некоторое время мы устанавливаем другое соединение между теми же IP-адресами и портами: 12.106.32.254, порт 1500 и 206.168.112.219, порт 21. Последнее соединение называется новым воплощением (incarnation) предыдущего соединения, поскольку IP-адреса и порты те же. TCP должен предотвратить появление старых дубликатов, относящихся к данному соединению, в новом воплощении этого соединения. Чтобы гарантировать это, TCP запрещает установление нового воплощения соединения, которое в данный момент находится в состоянии TIME_WAIT. Поскольку продолжительность состояния TIME_WAIT равна двум MSL, это позволяет удостовериться, что истечет и время жизни пакетов, посланных в одном направлении, и время жизни пакетов, посланных в ответ. Используя это правило, мы гарантируем, что в момент успешного установления соединения TCP время жизни в сети всех старых дубликатов от предыдущих воплощений этого соединения уже истекло.

Из этого правила существует исключение. Реализации, происходящие от Беркли, инициируют новое воплощение соединения, которое в настоящий момент находится в состоянии TIME WAIT, если приходящий сегмент SYN имеет порядковый номер «больше» конечного номера из предыдущего воплощения. На с. 958-959 [128] об этом рассказано более подробно. Для этого требуется, чтобы сервер выполнил активное закрытие, поскольку состояние TIME_WAIT должно существовать на узле, получающем следующий сегмент SYN. Эта возможность используется командой rsh. В документе RFC 1185 [54] рассказывается о некоторых ловушках, которые могут вас подстерегать при этом.

Данный текст является ознакомительным фрагментом.

Продолжение на ЛитРес

Читайте также

Состояние процесса

Состояние процесса Поле state дескриптора процесса описывает текущее состояние процесса (рис. 3.3). Каждый процесс в системе гарантированно находится в одном из пяти различных состояний. Рис. 3.3. Диаграмма состояний процессаЭти состояния представляются значением одного из

6.2. Состояние

6.2. Состояние Понятие состояния (state) является фундаментальным не только в метамоде-ли языка UML, но и в прикладном системном анализе. Ранее в главе 1 кратко были рассмотрены особенности представления динамических характеристик сложных систем, традиционно используемых для

Начальное состояние

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

Конечное состояние

Конечное состояние Конечное (финальное) состояние представляет собой частный случай состояния, которое также не содержит никаких внутренних действий (псевдосостояния). В этом состоянии будет находиться объект по умолчанию после завершения работы автомата в конечный

6.5. Историческое состояние

6.5. Историческое состояние Как было отмечено выше, формализм обычного автомата не позволяет учитывать предысторию в процессе моделирования поведения объектов. Однако функционирование целого ряда систем основано на возможности выхода из отдельных состояний с

7.1. Состояние действия

7.1. Состояние действия Состояние действия (action state) является специальным случаем состояния с некоторым входным действием и по крайней мере одним выходящим из состояния переходом. Этот переход неявно предполагает, что входное действие уже завершилось. Состояние действия

Физическое и эмоциональное состояние

Физическое и эмоциональное состояние Казалось бы, очевидная вещь, хорошее физическое и эмоциональное состояние позволяет работать на порядок лучше, меньше уставать, быть более сконцентрированным. Это вроде бы все понимают, и, в то же время, только единицы уделяют этим

Состояние и версия записи

Состояние и версия записи Каждый объект DataRow имеет свойство RowState, которое обозначает текущее состояние или статус записи. Кроме того, каждая запись хранит информацию о четырех разных версиях своего значения. По мере редактирования записи изменяется ее состояние и версия

Статическое состояние

Предыдущее состояние дел

Состояние готовности

Состояние готовности Наконец, нужно гарантировать, что при снятии указателя мыши с пункта меню пользователем в первой текстовой панели не останется «старая» подсказка, а будет отображено некоторое «типовое» сообщение (например: «Ожидание действий пользователя»). В текущем

8.4. Состояние планировщика событий

4.4.1. Состояние гонки

4.4.1. Состояние гонки Предположим, что в программу поступает группа запросов, которые обрабатываются несколькими одновременными потоками. Очередь запросов представлена связанным списком объектов типа struct job.Когда каждый поток завершает свою операцию, он обращается к

Состояние

Состояние Триггер может быть активным (active) или неактивным (inactive). Запускаются только активные триггеры. См. замечания к ALTER TRIGGER по поводу подробностей деактивации

Источник

Проблемы с очередью TIME_WAIT

Те кто разрабатывает активно работающие с сетью сервисы может наступить на особенности работы протокола TCP: переходу многих (или всех свободных) портов в состояние TIME_WAIT. В интернете много поверхностной информации и много не совсем корректной. Рассмотрим что это за ситуации, и определим возможные пути выхода из них.

Протокол TCP: закрытие соединения

Ниже типичная схема жизненного цикла TCP-соединения:

Не будем рассматривать её целиком, а сосредоточимся на наиболее важной для нас части — закрытии соединения.

Сторона, инициировавшая закрытие соединения называется «активной», вторая — «пассивной». Причем не важно кто из них был инициатором установки соединения.

Со стороны «пассивной» стороны всё просто. Получив пакет FIN, система должна ответить на него соответствующим ACK-пакетом, но имеет право продолжить отправку данных. С момента получения FIN пакета соединение у пассивной стороны находится в состоянии CLOSE_WAIT. По готовности, отправляется ответный FIN-пакет, после чего сторона дожидается ACK-пакета на него. По получении ACK на ответный FIN — соединение для пассивной стороны закрыто.

С точки зрения «активной» стороны всё несколько сложнее. После отправки FIN-пакета активная сторона переходит в состояние FIN_WAIT_1. Далее возможны три ситуации:

Как видно из диаграммы и описания активная сторона отправляет последний пакет в сессии (ACK на пассивный FIN). Поскольку она не может узнать получен ли этот пакет, для неё предусмотрен статус TIME_WAIT. В данном состоянии соединение должно находиться время 2 * MSL (максимальное время жизни пакета): время доставки пакета пассивной стороне + время доставки возможного ответного пакета назад. На практике, в настоящее время, таймер TIME_WAIT устанавливается в 1 — 2 минуты. По истечению этого таймера соединение считается закрытым.

Проблема TIME_WAIT для исходящих соединений

Соединение в операционной системы идентифицируется четырьмя параметрами: локальный IP, локальный порт, удалённый IP, удаленный порт. Допустим, у нас есть клиент, который активно подключается/отключается к удаленной службе. Поскольку оба IP и удаленный порт остаются неизменными, то на каждое новое соединение выделяется новый локальный порт. Если клиент был активной стороной завершения TCP-сессии, то это соединение будет заблокировано какое-то время в состоянии TIME_WAIT. Если соединения в устанавливаются быстрее чем порты выходят из карантина, то при очередной попытке соединения клиент получит ошибку EADDRNOTAVAIL (errno=99).

Что можно предпринять:

TIME_WAIT на серверах

Главная опасность которою несет разрастание очереди TIME_WAIT на сервере — это исчерпание ресурсов.

Тем не менее могут быть неприятные инциденты и при работе с NAT-клиентами (когда за одним IP находятся большое количество клиентов сервера). В случае малого значения времени карантина порта на Firewall велика вероятность что к серверу придёт запрос соединения с того же порта, соединение с которым ещё не закрыто (находится в TIME_WAIT). В этом случае возможны два три сценария:

Что можно предпринять на сервере.

Параметры ядра net.ipv4.tcp_tw_reuse и net.ipv4.tcp_tw_recycle

В ядре Linux есть два параметра, позволяющие нарушать требования TCP-протокола, высвобождая соединения из TIME_WAIT раньше положенного срока. Обе эти опции базируются на расширении TCP-timestamps (маркировки пакетов относительными временными метками).

Источник

Русские Блоги

Анализ статуса TCP TIME_WAIT и решение проблем

1. ПТС четыре раза махнул

TCP требует рукопожатия при установлении соединения, и аналогично ему также требуется рукопожатие при закрытии соединения.

Поскольку TCP-соединение является двунаправленным, при закрытии соединения необходимо закрыть оба направления. Сторона, отправляющая пакет FIN, сначала выполняет активное завершение работы, а сторона, отправляющая пакет FIN, позже выполняет пассивное завершение работы. Сторона, которая активно закрывается, перейдет в состояние TIME_WAIT и останется в этом состоянии в течение 2MSL.

Для MSL это означает максимальное время жизни сегмента сообщения. Если сегмент сообщения был активен в сети в течение времени MSL и не был получен, он будет отброшен. Что касается размера MSL, то в протоколе RFC 793 рекомендация составляет 2 минуты, но в Linux это обычно полминуты.

Для состояния TIME_WAIT есть следующая картина:

Мы ориентируемся на несколько концепций:

Условия генерации TIME_WAIT: Активная закрывающая сторона перейдет в состояние TIME_WAIT после четырехкратной отправки последнего ACK с продолжительностью 2MSL (MSL в Linux составляет 30 секунд и не настраивается).

TIME_WAIT продолжает роль двух MSL: Во-первых, надежно и безопасно закройте TCP-соединение. Например, если сеть перегружена, если последний ACK активной закрывающей стороны не получен пассивной закрывающей стороной, то пассивная закрывающая сторона будет повторно передавать FIN с течением времени. В это время незакрытый TIME_WAIT будет иметь дело с этими хвостовыми проблемами. Влияние на новые подключения и другие услуги. Во-вторых, для предотвращения установления нового TCP-соединения из-за отсутствия непрерывного времени TIME_WAIT задержанный пакет повторной передачи FIN будет мешать новому соединению.

Ресурсы, занятые TIME_WAIT: Небольшой объем памяти (около 4К) и файловый дескриптор fd.

Вред от закрытия TIME_WAIT: Во-первых, когда состояние сети плохое, если у активной стороны нет ожидания TIME_WAIT, после закрытия предыдущего соединения активная сторона и пассивная сторона устанавливают новое TCP-соединение, а затем пассивная сторона повторно передает или прибывает задержанный пакет FIN Затем это напрямую повлияет на новое TCP-соединение; во-вторых, когда состояние сети плохое и в то же время нет ожидающего TIME_WAIT, нового соединения после закрытия соединения нет, тогда, когда пассивная сторона повторно передает или получен задержанный пакет FIN, он будет отправлен пассивной стороне. Отправка пакета RST может повлиять на другие сервисные соединения на пассивной стороне.

TCP: time wait bucket table overflow Причины и последствия: Причина в том, что количество TIME_WAIT превышает порог количества TW в системе Linux. Вред состоит в том, что после превышения порога система удалит избыточный сокет TIME_WAIT и отобразит предупреждающее сообщение. Если это сеть NAT и имеется большое количество доступов, различные соединения будут нестабильными и отключаться.

2. Оптимизация и настройка соответствующих параметров.

1. tcp_tw_recycle

Как следует из названияВосстановить соединение TIME_WAIT, Можно сказать, что этот параметр ядра стал панацеей для обработки TIME_WAIT. Если вы ищете решение TIME_WAIT в Интернете, вы порекомендуете установить его во всех случаях, но есть ловушка, которую нелегко обнаружить: когда несколько клиентов проходят Когда режим NAT подключен к сети и взаимодействует с сервером, сервер видит тот же IP-адрес, что означает, что эти клиенты фактически эквивалентны одному для сервера. Поскольку временные метки этих клиентов могут быть разными, сервер С конечной точки зрения, отметка времени может быть неупорядоченной, что напрямую приводит к тому, что пакет с маленькой отметкой времени отбрасывается. Ссылка: tcp_tw_recycle и tcp_timestamps вызывают сбой подключения.

Примечания:Рекомендуется не включать эту опцию. В настоящее время часто используется Internet NAT, что может привести к невозможности проведения трехстороннего рукопожатия.。

После открытия TIME_WAIT восстанавливается в пределах 3,5 * RTO (время RTO рассчитывается на основе времени RTT), а временная метка в запросе подключения к сокету того же исходного IP-хоста в течение 60 секунд должна быть увеличена. Для сервера тот же исходный IP-адрес может быть За NAT находится много машин. Приращение отметки времени на этих машинах не может быть гарантировано. Сервер отклоняет неинкрементные запросы на соединение, что напрямую приводит к сбою трехстороннего рукопожатия.

2. tcp_tw_reuse

Как следует из названияПовторно использовать соединение TIME_WAIT, При создании нового соединения, если возможно, рассмотрите возможность повторного использования соответствующего соединения TIME_WAIT. обычно думаю tcp_tw_reuse соотношение tcp_tw_recycle Это безопаснее, потому что, во-первых, время создания TIME_WAIT должно превышать одну секунду, прежде чем его можно будет повторно использовать; во-вторых, оно будет повторно использоваться только при увеличении метки времени соединения. В официальном документе сказано: если это безопасно с точки зрения протокола, его можно использовать. Это просто дипломатическая риторика! На мой взгляд, если сеть относительно стабильна, например, она подключена к интранету, то вы можете попробовать ее использовать.

Но что требует внимания, так это то, где его использовать. Поскольку мы хотим повторно использовать соединение, его, конечно же, следует использовать на инициаторе соединения, а не на подключенной стороне. Например: клиент инициирует HTTP-запрос к серверу, и сервер активно закрывает соединение после ответа, поэтому TIME_WAIT остается на сервере. Используйте в этом случае tcp_tw_reuse Недопустимый, потому что сервер является подключенной стороной, поэтому повторное использование подключения отсутствует. Давайте немного расширим его. Например, если сервером является PHP, он запрашивает другой сервер MySQL, а затем активно отключается, поэтому TIME_WAIT приходится на сторону PHP. Используйте в таких случаях tcp_tw_reuse Эффективен, поскольку PHP в настоящее время является клиентом по отношению к MySQL, он является инициатором соединения, поэтому соединение можно использовать повторно.

Описание:Если вы используете tcp_tw_reuse, активируйте tcp_timestamps, иначе он будет недействительным.。

3. tcp_max_tw_buckets

Как следует из названияКонтролировать общее количество TIME_WAIT, В официальном документе веб-сайта говорится, что эта опция предназначена только для предотвращения некоторых простых DoS-атак и обычно не снижает ее искусственно. Если он будет уменьшен, система удалит избыточный TIME_WAIT, и журнал покажет: TCP: time wait bucket table overflow 。

Я должен напомнить всем, что все должно быть поменяно местами. Я видел, как кто-то установил «tcp_max_tw_buckets» на 0, то есть полностью отказался от TIME_WAIT. Это немного рискованно. Чтобы использовать пословицу Go, лучше переходить границу медленно.

Когда это появляется TCP: time wait bucket table overflow Когда, попробуйте увеличить следующие параметры:

Три, резюме

Иногда, если мы посмотрим на проблему с другой стороны, мы часто можем получить эффект двух или двух. Вышеупомянутый пример: клиент инициирует HTTP-запрос к серверу, и сервер активно закрывает соединение после ответа, поэтому TIME_WAIT остается на сервере. Ключевым моментом здесь является то, что именно сервер активно закрывает соединение!При закрытии TCP-соединения первая сторона обречена избежать участи TIME_WAIT., Перефразируя лирику: оставь мою печаль себе, твоя красота пусть заберет. Если клиент управляемый, то включите KeepAlive на сервере и постарайтесь не позволять серверу активно закрывать соединение, и позвольте клиенту активно закрывать соединение, так что проблема будет решена.

Четыре, дополнение

Введение в RST：

В протоколе TCP RST означает сброс и используется для закрытия ненормальных соединений.При отправке пакета RST для закрытия соединения вам не нужно ждать, пока все пакеты данных в буфере будут отправлены, а пакеты данных в буфере будут напрямую отброшены и будет отправлен пакет RST. После получения пакета RST принимающей стороне не нужно отправлять пакет ACK для подтверждения.。

Несколько ситуаций, когда появляется RST:

Порт не открыт: Порт, не открытый клиентом, подключающимся к серверной программе. Когда клиент отправляет SYN-запрос на порт сервера, но порт не открыт на сервере, он отправляет RST клиенту. Однако не все операционные системы будут отправлять RST клиенту, и win7 просто проигнорирует сообщение SYN.

Получать данные о закрытом сокете: Если сокет был закрыт, но все еще получает данные, то также будет сгенерирован RST.

Когда в приемном буфере есть данные, закройте соединение: Когда запрашивающая сторона запрашивает данные и запрашивает закрытие соединения без обработки всех данных в буфере, запрашивающая сторона не отправляет пакет FIN, как ожидалось, и вводит 4-стороннюю логику закрытия, но может напрямую отправить пакет RST для принудительного Связь закрыта.

Источник