tanenbaum_seti_all.pages (525408), страница 153
Текст из файла (страница 153)
Получатель подтвержлает получение этого запроса, посылая обратно ТРПА-модуль СОММЕСТ!ОМ АССЕРТЕО (соединение принято). Если оригинальный ТР1И)-модуль СОММЕСТ10М МЕООЕ5Т будет потерян, а его дубликат неожиданно появится на хосте 2, соединение будет установлено некорректно. Для разрешения этой проблемы Томлинсон (1975) предложил чтройное рукопожатие». Этот протокол' установки соединения не требует, чтобы обе стороны начинали передачу с одинаковыми порядковыми номерами, поэтому он может применяться вместе с методами синхронизации, отличными от метода глобальных часов. Нормальная процедура установки соединения показана на рис. 6.8, а. Хост 1 инициирует установку, выбирая порядковый номер х, и посылает ТР1И1-модуль СОмМЕСТ10м МЕООЕ57, содержащий этот начальный порядковый номер, хосту 2. Хост 2 отвечает ТРЕН)-модулем АСк, подтверждая х и объявляя свой начальный порядковый номер у.
Наконец, хост 1 подтверждает выбранный 572 Глава 6. Транспортный уровень хостом 2 начальный порядковый номер в первом посылаемом им информацион- ном ТР1Н)-модуле. Хост 1 Хост 2 Хост Хост 2 е Рис. В.в. Три сценария установки соединения с помощью тройного рукопожатия». Сй означает СОММЕСТЮМ йЕООЕЗТ. Нормальная работа (а); появление старого дубликата СОММЕСТЮМ йЕООЕЗТ (б); дубликат модуля СОММЕСТ(ОМ йЕООЕВТ и дубликат модуля АСК (в) Рассмотрим теперь работу «тройного рукопожатия» в присутствии задержавшегося дубликата управляющего ТРЕН)-модуля. На рис. 6.8, б первтяй ТРЕ)Е)- модуль представляет собой задержащпийся дубликат модуля СОй)(ЕСТ)0)( кЕ00Е5Т от старого соединения. Этот ТР0Е)-модуль прибывает на хост 2 тайком от хоста 1.
Хост 2 реагирует на этот ТР)Н)-модуль отправкой хосту 1 ТР1Н)-модуля АСК, таким образом прося хост 1 подтвердить, что тот действительно пытался установить новое соединение. Когда хост 1 отказывается это сделать, хост 2 пони- Элементы транспортных протоколов 573 мает, что он был обманут задержавшимся дубликатом, и прерывает соединение, Таким образом, задержавшийся дубликат не причиняет вреда. При наихудшем сценарии оба ТР1Н1-модуля — СОМИЕСТ10М МЕООЕ5т и АСХ вЂ” блуждают по подсети. Этот случай показан на рис. 6.8, в. Как и в предыдущем примере, хост 2 получает задержавшийся модуль СОИИЕСТ!ОМ ЙЕООЕ5Т и отвечает на него, В этом месте следует обратить внимание на то, что хост 2 предложил использовать у в качестве начального порядкового номера для трафика от хоста 2 к хосту 1, хорошо зная, что ТРПЕ1-модулей, содержащих порядковый номер у, или их подтверждений в данный момент в сети нет. Когда хост 2 получает второй задержавшийся ТРЕ111-модуль, он понимает, что зто дубликат, так как в этом модуле подтверждается не у, а г, Здесь важно понять, что не сушествует такой комбинации ТРПА-модулей, которая заставила бы протокол ошибиться и случайно установить соединение, когда оно никому не нужно.
Разрыв соединения Разорвать соединение проще, чем установить. Тем не менее, здесь также имеются подводные камни. Как уже было сказано, существует два стиля разрыва соединения: асимметричный и симметричный. Асимметричный разрыв связи соответствует принципу работы телефонной системы: когда одна из сторон вешает трубку, связь прерывается. Прн симметричном разрыве соединение рассматривается в виде двух отдельных однонаправленных связей, и требуется раздельное завершение каждого соединения.
Асимметричный разрыв связи является внезапным и может привести к потере данных. Рассмотрим сценарий, показанный на рис. 6.9. После установки соединения хост 1 посылает ТР1П)-модуль, который успешно добирается до хоста 2. Затем хост 1 посылает другой ТР1Н1-модуль. К несчастью, хост 2 посылает 015СОИМЕСТ1ОМ МЕООЕ5т (запрос разъединения) прежде, чем прибывает второй ТРЕ111- модуль.
В результате соединение разрывается, а данные теряются. Хост Хост 2 Рнс. 6.9. Внезапное разъединенно с потерей данных 674 Глава 6. Транспортный уровень Очевидно, требуется более сложный протокол, позволяющий избежать потери данных. Один из способов состоит в использовании симметричного разъединения, при котором каждое направление разъединяется независимо от другого. В этом случае хост может продолжать получать данные даже после того, как сам послал запрос разъединения.
Симметричное разъединение хорошо подходит для тех случаев, когда у каждой стороны есть фиксированное количество данных для передачи и каждая сторона точно знает, когда эти данные заканчиваются. В других случаях определить, что работа закончена и соединение может быть прервано, не так просто. Можно представить себе протокол, в котором хост 1 говорит: «Я закончил. Вы тоже закончили?» Если хост 2 отвечает: «Я тоже закончил. До свидания», соединение можно безо всякого риска разъединять. К сожалению, этот протокол работает не всегда Существует знаменитая проблема, называемая проблемой двух армий. Прелставьте, что армия белых расположилась в долине, как показано на рис.
6.10. На возвышенностях по обеим сторонам долины расположились две армии синих. Белая армия больше, чем любая из армий синих, но вместе синие превосходят белых. Если любая из армий синих атакует белых в одиночку, она потерпит поражение, но если синие сумеют атаковать белых одновременно, они могут победить, Рис. 6.10. Проблемадвух армий Синие армии хотели бы синхронизировать свое выступление. Однако единственный способ связи заключается в отправке вестового пешком по долине, гле он может быть схвачен, а донесение потеряно (то есть приходится пользоваться ненадежным каналом). Спрашивается: существует ли протокол, позволяющий армиям синих победить? Предположим, командир 1-й армии синих посылает слсдуюшее сообщение: «Я предлагаю атаковать 29 марта, на рассвете.
Сообшите ваше мнение». Теперь предположим, что сообщение успешно доставляется и что командир 2-й армии синих соглашается, а его ответ успешно доставляется обратно в 1-ю армию синих. Состоится ли атака? Вероятно, нет, так как командир 2-й армии не уверен, Элементы транспортных протоколов 676 что его ответ получен. Если нет, то 1-я армия синих не будет атаковать, и было бы глупо с его стороны в одиночку ввязываться в сражение. Теперь улучшим протокол с помощью «тройного рукопожатия». Инициатор оригинального предложения должен полтвердить ответ.
Но и в этом случае останется неясным, было ли доставлено последнее сообщение. Протокол четырехкратного рукопожатия здесь также не поможет. В действительности, можно доказать, что протокола, решающего данную проблему, не существует. Предположим, что такой протокол все же существует. В этом случае последнее сообщение протокола либо является важным, либо нет. Если оно не является важным, удалим его (а также все остальные несущественные сообщения), пока не останется протокол, в котором все сообщения являются существенными. Что произойдет, если последнее сообщение не дойдет до адресатау Мы только что сказали, что сообщение является важным, поэтому, если оно потеряется, атака не состоится.
Поскольку отправитель последнего сообщения никогда не сможет быть уверен в его получении, он не станет рисковать. Другая синяя армия это знает и также воздержится от атаки. Чтобы увидеть, какое отношение проблема двух армий имеет к разрыву соединения, просто замените слово «атаковать» на «разъединить».
Если ни одна из сторон не готова разорвать соединение до тех пор, пока она не уверена, что другая сторона также готова к этому, то разъединение не произойдет никогда. На практике к разрыву соединения обычно готовятся лучше, чем к атаке, поэтому ситуация не совсем безнадежна. На рис.
6.11 показаны четыре сценария разъединения, использующих «тройное рукопожатие». Хотя этот протокол и не безошибочен, обычно он работает успешно. На рис. 6.11, а показан нормальный случай, в котором один из пользователей посылает запрос разъединения 1)В (1)1БСОНХЕСТ1ОХ ВЕЦЕ)ЕБТ), чтобы инициировать разрыв соединения. Когда он прибывает, получатель посылает обратно также запрос разъединения 1)К и включает таймер на случай, если запрос потеряется. Когда запрос прибывает, первый отправитель посылает в ответ на него ТРЕ)Е)-модуль с подтверждением АСК и разрывает соединение.
Наконец, когда прибывает АСК, получатель также разрывает соединение. Разрыв соединения означает, что транспортная сущность удаляет информацию об этом соединении из своей таблицы открытых соединений и сигнализирует о разрыве соединения владельцу соединения (пользователю транспортной службы). Эта процедура отличается от использования пользователем примитива О!5СОМНЕСТ. Если последний ТР1И)-модуль с подтверждением теряется (рис. 6.11, б), ситуацию спасает таймер. Когда время истекает, соединение разрывается в любом случае. Теперь рассмотрим случай потери в~срого запроса разъединения ОК. Пользователь, инициировавший разъединение, не получит ожидаемого ответа, у него истечет время ожидания, и он начнет все сначала. На рис. 6.11, в показано, как это происходит в случае, если все последующие запросы и подтверждения успешно доходят до адресатов, Последний сценарий (рис.
6.11, г) аналогичен предыдущему — с той лишь разницей, что в этом случае предполагается, что все повторные попытки передать 570 Глава б. Транспортный уровень запрос разъединения тттт также терпят неудачу, поскольку все ТР1М.)-модули те- ряются. После Ф повторных попыток отправитель наконец сдается и разрывает соединение. Тем временем у получателя также истекает время, и он тоже разры- вает соединение.
Хост ! Хост 2 Хост 2 Хост 1 Хает 2 Хост ! Хает 2 Ха ри Потерян ои Разорвать соединение иск Послать подтверждение Рвзарвать соединение рис. 6. 11. Четыре сценария разрыва соединения: нормальный случай «тройного рукопожатия» (а); потеряно последнее подтверждение (б]; потерян ответ (н); потерян ответ и последующие запросы (г) Хотя такого протокола обычно бывает вполне достаточно, теоретически он может ошибиться, если потеряются начальный запрос разъединсния 1)й. и все Ф повторных попыток.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
