Интерпретация модели ЭМВОС применительно к стеку TCP/IP

004.72

Интерпретация модели ЭМВОС применительно к стеку TCP/IP

Кручинин С.В.

ООО «ВЭЛБОРН», г. Воронеж

Аннотация. В статье представлена интерпретация модели ЭМВОС применительно к существующей практике. Разобраны некоторые неоднозначности при сопоставлении моделей ЭМВОС и DOD. Представлена интерпретация представительского и сеансового уровней.

Ключевые слова: ЭМВОС, представительский уровень, сеансовый уровень.

OSI reference model interpretation in the relation on TCP/IP stack

Kruchinin S.V.

Wellborn LLC, Voronezh, Russia

Abstract. Author gives the OSI model interpretation in the relation on the DOD model, which is the implemented by TCP/IP stack. Author discuses some ambiguity in the comparison of OSI and DOD models. Author gives the interpretation of presentation and session level.

Keywords: OSI/ISO, OSI, DOD, TCP/IP, SSL, TLS, MIME-types.

Существует известная неоднозначность в интерпретации модели OSI/ISO (Open System Interconnection Reference Model, ЭМВОС - эталонной модели взаимодействия открытых систем) применительно к протоколам стека TCP/IP.

При этом, в целом, соотношение протоколов сетевого и транспортного уровней, как правило более-менее можно считать устоявшимся [1,12]. Наиболее проблематичным является уровень представления. Впрочем, при глубоком анализе данной проблемы можно найти неоднозначности и в трактовке и протоколов сетевого уровня.

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

разных протоколов. Например, вебинарная комната может использовать протокол HTTP (поверх TLS и TCP) для вывода веб-интерфейса, и RTP (поверх UDP) для передачи потоковых данных (речь, видео, демонстрация рабочего стола, являющаяся в общем случае тоже видео-потоком) [2,5,6].

Рассмотрим уровень представления. Наиболее неоднозначный уровень с точки зрения соотнесения с оным протоколов стека TCP/IP. Иногда с представительским уровнем соотносят протоколы SSL (secure socket layer) и TLS (transport layers security), что на наш взгляд, не верно, и методологически не корректно. Дело в том, что изначально представительский уровень предназначен для того, чтобы решать задачи переконвертации между машинами разных архитектур и способов представления информации. В частности, например, если один абонент использует Linux и кодировку koi8-r, а другой Windows и кодировку CP-1251, оба абонента должны видеть идентичный документ, благодаря во-первых, перекодировке из CP-1251 в некую сетевую (пусть даже UTF8), а затем в koi8-r и обратно, а во вторых, при доставке сообщения на Linux машину необходимо текстовые документы приводить к способу перевода строки указанием символа \n, а на Windows - к способу \r\n.

Ни SSL, ни TLS таких вопросов не решает. Давайте рассмотрим, какие действия на самом деле можно соотнести с представительским уровнем.

Во-первых, в наибольшей степени духу модели OSI/ISO соответствует преобразования порядка байт, выполняемое сетевыми проиложе-ниями.

Приложения (как правило, модули ядра или работающии с ним компоненты соответствующих сетевых драйверов) выполняют вызовы функций htons() либо htonl() - преобразования локального порядка байт в сетевой, и ntohs() либо ntohl() - преобразование порядка байт из сетевого в локальный. Так, если архитектура процессора использует Little-Endian (например Intel x86) то htonl() преобразует байты в Big-Endian (сетевой порядок байт), и обратно. Для процессора, который использует Big-Endian, функции не произведут никаких действий, но благодаря их наличию будет возможна кросс-компиляция. Как правило, преобразования порядка байт выполняются на сетевом-канальном уровнях, что не соответствует модели OSI. К этому же вопросу относится способ определения порядка байт в кодировках UTF, символ BOM (Byte Order Mark, в разных вариациях для разных кодировок, например, FEFF в UTF-16), но решается данный вопрос уже на прикладном уровне.

Во-вторых, к представлению также относятся способы задания кодировок. По смыслу OSI/ISO кодировки и должны соотноситься с ше-

стым уровнем. Т.е. приложения получают данные уже в «родной кодировке». Однако, на практике это совсем не так, и дело обстоит даже с точностью наоборот.

В стеке TCP/IP для маркировки кодировки изначально не нашлось места. Были попытки использовать для этой цели префиксов доменных имен (www для CP-1251, www-koi8-r для КОИ-8). Попытка неудачная, и ушедшая в прошлое, хотя некоторые сервера DNS до сих пор поддерживают указанные субдомены, впрочем, веб-сервера переадресуют с указанных хостов на традиционные (без www и иных префиксов, маркирующих кодировки или службы). Следу данной эпохи можно найти в поисковой выдачи, кешах поисковой выдачи и сайтах Архива Интернет.

Также, способ задания кодировки был указан и в HTML в виде META-тегов.

Пример:

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

HTML не входит в состав протоколов, являясь форматом файла, хотя на наш взгляд именно HTML и можно было бы отнести к протоколу прикладного уровня, в отличие от HTTP, как раз решающего задачи представления данных, и более того, самого служащего транспортом для таких протоколов как RPC (Remote Procedure Call), XML-RPC, JSON-RPC, SOAP, различные реализации REST.

В настоящее время указание кодировки решается протоколом HTTP.

Пример:

Content-type: text/html; charset=utf-8

Помимо указания кодировке используются MIME-типы для указания типов документа.

На наш взгляд, как раз это и есть та самая реализация уровня представления. Т.е. протокол HTTP (и аналогичные) действительно указывает способ кодирования и тип данных прикладного приложения. Так image/jpeg укажет, что кодируется картинка, тип application/msword укажет передать содержимое приложению Microsoft Word.

Таким образом, text/html, image/jpeg, application/msword и являются форматами(протоколами) прикладного уровня, а те протоколы, которые работают с данными пользователя (smtp, pop, http, ftp) фактически являются протоколами представления. Впрочем, возможна и обратная интерпретация, обозначить прикладные протоколы по традиции прикладными, но перенести на шестой уровень, а седьмой уровень обозначить представительским и включить в него все разнообразие MIME-типов.

Протоколы же системного характера, такие как DNS, DHCP, протоколы маршрутизации на наш взгляд следует считать не самостоятельными прикладными протоколами, (хотя они технически такими являются

и работают поверх транспортного, а то и секьюроного - в нашей терминологии - уровня) а частью соответствующих механизмов, например, из состава IPv4 (наряду с ICMP и ARP).

Таким образом в семейство IPv4 входят собственно протокол IPv4, ICMP, ARP, DHCP (для назначения IPv4 адресов, DNS - записи типа A, для получения по доменному имени IPv4 адреса, протоколы маршрутизации [3], IGMP и механизм AnyCast для IPTV[9]).

В семейство IPv6 входят собственно сам протокол IPv6, ICMPv6 (решает задачи ICMP и ARP), DHCPv6, DNS и DNSSEC - записи AAAA).

IPv5 в данном случае мы рассматривать не будем (его развитие ST, ST-II, MPLS) - отдельная тема [11]. Тоже касается и IPX (который интересен реализацией некоторых транспортных возможностей на сетевом уровне, фактически сетевой уровень IPX соответствует протоколу UDP).

Итак, мы разобрали седьмой и шестой уровень, которые решают задачи прикладного доступа и представления информации. Как мы видим, уровня действительно два, как и в модели OSI, но четкое соответствие сопоставить довольно проблематично.

Следующий уровень является сеансовым. Можно реализовать протокол с подтверждениями поверх UDP, и сделать некий аналог TCP, тогда в этом смысле протокол действительно является сеансовым. Так сделано в протоколе «системны телекоммуникаций» [3, 4, 10], в протоколе QUIC (который, в целом, относят все к тому же прикладному, хотя на наш взгляд, он несколько более низкого уровня и по структуре и по назначению). Но в тоже время, транспортный протокол TCP решает задачи сеансового уровня. При этом сейчас принято использовать TLS поверх TCP, фактически получается имплементация безопасного сеансового уровня.

На наш взгляд SSL и TLS (реализации поверх: FTPS = FTP+SSL, HTTPS=HTTP over SSL), SSH (реализации поверх: X11 forwarding, SFTP = SSH FTP) в полной мере являются сеансовыми протоколами. Впрочем, корректнее их было бы обозначить секьюрными протоколами, или протоколами промежуточного, секьюрного уровня, что и обозначено в их названиях.

Транспортные протоколы традиционно делят на UDP- без подтверждений и TCP- с подтверждениями. При использовании сокетов Беркли так и говорится, что тип сокета TCP или UDP. Однако это не верно. В терминологии сокетов Беркли TCP-сокеты на самом деле называются STREAM, и к ним помимо TCP относятся и сокеты для использования в SCTP. UDP-сокеты на самом деле называются DATEGRAM, и используются не только для UDP, но и для DCCP. Таким образом транспортные протоколы можно разделить на две группы: сеансовые-транспортные и дейтаграмные транспортные.

Фактически мы рассмотрели семиуровневую альтернативную модель. Прикладные протоколы в модели DOD (TCP) мы разделяем на целых три уровня. Два их них - протокол прикладных приложений, фактически является способом указания кодировки и формата данных, и, при необходимости, вызова прикладного приложения (text/html, image/jpeg, application/msword) и протоколы доставки конечной информации (smtp, http, ftp, pop3, imap4, имеющие непосредственно доступ к сокетам) соотносятся с прикладным и представительским уровнем. В нашей концепции на этих уровнях действительно решаются вопросы кодирования информации, выбора ее представления (в частности, image/gif или image/jpeg, например), а также сжатия. Сюда же относятся и аудио-кодеки, и способы сжатия изображения и видео [2,7,8]. Третья группа относится к прикладным и в DOD и в TCP, и действительно работает поверх транспортных протоколов. Но эти протоколы (DHCP, DNS, маршрутизации и прочие системные) сильно зависят от используемой версии сетевого протокола (ибо без нее бессмысленны) и по сути относятся к группе механизма соответствующего сетевого протокола.

Пятый уровень мы обозначим как секьюрный уровень. Фактически он соответствует сеансовому уровню в OSI/ISO.

Четвертый уровень - транспортный. Мы разделили его на две группы, STREAM и DATAGRAM, фактически сеансово-транспортный и дейтаграмно-транспортный. Сеансово-транспортный по использованию соотносится с транспортным модели OSI/ISO, а по своей структуре и логике, к сеансовому. Дейтаграмно-транспортный соответствует транспортному и в OSI/ISO и в DOD (TCP). Но применительно к IPv4, IPv6, так как в IPX уровень сокетов практически был включен в сетевой протокол, тогда как в TCP порты указываются в протоколах транспортного уровня.

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

1. Кручинин С.В. Семиуровневая модель OSI/ISO и стек протоколов TCP/IP: исследование взаимоотношения и интерпретации // Научно-исследовательские публикации. 2015. №5(25). С.115-120.

2. Кручинин С.В. Интеграция онлайн-трансляций в современные браузеры //Научно-исследовательские публикации. 2014. №13(17). С.32-37.

3. Кручинин С.В., Вишняков А.В. Обеспечение доступности абонентов VANET при их перемещении между транспортными средствами и реализация сетевых служб //Научно-исследовательские публикации. 2014. № 3. С. 69-82.

4. Зотов С.В. Тестирование обмена сообщениями на сеансовом уровне //Научно-исследовательские публикации. 2013. Т.1. №4. С.99-102.

5. Кручинин С.В. Минимизация и «аутсорсинг» функциональности в разработке SAAS-сервисов//Научные дискуссии. 2014. Т. 3. C. 5-10.

6. Галяс И.А., Орлов А.Г. Автоматические системы взаимодействия в формировании современного общества //Научные дискуссии. 2015. Т.1. С. 143-147.

7. Марей Р.А.С. Системны распознавания речи //Вопросы науки. 2015. Т.8.С.28-32.

8. Воронин В.В., Гапон Н.В., Сизякин Р.А., Ибадов Р.Р., Ибадов С.Р., Семенищев Е.А. Исследование метода восстановления искаженных пикселей изображений на основе текстурно-геометрической модели //Вопросы науки. 2015. Т.8.С.41-45.

9. Половинкин Д.В., Дмитриев В.Н. Анализ и оценка живучести транспортной сети передачи данных цифровых телерадиовещательных систем // Вопросы науки. 2015. Т.7. С.30-32.

10. Кручинин С.В. Тестирование времени доведения сообщений в режиме маршрутизации высокоскоростных и низкоскоростных резервных каналов // Вопросы науки. 2015. Т5. С. 53-58.

11. Романюк О.В., Шелковый Д.В. Балансировка траффика в транспортной сети с коммутацией пакетов // Вопросы науки, 2015, Т.5. С. 4247.

12. Кручинин С.В. Стеки сетевых технологий TCP/IP и OSI/ISO //Вопросы науки, 2015, Т.3. с.145-147.

Bibliography:

1. Kruchinin S.V. Semiurovnevaja model' OSI/ISO i stek pro-tokolov TCP/IP: issledovanie vzaimootnoshenija i interpretacii // Nauchno-is-sledovatel'skie publikacii. 2015. №5(25). S.115-120.

2. Kruchinin S.V. Integracija onlajn-transljacij v sovremen-nye brauzery //Nauchno-issledovatel'skie publikacii. 2014. №13(17). S.32-37.

3. Kruchinin S.V., Vishnjakov A.V. Obespechenie dostupnosti abo-nentov VANET pri ih peremeshhenii mezhdu transportnymi sredstvami i real-izacija setevyh sluzhb //Nauchno-issledovatel'skie publikacii. 2014. № 3. S. 69-82.

4. Zotov S.V. Testirovanie obmena soobshhenijami na seansovom urovne //Nauchno-issledovatel'skie publikacii. 2013. T.1. №4. S.99-102.

5. Kruchinin S.V. Minimizacija i «autsorsing» funkcional'nosti v razrabotke SAAS-servisov//Nauchnye diskussii. 2014. T. 3. C. 5-10.

6. Galjas I.A., Orlov A.G. Avtomaticheskie sistemy vzaimo-dejst-vija v formirovanii sovremennogo obshhestva //Nauchnye diskussii. 2015. T.1. S. 143-147.

7. Marej R.A.S. Sistemny raspoznavanija rechi //Voprosy nauki. 2015. T.8.S.28-32.

8. Voronin V.V., Gapon N.V., Sizjakin R.A., Ibadov R.R., Iba-dov S.R., Semenishhev E.A. Issledovanie metoda vosstanovlenija iskazhennyh pikselej izobrazhenij na osnove teksturno-geometricheskoj modeli //Voprosy nauki. 2015. T.8.S.41-45.

9. Polovinkin D.V., Dmitriev V.N. Analiz i ocenka zhivuchesti transportnoj seti peredachi dannyh cifrovyh teleradioveshhatel'nyh sistem // Voprosy nauki. 2015. T.7. S.30-32.

10. Kruchinin S.V. Testirovanie vremeni dovedenija soob-shhenij v rezhime marshrutizacii vysokoskorostnyh i nizkoskorostnyh rezervnyh kanalov // Voprosy nauki. 2015. T5. S. 53-58.

11. Romanjuk O.V., Shelkovyj D.V. Balansirovka traffika v transportnoj seti s kommutaciej paketov // Voprosy nauki, 2015, T.5. S. 42-47.

12. Kruchinin S.V. Steki setevyh tehnologij TCP/IP i OSI/ISO //Voprosy nauki, 2015, T.3. s.145-147.

Об авторе:

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

About author:

Kruchinin Sergei, Candidate of Political Sciences, research scientist, Wellborn LLC., Voronezh city, Russia.