Статья для большинства покажется очень легкой и что это все знают, но я все-таки решил ее написать.

Модель OSI выглядит так:

Описывать то делают на каждом уровне я не хочу, так как этого описания в интернете и так навалом.

Поговорим на самом деле о другом:

А зачем это учат если это не видно?

Вот тут мы подходим к самому важному вопросу, зачем все это сделано.

А сделано это для того чтоы четко определять стандарт работы.

То есть каждый уровень может строится на разных технологиях, НО эти уровни не должны затрагивать другие.

То есть когда ты что-то хочешь сделать ты определяешь на каком уровне это работает и пишешь протокол взаимодействия только для этого уровня.

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

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

Все проблемы благодаря модели OSI можно четко отслеживать по уровням снизу вверх.

Первое — горит ли лампочка на сетевушке, arpping — видимость мак адресов вокруг, ping любого адреса в 127 сетке — проверка стека, просмотр таблицы маршрутизации, пинг ближайшего шлюза, трасерт нужного адреса, проверка через dig или nslookup dns и потом проверка порта на нужном сервере.

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

Теперь мои небольшие размышления по поводу модели OSI и как это иногда используется. Это мои догадки, почему так сделано переписку разработчиков я не нашел.

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

Именно поэтому если запретить хождение через обратную петлю на компьютере графическая система упадет.

То есть так как общих драйверов не было для обращения к видеокарте был создан на прикладном уровне прокол прорисовки и через обратную петлю на сервер шлется запрос Xserver его обрабатывает и отрисовывает.

То есть этим решили вопрос совместимости по драйверам и сделали возможность модульной архитектуры. Работать с разными видео-картами для отрисовки картинки.

Я сильно подозреваю что и wayland работает по тому же принципу, но, честно говоря я пока еще его не смотрел.

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

Именно поэтому надо понимать модель OSI и на каком уровне у тебя работает тот или иной протокол.

upd: велком в комменты, давайте спорить

Комментарии