Полный курс лекций 2009-го года (1130357), страница 72
Текст из файла (страница 72)
Если задача сетевого обеспечить маршрутизацию пакетов, то задачатранспортного сервиса как раз обеспечить надежную доставку сообщений. Два процесса, соединенныемежду собой, ничего не должны знать о том, как физически они соединены. Один помещает данные навход транспортного уровня, другой получает их. Задача транспортного уровня скрыть и от получателя и ототправителя все детали передачи, исправления ошибок и т.п.Теоретически транспортный сервис может быть как ориентированным на соединения, так и нет.Однако дейтаграммный транспортный сервис - это редкость, поэтому мы будем рассматриватьтранспортный сервис, ориентированный на соединения.Другое важное различие между сетевым и транспортным сервисами состоит в том, кто их использует.Сетевой сервис использует транспортный сервис, а вот транспортный использует пользователь, т.е.прикладные программы. Поэтому транспортный сервис должен быть ориентирован на пользователя,должен быть удобным и простым в использовании.Общее представление о примитивах транспортного сервиса дает таблица 6-3.
Этот пример содержитосновные виды примитивов для установления соединения, передачи данных и разрыва соединения, чтовполне достаточно для многих приложений.Таблица 6-3. Примитивы транспортного сервисаПримитивОтправляемый пакет TPDUЗначениеLISTEN(нет)Блокировка, пока какой-либо процесс непопытается установить соединениеCONNECTCONNECTION REQ.Активная попытка установить соединениеSENDSENDИнформация об отправкеRECEIVE(нет)Блокировка до поступления DATA TPDUDISCONNECTDISCONNECTION REQ.Данная сторона собирается прерватьсоединениеИспользование этих примитивов может быть продемонстрировано следующим образом.
Серверприложения выполняет примитив LISTEN, в результате чего он блокируется до поступления запросов отклиентов. Клиент для установления соединения выполняет примитив CONNECT. Транспортный агент настороне клиента блокирует клиента и посылает серверу пакет с запросом на установление соединения.Напомним, что транспортные агенты обмениваются пакетами, которые имеют специальное название Transport Protocol Data Unit (TPDU).
Взаимосвязь между кадрами, пакетами и TPDU показана на рисунке 64.Рисунок 6-4. Взаимосвязь между кадрами, пакетами и TPDUИтак, по примитиву CONNECT транспортный агент на стороне клиента шлет CONNECTION REQUESTTPDU. Транспортный агент сервера, видя, что сервер заблокирован по LISTEN, разблокирует сервер ипосылает CONNECTION ACCEPTED TPDU.
После этого транспортное соединение считается установленным иначинается обмен данными с помощью примитивов SENT и RECEIVE.По окончании обмена соединение должно быть разорвано. Есть два варианта разрыва соединения:симметричный и асимметричный. Асимметричный разрыв предполагает, что для разрыва соединения однаиз сторон посылает DISCONNECT TPDU. Получив этот TPDU, другая сторона считает соединениеразорванным.При симметричном разрыве каждое направление закрывается отдельно.
Когда одна сторона посылаетDISCONNECT TPDU, это значит, что с ее стороны больше данных не будет. На рисунке 6-5 показанадиаграмма состояний при установлении и разрыве соединения. (Переходы, выделенные курсивом,вызываются прибытием пакета. Пунктирной линией обозначена последовательность состояний сервера,сплошной - клиента.)Рисунок 6-5. Диаграмма состояний при установлении и разрыве соединенияВ таблице 6-6 показан другой набор примитивов, так называемые сокеты Беркли. В этом набореесть два основных отличия от того, что мы только что рассмотрели.
Они состоят в следующем. Первыечетыре примитива выполняются сервером в том порядке, как они указаны в таблице. Примитив SOCKETсоздает новую точку подключения к серверу, резервирует для нее место в таблице транспортного агента.Параметры обращения определяют формат адреса, тип желаемого сервиса, протокол и т.д. По примитивуBIND сервер выделяет сокету адрес. Причина, по которой адрес выделяется не сразу, в том, что некоторыепроцессы сами управляют своими адресами, которые жестко закреплены за ними.
Второе – LISTEN - неблокирующий примитив. Он выделяет ресурсы и создает очередь, если несколько клиентов будутобращаться за соединением в одно и то же время. Примитив ACCEPT - блокирующий в ожидании запросана соединение.Таблица 6-6. Сокеты БерклиПримитивЗначениеSOCKETСоздание новой точки подключенияBINDПрикрепление локального адреса к сокетуLISTENОбъявление готовности принимать соединения; сообщение о размере очередиACCEPTБлокировка вызывающего в ожидании запроса на соединениеCONNECTАктивная попытка установить соединениеSENDОтправка данных через данное соединениеRECEIVEПолучение данных через данное соединениеCLOSEПрерывание соединенияКогда клиент выполняет примитив CONNECT, он блокируется своим транспортным агентом, изапускается процесс установления соединения.
Когда он закончится, клиента разблокируют, и начинаетсяобмен данными с помощью примитивов SEND и RECEIVE. Разрыв соединения здесь симметричен, т.е.соединение считается разорванным, если обе стороны выполнили примитив CLOSE.6.2. Элементы транспортного протоколаТранспортный сервис реализует транспортный протокол, который используют транспортные агенты.Транспортный протокол в чем-то схож с канальным. Однако между ними несколько различий:1.Они работают в разных средах (см. рисунок 6-7).2.Процессы на канальном уровне взаимодействуют непосредственно через физическую среду, поэтомупроцедура установления соединения много проще.3.Среда, в которой работает транспортный протокол, использует память, которая может терять своесодержимое.4.Количество соединений, которое может возникать на транспортном уровне, намного больше, чемколичество соединений на канальном уровне, что создает дополнительные проблемы для буферизации иуправления потоком.Рисунок 6-7.
(а) Среда канального уровня; (b) Среда транспортного уровняТранспортный протокол должен решать следующие проблемы:1.Как адресовать прикладной процесс, с которым надо установить соединение?2.Как корректно установить соединение? Пакеты могут теряться. Как отличить пакеты нового соединенияот повторных пакетов, оставшихся от старого?3.Как корректно разрывать соединение?Далее мы последовательно рассмотрим существующие решения для этих проблем.6.2.1. АдресацияПроблема адресации состоит в том, как указать, с каким удаленным прикладным процессом надоустановить соединение. Обычно для этого используется транспортный адрес, по которому прикладнойпроцесс может слушать запросы на соединение. Вместо него мы будем здесь использовать термин TSAP Transport Service Access Point. Аналогичное понятие существует и на сетевом уровне, это IP-адрес - NSAPдля сетевого уровня.На рисунке 6-8 показана взаимосвязь ТSAP и NSAP.
Он же иллюстрирует сценарий использованияТSAP для установления соединения между двумя удаленными процессами.Рисунок 6-8. Взаимодействие TSAP и NSAPИз этой иллюстрации не ясно лишь, как прикладной процесс на машине 1 узнает, что интересующийего сервер подключен к ТSAP 122 на машине 2? Одно из возможных решений - если данный сервер всегдаподключен к ТSAP 122, и все процессы об этом знают.Такое решение хорошо работает для часто используемого сервиса с длительным периодомактивности, но как быть прикладным процессам пользователя, которые активизируются спорадически накороткое время? Одно из решений, используемых в операционной системе Unix, показано на рисунке 6-9.Оно называется протоколом установления начального соединения. На каждой машине есть специальныйсервер процессов, который представляет все процессы, исполняемые на этой машине.
Этот сервер слушаетнесколько ТSAP, куда могут поступить запросы на ТСР-соединение. Если нет свободного сервера,способного выполнить запрос, то соединение устанавливается с сервером процессов, который переключитсоединение на нужный сервер, как только он освободится.Рисунок 6-9. Пользовательский процесс на хосте 1 устанавливает соединение ссервером времениОднако есть случаи, когда этот подход с сервером процессов не работает. Не всегда можно запускатьсервер сервиса по требованию пользователя.
Например, файловый сервер. Он должен существоватьвсегда. Решение в этом случае - сервер имен. Пользователь устанавливает соединение с сервером имен,для которого ТSAP известен, и передает ему имя сервиса. В ответ сервер имен шлет надлежащий ТSAP.Клиент разрывает соединение с сервером имен и устанавливает его по полученному адресу.Пусть пользователь узнал ТSAP, но как он узнает, на какой машине этот ТSAP расположен, какойсетевой адрес надо использовать? Ответ заключается в структуре ТSAP-адреса, где указана всянеобходимая информация.
Этот адрес имеет иерархическую структуру.6.2.2. Установление соединенияПроблема установления транспортного соединения сложна потому, что пакеты могут теряться,храниться и дублироваться на сетевом уровне.Типичный пример - установление соединения с банком для перевода денег с одного счета на другой.Из-за перегрузки в сети или по какой-либо другой причине может произойти большая задержка.
Тогда поtime_out активная сторона вышлет еще один запрос. Пакеты-дубли могут вызвать повторное соединение ивторичный перевод денег. Как быть?Одно из возможных решений - временное ТSAP. После того, как оно использовано, TSAP с такимадресом более не возникает. При этом решении не работает модель с сервером процессов (рисунок 6-9),когда определенные TSAP имеют фиксированные адреса.Другое решение - каждому транспортному соединению сопоставлять уникальный номер. Когдасоединение разрывается, этот номер заносится в специальный список. К сожалению, этот список можетрасти бесконечно.
Кроме этого, в случае сбоя машины он может быть потерян, и тогда...Альтернативой может быть ограничение времени жизни пакетов. Достичь этого можно тремя путями:1.ограничением конструкции подсети2.установкой счетчиков скачков в каждом пакете3.установкой временной метки на каждом пакетеЗаметим, что последний метод требует синхронизации маршрутизаторов в сети.На практике нам надо обеспечить, чтобы стали недействительными не только сами пакеты, но иуведомления о них. Это значит, что надо ввести величину Т – интервал времени, который в несколько разможет превышать время жизни пакета.
Эта величина Т получается умножением максимального временижизни пакета в сети на некоторый коэффициент. Конкретное значение этого коэффициента зависит отконкретного протокола и позволяет немного увеличить реальное время жизни так, чтобы по истечениипериода времен длины Т в сети не осталось ни самого пакета, ни уведомления о нем.При ограничении времени жизни пакета можно построить безопасный способ установлениясоединения. Этот метод был предложен Томлинсоном (Tomlinson).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
