tanenbaum_seti_all.pages (525408), страница 151
Текст из файла (страница 151)
Транспортный уровень Во-первых, на уровне передачи данных маршрутизатору не требуется указывать, с каким маршрутизатором он хочет поговорить, — каждая выходная линия однозначно определяет маршрутизатор, На транспортном уровне требуется явно указывать адрес получателя. Во-вторых, процесс установки соединения по проводу (рис.
6А, а) прост: противоположная сторона всегда присутствует (если только опа не вышла из строя), В любом случае, работы не очень много. На транспортном уровне начальная установка соединения, как булет показано далее, происходит более сложно. Еще одно весьма досадное различие между уровнем передачи данных и транспортным уровнем состоит в том, что подсеть потенциально обладает возможностями хранения информации.
Когда маршрутизатор посылает кадр, оп может прибыть или потеряться, но кадр не может побродить где-то какое-то время, спрятаться в отдаленном уголке земного шара, а затем внезапно появиться в самый неподходящий момент 30 секунд спустя. Если подсеть использует дейтаграммы и адаптивную маршрутизацию, то всегда есть ненулевая вероятность того, что пакет будет храниться где-нибудь несколько секунд, а уже потом булет доставлен по назначению. Последствия способности подсети хранить пакеты иногда могут быть катастрофичными и требуют применения специальных протоколов. Последнее различие между уровнем передачи данных и транспортным уровнем является скорее количественным, чем качественным. Буферизация и управление потоком необходимы на обоих уровнях, но наличие болыпого динамически изменяющегося количества соединений на транспортном уровне может потребовать принципиально другого подхода, нежели использовавшийся на уровне передачи ланных.
Некоторые протоколы, упоминавшиеся в главе 3, выделяют фиксированное количество буферов для каждой линии, так что, когда прибывает кадр, всегда имеется свободный буфер. На транспортном уровне из-за большого количества управляемых соединений идея выделения нескольких буферов каждому соединению выглядит не столь привлекательно.
В следующих разделах мы изучим зги и другие важные вопросы. Адресация Когда один прикладной процесс желает установить соединение с другим прикладным процессом, он должен указать, с кем именно он хочет связаться. (У не требующей соединений транспортной службы проблемы такие же: кому следует посылать каждое сообщение?) Применяемый обычно метод состоит в определении транспортных адресов, к которым процессы могут посылать запросы на установку соединения. В Интернете такие конечные точки называются портами.
В сетях АТМ это точки лоступа к службе ААТ.-ВАР (Бегу1се Ассевз Ро1пг). Мы булем пользоваться нейтральным термином ТИАР (Тгапзрогг Яегу1се Асеева Ро1пг— точка доступа к службам транспортного уровня). Аналогичные конечные точки сетевого уровня называются ХЯАР (Нега огк Яегт1се Ассеав Ро(пг — точка доступа к сетевому сервису). Примерами ХБАР являются 1Р-адреса. Рисунок 6.5 иллюстрирует взаимоотношения между НБАР, ТИАР и транспортным соединением. Прикладные процессы как клиента, так и сервера могут Элементы транспортных протоколов 565 связываться с Т5АР для установки соединения с удаленным Т5АР.
Такие соединения проходят через 1ч5АР на каждом хосте, как показано на рисунке, ТВАР нужны для того, чтобы различать конечные точки, совместно использующие М5АР, в сетях, где у каждого компьютера есть свой ХЯАР. Хост 1 Хост 2 Прикпэаной уровень Транспортный уровень Сетевой уровень Уровень передачи данных Физический уровень ы Рис. 6.$. Точки доступа к службам транспортного и сетевого уровня и транспортные соединения Возможный сценарий для трпгспортного соединения выглядит следующим образом: 1. Серверный процесс хоста 2, сообщающий время суток, подсоединяется к точке доступа Т5АР 1522 и ожидает входящего звонка. Вопрос о том, как процесс соединяется с ТИАР, лежит за пределами сетевой модели и целиком зависит от локальной операционной системы, Например, может вызываться примитив, подобный 1ЗТЫ 2. Прикладной процесс хоста 1 желает узнать, который час, позтому он обращается к сети с запросом СОМйкСТ, указывая Т5АР 1208 в качестве адреса отправителя и Т5АР 1522 в качестве адреса получателя.
Это действие в результате приводит к установке транспортного соединения между прикладным процессом хоста 1 и сервером 1, расположенным на хосте 2. 3. Прикладной процесс отправляет запрос, надеясь выяснить, который час. 4. Сервер обрабатывает запрос и в качестве ответа посылает информацию о точ- ном времени. 5. Транспортное соединение разрывается.
566 Глава 6. Транспортный уровень Обратите внимание на то, что на хосте 2 могут располагаться и другие серверы, соединенные со своими Т5АР и ожидаюшие входящих запросов на соединение, приходяших с того же Н5АР. Нарисованная картинка всем хороша, но мы обошли стороной один маленький вопрос: как пользовательский процесс хоста 1 узнает, что сервер, сообщаюший время, соединен с Т5АР 1522? Возможно, сервер, сообщающий время, подключается к Т5АР 1522 в течение долгих лет, и постепенно об этом узнают все пользователи сети.
В этом случае службы имеют постоянные Т5АР-адреса, хранящиеся в файлах, расположенных в известных местах, таких как е1о/вепяоеа в Ц)ч1Х-системах. В файлах перечисляются серверы, за которыми жестко закреплены определенные порты. Хотя постоянные Т5АР-адреса могут хорошо подходить для небольшого количества никогда не меняющихся ключевых служб (например, таких как вебсервер), в общем случае пользовательские процессы часто хотят пообщаться с другими пользовательскими процессами, сушествуюшими только в течение короткого времени и не обладаюшнми постоянными Т5АР-адресами, известным всем заранее.
Кроме того, при наличии большого количества серверных процессов, большая часть которых редко используется, слишком расточительным делом оказывается поддержка всех их в активном состоянии с постоянными Т5АР-адресами. То есть требуется другая модель. Одна такая модель показана в упрощенном виде па рис. 6.6. Она называется протоколом начального соединения.
Вместо того чтобы назначать всем возможным серверам хоро1по известные Т5АР-адреса, каждая машина, желающая предоставлять услуги удаленным пользователям, обзаводится специальным обрабатывающим сервером, действующим как прокси (посредник) для менее активно используемых серверов. Он прослушивает одновременно несколько портов, ожидая запроса на соединение. Потенциальные пользователи этой услуги начинают с того, что посылают запрос СОММЕСТ, указывая Т5АР-адрес нужной им службы. Если никакой сервер их не ждет, они получают соединение с обрабатывающим сервером, как показано на рис. 6.6, а.
Получив запрос, обрабатывающий сервер порождает подпроцесс на запрошенном сервере, позволяя ему унаследовать существующее соединение с пользователем. Новый сервер выполняет требуемую работу, в то время как обрабатывающий сервер возвращается к ожиданию новых запросов, как показано на рис. 6.6, б. Хотя протокол начального соединения прекрасно работает с серверами, которые можно создавать по мере надобности, есть много ситуаций, в которых службы существуют независимо от обрабатываюшего сервера.
Например, файловый сервер должен работать на специальном оборудовании (машине с диском) и не может быть создан на ходу, когда кто-нибудь захочет к нему обратиться. Чтобы справиться с этой ситуацией, часто используется другая схема. В этой модели используется специальный процесс, называющийся сервером имен или иногда каталоговым сервером.
Чтобы найти Т5АР-адрес, соответствующий данному имени службы, например «время суток», пользователь устанавливает соединение с сервером имен (Т5АР-адрес которого всем известен). Затем пользователь посылает сообщение с указанием названия нужной ему услуги, и сервер Элементы транспортных протоколов ВВ7 имен сообшает ему ТИАР-адрес этой службы.
После этого пользователь разрывает соединение с сервером имен и устанавливает новое соединение с нужной ему службой. Хост З Хост 1 Хост 1 Уровен Рис. 6.В. Пользовательский процесс хоста 1 устанавливает соединение с сервером хоста 2 В этой модели, когда создается новая служба, она должна зарегистрироваться на сервере имен, сообщив ему название услуги (обычно строка АЯСП) и ТИАР-адрес. Сервер имен сохраняет полученную информацию в своей базе данных, чтобы иметь возможность отвечать на будущие запросы. Функция сервера имен аналогична работе оператора телефонной справочной службы — он преобразует имена в номера. Как и в телефонной системе, важно, чтобы ТИАР-адрес сервера имен (или обрабатывающего сервера в протоколе начального соединения) был действительно хорошо известен. Если вы не знаете номера телефонной справочной, вы не сможете позвонить оператору.
Если вы полагаете, что номер справочной является очевидным, попытайтесь угадать его, находясь в другой стране, Установка соединения Установка соединения, хотя и просто звучит, неожиданно оказывается весьма непростым делом. На первый взгляд, должно быть достаточно одной транспортной сущности, для того чтобы послать адресату ТРЕШ-модуль с запросом соединения СОММЕСТ!ОМ ДЕООЕ5Т и услышать в ответ СОММЕСТ10М АССЕРТЕО (соединение принЯто). Неприятность заключается в том, что сеть может потерять, задержать или дубли- ровать пакеты.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
