Лекции 2010-го года (1130544), страница 74
Текст из файла (страница 74)
Установление соединения с помощью «троекратного рукопожатия»: (а)Нормальная ситуация; (б) Старый дубль CONNECTION REQUEST возникает «ниоткуда»;(с) Дубли CONNECTION REQUEST и ACKЭта процедура предполагает, что машина 1 шлет запрос на установление соединения подномером x. Машина 2 шлет подтверждение на запрос x, но со своим номером у. Машина 1подтверждает получение подтверждения с номером у. На рисунке 6-11 (b) и (c) показано,что будет, если поступит запоздавший запрос на соединение и запрос и подтверждение нанего.6.2.3.
Разрыв соединенияРазрыв соединения, как уже было сказано, может быть асимметричным илисимметричным. Асимметричный разрыв может привести к потере данных (см. рисунок 612).Рисунок 6-12. Разрыв соединения с потерей данныхСимметричный разрыв каждая сторона проводит самостоятельно, когда она передала весьимеющийся объем данных. Однако определить этот факт не всегда просто. Здесь естьодна проблема, которая называется проблемой двух армий (см. рисунок 6-13).Суть этой проблемы в следующем. Пусть есть две противоборствующие армии, скажем, Аи В. Армия А представлена двумя группировками, между которыми расположена армия В.Суммарно ресурсы А превосходят ресурсы В, и, если обе группировки А ударят по В, то Апобедит.
Дело лишь за тем как договорится, чтобы обе группировки ударилиодновременно. Имеется сложность – гонец от А должен пройти через территорию,контролируемую В. Пусть группировка №1 шлет гонца с донесением, в котором указановремя атаки. Вопрос, выслав гонца, может ли армия №1 выступать? Конечно, нет! Еслигонец не доставил донесение, то атака будет отбита, ресурсы потрачены, и В победит.Выход из создавшегося положения – дождаться гонца от армии №2 с подтверждением.Пусть гонец от армии №2 прибыл.
Можно ли наступать? Опять нельзя! Не получивподтверждения, что гонец доставил подтверждение, армия №2 не может выступить. Этотпроцесс ожидания подтверждений можно продолжать сколь угодно долго.Рисунок 6-13. Проблема двух армийВнимательно изучив проблему разрыва соединения, мы придем к выводу, что ни однаармия не начнет атаки до тех пор, пока не получит подтверждения на подтверждение, итак до бесконечности.
На самом деле, можно доказать, что нет протокола, которыйбезопасно разрешает эту ситуацию. На рисунке 6-14 показаны четыре сценария разрывасоединения: нормальный случай с «тройным рукопожатием», с потерей последнегоподтверждения, с потерей ответа и с потерей ответа и последующих данных. Обычно этупроблему решают, фиксируя число попыток разрыва.Рисунок 6-14. Четыре сценария разрыва соединения: (а) Нормальный случай трехкратногорукопожатия; (b) Потеря последнего ACK; (c) Потеря ответа; (d) Потеря ответа ипоследующих DR6.2.4. Управление потоком и буферизацияТеперь, рассмотрев, как устанавливают соединение, обратимся к тому, как им управляют.Прежде всего, рассмотрим управление потоком. Проблема управления потоком натранспортном уровне в чем-то аналогична проблеме управления потоком на канальномуровне. Различия в том, что у маршрутизатора число каналов невелико, в то время как натранспортном уровне соединений может быть очень много.Канальный протокол сохранял пакеты как на стороне отправителя, так и на сторонеполучателя до тех пор, пока они не будут подтверждены.
Если у нас есть 64 соединения иполе «время жизни» пакета занимает 4 разряда, то нам потребуется суммарная емкостьбуферов на 1024 TPDU-пакетов. Число буферов можно сократить, если есть информация онадежности сетевого уровня или о наличии буфера у получателя. На транспортном уровнеотправитель сохраняет все пакеты на случай, если какой-то из них придется посылатьвторично. Если получатель знает об этом, то он может иметь лишь один пул буферов длявсех соединений, и, если пришел пакет и ему нет буфера в пуле, то он сбрасывается, впротивном случае сохраняется и подтверждается.Если сетевой уровень не надежный, то на транспортном уровне отправитель вынужденсохранять все отправленные пакеты до тех пор, пока они не будут подтверждены.
Принадежном сетевом сервисе, наоборот, отправителю нет нужды сохранять отправленныепакеты, если он уверен, что у получателя всегда есть буфер для сохранения полученногоTPDU. Если такой уверенности нет, то ему придется сохранять пакеты.Однако и в первом и во втором случае возникает проблема размера буфера. Прификсированной длине буфера естественно организовывать пул буферов одного размера.Однако при переменной длине пакетов проблема становится много сложнее. Если размербуфера устанавливать по максимальной длине пакета, то мы столкнемся с проблемойфрагментации, т.е.
неэффективного использования пространства. Если по минимальнойдлине, то один пакет придется пересылать как несколько, с дополнительными накладнымирасходами. Можно установить схему динамического согласования размера буфера приустановлении соединения.Оптимальное соотношение между буферизацией на стороне отправителя или на сторонеполучателя зависит от типа трафика. Для низкоскоростного, нерегулярного трафикабуферизацию лучше делать на обоих концах.
В общем случае вопрос о количествебуферов лучше всего решать динамически. Здесь надо только позаботиться о решениипроблемы потери управляющих пакетов.Другую проблему представляет согласование доступного числа буферов и пропускнаяспособность сетевого уровня. Дело в том, что пропускная способность транспортнойсреды между двумя определенными хостами ограниченна, и если поток между нимипревысит пропускную способность транспортной среды, то возникнет перегрузка. Этупроблему лучше всего решать динамически с помощью управляющих сообщений.Механизм управления потоком должен прежде всего учитывать пропускную способностьподсети, а уже потом - возможности буферизации.
Располагаться этот механизм будет настороне отправителя, чтобы предотвращать накопление большого числанеподтвержденных сообщений.6.2.5. МультиплексированиеПотребность в мультиплексировании нескольких потоков одного уровня на одномсоединении, виртуальном канале, физической линии на других уровнях возникаетпостоянно. Эта проблема возникает и на транспортном уровне.Например, если пользователь за терминалом установил транспортное соединение иотошел попить кофе, то транспортное соединение продолжает поддерживаться, под негорезервируется буферное пространство, пространство в таблице маршрутизации и т.д.
Вцелях удешевления стоимости транспортных соединений можно отобразить несколькотранспортных соединений на одно сетевое. Такое отображение называется нисходящиммультиплексированием. Оно показано схематично на рисунке 6-15 (а).Рисунок 6-15. (а) Восходящее мультиплексирование; (b) НисходящеемультиплексированиеВ некоторых случаях, наоборот, в целях увеличения пропускной способности поотдельным транспортным соединениям можно отобразить транспортное соединение нанесколько сетевых и по каждому сетевому иметь свое скользящее окно. Тогда, быстроисчерпав возможности одного оконного буфера, можно переключиться на другое сетевоесоединение и продолжить передачу по нему.
В этом случае мы получим канал,пропускная способность которого равна сумме пропускных способностей отдельныхканалов на сетевом уровне. Такое мультиплексирование называется восходящим (рисунок6-15 (b)).6.2.6. Восстановление после сбоевВосстановление после сбоев мы будем рассматривать в предположении, чтотранспортный агент целиком располагается на абонентской машине. Восстановлениесетевого уровня достаточно просто. Если сетевой уровень предоставляет дейтаграммныйсервис, то транспортный уровень знает, как исправлять подобные ситуации. При сервисе,ориентированном на соединение, транспортный уровень восстановит потерянноесоединение и постарается в диалоге с транспортным агентом на другой стороне выяснить,что успели передать, а что нет.Проблема становится сложнее, когда надо восстанавливать работоспособность машины,включая и транспортный уровень.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
