Модель OSI на примере падений сайта: на каком уровне ломается и какая проверка это ловит

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

Модель OSI — это эталонная схема из семи уровней (ISO/IEC 7498-1), которая делит передачу данных по сети на слои: физический, канальный, сетевой, транспортный, сеансовый, представления и прикладной. Каждый уровень решает свою задачу и опирается на уровень ниже. В реальном интернете работает стек TCP/IP из четырёх уровней, но именно по номерам OSI инженеры говорят «проблема на L3» или «это L7» — и понимают друг друга.

Из каких семи уровней состоит модель OSI

Уровни нумеруются снизу вверх: L1 — провод, L7 — приложение. Чем ниже уровень сломался, тем больше отказывает одновременно: обрыв кабеля роняет и HTTP, и DNS, и почту, а ошибка в коде — только конкретный URL.

Стандарт ISO/IEC 7498-1 (вторая редакция — ноябрь 1994 года) описывает уровни абстрактно и называет единицы данных «(N)-PDU»; привычные «бит», «кадр», «пакет», «сегмент» — инженерная традиция, а не текст стандарта. Таблица собрана с практической стороны: что ломается, чем видно, какая проверка ловит.

Правая колонка важна: мониторинг работает снаружи и видит только уровни с третьего по седьмой. Обрыв кабеля (L1), выключенный порт коммутатора (L2) и сбой маршрутизации (L3) снаружи выглядят одинаково — хост не отвечает.

Как модель OSI соотносится с TCP/IP

Интернет построен на четырёхуровневой модели из RFC 1122 (октябрь 1989 года): Link, Internet, Transport, Application. RFC прямо пишет, что его прикладной уровень «объединяет функции двух верхних уровней OSI — представления и прикладного»; сеансового уровня в TCP/IP нет вовсе.

Главный практический вывод: уровни 5 и 6 в живом стеке размыты. TLS формально не принадлежит ни одному из них: RFC 8446 (TLS 1.3, август 2018 года) требует от нижнего уровня только «надёжный упорядоченный поток данных», то есть сидит над TCP, а наверх отдаёт уже расшифрованные байты HTTP. Кто-то называет это L5, кто-то L6, кто-то честно говорит «между 4 и 7». Для диагностики важно другое: TLS ломается отдельно от TCP и отдельно от HTTP, поэтому проверять его нужно отдельной командой и отдельной проверкой.

Что ломается на уровнях 1–2: кабель, порт коммутатора, дата-центр

На L1–L2 сайт «падает» целиком: выдернутый патч-корд, сгоревший блок питания, отключение стойки, ошибка VLAN на коммутаторе хостера. Снаружи это неотличимо от сетевого сбоя — сервер перестаёт отвечать на всё сразу.

Симптом в браузере: долгое ожидание и ERR_CONNECTION_TIMED_OUT (код −118 в Chromium) — пакеты уходят в пустоту. Снаружи проверяется только фактом молчания; изнутри, через консоль хостера или IPMI, смотрят линк:

# Пример вывода. Линк (L1) и канальный уровень (L2)
ip -br link
lo     UNKNOWN  00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
eth0   DOWN     52:54:00:a1:b2:c3 <NO-CARRIER,BROADCAST,MULTICAST,UP>

ethtool eth0 | grep -E 'Speed|Link detected'
        Speed: Unknown!
        Link detected: no

NO-CARRIER и «Link detected: no» — это L1: сигнала в кабеле нет. Если линк есть, а шлюз молчит, смотрят L2: ip neigh покажет состояние FAILED вместо REACHABLE — ARP-запрос остался без ответа.

Что ломается на уровне 3: маршрут, BGP и «сервер виден не всем»

L3 — IP-адреса и маршруты между сетями. Здесь ломается самое коварное: сервер жив, но из одного региона доступен, а из другого — нет. Причины: отозванный BGP-анонс у хостера, ошибка на стыке провайдеров, блокировка префикса, «чёрная дыра» после DDoS-фильтрации.

Симптом в браузере: ERR_ADDRESS_UNREACHABLE (−109, «нет маршрута к хосту») или тот же ERR_CONNECTION_TIMED_OUT. Первая команда — ping, вторая — mtr:

# Пример вывода. ICMP Echo (тип 8) / Echo Reply (тип 0), RFC 792
ping -c 4 203.0.113.10
PING 203.0.113.10 (203.0.113.10) 56(84) bytes of data.
From 198.51.100.1 icmp_seq=1 Destination Host Unreachable
--- 203.0.113.10 ping statistics ---
4 packets transmitted, 0 received, +2 errors, 100% packet loss

# Где именно обрывается путь
mtr -rwc 20 203.0.113.10
HOST: laptop          Loss%   Snt   Last   Avg  Best  Wrst
  1.|-- 192.168.1.1    0.0%    20    0.4   0.5   0.3   1.1
  2.|-- 198.51.100.1   0.0%    20    8.9   9.2   8.1  14.3
  3.|-- ???           100.0    20    0.0   0.0   0.0   0.0

«Destination Host Unreachable» — ICMP тип 3, и прислал его маршрутизатор 198.51.100.1, а не сервер: дальше пакеты не идут. Если ping даёт 100% потерь без сообщений об ошибке, а mtr обрывается перед сервером, вариантов два: L1–L2 у сервера или ICMP закрыт файрволом. Как читать хопы и звёздочки — в статье про трассировку маршрута.

Что ломается на уровне 4: порт закрыт, файрвол, сервис не слушает

L4 — TCP-соединение к конкретному порту: 80 для HTTP, 443 для HTTPS. Три классических сценария: nginx упал и порт никто не слушает; сервис слушает только 127.0.0.1; файрвол или security group хостера молча отбрасывает SYN. Первые два дают быстрый отказ, третий — таймаут.

Симптом в браузере: ERR_CONNECTION_REFUSED (−102) при быстром отказе, ERR_CONNECTION_TIMED_OUT (−118) при дропе. Разница принципиальна: по RFC 9293 закрытый порт отвечает на SYN сегментом RST — сервер жив и явно отказывает. Тишина означает, что SYN до сервера не дошёл.

# Пример вывода. Снаружи: есть ли кто-то на порту
nc -zv -w 3 example.com 443
nc: connect to example.com (203.0.113.10) port 443 (tcp) failed: Connection refused

nc -zv -w 3 example.com 80
Connection to example.com (203.0.113.10) 80 port [tcp/http] succeeded!

# Изнутри: кто и на каком адресе слушает
sudo ss -tlnp | grep -E ':80 |:443 '
LISTEN 0 511 0.0.0.0:80    0.0.0.0:* users:(("nginx",pid=812,fd=6))
# :443 нет -> HTTPS-листенер не поднялся

Три исхода nc: succeeded — L4 в порядке, идём выше; Connection refused — хост ответил RST, сервис не слушает или слушает не на том адресе; timed out — файрвол по пути или дроп на сервере. Почему 443 бывает «закрыт» при работающем nginx — в статье что такое порт.

Где в модели живёт TLS и что ломается в сертификате

TLS работает поверх установленного TCP-соединения и до первого байта HTTP, поэтому ошибки сертификата — отдельный класс: порт 443 открыт, но браузер отказывается продолжать. По номерам OSI это условно L5–L6; по RFC 8446 это два подпротокола — handshake (согласование параметров, проверка сертификата) и record (шифрование потока).

Симптомы в браузере: ERR_CERT_DATE_INVALID (−201, просрочен или ещё не действует), ERR_CERT_COMMON_NAME_INVALID (−200, имя не совпадает с доменом), ERR_CERT_AUTHORITY_INVALID (−202, цепочка не доверена), ERR_SSL_VERSION_OR_CIPHER_MISMATCH (−113). Chromium группирует коды ошибок диапазонами, и по диапазону уровень виден сразу:

# Пример вывода. Handshake и сертификат отдельно от HTTP
openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>&1 \
  | grep -E 'Verify return|Verification|notAfter|Protocol|subject='
Protocol  : TLSv1.3
subject=CN = example.com
Verify return code: 10 (certificate has expired)

# Даты действия сертификата
openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null \
  | openssl x509 -noout -dates
notBefore=Jun 12 00:00:00 2026 GMT
notAfter=Sep 10 23:59:59 2026 GMT

Ключ -servername обязателен: без SNI сервер с несколькими сайтами отдаст сертификат по умолчанию, и вы будете чинить не ту проблему. «Verify return code: 0 (ok)» — TLS в порядке, поднимаемся на L7. Разбор handshake и цепочек — в статье о том, как работает HTTPS.

Что ломается на уровне 7: HTTP-ответы 5xx и DNS

L7 — единственный уровень, на котором сайт может «работать» для сети и быть мёртвым для пользователя. Соединение установлено, TLS согласован, а в ответ приходит 502 Bad Gateway (nginx не достучался до бэкенда), 504 Gateway Timeout (бэкенд не ответил вовремя), 500 (исключение в коде) или 200 OK с заглушкой «Технические работы».

DNS — тоже L7 по RFC 1122, хотя ломается раньше всех: без ответа резолвера браузер не знает, к какому IP подключаться, и показывает ERR_NAME_NOT_RESOLVED (−105). Две команды закрывают весь седьмой уровень:

# Пример вывода. Только заголовки: код, сервер, время
curl -sI https://example.com/ -w 'time_total=%{time_total}\n'
HTTP/2 502
server: nginx/1.26.3
time_total=0.312

# DNS: есть ли A-запись и кто отвечает
dig +short example.com A
203.0.113.10

dig example.com A @8.8.8.8 | grep -E 'status|ANSWER SECTION' -A1
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 41207

502 приходит за сотни миллисекунд, потому что nginx сам сформировал ответ; 504 приходит после минуты ожидания — бэкенд принял соединение, но не ответил. NXDOMAIN от авторитетного сервера означает, что запись удалена или зона слетела; NXDOMAIN только от одного резолвера — кэш или региональная фильтрация.

Снизу вверх или сверху вниз: с какого уровня начинать диагностику

Снизу вверх (ping → порт → TLS → HTTP) — надёжно, но долго; сверху вниз — быстрее, потому что ошибка браузера или curl уже называет уровень. На практике совмещают: один curl сверху, затем прыжок на тот уровень, который он назвал.

Правило, которое экономит больше всего времени: быстрая ошибка — уровень выше, чем кажется (RST — это L4, а не сеть; 502 — бэкенд, а не nginx). Медленный таймаут — почти всегда L3–L4: пакеты уходят в пустоту.

Как набор проверок мониторинга локализует уровень поломки

Одна HTTP-проверка покрывает все уровни сразу: чтобы получить 200 OK, должны отработать DNS, маршрут, TCP, TLS и приложение. Но она не говорит, где именно сломалось, — «недоступен» и всё. Локализацию даёт комбинация независимых проверок: каждая следующая на уровень выше, и первая упавшая называет виновника.

В Пруфене это пять типов проверок из 18: Ping (ICMP, L3), Порт (TCP-соединение, L4), Сертификат (TLS), DNS и HTTP GET / HEAD (L7). Ping, Порт и HTTP запускаются с интервалом от 2 минут; Сертификат и DNS — от суток: срок сертификата и записи зоны не меняются каждую минуту. Результаты читаются по одной таблице:

Отдельный сигнал — раскладка по локациям. HTTP провалился из Владивостока и Новосибирска, но прошёл из Москвы, Минска и Испании — почти наверняка L3, маршрут сломался у одного магистрального оператора. Падение из всех точек сразу — L4 и выше либо авария у хостера.

Частые вопросы

На каком уровне OSI работает TLS?

Однозначного ответа нет. RFC 8446 определяет TLS как протокол поверх надёжного транспорта (TCP, L4), который отдаёт приложению (HTTP, L7) расшифрованный поток. Handshake похож на сеансовый уровень (L5), шифрование — на уровень представления (L6), поэтому в учебниках встречаются оба варианта. В модели TCP/IP, по которой реально работает интернет, TLS относят к прикладному уровню вместе с HTTP.

Почему говорят «проблема на восьмом уровне»?

Это инженерная шутка: уровней семь, восьмого не существует, а «L8» означает человека — пользователя или администратора. «Проблема на восьмом уровне» — неправильный пароль, ошибка в конфиге, случайно удалённая DNS-запись. В таблице выше такие случаи выглядят как всё OK, кроме одной проверки, упавшей сразу после чьего-то деплоя.

Зачем нужна модель OSI, если в жизни используют TCP/IP?

Как общий язык. Четыре уровня TCP/IP слишком крупные для разговора о поломках: «Application» в RFC 1122 — это и DNS, и TLS, и HTTP, которые ломаются по-разному. Номера OSI дают более мелкую сетку: L3 — маршрутизация, L4 — порт, L7 — приложение. Поэтому балансировщики называют L4- и L7-балансировщиками, а DDoS-атаки — атаками на L3/L4 или L7, хотя все они работают в TCP/IP.

Что такое инкапсуляция в модели OSI?

Это вкладывание данных одного уровня внутрь единицы уровня ниже. HTTP-запрос (L7) становится нагрузкой TCP-сегмента (L4), сегмент — нагрузкой IP-пакета (L3), пакет — нагрузкой Ethernet-кадра (L2), кадр — битами в кабеле (L1). Каждый уровень добавляет свой заголовок, на приёмной стороне они снимаются в обратном порядке. Следствие: при MTU 1500 байт на данные остаётся меньше — минус 20 байт IP и 20 байт TCP.

Может ли сайт отдавать 200 OK и при этом быть сломанным?

Да, и это самый неприятный случай: все семь уровней отработали, а страница показывает заглушку «Технические работы», пустой каталог или ошибку из кэша CDN с кодом 200. Проверки от L3 до HTTP-кода здесь бессильны — нужна проверка содержимого, которая ищет на странице ключевую фразу. Это уже не про OSI, а про смысл ответа.