Как прерывается TCP-соединение, если один из компьютеров умирает? - PullRequest
10 голосов
/ 26 февраля 2012

Если между двумя хостами (A и B) установлено TCP-соединение, и, скажем, хост A отправил 5 октетов на хост B, а затем хост B отказывает (по неизвестной причине).Хост A будет ожидать подтверждений, но, не получив их, отправит октеты и уменьшит размер окна отправителя.Это будет повторяться пару раз, пока размер окна не уменьшится до нуля из-за потери пакета.У меня вопрос, что будет дальше?

Ответы [ 5 ]

5 голосов
/ 26 февраля 2012

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

В случае вашего хостаB исчезает после того, как он отправил свои ACK, хост A не узнает об этом, пока не отправит что-то B, что в конечном итоге также приведет к истечению времени ожидания или к ошибке ICMP.(Как правило, первый вызов записи / отправки не будет завершен неудачей, так как TCP не будет прерывать соединение немедленно, и имейте в виду, что вызовы записи / отправки не ожидают ACK до их завершения).не уменьшать размер окна.

1 голос
/ 26 февраля 2012

в вашем случае будет сгенерирован FIN (для выжившего узла), и соединение в конечном итоге перейдет в состояние ЗАКРЫТО. Если вы сохраняете grep-ging для вывода netstat по ip-адресу назначения, вы будете наблюдать за переходом из состояния ESTABLISHED в TIMED_WAIT и затем, наконец, исчезать.

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

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

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

cforfun

1 голос
/ 26 февраля 2012

Зависит от реализации ОС. Короче говоря, он будет ждать подтверждения и повторной отправки пакетов, пока не истечет время ожидания. Тогда ваша связь будет разорвана. Чтобы увидеть, что именно происходит в Linux, посмотрите здесь , другие ОС следуют аналогичному алгоритму.

1 голос
/ 26 февраля 2012

Пожалуйста, перейдите по этой ссылке

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

Кроме того, если сломанный компьютер снова подключен к сети, будет соблюдаться процедура, описанная в ссылке, которую я только что вставил выше..

0 голосов
/ 03 июля 2014

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

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