Как принимающая сторона сопоставляет пакеты с сообщениями при передаче данных по сети?

Question

[Andreany]

На собеседовании на позицию C++ разработчика задали следующий вопрос:

"Мы отправляем несколько логических сообщений по сети. Каждое сообщение разбивается
на пакеты и передаётся получателю. Пакеты могут приходить не по порядку.
Вопрос: как принимающее устройство понимает, к какому сообщению относится каждый пакет,
и в каком порядке их нужно собрать?"

Интересует ответ на уровне сетевых протоколов (TCP/UDP), а не прикладной логики.
Также буду благодарен за пояснение, какие механизмы работают на разных уровнях OSI.

Comments

[pfg21]

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

[Кот Абсолютный]

Окей, гугл. Дай ссылку на RFC по TCP.

Берем ссылку и читаем, читаем... А про OSI читаем олиферов - уж понятнее учебника никто не обьяснит.

Answer 1

[Mors Clamor]

Этот момент описан в RFC по TCP и полезнее для Вас же будет изучить этот момент самостоятельно. Вопрос простой, только вот непонятно почему он прозвучал на собесе на разработчика C++, если в вакансии не было заявлено хорошее понимание TCP/IP

Comments

[SunTechnik]

Судя по всему, у автора вопроса нет вообще понимания основ tcp/ip.
А что за разработчик, который этого не знает?

[pfg21]

SunTechnik, разработчик каких-нить не сетевых алгоритмов :)

[Mors Clamor]

SunTechnik, для любого не-сетевика достаточно понимания, что TCP это гарантированная доставка с подтверждением, подробности ни к чему. Если только да, это не разработчик сетевого стека.

Answer 2

[SunTechnik]

При использовании TCP - устанавливается соединение. Протокол сам разбивает данные на пакеты, отслеживает доставку, порядок. Если в течении timeout пакет не был доставлен - делает повторную отправку данных (пока не сможет доставить, или вернёт ошибку, что соединение умерло) . Ваша задача - только кидать и забирать данные.

При использовании UDP —не гарантируется ничего. Пакеты могут приходить в любом порядке, теряется, задваиваться - задача самого приложения разруливать этот бардак... Но если частичные потери пакетов не страшны - это позволяет экономить время/ресурсы что бы не посылать повторно, что уже не актуально...

Ps, но лучше все же - почитать теорию. Главы из учебника тут никто цитировать не будет...

Comments

[Mors Clamor]

Вы кстати так и не ответили на вопрос автора - КАК это происходит

[Daemon23RUS]

Mors Clamor, Оффтоп. Мы раньше RFC TCP/IP разбирали по битам, и помнили его чуть ли не наизусть. Интересно как сейчас обстоят дела у студентов ? Меня волнует, как бы чего не вышло по типу "Утерянные знания древних цивилизаций". Буду признателен за любой фидбэк от всех кто в теме и прочел этот комментарий.

[Mors Clamor]

Daemon23RUS, RFC по биту разбирать? Ладно
Как практикующий инженер могу сказать, что если вы не работаете с чем-то достаточно часто, то знания забываются и упрощаются. Так как я самоучка (в нашей шараге формально был предмет Компьютерные сети, но преподавателя я не видел), то могу лишь сказать что "по битам" RFC никто не разбирает. Во-первых, потому что есть различные адаптации этого же материала (у RFC очень специфичный язык даже для технарей), во-вторых, потому что когда ты читаешь вторую половину, первую ты уже забыл.

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

Поэтому RFC используется как справочная информация, КАК ДОЛЖЕН работать протокол для вендоров и инженеров, а не как то, что нужно держать в голове постоянно (оперативки не хватит)

А касательно TCP/IP, вы, я уверен, сможете назвать основные механизмы, возможно даже механизм работы плавающего окна и congestion control, scale-factor. А вот по поводу каких-нибудь SACK, Fast-Open уже как будто не уверен, хотя всё может быть

[Daemon23RUS]

Mors Clamor, SACK, TFO появился гораздо позже моего первого знакомства с TCP/IP и описанных мной "мучений" (причем это было на ASM позже С) тогда и вменяемых библиотек то не было. Ну и как следствие свелось это (RFC) действительно, к тому, как должен работать протокол, без необходимости самостоятельно это писать.

[alexalexes]

Сейчас в RFC рука тянется посмотреть только когда нужно собрать свою обертку интерфейса, чтобы отправлять пакет с данными "как в стандарте". Обычно, разработчики на этот уровень не спускаются, так как велика вероятность, что есть готовая библиотека, которая сформирует необходимое сообщение, просто правильно подергав API библиотеки.