Минимальный размер TCP/IP

Question

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

Предполагая, что аппаратные и программные буферы целевого устройства достаточно велики (1000 байт), насколько маленьким должно быть сообщение, чтобы я был уверен, что оно всегда будет получаться целым на уровне приложения целевого устройства?

Другими словами, должен ли я включать размер сообщения в протокол приложения или он бесполезен, так как сообщение маленькое?

Answer 1

Вы пытаетесь настроить размер пакета TCP/IP в соответствии с так называемым MTU (максимальная единица передачи). Вы можете сделать это. Или вы можете проигнорировать это, и, поскольку вы используете TCP/IP, просто отправьте пакет: он пройдет через сеть, разрубится на части и позже автоматически склеится, а затем пакет будет доставлен.

Если ваше сообщение довольно маленькое и меньше "минимального размера дейтаграммы", тогда эта цитата вас порадует:

MTU не следует путать с минимальным размером дейтаграммы, который должны быть готовы принять все хосты, который имеет значение 576 байтов для IPv4 [2] и 1280 байтов для IPv6

Таким образом, если ваше сообщение меньше 556 байт (576 байт - 20 байт заголовка ipv4), оно должно прийти в виде одного пакета.

Но даже с фрагментацией: получатель получает полный пакет, только если все (возможные) фрагменты прибыли. Что делает бессмысленным "заботиться" о размере сообщения во избежание фрагментации.

Помимо размера передачи может быть хорошей идеей включить размер сообщения в сообщение (возможно, вы захотите перенести сообщение также на разные носители за один день)

Answer 2

Как указано в ответе Акиры, минимальный размер сообщения, которое хост должен принимать для IPv4, составляет 576 байт, поэтому пакеты размером 255 байт не должны быть фрагментированы.

Однако большинство хостов сегодня реализуют алгоритм Nagle, который ждет 200 мс, прежде чем отправлять пакеты, чтобы попытаться сгруппировать сообщения. Это означает, что если вы отправляете сообщения в режиме быстрой посылки, они могут быть сгруппированы, а затем фрагментированы. TCP предназначен не для дейтаграмм, а для потоков. Ящики в сети могут также делать некоторые странные вещи (вы никогда не знаете).

Я предлагаю вам включить размер сообщения в протокол вашего приложения. Это гарантирует, что у вас не возникнет проблем с фрагментацией сообщений TCP так, как вы этого не ожидали, и, как указано в ответе Акиры, позволит вам в один прекрасный день передавать данные через другой носитель.