что значит порт 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 по поводу подробностей деактивации
Русские Блоги
Анализ статуса 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 для принудительного Связь закрыта.