Здравствуйте, Marty, Вы писали:

M>Неясна связь с типом данных
+100500
Да, теоретически — вроде как её и не должно быть, как я понял изучая литературу по TCP.

Но практика, когда дробление на фрагменты начинается от 14 килобайт — для английских однобайтовых символов (когда передаём только JSON-текст);
и примерно от 1400 байт — для потока двоичных сериализованных данных.
О чём говорит?

Есть предположение, что софт поддержки TCP всё-же анализирует контент в канале (хотя бы на соответствие KOI8 или Latin1).

P.S. Приведу цифры, полученные при передаче JSON блоков данных на сети от Сервера к Клиенту
(они на разных компах, соединены витой парой; на обоих машинах OS Ubuntu 18.04):

LEN (длина блока, байт) Факт разделения блока на фпагменты
____________________________________________________________________
18494 +
14512 +
13911 иногда имело место
27148 +
14243 +
7727 -

Здравствуйте, Marty, Вы писали:

M>Неясна связь с типом данных
+100500
Да, теоретически — вроде как её и не должно быть, как я понял изучая литературу по TCP.

Но практика, когда дробление на фрагменты начинается от 14 килобайт — для английских однобайтовых символов (когда передаём только JSON-текст);
и примерно от 1400 байт — для потока двоичных сериализованных данных.
О чём говорит?

Есть предположение, что софт поддержки TCP всё-же анализирует контент в канале (хотя бы на соответствие KOI8 или Latin1).

P.S. Приведу цифры, полученные при передаче JSON блоков данных на сети от Сервера к Клиенту
(они на разных компах, соединены витой парой; на обоих машинах OS Ubuntu 18.04):

LEN (длина блока, байт) Факт разделения блока на фпагменты
____________________________________________________________________
18494 +
14512 +
13911 иногда имело место
27148 +
14243 +
7727 -

Здесь ясно видно, что JSON блок в 7 килобайт проходит без разделения на фрагменты. Как объснить данный феномен (при MTU = 1500)?