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

Модель OSI: что это такое и зачем нужны 7 уровней сети

Модель OSI (Open Systems Interconnection — «взаимодействие открытых систем») — эталонная схема, которая описывает, как два устройства обмениваются данными по сети. Её разработала ISO (International Organization for Standardization — Международная организация по стандартизации) в 1984 году. Модель закреплена в стандарте ISO/IEC 7498-1, где IEC — Международная электротехническая комиссия. Модель делит связь на 7 уровней: от физического, на котором сигналы идут по кабелю, до прикладного, с которым работает браузер.

Разбиение на уровни решает две практические задачи. Первая — изоляция проблем: если сайт не открывается, вы проверяете уровни по очереди и сразу видите, в чём причина — в кабеле или в настройках сервера. Вторая — независимая разработка: производителю сетевой карты не нужно думать о браузерах, а разработчику веб-сервера неважно, придёт запрос по Wi-Fi или по оптоволокну. Правила общения внутри каждого уровня задаёт протокол. Чтобы узнать, что такое сетевой протокол, прочитайте отдельную статью.

Вот как запрос проходит путь от браузера до сервера и обратно:

• браузер формирует запрос HTTPS (HyperText Transfer Protocol Secure — защищённый протокол передачи гипертекста) к порту 443 — это 7-й уровень;
• TCP (Transmission Control Protocol — протокол управления передачей) нарезает данные на сегменты, обычно до 1460 байт каждый, — это 4-й уровень;
• IP (Internet Protocol — межсетевой протокол) добавляет адрес сервера и выбирает маршрут — это 3-й уровень;
• сетевая карта упаковывает пакеты в кадры и превращает их в электрические сигналы или радиоволны — это 2-й и 1-й уровни;
• сервер разбирает полученные данные в обратном порядке, с 1-го уровня по 7-й, и отправляет ответ тем же путём.

Как устроены семь уровней OSI — от физического до прикладного

Модель OSI делит передачу данных на 7 уровней. Каждый уровень решает свою задачу и передаёт результат соседнему уровню: снизу — сигналы и кабели, сверху — программы и данные пользователя. Такое разделение упрощает диагностику: вы точно знаете, на каком участке искать неисправность.

Уровни нумеруются снизу вверх: 1 физический, 2 канальный, 3 сетевой, 4 транспортный, 5 сеансовый, 6 представления, 7 прикладной. IP-адрес и маршрутизация обрабатываются на 3-м уровне, а привычные протоколы вроде HTTP и HTTPS работают на 7-м уровне через порты 80 и 443. Подробнее про адресацию читайте в статье про IP-адрес.

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

Как определить, на каком уровне OSI возникла проблема в сети

Проверяйте уровни снизу вверх: начните с физического и дойдите до прикладного. Если нижний уровень не работает, верхние проверять бесполезно: пакеты до них просто не доходят. Обычно хватает 5–7 команд в терминале и 3–5 минут.

Каждая команда отвечает на один вопрос: работает ли конкретный уровень. Проблемный уровень там, где команда первой вернула ошибку. Утилиты ping и traceroute используют ICMP (Internet Control Message Protocol). Это служебный протокол 3-го, сетевого уровня.

На сервере без монитора линк проверяют командой, а не по индикатору. Если арендуете сервер, выберите VPS с доступом к VNC-консоли. VNC (Virtual Network Computing) позволяет зайти на машину, даже когда сеть на ней полностью отключена.

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

1. Физический уровень (1). Посмотрите на индикатор линка на сетевой карте или роутере: он должен гореть или мигать. В Linux выполните ip link show: в строке интерфейса должно быть state UP. Если линка нет, замените кабель или переключите его в другой порт.
2. Локальный стек. Выполните ping -c 4 127.0.0.1. Если ответ приходит быстрее 1 мс, стек TCP/IP в системе исправен. Если команда выдаёт ошибку, переустановите драйвер сетевой карты или сбросьте сетевые настройки.
3. Канальный и сетевой уровни (2–3). Узнайте адрес шлюза командой ip route (в Windows — ipconfig) и отправьте на него ping, например ping 192.168.1.1. Если шлюз не отвечает, ищите причину в локальной сети: Wi-Fi, VLAN (виртуальная локальная сеть), фильтр по MAC-адресу или IP-адрес не из той подсети.
4. Маршрутизация (3). Выполните ping 8.8.8.8. Если ответов нет или потери больше 2 %, запустите traceroute example.com (в Windows — tracert). Маршрут обрывается на узле, после которого идут строки * * *. Если имя домена не распознаётся, передайте утилите IP-адрес.
5. DNS (Domain Name System), уровень 7. Выполните nslookup example.com: запрос уйдёт на порт 53. Если 8.8.8.8 отвечает, а имя не распознаётся, обратитесь к другому DNS-серверу: nslookup example.com 1.1.1.1.
6. Приложение (7). Выполните curl -I example.com для HTTP (HyperText Transfer Protocol) на порту 80 и telnet example.com 443 для HTTPS. Код 200 или 301 в ответе curl означает, что веб-сервер работает. SSH (Secure Shell) проверьте командой telnet IP-сервера 22: строка SSH-2.0 в ответе значит, что SSH-сервер принимает подключения.

Протоколы и порты на каждом уровне OSI: примеры с цифрами

Каждый протокол в сети привязан к конкретному уровню модели OSI (Open Systems Interconnection, взаимосвязь открытых систем) и часто использует свой порт. Порт — это число от 1 до 65535, по которому сервер понимает, какой службе адресован пакет. Зная эти цифры, вы быстрее найдёте, где искать неисправность.

На прикладном, 7-м уровне работают протоколы, с которыми сталкивается пользователь напрямую: HTTP на порту 80, HTTPS на порту 443, SSH (Secure Shell) на порту 22, DNS (Domain Name System) на порту 53, FTP (File Transfer Protocol) на порту 21 и SMTP (Simple Mail Transfer Protocol) на порту 25. Транспортный, 4-й уровень отвечает за доставку данных через TCP или UDP — именно он добавляет к адресу номер порта. Сетевой, 3-й уровень обрабатывает IP-адреса и маршрутизацию через протоколы IP и ICMP, а канальный, 2-й уровень передаёт кадры по локальной сети через Ethernet или Wi-Fi 802.11.

Разберём два примера. Первый: вы открываете сайт по HTTPS — браузер сначала обращается к DNS на порту 53, получает IP-адрес сервера, затем 3-й уровень строит маршрут по этому адресу, 4-й уровень устанавливает TCP-соединение на порту 443, а 2-й уровень доставляет кадры через вашу сеть до провайдера. Второй пример: вы подключаетесь к серверу по SSH для настройки — запрос идёт через порт 22, 4-й уровень гарантирует доставку пакетов без потерь через TCP, а 3-й уровень маршрутизирует их через несколько узлов до нужного IP-адреса.

Протоколы и порты по уровням модели OSI:

• 7-й уровень (прикладной): HTTP 80, HTTPS 443, SSH 22, DNS 53, FTP 21, SMTP 25
• 4-й уровень (транспортный): TCP и UDP — добавляют порт к адресу
• 3-й уровень (сетевой): IP и ICMP — маршрутизация по IP-адресу
• 2-й уровень (канальный): Ethernet и Wi-Fi 802.11 — передача кадров в локальной сети

Если вы настраиваете сервер и не уверены, какой порт открыть для конкретной службы, закажите готовый VPS с уже настроенным доступом по SSH — это избавит от ошибок в конфигурации портов.

Ошибки при работе с моделью OSI и как их избежать

Новички чаще всего путают канальный уровень (2-й) с сетевым (3-м) и ищут проблему не на том уровне. Ниже разберём каждую ошибку по отдельности.

Первая ошибка: поиск проблемы не на том уровне

Администратор увидел, что сайт не открывается, и 25 минут проверял маршрутизацию и IP-адреса на 3-м уровне, хотя проблема была в DNS (Domain Name System) на 7-м уровне — сервер имён на порту 53 не отвечал. Простой запрос nslookup занял бы 1 минуту и сразу указал верный уровень.

Вторая ошибка: путаница канального и сетевого уровней

На канальном уровне (2-м) работают MAC-адреса и коммутаторы, на сетевом (3-м) — IP-адреса и маршрутизация. Если проблема в MAC-таблице свитча, а вы проверяете таблицу маршрутизации, диагностика затянется без результата. Проверяйте IP и маршруты на 3-м уровне отдельно от MAC-адресов на 2-м.

Третья ошибка: OSI вместо реального стека TCP/IP

Реальный интернет работает по стеку TCP/IP из 4 уровней, а не строго по 7 уровням OSI. OSI — учебная модель для понимания логики, а не буквальная схема пакета, который идёт через traceroute. Из-за этого новички ищут в дампе трафика уровни, которых физически нет в заголовках. Сверяйтесь с реальным стеком TCP/IP, а не только со схемой из 7 уровней.

Четвёртая ошибка: пропуск физического уровня

При поиске неполадки физический уровень (1-й) пропускают и сразу лезут в настройки протоколов. Отошедший патч-корд или неисправный порт коммутатора объясняют обрыв связи быстрее, чем анализ конфигурации DNS. Начинайте диагностику с физического уровня — проверьте кабель и индикаторы порта.

Пятая ошибка: путаница порта и протокола

Порт — это число, например 80 или 443, а протокол — это правило обмена данными, например HTTP (HyperText Transfer Protocol). Не путайте их и уточняйте оба параметра.

Помните, что в терминале обычно хватает 5–7 команд для локализации проблемы.

Идите по уровням снизу вверх, и диагностика займёт минуты, а не часы. Если ошибки в сети регулярно связаны с нестабильным каналом или слабым железом, замена сервера снимет часть проблем на физическом уровне — подобрать надёжный VPS.

OSI и TCP/IP: чем отличаются и как соотносятся уровни

Модель OSI (Open Systems Interconnection, «взаимодействие открытых систем») из 7 уровней — учебная и справочная схема, которую разработала ISO (International Organization for Standardization) в 1984 году как стандарт ISO/IEC 7498-1. Реальный интернет работает на другом стеке — TCP/IP (Transmission Control Protocol/Internet Protocol), в котором всего 4 уровня вместо 7. Разница не в физике сети, а в детализации описания одних и тех же процессов.

Три верхних уровня OSI — представительский, сеансовый и прикладной — в TCP/IP объединены в один прикладной уровень. Именно там работают HTTP и HTTPS через порты 80 и 443, SSH (Secure Shell) через порт 22, DNS (Domain Name System) через порт 53. Транспортный уровень OSI соответствует транспортному уровню TCP/IP, сетевой уровень OSI — уровню интернета, где обрабатываются IP-адреса и маршрутизация. Два нижних уровня OSI сливаются в уровень сетевого доступа.

На практике инженеры настраивают оборудование и пишут правила файрвола в терминах 4 уровней TCP/IP — так проще и ближе к реальным конфигурациям. Модель OSI при этом остаётся инструментом диагностики: она позволяет точно указать, на каком из 7 уровней возникла проблема, прежде чем переходить к укрупнённой схеме TCP/IP.

Оба стека спрашивают на сертификации CCNA (Cisco Certified Network Associate) и на собеседованиях не случайно: OSI проверяет, понимает ли кандидат логику разделения функций по 7 уровням, а TCP/IP — знает ли он, как эти функции реализованы в настоящей сети. Если при диагностике сбоя вы за 5–7 команд в терминале определили уровень OSI, то настройку исправления всё равно будете делать в терминах TCP/IP. Подробнее о самой диагностике читайте в статье про поиск проблемы по уровням сети.

Когда модель OSI не нужна на практике

Для настройки обычного сайта или VPS (Virtual Private Server, виртуальный выделенный сервер) семь уровней помнить наизусть не нужно. Хостинг-провайдер и операционная система уже скрывают физический, канальный и часть сетевого уровня — вы просто открываете порты и запускаете сервис. Модель OSI остаётся справочной картой, а не ежедневным инструментом администратора.

Она действительно полезна в трёх случаях: при подготовке к сертификации CCNA (Cisco Certified Network Associate), при разработке сетевого программного обеспечения, где важно точно знать, на каком уровне обрабатывается пакет, и при разборе сложных инцидентов на стороне провайдера, когда нужно объяснить инженеру поддержки, где именно рвётся соединение. В остальных ситуациях достаточно практической цепочки диагностики.

Для повседневной работы хватает трёх команд: ping проверяет доступность узла, traceroute показывает маршрут до него, а проверка порта (например, telnet host 443 или nc -zv host 80) подтверждает, что сервис отвечает. Такая проверка обычно занимает 2–3 команды и 1–2 минуты, вместо разбора всех 7 уровней по очереди.

С чего начать проверку при типичных сбоях:

• Сайт не открывается — сначала ping, потом проверка порта 80 или 443
• SSH (Secure Shell) не подключается — проверьте порт 22 и правила брандмауэра
• Домен не резолвится — проверьте DNS (Domain Name System) на порту 53

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