В конце 1970-х у каждого крупного производителя был свой закрытый стек протоколов: у IBM — SNA, у DEC — DECnet, у Xerox — XNS, плюс отдельно развивался X.25 для сетей операторов связи. Купив оборудование одного вендора, вы были привязаны к нему навсегда — соединить две системы разных производителей напрямую часто было физически невозможно, не то что программно. International Organization for Standardization взялась решить эту проблему и в 1984 году выпустила стандарт ISO/IEC 7498 — он и есть та самая модель OSI. Это не протокол и не код, а просто договорённость, кто за что отвечает: 7 этажей с чёткой границей ответственности между ними, чтобы производители могли делать совместимые друг с другом куски сети, не зная деталей реализации соседних уровней.

Забавный поворот: сама OSI как стек протоколов в итоге проиграла. Покуда ISO годами утверждала стандарт через комитеты, в DARPA-сети ARPANET уже несколько лет вполне успешно работал TCP/IP, выросший из принципа «грубый консенсус и работающий код» — без долгих бюрократических согласований. К моменту, когда OSI была готова, TCP/IP уже захватил критическую массу сетей, и переучивать индустрию назад не было смысла. Так и получилось странное наследие: сам стек OSI почти никто не использовал, а вот его 7-уровневая модель прижилась повсеместно как общий язык описания сети — она и сегодня лежит в основе того, как структурированы курсы CCNA, документация вендоров и просто разговоры инженеров. Когда коллега говорит «у нас проблема на третьем уровне», все в комнате сразу понимают — речь про IP и маршрутизацию, а не про кабель и не про приложение, и не нужно тратить пять минут на уточнения.

Это не «программа» в широком смысле, а конкретный протокол, на котором программа разговаривает по сети: HTTP у браузера, DNS при резолвинге имён, SMTP/IMAP у почты, SSH у терминала, SNMP у систем мониторинга. Когда curl отправляет запрос, строка GET / HTTP/1.1 и заголовок Host: example.com — это и есть данные прикладного уровня, которые дальше поедут вниз, обрастая заголовками других уровней.

Проблемы здесь — это HTTP 404 и 500, истёкший SSL-сертификат, неверная версия API, бан по логину. Их диагностируют, читая ответ сервера или лог приложения, а не разбирая дамп трафика в Wireshark — до этого уровня дело обычно не доходит, если только не подозреваете, что протокол сломан на уровне самого формата сообщений.

Отвечает за то, как данные закодированы, прежде чем их можно передавать: кодировка символов (ASCII, UTF-8), форматы сериализации (JSON, Protobuf, XML), сжатие (gzip), шифрование. Из всех семи уровней это самый «бумажный» — в реальных протоколах отдельного модуля «presentation layer» почти никогда не существует. Вместо этого HTTP сам решает вопрос кодировки через заголовки Content-Type и Content-Encoding, а TLS (шифрование канала) на практике принято считать чем-то между пятым и шестым уровнем сразу — стандарт 1984 года просто не предвидел, что шифрование станет отдельной массивной индустрией.

Если веб-страница приходит с заголовком Content-Encoding: gzip, а браузер по какой-то причине не может её распаковать — формально это и есть сбой на уровне представления данных, хотя на практике никто не скажет «у меня сломался L6», просто скажут «страница не открывается».

По задумке отвечает за то, чтобы открыть диалог между двумя приложениями, поддерживать его (включая повторное подключение после обрыва) и аккуратно закрыть. В классических протоколах это NetBIOS или RPC, которые явно ведут сессию. Но в современном вебе всё устроено иначе: TCP-соединение само по себе не является сессией в смысле OSI — оно не помнит, кто вы такой, как только закрылось. Поэтому веб-приложения изобрели свой костыль — cookie и session ID, которые живут на прикладном уровне и эмулируют то, что должен был делать пятый уровень.

Забавно, что большинство разработчиков веба никогда не слышали термина «сеансовый уровень», но при этом каждый день работают с механизмом, который его заменяет — просто в другом месте стека.

Здесь живут TCP и UDP, и разница между ними — это, по сути, выбор между надёжностью и скоростью. TCP перед передачей данных устанавливает соединение через трёхстороннее рукопожатие (SYN → SYN-ACK → ACK), нумерует байты, подтверждает их получение, переотправляет потерянное и тормозит передачу при признаках перегрузки сети (congestion control). UDP ничего этого не делает — отправил и забыл, зато быстрее и без накладных расходов на рукопожатие, поэтому его используют там, где скорость важнее идеальной доставки: DNS-запросы, VoIP, потоковое видео, где потерянный кадр проще пропустить, чем ждать его повторной отправки с задержкой.

И TCP, и UDP используют порты (0–65535) для различения служб на одном IP — 80 и 443 для веба, 53 для DNS, 22 для SSH. Когда подключение сразу обрывается с «connection refused» — порт закрыт и там никто не слушает; когда оно просто зависает и таймаутится — скорее всего, пакеты режет файрвол где-то по дороге, и это уже совсем другая по характеру проблема, хоть выглядит похоже.

Сетевой уровень отвечает за IP-адресацию и маршрутизацию — то, как пакет находит путь от одной сети к другой, возможно, через десяток промежуточных роутеров. Каждый роутер на пути смотрит на IP-адрес назначения, ищет наиболее точное совпадение в своей таблице маршрутизации (тему статической и динамической маршрутизации разбираем дальше в этом курсе — включая OSPF и BGP) и отправляет пакет дальше, уменьшая поле TTL на единицу, чтобы пакет не мог кружить по сети бесконечно при случайной петле в маршрутах.

Сюда же относится ICMP — протокол, на котором держится ping и сообщения вида «адрес недоступен» или «время жизни пакета истекло» (последнее, кстати, и есть механизм работы traceroute: он шлёт пакеты с искусственно маленьким TTL и собирает ICMP-ответы от каждого роутера на пути).

Канальный уровень работает внутри одного физического сегмента сети и оперирует MAC-адресами вместо IP. Сюда относятся Ethernet-кадры, коммутация (подробно разбираем в следующей теме курса) и VLAN. Коммутатор, получив кадр, смотрит только на MAC-адрес назначения — ему совершенно неинтересно, что внутри лежит IP-пакет с каким-то там адресом, для коммутатора это просто полезная нагрузка.

Здесь же живёт ARP — протокол, который переводит IP-адрес в MAC-адрес перед тем, как кадр можно будет реально отправить (без этого канальный уровень просто не знает, кому физически адресовать кадр). Типичные проблемы этого уровня — широковещательный шторм при петле без STP, duplex mismatch или порт, оказавшийся не в том VLAN.

Самый нижний уровень — никаких адресов, никакой логики, просто сигнал: напряжение, переключающееся в витой паре, импульсы света в оптоволокне, модуляция радиоволны в Wi-Fi. Сюда же относятся физические стандарты — категории кабеля (Cat5e, Cat6), типы разъёмов, типы SFP-модулей для оптики, дальность и затухание сигнала.

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

Отправляя что-то по сети, каждый уровень добавляет собственный заголовок (а канальный — ещё и трейлер в конце), упаковывая то, что пришло сверху, как письмо в конверт побольше, на котором дальше пишут уже свой собственный обратный адрес и адрес получателя. У каждого такого «конверта» своё название — PDU (Protocol Data Unit): на транспортном уровне это Segment у TCP или Datagram у UDP, на сетевом — Packet, на канальном — Frame, а на физическом уже просто биты. Важно, что нижний уровень понятия не имеет, что лежит у него внутри — для коммутатора что внутри кадра IP-пакет с HTTP, что зашифрованный VPN-трафик, что вообще мусор — для него это просто данные, которые нужно доставить по MAC-адресу.

Разберём по байтам: HTTP-запрос размером, скажем, 1000 байт сначала получает TCP-заголовок (минимум 20 байт, если без опций вроде временных меток) — становится сегментом в 1020 байт. Затем IP оборачивает это своим заголовком (тоже минимум 20 байт) — пакет уже 1040 байт. Дальше Ethernet добавляет 14 байт заголовка (MAC получателя 6 + MAC отправителя 6 + EtherType 2) спереди и 4 байта FCS-трейлера сзади — итоговый кадр на проводе занимает 1058 байт, хотя полезных данных в нём было всего 1000. На больших файлах эти накладные расходы почти не заметны, а вот при передаче мелких пакетов (например, голосовых VoIP-фреймов по 20-30 байт полезной нагрузки) заголовки могут составлять большую часть трафика — отсюда и берётся интерес к специальным механизмам сжатия заголовков в таких сценариях.

Отсюда же берётся ограничение MTU (Maximum Transmission Unit) — максимальный размер кадра, который умеет передать конкретная среда (для обычного Ethernet это 1500 байт полезной нагрузки без заголовков самого Ethernet). Если данных больше, чем помещается с учётом всех заголовков, IP может их фрагментировать на несколько пакетов — но фрагментация работает медленно и считается дурным тоном, поэтому современные системы предпочитают механизм Path MTU Discovery: заранее находят максимальный размер, который пройдёт по всему пути без фрагментации, и режут данные на сегменты такого размера сразу на транспортном уровне.

На приёмной стороне весь процесс идёт в обратном порядке — это называется декапсуляция: канальный уровень снимает заголовок Ethernet и проверяет FCS (совпала контрольная сумма — кадр цел, не совпала — кадр молча выбрасывается без объяснений отправителю), затем IP снимает свой заголовок, затем TCP — и на выходе из всей этой матрёшки остаются ровно те же 1000 байт HTTP-запроса, с которых всё начиналось.

Определения определениями, но модель куда понятнее на конкретном примере. Вы набираете адрес сайта в браузере и жмёте Enter — вот что происходит за те доли секунды, что страница «думает».

Шаг 1. Браузеру нужен IP-адрес сайта, а у него есть только имя — он спрашивает DNS-сервер (прикладной уровень, поверх UDP-порта 53, потому что для одного короткого вопроса устанавливать TCP-соединение избыточно). Если ответ уже лежит в локальном кэше резолвера — этот шаг вообще пропускается, именно поэтому повторное открытие того же сайта обычно ощущается быстрее.

Шаг 2. Получив IP, браузер открывает TCP-соединение к порту 443 (HTTPS) — уходит SYN, приходит SYN-ACK, уходит ACK. Три пакета, прежде чем хоть один байт HTTP успел куда-то полететь. Сразу после рукопожатия для HTTPS добавляется ещё и TLS-хендшейк (обмен сертификатами и согласование ключей шифрования) — ещё несколько round-trip'ов, прежде чем реальные данные пойдут в зашифрованном виде.

Шаг 3. Операционная система оборачивает HTTP-запрос в TCP-сегмент, тот — в IP-пакет с адресом сервера, и смотрит в таблицу маршрутизации: если сервер не в локальной сети (а почти всегда это так), пакет пойдёт на шлюз по умолчанию. Но чтобы физически отправить кадр, нужен MAC-адрес этого шлюза, а не его IP — компьютер заглядывает в свой ARP-кэш, и если записи там нет, рассылает широковещательный ARP-запрос «кто здесь 192.168.1.1, скажи мне свой MAC». Получив ответ, он наконец формирует Ethernet-кадр и отправляет его в провод как последовательность электрических сигналов или световых импульсов.

Шаг 4 — на стороне сервера. Всё повторяется в обратном порядке, снизу вверх: сигнал → кадр (коммутаторы по дороге смотрят только на MAC и пересылают, не трогая содержимое) → IP-пакет (роутеры смотрят на IP и решают, куда дальше) → TCP-сегмент (операционная система сервера собирает поток байт обратно) → и наконец сам HTTP-запрос долетает до процесса веб-сервера, который читает заголовок Host и решает, какой сайт вообще обслуживать (на одном IP часто висит несколько доменов).

Ответ сервера проходит весь тот же путь в обратную сторону. Итого: один клик мышью — а под капотом DNS, TCP, TLS, ARP и IP успели обменяться добрым десятком пакетов, прежде чем на экране появился хоть один пиксель страницы.

В живых сетях говорят не про семь уровней OSI, а про четырёхуровневый стек TCP/IP (его ещё называют моделью DARPA, по имени агентства, которое финансировало разработку): Network Access (объединяет физический и канальный) → Internet (это IP, аналог сетевого уровня — отсюда, кстати, и название всего стека) → Transport (TCP/UDP) → Application (всё, что выше транспорта, без деления на сессию/представление/приложение).

Разница в подходах не случайна: TCP/IP проектировался инженерами, которым нужно было быстро построить работающую сеть, а не выпустить идеальный по форме стандарт — отсюда и более грубое деление верхних уровней, которое на практике оказалось достаточным. Документы TCP/IP до сих пор называются RFC (Request for Comments) — само название честно отражает происхождение: это были рабочие предложения для обсуждения сообществом, а не финальные постановления комитета.

OSI и TCP/IP не противоречат друг другу — это просто два разных способа резать один и тот же пирог на куски, и инженеры спокойно мешают термины из обеих моделей в одном разговоре: «у нас проблема на третьем уровне» (термин OSI) соседствует с «TCP-сессия зависла» (термин, характерный для мира TCP/IP, хотя сам термин «сессия» в OSI означает кое-что другое) — и всех вокруг это ни капли не смущает, потому что из контекста всё равно ясно, о чём речь.

Привязка устройства к уровню — рабочий инструмент диагностики, а не пункт в учебнике для галочки. Хаб (сегодня музейная редкость, но в старых зданиях иногда всё ещё попадается) просто повторяет электрический сигнал на физическом уровне, ничего не понимая ни про MAC, ни про IP — отправленное в один порт появляется во всех остальных без разбора. Коммутатор уже умнее: принимает решения по MAC-адресам, запоминая, за каким портом какой адрес живёт — это канальный уровень. Роутер смотрит на IP-адреса и решает, в какую сеть пакет отправить дальше — сетевой уровень. Точка доступа Wi-Fi формально работает на физическом и канальном уровнях одновременно, превращая радиоволны в Ethernet-кадры и обратно.

Файрвол классически фильтрует по связке IP-адрес плюс порт (сетевой и транспортный уровень вместе), а современные NGFW (Next-Generation Firewall) лезут ещё выше, разбирая содержимое HTTP-запроса или даже распознавая конкретное приложение по характеру трафика — это уже прикладной уровень. Балансировщик нагрузки бывает L4 (просто раскидывает целые TCP-соединения по серверам, не заглядывая внутрь) или L7 (читает заголовки HTTP и осознанно решает, на какой именно сервер отправить конкретный запрос — например, все запросы на /api/ на одни серверы, а статику на другие). IDS/IPS-системы (обнаружение и предотвращение вторжений) обычно анализируют трафик сразу на нескольких уровнях параллельно, потому что атака может прятаться где угодно — от аномального паттерна TCP-флагов до подозрительной строки в HTTP-запросе.

Знание этой привязки экономит время при поиске причины проблемы: если коммутатор «не пускает» трафик — почти наверняка дело в VLAN или MAC-таблице, а не в IP-адресации, потому что коммутатор про IP вообще ничего не знает и не обязан знать. Идти разбираться в настройки IP на устройстве, которое физически не способно их учитывать, — потеря времени.

Классический подход к поиску проблемы — bottom-up: сначала физика (горит ли линк на порту, не перепутан ли кабель), потом канальный уровень (та ли VLAN, появился ли MAC в таблице коммутатора), потом сетевой (пингуется ли IP, нет ли петли в маршрутах), потом транспортный (открыт ли нужный порт, отвечает ли служба) — и только в самом конце разбираются с логами самого приложения. На каждом уровне есть своя типовая команда: линк и физику смотрят через show interfaces на сетевом оборудовании; MAC-таблицу — через arp -a на хосте или show mac address-table на коммутаторе; маршрут — через ping и traceroute; открыт ли порт — через telnet host port или curl -v, который вдобавок честно покажет, на каком именно шаге (DNS, TCP-соединение, TLS, ответ сервера) всё застряло.

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

Bottom-up — не единственный подход, и не всегда самый быстрый. Если сломалось только одно конкретное приложение, а остальная сеть работает прекрасно, разумнее начать сверху, с самого приложения — глупо проверять кабель, если по тому же кабелю прямо сейчас прекрасно работает что-то другое. Есть и третий вариант — divide and conquer (разделяй и властвуй): начинают с середины стека, например с сетевого уровня (банальный ping), и по результату решают, копать выше или ниже. На практике опытные инженеры интуитивно смешивают все три стратегии, выбирая ту, что быстрее приведёт к ответу в конкретной ситуации, а не следуют ритуалу «всегда снизу вверх» буквально.

OSI — справочная модель для разговора, а не описание того, как на самом деле устроен код реальных протоколов, поэтому часть вещей в неё не укладывается аккуратно, и это совершенно нормально. ARP формально болтается между L2 и L3 — он использует IP-адреса (вроде бы L3), но сам кадр ARP не инкапсулирован в IP и пересылается прямо в Ethernet-кадре (вроде бы L2). ICMP, на котором держится ping, технически передаётся внутри IP-пакетов как полезная нагрузка — но его принято считать частью самого сетевого уровня, а не отдельным протоколом над ним. TLS одновременно немного про шифрование (L6) и немного про установление и поддержание защищённой сессии (L5), и спорить о том, какой именно уровень ему приписать, можно бесконечно без особого практического смысла.

Есть и более вызывающие случаи нарушения чистоты уровней — туннелирование. VXLAN заворачивает целый Ethernet-кадр (L2) внутрь UDP-пакета (L4) для передачи через обычную IP-сеть — пакет в пакете, причём более высокий уровень оказывается снаружи более низкого, что прямо противоречит идее строгой иерархии уровней. GRE и IPsec делают похожее — заворачивают целый IP-пакет внутрь другого IP-пакета. NAT, который разберём отдельной темой этого курса, тоже формально нарушает модель: устройство сетевого уровня (L3) лезет внутрь TCP/UDP-заголовка (L4), чтобы подменить номер порта — по идее ему вообще не положено туда заглядывать.

Если на собеседовании спросят «а на каком уровне точно живёт X» и ответ окажется неочевидным — это не ваша ошибка, это особенность модели почти 40-летней давности, которую заставляют описывать протоколы и приёмы, придуманные через десятилетия после неё. Хороший ответ в такой ситуации — не зазубренная цифра, а объяснение, почему этот конкретный случай не укладывается в схему.

У самой модели OSI нет команд настройки — это не протокол, а способ рассуждать о сети. Но у каждого уровня свой набор диагностических команд, и держать их перед глазами по уровням удобно:

# L1, физический: линк, ошибки, drops
show interfaces              # без аргумента — все порты; можно дописать имя одного

# L2, канальный: кто кого видит
show mac address-table       # какие MAC и на каких портах выучил коммутатор
arp -a                       # -a — показать все выученные пары IP и MAC

# L3, сетевой: доходит ли пакет и каким путём
ping <адрес>                 # доходит ли и за какое время
traceroute <адрес>           # через какие узлы идёт
show ip route                # куда устройство вообще умеет отправлять пакеты

# L4, транспортный: открыт ли порт
telnet <узел> <порт>
nc -zv <узел> <порт>         # -z — только проверить порт, ничего не передавая;
                             #  -v — сказать результат вслух. Без -v команда молча
                             #       вернёт код возврата

# L7, прикладной
curl -v <адрес>              # -v печатает каждый шаг: чей адрес спросили у DNS,
                             #    куда установили TCP-соединение, как прошёл TLS,
                             #    что ответил сервер. По тому, где всё встало,
                             #    сразу видно, на какой уровень смотреть дальше