Назад | Перейти на главную страницу

Почему HTTP-серверы не отправляют обратно ни одного файла, когда это возможно?

Мне интересно, почему HTTP-серверы не упаковывают запрос веб-страницы в один файл, который затем читается браузером?

Насколько мне известно, количество запросов, сделанных для каждой веб-страницы (CSS / JSS / изображения + HTML-вывод), вместе делает загрузку веб-страницы медленнее, а также увеличивает нагрузку на веб-сервер. Есть ли веб-сервер, который упаковывает весь контент (или столько, сколько возможно) и отправляет его клиенту?

Итак, чтобы проиллюстрировать мой вопрос:

Нормальная ситуация widgets.js widgets.css picture1.png picture2.png widgets.html

Ситуация с упаковкой

widgets.pck

Конечно, сначала это вызовет небольшие накладные расходы, но с умным кешированием я бы сказал, что возможны некоторые улучшения?

Если бы все объекты на одной конкретной странице обслуживались одним и тем же сервером, я полагаю, что это было бы возможно. Однако в большинстве случаев (особенно с крупными многомиллионными веб-сайтами) это не так. Множество разных серверов обслуживают разные части каждой страницы, и если вам нужен один «внешний» сервер для сбора всех ресурсов, их упаковки и отправки, производительность будет значительно хуже, чем сейчас, когда все работает, когда браузер отвечает за выборку всех ресурсов страницы.

На самом деле это возможно:

Преимущество наличия отдельных ресурсов заключается в том, что они кэшируются отдельно различными частями веб-приложения цепочки для веб-браузера: - кеширование на уровне файловой системы на веб-сайте - отдельные сайты для статических файлов (изображения, JS и т. Д.) - кеширование и сеть распространения (например, Akamai) - кеширование в веб-браузере.

Поэтому вместо того, чтобы аннулировать кеш для всей страницы из-за того, что вы добавили запятую, браузер перезагрузит только HTML-страницу.

Также не забывайте, что большинство веб-сайтов и браузеров используют HTTP / 1.1 с включенным KeepAlive. Это означает, что объекты с одного и того же веб-сайта будут загружены по одному и тому же TCP-соединению.

Стандартные методы уменьшения количества запросов:

  • размещение всего JS-кода в одном файле (и его минимизация);
  • поместить весь код CSS в один файл (и минимизировать его);
  • объединение всех маленьких многократно используемых изображений в один спрайт;

Однако помещать все это как встроенное в HTML было бы непрактично. JS / CSS / спрайты можно повторно использовать на всем сайте, и они останутся в кеше браузера, когда вы запросите другую страницу.

кстати. Я бы порекомендовал вам книгу на эту тему:

Ответы с веб-серверов не упаковываются в архив, но происходят две вещи.

  1. http keepalives, которые позволяют обслуживать несколько объектов через одно соединение http (KeepAlive в терминах конфигурации Apache). Это работает только с объектами, которые имеют известный размер (поэтому сервер может сообщить клиенту, где находится конец текущего объекта, что исключает динамические объекты).
  2. сжатие ответов (модуль Apache mod_deflate), согласованных между сервером и клиентом

Я думаю, что эти двое вместе делают примерно то же, что вы предлагаете, но все они основаны на переговорах между клиентом и сервером о возможностях и пожеланиях.

Как уже упоминалось, текущий протокол HTTP предоставляет ограниченную поддержку для этого.

Существует схема DATA URI, которая позволяет вам кодировать двоичные объекты, такие как изображения, в base64 и встраивать их, эффективно объединяя HTML и объект в один файл. Это снижает возможность кэширования, но все же может быть целесообразным для небольших объектов за счет уменьшения количества кратковременных соединений и уменьшения передачи несжатых заголовков. Расширение Google mod_pagespeed Apache выполняет этот трюк, среди прочего, автоматически для объектов размером 2 КБ и меньше. Видеть http://code.google.com/intl/nl/speed/page-speed/docs/filter-image-optimize.html

HTTP Pipelining / keepalive полезны, но, как упоминает Коос ван ден Хаут, работают только с объектами с известным размером. Кроме того, конвейерная обработка и сжатие gzip ничего не делают для несжатой передачи заголовков и файлов cookie.

Интересная разработка Google исследовательский проект SPDY, который делает почти то, что вы предлагаете. Среди прочего, он чередует несколько HTTP-запросов по одному TCP-соединению, чередуя ресурсы и присваивая им приоритеты. Он также сжимает весь поток, включая заголовки и файлы cookie. Тесты показали сокращение времени загрузки страницы примерно на 50%, поэтому я определенно буду следить за этим проектом.

Браузер Google Chrome уже использует протокол SPDY при взаимодействии с такими сайтами Google, как Gmail и Search. Вы можете найти внутреннюю диагностику, введя about: net-internals в адресную строку.