Компьютерные сети. 6-е изд.

Далее клиент выполняет примитив SEND для передачи своего запроса (3) с последующим RECEIVE для получения ответа. Поступление пакета с запросом разблокирует сервер, и он может обработать запрос. После завершения необходимых действий сервер отправляет ответ клиенту (4) с помощью примитива SEND. Получение этого пакета разблокирует клиента, который теперь может обработать ответ и отправить дополнительные запросы, если таковые у него есть.

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

Конечно, на практике не все так просто. Многое может пойти не так. Могут возникать проблемы с очередностью происходящего (например, выполнение CONNECT перед LISTEN), теряться пакеты и многое другое. Эти проблемы будут подробнее рассмотрены позже, а пока что илл. 1.30 вкратце резюмирует взаимодействие «клиент-сервер» для дейтаграмм с подтверждением (мы можем игнорировать потери пакетов).

Учитывая, что для одного цикла этого протокола требуется шесть пакетов, может показаться странным, что взамен него не используется протокол без установления соединения. Конечно, в идеальном мире так бы и было. Понадобились бы только два пакета: один для запроса, а второй для ответа. Впрочем, если учесть возможность передачи сообщений большого размера в обе стороны (например, файла размером в мегабайт), потенциальные ошибки передачи и возможную потерю пакетов, ситуация меняется. Если ответ состоит из сотен пакетов, клиенту необходимо знать, не потерялась ли часть из них при передаче. Как он узнает, что последний полученный пакет был последним отправленным? Или представим, что клиент запросил второй файл. Как он сможет отличить пакет 1 второго файла от потерянного и внезапно найденного пакета 1 из первого файла? Короче говоря, на практике простого протокола запрос/ответ при связи по ненадежной сети обычно недостаточно. В главе 3 мы подробно изучим множество протоколов, позволяющих решить эти и другие проблемы. А пока что отметим только, что надежный упорядоченный байтовый поток между процессами иногда может очень пригодиться.

1.5.5. Службы и протоколы

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

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

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

Илл. 1.31. Соотношение между службой и протоколом

Уместно будет провести аналогию с языками программирования. Служба подобна абстрактному типу данных или объекту в объектно-ориентированном языке. Она описывает, какие операции можно выполнять над объектом, но не уточняет, как они должны быть реализованы. А протокол относится к реализации службы и сам по себе пользователю службы не виден.

Во многих старых протоколах службы и протоколы не различались. В сущности, типичный уровень мог включать примитив службы SEND PACKET10, а пользователь передавал ссылку на полностью готовый пакет. Такое соглашение означало, что все изменения протокола сразу же становились видимы пользователям. Большинство разработчиков сетей считают подобную архитектуру серьезной ошибкой.

9Дикий кролик (лат.). — Примеч. ред.

10«Отправить пакет». — Примеч. пер.

1.6. Эталонные модели

Многоуровневая архитектура протоколов — одна из ключевых абстракций в сетевой архитектуре. Важнейшей задачей при этом является описание функциональности уровней и взаимодействий между ними. Ниже рассматриваются две основные эталонные модели — TCP/IP и OSI, а также модель, которая представляет собой компромисс между ними (ее мы и будем использовать далее в книге).

1.6.1. Эталонная модель OSI

Модель OSI (за исключением физической среды) показана на илл. 1.32. В основе этой модели лежит проект, разработанный Международной организацией по стандартизации (International Standards Organization, ISO). Это был первый шаг к международной стандартизации протоколов, используемых на различных уровнях (Дэй и Циммерман; Day & Zimmermann, 1983). Модель была пересмотрена в 1995 году (Дэй; Day, 1995) и получила название эталонной модели взаимодействия открытых систем ISO (ISO OSI (Open Systems Interconnection) Reference Model). Она описывает вопросы соединения открытых систем, то есть таких, которые открыты для обмена информацией с другими системами. Для краткости мы будем называть ее моделью OSI.

Модель OSI включает 7 уровней, выделенных согласно следующим принципам:

1.Каждый уровень соответствуют отдельной абстракции.

2.Все уровни выполняют четко определенные функции.

3.Функция каждого уровня выбирается с учетом создания в дальнейшем международных стандартизированных протоколов.

4.Границы уровней должны выбираться так, чтобы минимизировать поток информации через интерфейсы.

5.Количество уровней не должно быть слишком низким, чтобы не приходилось собирать разные функции в одном уровне; но нельзя, чтобы их было чересчур много, иначе архитектура будет громоздкой.

Центральными для модели OSI являются три понятия:

1.Службы.

2.Интерфейсы.

3.Протоколы.

Илл. 1.32. Эталонная модель OSI

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

В модели TCP/IP изначально отсутствовало четкое разграничение служб, интерфейсов и протоколов; хотя позже были попытки сделать ее более похожей на модель OSI.

1.6.2. Эталонная модель TCP/IP

Эталонная модель TCP/IP использовалась в прародителе всех глобальных вычислительных сетей — ARPANET и его наследнике — всемирной сети интернет. Как мы рассказывали выше, ARPANET была исследовательской сетью, которую финансировало Минобороны США. В конечном счете она объединила сотни университетов и правительственных объектов при помощи выделенных телефонных линий. С появлением радио- и спутниковых сетей оказалось, что существующие протоколы не подходили для межсетевого взаимодействия, так что появилась необходимость в новой эталонной архитектуре. Таким образом, практически с самого начала одной из основных целей ее разработки было обеспечение бесперебойного соединения множества сетей. Эта архитектура позднее стала известна под названием эталонной модели TCP/IP (TCP/IP Reference Model; TCP и IP — два ее основных протокола). Первыми ее описали Серф и Кан (Cerf & Kahn, 1974), а позднее она была пересмотрена и зафиксирована в виде интернет-стандарта (Брейден; Braden, 1989). Основные принципы проектирования этой модели обсуждаются в работе Кларка (Clark, 1988).

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

Канальный уровень

С учетом этих требований была выбрана сеть с коммутацией пакетов, основанная на уровне без соединений, работающем в различных сетях. Низший уровень модели, канальный уровень (link layer), описывает, какими должны быть каналы связи (например, последовательные линии связи и традиционный Ethernet) для удовлетворения потребностей межсетевого уровня без соединений. На самом деле это даже не уровень в обычном смысле этого слова, а скорее интерфейс между хостами и линиями передачи. В первых описаниях модели TCP/IP он игнорировался.

Межсетевой уровень

Межсетевой уровень (internet layer) — краеугольный камень всей архитектуры. Он показан на илл. 1.33. Его задача — сделать так, чтобы хосты могли внедрять пакеты в произвольную сеть для последующего движения к пункту назначения (возможно, расположенного в другой сети) независимо друг от друга. Эти пакеты даже могут прибывать совершенно не в том порядке, в каком они были отправлены. Если необходимо соблюдение очередности, высшие уровни должны упорядочить пакеты.

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

Илл. 1.33. Эталонная модель TCP/IP

по дороге пройдут через один или несколько международных сортировочных центров, но пользователи об этом не узнают. Более того, от пользователей скрыт тот факт, что в каждой стране (то есть сети) свои почтовые марки, размеры конвертов и правила доставки.

Межсетевой уровень определяет официальный формат пакетов, IP (Internet Protocol — межсетевой протокол), а также вспомогательный протокол ICMP (Internet Control Message Protocol — протокол управления межсетевым обменом сообщениями). Задача межсетевого уровня заключается в доставке IP-пакетов по месту назначения. Главная проблема состоит в маршрутизации пакетов, а также в контроле перегруженности сети. Задача маршрутизации в основном уже решена, но справиться с перегруженностью нельзя без помощи вышележащих уровней.

Транспортный уровень