Почему tcp connect term требует 4-way-handshake?

Ответ 1

• В трехстороннем рукопожатии (настройка соединения): сервер должен подтвердить (ACK) клиент SYN, и сервер также должен отправить свой собственный SYN, содержащий начальный порядковый номер для данных, которые сервер будет отправлять по соединению.
  Поэтому сервер отправляет SYN и ACK клиента SYN в одном сегменте.
• В соединении Termination: для завершения соединения требуется четыре сегмента, так как FIN и ACK требуются в каждом направлении.
  (2) означает, что принятый FIN (первый сегмент) подтвержден (ACK) TCP
  (3) означает, что через некоторое время приложение, получившее конец файла, закроет его сокет. Это заставляет TCP отправлять FIN.
  И тогда последний сегмент будет означать, что TCP в системе, которая получает этот окончательный FIN, подтверждает (ACK) FIN.

Ответ 2

После долгих поисков, я понял, что четырехстороннее рукопожатие - это две пары двухсторонних рукопожатий.

Если завершение является РЕАЛЬНЫМ четырехсторонним действием, 2 и 3 действительно могут быть установлены в 1 для одного и того же пакета.

Но это двухэтапная работа: первая фаза (то есть первое двустороннее рукопожатие):

Client ------FIN-----> Server

Client <-----ACK------ Server

В этот момент клиент находился в состоянии FIN_WAIT_2 в ожидании FIN от Сервера. В качестве двунаправленного и полнодуплексного протокола в настоящее время одно направление нарушено, клиент должен дождаться завершения другого "полудуплексного режима".

В то время как FIN с Сервера был отправлен Клиенту, Клиент ответил ACK для разрыва соединения.

Заключительное примечание: 2 и 3 нельзя объединить в один пакет, поскольку они принадлежат разным состояниям.

Рекомендации:

1. http://www.tcpipguide.com/free/t_TCPConnectionTermination-2.htm
2. http://www.tcpipguide.com/free/t_TCPConnectionEstablishmentProcessTheThreeWayHandsh-3.htm
3. http://www.tcpipguide.com/free/t_TCPOperationalOverviewandtheTCPFiniteStateMachineF-2.htm

Ответ 3

Из Википедии - "Также возможно разорвать соединение путем трехстороннего рукопожатия, когда хост A отправляет FIN, а хост B отвечает FIN & ACK (просто объединяет 2 шага в один), а хост A отвечает ACK. [14]"

Источник:

Википедия - https://en.wikipedia.org/wiki/Transmission_Control_Protocol

[14] - Таненбаум, Эндрю С. (2003-03-17). Компьютерные сети (Четвертое издание). Прентис Холл. ISBN 0-13-066102-3.

Ответ 4

Я думаю, конечно, что 2 и 3 могут слиться технически, но недостаточно гибко, как не атомарно.
Первый FIN1 C на S означает и только означает: я бы закрыл свой путь общения. Первый ACK1 S к C означает ответ на FIN1. Хорошо, я знаю, что ваш канал отключен, но для моего соединения по S (серверу) я еще не уверен. Возможно, мой приемный буфер еще не полностью обработан. Время, которое мне нужно, неясно. Таким образом, 2 и 3 не подходят для слияния. Только сервер будет иметь право решать, когда его способ соединения может быть отключен.

Ответ 5

Если это наблюдается с точки зрения кодирования, более разумно использовать 4 пути, чем 3 пути, хотя оба являются возможными способами использования.

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

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

Таким образом, становится более естественным выяснить, почему на основе выше. Если одноранговый узел находится в автономном состоянии, то клиенту довольно просто вывести состояние однорангового узла, углубившись в содержимое пакета, захваченное в процедуре, поскольку первое подтверждающее сообщение MSG не может быть получено от однорангового узла. Но если эти два сообщения объединены вместе, клиенту становится намного труднее понять, почему одноранговый узел не отвечает, потому что не только автономное состояние может привести к отсутствию пакета, но и различные исключения в процедуре обработки на стороне сервера могут сделать это Не говоря уже о том, что клиент должен ждать большое количество времени до истечения времени ожидания. С дополнительным сообщением 1, две проблемы могут стать более легкими для решения со стороны клиента.

Причина этого выглядит как кодирование, потому что информация, содержащаяся в сообщении, похожа на журнал кода.