Ethernet (и в этом отношении IP) был спроектирован так, чтобы иметь фиксированную верхнюю длину по размерам пакетов, чтобы никто не мог слишком долго захватывать общую среду при передаче какого-либо длинного сообщения произвольной длины.
Стандартные кадры Ethernet могут иметь до 1500 байт полезной нагрузки.
Стандартные дейтаграммы IP могут быть длиной до 64 КБ. (Но поскольку в Интернете очень много Ethernet-подобных сетевых соединений, большую часть времени IP-дейтаграммы в любом случае остаются в пределах 1500 байт Ethernet, поскольку фрагментация и повторная сборка больших IP-дейтаграмм менее эффективна, чем просто хранение дейтаграмм в данных. MTU канального уровня.)
Если ваше приложение обрабатывает сообщения большего размера, вы должны самостоятельно выполнить фрагментацию / повторную сборку / проверку сообщений на своем собственном уровне. Вот как это было разработано и как все с этим справляются, и вы будете плыть вверх по течению, пытаясь взломать ваше оборудование, чтобы разрешить сообщения объемом 1 МБ. Вместо этого вы просто должны понимать, что то, что вы хотите, - это не то, что предоставляют вам эти нижние уровни, но они предоставляют вам строительные блоки, необходимые для построения вашего собственного решения на вашем уровне. Сетевые протоколы и технологии специально разрабатываются по уровням, причем самые нижние уровни обеспечивают минимальный уровень, необходимый для этого уровня, так что верхние уровни не обременены нижними уровнями, выполняющими намного больше, чем нужно верхним уровням. На это есть оригинальный документ Солтцера, Рида и Кларка под названием «Сквозные аргументы в проектировании системы». Любой, кто входит в сеть с таким уровнем детализации, должен прочитать его.
Я уверен, что существует множество библиотек создания сообщений, чтобы упростить передачу сообщений произвольной длины через TCP или UDP, где библиотека создания сообщений заботится о фрагментации, повторной сборке и проверке ваших сообщений.
