Модель OSI (CCNA1 2.4.1.1 – 2.4.2.1) – ЧАСТЬ 5

Изобразим этот процесс графически:

Отсюда можно сделать следующий вывод – КПД любой сетевой технологии всегда будет меньше 100%. Очевидно, это связано с тем, что по сети кроме полезных данных в обязательном порядке будут передаваться служебные заголовки.

Единицы данных каждого уровня в рамках модели называются «протокольными единицами данных» или PDU (Protocol Data Unit) соответствующего уровня.

Блоки данных трех верхних уровней не имеют отдельных названий, и называются просто данными. Блоки данных остальных уровней имеют свои собственные названия. Перечислим их.

Блок данных транспортного уровня называется сегментом (segment), либо дейтаграммой

(datagram).

Блок данных сетевого уровня называется пакетом (packet). Блок данных канального уровня называется кадром (frame). Единица данных физического уровня – бит (bit).

Итак,  вроде  бы  все  просто.  Перед  тем,  как  передать  данные  на  нижний  уровень, необходимо только добавить соответствующую служебную информацию. Но здесь возникает следующий вопрос – а можем ли мы быть уверены в том, что способ, которым обрабатываются данные при передаче, будет правильно применен при взаимодействии между уровнями? Или, применяя более формальные термины, – а всегда ли интерфейс между двумя одинаковыми уровнями реализован одним и тем же способом, то есть, являются ли интерфейсы между уровнями стандартизованными?

С одной стороны, очевидно удобство такого подхода: при наличии стандартизованных интерфейсов между всеми уровнями достигается полная независимость уровней друг от друга, и разработка и модификация каждого уровня может не учитывать наличие других уровней, при условии сохранения стандартных интерфейсов к ним. С другой стороны, модель OSI является абстрактной, и в самой модели отсутствуют требования к стандартизации интерфейсов: «OSI по сути не требует стандартизации интерфейсов для открытых систем. Более того, даже если стандарты для таких интерфейсов определены, приверженность таким внутренним стандартам никоим образом не может рассматриваться, как условие открытости». («…OSI per se does not require interfaces within open systems to be standardized. Moreover, whenever standards for such interfaces are defined, adherence to such internal interface standards can in no way be considered as a condition of openness»).

Как же обстоят дела на самом деле? В действительности, для существующих сетевых технологий  существует  только  один  стандартизованный  интерфейс.  Это  интерфейс  между сетевым и канальным уровнями. И даже такая, казалось бы, малость приносит огромную пользу. Ведь что такое интерфейс между сетевым и канальным уровнями? Это интерфейс между программной и аппаратной частью системы! Следовательно, стандартизация этого интерфейса

привела к возможности независимой разработки оборудования и программного обеспечения, к независимости разработчиков ПО от производителей оборудования и наоборот.

Теперь перейдем к рассмотрению протоколов.

Ясно,   что   на   каждом   уровне   функционирует   свой   протокол.   Следовательно,   для обеспечения передачи информации, эти протоколы должны быть соответствующим образом согласованы друг с другом, то есть, нужно рассматривать не каждый протокол в отдельности, а некий набор взаимодействующих протоколов. Для таких наборов существует свое определение – стек протоколов. (CCNA1 2.3.x.x)

Если быть более точным, то существует целых два определения: 1) protocol suite (буквальный перевод – набор протоколов), определяемый как иерархический набор взаимосвязанных протоколов, разработанный, как правило, совместно группой разработчиков («Protocol Suite: A hierarchical set of related protocols designed usually by one vendor»); и 2) стек протоколов, определяемый как программная реализация какого-либо Protocol Suite («Protocol stack: A representation of the hierarchical nature of a protocol suite»). Говоря корректно, suite – это определение протоколов, а stack – программная реализация этого набора протоколов. В англоязычной литературе эти термины часто взаимозаменяемы, в русскоязычной литературе используется только термин «стек»,    определение которого соответствует англоязычному определению suite: «иерархический набор взаимосвязанных протоколов, разработанный, как правило,  совместно  единой  группой  разработчиков».  Однако,  с  учетом  независимости  двух нижних уровней модели OSI от верхних уровней, это определение стека протоколов можно заменить более корректным: стек протоколов – это иерархический набор взаимосвязанных протоколов верхних уровней, разработанный, как правило, совместно единой группой разработчиков.  Я  думаю,  понятно,  почему  необходимо  такое  уточнение:  в  связи  со стандартизацией интерфейса между 2-м и 3-м уровнем модели, разработка протоколов 1-2 и 3-7 уровней ведется, как правило, принципиально разными группами разработчиков. При этом за соответствующим набором протоколов верхних уровней оставили название «стек протоколов», набор же протоколов канального и физического уровня использует название «базовая сетевая технология». И эта терминология очень точно отражает положение дел в сетевых технологиях – ведь  именно  базовая  сетевая  технология  (БСТ)  определяет  аппаратную  реализацию,  «лицо» каждой существующей сетевой технологии.

Таким образом, в настоящее время положение дел таково: существуют различные базовые сетевые технологии, по-разному реализованные аппаратно, и существуют различные стеки протоколов от разных разработчиков. Наличие же стандартизованного интерфейса между аппаратной и программной частями модели обеспечивает возможность функционирования любого стека протоколов поверх любой базовой сетевой технологии.

В качестве примеров стеков протоколов можно привести стеки TCP/IP, IPX/SPX, NetBIOS/SMB. Примерами базовых сетевых технологий могут являться технологии Ethernet, PPP, Frame Relay, ATM и многие другие. В этом курсе мы с вами займемся рассмотрением базовых сетевых технологий локальных сетей, но предварительно обзорно рассмотрим некоторые популярные стеки протоколов.

Начнем со стека протоколов TCP/IP. (CCNA1 2.4.3.x, 2.4.8.x)

Transmission  Control  Protocol/Internet  Protocol  (TCP/IP)  –  это  наиболее  широко используемый в настоящее время промышленный стандарт стека протоколов,   который был разработан для глобальных сетей. Стандарты TCP/IP опубликованы в серии документов, называемых Request for Comment (RFC). Согласен, что «Запрос комментариев» – несколько странное название для документа, но так сложилось, что этот термин давно прижился и является устоявшимся для именования различных документов Интернет, включая и стандарты.

Первые версии протоколов стека появились в середине 70-х гг. прошлого века, по инициативе Министерства обороны США (Department of Defense, сокращенно – DoD), поэтому иногда стек называют «стек DoD». В 1969 году, после построения первой сети ARPANET, Агентство по перспективным научным исследованиям при Министерстве обороны (Defense Advanced  Research  Project  Agency,  DARPA)  заинтересовалось  созданием  надежной  сети  с

коммутацией пакетов, обеспечивающей обмен данными между разнородными вычислительными системами, установленными в исследовательских институтах. Для разработки обеспечения связи между неоднородными сетями DARPA финансировало исследования Стэндфордского университета,   а   так   же   компании   Bolt,   Beranek   and   Newman   (BBN).   Результатом   этих исследований стал набор протоколов Internet.

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

Значительный вклад в развитие стека TCP/IP внес университет Беркли, реализовав протоколы стека в своей версии ОС UNIX. Широкое распространение ОС UNIX привело и к широкому распространению протокола IP и других протоколов стека. На этом же стеке работает глобальная сеть Internet.

Чем же можно объяснить широкое распространение и лидирующую роль стека TCP/IP?

В первую очередь, это объясняется следующими его свойствами:

9 это наиболее завершенный стандартный стек сетевых протоколов, имеющий многолетнюю

историю;

9 этот стек представляет собой набор открытых стандартов, которые могут быть свободно

использованы любым разработчиком;

9 практически все сети передают основную часть своего трафика с помощью протокола

TCP/IP, кроме того, это метод получения доступа к самой большой глобальной сети – Internet, то есть, этот стек является стандартом де-факто;

9 все современные операционные системы поддерживают стек TCP/IP.

Так как стек TCP/IP был разработан до появления модели OSI, то, хотя он также имеет многоуровневую структуру, соответствие уровней стека TCP/IP уровням модели OSI достаточно условно (не в последнюю очередь потому, что количество уровней в моделях различается) и в разных источниках может быть представлено по-разному.

Протоколы TCP/IP делятся на 4 уровня.

Самый нижний, четвертый уровень, условно соответствует физическому и канальному уровням модели OSI. Этот уровень в протоколах TCP/IP не регламентируется, но поддерживает все популярные стандарты физического и канального уровня, другими словами – любую Базовую Сетевую Технологию. Обычно при появлении новой технологии локальных или глобальных сетей она быстро включается в стек TCP/IP за счет разработки соответствующего RFC, определяющего метод инкапсуляции пакетов IP в ее кадры. Существует также мнение, что этот уровень можно ассоциировать с интерфейсом между вторым и третьим уровнем модели OSI, то есть, с единственным стандартизованным интерфейсом. На самом деле, в зависимости от точки зрения, оба взгляда можно считать верными, поскольку вопрос соответствия уровней – в значительной степени терминологический.

Следующий уровень, третий, –   это уровень межсетевого взаимодействия (буквальный перевод термина internet, который не следует путать с термином Internet с большой буквы, обозначающим самую большую составную сеть), занимающийся передачей пакетов с использованием различных технологий. Этому уровню полностью соответствует сетевой уровень модели OSI. В качестве основного протокола уровня в стеке используется протокол IP, который изначально проектировался как протокол передачи пакетов в составных сетях, состоящих из большого количества различных сетей, объединенных с помощью различных базовых сетевых технологий. Протокол IP является так называемым «дейтаграммным» протоколом, то есть он не обеспечивает  предварительную  установку  связи,  управление  потоком  данных,  не  гарантирует

доставку пакетов до узла назначения, но старается это сделать (этот метод доставки называется

«метод best effort»).

К уровню межсетевого взаимодействия относятся и все протоколы помогающие решить задачи маршрутизации в составных сетях – так называемые «протоколы динамической маршрутизации, такие как RIP, OSPF, BGP и другие, которые мы изучим позже, а также протокол межсетевых управляющих сообщений ICMP (Internet Control Message Protocol) применяющийся для диагностики сети и информирования об ошибках.

Следующий уровень (уровень II) называется основным, иногда – транспортным. На этом уровне функционируют протокол управления передачей TCP (Transmission Control Protocol) и протокол  пользовательских  дейтаграмм  UDP  (User  Datagram  Protocol).  Протокол  TCP обеспечивает надежную передачу сообщений между удаленными прикладными процессами за счет образования виртуальных соединений. Протокол UDP обеспечивает передачу прикладных пакетов дейтаграммным способом, как и IP, и выполняет только функции связующего звена между сетевым протоколом и многочисленными прикладными процессами. С точки зрения модели OSI этот уровень отчасти соответствует транспортному уровню, но наличие на основном уровне протокола UDP, который не выполняет функций надежной доставки (а вы помните, что это основная функция транспортного уровня модели OSI) делает это соответствие не совсем корректным. Кроме того, в зависимости от подхода, можно считать, что протокол TCP также не целиком соответствует транспортному уровню модели OSI, поскольку в его заголовке содержатся данные, благодаря которым организуются сеансы обмена данными между отправителем и получателем, а это, как вы помните, функции сеансового уровня OSI. Ничего страшного в этом несоответствии нет, если не считать путаницы, которая может образоваться в знаниях, если бездумно заучивать различные источники, не полностью соответствующие друг другу. На самом деле, с точки зрения OSI можно ассоциировать основной уровень TCP/IP как с транспортным и сеансовым уровнями OSI одновременно, так и ассоциировать его только с транспортным уровнем, который просто с помощью части данных заголовка предоставляет службы-провайдеры для сеансового уровня OSI. Вы спросите, почему нет строгого соответствия? Да просто потому, что установить взаимно однозначное четкое соответствие между двумя разными моделями невозможно.

Верхний  уровень,  первый,  называется  прикладным.  За  годы  использования  в  различных сетях в стеке TCP/IP было разработано большое количество протоколов прикладного уровня. К ним относятся такие широко используемые протоколы, как протокол копирования файлов FTP, протокол эмуляции терминала telnet, протокол передачи почты SMTP, клиентские почтовые протоколы, такие как POP3 и IMAP4, гипертекстовый протокол HTTP, протокол динамического конфигурирования хостов DHCP, протокол службы разрешения имен DNS, протокол управления сетью  SNMP  и  многие  другие.  Поскольку  в  дальнейшем  изучению  этих  протоколов  будет посвящен отдельный большой курс, подробно на них останавливаться мы сейчас не будем.

Теперь давайте попробуем изобразить графически состав стека протоколов:

Далее давайте составим графическое представление различных версий проекций уровней модели TCP/IP на уровни модели OSI.

Также может существовать модификация проекции, при которой уровень сетевых интерфейсов модели TCP/IP будет соответствовать интерфейсу между вторым и третьим уровнями модели OSI:

Теперь рассмотрим следующий стек протоколов, который в свое время занимал доминирующее положение среди остальных. Это стек IPX/SPX.

Этот стек является оригинальным стеком протоколов фирмы Novell, который она разработала  для  своей  сетевой  операционной  системы  NetWare  еще  в  начале  80-х  годов. Протоколы Internetwork Packet Exchange (IPX) и Sequenced Packet Exchange (SPX), которые дали имя стеку, являются прямой адаптацией протоколов XNS фирмы Xerox, которые были распространены в гораздо меньше степени, чем IPX/SPX. В 80-е годы и в начале 90-х протоколы IPX/SPX лидировали по количеству установок. Это было обусловлено тем, что сама ОС Novell NetWare занимала лидирующее положение с долей установок в мировом масштабе превышавшей

80%.  В связи с тем, что стек IPX/SPX являлся проприетарным (собственностью разработчика) его использование сторонними разработчиками было ограничено и от разработчиков требовалось приобретение лицензии. В это время на рынок вышел мощный конкурент – стек TCP/IP, который кроме открытости стандартов обладал еще рядом преимуществ, и популярность стека IPX/SPX пошла на убыль. В настоящее время этот стек практически не используется.

Семейство протоколов фирмы Novell и их соответствие модели OSI представлено на рисунке.

На верхнем уровне, соответствующем прикладному, представительному и сеансовому уровням OSI, работают протоколы NCP и SAP. Протокол NCP (NetWare Core Protocol) является протоколом взаимодействия сервера NetWare и оболочки рабочей станции.

C помощью этого протокола рабочая станция производит подключение к серверу, отображает каталоги сервера на локальные буквы дисководов, просматривает файловую систему сервера, копирует удаленные файлы, изменяет их атрибуты и т.п., а также осуществляет разделение сетевого принтера между рабочими станциями.   SAP (Service Advertising Protocol) – протокол объявления о сервисе – дает возможность сетевым устройствам обмениваться информацией об имеющихся сетевых сервисах. Серверы и маршрутизаторы используют SAP для объявления о своих сервисных услугах и сетевых адресах. Протокол SAP позволяет сетевым устройствам постоянно корректировать данные о том, какие сервисные услуги имеются сейчас в сети. При старте серверы используют SAP для оповещения оставшейся части сети о своих услугах. Когда сервер завершает работу, то он использует SAP для того, чтобы известить сеть о прекращении действия своих услуг.

Транспортному уровню модели OSI в стеке Novell соответствует протокол SPX, который осуществляет передачу сообщений с установлением соединений. Обратите внимание на интересную особенность реализации стека IPX/SPX – функционирование этого уровня в нем не является обязательным. Службы прикладного уровня могут обращаться непосредственно к сетевому уровню, на котором работает протокол IPX.

На  сетевом  уровне  в  стеке  IPX/SPX  кроме  протокола  IPX  также  работают  протоколы обмена маршрутной информацией RIP и NLSP. IPX является протоколом, который занимается вопросами адресации и маршрутизации пакетов в сетях Novell. Маршрутные решения IPX основаны на адресных полях в заголовке его пакета, а также на информации, поступающей от протоколов обмена маршрутной информацией. Например, IPX использует информацию, поставляемую либо протоколом RIP, либо протоколом NLSP (NetWare Link State Protocol) для передачи пакетов компьютеру назначения или следующему маршрутизатору. Протокол IPX поддерживает только дейтаграммный способ обмена сообщениями, за счет чего экономно потребляет вычислительные  ресурсы. Таким образом, протокол IPX обеспечивает выполнение трех функций: задание адреса, установление маршрута и рассылку дейтаграмм.

Особенности стека IPX/SPX обусловлены особенностями ОС NetWare, а именно ориентацией ее ранних версий (до 4.0) на работу в локальных сетях небольших размеров, состоящих из персональных компьютеров со скромными ресурсами. Поэтому Novell нужны были протоколы, на реализацию которых требовалось минимальное количество оперативной памяти (ограниченной в IBM-совместимых компьютерах под управлением MS-DOS 640 Кбайтами) и которые бы быстро работали на процессорах небольшой вычислительной мощности. В результате, ранние протоколы стека IPX/SPX хорошо работали в небольших локальных сетях, и значительно хуже – в глобальных сетях, так как слишком перегружали медленные связи широковещательными пакетами, которые интенсивно используются несколькими протоколами этого стека (например, для установления связи между клиентами и серверами). Этот недостаток стека также повлиял на его распространенность наряду с необходимостью получения лицензии на использование.

Перейдем к рассмотрению следующего популярного стека, который продолжает использоваться в наше время.

Стек NetBIOS/SMB появился в 1984 г., благодаря разработкам фирмы IBM, которая спустя три года после выпуска первого компьютера IBM PC, в целях расширения стандартных функций базовой системы ввода/вывода (BIOS) разработала программный интерфейс (API) NetBIOS – Network Basic Input/Output System. Это расширение применялось для взаимодействия между сетевыми ресурсами, но не предусматривало низкоуровневого протокола для передачи данных по сети. Такой протокол появился в 1985 г. и был объединен с NetBIOS в связке NetBEUI (NetBIOS Extended User Interface).

NetBEUI создавался в расчете на небольшие рабочие группы (до 255 узлов) и не имел функций маршрутизации.

Позже Microsoft выпустила дополнение – протокол SMB (Server Message Block), реализующий целый ряд высокоуровневых сервисов, таких как файловая служба, служба печати и передача сообщений между приложениями, и использующий для этого возможности NetBIOS.

Протокол SMB используется в операционных системах Windows. Он является проприетарным (закрытым) стандартом, и Microsoft предоставляет спецификации SMB только сертифицированным партнерам. SMB постоянно дорабатывается (обновления выходят с каждой новой версией Windows).

Стек NetBIOS/SMB и его проекцию на модель OSI можно изобразить так:

Как мы видим, в стеке NetBIOS/SMB отсутствуют все нижние уровни! И если к отсутствию специфицирования канального и физического уровня мы привыкли, то с отсутствием сетевого уровня сталкиваемся впервые. Возникает вопрос – хорошо это или плохо? Является ли данный стек «полноценным»? На самом деле «единственно правильного ответа» на этот вопрос не существует. Естественно, раз этот стек широко используется, то с ним все в порядке. Нужно понимать, что рассматривать термины «хорошо» и «плохо» нельзя абстрактно, не привязываясь к ситуации. Да, у стека нет сетевого уровня. Но давайте вспомним, зачем он вообще нужен? Этот уровень мы вводили для возможности объединения сетей, для того, чтобы стало возможным создавать сложные составные сети. А зачем нам сетевой уровень в локальных сетях? Ведь в локальных сетях маршрутизация не нужна, и протокол может работать поверх кадров канального уровня, экономя вычислительные ресурсы хостов! Вы спросите – а как быть, когда данные этого стека все  же нужно  будет маршрутизировать? И здесь решение напрашивается – эти данные можно маршрутизировать поверх любого сетевого протокола любого стека в качестве прикладных! То есть, мы видим, что такое построение стека обеспечивает значительную гибкость его применения. Например, в реализации данного стека в ОС Microsoft Windows включены обе возможности – можно использовать как передачу данных протокола непосредственно поверх канального уровня (NetBIOS over Frame, NetBF), так и поверх сетевого (NetBIOS over TCP/IP, NetBT).

Протокол NetBIOS работает на двух уровнях модели OSI: транспортном и сеансовом. NetBIOS может обеспечить сервис более высокого уровня, чем протоколы IPX и SPX, однако не обладает способностью к маршрутизации. NetBIOS не относится к сетевым протоколам в строгом смысле этого слова, хотя и содержит много полезных сетевых функций, которые можно отнести к сетевому  уровню.  Однако  с  его  помощью  невозможна  маршрутизация  пакетов,  так  как  в протоколе обмена кадрами NetBIOS не вводится такое понятие как сеть.

Протокол SMB, соответствующий прикладному и представительному уровням модели OSI, регламентирует взаимодействие рабочей станции с сервером. В функции SMB входят следующие операции:

9 Управление сессиями. Создание и разрыв логического канала между рабочей станцией и сетевыми ресурсами файлового сервера.

9 Файловый  доступ.  Рабочая  станция  может  обратиться  к  файл-серверу  с  запросами  на

создание и удаление каталогов, создание, открытие и закрытие файлов, чтение и запись в файлы,  переименование  и  удаление  файлов,  поиск  файлов,  получение  и  установку файловых атрибутов, блокирование записей.

9 Сервис печати. Рабочая станция может ставить файлы в очередь для печати на сервере и

получать информацию об очереди печати.

9 Сервис  сообщений.  SMB  поддерживает  простую  передачу  сообщений  со  следующими

функциями: послать простое сообщение; послать широковещательное сообщение; послать начало блока сообщений; послать текст блока сообщений; послать конец блока сообщений; переслать имя пользователя; отменить пересылку; получить имя машины.

Несмотря  на  коммерческий  статус  протокола  SMB,  существует  свободно распространяемый программный пакет Samba, обеспечивающий ограниченную поддержку сервисов SMB для ОС Unix/Linux. Поскольку основными протоколами Unix-систем являются протоколы стека TPC/IP, то в Samba для совместимости применяется NetBIOS over TCP/IP.

Автора: © Виталий Бочаров, Владимир Недеркин, Александр Трофимов

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете оставить ответ, или trackback с вашего собственного сайта.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100