Модель OSI: 7 уровней сети

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

Словарём она и осталась. Когда админ говорит «это проблема на втором уровне», а в описании оборудования написано «коммутатор L3», обе фразы понятны без расшифровки — обе указывают на конкретное место в общепринятой схеме. Без такой схемы каждый разговор про сеть начинался бы с объяснения, о какой именно части системы речь.

Главная практическая польза — порядок действий

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

Опытный инженер этот порядок держит в голове автоматически и часто перескакивает сразу к вероятной причине. Новичку же модель заменяет опыт: она не даёт распыляться и превращает панику в конечный список из семи пунктов.

Уровни принято нумеровать снизу вверх: первый — самый близкий к железу, седьмой — к пользователю. У каждого есть собственное название для порции данных, которой он оперирует (в теории это называют PDU — protocol data unit), и это не занудство: именно поэтому одни и те же данные на разных уровнях называют то кадром, то пакетом, то сегментом.

На практике сетевик почти всё время живёт на четырёх нижних уровнях: L1–L4. Уровни с пятого по седьмой в реальных протоколах обычно слиты воедино — разделить в HTTPS, где заканчивается «представление» и начинается «приложение», можно только теоретически, и никакой пользы от этого нет.

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

На конкретном примере

Вы открываете сайт. Браузер формирует запрос GET /index.html — это L7. Транспортный уровень режет его на сегменты и подписывает: «от порта 54321 к порту 443» — теперь понятно, какой программе на сервере отдать данные. Сетевой уровень добавляет «от 192.168.1.50 к 93.184.216.34» — теперь понятно, куда вообще везти. Канальный добавляет «от моей сетевой карты к MAC-адресу роутера» — теперь понятно, кому передать прямо сейчас. Физический превращает всё это в электрические импульсы.

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

Побочный эффект: накладные расходы и MTU

Заголовки занимают место. В обычной сети Ethernet за раз можно передать 1500 байт полезной нагрузки — это значение называют MTU. Заголовки IP и TCP съедают из них около 40 байт, и приложению остаётся примерно 1460. Если данных больше, они режутся на несколько пакетов.

Знать про MTU стоит по одной практической причине: любой туннель (VPN, PPPoE у провайдера) добавляет свой заголовок поверх существующих, и эффективный MTU уменьшается. Когда «почта работает, а сайты открываются наполовину», виноват обычно именно он: маленькие пакеты проходят, большие — нет.

Стек TCP/IP, на котором реально работает интернет, устроен проще — в нём четыре уровня вместо семи. Он не заменяет модель OSI, а описывает ту же реальность крупнее.

Расхождения между моделями начинаются в деталях, и спорить о них можно долго. Классический пример — ARP: он переводит IP-адреса в MAC-адреса, то есть связывает два уровня сразу, и куда его отнести, зависит от учебника. На практике это ни на что не влияет: важно понимать, что протокол делает, а не к какой полке его приписали.

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

Пример из жизни. Пользователь жалуется, что не открывается внутренний портал. Ping до сервера проходит — значит L1–L3 в порядке, кабель и маршруты можно не трогать. Подключение на 443-й порт не устанавливается — проблема на L4 или выше: либо служба не слушает, либо мешает фаервол. Две команды отсекли половину возможных причин.

Кабель, патч-корд, трансивер — физический уровень: они передают биты и ничего не знают про адреса. Коммутатор работает на канальном: смотрит на MAC-адрес и решает, в какой порт отправить кадр. Маршрутизатор — на сетевом: смотрит на IP-адрес и выбирает, в какую сеть передать пакет дальше. Фаервол, фильтрующий по портам, работает уже на транспортном.

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

Самый наглядный способ увидеть уровни своими глазами — открыть любой перехваченный пакет в Wireshark. Он показывает ровно ту матрёшку, о которой шла речь: сначала строка Ethernet с MAC-адресами, под ней Internet Protocol с IP-адресами, ещё ниже TCP с портами и флагами, и в самом низу — данные приложения.

Для быстрой проверки Wireshark даже ставить не обязательно: tcpdump -nn -i eth0 host 192.168.1.10 в Linux покажет то же самое текстом. Ключ -nn отключает преобразование адресов и портов в имена.