Э. Таненбаум, Д. Уэзеролл - Компьютерные сети (1114668), страница 17
Текст из файла (страница 17)
Ониприводят к возникновению системных прерываний в привилегированном режиме,в результате чего управление машиной передается операционной системе, котораяи отсылает нужные пакеты.Набор доступных примитивов зависит от природы сервиса. Скажем, примитивысервисов с установлением соединения и без него различаются. В табл. 1.3 приведен минимальный набор примитивов, обеспечивающий надежную передачу битового потока54 Глава 1.
Введениев среде типа «клиент-сервер». Они будут знакомы поклонникам сокет-интерфейсаБеркли, поскольку примитивы — упрощенная версия этого интерфейса.Таблица 1.3. Шесть сервисных примитивов, обеспечивающих простую передачус установлением соединенияПримитивЗначениеLISTEN (ожидание)Блокировка, ожидание входящего соединенияCONNECT (соединение)Установка соединения с ожидающим объектом того же рангаACCEPT (прием)Прием входящего соединения от объекта того же рангаRECEIVE (прием)Блокировка, ожидание входящего сообщенияSEND (отправка)Отправка сообщения ожидающему объекту того же рангаDISCONNECT (разрыв)Разрыв соединенияЭти примитивы могут использоваться для взаимодействия запрос-ответ в средеклиент-сервер.
Чтобы проиллюстрировать, как это происходит, мы покажем набросок простого протокола, который осуществляет службу, используя общепризнанныедейтаграммы.Вначале сервер исполняет ����������������������������������������������������LISTEN����������������������������������������������, показывая тем самым, что он готов устанавливать входящие соединения. Этот примитив обычно реализуется в виде блокирующегосистемного вызова. После его исполнения процесс сервера приостанавливается до техпор, пока не будет установлено соединение.Затем процесс клиента выполняет примитив CONNECT, устанавливая соединениес сервером.
В системном вызове должно быть указано, с кем именно необходимо установить связь. Для этого может вводиться специальный параметр, содержащий адрессервера. Далее операционная система клиента посылает равноранговой сущностипакет с запросом на соединение, как показано на рис. 1.15 стрелочкой с пометкой (1).Процесс клиента приостанавливается в ожидании ответа.Когда пакет приходит на сервер, операционная система обнаруживает запрос насоединение. Она проверяет, есть ли слушатель, и в этом случае разблокирует его.
Затем процесс сервера может установить соединение с помощью ACCEPT. Он посылаетответ (2) назад к процессу клиента, чтобы принять соединение. Прибытие этого ответа освобождает клиента. Начиная с этого момента считается, что сервер и клиентустановили соединение.Самым очевидным жизненным примером такого взаимодействия может служитьзвонок покупателя (клиента) в сервисный центр компании. Менеджер сервисногоцентра должен находиться у телефона, чтобы иметь возможность ответить на звонок.Клиент совершает звонок. Когда менеджер поднимает трубку, считается, что соединение установлено.Следующим шагом будет выполнение сервером примитива RECEIVE, подготавливающего систему к принятию первого запроса.
В нормальной ситуации это происходит сразу же после прекращения ожидания (LISTEN), даже до того, как клиентполучает подтверждение соединения. Системный вызов RECEIVE вновь блокируетсервер.1.3. Сетевое программное обеспечение 55Рис. 1.15. Простейшее взаимодействие клиента и сервера с использованиемобщепризнанных дейтаграммКлиент выполняет SEND��������������������������������������������������������������������������������������������������������������������, передает запрос (3) и сразу же выполняет �������������RECEIVE������, ожидая ответ. Прием пакета с запросом разблокирует сервер, благодаря чему он может обработать запрос. По окончании обработки сервер выполняет примитив �����������������SEND�������������, и ответ отсылается клиенту (4).
Прием пакета разблокирует клиента, теперь наступает его очередьобрабатывать пакет. Если у клиента есть еще запросы к серверу, он может отослать их.Когда запросы клиента окончены, он осуществляет разрыв соединения с помощьюDISCONNECT�������������������������������������������������������������. Обычно первый примитив DISCONNECT��������������������������������������������������������������отсылает пакет, уведомляющий сервер об окончании сеанса, и блокирует клиента (5). В ответ сервер генерируетсвой примитив DISCONNECT, являющийся подтверждением для клиента и командой,разрывающей связь. Клиент, получив его, разблокируется, и соединение считаетсяокончательно разорванным.
Именно так в двух словах можно описать схему коммуникации с установлением соединения.Конечно, жизнь не настолько проста. Описанный выше алгоритм работы весьмасхематичен, а кое-что просто неправильно (например, CONNECT на самом делевыполняется до LISTEN). При этом пакеты, бывает, теряются, возникают и другиепроблемы. Позднее мы рассмотрим все это гораздо более подробно, но на данныймомент можно по рис. 1.15 получить общее представление о работе клиент-сервернойсистемы с установлением соединения, использованием общепризнанных дейтаграмми игнорированием потерянных пакетов.Увидев эти шесть пакетов, необходимых для работы протокола, можно удивиться,почему же не используется протокол без установления соединения? Ответ таков:в идеальном мире, где нужны всего два пакета — один для запроса и один для ответа, — это, возможно, имело бы смысл.
Но стоит представить себе передачу большогосообщения (скажем, мегабайтного файла), причем в обе стороны, причем с ошибкамипри передаче, потерянными пакетами и т. д., как ситуация меняется. Если ответ сервера состоит из нескольких сотен пакетов, парочка из которых затерялась по пути,то как клиент узнает, что он получил сообщение не в полном объеме? Как он узнаето том, что последний принятый пакет является действительно последним? Допустим,клиент запросил второй файл. Как он отличит пакет 1 из второго файла от потерянногопакета 1 из первого файла, который вдруг нашелся? Короче говоря, в реальном мирепростой протокол запросов-ответов без подтверждений часто не подходит. В главе 356 Глава 1. Введениемы обсудим протоколы, позволяющие решать самые разные проблемы, возникающиепри передаче данных. А сейчас поверьте на слово: наличие надежной связи с упорядоченным байтовым потоком между процессами — это удобно.1.3.5.
Службы и протоколыСлужбы и протоколы являются различными понятиями. Различие между ними стольважно, что мы хотели бы еще раз обратить на него ваше внимание. Служба (илисервис)����������������������������������������������������������������������� ����������������������������������������������������������������������— это набор примитивов (операций), которые более низкий уровень предоставляет более высокому. Служба определяет, какие именно операции уровень будетвыполнять от лица своих пользователей, но никак не оговаривает, как должны реализовываться эти операции. Служба описывает интерфейс между двумя уровнями, в котором нижний уровень является поставщиком сервиса, а верхний — его потребителем.Напротив, протокол — это набор правил, описывающих формат и назначение кадров, пакетов или сообщений, которыми обмениваются объекты одного ранга внутриуровня.
Объекты используют протокол для реализации определений своих служб. Онимогут менять протокол по желанию, при условии, что при этом остаются неизменнымислужбы, предоставляемые ими своим пользователям. Таким образом, служба и протокол оказываются практически независимыми. Это — ключевое понятие, котороедолжен хорошо понять любой проектировщик сетей.Повторим этот важный момент, службы — это нечто, связанное с межуровневымиинтерфейсами, тогда как протоколы связаны с пакетами, передающимися объектамиодного уровня, расположенными на разных машинах.
Это показано на рис. 1.16. Оченьважно не путать эти два понятия.Стоит провести аналогию с языками программирования. Службу можно уподобитьабстрактному типу данных или объекту в объектно-ориентированных языках программирования. Он определяет операции, которые могут выполняться с объектом,но не описывает, как реализованы эти операции. В этом случае протокол, напротив,относится к реализации службы и, таким образом, невидим для пользователей службы.Рис. 1.16. Связь между службой и протоколомВо многих старых системах служба не отделялась от протокола. В результате типичный уровень мог содержать примитив службы SEND PACKET, в котором пользовательдолжен был указать ссылку на полностью собранный пакет. Это означало, что любыеизменения протокола тут же становились видимыми для пользователей. Большинство разработчиков сетей сегодня считают подобный подход серьезнейшей ошибкой.1.4.
Эталонные модели 571.4. Эталонные моделиОбсудив многоуровневые сети в общих чертах, пора рассмотреть несколько примеров.Мы опишем два важных архитектурных типа — эталонные модели OSI и TCP/IP.Несмотря на то что протоколы, связанные с эталонной моделью OSI, сейчас не используются, сама модель до сих пор весьма актуальна, а свойства ее уровней, которыебудут обсуждаться в этом разделе, очень важны.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
