Из RF C:
Это позволяет динамически создаваемому контенту быть переданным ...
Другими словами: Transfer-Encoding: chunked необходим, когда длина контента неизвестна .
Длина вашего контента может достигать 10 Тб ... но также может быть маленький как 10 байтов. Это не важно Размеры патчей зависят исключительно от алгоритмов, которые вы используете для генерации их и последующего чтения.
Допустим, вы генерируете поток сообщений различной длины, один символ в секунду. В этом случае вы можете отправить клиенту один байт. Таким образом, клиент сможет использовать данные, как только они поступят. Но если ваш клиент не использует частичные сообщения, вам, вероятно, следует сэкономить пропускную способность и отправить чанк в тот момент, когда вы закончили генерировать следующее сообщение. И опять же, не имеет значения, насколько большое или маленькое сообщение. Это может быть 2 символа или 1000.
Если подумать, есть некоторые варианты использования Transfer-Encoding: chunked с данными известного размера. Но тогда ваш вопрос станет широким, чтобы ответить. Это зависит от кода вашего клиента, кода сервера, состояния сети, свойств данных, желаемого пользовательского опыта и т. Д. c.
. И если по какой-либо причине вы спрашиваете об оптимальном размере с точки зрения сети, то просто отправьте весь файл - это лучшая ставка. И поддержка Content-Range на вашем сервере вместо Transfer-Encoding: chunked.