Увидев эти шесть пакетов, необходимых для работы протокола, можно удивиться, почему же не используется протокол без установления соединения? Ответ таков: в идеальном мире, где нужны всего два пакета — один для запроса и один для ответа, — это, возможно, имело бы смысл. Но стоит представить себе передачу большого сообщения (скажем, мегабайтного файла), причем в обе стороны, причем с ошибками при передаче, потерянными пакетами и т. д., как ситуация меняется. Если ответ сервера состоит из нескольких сотен пакетов, парочка из которых затерялась по пути, то как клиент узнает, что он получил сообщение не в полном объеме? Как он узнает о том, что последний принятый пакет является действительно последним? Допустим, клиент запросил второй файл. Как он отличит пакет 1 из второго файла от потерянного пакета 1 из первого файла, который вдруг нашелся? Короче говоря, в реальном мире простой протокол запросов-ответов без подтверждений часто не подходит. В главе 3
мы обсудим протоколы, позволяющие решать самые разные проблемы, возникающие при передаче данных. А сейчас поверьте на слово: наличие надежной связи с упорядоченным байтовым потоком между процессами — это удобно.
1.3.5. Службы и протоколы
Службы и протоколы являются различными понятиями. Различие между ними столь важно, что мы хотели бы еще раз обратить на него ваше внимание.
Напротив,
Повторим этот важный момент, службы — это нечто, связанное с межуровневыми интерфейсами, тогда как протоколы связаны с пакетами, передающимися объектами одного уровня, расположенными на разных машинах. Это показано на рис. 1.16. Очень важно не путать эти два понятия.
Стоит провести аналогию с языками программирования. Службу можно уподобить абстрактному типу данных или объекту в объектно-ориентированных языках программирования. Он определяет операции, которые могут выполняться с объектом, но не описывает, как реализованы эти операции. В этом случае протокол, напротив, относится к
Рис. 1.16. Связь между службой и протоколом
Во многих старых системах служба не отделялась от протокола. В результате типичный уровень мог содержать примитив службы SEND PACKET, в котором пользователь должен был указать ссылку на полностью собранный пакет. Это означало, что любые изменения протокола тут же становились видимыми для пользователей. Большинство разработчиков сетей сегодня считают подобный подход серьезнейшей ошибкой.
1.4. Эталонные модели
Обсудив многоуровневые сети в общих чертах, пора рассмотреть несколько примеров. Мы опишем два важных архитектурных типа — эталонные модели OSI и TCP/IP. Несмотря на то что
1.4.1. Эталонная модель OSI
Эталонная модель OSI (за исключением физической среды) показана на рис. 1.17. Эта модель основана на разработке Международной организации по стандартизации (International Organization for Standardization, ISO) и является первым шагом к международной стандартизации протоколов, используемых на различных уровнях (Day и Zimmerman, 1983). Затем она была пересмотрена в 1995 году (Day, 1995). Называется эта структура эталонной моделью взаимодействия открытых систем ISO (ISO OSI (Open System Interconnection) Reference Model), поскольку она связывает открытые системы, то есть системы, открытые для связи с другими системами. Для краткости мы будем называть эту модель просто «модель OSI».
Модель OSI имеет семь уровней. Появление именно такой структуры было обусловлено следующими соображениями.