Взаимодействие уровней сетевых моделей?

Question

[Сергей Малинин]

Здравствуйте!
Как взаимодействуют между собой протоколы разных уровней сетевых моделей (OSI и пр.)?
Много написано о самих уровнях, но о том, как данные перемещаются между ними, обычно не говорят. Ну или я не нашел / не понял.
Сама по себе мысль, что протокол вышележащиего уровня вкладывается в качестве полезной нагрузки в протокол нижележащего уровня - понятна.
Как именно это происходит?
Например, браузер. Вот мы ввели qna.habr.com, браузер хочет открыть HTTP соединение. Он формирует набор данных для передачи, затем стучится вниз, на уровень TCP, и говорит: "вот у меня пачка данных, передай их серверу на таком-то адресе". TCP, в свою очередь, стучится на уровень IP и просит о том же самом?
Тогда что конкретно означает "стучится вниз/вверх"? Ищет службу, которая может обслужить подобный запрос, и связывается с ней через некоторый интерфейс межпроцессного взаимодействия?
Спасибо.

Comments

[mayton2019]

Вы пропустили DNS запрос. И его хранилище записей.

В целом такая интересная метафора возможна. Только описывать ее словами очень долго.

Здесь - взаимодействие как минимум 2х конечных автоматов. Ваше приложение. И tcp-сокет. Так я себе это вижу. Под воздействием методов эти автоматы асинхронно переходят в разные состояния. Здесь я еще не учел HTTP(s) (TLS/SSL). Там тоже идет внутренний диалог и в нем тоже есть состояния. Есть хранилище сертификатов у вас в браузере оно - тоже участник этого процесса.

Возможно сетевики найдут еще больше состояний. Я не против. Вот как-то так.

Описывать это в терминах "стучится вверх или вниз" неудобно. Удобнее - переходит в состояние. И делает при этом действие.

[Сергей Малинин]

Любопытно, действительно.
Получается такой как бы каскад: событие в одной точке меняет состояние в другой. Это событие, в свою очередь, меняет состояние в третьей, и так до провода/эфира, а потом назад.
Но структурно: приложение взаимодействует с некоторыми системными библиотеками, те - с драйвером сетевой карты. Так?

[pfg21]

Сергей Малинин, нэт.
приложение работает с одной конкретно выбранной "библиотекой": командами http-проткола, tcp-драйвера или udp-драйвером и фсё
дальнейшие блуждания информации приложению обычно не известны.
всю остальную цепочку формирует операционка на основе своих настроек.

Answer 1

[hint000]

что конкретно означает "стучится вниз/вверх"? Ищет службу, которая может обслужить подобный запрос, и связывается с ней через некоторый интерфейс межпроцессного взаимодействия?

Часть имплементации сетевого стека содержится в ядре операционной системы, часть - в драйвере сетевого адаптера, часть - в железе сетевого адаптера. Некоторые протоколы вынесены в службы\демоны (ppp, pptp, openvpn,..). Протоколы 6-го и 7-го уровня реализуются либо в службах, либо в прикладных программах.

Например, браузер. Вот мы ввели qna.habr.com, браузер хочет открыть HTTP соединение. Он формирует набор данных для передачи, затем стучится вниз, на уровень TCP, и говорит: "вот у меня пачка данных, передай их серверу на таком-то адресе".

Браузер сначала на уровне API операционной системы обращается к резолверу (клиенту DNS), резолвер (сперва проверив свой кэш) берёт адрес DNS-сервера из настроек ОС и стучится на порт 53/UDP с запросом, а не "ищет службу". Получает ответ и передаёт его браузеру. Браузер запоминает IP-адрес хоста qna.habr.com и снова через API операционной системы говорит "хочу установить соединение с хостом, адрес такой-то, порт 443/TCP". ОС устанавливает соединение, сообщает об этом браузеру и передаёт какой-то там хэндлер, через который можно использовать уже готовое TCP-соединение. Дальше браузер просто заливает свои данные в соединение, и читает оттуда же ответы. Более высокий уровень - протокол 7-го уровня http - браузер реализует самостоятельно, вот прямо самостоятельно, никого ни о чём не просит, когда дело в http. Более низкие уровни - как уже сказал, на совести ОС, драйвера, железа. Чтобы обеспечить высокую эффективность, там взаимодействие довольно низкоуровневое, такая каша, что не только в рамках ответа, а даже в рамках статьи не описать, целая книга нужна, а то и не одна. Причём для каждой ОС своя отдельная книга, в Linux сетевой стек будет отличаться от сетевого стека Windows, сетевого стека MacOS, сетевого стека BSD.

Comments

[Сергей Малинин]

Во! То, что надо. Большое спасибо!
И всем, кто поучаствовал в ответах - тоже огромное спасибо!

[hint000]

Сергей Малинин, ещё можно посмотреть интересную диаграмму про то, как гуляет сетевой пакет по частям операционной системы Linux: https://commons.wikimedia.org/wiki/File:Netfilter-...
другая популярная версия того же самого: https://stuffphilwrites.com/wp-content/uploads/201...
Другой уровень: https://openwrt.org/docs/guide-developer/networkin...

Answer 2

[Saboteur]

А что ты уже читал хотябы в википедии?

Ну вот например протокол низкого уровня - мы по кабелю пересылаем данные при помощи дискретного сигнала. Это же явно уровень ниже, чем HTTP
или вместо кабеля на каком-то этапе нам нужно перейти на wifi, и передавать данные уже радиоволной, со своими особенностями, синхронизацией сигнала, отвержением отраженных повторений.

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

Comments

[Сергей Малинин]

Читал, конечно - про OSI, стек TCP/IP и вокруг этих тем. Я и говорю: про сами уровни, что происходит на каждом из них - понятно. Не понятно, как данные попадают с одного уровня на другой.

[Vitsliputsli]

Сергей Малинин, данные не "попадают с одного уровня на другой". Откройте пакет в сниффере, том же Wireshark и посмотрите. В начале пакета будут адреса уровня Ethernet, потому будут адреса TCP/IP, а дальше будут данные HTTP.

[Сергей Малинин]

Какжется, я неудачно задал вопрос ))
Попробую уточнить.
Я знаю, что кадр ethernet это матрешка из протоколов. Я не понимаю, как эту матрешку получают.
Вот браузер. Я правильно понимаю: он "знает", что для передати своих данных по HTTP ему нужно открыть TCP соединение? Если да - то он это делает сам или с помощью отдельной службы ОС?
Или, другими словами: код, реализующий используемые для связи протоколы - это часть каждой отдельной программы, использующей сеть, или это общие для всех службы, работающие в ОС, к которым обращается программа, желающая работать с сетью?

[pfg21]

Сергей Малинин, да. http открывает tcp-соединение в посылает/полчает из него http-команды и данные как в обычный поток ввода/вывода. http хвататает потока ввода/вывода и больше ничего не волнует.
tcp получает данные с потока нарезает на требуемые по условиям кусочки (MTU и иже с ним) и записывает необходимый заголовок tcp-сегмента и передает пакетом в нижний слой.
плюс открывает, контролирует работу и закрывает работу tcp-потока.
нижний слой (будь он хоть IPv4 IPv6 (они сильно отличаются :)) или иной типа GRE) обрабатывает пакет данных добавляя свои заголовки в пакет и передает разросшийся на заголовок пакет дальше, согласно настройкам сетевой инфраструктуры данного компутера.
и т.д. и т.п.

[Saboteur]

Сергей Малинин, Приложения пользуются стандартными API операционной системы.
Соответственно браузер не будет обращаться к драйверу сетевой карты. Он будет обращаться к tcp подсистеме через стандартный API запрос. А TCP подсистема виндовс уже знает как она сейчас сконфигурирована и куда дальше маршрутизировать пакет - в драйвер проводной сетевушки или драйвер блутус или драйвер модема.

Поэтоум да, есть службы ОС, которые отвечают за сеть.

Answer 3

[Владимир Коротенко]

На примере письма

Вы пишете письмо- прикладной уровень
Либо электронное либо бумажное протокольный уровень
Его доставляют либо по земле либо по воздуху либо по энтернету это уже физика
На каждом уровне лепят марку от кого и куда

Когда идёт в обратную эти марки снимают и вы получаете ответ в итоге ваше письмо выглядит так в идеале

7654321234567

Comments

[Сергей Малинин]

Вот, вот, давайте конкретизируем - кто и что делает?
Я же не бросаю письмо в окно - несу его на почту. Оттуда его тоже грузят не на первый попавшийся велосипед.
В реальной жизни мы понимаем, кто перетаскивает письмо между каждым из уровней и почему это делает. А в сетях?

[pfg21]

Сергей Малинин, а в сетях "кто" определяется настройкой сетевого стека.
к примеру вот будет цепочка спутеществием данных по стеку вверх-вниз
http-клиент - tcp - ipv4 - ethernet - (медный LAN кабель) - ethernet - свитч(mac-маршрутизатор) - ethernet - (медный LAN кабель) - ethernet - роутер(ipv4-роутер с NAT) - ethernet(оптический) - (оптоволокно) - "провайдер" - ethernet - ipv4 - tcp - http-сервер
на каждом уровне пакет будет очищаться от нижнеуровненевых оболочек или обратно запаковываться.

[Сергей Малинин]

Значит, каждый уровень должен знать о двух смежных - верхнем и нижнем. Он узнает о них из каких-то конфигов?
Другими словами - эту цепочку определяет разработчик? Но в какой степени? И тогда ОС (как минимум) должна включать в себя реализации хотя бы наиболее популярных протоколов и иметь возможность установки других?

[Владимир Коротенко]

Сергей Малинин, RFC RTFM

[pfg21]

Сергей Малинин, цепочку формирует администратор системы на котором онное ПО работает.
к примеру я для доступа к закртым ресурсам могу использовать впн. и настрою сетевую подсистему чтобы часть потока пакетов ipv4 перенаправлялось не в etnernet драйвер с последующей передачей через сетевую карту, а к примеру в драйвер openvpn, который пакеты обработает/зашифрует и сформирует новый поток данных через tcp
современная ОС вообще до хрена чего в себе содержит :)

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

Answer 4

[Василий Банников]

Никто никуда не стучится.
Просто "открытие http соединения" подразумевает собой открытие TCP.
Открытие TCP подразумевает, что сетевая карта будет отправлять IP-датаграммы и так далее.

Comments

[Сергей Малинин]

По-человечески это понятно, конечно. Но ведь в компьютерных системах нет такого понятия. Понятна, например, событийная модель: я нажал кнопку в форме - движок браузера сгенерировал событие - его получили подписчки - подписчики отреагировали. Все участники видны, их роль ясна. А в стеке протоколов как?

[Василий Банников]

Сергей Малинин, Ты в прикладном коде пишешь "Отправить такой-то HTTP запрос".
Где-то в кишках используемой библиотеки вызывается какая-нибудь функция ОС, чтобы открыть TCP соединение.
Затем ядро ОС через драйвер обращается к сетевой карте, которая и знать то не знает, что существует какой-то HTTP.
А дальше уже всякие совсем низкоуровневые вещи рядом с физическим уровнем.
Никакого попадания из верхнего в нижний нет - нижние уровни тащат данные от всех верхних уровней, но при этом они для него "просто какие-то данные"

[Сергей Малинин]

Вот, вот оно.
Значит, приложение, желающее использовать сеть, делает примерно так:
-упаковывает данные в свой прикладной протокол (HTTP, SMTP, и т.д.);
-делает системный вызов к некоторой службе ОС для открытия TCP соединения;
-эта служба, в свою очередь, инициирует формирование IP-пакета;
-карта отправляет пакет в физическую среду.
Верно?

[Василий Банников]

Сергей Малинин, в моём представлении да, как-то так.

[hint000]

Сергей Малинин,

делает системный вызов к некоторой службе ОС для открытия TCP соединения;

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

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

[res2001]

Сергей Малинин,

Верно?

Только отчасти. Так мы сформировали IP пакет. Но есть уровень ниже, Ethernet например. Т.е. еще надо ethernet фрейм таким же макаром соорудить поверх IP пакета. Этим обычно драйвер сетвого адаптера занимается. Ну а дальше уже железо пошло запихивать биты в провода.

[Сергей Малинин]

Ммм... Так. Свет в тоннеле становится всё ярче )
А если это не служба, то что?

[pfg21]

Сергей Малинин, демон драйвер или чтото еще, как его ни назови :)
некоторая програмная сущность используемая системой для проведения каких-либо действий.

Answer 5

[res2001]

Взаимодействие между уровнями - это детали реализации.
Тот же TCP/IP можно реализовать очень по разному с разными интерфейсами для прикладного приложения.
Наиболее распространенное сейчас сетевое API это Berkeley Sockets (или просто сокеты). Сокеты реализуют в т.ч. и взаимодействие по TCP/IP. Есть и другие сетевые API, например TLI, но я никогда в реальности не встречал его использования.
Сетевое API - это то с помощью чего прикладной программист использует сеть. Внутри тех же сокетов есть свои интерфейсы для передачи между сетевыми уровнями.

Comments

[Сергей Малинин]

Всё так, но вот как раз о деталях реализации и хочется составить представление!

[res2001]

Сергей Малинин, Детали платформозависимые. Поэтому ваш вопрос сильно абстрактен, нужно уточнять платформу для которой нужны детали.
Вообще теория по сетям хорошо описана у Олиферов и у Таненбаума.
В плане программирования можно почитать Unix. Разработка сетевых приложений Стивенса. Книжка хоть уже и старая, но актуальность не потеряла. Тут описаны сокеты применительно к Unix/Linux системам. В винде то же сокеты, но со своим "акцентом".