tanenbaum_seti_all.pages (525408), страница 148
Текст из файла (страница 148)
В этом случае пользователи столкнутся с большими проблемами. У них нет контроля над сетевым уровнем, поэтому они не смогут улучшить качество обслуживания, используя хорошие маршрутизаторы или совершенствуя обработку ошибок уровня передачи данных. Единственная возможность заключается в использовании еше одного уровня, расположенного над сетевым, для улучшения качества обслуживания. Если транспортный объект узнает, что его сетевое соединение было внезапно прервано, но не получит каких-либо сведений о том, что случилось с передаваемыми в этот момент данными, он может установить новое соединение с удаленной транспортной сущностью. С помощью нового сетевого соединения он может послать запрос к равноранговому объекту и узнать, какие данные дошли до адресата, а какие нет, после чего продолжить передачу данных. По сути, благодаря наличию транспортного уровня транспортный сервис может быть более надежным, чем лежащий ниже сетевой сервис.
Транспортным уровнем могут быть обнаружены потерянные пакеты и искаженные данные, после чего потери могут быть компенсированы. Более того, примитивы транспортной службы могут быть разработаны таким образом, что они будут независимы от примитивов сетевой службы, которые могут значительно варьироваться от сети к сети (например, сервис локальной сети без соединений может значительно отличаться от сервиса ориентированной на соединение глобальной сети).
Если спрятать службы сетевого уровня за набором примитивов транспортной службы, то для изменения сетевой службы потребуется просто заменить один набор библиотечных процедур другими, делаюшими то же самое, но с помощью других сервисов более низкого уровня. Благодаря наличию транспортного уровня прикладные программы могут использовать стандартный набор примитивов и сохранять работоспособность в самых различных сетях. Им не придется учитывать имеюшееся разнообразие интерфейсов подсетей и беспокоиться о неналежной передаче данных. Если бы все реальные сети работали идеально и у всех сетей был один набор служебных примитивов, то транспортный уровень, вероятно, был бы не нужен.
Однако в реальном мире он выполняет ключевую роль изолирования верхних уровней от леталей технологии, устройства и несовершенства подсети. Именно по этой причине часто проводится разграничение между уровнями с первого по четвертый и уровнями выше четвертого. Нижние четыре уровня можно рассматривать как поставщика транспортных услуг, а верхние уровни — как пользователя транспортных услуг. Разделение на поставщика и пользователя оказывает серьезное влияние на устройство уровней и помешает транспортный уровень в ключевую позицию, поскольку он формирует основную границу между поставщиком и пользователем надежной службы передачи данных.
554 Глава б. Транспортный уровень Примитивы транспортной службы Чтобы пользователи могли получить доступ к транспортной службе, транспортный уровень должен совершать некоторые действия по отношению к прикладным программам, то есть предоставлять интерфейс транспортной службы. У всех транспортных служб есть свои интерфейсы, В этом разделе мы вначале рассмотрим простой (но гипотетический) пример транспортной службы и ее интерфейсов, просто чтобы узнать основные принципы и понятия. Следующий раздел будет посвящен реальному примеру. Транспортная служба подобна сетевой, но имеет и некоторые существенные отличия, Главное отличие состоит в том, что сетевая служба предназначена для моделирования сервисов, предоставляемых реальными сетями, со всеми их особенностями.
Реальные сети теряют пакеты, поэтому в общем случае сетевая служба ненадежна. Ориентированная на соединение транспортная служба, напротив, является надежной. Конечно, реальные сети содержат ошибки, но именно транспортный уровень как раз и должен обеспечивать надежность сервисов ненадежных сетей. В качестве примера рассмотрим два процесса, соединенных каналами в системе ПХ1Х. Эти процессы предполагают, что соединение между ними идеально. Они не желают знать о подтверждениях, потерянных пакетах, заторах и т. п. Им требуется стопроцентно нздежное соединение. Процесс А помещает данные в один конец канала, а процесс В извлекает их на другом.
Имеьшо для этого и предназначена ориентированная на соединение транспортная служба — скрывать несовершенство сетевого уровня, чтобы пользовательские процессы могли считать, что существует безошибочный поток битов. Кстати, транспортный уровень может также предоставлять ненадежный (дейтаграммный) сервис, но о нем сказать почти нечего, поэтому мы в данной главе сконцентрируемся на транспортной службе, ориентированной на соединение. Тем не менее, некоторые приложения, например, клиент-серверные вычислительные системы и потоковое мультимедиа, даже выигрывают от дейтаграммных сервисов, поэтому далее мы еще упомянем их. Второе различие между сетевой и транспортной службами состоит в том, для кого они предназначены.
Сетевая служба используется только транспортными объектами. Мало кто пишет свои собственные транспортные объекты, и поэтому пользователи и программы почти не встречаются с голой сетевой службой. Транспортные примитивы, напротив, используются многими программами, а следовательно, и программистами. Поэтому транспортная служба должна быть удобной и простой в употреблении. Чтобы получить представление о транспортной службе, рассмотрим пять примитивов, перечисленных в табл, 6.1, Этот транспортный интерфейс сильно упрощен, но он лает представление о назначении ориентированного на соединение транспортного интерфейса.
Он позволяет прикладным программам устанавливать, использовать и освобождать соединения, чего вполне достаточно для многих приложений. Транспортная служба 665 Таблица 6.1. Примитивы простой транспортной службы Поопанный модуль денных Значение транспортного протокола Примитив ЫЗТЕМ (ОЖИДАТЬ) (нвт) Блокировать сервер, пока какой-либо процесс на попытается соединиться Активно пытаться установить соединение Послать информацию Блокировать сервер, пока нв прибудутданныв Прервать соединение ЗАПРОС СОЕДИНЕНИЯ СОММЕСТ (СОЕДИНИТЬ] ЗЕМО (ПОСЛАТЬ) ЙЕСЕ1(ГЕ (ПОЛУЧИТЬ) 018СОММЕСТ (РАЗЪЕДИНИТЬ) ДАННЫЕ (нвт) ЗАПРОС РАЗЪЕДИНЕНИЯ Заголовок кадра Заголовок Заголовок пакете ТРО0-модуля Рис. 6.2.
Вложенность модулей данных транспортного протокола, пакетов и кадров Чтобы понять, как могут быть использованы эти примитивы, рассмотрим приложение, состоящее из сервера и нескольких удаленных клиентов. Вначале сервер выполняет примитив (.15Ткй' — обычно для этого вызывается библиотечная процедура, которая обращается к системе. В результате сервер блокируется, пока клиент не обратится к нему. Когда клиент хочет поговорить с сервером, он выполняет примитив ОО)())5СТ. Транспортный объект выполняет этот примитив, блокируя обратившегося к нему клиента и посылая пакет серверу. Поле данных пакета содержит сообщение транспортного уровня, адресованное транспортному объекту сервера.
Следует сказать пару слов о терминологии. За неимением лучшего термина, для сообщений, посылаемых одной транспортной сущностью другой транспортной сущности, нам придется использовать несколько неуклюжее сокращение ТР$К1 (Тгапзрогс Ргогосо1 Ра(а ()п(с — модуль данных транспортного протокола). Модули данных, которыми обмениваются транспортные уровни, помещаются в пакеты (которыми обмениваются сетевые уровни). Эти пакеты, в свою очередь, содержатся в кадрах, которыми обмениваются уровни передачи данных. Получив кадр, уровень передачи данных обрабатывает заголовок кадра и передает содержимое поля полезной нагрузки кадра наверх, сетевой сущности. Сетевая сущность обрабатывает заголовок пакета и передает содержимое поля полезной нагрузки пакета наверх, транспортной сущности.
Эта вложенность проиллюстрирована на рис. 6.2. 666 Глава 6. Транспортный уровень Итак, вернемся к нашему примеру обшения клиента и сервера. В результате запроса клиента СОММЕСТ серверу посылается модуль данных транспортного протокола, содержащий СОММЕСТ!ОМ МЕООЕ5Т (запрос соединения).
Когда он прибывает, транспортная сущность проверяет, заблокирован ли сервер примитивом С15ТЕМ (то есть заинтересован ли сервер в обработке запросов). Затем она разблокирует сервер и посылает обратно клиенту модуль данных СОММЕСТ!ОМ АССЕРТЕО (соединение принято). Получив этот модуль, клиент разблокируется, после чего соединение считается установленным.
Теперь клиент и сервер могут обмениваться данными с помощью примитивов 5ЕМО и МЕСЕ1ЧЕ. В простейшем случае каждая из сторон может использовать блокируюший примитив МЕСЕ1ЧЕ для перехода в режим ожидания модуля данных, посылаемого противоположной стороной при помощи примитива 5ЕМО. Когда модуль данных прибывает, получатель разблокируется.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
