При использовании TCP лучше отправлять 1 большой кусок или много маленьких?

Клиент и сервер будут разбивать ваши данные по своему усмотрению, поэтому вы можете отправить столько, сколько захотите, одним фрагментом. Посмотрите статью фон Велча в Руководстве пользователя по TCP Windows.

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

Алгоритм Нэгла, который обычно включен по умолчанию для сокетов TCP, скорее всего, объединит эти четыре 256 байт записываются в один и тот же пакет. Так что на самом деле не имеет значения, отправляете ли вы его как одну запись или несколько, в любом случае он должен оказаться в одном пакете. Отправка его как одного фрагмента имеет больше смысла, если у вас есть большой кусок для начала.

С уровня TCP, да, ваш большой буфер будет разделен, когда он слишком велик, и он будет объединен, когда он станет слишком маленьким.

На уровне приложения не позволяйте своему приложению иметь дело с неограниченными размерами буфера. На каком-то уровне их нужно разделить.

Если вы отправляете файл через сокет и, возможно, обрабатываете некоторые данные этого файла, например, сжимаете его. Затем вам нужно разделить это на части. В противном случае вы будете использовать слишком много ОЗУ, когда в конечном итоге столкнетесь с большим файлом, и ваша программа будет вне ОЗУ.

ОЗУ - не единственная проблема. Если ваш буфер становится слишком большим, вы можете потратить слишком много времени на чтение данных или их обработку, и вы не будете использовать сокет, который сидит там в ожидании данных. По этой причине лучше иметь параметр для размера буфера, чтобы вы могли определить значение, которое не было ни слишком маленьким, ни слишком большим.

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

Если вы вычисляете данные между этими записями, может быть лучше передать их в потоковом режиме по мере их доступности. Кроме того, запись их всех сразу может привести к переполнению буфера (хотя это, вероятно, редко, но случается), а это означает, что вашему приложению необходимо приостановить и повторить попытку записи (не все из них, только с того момента, когда вы попали в переполнение). .)

Обычно я бы не стал изо всех сил разбивать записи, особенно не такие маленькие, как 256-байтовые куски. (Поскольку после накладных расходов TCP / IP в пакет Ethernet может поместиться примерно 1500 байтов, я бы использовал куски, по крайней мере, такого размера.)

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

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