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