Э. Таненбаум - Компьютерные сети. (4-е издание) (DJVU) (1130092), страница 149
Текст из файла (страница 149)
Тем не менее, некоторые приложения, например, клиент-серверные вычислительные системы и потоковое мультимедиа, даже выигрывают от дейтаграммных сервисов, поэтому далее мы еще упомянем их. Второе различие между сетевой и транспортной службами состоит в том, для кого они предназначены. Сетевая служба используется только транспортными объектами. Мало кто пишет свои собственные транспортные объекты, и поэтому пользователи и программы почти не встречаются с голой сетевой службой. Транспортные примитивы, напротив, используются многими программами, а следовательно, и программистами. Поэтому транспортная служба должна быть удобной и простой в употреблении.
Чтобы получить представление о транспортной службе, рассмотрим пять пРимитивов, перечисленных в табл. 6.1. Этот транспортный интерфейс сильно упрощен, но он дает представление о назначении ориентированного на соединение тРанспортного интерфейса. Он позволяет прикладным программам устанавливать, использовать и освобождать соединения, чего вполне достаточно для многих приложений. Транспортная служба 556 Таблица 6.1. Примитивы простой транспортной службы Посланный модуль данных Знвчвнив транспортного протокола Примитив ЫЗТЕМ (Ожиддть) (нет) Блокировать сервер, пока какой-либо процесс не попытается соединиться Активно пытаться установить соединение Послать информацию Блокировать сервер, пока не прибудугданные Прерватьсоединение ЗАПРОС СОЕДИНЕНИЯ СОММЕСТ (СОЕДИНИТЬ) ЗЕМО(ПОСЛАТЬ) РЕСЕ)УЕ (ПОЛУЧИТСЯ О)ЗСОММЕСТ (РАЗЪЕДИНИТЬ) ДАННЫЕ (нет) ЗАПРОС РАЗЪЕДИНЕНИЯ Заголовок кадра Заголовок Заголовок пакета ТРОСЬмодуля Рис.
6.2. Вложенность модулей данных транспортного протокола, пакетов н кадРов Чтобы понять, как могут быть использованы зти примитивы, рассмотрим приложение, состоящее из сервера и нескольких удаленных клиентов. Вначале сервер выполняет примитив С!5ТС)( — обычно для этого вызывается библиотечная процедура, которая обращается к системе. В результате сервер блокируется, пока клиент не обратится к нему. Когда клиент хочет поговорить с сервером, он выполняет примитив СОп))ГСТ. Транспортный объект выполняет этот примитив, блокируя обратившегося к нему клиента и посылая пакет серверу. Поле данных пакета содержит сообщение транспортного уровня, адресованное транспортному объекту сервера.
Следует сказать пару слов о терминологии. За неимением лучшего термина, для сообщений, посылаемых одной транспортной сущностью другой транспортной сущности, нам придется использовать несколько неуклюжее сокращение ТР1Н1 (Тгапзрог( Ргогосо1 Рата ()п(Š— модуль данных транспортного протокола). Модули данных, которыми обмениваются транспортные уровни, помещаются в пакеты (которыми обмениваются сетевые уровни). Эти пакеты, в свою очередь, содержатся в кадрах, которыми обмениваются уровни передачи данных. Получив кадр, уровень передачи данных обрабатывает заголовок кадра и передает содержимое поля полезной нагрузки кадра наверх, сетевой сущности. Сетевая сущность обрабатывает заголовок пакета и передает содержимое поля полезной нагрузки пакета наверх, транспортной сущности. Эта вложенность проиллюстрирована на рис. 6.2.
656 Глава 6, Транспортный уровень Итак, вернемся к нашему примеру общения клиента и сервера. В результате запроса клиента СОИИЕСТ серверу посылается модуль данных транспортного протокола, содержаший СОИИЕСТ!ОИ ЙЕООЕ5Т (запрос соединения). Когда он прибывает, транспортная сущность проверяет, заблокирован ли сервер примитивом Е15ТЕИ (то есть заинтересован ли сервер в обработке запросов). Затем она разблокирует сервер и посылает обратно клиенту модуль данных СОИИЕСТ1ОИ АССЕРТЕО (соединение принято). Получив этот модуль, клиент разблокируется, после чего соединение считается установленным. Теперь клиент и сервер могут обмениваться данными с помощью примитивов 5ЕИО и ИЕСЕ1ЧЕ. В простейшем случае каждая из сторон может использовать блокирующий примитив ВЕСЕ!ЧЕ для перехода в режим ожидания модуля данных, посылаемого противоположной стороной при помощи примитива 5ЕИО. Когда модуль данных прибывает, получатель разблокируется. Затем он может обработать полученный модуль и послать ответ.
Такая схема прекрасно работает, пока обе стороны помнят, чей черед посылать, а чей — принимать. Обратите внимание на то, что на сетевом уровне даже простая однонаправленная пересылка данных оказывается сложнее, чем на транспортном уровне. Каждый посланный пакет данных будет, в конце концов, подтвержден. Пакеты, содержащие управляющие модули данных, также подтверждаются, явно или неявно. Эти подтверждения управляются транспортными сущностями при помощи протокола сетевого уровня и не видны пользователям транспортного уровня.
Аналогично транспортным сущностям нег необходимости беспокоиться о таймерах и повторных передачах. Все эти механизмы не видны пользователям транспортного уровня, для которых соединение представляется надежным битовым каналом. Один пользователь помещает в канал биты, которые волшебным образом появляются на другом конце канала.
Эта способность скрывать сложность от пользователей свидетельствует о том, что многоуровневые протоколы являются довольно мощным инструментом. Когда соединение больше не требуется, оно должно быть разорвано, чтобы можно было освободить место в таблицах двух транспортных сущностей. Разъединение существует в двух вариантах: симметричном и асимметричном. В асимметричном варианте любой пользователь транспортной службы может вызвать примитив 015СОИИЕСТ, в результате чего удаленной транспортной сущности будет послан управляющий модуль ТР?Н1 015СОИиЕСТ!Ои ИЕООЕ5Т (запрос разъединения).
После получения модуля ТРЕ)(3 удаленной транспортной сугцностью соединение разрывается. В симметричном варианте каждое направление закрывается отдельно, независимо от другого. Когда одна сторона выполняет примитив 015СОИИЕСТ, зто означает, что у нее больше нет данных для передачи, но что она все еше готова принимать данные от своего партнера. В этой схеме соединение разрывается, когда обе стороны выполняют примитив 015СОИИЕСТ. Диаграмма состояний для установки и разрыва соединения показана на рис. 6.3.
Каждый переход вызывается каким-то событием или примитивом, выполненным локальным пользователем транспортной службы или входящим пакетом. Для простоты мы будем считать, что каждый модуль треэ() подтверждается отдельно. Транспортная служба ВВ7 Мы также предполагаем, что используется модель симметричного разъединения в которой клиент делает первый ход. Обратите внимание на простоту этой моде- ли. Позднее мы рассмотрим более реалистичные модели. Получен ТРРСьмодуль с запросом соединяли Выполнен примитив 1 Выполнен примитив СОЕДИНИТЬ Получен ТРОО с запросом резь дуль ем ПАССИВНОЕ РАЗЪЕДИНЕНИЕ одупь сзепросом рвзьединения Выполнен примитив РАЗЪЕДИНИТЬ Рис. 6.3.
Диаграмма состояний для простой схемы управления соединениями. Переходы, обозначенные курсивом, вызываются прибытием пакетов. Сплошными линиями показана последовательность состояний клиента. Пунктирными линиями показана последовательность состояний сервера Сокеты Беркли Теперь рассмотрим другой набор транспортных примитивов — примитивы сокетов (иногда называемых гнездами), используемые в операционной системе Вег)ге1еу ())к(1Х для протокола ТСР (Тгапзт(зз(оп Соптго1 Ргососо1 — протокол управления передачей). Они приведены в табл. 6.2. Модель сокетов во многом подобна рассмотренной ранее модели транспортных примитивов, но обладает большей гибкостью и предоставляет больше возможностей.
Модули ТРТ)Ц соответствующие этой модели, будут рассматриваться далее в этой главе, когда мы будем изучать ТСР. Первые четыре примитива списка выполняются серверами в таком же порядке. Примитив 50СКСТ создает новый сокет и выделяет для него место в таблице транспортной сущности. Параметры вызова указывают используемый формат адресов, тип требуемой услуги (например, надежный байтовый поток) и протокол. В случае успеха примитив 50СКЕТ возвращает обычный описатель файла, ис- 658 Глава 6.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
