1.5 Стек протоколов tcp/ip: назначение, основные характеристики и понятия

1.5.1 Роль и место транспортного уровня в иерархии протоколов

Транспортный уровень – это сердцевина всей иерархии протоколов. Его задача состоит в предоставлении надежной и экономичной передачи данных от машины-источника машине-адресату вне зависимости от физических характеристик использующейся сети или сетей. То есть он организует вход отдельного ПК в сеть любой конфигурации, ниже его осуществляется навигация между сетями или связь ПК в одной сети. Поэтому без транспортного уровня вся концепция многоуровневых протоколов потеряет смысл.

Конечная цель транспортного уровня заключается в предоставлении эффективных и надежных услуг своим пользователям, которыми являются процессы прикладного уровня (процесс: программа в момент выполнения). Для достижения этой цели транспортный уровень в свою очередь пользуется услугами, предоставляемыми сетевым уровнем. Тем самым формируется связанная совокупность услуг, реализуемая только набором протоколов, называемым стеком. Аппаратура и/или программа, выполняющая работу транспортного уровня, называется транспортной сущностью или транспортным объектом. Транспортный объект может располагаться в ядре транспортной системы, в отдельном пользовательском процессе, в библиотечном модуле, загруженном сетевым приложением, или в сетевой интерфейсной плате. Логическая взаимосвязь сетевого, транспортного и прикладного уровней проиллюстрирована на рисунке 6.6.

Все компьютерные сети представляют своим пользователям (хостам и процессам) службы двух типов: ориентированные на соединение и без установления соединения. Служба, ориентированная на соединение, действует подобно телефонной системе, то есть сначала устанавливается соединение, оно используется, после чего разрывается связь. Существенным моментом является то, что это соединение действует подобно трубе: отправитель посылает объекты (биты) с одного конца, а получатель извлекает их на другом конце в том же самом порядке.

Служба без установления соединения является аналогом почтовой связи. Каждое сообщение (как и письмо) содержит полный адрес назначения и каждое сообщение пересылается по системе независимо от других, в силу чего их последовательность может нарушаться.

Сервисы транспортного уровня, как и сервисы сетевого уровня, могут быть ориентированными на соединение или не требующими соединений. В обоих случаях соединение проходит три этапа: установка, передача данных и разъединение. Адресация и управление потоком на разных уровнях также схожи. Похожи друг на друга и не требующие соединений сервисы этих уровней.

Возникает закономерный вопрос: если сервис транспортного уровня так схож с сервисом сетевого уровня, то зачем нужны два различных уровня? Почему недостаточно одного уровня? Для ответа на этот важный вопрос следует вспомнить, что транспортный код запускается целиком на пользовательских машинах, а сетевой уровень запускается в основном на маршрутизаторах, которые управляются оператором связи (а не пользователем). Представьте себе, что произойдет, если сетевой уровень будет предоставлять ориентированный на соединение сервис, но этот сервис будет ненадежным? Например, если он часто будет терять пакеты? Или маршрутизатор вышел из строя?

В этом случае пользователи столкнутся с большими проблемами. В связи с отсутствием контроля над сетевым уровнем они не смогут улучшить качество обслуживания, используя хорошие маршрутизаторы. Единственная возможность в улучшении качества обслуживания заключается в использовании еще одного уровня, расположенного над сетевым. В этом случае, если транспортный объект узнает, что его сетевое соединение было внезапно прервано и он не получит каких-либо сведений о том, что случилось с передаваемыми в этот момент данными, то он может установить новое соединение. С помощью нового сетевого соединения он может послать запрос к равноранговому объекту и узнать, какие данные дошли до адресата, а какие нет, после чего продолжить передачу данных.

По сути, благодаря наличию транспортного уровня транспортный сервис может быть более надежным, чем лежащий ниже сетевой сервис. Транспортным уровнем могут быть обнаружены потерянные пакеты и искаженные данные, после чего потери могут быть восстановлены. Более того, примитивы (операции соединения) транспортной службы могут быть разработаны таким образом, что они будут независимы от примитивов сетевой службы, которые могут значительно варьироваться от сети к сети. Если спрятать службы сетевого уровня за набором примитивов транспортной службы, то для изменения сетевой службы потребуется просто заменить один набор библиотечных процедур другими, делающими то же самое. Взаимоотношение транспортного и сетевого уровней показано на рис. 1.7.

Благодаря наличию транспортного уровня прикладные программы могут использовать стандартный набор примитивов и сохранять работоспособность в самых различных сетях. Им не придется учитывать имеющееся разнообразие интерфейсов подсетей и беспокоиться о ненадежной передаче данных. Если бы все реальные сети работали идеально и у всех сетей был один набор служебных примитивов, то транспортный уровень был бы не нужен. Однако в реальном мире он выполняет ключевую роль изолирования верхних уровней от деталей технологии, устройства и несовершенства подсети.

Именно по этой причине часто проводится разграничение между уровнями с первого по четвертый и уровнями выше четвертого. Нижние четыре уровня можно рассматривать как поставщика транспортных услуг, а верхние уровни – как пользователя транспортных услуг. Разделение на поставщика и пользователя оказывает серьезное влияние на устройство уровней и помещает транспортный уровень в ключевую позицию, поскольку он формирует основную границу между поставщиком и пользователей надежной службы передачи данных.

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

Транспортная служба подобна сетевой, но имеет и некоторые существенные отличия. Главное отличие состоит в том, что сетевая служба предназначена для моделирования сервисов, предоставляемых реальными сетями, со всеми их особенностями. Реальные сети теряют пакеты, поэтому в общем случае сетевая служба ненадежна.

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

Второе различие между сетевой и транспортной службами состоит в том, для кого они предназначены. Сетевая служба используется только транспортными объектами. Мало кто пишет свои собственные транспортные объекты, и поэтому пользователи и программы почти не встречаются с голой сетевой службой. Транспортные же примитивы, напротив, используются многими прикладными программами, а, следовательно, и программистами. Поэтому транспортная служба должна быть удобной и простой в употреблении (программировании).

Чтобы получить представление о транспортной службе, рассмотрим пять примитивов, перечисленных в таблице 1.2. Этот транспортный интерфейс сильно упрощен, но он дает представление о назначении ориентированного на соединение интерфейса. Он позволяет прикладным программам устанавливать, использовать и освобождать соединения, чего вполне достаточно для многих приложений.

Таблица 1.2.

Примитив	Посланный модуль данных транспортного протокола	Значение
LISTEN (ОЖИДАТЬ)	(нет модуля)	Блокировать сервер, пока какой-либо процесс клиента не попытается соединиться
CONNECT (СОЕДИНИТЬ)	ЗАПРОС СОЕДИНЕНИЯ	Активно пытаться установить соединение
SEND (ПОСЛАТЬ)	ДАННЫЕ	Послать информацию
RECEIVE (ПОЛУЧИТЬ)	(нет модуля)	Блокировать сервер, пока не прибудут данные
DISCONNECT (РАЗЪЕДИНИТЬ)	ЗАПРОС РАЗЪЕДИНЕНИЯ	Прервать соединение

Чтобы понять, как могут быть использованы эти примитивы, рассмотрим приложение, обслуживающее систему, состоящую из сервера и нескольких удаленных клиентов. Вначале сервер выполняет примитив LISTEN, для чего вызывается библиотечная процедура, которая обращается к системе. В результате сервер блокируется, пока клиент не обратится к нему. Когда клиент хочет поговорить с сервером, он выполняет примитив CONNECT. Транспортный объект выполняет этот примитив, блокируя обратившегося к нему клиента и посылая пакет серверу. Поле данных этого пакета содержит сообщение транспортного уровня клиента, адресованное транспортному объекту сервера.

При этом сообщения, посылаемые одной транспортной сущностью другой транспортной сущности, называются TPDU (Transport Protocol Data Unit – модуль данных транспортного протокола). Модули данных, которыми обмениваются транспортные уровни, помещаются в пакеты (которыми обмениваются сетевые уровни). Эти пакеты, в свою очередь, содержатся в кадрах, которыми обмениваются уровни передачи данных. Получив кадр, уровень передачи данных обрабатывает заголовок кадра и передает содержимое поля полезной нагрузки кадра наверх, сетевой сущности. Сетевая сущность обрабатывает заголовок пакета и передает содержимое поля полезной нагрузки пакета наверх, транспортной сущности. В результате посланного ранее запроса клиента CONNECT серверу его транспортный протокол формирует CONNECTION REQUEST (запрос соединения). Когда посланный запрос прибывает на сервер, его транспортная сущность проверяет, заблокирован ли сервер примитивом LISTEN (то есть заинтересован ли сервер в обработке запросов). Если это так, то она разблокирует сервер, а клиенту посылает модуль данных CONNECTION ACCEPTED (соединение принято). Получив этот модуль, клиент разблокируется, после чего соединение считается установленным.

Теперь клиент и сервер могут обмениваться данными с помощью примитивов SEND и RECEIVE. В простейшем случае каждая из сторон может использовать блокирующий примитив RECEIVE для перехода в режим ожидания модуля данных посылаемого противоположной стороной при помощи примитива SEND. Когда модуль данных прибывает, получатель разблокируется. Затем он может обработать полученный модуль и послать ответ. Такая схема прекрасно работает, пока обе стороны помнят, чей черед посылать, а чей – принимать.

Когда соединение больше не требуется, оно должно быть разорвано. Указанная процедура является упрощенной и в реальных протоколах не используется. В операционной системе UNIX для протокола TCP (Transmission Control Protocol – протокол управления передачи) используется другой набор транспортных примитивов – примитивы сокетов (иногда называемых гнездами или конечными точками). Они приведены в таблице 1.3.

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

Первые четыре примитива списка выполняются серверами в таком же порядке. Примитив SOCKET создает новый сокет и выделяет для него место в таблице транспортной сущности.

Таблица 1.3.

Примитив	Значение
SOCKET (СОКЕТ)	Создать новый сокет (гнездо связи)
BIND (СВЯЗАТЬ)	Связать локальный адрес с сокетом
LISTEN (ОЖИДАТЬ)	Объявить о желании принять соединение; указать размер очереди, ибо сокет имеет множественность
ACCEPT (ПРИНЯТЬ)	Блокировать звонящего до получения попытки соединения
CONNECT (СОЕДИНИТЬ)	Активно пытаться установить соединение
SEND (ПОСЛАТЬ)	Посылать данные по соединению
RECEIVE (ПОЛУЧИТЬ)	Получать данные у соединения
CLOSE (ЗАКРЫТЬ)	Разрывать соединение

У только что созданного сокета нет сетевых адресов. Они назначаются с помощью примитива BIND. После того, как сервер привязывает адрес к сокету, с ним могут связаться удаленные клиенты.

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

Чтобы заблокировать ожидание входящих соединений, сервер выполняет примитив ACCEPT.

В модели сокетов соединение разрывается, когда обе стороны выполняют примитив CLOSE.