Модель OSI и сетевые протоколы: 7 уровней, инкапсуляция и диагностика

Модель OSI (Open Systems Interconnection) — эталонная схема сетевого взаимодействия из семи уровней: она описывает путь данных от сигнала в кабеле или радиоканале до запроса HTTP, DNS-ответа либо SSH-сессии. Стандарт ISO делит функции сети на уровни и дает инженерам общий язык для описания протоколов, оборудования и неисправностей.

Быстрый ответ

• Модель OSI — эталонная схема из 7 уровней: физический, канальный, сетевой, транспортный, сеансовый, представления и прикладной.
• Каждый уровень добавляет к данным свой заголовок — это инкапсуляция; единица данных (PDU) меняется от сообщения и сегмента до пакета, кадра и битов.
• Диагностика сети по уровням идет снизу вверх: линк и VLAN, IP-адрес и маршрут, порт и handshake, затем DNS, TLS и приложение.
• Дальше в статье: таблица 7 уровней с PDU и протоколами, сравнение OSI и TCP/IP, готовые команды ip, ss, ping, tracepath, tcpdump и разбор трафика в Wireshark.

В реальной инфраструктуре обычно используют стек TCP/IP, а не буквальную семиуровневую реализацию OSI. При этом OSI остается удобной картой для работы: если приложение не получает ответ, инженер последовательно проверяет интерфейс, Ethernet или VLAN, IP-маршрут, TCP-порт, DNS и прикладной сервис. Такой порядок сокращает область поиска и не дает смешивать проблемы маршрутизации с ошибками веб-сервера.

Модель OSI: что это и зачем она нужна

Семиуровневая модель OSI описывает, как данные проходят путь от приложения до битов: каждый уровень решает ограниченный набор задач, добавляет свой заголовок и передает результат соседнему уровню. Именно так работает инкапсуляция, и по этим же уровням строится диагностика сети. Физический уровень кодирует биты в сигнал, канальный доставляет кадр соседнему узлу, сетевой выбирает путь между сетями, транспортный направляет данные нужному процессу. Верхние уровни описывают диалог, формат данных и правила конкретного сервиса.

Модель не диктует, какой кабель, коммутатор или операционную систему нужно использовать. Она помогает сопоставить функции сетевого стека с конкретными технологиями: Ethernet, Wi-Fi, IP, TCP, UDP, TLS, DNS, HTTP и SSH.

Какие задачи решает семиуровневая модель

Первая практическая задача, разделить ответственность. Коммутатор пересылает Ethernet-кадры по MAC-адресам, маршрутизатор работает с IP-префиксами и таблицей маршрутизации, веб-сервер обрабатывает HTTP. Ошибка на одном уровне не требует немедленно менять настройки на другом.

Вторая задача, дать проектировщикам и эксплуатационным командам точные термины. Формулировка проблема на L3 обычно означает проверку адреса, префикса, шлюза и маршрута. Проблема на L7 указывает на DNS, TLS, HTTP, аутентификацию, reverse proxy или приложение.

Третья задача, локализовать отказ. Отсутствующий link относится к L1 или L2. Неразрешаемое имя при рабочем доступе к IP-адресу указывает на DNS на прикладном уровне. Таймаут TCP-подключения часто связан с firewall, маршрутом, политикой Kubernetes либо недоступным сервером.

Уровни OSI снизу вверх

• 1. Физический: передает биты через электрический, оптический или радиосигнал.
• 2. Канальный: доставляет кадры внутри локального сегмента по MAC-адресам.
• 3. Сетевой: адресует IP-пакеты и направляет их между сетями.
• 4. Транспортный: доставляет поток или дейтаграммы конкретному сервису через порты.
• 5. Сеансовый: управляет логическим диалогом между приложениями.
• 6. Представления: определяет кодировку, сериализацию, сжатие и защиту формата данных.
• 7. Прикладной: задает правила обмена для DNS, HTTP, HTTPS, SSH, DHCP и других сервисов.

7 уровней модели OSI: функции и единицы данных

Единица данных уровня, PDU, меняется по мере движения трафика. Прикладное сообщение превращается в TCP-сегмент или UDP-дейтаграмму, затем в IP-пакет, Ethernet-кадр и последовательность битов. На стороне получателя этот процесс идет в обратном направлении.

1. Физический уровень: передача битов по среде

Физический уровень описывает сигнал и среду передачи: медный кабель, оптоволокно, SFP-модуль, радиоканал Wi-Fi, разъем, частоту, модуляцию и скорость линии. Здесь нет IP- и MAC-адресов. Полезная единица данных, биты.

Типовые симптомы L1: интерфейс имеет состояние DOWN, индикатор линка не горит, порт согласовал 100 Мбит/с вместо 1 Гбит/с, растет число ошибок приема. В виртуальной среде аналогом физического подключения выступают veth-пары, виртуальный коммутатор, состояние порта VM или политика облачной сети.

2. Канальный уровень: кадры, MAC-адреса и Ethernet

Канальный уровень доставляет кадры между узлами одного сегмента. Ethernet-кадр содержит MAC-адреса источника и назначения, тип полезной нагрузки, данные и контрольную последовательность FCS. Коммутатор изучает MAC-адреса по входящим кадрам и пересылает трафик на нужный порт либо рассылает его в пределах широковещательного домена.

VLAN делит один коммутатор на несколько логических L2-сегментов. Узел в VLAN 20 не увидит широковещательные кадры VLAN 10 без маршрутизации или специальной настройки. IEEE 802.11 охватывает функции физического и канального уровней, поэтому Wi-Fi связан и с радиоэфиром, и с MAC-кадрами.

ARP сопоставляет IPv4-адрес следующего узла с его MAC-адресом. В классическом разборе OSI ARP находится на границе L2 и L3: запрос содержит сетевой IPv4-адрес, но передается широковещательным Ethernet-кадром. В IPv6 для похожей задачи применяют Neighbor Discovery поверх ICMPv6.

3. Сетевой уровень: IP-адресация и маршрутизация

Сетевой уровень отвечает за передачу пакета между разными сетями. IPv4 использует 32-битные адреса, IPv6, 128-битные. Префикс определяет, какие адреса доступны напрямую, а для удаленных сетей хост отправляет пакет на шлюз по умолчанию.

Маршрутизатор получает IP-пакет, сверяет адрес назначения со своей таблицей маршрутизации, уменьшает TTL в IPv4 или Hop Limit в IPv6 и выбирает следующий узел. IP сам по себе не подтверждает доставку, не восстанавливает порядок данных и не открывает соединение между процессами.

ICMP обслуживает диагностику и сообщения об ошибках. Команда ping обычно посылает ICMP Echo Request, а traceroute или tracepath помогают увидеть последовательность маршрутизаторов и проблемы с MTU. Рабочий ping не доказывает доступность TCP-порта или HTTP-сервиса.

При нескольких интерфейсах одного default route часто недостаточно. Для трафика с разными исходными IP-адресами применяют правила ip rule и отдельные таблицы маршрутизации. Практическая настройка этого сценария разобрана в руководстве по policy routing в Linux.

4. Транспортный уровень: TCP, UDP и порты

Транспортный уровень связывает сетевую доставку с конкретным процессом. IP-адрес определяет хост или сетевой интерфейс, порт указывает сервис. Комбинация протокола, IP-адреса и порта образует сокет. Например, веб-сервер может слушать TCP-порт 443, а DNS-служба, UDP-порт 53.

TCP строит соединение через трехэтапное рукопожатие SYN, SYN-ACK, ACK. Он нумерует байты, подтверждает получение, повторно передает потерянные сегменты, сохраняет порядок и управляет перегрузкой сети. Эти свойства подходят для SSH, HTTPS, репликации баз данных и большинства HTTP/1.1 или HTTP/2-соединений.

UDP отправляет независимые дейтаграммы без установки соединения и без встроенного подтверждения доставки. Он меньше нагружает обмен служебными данными, но приложению приходится самостоятельно учитывать потерю, дублирование и порядок сообщений, когда это требуется. UDP часто используют DNS-запросы, DHCP, RTP и QUIC. DNS способен перейти на TCP при крупном ответе или в специальных сценариях, включая передачу зон.

QUIC работает поверх UDP и берет на себя надежную передачу, контроль перегрузки, мультиплексирование потоков и криптографическое рукопожатие TLS 1.3. HTTP/3 использует QUIC, поэтому утверждение весь HTTPS-трафик работает через TCP уже неточно.

Программы открывают соединения через socket API операционной системы. Примеры TCP- и UDP-серверов, конкурентные модели и особенности неблокирующего ввода-вывода собраны в практическом разборе сокетов на Python и Go.

5. Сеансовый уровень: управление диалогом

Сеансовый уровень описывает установление, поддержку, синхронизацию и завершение логического диалога. Сеанс может переживать отдельный запрос или переносить восстановление после краткого сбоя. Пример функции, хранение идентификатора пользовательской сессии, контроль этапов обмена или повторная аутентификация.

В стеке TCP/IP отдельного универсального протокола L5 обычно нет. Его функции распределены между приложением, библиотекой, API, TLS-сессией, брокером сообщений или фреймворком. TCP-соединение близко к понятию сеанса, но не совпадает с ним: одно прикладное взаимодействие может открывать несколько TCP-соединений, а один TCP-канал способен обслуживать множество HTTP-запросов.

6. Уровень представления: формат, кодирование и шифрование

Уровень представления преобразует данные в форму, понятную получателю. Сюда относят кодировки UTF-8, сериализацию JSON, Protobuf или ASN.1, сжатие gzip и преобразование структур данных. Клиент и сервер должны одинаково интерпретировать формат, иначе связь на TCP-уровне будет рабочей, а обмен сообщениями завершится ошибкой.

TLS часто условно относят к уровню представления, поскольку он шифрует и проверяет целостность полезных данных. В практической модели TCP/IP TLS обычно рассматривают как часть прикладного взаимодействия над TCP или внутри QUIC. Для диагностики полезнее искать конкретную причину: неподходящий сертификат, неверное SNI-имя, несовместимый набор шифров или сбой рукопожатия.

7. Прикладной уровень: HTTP, DNS, SSH и сервисы

Прикладной уровень определяет формат сообщений и логику сервиса. HTTP задает методы, заголовки, статусы и тело запроса. DNS описывает запросы и ресурсные записи. SSH строит защищенную удаленную сессию, DHCP выдает параметры адресации, SMTP передает почту.

Прикладной уровень не равен графическому интерфейсу. Команда curl, Nginx, API-клиент, DNS-резолвер и SSH-клиент работают на L7 даже без оконной оболочки. HTTP/1.1 и HTTP/2 обычно используют TCP, HTTPS добавляет TLS, HTTP/3 передает HTTP-сообщения через QUIC поверх UDP.

Уровни OSI и протоколы: практическая карта соответствий

Протоколы канального и сетевого уровня

Ethernet, Wi-Fi и VLAN работают с локальной доставкой кадров. MAC-адрес нужен для пересылки в пределах сегмента, а VLAN ID ограничивает область широковещательного трафика. ARP помогает IPv4-хосту найти MAC-адрес шлюза или соседнего сервера.

IP и ICMP работают с сетевой адресацией и маршрутизацией. Когда клиент обращается к удаленному серверу, он формирует Ethernet-кадр на MAC-адрес шлюза, а IP-пакет сохраняет адрес удаленного назначения. Маршрутизатор снимает входящий кадр и формирует новый для следующего сегмента. MAC-адреса меняются на каждом маршрутизируемом участке, IP-адреса обычно сохраняются.

Транспортные и прикладные протоколы

TCP и UDP используют порты, чтобы передать трафик конкретному приложению. HTTPS чаще использует TCP-порт 443, SSH, TCP-порт 22, DHCP, UDP-порты 67 и 68. Номера портов помогают классифицировать трафик, но сам номер не гарантирует тип протокола: сервис может слушать нестандартный порт.

Один прикладной протокол способен использовать несколько транспортных вариантов. DNS чаще отправляет короткие запросы через UDP, затем использует TCP при необходимости. HTTP доступен через TCP в вариантах HTTP/1.1 и HTTP/2, а HTTP/3 работает через QUIC и UDP. Анализируйте фактическую конфигурацию сервиса, а не только типовой порт.

Почему один протокол нельзя всегда отнести только к одному уровню

OSI классифицирует функции, поэтому отдельные технологии пересекают границы уровней. ARP связывает IPv4-адрес с Ethernet MAC-адресом. TLS защищает данные приложения, но тесно взаимодействует с транспортом. QUIC использует UDP как носитель, при этом сам добавляет надежность, контроль потока и шифрование.

HTTP/3 хорошо показывает ограничение механического заучивания. HTTP остается прикладным протоколом, QUIC решает транспортные задачи, UDP передает дейтаграммы, IP маршрутизирует пакеты, а Ethernet или Wi-Fi доставляют кадры в локальном сегменте. Четкая граница между L4, L5 и L6 в этой цепочке условна.

Инкапсуляция данных: как запрос проходит через сеть

Инкапсуляция, это добавление служебной информации каждого нижележащего уровня к данным верхнего. Она дает сети адреса, порты, номера последовательности, контрольные поля и сведения для локальной доставки. Получатель выполняет декапсуляцию, проверяет заголовки и передает полезную нагрузку выше.

Единицы данных: сообщение, сегмент, пакет, кадр и биты

• Сообщение или данные: HTTP-запрос, DNS-запрос, SSH-команда на прикладном уровне.
• TCP-сегмент: данные с TCP-заголовком, включая порты, sequence number и flags.
• UDP-дейтаграмма: данные с UDP-заголовком и портами.
• IP-пакет: транспортная нагрузка с IP-адресами источника и назначения.
• Кадр: IP-пакет с Ethernet- или Wi-Fi-заголовком для конкретного канала.
• Биты: физическое представление кадра в среде передачи.

В технической документации термин пакет иногда используют шире и называют так любые сетевые данные. При анализе дампа лучше ориентироваться на конкретный заголовок: Ethernet, IP, TCP, UDP, TLS или HTTP.

Инкапсуляция на стороне клиента

Представим запрос к HTTPS-сервису. Браузер или curl формирует HTTP-сообщение. TLS шифрует полезную нагрузку после рукопожатия. TCP добавляет исходный временный порт, порт назначения 443, номера последовательности и флаги. IP добавляет исходный и целевой IP-адреса.

Перед передачей ядро определяет next hop по таблице маршрутизации. Если сервер находится в другой подсети, next hop обычно совпадает со шлюзом по умолчанию. Через ARP ядро узнает MAC-адрес шлюза и создает Ethernet-кадр: MAC назначения указывает на шлюз, а внутри остается IP-пакет с адресом конечного сервера.

Размер кадра ограничивает MTU. Для Ethernet без дополнительных тегов стандартное значение часто равно 1500 байт. TCP подбирает размер сегмента MSS с учетом IP- и TCP-заголовков. Крупная полезная нагрузка делится на сегменты. Неподходящий MTU на пути вызывает таймауты, обрывы загрузки или проблемы только с крупными ответами.

Декапсуляция на сервере

Сетевая карта сервера принимает кадр, проверяет его целостность и передает в ядро. Канальный уровень сверяет MAC-адрес назначения. IP-обработчик проверяет адрес назначения и протокол полезной нагрузки. Затем TCP находит сокет по сочетанию адресов и портов, собирает поток байтов в правильном порядке и передает его процессу, который слушает порт.

Веб-сервер получает TLS-данные, завершает криптографический обмен и передает HTTP-запрос обработчику. Nginx может ответить статическим файлом, направить запрос в upstream или вернуть ошибку. Успешное TCP-соединение подтверждает доступность L3 и L4, но не подтверждает корректность TLS, HTTP-маршрута или состояния upstream.

Что меняется при прохождении маршрутизатора

Маршрутизатор не пересылает Ethernet-кадр целиком через разные сети. Он принимает кадр, удаляет канальный заголовок, обрабатывает IP-пакет и формирует новый кадр для следующего hop. В новом кадре MAC-адрес источника принадлежит исходящему интерфейсу маршрутизатора, а MAC-адрес назначения принадлежит следующему узлу.

IP-адреса источника и назначения обычно сохраняются. Исключение, NAT: маршрутизатор или firewall может заменить адрес, порт либо оба параметра. На каждом маршрутизаторе уменьшается TTL или Hop Limit. Когда значение достигает нуля, устройство отбрасывает пакет и обычно отправляет ICMP-сообщение Time Exceeded, на этом основана работа traceroute.

Модель OSI и TCP/IP: различия и соответствие

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

Таблица соответствия OSI и TCP/IP

Встречается и пятиуровневая учебная схема TCP/IP, где канальный и физический уровни разделены. Различие терминов не меняет порядок диагностики: сначала проверьте среду и интерфейс, затем адресацию, маршрут, порт и протокол сервиса.

Где находятся TLS, QUIC и HTTP/3

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

QUIC использует UDP на уровне IP, но сам ведет учет доставки, управляет перегрузкой и поддерживает несколько потоков в одном соединении. HTTP/3 передает прикладные HTTP-сообщения через QUIC. При проблеме с HTTP/3 проверяйте доступность UDP-порта, правила firewall, поддержку QUIC в reverse proxy и поведение клиента.

Ограничения модели OSI

OSI не заменяет знание ядра Linux, сетевого оборудования, firewall, NAT, балансировщиков и приложений. Один симптом способен затрагивать несколько уровней. Например, HTTPS может завершаться таймаутом из-за неверного маршрута, блокировки TCP SYN, PMTU black hole, сертификата или зависшего upstream.

Модель полезна как порядок рассуждения. Она не отменяет сбор фактов: снимок маршрутов, состояние порта, логи приложения, DNS-ответ и захват трафика часто дают более точный ответ, чем предположение о проблемном уровне.

Диагностика сети по уровням OSI

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

Уровни 1-2: интерфейс, линк и локальная сеть

Проверьте, существует ли интерфейс, поднят ли он и согласован ли линк. На физическом сервере используйте ethtool для скорости, дуплекса и состояния carrier. На виртуальной машине проверьте подключение виртуального NIC, настройки сети гипервизора, VLAN и security groups.

ip link show
ip -s link show dev eth0
ethtool eth0
ip neigh show
bridge vlan show

Статус NO-CARRIER указывает на отсутствие физического линка или отключенный виртуальный порт. Записи INCOMPLETE либо FAILED в ip neigh часто говорят о проблеме ARP, VLAN, коммутатора или локального firewall. Несовпадение скорости и дуплекса приводит к потерям и ошибкам, хотя интерфейс может оставаться UP.

Готовая последовательность проверки линка, адресов, маршрутов, портов и Docker-сетей есть в шпаргалке по диагностике сетевых интерфейсов Linux.

Уровень 3: адрес, маршрут и доступность узла

Проверьте IP-адрес, префикс, шлюз и маршрут до цели. Ошибка в маске или префиксе заставляет хост считать удаленный адрес локальным либо отправлять локальный трафик на шлюз. При нескольких NIC убедитесь, что ответный трафик идет через ожидаемый интерфейс.

ip addr show
ip route show
ip route get $TARGET_IP
ping -c 3 $TARGET_IP
tracepath $TARGET_IP

Сообщение Network is unreachable означает, что ядро не нашло подходящий маршрут. Таймаут ping не доказывает отсутствие маршрута: ICMP могут фильтровать. Доступность шлюза при недоступности удаленной сети сужает поиск до маршрутизации, ACL, VPN, удаленного сегмента или обратного маршрута.

tracepath полезен для поиска проблем Path MTU. Если короткие запросы проходят, а крупные ответы зависают, проверьте ICMP Fragmentation Needed для IPv4 или Packet Too Big для IPv6: когда firewall или провайдер блокирует эти сообщения, ядро не узнает о меньшем MTU и соединение зависает на передаче крупных пакетов — классический PMTU black hole.

Уровень 4: порты, соединения и фильтрация

Транспортный уровень проверяют по состоянию сокетов и по тому, устанавливается ли соединение до конца. Слушающие порты показывают, запущен ли сервис и на каком адресе он принимает трафик.

ss -tulpn
ss -tan state established
ss -s

Если сервис слушает, а клиент получает таймаут, снимайте трафик на обеих сторонах. Блокировка TCP SYN на firewall, ACL, NAT или в сетевой политике Kubernetes выглядит как молчание, хотя ping и таблица маршрутизации в порядке. Как устроена фильтрация пакетов и чем stateful-правила отличаются от пакетных, разбираем в статье про принципы работы firewall.

tcpdump -ni any -c 50 'tcp port 443'
tcpdump -ni any -c 50 'udp port 53'

UDP-проверки сложнее: подтверждения доставки нет, поэтому потерю дейтаграмм видно только по реакции приложения, например по повторным DNS-запросам. Учтите, что QUIC и HTTP/3 тоже работают поверх UDP и блокировка UDP-порта 443 ломает их, хотя HTTPS по TCP продолжает отвечать.

Уровни 5-7: имя, TLS и ответ сервиса

Когда L3 и L4 в порядке, переходите к прикладному уровню. Сначала убедитесь, что имя разрешается в нужный IP-адрес, затем проверьте TLS-рукопожатие и только после этого разбирайте ответ сервиса и логи приложения.

dig +short example.com
curl -vI https://example.com
openssl s_client -connect example.com:443 -servername example.com

Для разбора обмена на уровне пакетов удобно сочетать tcpdump на сервере и Wireshark на рабочей станции. В Wireshark полезны фильтры tcp.port == 443, dns, icmp, а также фильтр по входящим попыткам установить соединение. Если SYN приходит, а SYN-ACK не уходит, причина на стороне сервера: firewall, не запущенный сервис или неверная привязка к адресу.

Если TLS проходит, а сервис отвечает ошибкой, смотрите коды ответов и логи upstream. Порядок разбора access- и error-логов с готовыми командами описан в статье про анализ логов Nginx и Apache. Для защищенного разрешения имен и проверки DNSSEC пригодятся практики из материала про безопасную DNS-маршрутизацию DoT, DoH и DNSSEC.

Чек-лист: порядок проверки по уровням

• L1-L2: ip link show, ip -s link show dev eth0, ethtool eth0, ip neigh show, bridge vlan show.
• L3: ip addr show, ip route show, ip route get, ping -c 3, tracepath.
• L4: ss -tulpn, ss -tan state established, tcpdump по нужному порту.
• L5-L7: dig +short, curl -v, openssl s_client, логи reverse proxy и приложения.

Проверки идут снизу вверх, но перепрыгивать уровни бессмысленно: чинить TLS до появления линка и маршрута — потеря времени. Зафиксируйте уровень отказа, меняйте одну настройку за раз и повторяйте тот же тест — так модель OSI превращается из теории в рабочий алгоритм диагностики сети.