Какова цель TIME WAIT в разрыве соединения TCP?


12

Я обнаружил, что причина, по которой активный ближе входит в TIME WAIT, состоит в том, чтобы убедиться, что окончательный ACK не потерян. Но как он узнает, что окончательный ACK потерян? Будет ли пассивный доводчик повторно отправить FIN, и тогда активный доводчик узнает, что ACK был потерян? Вот изображение TCP FSM.

TCP FSM



1
Этот пост в блоге имеет отличный ответ: vincent.bernat.im/en/blog/…
Воинственный шимпанзе

Ответы:


5

Будет ли пассивный доводчик повторно отправить FIN, и тогда активный доводчик узнает, что ACK был потерян?

Да. Цитирование из иллюстрированного тома TCP / IP 1 , в разделе «Управление TCP-соединениями»:

  1. Чтобы завершить закрытие, последний сегмент содержит ACK для последнего FIN. Обратите внимание, что если FIN потерян, он повторно передается до тех пор, пока не будет получен ACK для него.

Тайм-аут При LAST_ACKвходе пассивный доводчик будет повторно отправляться FINпри истечении времени ожидания, предполагая, что он был потерян. Если он действительно был потерян, то активный доводчик в конечном итоге получит ретранслируемый FINи войдет TIME_WAIT. Если FINне был потерян, но финал ACKбыл потерян, то активный ближе находится TIME_WAITи получает FINснова. Когда это произойдет - поступает FINв TIME_WAIT- ACKретранслируется.

Значение тайм - аута в TIME_WAITэто НЕ используется для целей повторной передачи. Когда истекает тайм-аут TIME_WAIT, предполагается, что финал ACKбыл успешно доставлен, потому что пассивный доводчик не ретранслировал FINпакеты. Таким образом, тайм-аут в TIME_WAITэто просто количество времени, после которого мы можем с уверенностью предположить, что если другой конец ничего не отправил, то это потому, что он получил финал ACKи закрыл соединение.


1

Но как он узнает, что окончательный ACK потерян?

Потому что он не получил его в течение периода ожидания. Я знаю, что это "дух" ответ, но именно поэтому существуют эти состояния и тайм-ауты.

Будет ли пассивный ближе переслать FIN

Нет, если только дополнительные пакеты не поступят для этого потока, и это приведет к отправке "RST" (сброс).

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

TL; DR Это дерево состояний предназначено для обработки всех возможных режимов отказа.


Спасибо, но я все еще не понимаю первую часть. Я имел в виду, как активный доводчик узнает, что ACK не был получен пассивным доводчиком? Когда пассивный доводчик получает ACK, он просто разрывает свою сторону соединения, и если он не получает ACK, он просто остается в LAST ACK, так как же активный доводчик узнает, было ли получено ACK?
Чжао

потому что есть таймеры, прикрепленные к каждому состоянию.
Рикки Бим

Извините, я не понимаю. Как эти таймеры сообщают активному доводчику, что пассивный доводчик не получил окончательный ACK? т.е. как активный ближе узнает, должен ли он повторно отправить окончательный ACK?
Чжао

0

Цель TIME_WAIT - позволить сети отличать пакеты, которые поступают как принадлежащие «старому, существующему» соединению, от нового. Рекомендуется установить таймер TIME_WAIT в два раза больше максимального времени жизни сегмента (MSL), в моей системе MSL составляет 1 минуту, поэтому соединения остаются в состоянии TIME_WAIT в течение 2 минут.

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

TIME_WAIT не ожидает напрямую отправки пакетов ACK; это обусловлено состояниями CLOSE_WAIT и FIN_WAIT. Когда вы переходите в состояние TIME_WAIT, сокет уже закрыт.

Ссылки: http://www.tcpipguide.com/free/t_TCPConnectionTermination-3.htm https://en.wikipedia.org/wiki/Maximum_segment_lifetime http://www.lognormal.com/blog/2012/09/27/ линукс-TCPIP-тюнинг /

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.