Семиуровневая модель OSI/ISO и стек протоколов TCP/IP: исследование взаимоотношения и интерпретации

УДК 004.72

Seven-layer OSI / ISO model and TCP / IP stack protocols: research of the relationship and interpretation

Kruchinin Sergey Vladimirovich - candidate of Political Science, "Wellborn" LLC., candidate

for a degree of Doctor of Technical Sciences

Abstract. The article deals with a problem of comparing the theoretical seven-layer OSI / ISO model and practically used stack protocols of network services. We have proposed an approach that allows to compare the practical protocols and nominal levels of model OSI / ISO by maximally closing of meaning of the model levels and practical functionality of used protocols.

Keywords: OSI / ISO, reference model for open systems interconnection (RMOSI), TCP / IP, the protocol stack, MIME.

Семиуровневая модель OSI/ISO и стек протоколов TCP/IP: исследование взаимоотношения и интерпретации

Кручинин Сергей Владимирович - кандидат политических наук, ООО "ВЭЛБОРН", соискатель ученой степени доктора технических наук.

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

Ключевые слова: OSI/ISO, ЭМВОС, TCP/IP, стек протоколов, MIME.

Актуальность. Эталонная модель взаимодействия открытых систем (ЭМВОС), более известная как модель стека сетевых протоколов OSI/ISO стала фактическим стандартом, применяемом в обучении, документации, теоретических рассуждениях. При этом ЭМВОС справедливо критикуется за недостаточную гибкость и не полное соответствие реалиям современных технологий передачи данных, за ее теоретический характер. Общеизвестно, что на практике используемый стек сетевых протоколов TCP/IP не соответствует модели ЭМВОС, хотя и существуют спекулятивные варианты их соотношения и сопоставления. Э. Таненбаум отдельно останавливается как на критике модели ЭМВОС [1, c. 66-69], так и на критике стека сетевых протоколов TCP/IP [1, c.69], в результате предлагая собственную модель, включающую пять уровней [1, c.64], имеющих то или иное сопоставление с моделями ЭМВОС и TCP/IP. См. табл. 1.

Таблица 1. Сетевые модели по Э. Таненбауму

ЭМВОС (081/180) TCP/IP Э. Таненбаум

Прикладной Прикладной Прикладной

Уровень представления

Сеансовый

Транспортный Транспортный Транспортный

Сетевой Межсетевой Сетевой

Передачи данных От хоста к сети Передачи данных

Физический Физический

Свою модель Э. г "аненбаум обозначил как «гибридная», признав,

что модель OSI чрезвычайно полезна при обсуждении компьютерных сетей, а сила модели TCP/IP - реализованные протоколы, используемые и хорошо зарекомендовавшие себя на протяжение многих лет. Таким образом, так или иначе приходится работать с двумя моделями, используя на практике TCP/IP, а в обсуждениях и документации ЭМВОС. Попытку совместить модели предпринял Э. Таненбаум, уменьшив число уровней с 7 до 5.

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

Проведение исследования.

Наша цель - построить семиуровневую модель, соответствующую реалиям современных технологий передачи данных, как протоколов TCP/IP, так и учитывая современные технологии, такие как HTML5 и протоколы шифрования. Оставаясь в рамках формальных наименований уровней ЭМВОС, мы попытаемся найти соответствия существующих протоколов данным уровням. Начнем с верхних двух уровней, прикладного и представления.

В [2] мы сделали предположение, что такие протоколы, как HTTP, SMTP, традиционно относимые к уровню прикладному, следует относить к уровню представления, а к протоколам прикладного уровня следует относить ориентированные на прикладные программы MIME/TYPE. Текст, или видео, или формат графического файла, он может быть передан и через HTTP, и через SMTP, таким образом, мы наблюдаем вложенность протоколов и стандартизацию передаваемого контента, так как HTTP и SMTP при таком подходе выполняют промежуточную функцию контейнера, отдавая данные для отображения прикладному программному обеспечению.

Далее следуют сеансовый и транспортный уровень, которые в рамках стека TCP/IP трудно разнести, так как два протокола уровня UDP и TCP с одной стороны относятся к транспортному уровню, с дру-

гой, протокол TCP устанавливает сеансовое соединение. Кроме того, существует ряд технологий, когда данные передаются одним потоком, а контролирует передачу другой поток, при этом протокол контроля также может быть отнесен к сеансовым (например, SIP). Помимо этого, в [2] мы ответили, что в какой-то степени роль протокола организации сеанса играет и DNS, потому как без установления соответствия доменного имени и IP-адреса организация сеанса связи в подавляющем большинстве случаев не возможна.

Проблема соотношения транспортного и сеансового протокола решается, если протокол системы передачи данных, устанавливающий соединение, использует как протокол более низкого уровня UDP [3,4]. В этом случае соотношение протоколов становится прозрачным, но для большинства сетей, использующих TCP/IP ситуация принципиально иная.

Можно попробовать разделить протоколы на транспортные и сеансовые, воспользовавшись «виртуальным разделением», основываясь на схожести заголовков пакетов протоколов TCP, UDP и SCTP [5]. Рассмотрим заголовки этих протоколов (таблицы 2а, 2б, 2в).

Таблица 2А. Структура заголовка протокола UDP

Биты 0 - 15 16 - 31

+0 Порт отправителя Порт получателя

32 Длина датаграммы Контрольная сумма

64 Данные

Таблица 2Б. Заголовки протокола SCTP

Биты 0 - 7 8 - 15 16 - 23 24 - 31

+0 Порт отправителя Порт получателя

32 Тег проверки

64 Контрольная сумма

96 Тип 1 блока Флаги 1 блока Длина 1 блока

128 Данные 1 блока

Тип N блока Флаги N блока Длина N блока

Данные N блока

Таблица 2В. Заголовок п ротокола TCP

Биты 0 - 3 4 - 9 10 - 15 16 - 31

+0 Порт отправителя Порт получателя

32 Порядковый номер

64 Н омер подтверждения

96 Длина заголовка Зарезервировано Флаги Размер окна

128 Контрольная сумма Указатель важности

160 Опции

160/192+ Данные

Несмотря на определенную похожесть (отправитель, получатель, дополнительная информация, данные), достоверно общая часть только поля отправитель (source) и получатель (destination) Если условно считать общий участок (заголовок SRC/DST) за «виртуальный» протокол, мы можем получить условное соответствие модели ЭМВОС.

Так для протокола СПД (системы передачи данных, устанавливающего соединение), реализованного поверх ИБР, вложенность будет следующей: ____

Заголовок фрейма Заголовок IP-пакета UDP SRC/DST СПД Данные

а для TCP/IP:

Заголовок фрейма Заголовок IP-пакета SRC/DST TCP Данные

Данный метод сопоставления выглядит искусственно, потому мы предложим еще два.

Один из вариантов состоит в том, что фактически в настоящее время сеанс устанавливается на уровне клиентского приложения. Это может быть технология HTML5 или Flash, которая уже используя разные форматы файлов (HTML, jpeg, json) и протоколы (HTTP, Web Socket) создает единую среду веб-приложения. Таким образом, если перенести уровень сеанса с 5 на 7 уровень и обозначить уровнем приложений, мы формально решим семиуровневую задачу. При этом сеанс реализуется на самом верхнем уровне, через механизмы авторизации и куки (cookies). Подробный подход требует пересмотра назначения всех уровней с 5 по 7. См. табл.3.

Таблица 3. Вариант семиуровневой модели с «уровнем приложения»

Уровень Примеры

7 Уровень веб-приложения HTML5, Flash

6 Уровень веб-компонентов HTML, JPEG, MPEG, JSON

5 Уровень передачи SMTP, HTTP

4 Уровень транспорта TCP, UDP, SCTP

3 Сетевой уровень IPv4, IPv6

2 Канальный уровень MAC

1 Физический уровень 802.3, 802.11

Недостатком подобного подхода является то, что модель ЭМВОС перестала «соблюдаться», хотя формально и осталось семь уровней модели.

Рассмотрим тогда еще один подход. Он базируется на текущем переходе к защищенным соединениям, и, в частности, на замене HTTP на HTTPS.

Фактически же HTTPS это HTTP, инкапсулированный в SSL или

TLS.

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

Таблица 4. Вариант семиуровневой модели с «уровнем приложения»

Уровень Примеры

Веб-приложение HTML5, Flash

7 Прикладной уровень MIME-типы: HTML, JPEG, MPEG, JSON

6 Уровень представления HTTP, Web Socket, SMTP

5 Сеансовый уровень SSH, SSL, TLS

4 Уровень транспорта TCP, UDP, SCTP

3 Сетевой уровень IPv4, IPv6

2 Канальный уровень MAC

1 Физический уровень 802.3, 802.11

Выводы:

Таким образом, мы предложили семиуровневую модель, соотносимую с моделью ЭМВОС (OSI/ISO). Это удалось благодаря перераспределению протоколов прикладного уровня/уровня представления. На прикладной уровень вынесены ориентированные на приложения протоколы, форматы файлов (HTML, CSS, text, JPEG, MPEG, json и т.д.). На уровень представления условно вынесены «transfer protocols» (HTTP

- HyperText Transfer Protocol, SMTP - Simple Mail Transfer Protocol). Место протоколов сеансового уровня заняли протоколы обеспечения безопасности, SSL, TLS.

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

Библиографический указатель:

1. Таненбаум Э., Уэзеролл Д. Компьютерные сети. 5-е изд. -СПб.: Питер, 2012. - 960 с.

2. Кручинин С.В. Стеки сетевых технологий TCP/IP и OSI/ISO // Вопросы науки [Современные технологии и технический прогресс. Сборник статей по материалам Международной научно-практической конференции 16 апреля 2015 г. Воронеж], 2015, Т.3. с.145-147

3. Кручинин С.В., Лазарев В.В. Программа настройки ПО СТ //Свидетельство о регистрации программы для ЭВМ № 2011618880, 15.11.2011. Москва. Федеральная служба по интеллектуальной собственности, патентам и товарным знакам.

4. Пономарев М.П. Телекоммуникационный сервер ЕСУ ТЗ//Свидетельство о государственной регистрации программы для ЭВМ №2011618939, 27.09.11. Москва. Федеральная служба по интеллектуальной собственности, патентам и товарным знакам.

5. http://www.protocols.ru/files/RFC/rfc3286.pdf

Статья поступила в редакцию 9.06.2015 г.