CC BY
21
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.
