При наихудшем сценарии оба сегмента — CONNECTION REQUEST и ACK — блуждают по подсети. Этот случай показан на рис. 6.8, в. Как и в предыдущем примере, хост 2 получает задержавшийся сегмент CONNECTION REQUEST и отвечает на него. В этом месте следует обратить внимание на то, что хост 2 предложил использовать у в качестве начального порядкового номера для трафика от хоста 2 к хосту 1, хорошо зная, что сегментов, содержащих порядковый номер у, или их подтверждений в данный момент в сети нет. Когда хост 2 получает второй задержавшийся сегмент, он понимает, что это дубликат, так как в этом модуле подтверждается не у, а z. Здесь важно понять, что не существует такой комбинации сегментов, которая заставила бы протокол ошибиться и случайно установить соединение, когда оно никому не нужно.
Рис. 6.8. Три сценария установки соединения с помощью «тройного рукопожатия» (CR означает CONNECTION REQUEST): а — нормальная работа; б — появление старого дубликата CR; в — дубликат сегмента CR и дубликат сегмента ACK
TCP использует «тройное рукопожатие» для установки соединения. Внутри соединения к 32-битному порядковому номеру добавляется метка времени, чтобы он не мог использоваться повторно в течение максимального времени жизни пакета, даже если скорость соединения составляет несколько гигабит в секунду. Этот механизм был добавлен в TCP для решения проблем, возникших при использовании быстрых линий. Он описан в RFC 1323 и называется PAWS (Protection Against Wrapped Sequence numbers — детектирование повторного использования порядковых номеров). Для работы с несколькими соединениями, имеющими начальные порядковые номера, до появления PAWS протокол TCP применял метод, использующий показания часов (см. выше). Однако этот метод оказался неэффективным с точки зрения безопасности.
Благодаря использованию часов злоумышленники могли легко угадать следующий начальный порядковый номер, и таким образом обманув схему «тройного рукопожатия», инициировать ложное соединение. Поэтому на практике используются псевдослучайные начальные порядковые номера. Но для таких порядковых номеров, со стороны кажущихся абсолютно случайными, все-таки важно, чтобы они не повторялись в течение определенного промежутка времени. Иначе задержавшиеся дубликаты могут вызвать серьезные неполадки в работе сети.
6.2.3. Разрыв соединения
Разорвать соединение проще, чем установить. Тем не менее здесь также имеются подводные камни. Как уже было сказано, существует два стиля разрыва соединения: асимметричный и симметричный. Асимметричный разрыв связи соответствует принципу работы телефонной системы: когда одна из сторон вешает трубку, связь прерывается. При симметричном разрыве соединение рассматривается в виде двух отдельных однонаправленных связей, и требуется раздельное завершение каждого соединения.
Асимметричный разрыв связи является внезапным и может привести к потере данных. Рассмотрим сценарий, показанный на рис. 6.9. После установки соединения хост 1 посылает сегмент, который успешно добирается до хоста 2. Затем хост 1 посылает другой сегмент. К несчастью, хост 2 посылает DISCONNECTION REQUEST (запрос разъединения — DR) прежде, чем прибывает второй сегмент. В результате соединение разрывается, а данные теряются.
Рис. 6.9. Внезапное разъединение с потерей данных
Очевидно, требуется более сложный протокол, позволяющий избежать потери данных. Один из способов состоит в использовании симметричного разъединения, при котором каждое направление разъединяется независимо от другого. В этом случае хост может продолжать получать данные даже после того, как сам послал запрос разъединения.
Симметричное разъединение хорошо подходит для тех случаев, когда у каждой стороны есть фиксированное количество данных для передачи, и каждая сторона точно знает, когда эти данные заканчиваются. В других случаях определить, что работа закончена и соединение может быть прервано, не так просто. Можно представить себе протокол, в котором хост 1 говорит: «Я закончил. Вы тоже закончили?» Если хост 2 отвечает: «Я тоже закончил. До свидания», соединение можно безо всякого риска разъединять.
К сожалению, этот протокол работает не всегда. Существует знаменитая проблема, называемая проблемой двух армий. Представьте, что армия белых расположилась в долине, как показано на рис. 6.10. На возвышенностях по обеим сторонам долины расположились две армии синих. Белая армия больше, чем любая из армий синих, но вместе синие превосходят белых. Если любая из армий синих атакует белых в одиночку, она потерпит поражение, но если синие сумеют атаковать белых одновременно, они могут победить.
Рис. 6.10. Проблема двух армии
Синие армии хотели бы синхронизировать свое выступление. Однако единственный способ связи заключается в отправке вестового пешком по долине, где он может быть схвачен, а донесение потеряно (то есть приходится пользоваться ненадежным каналом). Спрашивается: существует ли протокол, позволяющий армиям синих победить?
Предположим, командир первой армии синих посылает следующее сообщение: «Я предлагаю атаковать 29 марта, на рассвете. Сообщите ваше мнение». Теперь предположим, что сообщение успешно доставляется и что командир 2-й армии синих соглашается, а его ответ успешно доставляется обратно в 1-ю армию синих. Состоится ли атака? Вероятно, нет, так как командир 2-й армии не уверен, что его ответ получен. Если нет, то 1-я армия синих не будет атаковать, и было бы глупо с его стороны в одиночку ввязываться в сражение.
Теперь улучшим протокол с помощью «тройного рукопожатия». Инициатор оригинального предложения должен подтвердить ответ. Но и в этом случае останется неясным, было ли доставлено последнее сообщение. Протокол четырехкратного рукопожатия здесь также не поможет.
В действительности, можно доказать, что протокола, решающего данную проблему, не существует. Предположим, что такой протокол все же существует. В этом случае последнее сообщение протокола либо является важным, либо нет. Если оно не является важным, удалим его (а также все остальные несущественные сообщения), пока не останется протокол, в котором все сообщения являются существенными. Что произойдет, если последнее сообщение не дойдет до адресата? Мы только что сказали, что сообщение является важным, поэтому если оно потеряется, атака не состоится. Поскольку отправитель последнего сообщения никогда не сможет быть уверен в его получении, он не станет рисковать. Другая синяя армия это знает и также воздержится от атаки.
Чтобы увидеть, какое отношение проблема двух армий имеет к разрыву соединения, просто замените слово «атаковать» на «разъединить». Если ни одна сторона не готова разорвать соединение до тех пор, пока она не уверена, что другая сторона также готова к этому, то разъединение не произойдет никогда.
На практике, чтобы справиться с этой ситуацией, нужно отказаться от идеи договоренности и переложить ответственность на потребителей транспортных услуг, так чтобы каждая сторона приняла независимое решение о том, когда будет выполнена операция. Такую проблему решить проще. На рис. 6.11 показаны четыре сценария разъединения, использующих «тройное рукопожатие». Хотя этот протокол и не безошибочен, обычно он работает успешно.
На рис. 6.11, а показан нормальный случай, в котором один из пользователей посылает запрос разъединения DR (DISCONNECTION REQUEST), чтобы инициировать разрыв соединения. Когда запрос прибывает, получатель посылает обратно также запрос разъединения DR и включает таймер на случай, если запрос потеряется. Когда запрос прибывает, первый отправитель посылает в ответ на него сегмент с подтверждением ACK и разрывает соединение. Наконец, когда прибывает ACK, получатель также разрывает соединение. Разрыв соединения означает, что транспортная подсистема удаляет информацию об этом соединении из своей таблицы открытых соединений и сигнализирует о разрыве соединения владельцу соединения (потребителю транспортного сервиса). Эта процедура отличается от применения пользователем операции DISCONNECT.
