Э. Таненбаум - Компьютерные сети. (4-е издание) (DJVU) (1130092), страница 152

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 152)

Хост 2 Хост 1 Прикладной уровень Транспортный уровень Сетевой уровень Уровень передачи данных Физический уровень Рис. 6.6. Точки доступа к слухгбам транспортного и сетевого уровня н транспортные соединения Возможный сценарий для транспортного соединения выглядит следующим образом: 1. Серверный процесс хоста 2, сообщающий время суток, подсоединяется к точке доступа ТИАР 1522 и ожидает входящего звонка.

Вопрос о том, как процесс соединяется с ТИАР, лежит за пределами сетевой модели и целиком зависит от локальной операционной системы. Например, может вызываться примитив, подобный ~! 5Т~М. 2. Прикладной процесс хоста 1 желает узнать, который час, поэтому он обращается к сети с запросом СОййЕСТ, указывая ТИАР 1208 в качестве адреса отправителя и ТИАР 1522 в качестве адреса получателя.

Это действие в результате приводит к установке транспортного соединения между прикладным процессом хоста 1 и сервером 1, расположенным на хосте 2. 3. Прикладной процесс отправляет запрос, надеясь выяснить, который час. 4. Сервер обрабатывает запрос и в качестве ответа посылает информацию о точ- ном времени. 5. Транспортное соединение разрывается. 5бб Глава 6. Транспортный уровень Обратите внимание на то, что на хосте 2 могут располагаться и другие серверы, соединенные со своими ТБАР и ожидающие входящих запросов на соединение, приходящих с того же К1БАР.

Нарисованная картинка всем хороша, но мы обошли стороной один маленький вопрос как пользовательский процесс хоста 1 узнает, что сервер, сообщающий время, соединен с ТБАР 1522? Возможно, сервер, сообщающий время, подключается к ТБАР 1522 в течение долгих лет, и постепенно об этом узнают все пользователи сети. В этом случае службы имеют постоянные ТБАР-адреса, хранящиеся в файлах, расположенных в известных местах, таких как е1с/зеплсеа в ПсПХ-системах, В файлах перечисляются серверы, за которыми жестко закреплены определенные порты.

Хотя постоянные ТБАР-адреса могут хорошо подходить для небольшого количества никогда не меняющихся ключевых служб (например, таких как вебсервер), в общем случае пользовательские процессы часто хотят пообщаться с другими пользовательскими процессами, существующими только в течение короткого времени и не обладающими постоянными ТБАР-адресами, известным всем заранее. Кроме того, при наличии большого количества серверных процессов, большая часть которых редко используется, слишком расточительным делом оказывается поддержка всех их в активном состоянии с постоянными ТБАР-адресамн.

То есть требуется другая модель. Одна такая модель показана в упрощенном виде на рис. 6.6. Она называется протоколом начального соединения. Вместо того чтобы назначать всем возможным серверам хорошо известные ТБАР-адреса, каждая машина, желающая предоставлять услуги удаленным пользователям, обзаводится специальным обрабатывающим сервером, действующим как прокси (посредник) для менее активно используемых серверов. Он прослушивает одновременно несколько портов, ожидая запроса на соединение. Потенциальные пользователи этой услуги начинают с того, что посылают запрос СОййеСТ, указывая ТБАР-адрес нужной им службы.

Если никакой сервер их не ждет, они получают соединение с обрабатывающим сервером, как показано на рис. 6.6, а. Получив запрос, обрабатывающий сервер порождает подпроцесс на запрошенном сервере, позволяя ему унаследовать существующее соединение с пользователем. Новый сервер выполняет требуемую работу, в то время как обрабатывающий сервер возвращается к ожиданию новых запросов, как показано на рис. 6.6, б. Хотя протокол начального соединения прекрасно работает с серверами, котоРые можно создавать по мере надобности, есть много ситуаций, в которых службы существуют независимо от обрабатывающего сервера, Например, файловый сервер должен работать на специальном оборудовании (машнне с диском) и не может быть создан на ходу, когда кто-нибудь захочет к нему обратиться. Чтобы справиться с этой ситуацией, часто используется другая схема.

В этой модели используется специальный процесс, называющийся сервером имен или иногда каталоговым сервером. Чтобы найти ТБАР-адрес, соответствующий данному имени службы, например квремя суток», пользователь устанавливает соединение с сервером имен (ТБАР-адрес которого всем известен). Затем пользователь посылает сообщение с указанием названия нужной ему услуги, и сервер Элементы транспортных протоколов 567 имен сообщает ему ТИАР-адрес этой службы. После этого пользователь разрывает соединение с сервером имен и устанавливает новое соединение с нужной ему службой, Уроввн Рис. 6.6. Пользовательский процесс хоста! устанавливает соединение с сервером хоста 2 В этой модели, когда создается новая служба, она должна зарегистрироваться на сервере имен, сообщив ему название услуги (обычно строка АБСП) и ТИАР-адрес.

Сервер имен сохраняет полученную информацию в своей базе данных, чтобы иметь возможность отвечать на будущие запросы. Функция сервера имен аналогична работе оператора телефонной справочной службы — он преобразует имена в номера. Как и в телефонной системе, важно, чтобы ТИАР-адрес сервера имен (или обрабатывающего сервера в протоколе начального соединения) был действительно хорошо известен. Если вы не знаете номера телефонной справочной, вы не сможете позвонить оператору. Если вы полагаете, что номер справочной является очевидным, попытайтесь угадать его, находясь в другой стране. Установка соединения Установка соединения, хотя и просто звучит, неожиданно оказывается весьма непростым делом. На первый взгляд, должно быть достаточно одной транспортной сущности, для того чтобы послать адресату ТРЕШ-модуль с запросом соединения СОИИЕСТ1ОИ КЕООЕ5Т и услышать в ответ СОИИЕСТ10И АССЕРТЕО (соединение принлто).

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

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

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

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

После разрыва каждого соединения каждая транспортная су|цность может обновить таблицу, в которой хранятся устаревшие соединения в виде пар (одноранговая транспортная сущность, идентификатор соединения). Для каждого приходящего запроса соединения может быть проверено, не хранится ли уже его идентификатор в таблице (он мог остаться там со времен разорванного ранее соединения). К сожалению, у этой схемы есть существенный изъян: требуется, чтобы каждая транспортная сущность хранила неопределенно долго некоторое количество информации об истории соединений. Если машина выйдет из строя и потеряет свою память, она не сможет определить, какие соединения уже использовались, а какие нет.

Вместо этого можно применить другой подход. Следует разработать механизм, уничтожающий устаревшие заблудившиеся пакеты и не позволяющий им существовать в сети бесконечно долго, Если мы сможем гарантировать, что ни один пакет не сможет жить дольше определенного периода времени, проблема станет более управляемой. Время жизни пакета может быть ограничено до известного максимума с помощью одного из следующих методов: Е Проектирование подсети с ограничениями. Элементы транспортных протоколов 669 2, Помещение в каждый пакет счетчика транзитных участков. 3.

Характеристики

Список файлов книги