Я не могу найти ссылку на числа, которые можно использовать для этого, но в прошлом я читал из надежного источника, что кто-то (я думаю, Google или FB) провел много исследований по вопросам эффективности, связанных с параллелизмом запросов. когда они строили свои CDN и обнаружили, что 2-3 одновременных передачи были оптимальными, принимая во внимание потерю пакетов, издержки транспортного уровня и другие подобные факторы. Это относится к одному клиенту, взаимодействующему с одним сервером, и небольшой, но заметный выигрыш в эффективности можно найти, распределяя контент с нескольких серверов - еще одно преимущество использования распределенной CDN.
Снизу вверх - HTTP при работе по TCP неизбежно включает в себя множество обходных путей на низком уровне, поскольку каждый TCP PSH должен быть подтвержден перед отправкой следующего. Учитывая, что значение MTU Ethernet составляет 1500 (часто 1492 на практике, учитывая обилие DSL и других подключений на базе ATM), нет смысла устанавливать максимальный размер полезной нагрузки TCP, так как это фактически снизит эффективность. Поскольку многие (если не все) ресурсы, используемые веб-страницей, имеют размер более ~ 1,4 КБ, они неизбежно будут «разделены» (фрагментированы) на транспортном уровне, а глупые настройки размера полезной нагрузки TCP приведут к фрагментации в сети. слой также. Каждый из этих транспортных фрагментов, как уже упоминалось, должен быть подтвержден получателем до отправки следующего, что должно привести как минимум к нескольким обратным путям.
На прикладном уровне сам HTTP также поддерживает «чанкинг», что немного отличается от игры в мяч с проблемой фрагментации транспортного уровня. Chunked Transfer Encoding разработан с учетом концепции постоянства, а также предлагает преимущества использования памяти как для сервера, так и для клиента. Хотя ответ увеличится на немного , маловероятно, что это приведет к значительно большему количеству циклов (если правильно реализовано), а любые дополнительные циклы - просто пары TCP PSH / ACK, а не совершенно новый HTTP запрос. Идея кодирования передачи по частям состоит в том, чтобы разделить тело на куски внутри одного потока, а не разбивать на куски, которые будут обмениваться на несколько потоков. Разумеется, формулировка вашего вопроса предполагает, что все HTTP-сообщения передаются порциями, и это просто не тот случай. Если ваш сервер настроен разумно, то будет динамически сжат только динамический контент и контент, который динамически сжат, и даже тогда не все будет. Большинство HTTP-серверов будут прилагать все усилия, чтобы вписать ответ в как можно меньшее количество TCP-пакетов.
Что касается максимального рекомендуемого размера, я не могу дать авторитетный ответ, но я выскажу вам свое мнение по этому вопросу. Учитывая уже бесконечные вариации, которые могут происходить в пределах параметров, указанных выше, наиболее эффективный способ сделать это сильно зависит от того, что именно вы обслуживаете и как вы его обслуживаете.
Если вы обслуживаете кучу статического контента, возможно, чем больше будет передача, тем лучше в целом, с оговоркой: скажем, мы обслуживаем веб-страницу с большим количеством динамического контента на стороне клиента (например, с помощью JS)мы хотим, чтобы страница загружалась как можно быстрее.Но все, что нам нужно отправить вначале, - это контент, необходимый для отображения начального состояния дисплея - основной HTML, очевидно, является первой вещью, которую нам нужно отправить, но в значительной степени это так.Далее нам понадобится таблица стилей, которая дает странице ее начальный макет, и любые необходимые изображения - так что все выглядит так, как будто оно загружено.Далее нам нужен Javascript, который присоединяет весь базовый клиентский код к странице - скорее всего, это может быть довольно мало.Только после того, как все это будет загружено, нам нужно получить больший объем ресурсов, поэтому вместо того, чтобы помещать все ссылки на это в заголовок HTML, где вы практически не контролируете порядок загрузки ресурсов (примечание: загружено не выполнено ), загрузите их динамически из вашего основного файла Javascript.Это позволяет вам создать страницу, которая выглядит как , как если бы она загружалась как можно быстрее, но фактически загружает менее часто используемые ресурсы или ресурсы, которые необходимы только после нескольких действий пользователя позже.
Если вы обслуживаете все динамически - проходя все через PHP / Perl / ASP / Insert Server Side Language здесь - тогда вам также необходимо учитывать время выполнения на стороне сервера, но применяется тот же принцип.Создайте разметку / styles / scripts / images / все, что требуется для того, чтобы страница выглядела так, как если бы она загружалась максимально быстро, а все, что требуется для создания, может быть загружено через JS позже..
Читая об этом, я не уверен, насколько это будет полезно для вас или даже ответит на ваш вопрос, но, надеюсь, это принесет интересное (?) Чтение.