Транспортный протокол - это центральный протокол во всей иерархии протоколов. Именно он обеспечивает надежную передачу данных от одного абонента в сети другому. Здесь мы рассмотрим достаточно подробно организацию, сервис, протоколы и производительность.

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

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

Тогда возникает вопрос: Если сервис сетевого уровня столь схож с сервисом транспортного, то зачем два разных уровня? Причина этого состоит в том, что сетевой уровень - это часть подсети передачи данных, которой управляет оператор подсети. Что будет если сетевой уровень предоставляет ненадежный сервис, ориентированный на соединения? Предположим, что он часто теряет пакеты? Что делать если маршрутизатор время от времени отказывает?

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

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

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

Мы уже встречались с понятием качества сервиса при рассмотрении сетевого уровня, где рассматривали набор параметров, с помощью которых можно охарактеризовать это понятие. Транспортный уровень позволяет пользователю определить желаемые, допустимые и минимальные значения для различных параметров в момент установки соединения. Далее сам транспортный уровень будет решать сможет ли он с помощью сетевого сервиса удовлетворить запросы пользователя и до какой степени. На рис. 6-2 перечислены основные параметры сервиса. Заметим, что лишь немногие сети поддерживают все эти параметры.

• Connection establishment delay - задержка на установку соединения время между запросом на установку соединения и подтверждением о его установлении;
• Connection establishment failure probability - вероятность что соединение не будет установлено за время, равное задержке на установку соединения;
• Throughput - пропускная способность - количество байт пользователя, передаваемых за секунду;
• Transit delay - задержка на передачу - время от момента, когда сообщение ушло с машины отправителя, до момента, когда оно получено машиной получателем;
• Residual error ration - доля ошибок при передаче. Теоретически этот параметр должен быть равен 0, если транспортный уровень надежно передает сообщение. На практике это не так;
• Protection - защита: этот параметр позволяет определить уровень защиты передаваемых данных от не санкционированного доступа третьей стороной;
• Priority - приоритет: этот параметр позволяет пользователю указать что это соединение для него важнее чем другие. Поэтому оно должно обслуживаться раньше других;
• Resilience - устойчивость: вероятность что транспортный уровень сам разорвет соединение в силу внутренних проблем или перегрузки.

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

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

6.1.3.Примитивы транспортного уровня

Общее представление о примитивах транспортного сервиса дает рис. 6-3. Этот пример содержит основные виды примитивов для установления соединения, передачи данных и разрыва соединения, что вполне достаточно для многих приложений.

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

Напомним, что транспортные агенты обмениваются пакетами, которые имеют специальное название - Transport Protocol Data Unit (TPDU). Взаимосвязь между кадрами, пакетами и TPDU показана на рис. 6-4.

По примитиву CONNECT транспортный агент на стороне клиента шлет TPDU CONNECTION REQUEST. Транспортный агент сервера, видя что сервер заблокирован по LISTEN, разблокирует сервер и посылает CONNECTION ACCEPTED TPDU. После этого транспортное соединение считается установленным. После этого наступает обмен данными с помощью примитивов SENT и RECEIVE.

По окончании обмена соединение должно быть разорвано. Есть два варианта разрыва соединения: симметричный и асимметричный. Асимметричные предполагает, что для разрыва соединения одна из сторон посылает DISCONNECT TPDU. Получив этот TPDU, другая сторона считает соединение разорванным.

При симметричном разрыве каждое направление закрывается отдельно. Когда одна сторона посылает DISCONNECT TPDU это значит, что с ее сторона больше данных не будет. На рис. 6-5 показана диаграмма состояний при установлении и разрыве соединения.

На рис. 6-6 показан другой набор примитивов - сокеты Беркли. Здесь два основных отличия от того, что мы только что рассмотрели. Первое - создается точка подключения соединения (SOCET), которой прис. аивается адрес (BIND). Второе - LISTEN не блокирующий примитив. Он создает очередь, если несколько клиентов будут обращаться за соединением в одно и то же время.

6.2.Элементы транспортного протокола

1. они работают в разных средах ( см. рис. 6-7);
2. процессы на канальном уровне взаимодействуют через провод, поэтому процедура установления соединения много проще;
3. среда в которой работает транспортный протокол обладает памятью, которая может теряться;
4. количество соединений, которое может возникать на транспортном уровне много больше, чем бывает на канальном, что создает дополнительные проблемы для буферезации и управления потоком.

Транспортный протокол должен решать следующие проблемы:

1. Адресация: как адресовать прикладной процесс, с которым надо установить соединение?
2. Как корректно установить соединение? Ведь ракеты могут теряться. Как отличить пакеты нового соединения от повторных пакетов, оставшихся от старого?
3. Как корректно разрывать соединение?

На рис. 6-8 показано взаимосвязь ТSAP и NSAP. Он же иллюстрирует сценарий использования ТSAP для установления соединения между двумя удаленными процессами. В этой иллюстрации в целом все правильно. Не ясно лишь как прикладной процесс на хост 1 узнает, что интересующий его сервер подключен к ТSAP 122 на хост 2? Одно из возможных решений - данный сервер всегда подключен к ТSAP 122 и все об этом знают.

Это решение хорошо работает для часто используемого сервиса, но как быть прикладным процессам пользователя? Одно из решение, используемых в Unix, показано на рис. 6-9. Оно называется протоколом установления начального соединения. На каждой машине есть специальный сервер процессов, который как бы представляет все процессы исполняемые на этой машине. Этот сервер слушает несколько ТSAP куда могут поступить запросы на ТСР соединение. Если нет свободного сервера, способного выполнить запрос, то соединение устанавливается с сервером процесса, который переключит соединение на нужный сервер, как только он освободится. Однако, есть случаи когда этот подход с сервером процессов не работает. Например, файл сервер. Другое решение - сервер имен. Пользователь устанавливает соединение с сервером имен, для которого ТSAP известен, и передает ему имя сервиса. В ответ сервер имен шлет надлежащий ТSAP.

Пусть пользователь узнал ТSAP, но как он узнает на какой машине этот ТSAP расположен, какой сетевой адрес надо использовать? Ответ заключается в структуре ТSAP адреса, где заключается вся необходимая информация.

Одно из возможных решений - временное ТSAP. Когда оно использовано, использованный адрес более не возникает. При этом решении не работает модель с сервером процессов на рис. 6-9.

Другое решение - каждому транспортному соединению сопоставлять уникальный номер. Когда соединение разрывается этот номер заносится в специальный список. К сожалению этот список может расти бесконечно. Кроме этого в случае сбоя машины он может быть потерян и тогда ...

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

1. Ограничением конструкции подсети;
2. Установкой счетчиков скачков в каждом пакете;
3. Установлением временной метки на каждом пакте.

Заметим, что последний метод требует синхронизации маршрутизаторов в сети.

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

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

Проблема возникает когда машина восстанавливается после сбоя. Транспортный агент не знает в этот момент какое последовательное число использовать. Для того чтобы избежать повторного использования порядкового номера вводится специальная величина по времени, которая образует запрещенную область последовательных номеров(см. рис. 6-10).

Другая нетривиальная проблема - надежное установление соединения: пакеты ведь могут пропадать. Для ее решения Томлинсон предложил процедуру троекратного рукопожатия (рис. 6-11)

Разрыв соединения как уже было сказано может быть асимметричным или симметричным. Асимметричный разрыв может привести к потере данных (см.рис. 6-12). Симметричный разрыв каждая сторона проводит самостоятельно, когда она передала весь имеющийся объем данных. Однако, определить этот факт не всегда просто. Здесь есть одна проблема, которая называется проблемой двух армий (см.рис. 6-13).

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

6.4. Транспортные протоколы в Internet: TCP и UDP

Заголовок ТСР сегмента показан на рис. 6-24. Его многочисленные флаги мы будем рассматривать по ходу изложения.

На рис. 6-26 показаны ситуации при установлении соединения. Случай b показывает ситуацию, когда два хоста одновременно пытаются установить соединение между двумя одинаковыми сокетами. Посколку каждое соединение идентифицируется парой сокетов, то будет установлено только одно из соединений.

Таймер для последовательных номеров сегментов тактируется с частотой 4 (сек, а максимальное время жизни ракета - 120 сек.

ТСР соединение как уже говорилось дуплексное, т.е. в каждом направлении данные передаются независимо и соединение разрывается независимо. Если в очередном сегменте флаг FIN = 1, то в этом направлении данных больше не будет При получении подтверждения для этого сегмента соединение в этом направлении считается разорванным. В другом направлении передача может продолжаться сколь угодно долго. Если подтверждения на первый FIN нет, то попытки продолжаются до трех раз, после чего соединение считается разорванным.

На рис. 6-27 и 6.28 представлена процедура установления и разрыва соединения в виде диаграммы конечного автомата.

Управление окнами в ТСР не связано прямо с поступлением подтверждений. На рис. 6-29 показан случай взаимодействия для буфера в 4096 байт.

Когда поле WIN=0 отправитель может послать сегмент в двух случаях. Первый - если это URGENT данные. Второй, однобайтовый сегмент, чтобы заставить получателя показать текущее состояние буфера. Это очень важно так, как позволяет обойти тупик.

Заметим, что ТСР не требует сразу передавать сегмент как только данные поступили. Эту свободу ТСР использует чтобы повысить свою производительность. Поэтому, часто при реализации ТСР вводят специальную задержку на посылку подтверждения и состояния окна, чтобы дать отправителю накопить буфер для отправки.

Здесь есть одна неприятность. Если на стороне получателя приложение будет медленно считывать буфер , например, по байтно, отправитель будет вынужден отправлять короткие сегменты и не эффективно расходовать пропускную способность.

На рис. 6-31 дана иллюстрация ситуации когда отправителю не разрешается передавать много данных. Это может быть по двум причинам.

Нехватка буфера на стороне получателя. Перегрузка в сети.

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

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

Этот алгоритм называемый slow start- медленный старт реализован с модификацией, показанной на рис. 6-32.

Internet поддерживает также транспортный протокол без соединений - UDP (User Data Protocol). Этот протокол инкапсулирует сегменты в виде дейтаграмм и шлет их через сеть. Структура UDP сегмента показана на рис. 6-34.