1.11. Маршрутизация - протоколы маршрутизации

2. Транспортный уровень

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

2.1. Службы предоставляемые верхним уровням

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

Сервисы транспортного уровня, как и сервисы сетевого уровня, могут быть ориентированными на соединение или не требующими соединений. Ориентиро- ванный на соединение транспортный сервис во многом похож на ориентирован- ный на соединение сетевой сервис. В обоих случаях соединение проходит три этапа: установка, передача данных и разъединение. Адресация и управление по- током на разных уровнях также схожи. Более того, похожи друг на друга и не требующие соединений сервисы разных уровней. Возникает закономерный вопрос: если сервис транспортного уровня так схож с сервисом сетевого уровня, то зачем нужны два различных уровня? Почему не- достаточно одного уровня? Для ответа на этот важный вопрос следует вернуться к рис. 1.7. На рисунке мы видим, что транспортный код запускается целиком на пользовательских машинах, а сетевой уровень запускается в основном на машру-тизаторах, которые управляются оператором связи (по крайней мере, в глобаль- ных сетях). Что произойдет, если сетевой уровень будет предоставлять ориенти- рованный на соединение сервис, но этот сервис будет ненадежным? Например, если он часто будет терять пакеты? Можно себе представить, что случится, если маршрутизаторы будут время от времени выходить из строя. В этом случае пользователи столкнутся с большими проблемами. У них нет контроля над сетевым уровнем, поэтому они не смогут улучшить качество обслуживания, используя хорошие маршрутизаторы или совершенствуя обработ- ку ошибок уровня передачи данных. Единственная возможность заключается в использовании еще одного уровня, расположенного над сетевым, для улуч- шения качества обслуживания. Если транспортный объект узнает, что его се- тевое соединение было внезапно прервано, но не получит каких-либо сведений о том, что случилось с передаваемыми в этот момент данными, он может устано- вить новое соединение с удаленной транспортной сущностью. С помощью но- вого сетевого соединения он может послать запрос к равноранговому объекту и узнать, какие данные дошли до адресата, а какие нет, после чего продолжить пе- редачу данных. По сути, благодаря наличию транспортного уровня транспортный сервис мо- жет быть более надежным, чем лежащий ниже сетевой сервис. Транспортным уровнем могут быть обнаружены потерянные пакеты и искаженные данные, по- сле чего потери могут быть компенсированы. Более того, примитивы транспорт- ной службы могут быть разработаны таким образом, что они будут независимы от примитивов сетевой службы, которые могут значительно варьироваться от се- ти к сети (например, сервис локальной сети без соединений может значительно отличаться от сервиса ориентированной на соединение глобальной сети). Если спрятать службы сетевого уровня за набором примитивов транспортной службы, то для изменения сетевой службы потребуется просто заменить один набор биб- лиотечных процедур другими, делающими то же самое, но с помощью других сервисов более низкого уровня. Благодаря наличию транспортного уровня прикладные программы могут ис- пользовать стандартный набор примитивов и сохранять работоспособность в са- мых различных сетях. Им не придется учитывать имеющееся разнообразие ин- терфейсов подсетей и беспокоиться о ненадежной передаче данных. Если бы все реальные сети работали идеально и у всех сетей был один набор служебных при- митивов, то транспортный уровень, вероятно, был бы не нужен. Однако в реаль- ном мире он выполняет ключевую роль изолирования верхних уровней от дета- лей технологии, устройства и несовершенства подсети. Именно по этой причине часто проводится разграничение между уровнями с первого по четвертый и уровнями выше четвертого. Нижние четыре уровня мож- но рассматривать как поставщика транспортных услуг, а верхние уровни — как пользователя транспортных услуг. Разделение на поставщика и пользователя оказывает серьезное влияние на устройство уровней и помещает транспортный уровень в ключевую позицию, поскольку он формирует основную границу меж- ду поставщиком и пользователем надежной службы передачи данных.