Э. Таненбаум - Компьютерные сети. (4-е издание) (DJVU) (1130092), страница 14
Текст из файла (страница 14)
Аналогично, при проведении видеоконференции отдельные неправильные пикселы окажутся меньшей проблемой, нежели дергающиеся и останавливающиеся кадры. Не все приложения требуют установки соединения. Например, при рассылке рекламы по электронной почте установка связи для пересылки каждого отдельного сообщения нежелательна. Также не требуется в этом случае и 100-процентная надежность, особенно, если это существенно увеличит стоимость. Все, что нужно, — это способ переслать сообщение с высокой вероятностью его получения, но без гарантии.
Ненадежная (то есть без подтверждений) служба без установления соединения часто называется службой дейтаграмм, или дейтаграммной службой — по аналогии с телеграфной службой, также не предоставляюьцей подтверждений отправителю. В других ситуациях бывает желательно не устананавливать соединение для пересылки коротких сообщений, но надежность, тем не менее, существенна. Такая служба называется службой дейтаграмм с подтверждениями.
Она подобна отправке заказного письма с подтверждением получения. Получив подтверждение, отправитель уверен, что письмо доставлено адресату, а не потеряно по дороге. Кроме того, существует служба запросов и ответов, в которой отправитель Посылает дейтаграммы, содержащие запросы, и получает ответы от получателя. Например, к данной категории можно отнести вопрос к библиотеке о том, где говорят по-уйгурски. Обычно модель запросов и ответов применяется для реализации общения в модели «клиент-серверги клиент посылает запрос, а сервер отвечает на него. Обсуждавшиеся ранее типы служб сведены в таблицу на рис. 1.13.
68 Глава 1. Введение Пример Служба Надежный поток сообщений Последовательность страниц Ориентированная на соединение Надежный поток байт Удаленная регистрация Ненадежное совдиненив Цифровая голосовая связь Рассылка рекламы злектронной почтой Ненадежная дейтаграмма Без установления соединения Дейтаграмма с подтверждениями Заказные письма Запрос к базе данных Запрос в ответ Рис. 1.13. Шесть типов служб Концепция использования ненадежной связи поначалу может показаться несколько странной. В самом деле, почему это может возникать такая ситуация, когда выгоднее предпочесть ненадежную связь надежной? Во-первых, надежное соединение (в том смысле, который был оговорен ранее, то есть с подтверждением) не всегда можно установить.
Скажем, ЕгЬегпес не является «надежнымь средством коммуникации. Пакеты при передаче могут искажаться, но решать эту проблему должны протоколы более высоких уровней. Во-вторых, задержки, связанные с отсылкой подтверждения, в некоторых случаях неприемлемы, особенно при передаче мультимедиа в реальном времени. Именно благодаря этим факторам продолжают сосуществовать надежные и ненадежные соединения. Примитивы служб Служба (сервис) формально описывается набором примитивов или операций, доступных пользователю или другой суппгости для получения сервиса.
Эти примитивы заставляют службу выполнять некоторые действия или служат ответами на действия сущности того же уровня. Если набор протоколов входит в состав операционной системы (как часто и бывает), то примитивы являются системными вызовами. Они приводят к возникновению системных прерываний в привилегированном режиме, в результате чего управление машиной передается операционной системе, которая и отсылает нужные пакеты.
Набор доступных примитивов зависит от природы сервиса. Скажем, примитивы сервисов с установлением соединения и без него различаются. В табл. 1.3 приведен минимальный набор примитивов, обеспечиваюгций надежную передачу битового потока в среде типа «клиент-серверы Эти примитивы могут использоваться следующим образом. Вначале сервер исполняет ЫВТЕХ, показывая тем самылг, что он готов устанавливать входящие соединения. Этот примитив обычно реализуется в виде блокирующего системного вызова.
После его исполнения процесс сервера приостанавливается до тех пор, пока не будет установлено соединение. Сетевое программное обеспечение 59 Таблица 1.3. Пять сервисных примитивов, обеспечивающих простую передачу с установлением соединения Значение Примитив Блок ожидает входящего соединения Установка соединения с ожидающей сущностью тога же ранга Блок ожидает входящего сообщения Отправка сообщения ожидающей сущности того же ранга Разрыв соединения ОБТЕМ (ожидание) СОММЕСТ (соединение) НЕСЕй(Е (прием) БЕМО (отправка) О(БСОММЕСТ (разрыв) Клиент Сервер 1) Запрос на соединение Процесс клиент Ев жБ йб й О Рис. 1.14. Простейшее взаимодействие клиента и сервера при передаче пакетов по сети с установлением соединения Самым очевидным жизненным примером такого взаимодействия может служить звонок покупателя (клиента) в сервисный центр компании.
Менеджер сер- Ватем процесс клиента выполняет примитив СОЛЛ)ЕСТ, устанавливая соединение с сервером. В системном вызове должно быть указано, с кем именно необходимо установить связь. Для этого может вводиться специальный параметр, содержащий адрес сервера. Далее операционная система клиента посылает равноранговой сущности пакет с запросом на соединение, как показано на рис. 1.14 стрелочкой с пометкой (1). Процесс клиента приостанавливается в ожидании ответа.
Пакет, пришедший на сервер, обрабатывается его операционной системой. Если в пакете обнаруживается запрос на соединение, начинается поиск того клиента, который отправил этот запрос. При его обнаружении производятся два действия: клиент разблокируется и ему отсылается подтверждение (2). Реальное разблокирование происходит по прибытии подтверждения на клиентскую машину. Начиная с этого момента считается, что сервер и клиент установили соединение, Важно отметить здесь то, что подтверждение (2) генерируется самим кодом протокола и не является ответом на примитив пользователя, содержащий запрос. Может возникнуть ситуация, когда запрос на соединение есть, а клиента нет.
В этом случае результат будет неопределенным. В некоторых системах пакет может быть отложен на короткое время, в течение которого ожидается Е!5ТЕЛ). 60 Глава 1. Введение впсного центра должен находиться у телефона, чтобы иметь возможность ответить в том случае, если он зазвонит. Клиент совершает звонок. Когда менеджер поднимает трубку, считается, что соединение установлено. Следуюгцим шагом будет выполнение сервером примитива ВЕСЕ1ЧЕ, подготавливающего систему к принятию первого запроса. В нормальной ситуации это происходит сразу же после прекрашения ожидания (Е13ТЕХ), даже до того, как клиент получает подтверждение соединения.
Системный вызов КЕСЕ1Ъ'Е вновь блокирует сервер. Клиент выполняет ЯЕХР, передает запрос (3) и сразу же выполняет ВЕСЕ1ЧЕ, ожидая ответ. Прием пакета с запросом разблокирует процесс сервера, благодаря чему он может обработать запрос. По окончании обработки выполняется примитив 3ЕХР, и ответ отсылается клиенту (4). Прием пакета разблокирует клиента, теперь наступает его очередь обрабатывать пакет. Если у клиента есть еще запросы к серверу, он может отослать их.
В противном случае соединение разрывается с помощью Р13СОХХЕСТ. Обычно первый примитив Р15СОХХЕСТ отсылает пакет, уведомляюший сервер об окончании сеанса, и блокирует клиента (5). В ответ сервер генерирует свой примитив Р1БСОХХЕСТ, являющийся подтверждением для клиента и командой, разрывающей связь.
Клиент, получив его, разблокируется, и соединение считается окончательно разорванным. Именно так в двух словах можно описать схему коммуникации с установлением соединения. Конечно, жизнь не настолько проста. Описанный алгоритм работы весьма схематичен, а кое-что просто неправильно (например, СОХХЕСТ на самом деле выполняется до ЫВТЕХ). При этом пакеты, бывает, теряются, возникают и другие проблемы. Позднее мы рассмотрим все это гораздо более подробно, но на данный момент можно получить лишь общее представление о работе клиент-серверной системы с установлением соединения. Для этого полезно внимательно изучить рис.
1.14. Увидев эти шесть пакетов, необходимых для работы протокола, можно удивиться, почему же не используется протокол без установления соединения? Ответ таков: в идеальном мире, где нужны всего два пакета — один для запроса и один для ответа, — это, возможно, имело бы смысл. Но стоит представить себе передачу большого сообщения (скажем, мегабайтного файла), причем в обе стороны, причем с ошибками при передаче, потерянными пакетами и т. д., как ситуация меняется.
Если ответ сервера состоит из нескольких сотен пакетов, парочка из которых затерялась по пути, то как клиент узнает, что он получил сообщение не в полном объеме? Как он узнает о том, что последний принятый пакет является действительно последним? Допустим, клиент запросил второй файл, Как он отличит пакет 1 из второго файла от потерянного пакета 1 из первого файла, который вдруг нашелся? Короче говоря, в реальном мире простой протокол запросов-ответов без подтверждений часто не подходит. В главе 3 мы обсудим протоколы, позволяющие решать самые разные проблемы, возникающие при передаче данных. А сейчас поверьте на слово: наличие надежной связи с упорядоченным байтовым потоком между процессами — зто удобно.
Сетевое программное обеспечение 61 Службы и протоколы Службы и протоколы являются различными понятиями, хотя часто эти понятия смешиваются. Различие между ними, однако, столь важно, что мы хотели бы еще раз обратить на него ваше внимание. Служба (или сервис) — это набор примитивов (операций), которые более низкий уровень предоставляет более высокому, Служба определяет, какие именно операпии уровень будет выполнять от лица своих пользователей, но никак не оговаривает, как должны реализовываться эти операции. Служба описывает интерфейс между двумя уровнями, в котором нижний уровень является поставщиком сервиса, а верхний — его потребителем. Напротив, протокол — это набор правил, описывающих формат и назначение кадров, пакетов или сообщений, которыми обмениваются одноранговые сущности внутри уровня.