Отправляется PID вместе с пакетом или нет?

Question

[mifkamaz]

Преподаватель в нашем университете утверждает что PID (Process ID), отправляется в одном из заголовков пакета.
Т.е. для адресации используются IP, port и PID.
Прошерстил основные стандарты RFC сетевого, транспортного, прикладного уровня и нигде не говорится про отправку PID.
Да и везде написанно что в точкой конечной адресации является порт.
Он не хочет верить мне на слово, а документы подтверждающие это не гуглятся(

Где можно найти документы, которые описывают как это происходит на самом деле?

Comments

[VZVZ]

Носом в сниффер ткнуть а не документы

Answer 1

[Владимир Мартьянов]

Снимаете Wireshark'ом траффик с процесса с известным PID'ом, смотрите в сырых данных этот PID. Вообще бремя доказательства лежит на утверждающем, так что попросите препода показать в том же Wireshark соответствующие байты.

Comments

[mifkamaz]

Спасибо за ответ.
Может подскажешь например как происходит передача пакета запроса от ОС к процессу и от процесса к ОС?

[VZVZ]

mifkamaz: Это какие такие запросы ОС делает к процессу? и еще интереснее: какие запросы может делать процесс к ОС? Это о чем вообще? К какой именно части ОС?

[mifkamaz]

VZVZ: Может я не совсем правильно осведомлен, но процесс же не напрямую отправляет запрос, а как бы говорит ОС отправь мне такой запрос, а ОС потом отдает ответ процессу.

[VZVZ]

mifkamaz: тихо шифером шурша, едет крыша не спеша. Вы о каких запросах говорите? Вы о сетевых протоколах передачи данных (TCP и т.д.) или о чем? Если не о сетевых протоколах, то слово "пакеты" вообще как-то не уместно, ну и вопрос ваш без уточнения "какие именно запросы" не имеет смысла.

[mifkamaz]

VZVZ: Ну ок.
Допустим хром отправляет HTTP запрос на пикабу.
Хром генериурет HTTP запрос на страницу, например, pikabu.ru/best, обычный GET запрос без спецэфектов.
И вот мы имеем HTTP запрос на адрес pikabu.ru/best.
Опустим момент получения адреса хоста на котором расположен ресурс.
Начинается формирование самого пакета который уйдет в сеть.
Сначала HTTP обрамляется в TCP (порт отправителя: 131313(допустим его закрепил за собой текущий процесс хрома), порт получателя 80(стандартный для HTTP)).
Обрамляется в IP (получатель отправитель).
Режется на кадры и уходит в сеть.

Приходит ответ от сервера. В каком виде его получает хром?
Прямо целиком в таком виде [ IP [ TCP [HTTP]]]
Или только [HTTP]?
Если только HTTP, то как работает механизм передачи от ОС к хрому?

[vreitech]

mifkamaz: хром получает http.
ос видит, на какой порт приходит пакет, смотрит, какое приложение слушает этот порт и передаёт пакет этому приложению.

Answer 2

[flr]

Во-первых, вы не указали, о каком протоколе идёт речь. Хотя это в данном контексте вряд ли важно.
Во-вторых, не понятно какие стандарты вы шерстили. Если пойти по простому пути и открыть Википедию, то там можно увидеть составы пакетов, например, TCP и UDP (так как протокол из контекста не ясен, берем их).
TCP: https://ru.wikipedia.org/wiki/TCP#.D0.97.D0.B0.D0....
UDP: https://ru.wikipedia.org/wiki/UDP#.D0.A1.D1.82.D1....

Разумеется для обмена данными с внешними источниками PID не используется (если мы говорим про какие-то классические схемы). Во-первых, операционная система знает какой процесс слушает какой порт. То есть если известен порт, то PID не нужен. Во-вторых, один и тот же процесс может слушать разные порты. То есть PID для внешнего источника не является уникальным идентификатором, а порт является.

Итого:
В классических транспортных протоколах — нет, не отправляется. Это просто бесполезная информация для сетевого взаимодействия.

Comments

[mifkamaz]

Я ему примерно тоже самое и сказал. А он мне "Пруфы где?!"

[flr]

mifkamaz: ссылки на википедию не котируются? Они как минимум более весомые, чем его слово. Если у него есть более надежные доказательства, то я всегда готов признать свою ошибку.

[flr]

mifkamaz: и разумеется всегда можно посмотреть tcpdump, я просто сразу опускаю этот момент, так как речь о теоретиках. =)

[mifkamaz]

flr: Ну вообще он всегда приводит в пример chrome. Хром отправляет запрос за http сервер, а сервер должен отдать ему страницу, и что бы это сделать он(сервер) должен знать какому конкретно процессу chrome отдать.

[flr]

mifkamaz: он точно преподаватель?

https://ru.wikipedia.org/wiki/TCP#.D0.97.D0.B0.D0....

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

[mifkamaz]

Да, преподаватель.
Вот например его книга.
www.ozon.ru/context/detail/id/7968881

[flr]

mifkamaz: в таком случае ему не составит труда показать дамп вам tcp пакета, в котором для маршрутизации используется PID.

[res2001]

HTTP работает поверх TCP, TCP поддерживает виртуальное соединение (сессию). Сессии в TCP адресуются с помощью адреса и порта отправителя и адреса и порта получателя. Таким образом обоим сторонам сессии известен и адрес и порт "собеседника". Все данные для адресации должны быть известны еще до установки соединения. Для доказательства того что PID не передается можно просто посмотреть формат IP+TCP заголовка.
Ответ на HTTP запрос приходит в рамках одной сессии. Т.е. проблем со знанием порта chroma у сервера нет.
Вообще довольно странная точка зрения у вашего преподавателя, учитывая, что tcp/ip - это универсальный способ передачи данных по сети, не привязанный к конкретной реализации в конкретной операционной системе. Например, в одной ОС PID может быть целым без знаковым 32 битным числом, а в другой - знаковым 16 битным, а в третьей - вообще идентифицироваться именем исполняемого файла - никаких жестких стандартов по этому поводу нет. А в каких-нибудь встроенных контроллерах вообще нет ОС и нет процессов в общем понимании, но они при этом вполне могут посылать информацию по сети.

[mifkamaz]

res2001: VZVZ: Ну ок.
Допустим хром отправляет HTTP запрос на пикабу.
Хром генериурет HTTP запрос на страницу, например, pikabu.ru/best, обычный GET запрос без спецэфектов.
И вот мы имеем HTTP запрос на адрес pikabu.ru/best.
Опустим момент получения адреса хоста на котором расположен ресурс.
Начинается формирование самого пакета который уйдет в сеть.
Сначала HTTP обрамляется в TCP (порт отправителя: 131313(допустим его закрепил за собой текущий процесс хрома), порт получателя 80(стандартный для HTTP)).
Обрамляется в IP (получатель отправитель).
Режется на кадры и уходит в сеть.

Приходит ответ от сервера. В каком виде его получает хром?
Прямо целиком в таком виде [ IP [ TCP [HTTP]]]
Или только [HTTP]?
Если только HTTP, то как работает механизм передачи от ОС к хрому?

[mifkamaz]

SyavaSyava: посмотри комент выше пожалуйста

[mifkamaz]

flr: посмотри комент выше пожалуйста

[res2001]

Хром получает только HTTP ответ (внешний слой инкапсуляции пакета уже обработан ОС), но т.к. на момент получения ответа соединение уже установлено, то хром знает и адрес и порт сервера, и свои то же знает, конечно.
В ОС есть таблица соответствия номера порта и процесса открывшего этот порт. Но на самом деле ОС не отправляет данные процессу из таблицы, а процесс сам читает свой сокет (читай "данные пришедшие на свой порт"). Это сделано так, потому что, например, возможна ситуация, когда TCP соединение устанавливает один процесс, а прием/передачу данных по этому соединению осуществляет другой.
В винде посмотреть таблицу можно:
netstat -ab
Правда PIDы не отображаются, но имя процесса есть, на самом деле, конечно, в таблице лежат PIDы, а уже из них netstat получает имена процессов.
В никсах есть аналогичная команда:
sockstat - во FreeBSD
В линуксе то же она должна быть, но точно не скажу, т.к. с линуксом мало имею дела.

[Mystray]

mifkamaz: Если преподаваемый материал в целом такой же, как и эта методичка, то мои соболезнования. Жуткая каша из "голой" теории, ISO и TCP/IP, с отсылками на ITU, RFC и прочие ISO к месту и не к месту, понять из которой, что же реально применяется, а что умерло, не родившись, нереально.
Стоит уточнить, имеет ли ввиду преподаватель конкретно TCP/IP. Потому что он вполне может иметь и что-то другое. Может быть и не существующее.
Вообще, почитайте его же методичку в районе 25 страницы. Такие преподы, как правило, любят, когда их книги цитируют.

[mifkamaz]

Mystray:
"На этапе установления виртуального соединения средства сеансовой службы организуют порты с адресами с и d и сопрягают порты с
точками a и b процессов А и В. Адреса портов запоминаются в блоках связи процессов."
Это как раз с 25-ой страницы.
Тут как бы написанно что процессы сами запонимают свой порт.

Вот полный абзац.

"Основными адресуемыми объектами являются процессы и порты, через которые процессы обмениваются данными. Порты организуются средствами управления сеансами (уровень 5 на рис.1.4 и 1.5), а передача данных между СПД и портами обеспечивается транспортной службой (уровень 4). Для функционирования сети необходимо идентифицировать соединения, установленные между процессами и их портами через СПД. Соединения идентифицируются парами адресов портов, например по схеме, изображенной на рис.3.1. Здесь А — адрес процесса, ввод-вывод данных в котором производится через логическое устройство ввода-вывода а, рассматриваемое в качестве источника- приемника данных. Процесс идентифицируется адресом А.а. Аналогично идентифицируется процесс В, принадлежащий другой системе. Связь между процессами описывается блоками связи, хранимыми в соответствующих системах. На этапе установления виртуального соединения средства сеансовой службы организуют порты с адресами с и d и сопрягают порты с
точками a и b процессов А и В. Адреса портов запоминаются в блоках связи процессов. СПД обеспечивает передачу данных, которыми процессы обмениваются через порты c и d, в узлы m и n, к которым подключены соответствующие системы. Средства транспортной службы (ТС) передают данные между СПД, т.е. узлами подключения m и n, и портами с и d."

Answer 3

[Владимир Дубровин]

На уровне сети (IP) и транспорта (UDP, TCP) pid не передается. Процесс, которому предназначем полученные данные транспортного уровня, определяется по принадлежащему ему слушающему сокету, который определяется IP адресом, протоколом и портом.