tanenbaum_seti_all.pages (525408), страница 155
Текст из файла (страница 155)
При отправлении каждого ТРьг11-модуля отправитель должен уменьшать па единицу число буферов, а когда это число достигнет нуля, он должен остановиться. Получатель отправляет обратно на попутных ТР13П-модулях отдельно подтверждения и информацию об имеющихся у него свободных буферах. На рис. 6.13 показан пример управления динамическим окном в дейтаграммной подсети с 4-битными порядковыми номерами. Предположим, что запрос на предоставление буферов пересылается в отдельньгх ТР1И г-модулях, а не добирается «автостопом> на попутных модулях, Вначале хост А запрашивает 8 буферов, но ему выделяется только 4.
Затем он посылает три ТРАНШ-модуля, из которых последний теряется. На шаге 6 хост А получает подтверждение получения посланных им ТР1П3-хгодулейг О и 1, разрешает хосту А освободить буферы и послать еще три модуля 1с порядковыми номерами 2, 3 и 4). Хост А знает, что ТР1НЗ- модуль номер 2 он уже посылагг, поэтому он думает, что может послать модули 3 и 4, что он и делает.
На этом шаге он блокируется, так как его счетчик буферов достиг нуля, и ждет предоставления новых буфероп. На шаге 9 наступает таймаут хоста А, так как он до сих пор нс получил подтверждения для ТР1Н3-модуля 2. Этот модуль посылается еще раз. В строке 10 хост В подтверждает получение всех ТРПА-модулей, вклгочая 4-й, но отказывается предоставлять буферы хосту А, Такая ситуация невозможна в протоколах с фиксированным размером окна, описанных в главе 3. Следующий ТРОП-модулгь посланный хостом В, разрешает хосту А передать еще один ТРПП-модуле« Элементы транспортных протокалоа 661 Потенциальные проблемы при такой схеме выделения буферов в дейтаграммных сетях могут возникнуть при потере управляющего ТРР()-модуля.
Взгляните на строку 16. Хост В выделил хосту А дополнительные буферы, но сообщение об этом было потеряно. Поскольку получение управляюгцнх ТР1Н)-модулей не подтверждается и, следовательно, управляющие ТР1Н1-модули не посылаются повторно по тайм-ауту, хост А теперь оказался блокированным всерьез и надолго. Для предотврашения такой тупиковой ситуации каждый хост должен периодически посылать управляющий ТРР()-модуль, содержащий подтверждение и состояние буферов для каждого соединения. Это позволит в конце концов выбраться из тупика.
До сих пор мы по умолчанию предполагали, что единственное ограничение, накладываемое на скорость передачи данных, состоит в количестве свободного буферного пространства у получателя. По мере все продолжающегося снижения цен на микросхемы памяти и винчестеры становится возможным оборудовать хосты таким количеством памяти, что проблема нехватки буферов будет возникать очень редко, если вообще будет возникать. Если размер буферов перестанет ограничивать максимальный поток, возникнет другое узкое место: пропускная способность подсети.
Если максимальная скорость обмена кадрами между соседними маршрутизаторами будет х кадров в секунду и между двумя хостами имеется ), йепересскающихся путей, то, сколько бы ни было буферов у обоих хостов, они не смогут пересылать друг другу больше чем ях ТР1Н1-модулей в секунду. И если отправитель будет передавать с большей скоростью, то подсеть окажется перегружена. Требуется механизм, основанный не столько на емкости буферов получателя, сколько на пропускной способности подсети.
Очевидно, управление потоком должен проводить отправитель, в противном случае у него будет слишком много неподтвержденных ТРР(1-модулей. В 1975 году Бслснес (Ве1зпез) предложил использовать схему управления потоком скользяшего окна, в которой отправитель динамически приводит размер окна в соответствие с пропускной способностью сети. Если сеть может обработать с ТРП(1-модулей в секунду, а время цикла (включая передачу, распространение, ожидание в очередях, обработку получателем и возврат подтверждения) равно б тогда размер окна отправителя должен быть равен сг. При таком размере окна отправитель работает, максимально используя канал.
Любое уменьшение производительности сети приведет к его блокировке. Для периодической настройки размера окна отправитель может отслеживать оба параметра и вычислять требуемое значение. Пропускная способность может быть определена простым подсчетом числа ТР1П)-модулей, получивших подтверждения за определенный период времени, и делением этого числа на тот же период времени. Во время измерения отправитель должен посылать данные с максимальной скоростью, чтобы удостовериться, что ограничиваюшим фактором является пропускная способность сети, а не низкая скорость передачи, Время, необходимое для получения подтверждения, может быть замерено аналогично.
Так как пропускная способность сети зависит от количества трафика в ней, размер окна должен настраиваться довольно часто, чтобы можно было отслеживать 582 Глава 6. Транспортный уровень Мультиплексирование Объединение нескольких разговоров в одном соединении, виртуальном канале и по одной физической линии играет важную роль в нескольких уровнях сетевой архитектуры. Потребность в подобном уплотнении возникает в ряде случаев и на транспортном уровне. Например, если у хоста имеется только один сетевой адрес, он используется всеми соединениями транспортного уровня.
Нужен какой-то способ, с помощью которого можно было бы различать, какому процессу следует передать входящий ТРР0-модуль. Такая ситуация, называемая восходящим мультиплексированием, показана на рис. 6.14, а. На рисунке четыре различных соединения транспортного уровня используют одно сетевое соединение (например, один 1Р- адрес) с удаленным хостом.
транспортные адресе ЛГ Сетевые реса Уровень е б рнс. В.14. Восходящее мультиплексирование (ай нисходящее мультиплексирование (б) Уплотнение может играть важную роль на транспортном уровне и по другой причине. Предположим, например, что подсеть построена на основе виртуальных каналов и на каждом из них данные передаются с максимальной скоростью. Если пользователю требуется большая пропускная способность, нежели может предоставить один виртуальный канал, то можно попробовать решить зту проблему путем открытия нескольких сетевых соединений и распределения трафика между ними, используя виртуальные каналы поочередно, как показано на рис.
6.14, б. Такой метол называется нисходящим мультиплексированием. При Й открытых сетевых соединениях эффективная пропускная способность увеличивается в я раз. В качестве примера можно привести нисходящее мультиплексирование, осуществляемое при работе частных пользователей, имеющих доступ к каналам 1ЯЭХ. Такая линия обеспечивает установку двух отдельных соедине- изменения пропускной способности.
Как будет показано далее, в Интернете ис- пользуется похожая схема. Элементы транспортных протоколов 583 ний по 64 Кбит/с. Использование обоих соединений для доступа в Иптсрнет и разделение графика позволяют достигать эффективной пропускной способности 128 Кбит/с. Восстановление после сбоев Поскольку хосты и маршрутизаторы подвержены сбоям, следует рассмотреть вопрос восстановления после сбоев. Если транспортная сущность целиком помещается в хостах, восстановление после отказов сети и маршрутизаторов не вызывает затруднений.
Если сетевой уровень поставляет дейтаграммные услуги, транспортные сущности постоянно ожидают потери ТРРУ-модулей и знают, как с этим бороться. Если сетевой уровень предоставляет услуги, ориентированные на соединение, тогда потеря виртуального канала обрабатывается при помощи установки нового виртуального канала с последующим запросом у удаленной транспортной сущности ее текущего состояния.
При этом выясняется, какие ТРПП- модули были получены, а какие нет. Потерянные ТРОП-модули передаются повторно. Более серьезную проблему представляет восстановление после сбоя хоста. В частности, для клиентов может быть желательной возможность продолжать работу после отказа и быстрой перезагрузки сервера. Чтобы пояснить, в чем тут сложность, предположим, что один хост — клиент — посылает длинный файл другому хосту — файловому серверу — при помощи простого протокола с ожиданием. Транспортный уровень сервера просто передает приходящие ТР()()-модули один за другим пользователю транспортного уровня, Получив половину файла, сервер сбрасывается и перезагружается, после чего все его таблицы пере- инициализируются, поэтому ои уже не помнит, что с ним было раньше.
Пытаясь восстановить предыдущее состояние, сервер может разослать широковещательный ТРПА-модуль всем хостам, объявляя им, что он только что переэагрузился, и прося своих клиентов сообщить ему о состоянии всех открытых соединений. Каждый клиент может находиться в одном из двух состояний: один неподтвержденный ТРПБ-модуль (состояние 51) или ни одного неподтвержденного ТРАНШ-модуля (состояние 50).
Этой информации клиенту должно быть достаточно, чтобы решить, передавать ему повторно последний ТР1)(1-модуль или нет. На первый взгляд, здесь все очевидно: узнав о перезапуске сервера, клиент должен передать повторно последний неподтвсржденный ТР1П)-модуль. То есть повторная передача требуется, если клиент находится в состоянии 51. Однако при более детальном рассмотрении оказывается, что все не так просто, как мы наивно предположили. Рассмотрим, например, ситуацию, в которой транспортная сущность сервера сначала посылает подтверждение, а уже затем передает пакет прикладному процессу. Запись ТРЕШ-модуля в выходной поток и отправка подтверждения являются двумя различными неделимыми событиями, которые не могут быть выполнены одновременно.
Если сбой произойдет после отправки подтверждения, но до того как выполнена запись, клиент получит подтверждение, а при получении объявления о перезапуске сервера окажется в состоянии ЯО. 584 Глава 6. Транспортный уровень Таким образом, клиент пе станет передавать ТРР(1-модуль повторно, так как будет считать, что ТРАЯН)-модуль уже получен, что в конечном итоге привсдет к отсутствию ТРОП-модуля. В этом месте вы, должно быть, подумаете; «А что если поменять местами последовательность действий, выполняемых транспортной сущностью сервера, чтобы сначала осуществлялась запись, а потом высылалось подтверждение?» Представим, что запись сделана, цо сбой произошел до отправки подтверждения, В этом случае клиент окажется в состоянии 51 и поэтому передаст ТРП1)-модуль повторно, и мы получим дубликат ТРР()-модуля в выходном потоке.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
