Конечно, жизнь не настолько проста. Описанный выше алгоритм работы весьма схематичен, а кое-что просто неправильно (например, CONNECT на самом деле выполняется до LISTEN). При этом пакеты, бывает, теряются, возникают и другие проблемы. Позднее мы рассмотрим все это гораздо более подробно, но на данный момент можно по рис. 1.15 получить общее представление о работе клиент-серверной системы с установлением соединения, использованием общепризнанных дейтаграмм и игнорированием потерянных пакетов.
Увидев эти шесть пакетов, необходимых для работы протокола, можно удивиться, почему же не используется протокол без установления соединения? Ответ таков: в идеальном мире, где нужны всего два пакета — один для запроса и один для ответа, — это, возможно, имело бы смысл. Но стоит представить себе передачу большого сообщения (скажем, мегабайтного файла), причем в обе стороны, причем с ошибками при передаче, потерянными пакетами и т. д., как ситуация меняется. Если ответ сервера состоит из нескольких сотен пакетов, парочка из которых затерялась по пути, то как клиент узнает, что он получил сообщение не в полном объеме? Как он узнает о том, что последний принятый пакет является действительно последним? Допустим, клиент запросил второй файл. Как он отличит пакет 1 из второго файла от потерянного пакета 1 из первого файла, который вдруг нашелся? Короче говоря, в реальном мире простой протокол запросов-ответов без подтверждений часто не подходит. В главе 3
мы обсудим протоколы, позволяющие решать самые разные проблемы, возникающие при передаче данных. А сейчас поверьте на слово: наличие надежной связи с упорядоченным байтовым потоком между процессами — это удобно.
1.3.5. Службы и протоколы
Службы и протоколы являются различными понятиями. Различие между ними столь важно, что мы хотели бы еще раз обратить на него ваше внимание. Служба (или сервис) — это набор примитивов (операций), которые более низкий уровень предоставляет более высокому. Служба определяет, какие именно операции уровень будет выполнять от лица своих пользователей, но никак не оговаривает, как должны реализовываться эти операции. Служба описывает интерфейс между двумя уровнями, в котором нижний уровень является поставщиком сервиса, а верхний — его потребителем.
Напротив, протокол — это набор правил, описывающих формат и назначение кадров, пакетов или сообщений, которыми обмениваются объекты одного ранга внутри уровня. Объекты используют протокол для реализации определений своих служб. Они могут менять протокол по желанию, при условии, что при этом остаются неизменными службы, предоставляемые ими своим пользователям. Таким образом, служба и протокол оказываются практически независимыми. Это — ключевое понятие, которое должен хорошо понять любой проектировщик сетей.
Повторим этот важный момент, службы — это нечто, связанное с межуровневыми интерфейсами, тогда как протоколы связаны с пакетами, передающимися объектами одного уровня, расположенными на разных машинах. Это показано на рис. 1.16. Очень важно не путать эти два понятия.
Стоит провести аналогию с языками программирования. Службу можно уподобить абстрактному типу данных или объекту в объектно-ориентированных языках программирования. Он определяет операции, которые могут выполняться с объектом, но не описывает, как реализованы эти операции. В этом случае протокол, напротив, относится к реализации службы и, таким образом, невидим для пользователей службы.
Рис. 1.16. Связь между службой и протоколом
Во многих старых системах служба не отделялась от протокола. В результате типичный уровень мог содержать примитив службы SEND PACKET, в котором пользователь должен был указать ссылку на полностью собранный пакет. Это означало, что любые изменения протокола тут же становились видимыми для пользователей. Большинство разработчиков сетей сегодня считают подобный подход серьезнейшей ошибкой.
1.4. Эталонные модели
Обсудив многоуровневые сети в общих чертах, пора рассмотреть несколько примеров. Мы опишем два важных архитектурных типа — эталонные модели OSI и TCP/IP. Несмотря на то что протоколы, связанные с эталонной моделью OSI, сейчас не используются, сама модель до сих пор весьма актуальна, а свойства ее уровней, которые будут обсуждаться в этом разделе, очень важны. В эталонной модели TCP/IP все наоборот: сама модель сейчас почти не используется, а ее протоколы являются едва ли не самыми распространенными. Исходя из этого, мы обсудим подробности, касающиеся обеих моделей. К тому же иногда приходится больше узнавать из поражений, чем из побед.