Компьютерные сети. Принц, техн, прот 1-303. Книга переведена на английский, испанский, китайский и португальский языки
Скачать 5.49 Mb.
|
темы для обсуждения (Request For Comments, RFC) – показывает гласный и открытый характер принимаемых стандартов. В результате Интернет сумел объединить в себе разнообразное оборудование и программное обеспечение огромного числа сетей, разбросанных по всему миру. Ввиду постоянной растущей популярности Интернета RFC-документы становятся международными стандартами де-факто, многие из которых затем приобретают статус официальных международных стандартов в результате их утверждения какой-либо организацией по стандартизации, как правило, ISO и ITU-T. Существует несколько организационных подразделений, отвечающих за развитие и, в частности, за стандартизацию архитектуры и протоколов Интернета. Основным из них является научно-административное сообщество Интернета (Internet Society, ISOC), объединяющее около 100 000 человек, которое занимается социальными, политическими и техническими проблемами эволюции Интернета. Под управлением ISOC работает совет по архитектуре Интернета (Internet Architecture Board, IAB). В IAB входят две основные группы: Internet Research Task Force (IRTF) и Internet Engineering Task Force (IETF). IRTF координирует долгосрочные исследовательские проекты по протоколам TCP/IP. IETF – это инженерная группа, которая занимается решением текущих технических проблем Интернета. Именно IETF определяет спецификации, которые затем становятся стандартами Интернета. Процесс разработки и принятия стандарта для протокола Интернета состоит из ряда обязательных этапов, или стадий, включающих непременную экспериментальную проверку. В соответствии с принципом открытости Интернета все RFC-документы, в отличие, скажем, от стандартов ISO, находятся в свободном доступе. Список RFC-документов можно найти, в частности, на сайте www.rfc-editor.org. Стандартные стеки коммуникационных протоколов Важнейшим направлением стандартизации в области вычислительных сетей является стандартизация коммуникационных протоколов. Наиболее известными стеками протоколов являются: OSI, TCP/IP, IPX/SPX, NetBIOS/SMB, DECnet, SNA (отметим, не все из них применяются сегодня на практике). Стек OSI Важно различать модель OSI и стек протоколов OSI. В то время как модель OSI является абстрактной концепцией, стек OSI, построенный на основе модели OSI, представляет со бой набор спецификаций конкретных протоколов, а также многочисленные программные реализации этих протоколов. В отличие от других стеков протоколов, стек OSI полностью соответствует модели OSI, включая спецификации протоколов для всех семи уровней взаимодействия, определенных в этой модели (рис. 4.10). Это вполне объяснимо – разработчики стека OSI использовали модель OS1 как прямое руководство к действию. Протоколы стека OSI отличает сложность и неоднозначность спецификаций. Эти свойства стали результатом общей политики разработчиков стека, стремившихся учесть в своих протоколах все многообразие уже существующих и появляющихся технологий. На физическом и канальном уровнях стек OSI поддерживает протоколы Ethernet, Token Ring, FDDI, а также протоколы LLC, X.25 и ISDN, то есть, как и большинство других стеков, использует все разработанные вне стека популярные протоколы нижних уровней. Сетевой уровень включает сравнительно редко используемые протоколы Connection- oriented Network Protocol (CONP) и Connectionless Network Protocol (CLNP). Как следует из названий, первый из них ориентирован на соединение (connection-oriented), второй – нет (connectionless). Более популярны протоколы маршрутизации стека OSI: между конечной и промежуточной системами (End System – Intermediate System, ES-IS) и между промежуточными системами (Intermediate System – Intermediate System, IS-IS). Транспортный уровень стека OSI в соответствии с функциями, определенными для него в модели OSI, скрывает различия между сетевыми сервисами с установлением соединения и без установления соединения, так что пользователи получают требуемое качество обслуживания независимо от нижележащего сетевого уровня. Чтобы обеспечить это, транспортный уровень требует, чтобы пользователь задал нужное качество обслуживания. Службы прикладного уровня обеспечивают передачу файлов, эмуляцию терминала, сервис каталогов и почту. Из них наиболее популярными являются сервис каталогов (стандарт Х.500), электронная почта (Х.400), протокол виртуального терминала (VTP), протокол передачи, доступа и управления файлами (FTAM), протокол пересылки и управления работами (JTM). Протокол Network Basic Input/Output System (NetBIOS) появился в 1984 году как сетевое расширение стандартных функций базовой системы ввода-вывода (BIOS) IBM PC для сетевой программы PC Network фирмы IBM. В дальнейшем этот протокол был заменен так называемым протоколом расширенного пользовательского интерфейса NetBEUI (NetBIOS Extended User Interface). Для совместимости приложений в качестве интерфейса к протоколу NetBEUI был сохранен интерфейс NetBIOS. NetBEUI разрабатывался как эффективный протокол, потребляющий немного ресурсов и предназначенный для сетей, насчитывающих не более 200 рабочих станций. Этот протокол поддерживает много полезных сетевых функций, которые можно отнести к транспортному и сеансовому уровням модели OSI, однако с его помощью невозможна маршрутизация пакетов. Это ограничивает применение протокола NetBEUI локальными сетями, не разделенными на подсети, и делает невозможным его использование в составных сетях. Протокол Server Message Block (SMB) поддерживает функции сеансового уровня, уровня представления и прикладного уровня. На основе SMB реализуется файловая служба, а также службы печати и передачи сообщений между приложениями. Стек TCP/IP Стек TCP/IP был разработан по инициативе Министерства обороны США более 20 лет назад для связи экспериментальной сети ARPAnet с другими сетями как набор общих протоколов для разнородной вычислительной среды. Большой вклад в развитие стека TCP/IP, который получил свое название по популярным протоколам IP и TCP, внес Университет Беркли, реализовав протоколы стека в своей версии ОС UNIX. Популярность этой операционной системы привела к широкому распространению протоколов TCP, IP и других протоколов стека. Сегодня этот стек используется для связи компьютеров в Интернете, а также в огромном числе корпоративных сетей. Мы подробно рассмотрим стек протоколов TCP/IP в части IV этой книги, посвященной одноименным сетям. Соответствие популярных стеков протоколов модели OSI На рис. 4.12 показано, в какой степени популярные стеки протоколов соответствуют рекомендациям модели OSI. Как мы видим, часто это соответствие весьма условно. В большинстве случаев разработчики стеков отдавали предпочтение скорости работы сети в ущерб модульности – ни один стек, кроме стека OSI, не разбит на семь уровней. Чаще всего в стеке явно выделяются 3-4 уровня: уровень сетевых адаптеров, в котором реализуются протоколы физического и канального уровней, сетевой уровень, транспортный уровень и уровень служб, вбирающий в себя функции сеансового уровня, уровня представления и прикладного уровня. Структура стеков протоколов часто не соответствует рекомендуемому моделью OSI разбиению на уровни и по другим причинам. Давайте вспомним, чем характеризуется идеальная многоуровневая декомпозиция. С одной стороны, необходимо соблюсти принцип иерархии: каждый вышележащий уровень обращается с запросами только к нижележащему, а нижележащий предоставляет свои сервисы только непосредственно соседствующему с ним вышележащему. В стеках протоколов это приводит к тому, что PDU вышележащего уровня всегда инкапсулируется в PDU нижележащего. С другой стороны, идеальная многоуровневая декомпозиция предполагает, что все модули, отнесенные к одному уровню, ответственны за решение общей для всех них задачи. Однако эти требования часто вступают в противоречие. Например, основной функцией протоколов сетевого уровня стека TCP/IP (так же, как и сетевого уровня OSI) является передача пакетов через составную сеть. Решение этой задачи возлагается на протокол продвижения IP-пакетов и протоколы маршрутизации, в частности, RIP и OSPF. Если считать признаком принадлежности к одному и тому же уровню общность решаемых задач, то, очевидно, протокол IP и протоколы маршрутизации должны быть отнесены к одному уровню. Но если принять во внимание, что сообщения протокола маршрутизации RIP инкапсулируются в дейтаграммы транспортного уровня, а сообщения протокола OSPF – в IP-пакеты, то, формально следуя принципу иерархической организации стека, OSPF следовало бы отнести к транспортному, a RIP – к прикладному уровню. На практике же протоколы маршрутизации обычно включают в сетевой уровень. В телекоммуникационных сетях «докомпьютерной» эры всегда преобладали транспортные услуги. Основной услугой телефонной сети была передача голосового трафика между абонентами, в то время как справочные услуги были дополнительными. С появлением компьютеров информационные услуги пережили революцию, так как компьютер и был изобретен для автоматической программной обработки информации. В компьютерных сетях одинаково важны обе категории услуг. Благодаря этой особенности новое поколение телекоммуникационных сетей иногда называют инфокоммуникационными сетями. Из рисунка видно, что полный стек протоколов реализован только на конечных узлах, а коммуникационным устройствам для продвижения пакетов достаточно функциональности нижних трех уровней. Более того, коммуникационное устройство может поддерживать только протоколы двух нижних уровней или даже одного физического уровня – это зависит от типа устройства. Именно к таким устройствам, работающим на физическом уровне, относятся, например, сетевые повторители, называемые также концентраторами или хабами. Они повторяют электрические сигналы, поступающие на одни их интерфейсы, на других своих интерфейсах, улучшая характеристики сигналов – мощность и форму, синхронность их следования. Коммутаторы локальных сетей поддерживают протоколы двух нижних уровней, физического и канального, что дает им возможность работать в пределах стандартных топологий. Маршрутизаторы должны поддерживать протоколы всех трех уровней, так как сетевой уровень нужен им для объединения сетей различных технологий, а протоколы нижних уровней – для взаимодействия с конкретными сетями, образующими составную сеть, например, Ethernet или Frame Relay. Коммутаторы глобальных сетей (например, MPLS), работающие на основе технологии виртуальных каналов, могут поддерживать как два уровня протоколов, так и три. Протокол сетевого уровня нужен им в том случае, если они поддерживают процедуры автоматического установления виртуальных каналов. Так как топология глобальных сетей произвольна, без сетевого протокола обойтись нельзя. Если же виртуальные соединения устанавливаются администраторами сети вручную, то коммутатору глобальной сети достаточно поддерживать только протоколы физического и канального уровней, чтобы передавать данные по уже проложенным виртуальным каналам. Компьютеры, на которых работают сетевые приложения, должны поддерживать протоколы всех уровней. Протоколы прикладного уровня, пользуясь сервисами протоколов уровня представления и сеансового уровня, предоставляют приложениям набор сетевых услуг в виде сетевого прикладного программного интерфейса (API). Протокол транспортного уровня также работает на всех конечных узлах. При передаче данных через сеть два модуля транспортного протокола, работающие на узле-отправителе и узле-получателе, взаимодействуют друг с другом для поддержания транспортного сервиса нужного качества. Коммуникационные устройства сети переносят сообщения транспортного протокола прозрачным образом, не вникая в их содержание. Конечные узлы сети (компьютеры и компьютеризованные устройства, например мобильные телефоны) всегда предоставляют как информационные, так и транспортные услуги, а промежуточные узлы сети – только транспортные. Когда мы говорим, что некоторая сеть предоставляет только транспортные услуги, то подразумеваем, что конечные узлы находятся за границей сети. Это обычно имеет место в обслуживающих клиентов коммерческих сетях. Если же говорят, что сеть предоставляет также информационные услуги, то это значит, что компьютеры, предоставляющие эти услуги, включаются в состав сети. Примером является типичная ситуация, когда поставщик услуг Интернета поддерживает еще и собственные веб-сервера. Вспомогательные протоколы транспортной системы Настало время сказать, что на рис. 4.13 показан упрощенный вариант распределения протоколов между элементами сети. В реальных сетях некоторые из коммуникационных устройств поддерживают не только протоколы трех нижних уровней, но и протоколы верхних уровней. Так, маршрутизаторы реализуют протоколы маршрутизации, позволяющие автоматически строить таблицы маршрутизации, а концентраторы и коммутаторы часто поддерживают протоколы SNMP и telnet, которые не нужны для выполнения основных функций этих устройств, но позволяют конфигурировать их и управлять ими удаленно. Существуют также DNS-сервера, которые отображают символьные имена хостов на их IP-адреса, и без этой вспомогательной функции нормальная работа в Интернете практически невозможна. Большинство вспомогательных протоколов формально относятся к прикладному уровню модели OSI, так как в своей работе они обращаются к протоколам нижних уровней, таким как TCP, UDP или SSL. При этом вспомогательные протоколы не переносят пользовательские данные, то есть они не выполняют непосредственно функций протокола прикладного уровня, описанного в модели OSI. Очевидно, что при рассмотрении вспомогательных протоколов мы сталкиваемся с ситуацией, когда деления протоколов на уровни иерархии (то есть деления «по вертикали»), присущего модели OSI, оказывается недостаточно. Полезным оказывается деление протоколов на группы «по горизонтали». При горизонтальном делении все протоколы (как основные, так и вспомогательные) разделяют на три слоя (planes) (рис. 4.14): |