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