 |
Сервер Информационных Технологий содержит море(!) аналитической информации |
Сервер поддерживается |
|---|
|
Сервер Информационных Технологий содержит море(!) аналитической информации |
Сервер поддерживается |
|---|
Предыдущие главы рассмотрели архитектурные основы межсетевого обмена, описали, как шлюзы маршрутизируют дейтаграммы Интернета между собой и ГВМ, и представили механизмы, используемые для отображения IP-адресов в физические сетевые адреса. Эта глава рассмотрит общую структуру программного обеспечения, находящегося в шлюзах и ГВМ, которое решает задачу сетевого взаимодействия. Она опишет общий принцип разделения на уровни, покажет, как это разделение делает программное обеспечение Межсетевого Протокола легче для понимания и построения, и проследит путь дейтаграмм через протокольное программное обеспечение, который они проходят при передаче через интернет TCP/IP.
Мы уже говорили, что протоколы позволяют специфицировать или понимать взаимодействие, не зная детали сетевого оборудования конкретного производителя. Они являются для компьютерного взаимодействия тем же самым, чем являются языки программирования для вычислений. Теперь вам должно быть понятно, насколько верна эта аналогия. Как язык ассемблера, некоторые протоколы описывают взаимодействие по физической сети. Например, детали формата кадра Etherneta, политика доступа к сети, обработка ошибок в кадрах вместе составляют протокол, описывающий взаимодействие по Ethernetу. Аналогично, детали IP-адресов, формат дейтаграммы, понятие ненадежной доставки, без установления соединения составляют Межсетевой Протокол.
Сложные системы передачи данных не используют один протокол для решения всех задач передачи. Вместо этого, им требуется набор взаимодействующих протоколов, иногда называемый семейством протоколов или стеком протоколов. Чтобы понять почему это так, перечислим ошибки, которые могут возникнуть, когда машины взаимодействуют по сети данных.
Собранные воедино, эти проблемы подавляют. Трудно понять, как написать один протокол, которые бы обрабатывал их всех. По аналогии с языками программирования мы можем выбрать способ, как справиться с таким уровнем сложности. Трансляция программ делится на четыре концептуальных этапа, выделяемые по именам запускаемых программ: компилятор, ассемблер, компоновщик и загрузчик. Такое деление позволяет разработчику сосредотачиваться в каждый момент времени на одной проблеме, а программисту писать и тестировать каждый модуль ПО независимо от других.
Два последних наблюдения из нашей аналогии с языками программирования помогут вам уяснить организацию протоколов. Во-первых, ясно, что части транслируемого ПО должны согласовать формат данных, передаваемых между ними. Например, данные, передаваемые от компилятора ассемблеру, состоят из программы на языке ассемблера. Поэтому, мы видим, как процесс трансляции включает несколько языков программирования. Эта аналогия применима к коммуникационному ПО, где мы видим, что несколько протоколов определяют интерфейсы между модулями коммуникационного ПО. Во-вторых, четыре части транслятора образуют линейную последовательность, в которой выход компилятора становится входом для ассемблера, и т.д. Протокольное ПО также использует линейную последовательность.
Представляйте себе, что модули протокольного ПО
на каждой машине как бы поставлены друг на друга и находятся
на разных уровнях, как на рисунке 10.1 Каждый уровень отвечает
за одну из частей большой проблемы.
----------------- -----------------
| ОТПРАВИТЕЛЬ | | ПОЛУЧАТЕЛЬ |
|---------------- |----------------
| Уровень n | | Уровень n |
|---------------| |---------------|
| .... | | .... |
|---------------| |---------------|
| Уровень 2 | | Уровень 2 |
|---------------| |---------------|
| Уровень 1 | | Уровень 1 |
|_______________| |_______________|
| ^
| |
---V--------------------------|---
| СЕТЬ |
----------------------------------
Концептуально, посылка сообщения от прикладной программы на одной машине к прикладной программе на другой машине означает последовательную передачу сообщения вниз через соседние уровни протокольного ПО на машине получателя, передачу сообщения по сети и передачу сообщения вверх через соседние уровни протокольного ПО на машине получателя.
На практике, протокольное ПО гораздо более сложное, чем это может показаться на основании рисунка 10.1. Каждый уровень принимает решение о корректности сообщения и выбирает соответствующее действие на основании типа сообщения или адреса назначения. Например, один из уровней на принимающей машине должен решить, оставить сообщение или передать его дальше другой машине. Другой уровень должен решить, какая прикладная программа должна принять сообщение.
Чтобы понять разницу между концептуальной
организацией протокольного ПО и деталями реализации,
рассмотрим их сопоставление, показанное на рисунке 10.2.
Концептуальная диаграмма на рисунке 10.2а показывает Межсетевой
уровень между высокоуровневым протокольным уровнем и
уровнем сетевого интерфейса. Реальная диаграмма на рисунке
10.2б показывает, что ПО IP может взаимодействовать с несколькими
модулями протоколов высокого уровня и с несколькими сетевыми
интерфейсами. Хотя диаграмма концептуального разделения протоколов
на уровни не показывает все детали, она помогает объяснить
базовые идеи. Например, рисунок 10.3 показывает уровни протокольного
ПО, используемые сообщением, пересекающим три сети. Диаграмма
показывает только уровни интерфейса с сетью и Межсетевого
Протокола в шлюзах, так как только эти уровни требуются
при получении, маршрутизации и отправке дейтаграмм. Мы понимаем,
что любая машина, присоединенная к двум сетям, должна иметь
два модуля интерфейса с сетью, хотя диаграмма концептуального
разделения на уровни показывает только один уровень интерфейса
с сетью в каждой машине.
---------------------- ------------ ------------ ------------
| уровень протоколов| |Протокол 1| |Протокол 2| |Протокол 3|
| высокого уровня | ---------\-- -----|------ --/---------
---------------------- \ | /
| уровень межсетево-| \ -----|------ /
| го протокола | |Модуль IP |
---------------------- / ------------\
| уровень интерфейса| / | \
| с сетью | ------------ ------------ ------------
---------------------- |Интерфейс1| |Интерфейс2| |Интерфейс3|
(а) ------------ ------------ ------------
(б)
Как показывает рисунок 10.3, отправитель на исходной
машине передает сообщение, которое уровень IP помещает в дейтаграмму
и посылает по сети 1. На промежуточных машинах дейтаграмма
передается вверх до уровня IP, который отправляет ее обратно вниз
и из машины( в другую сеть). Только когда она достигает конечного
назначения, машина заставляет IP выделить сообщение и передать
его на верхние уровни протокольного ПО.
------------- ------------- ------------- -------------
|Отправитель| | | | | |Получатель |
| | | | | | | | ^ |
------V------ | | | | ------|------
| другие ...| | | | | | другие ...|
------------- ------------- ------------- -------------
| Уровень IP| |Уровень IP| | Уровень IP| | Уровень IP|
------------- ------------- ------------- -------------
| Интерфейс | | Интерфейс| | Интерфейс | | Интерфейс |
---------|--- -^-------|-- --^--------|- ---^---------
| | | | | |
--V------| -V------|- V------|--
/ \ / \ / \
| Сеть 1 | | Сеть 2 | | Сеть 3 |
\ / \ / \ /
---------- ---------- ----------
Раз принято решение разделить задачу взаимодействия на подзадачи и организовать протокольное ПО в виде модулей, каждый из которых решает одну из подзадач, возникает вопрос: "какие возможности должен обеспечивать каждый модуль ?". На этот вопрос нелегко ответить по нескольким причинам. Во-первых, при заданном наборе целей и ограничений, приводящем к специфической задаче взаимодействия, можно выбрать организацию, оптимизирующую протокольное ПО для этой конкретной задачи. Во-вторых, даже при рассмотрении общих сервисов сетевого уровня, таких как надежная транспортировка, можно выбрать один из нескольких принципиально отличающихся друг от друга подходов для решения этой задачи. В-третьих, разработка сетевой( или межсетевой) архитектуры и организация протокольного ПО не связаны между собой; можно разрабатывать одно в отрыве от другого.
В этой области доминируют две идеи относительно
разделения протоколов на уровни. Первая, основывающаяся
на работе, проделанной Международной Организацией по Стандартизации(МОС),
известной как Справочная Модель ВОС Взаимодействия Открытых
Систем, часто называется моделью ВОС. Модель ВОС, содержащая семь
концептуальных уровней, организована так, как показано на рисунке
10.4.
Уровень Возможности
---------------------------
7 | Прикладной |
| |
---------------------------
6 | Представительный |
| |
---------------------------
5 | Сеансовый |
| |
---------------------------
4 | Транспортный |
| |
---------------------------
3 | Сетевой |
| |
---------------------------
2 | Канальный |
| (аппаратный интерфейс) |
---------------------------
1 | Физический |
| |
---------------------------
Модель ВОС, созданная для описания протоколов одной сети, не содержит специального уровня для межсетевой маршрутизации, имеющегося в стеке протоколов TCP/IP.
Схема разделения на уровни ВОС, хотя и разрабатывалась как концептуальная модель, а не руководство для реализаций, является основой для нескольких реализаций протоколов. Среди протоколов, связанных с моделью ВОС, набор протоколов, известный как Х.25, является вероятно самым популярным и широко используемым. Х.25 был создан как рекомендация Международного Консультативного Комитета по Телефонии и Телеграфии( МККТТ), международной организации, вырабатывающей стандарты для международных телефонных служб. Х.25 используется сетями передачи данных общего пользования в Европе и США.
С точки зрения Х.25, сеть работает во-многом аналогично телефонной системе. Как и ARPANET, описанный в главе 2, сеть Х.25 предполагается состоящей из сложных коммутаторов пакетов, имеющих достаточную интеллектуальность, чтобы маршрутизировать пакеты. ГВМ не присоединены напрямую к каналам сети. Вместо этого каждый ГВМ присоединен к одному из коммутаторов пакетов, используя последовательную линию взаимодействия. Можно сказать и по-другому, то есть что соединение между пакетным коммутатором Х.25 и ГВМ - миниатюрная сеть, состоящая из одной последовательной линии. ГВМ должен использовать довольно сложную процедуру для передачи пакетов в сеть.
Самый широко используемый протокол уровня 2, имеющий название Высокоуровневое Взаимодействие по Каналу Данных, известен по его аббревиатуре - HDLC. Существует несколько версий HDLC, из которых самая последняя имеет название - HDLC/LAPB. Важно помнить, что успешная передача на уровне 2 означает, что кадр был передан сетевому коммутатору пакетов для доставки; она не гарантирует, что пакетный коммутатор примет пакет, или сможет переправить его для доставки.
Вторая основная модель разделения протоколов на уровни не была разработана комитетом по стандартам, а появилась в результате исследований, приведших к появлению стека протоколов TCP/IP. После небольшой доработки модель МОС может быть приспособлена для описания схемы деления на уровни в TCP/IP, но базовые предпосылки этих схем сильно различаются, что позволяет говорить об их различии.
На концептуальном уровне ПО TCP/IP организовано
в виде 4 уровней, опирающихся на пятый уровень оборудования.
Рисунок 10.5 показывает концептуальные уровни, а также форму,
в которой передаются данные между ними.
Концептуальный уровень Объекты, передаваемые
между уровнями
-----------------
| Прикладной |
| |
----------------- <---------Сообщения или потоки
| Транспортный |
| |
----------------- <---------Пакеты транспортного
| Межсетевой | протокола
| |
----------------- <---------Дейтаграммы IP
| Интерфейс с |
| сетью |
----------------- <---------Кадры конкретной сети
. Оборудование .
. .
.................
Существует два тонких и важных различия между схемой разделения на уровни TCP/IP и Х.25. Первое различие связано с надежностью, в то время как второе - с местонахождением интеллектуальных функций в системе.
Одно из основных различий между протоколами TCP/IP и Х.25 состоит в их подходах к обеспечению сервиса надежной пердачи данных. В модели Х.25 протокольное ПО обнаруживает и обрабатывает ошибки на всех уровнях. На канальном уровне сложные протоколы гарантируют, что передача между ГВМ и пакетным коммутатором, к которому он присоединен, будет корректной. К каждому передаваемому элементу данных присоединяется контрольная сумма, и получатель подтверждает каждый принятый кусок данных. Протокол канального уровня включает таймаут и алгоритм повторной передачи, защищающие от потери данных и обеспечивающие автоматическое восстановление после сбоев или рестартов оборудования.
Следующие уровни Х.25 обеспечивают свою надежность. На уровне 3 Х.25 также обеспечивает обнаружение ошибок и восстановление после них для пакетов, передаваемых по сети, используя контрольные суммы, а также технологии таймаута и повторной передачи. Наконец, уровень 4 должен обеспечивать межконцевую надежность, заставляя при этом место конечного назначения проверять доставку.
В отличие от этой схемы TCP/IP основывает свое разделение на уровни на том, что надежность - это межконцевая проблема. Философия архитектуры проста: создать интернет таким, чтобы он мог управляться с ожидаемой загрузкой, и позволить отдельным каналам или машинам терять данные или искажать их, не пытаясь исправлять ошибки. Фактически, большая часть ПО TCP/IP уровня интерфейса с сетью не обеспечивает надежности. Вместо этого, большинство ошибок обрабатывает транспортный уровень.
Освобождение уровня интерфейса от верификации делает ПО TCP/IP более легким для понимания и реализации. Промежуточные шлюзы могут отбрасывать дейтаграммы, ставшие испорченными из-за ошибок передачи. Они могут отбрасывать любые дейтаграммы, которые не могут быть доставлены. Они могут отбрасывать дейтаграммы, когда скорость их поступления превышает пропускную способность машины. Они могут посылать дейтаграммы по другим путям с меньшей или большей задержкой, не информируя об этом источник или назначение.
Наличие ненадежных каналов означает, что некоторые дейтаграммы не дойдут до назначения. Обнаружение и восстановление после потери дейтаграмм выполняется между источником и назначением, и поэтому называется межконцевой верификацией. Межконцевое ПО, находящееся на транспортном уровне, использует контрольные суммы, подтверждения и таймауты для управления передачей. Поэтому, в отличие от разделения на уровни в Х.25, ориентированного на соединения, ПО TCP/IP помещает большую часть управления надежностью на один уровень.
Другое различие между моделью Х.25 и TCP/IP появляется при определении местонахождения средств управления работой. Как правило, в сетях, использующих Х.25, подразумевается, что сеть - это утилита, обеспечивающая транспортное средство. Производитель, предоставляющий средство, управляет доступом к сети и следит за траффиком для учета работы пользователей. Поставщик сетевого сервиса решает такие проблемы, как маршрутизация и управление потоком внутренним образом, делая процесс передачи данных надежным. При таком подходе на долю ГВМ мало что остается. Короче говоря, сеть - это сложная, независимая система, к которой могут присоединяться относительно простые ГВМ; сами ГВМ мало участвуют в работе сети.
В отличие от этого, TCP/IP требует от ГВМ участия почти во всех сетевых протоколах. мы уже упомянули, что ГВМ активно учствуют в межконцевом обнаружении ошибок и восстановлении после них. Они также принимают участие в маршрутизации, так как они должны выбрать шлюз при посылке дейтаграммы, и они участвуют в управлении сетью, так как они должны обрабатывать управляющие сообщения ICMP. Поэтому, при сравнении с сетью Х.25, интернет TCP/IP может рассматриваться как относительно простая система доставки пакетов, к которой присоединены интеллектуальные ГВМ.
Независимо от конкретной используемой схемы разделения на уровни, или функций уровней, работа протоколов, разнесенных по уровням, основывается на одной фундаментальной идее. Эта идея, называемая принципом разделения на уровни, может быть описана следующим образом:
Протоколы, разнесенные по уровням, разрабатываются таким образом, что назначение на уровне N получает точно такой объект, который был послан отправителем на уровне N.
Принцип разделения протоколов на уровни объясняет, почему разделение на уровни - такя мощная идея. Она позволяет разработчику протоколов последовательно сосредотачивать свое внимание на одном из урвоней, не заботясь при этом о работе других уровней. Например, при создании приложения передачи файлов, разработчик думает только о двух копиях прикладной программы, функционирующих на двух машинах, концентрируется на сообщениях, которыми нужно обменяться при передаче файлов. Разработчик предполагает, что приложение на одной ГВМ принимает точно то, что ему посылает приложение на другой ГВМ.
Рисунок 10.6 иллюстрирует, как работает принцип разделения
на уровни:
ГВМ А ГВМ В
----------------- -----------------
| Прикладной | | Прикладной |
| | идентичное | |
----------------- сообщение --------^--------
| <---------------------------------------->|
-------V--------- --------|--------
| Транспортный | | Транспортный |
| | идентичный | |
----------------- пакет --------^--------
| <---------------------------------------->|
-------V--------- --------|--------
| Межсетевой | | Межсетевой |
| | идентичная | |
----------------- дейтаграмма --------^--------
| <---------------------------------------->|
-------V--------- --------|--------
| Интерфейс с | | Интерфейс с |
| сетью | идентичный | сетью |
------------\---- кадр --^--------------
\ <-------------------------->/
\ /
-V--------------------------/-
/ Физическая сеть /
/ /
------------------------------
Наше определение принципа разделения на уровни несколько туманно, а иллюстрация на рисунке 10.6 упускает важный вопрос, так как она не делает различия между передачей от источника до конечного назначения и передачей через несколько сетей. Рисунок 10.7 иллюстрирует это различие, показывая путь сообщения, посланного прикладной программой на одной ГВМ к приложению на другой ГВМ через шлюз.
Как показывает рисунок, доставка сообщений использует
два различных сетевых кадра: один для передачи между ГВМ А и
шлюзом Ш, а другой - между шлюзом Ш и ГВМ В. Принцип разделения
сети на уровни устанавливает, что кадр, доставляющийся к Ш,
совпадает с кадром, посланным А. Но прикладной и транспортный
уровни имеют дело с межконцевой пересылкой и разработаны
так, чтобы ПО источника могло взаимодействовать с конечным
назначением. Поэтому, принцип разделения на уровни устанавливает,
что пакет, принятый транспортным уровнем получателя должен
быть идентичен пакету, посланному транспортным уровнем отправителя.
ГВМ А ГВМ В
----------------- -----------------
| Прикладной | | Прикладной |
| | идентичное | |
----------------- сообщение --------^--------
| <------------------------------------------>|
-------V--------- --------|--------
| Транспортный | | Транспортный |
| | идентичный | |
----------------- пакет --------^--------
| <------------------------------------------>|
-------V--------- Шлюз Ш --------|--------
| Межсетевой | ----------------- | Межсетевой |
| | | Межсетевой | | |
----------------- | | --------^--------
| --^---------|---- |
-------V--------- | | --------|--------
| Интерфейс с | --|---------V---- | Интерфейс с |
| сетью | | Интерфейс с | | сетью |
---------|------- | сетью | -----^-----------
| ---^--------|---- |
-----V---------- | | ------------|----
/Физическая сеть/----/ \--->/Физическая сеть/
/ 1 / / 2 /
---------------- -----------------
Легко понять, что на верхних уровнях принцип разделения на уровни применим к межконцевым передачам, и что на самом нижнем уровне применим к передаче между двумя машинами.
Назад | Содержание | Вперед