Как раздельно передать сообщения, которые не помешаются в один пакет?

Question

[BUTURUM]

В нашем прекрасном мире существует такой прекрасный протокол передачи данных как tcp/ip. Он позволяет передавать информацию дробя её на пакеты. Пакеты это хорошо, но я до сих пор не вдупляю как протоколы основанные на TCP умудряются передать цельно сообщения, в несколько пакетов. Возьмём тот же самые HTTP, вряд-ли даже GET запрос отправляться в один пакет, но каким-то обзором сервер понимает что все пакеты переданы и можно начинать разбирать запрос, притом что соединения не обрывается. Я же хотел написать протокол для своего приложения (локального мессенджера), который сможет передать зашифрованные сообщения по TCP/IP соединению от обоих его участников, желательно параллельно. Сообщения как вы понимаете в один пакет не влезет, поэтому нужно как-то объяснить получателю что все пакеты одного сообщения переданы.

Answer 1

[Ярослав]

А всё просто )
Когда Вы работаете с протоколом TCP, вы не оперируете понятием "пакет": TCP скрывает от Вас тот факт, что сообщение при передаче каким-то образом разбивается на отдельно передаваемые фрагменты.
Причём, уровень шифрования, например, SSL/TLS, большинство библиотек реализуют прозрачно и незаметно для Вас, поэтому Ваша программа может и не знать, что в какой-то момент данные на отправке зашифровываются, а на приёме расшифровываются.

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

Например, популярной является разметка TLV: Tag-Length-Value
Tag: тип сообщения или некоторый маркер начала нового сообщения. Как правило, это поле фиксированной длины, например, 1 байт.
Length: длина сообщения. Поле фиксированной длины, например, 4 байта.
Value: само передаваемое сообщение переменной длины.

Какое какое именно значение передавать в Length - решать Вам.
Можно сделать так:
Length = длина_поля_в_байтах(Value)
А можно и так:
Length = длина_поля_в_байтах(Tag) + длина_поля_в_байтах(Length) + длина_поля_в_байтах(Value)

Не надо опасаться, что, начав читать из TCP-соединения, Вы начнёте читать его "с середины": протокол гарантирует, что Вы при чтении увидите байты в том же самом порядке, в котором они были отправлены в вашу сторону с той стороны.

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

2. Будьте готовы к тому, что Вы можете начать читать некоторое сообщение в тот момент, когда его отправка с той стороны уже начата, но ещё не завершена.
Зато, Вы можете в любой момент посмотреть, сколько там байт уже прилетело и накопилось в буфере приёма.

Пример: допустим, Вы ожидаете сообщение длиной 100 байт.
Возможна ситуация, когда Вы прочитали из соединения 50 байт, а затем Вы получаете уведомление "больше данных нет". Это означает, что оставшиеся 50 байт всё ещё где-то в пути; Вам следует периодически повторять процедуру чтения из соединения до тех пор, пока Вы не получите, вероятно, за несколько приёмов, оставшиеся данные.

Получается, на псевдокоде пусть не оптимальная, но зато простейшая логика чтения каждого нового сообщения в разметке TLV может иметь следующий вид:

пока (соединение_не_закрыто):
    подождать_пока_в_буфере_приёма_не_окажется_байт(1)
    tag = прочитать_байт(1)

    подождать_пока_в_буфере_приёма_не_окажется_байт(4)
    length = прочитать_байт(4)

    подождать_пока_в_буфере_приёма_не_окажется_байт(length)
    value = прочитать_байт(length)

    обработать_новое_сообщение(tag, value)

Подобная логика позволит Вам нормально обработать ситуацию, когда кто-то отправил Вам два сообщения подряд, но сразу до Вас первое сообщение долетело целиком, а от второго - только первая половина: столько влезло в один TCP-пакет. Вторая же половина второго сообщения в следующем TCP-пакете может прилететь даже и через полчаса.

Comments

[BUTURUM]

сделал приблизительно также. Спасиьо за помощь!

Answer 2

[Рональд Макдональд]

Курите модель OSI.

Данные в TCP (4 уровень) никак не связаны с тем, что там в GET (7 уровень), ему вообще наплевать.

И ещё подробно раскурите протокол TCP (читайте Куроуза и Олиферов), там просто и понятно объясняется, как TCP понимает, как управлять потоком, как понять, на сколько частей дробить и как понять, что все части собрались воедино.

Ваш протокол 100% будет работать на прикладном, 7-ом уровне и TCP по барабану, шифрованные данные там передаются или нет.

Comments

[BUTURUM]

Модель OSI я знаю, имменно поэтому вопрос был в том как же сделать протокол над TCP чтобы сообщения в несколько пакетов слать.
>Читайте Куроуза и Олиферов
Зарание спасибо за книгу, только я не знаю как она назваться (по авторам её не так уж просто найти)
>Ваш протокол 100% будет работать на прикладном, 7-ом уровне и TCP по барабану, шифрованные данные там передаются или нет.
Я обещаю вам что в аббревиатуре названия этого протокола, будет отдельной буквой указанно что он прикладной.

[Рональд Макдональд]

BUTURUM, книги Олиферов гуглятся по фамилиям авторов, а книга Куроуза называется "Компьютерные сети. Нисходящий подход".
Не совсем понял, вы хотите принудительно поделить сообщение на несколько TCP-пакетов? Прошу пардона, иногда я не до конца понимаю, что мне пишут.

[BUTURUM]

Рональд Макдональд, нет я хочу чтобы большие сообщение имели возможность передаваться в несколько пакетов. Прошу пардона, это скорее я иногда не понятно пишу.

[Рональд Макдональд]

BUTURUM, они и так будут передаваться в виде нескольких пакетов, если TCP MSS (максимально возможный размер пакета TCP) будет меньше, чем размер передаваемых данных.
А он 100% будет, потому что обычно размер TCP-пакета - не больше 1,5 Кб минус служебные данные.

[BUTURUM]

Рональд Макдональд, да но потом эти пакеты нужно объединить в одно цельное сообщение, а их по одному соединению будет гонятся много. То есть нужно как-то сообщить получателю что все пакеты отправлены и можно начинать обработку сообщения, не обрывая соединение.

[Рональд Макдональд]

BUTURUM, просто передать его одним HTTP (им же?)-запросом. TCP сам его соберёт.

[BUTURUM]

Рональд Макдональд, я задавал этот вопрос для того чтобы вместо HTTP использовать, свой протокол

[Рональд Макдональд]

BUTURUM, а, так без разницы. Всё равно вы на 7-ом уровне, а TCP на 4-ом, просто не думайте о нём, он всё сделает сам.
Просто реализовывайте свой протокол (текстовый, бинарный) - не важно, TCP самостоятельно и без внешнего вмешательства разделит его, передаст и склеит обратно.

[BUTURUM]

const net = require('net');

let socket = new net.Socket()

net.createServer((socket) => {
    socket.on('data', (data) => {
        console.log('data: ', data.toString('utf8'))
    })
}).listen(3000);

socket.connect({
    host : 'localhost', port : 3000
}, () => {
    socket.write(Buffer.from('msg1'.repeat(100000), 'utf8')); // send first massege
    socket.write(Buffer.from('msg2'.repeat(100000), 'utf8')); // send second massege
})

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

[Lynn «Кофеман»]

BUTURUM, так это вам нужно на уровне вашего протокола разбирать. В том же http есть заголовок content-length, например

Answer 3

[res2001]

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

Протокол, который ориентирован на передачу отдельных сообщений (пакетов) - UDP. Он то же входит в набор протоколов TCP/IP.