Лекции 2010-го года (1130544), страница 73
Текст из файла (страница 73)
Диаграмма состояний при установлении и разрыве соединенияВ таблице 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). Его идеясостоит в следующем. Все машины в сети оснащены таймерами. Таймер работает даже вслучае сбоя машины, т.е. он абсолютно надежен. Каждый таймер - двоичный счетчикдостаточно большой разрядности, равной или превосходящей разрядностьпоследовательных чисел, используемых для нумерации пакетов. При установлениисоединения значения нескольких младших разрядов этого таймера берутся в качественачального номера пакета.
Главное, чтобы последовательности номеров пакетов одногосоединения не приводили к переполнению счетчика и его обнулению. Эти номера можнотакже использовать для управления потоком в протоколе скользящего окна.Проблема возникает, когда машина восстанавливается после сбоя. Транспортный агент незнает в этот момент, какое число можно использовать для очередного номера. Чтобыизбежать повторного использования порядкового номера, который уже был сгенерированперед сбоем машины, вводится специальная величина по времени, которая образуетобласть запрещенных номеров (см. рисунок 6-10).Рисунок 6-10. (а) TPDU не могут попасть в запрещенную область; (b) ПроблемаресинхронизацииНеобходимость введения этой области демонстрирует следующий пример. Предположимдля простоты, что в момент x начальный номер будет x, и что максимальное время жизнипакета равно 60 сек.
Пусть в t=30 сек. был послан пакет с номером 80, после чегонаступил сбой в ее работе. Пусть в момент t=60 машина была восстановлена после сбоя, ив момент t=70 появился пакет с номером 80. Однако старый пакет с номером 80 все ещесуществует, так как он будет жить до t=90. Поэтому для каждого момента времени вводятобласть запрещенных номеров. Машина, восстановленная после сбоя, не может выбиратьномера из этой запретной зоны. Поэтому после восстановления следует подождать Т сек.,пока все ранее посланные пакеты не перестанут существовать. На практике поступаютиначе, чтобы не тратить впустую эти Т сек.
Строят кривую скорости генерации номеровn=at, тогда после сбоя надо выбирать номера по формуле: n=at+T.Проблема номеров может возникать по двум причинам. Либо потому, что машинагенерирует слишком быстро пакеты и соединения, либо потому, что делает это слишкоммедленно. Чем больше разрядность счетчика последовательных номеров, тем дальшеотодвигается момент попадания в запретную область.Другая нетривиальная проблема - надежное установление соединения: пакеты ведь могутпропадать. Для ее решения Томлинсон предложил процедуру «троекратногорукопожатия» (three-way handshake), которая проиллюстрирована на рисунке 6-11. (CR иACK обозначают соответственно CONNECTION REQUEST и CONNECTIONACCEPTED.)Рисунок 6-11.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
