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

 Транспортный протокол - это центральный протокол во всей иерархии протоколов. Именно он обеспечивает надежную передачу данных от одного абонента в сети другому. Здесь мы рассмотрим достаточно подробно организацию, сервис, протоколы и производительность. 6.1.1. Сервис для верхних уровней
Единственной целью транспортного уровня - обеспечить эффективный, надежный и дешевый сервис для пользователей на прикладном уровне. То что выполняет работу транспортного уровня называется транспортным агентом. Транспортный агент может располагаться в ядре операционной системы, в отдельном процессе пользователя, в библиотеке сетевого приложения, на карте сетевого интерфейса Подобно тому, как сетевой уровень имеет два вида сервиса: ориентированный на соединения и нет, транспортный так же имеет сервис, ориентированный на соединения и без соединений. Адресация и управление потоком схожи на обоих уровнях. Тогда возникает вопрос: Если сервис сетевого уровня столь схож с сервисом транспортного, то зачем два разных уровня? Причина этого состоит в том, что сетевой уровень - это часть подсети передачи данных, которой управляет оператор подсети. Что будет если сетевой уровень предоставляет ненадежный сервис, ориентированный на соединения? Предположим, что он часто теряет пакеты? Что делать если маршрутизатор время от времени отказывает? У пользователя подсетью нет средств для решения проблемы если она возникла. Для того, чтобы ему дать такую возможность надо поверх сетевого пустить еще один уровень, который позволит исправлять качество сетевого уровня. Если транспортному уровню придет сообщение, что соединение на сетевом уровне неожиданно было разорвано, то он может установить новое сетевое соединение с помощью которого выяснить что произошло, какие данные были переданы, а какие нет и т.п. Существо транспортного уровня в том, чтобы сделать сервис транспортного уровня более надежным, чем сетевого. Другое важное соображение в том, что прикладная программа, опираясь на транспортный сервис, становится независимой от сети и может работать в сети с любым сервисом. · 6.1.2. Качество сервиса
Транспортный уровень позволяет пользователю определить желаемые, допустимые и минимальные значения для различных параметров в момент установки соединения. Далее сам транспортный уровень будет решать сможет ли он с помощью сетевого сервиса удовлетворить запросы пользователя и до какой степени. · Connection establishment delay - задержка на установку соединения время между запросом на установку соединения и подтверждением о его установлении; · Connection establishment failure probability - вероятность что соединение не будет установлено за время, равное задержке на установку соединения; · Throughput - пропускная способность - количество байт пользователя, передаваемых за секунду; · Transit delay - задержка на передачу - время от момента, когда сообщение ушло с машины отправителя, до момента, когда оно получено машиной получателем; · Residual error ration - доля ошибок при передаче. Теоретически этот параметр должен быть равен 0, если транспортный уровень надежно передает сообщение. На практике это не так; · Protection - защита: этот параметр позволяет определить уровень защиты передаваемых данных от не санкционированного доступа третьей стороной; · Priority - приоритет: этот параметр позволяет пользователю указать что это соединение для него важнее чем другие. Поэтому оно должно обслуживаться раньше других; · Resilience - устойчивость: вероятность что транспортный уровень сам разорвет соединение в силу внутренних проблем или перегрузки. Параметры качества сервиса определяются пользователем в момент установления транспортного соединения. Указывается желаемое и минимальное значение. Если требуемое качество недостижимо, то транспортный уровень сразу сообщает об этом пользователю даже не обращаясь к получателю сообщения. 6.1.3.Примитивы транспортного уровня
Примитивы транспортного уровня позволяют пользователя получить доступ к транспортному сервису. Транспортный сервис аналогичен сетевому. Между ними существует одна большая разница - сетевой сервис по природе своей не надежен. Задача транспортного сервиса, как раз, обеспечить надежную доставку сообщений. Два процесса, соединенные между собой ничего не должны знать о том как физически они соединены. Один помещает данные на вход другого, другой получает их. Задача транспортного уровня спрятать от них все детали передачи, исправления ошибок и т.п. Другое важное отличие между сетевым и транспортным сервисами - кто их использует. Сетевой - использует транспортный, а вот транспортный - использует пользователь, прикладные программы. Поэтому он должен быть ориентирован на пользователя: удобен, прост в использовании. Использование этих примитивов может быть продемонстрировано следующим образом. Сервер приложения выполняет примитив LISTEN, в результате чего он блокируется до поступления запросов от клиентов. Клиент для установления соединения выполняет примитив CONNECT. Транспортный агент на стороне клиента блокирует клиента и посылает пакет с запросом на установление соединения серверу. Адресация
Проблема адресации состоит в том, как указать с каким удаленным прикладным процессом надо установить соединение? Обычно для этого используется транспортный адрес, по которому прокладной процесс может слушать запросы на соединение. Мы будем использовать термин TSAP - Transport Service Access Point. Аналогичное понятие существует и на сетевом уровне - IP адрес - SAP для сетевого уровня. Это решение хорошо работает для часто используемого сервиса, но как быть прикладным процессам пользователя? Одно из решение, используемых в Unix, показано на рис. 6-9. Оно называется протоколом установления начального соединения. На каждой машине есть специальный сервер процессов, который как бы представляет все процессы исполняемые на этой машине. Этот сервер слушает несколько ТSAP куда могут поступить запросы на ТСР соединение. Если нет свободного сервера, способного выполнить запрос, то соединение устанавливается с сервером процесса, который переключит соединение на нужный сервер, как только он освободится. Однако, есть случаи когда этот подход с сервером процессов не работает. Например, файл сервер. Другое решение - сервер имен. Пользователь устанавливает соединение с сервером имен, для которого ТSAP известен, и передает ему имя сервиса. В ответ сервер имен шлет надлежащий ТSAP. Пусть пользователь узнал ТSAP, но как он узнает на какой машине этот ТSAP расположен, какой сетевой адрес надо использовать? Ответ заключается в структуре ТSAP адреса, где заключается вся необходимая информация. 6.2.2.Установление соединения
Проблема установления транспортного соединения сложно потому, что пакеты могут теряться, храниться и дублироваться на сетевом уровне. Одно из возможных решений - временное ТSAP. Когда оно использовано, использованный адрес более не возникает. Другое решение - каждому транспортному соединению сопоставлять уникальный номер. Когда соединение разрывается этот номер заносится в специальный список. К сожалению этот список может расти бесконечно. Кроме этого в случае сбоя машины он может быть потерян и тогда ... Ограничить время жизни пакетов. Это можно достичь тремя путями: 1. Ограничением конструкции подсети; 2. Установкой счетчиков скачков в каждом пакете; 3. Установлением временной метки на каждом пакте. На практике нам надо обеспечить, чтобы умерли не только сами пакеты, но и уведомления о них. Это значит, что надо ввести величину Т такую, что по ее истечении в сети не осталось ни самого пакета ни уведомления о нем. 6.2.3.Разрыв соединения
Разрыв соединения как уже было сказано может быть асимметричным или симметричным. Асимметричный разрыв может привести к потере данных. Симметричный разрыв каждая сторона проводит самостоятельно, когда она передала весь имеющийся объем данных. Однако, определить этот факт не всегда просто.