Элементы транспортных протоколов. Управление потоком и буферизация. Мультиплексирование. Восстановление после сбоев.

На рис. 6.13 показан пример управления динамическим окном в дейтаграмм-

ной подсети с 4-битными порядковыми номерами. Предположим, что запрос на

предоставление буферов пересылается в отдельных TPDU-модулях, а не добира-

ется «автостопом» на попутных модулях. Вначале хост А запрашивает 8 буфе-

ров, но ему выделяется только 4. Затем он посылает три TPDU-модуля, из кото-

рых последний теряется. На шаге 6 хост А получает подтверждение получения

посланных им TPDU-модулей О и 1, разрешает хосту А освободить буферы и по-

слать еще три модуля (с порядковыми номерами 2, 3 и 4). Хост А знает, что TPDU-

модуль номер 2 он уже посылал, поэтому он думает, что может послать модули 3

и 4, что он и делает. На этом шаге он блокируется, так как его счетчик буферов

достиг нуля, и ждет предоставления новых буферов. На шаге 9 наступает тайм-

аут хоста А, так как он до сих пор не получил подтверждения для TPDU-моду-

ля 2. Этот модуль посылается еще раз. В строке 10 хост В подтверждает получе-

ние всех TPDU-модулей, включая 4-й, но отказывается предоставлять буферы

хосту А. Такая ситуация невозможна в протоколах с фиксированным размером

окна, описанных в главе 3. Следующий TPDU-модуль, посланный хостом В, раз-

решает хосту А передать еще один TPDU-модуль.

 

Потенциальные проблемы при такой схеме выделения буферов в дейтаграмм-

ных сетях могут возникнуть при потере управляющего TPDU-модуля. Взгляни-

те на строку 16. Хост В выделил хосту А дополнительные буферы, но сообщение

об этом было потеряно. Поскольку получение управляющих TPDU-модулей не

подтверждается и, следовательно, управляющие TPDU-модули не посылаются

повторно по тайм-ауту, хост А теперь оказался блокированным всерьез и надол-

го. Для предотвращения такой тупиковой ситуации каждый хост должен перио-

дически посылать управляющий TPDU-модуль, содержащий подтверждение и

состояние буферов для каждого соединения. Это позволит в конце концов вы-

браться из тупика.

До сих пор мы по умолчанию предполагали, что единственное ограничение,

накладываемое на скорость передачи данных, состоит в количестве свободного

буферного пространства у получателя. По мере все продолжающегося снижения

цен на микросхемы памяти и винчестеры становится возможным оборудовать

хосты таким количеством памяти, что проблема нехватки буферов будет возни-

кать очень редко, если вообще будет возникать.

Если размер буферов перестанет ограничивать максимальный поток, возник-

нет другое узкое место: пропускная способность подсети. Если максимальная ско-

рость обмена кадрами между соседними маршрутизаторами будет х кадров в се-

кунду и между двумя хостами имеется k непересекающихся путей, то, сколько

бы ни было буферов у обоих хостов, они не смогут пересылать друг другу больше

чем kx TPDU-модулей в секунду. И если отправитель будет передавать с боль-

шей скоростью, то подсеть окажется перегружена.

Требуется механизм, основанный не столько на емкости буферов получателя,

сколько на пропускной способности подсети. Очевидно, управление потоком дол-

жен проводить отправитель, в противном случае у него будет слишком много не-

подтвержденных TPDU-модулей. В 1975 году Белснес (Belsnes) предложил ис-

пользовать схему управления потоком скользящего окна, в которой отправитель

динамически приводит размер окна в соответствие с пропускной способностью

сети. Если сеть может обработать с TPDU-модулей в секунду, а время цикла

(включая передачу, распространение, ожидание в очередях, обработку получате-

лем и возврат подтверждения) равно г, тогда размер окна отправителя должен

быть равен сг. При таком размере окна отправитель работает, максимально ис-

пользуя канал. Любое уменьшение производительности сети приведет к его бло-

кировке.

Для периодической настройки размера окна отправитель может отслеживать

оба параметра и вычислять требуемое значение. Пропускная способность может

быть определена простым подсчетом числа TPDU-модулей, получивших подтвер-

ждения за определенный период времени, и делением этого числа на тот же пе-

риод времени. Во время измерения отправитель должен посылать данные с мак-

симальной скоростью, чтобы удостовериться, что ограничивающим фактором

является пропускная способность сети, а не низкая скорость передачи. Время,

необходимое для получения подтверждения, может быть замерено аналогично.

Так как пропускная способность сети зависит от количества трафика в ней, раз-

мер окна должен настраиваться довольно часто, чтобы можно было отслеживать5 82 Глава 6. Транспортный уровень

изменения пропускной способности. Как будет показано далее, в Интернете ис-

пользуется похожая схема.

 

 

Мультиплексирование

Объединение нескольких разговоров в одном соединении, виртуальном канале

и по одной физической линии играет важную роль в нескольких уровнях сетевой

архитектуры. Потребность в подобном уплотнении возникает в ряде случаев и на

транспортном уровне. Например, если у хоста имеется только один сетевой адрес,

он используется всеми соединениями транспортного уровня. Нужен какой-то спо-

соб, с помощью которого можно было бы различать, какому процессу следует пере-

дать входящий TPDU-модуль. Такая ситуация, называемая восходящим мультип-

лексированием, показана на рис. 6.14, а. На рисунке четыре различных соединения

транспортного уровня используют одно сетевое соединение (например, один IP-

адрес) с удаленным хостом.

Уплотнение может играть важную роль на транспортном уровне и по другой

причине. Предположим, например, что подсеть построена на основе виртуаль-

ных каналов и на каждом из них данные передаются с максимальной скоростью.

Если пользователю требуется большая пропускная способность, нежели может

предоставить один виртуальный канал, то можно попробовать решить эту про-

блему путем открытия нескольких сетевых соединений и распределения трафи-

ка между ними, используя виртуальные каналы поочередно, как показано на

рис. 6.14, б. Такой метод называется нисходящим мультиплексированием. При к

открытых сетевых соединениях эффективная пропускная способность увеличи-

вается в k раз. В качестве примера можно привести нисходящее мультиплекси-

рование, осуществляемое при работе частных пользователей, имеющих доступ

к каналам ISDN. Такая линия обеспечивает установку двух отдельных соедине-ний по 64 Кбит/с. Использование обоих соединений для доступа в Интернет

и разделение трафика позволяют достигать эффективной пропускной способно-

сти 128 Кбит/с.

 

Восстановление после сбоев

Поскольку хосты и маршрутизаторы подвержены сбоям, следует рассмотреть во-

прос восстановления после сбоев. Если транспортная сущность целиком помеща-

ется в хостах, восстановление после отказов сети и маршрутизаторов не вызывает

затруднений. Если сетевой уровень поставляет дейтаграммные услуги, транс-

портные сущности постоянно ожидают потери TPDU-модулей и знают, как с

этим бороться. Если сетевой уровень предоставляет услуги, ориентированные на

соединение, тогда потеря виртуального канала обрабатывается при помощи уста-

новки нового виртуального канала с последующим запросом у удаленной транс-

портной сущности ее текущего состояния. При этом выясняется, какие TPDU-

модули были получены, а какие нет. Потерянные TPDU-модули передаются по-

вторно.

Более серьезную проблему представляет восстановление после сбоя хоста.

В частности, для клиентов может быть желательной возможность продолжать ра-

боту после отказа и быстрой перезагрузки сервера. Чтобы пояснить, в чем тут

сложность, предположим, что один хост — клиент — посылает длинный файл

другому хосту — файловому серверу — при помощи простого протокола с ожи-

данием. Транспортный уровень сервера просто передает приходящие TPDU-мо-

дули один за другим пользователю транспортного уровня. Получив половину

файла, сервер сбрасывается и перезагружается, после чего все его таблицы пере-

инициализируются, поэтому он уже не помнит, что с ним было раньше.

Пытаясь восстановить предыдущее состояние, сервер может разослать широ-

ковещательный TPDU-модуль всем хостам, объявляя им, что он только что пе-

резагрузился, и прося своих клиентов сообщить ему о состоянии всех открытых

соединений. Каждый клиент может находиться в одном из двух состояний: один

неподтвержденный TPDU-модуль (состояние S1) или ни одного неподтверж-

денного TPDU-модуля (состояние SO). Этой информации клиенту должно быть

достаточно, чтобы решить, передавать ему повторно последний TPDU-модуль

или нет.

На первый взгляд, здесь все очевидно: узнав о перезапуске сервера, клиент

должен передать повторно последний неподтвержденный TPDU-модуль. То есть

повторная передача требуется, если клиент находится в состоянии S1. Однако

при более детальном рассмотрении оказывается, что все не так просто, как мы

наивно предположили. Рассмотрим, например, ситуацию, в которой транспорт-

ная сущность сервера сначала посылает подтверждение, а уже затем передает па-

кет прикладному процессу. Запись TPDU-модуля в выходной поток и отправка

подтверждения являются двумя различными неделимыми событиями, которые

не могут быть выполнены одновременно. Если сбой произойдет после отправки

подтверждения, но до того как выполнена запись, клиент получит подтвержде-

ние, а при получении объявления о перезапуске сервера окажется в состоянии SO.

Таким образом, клиент не станет передавать TPDU-модуль повторно, так как бу-

дет считать, что TPDU-модуль уже получен, что в конечном итоге приведет к от-

сутствию TPDU-модуля.

В этом месте вы, должно быть, подумаете: «А что если поменять местами по-

следовательность действий, выполняемых транспортной сущностью сервера,

чтобы сначала осуществлялась запись, а потом высылалось подтверждение?»

Представим, что запись сделана, но сбой произошел до отправки подтверждения.

В этом случае клиент окажется в состоянии S1 и поэтому передаст TPDU-мо-

дуль повторно, и мы получим дубликат TPDU-модуля в выходном потоке.

Таким образом, независимо от того, как запрограммированы клиент и сервер,

всегда могут быть ситуации, в которых протокол не сможет правильно восстано-

виться. Сервер можно запрограммировать двумя способами: так, чтобы он снача-

ла передавал подтверждение, или так, чтобы сначала записывал TPDU-модуль.

Клиент может быть запрограммирован одним из четырех способов: всегда пере-

давать повторно последний TPDU-модуль, никогда не передавать повторно по-

следний TPDU-модуль, передавать повторно TPDU-модуль только в состоянии

SO и передавать повторно TPDU-модуль только в состоянии S1. Таким образом,

получаем восемь комбинаций, но, как будет показано, для каждой комбинации

имеется набор событий, заставляющий протокол ошибиться.

На сервере могут происходить три события: отправка подтверждения (Л), за-

пись TPDU-модуля в выходной процесс (W) и сбой (С). Они могут произойти в

виде шести возможных последовательностей: AC(W), A WC, C(AW), C(WA), WAC

и WC(A), где скобки означают, что после события С событие А или В может и не

произойти (то есть уж сломался — так сломался). На рис. 6.15 показаны все во-

семь комбинаций стратегий сервера и клиента, каждая со своими последователь-

ностями событий. Обратите внимание на то, что для каждой комбинации суще-

ствует последовательность событий, приводящая к ошибке протокола. Например,

если клиент всегда передает повторно неподтвержденный TPDU-модуль, собы-

тие A WC приведет к появлению неопознанного дубликата, хотя при двух других

последовательностях событий протокол будет работать правильно.

Усложнение протокола не помогает. Даже если клиент и сервер обменяются

несколькими TPDU-модулями, прежде чем сервер попытается записать полу-

ченный пакет, так что клиент будет точно знать, что происходит на сервере, у не-

го нет возможности определить, когда произошел сбой на сервере: до или после

записи. Отсюда следует неизбежный вывод: невозможно сделать отказ и восста-

новление хоста прозрачными для более высоких уровней.

В более общем виде это может быть сформулировано следующим образом:

восстановление от сбоя уровня N может быть осуществлено только уровнем N+ 1

и только при условии, что на более высоком уровне сохраняется достаточное ко-

личество информации о состоянии процесса. Как упоминалось ранее, транспорт-

ный уровень может обеспечить восстановление от сбоя на сетевом уровне, если

каждая сторона соединения отслеживает свое текущее состояние.

Эта проблема подводит нас к вопросу о значении так называемого сквозного

подтверждения. В принципе, транспортный протокол является сквозным, а не

цепным, как более низкие уровни. Теперь рассмотрим случай обращения пользо-

Простой транспортный протокол 5 85

вателя к удаленной базе данных. Предположим, что удаленная транспортная

сущность запрограммирована сначала передавать TPDU-модуль вышестоящему

уровню, а затем отправлять подтверждение. Даже в этом случае получение под-

тверждения машиной пользователя не означает, что удаленный хост успел обно-

вить базу данных. Настоящее сквозное подтверждение, получение которого

означает, что работа была сделана, и, соответственно, отсутствие которого озна-

чает обратное, вероятно, невозможно. Более подробно этот вопрос обсуждается в

(Saltzer и др., 1984)

⇐ Предыдущая16171819202122232425Следующая ⇒

Поделиться: