Использование подстановочных доменов для обслуживания изображений без блокировки http

Question

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

Одно предостережение: мне нужно обслуживать файлы по протоколу HTTPS.

Есть ли мнения о том, осуществимо ли это:

1. Настройте подстановочный сертификат для *.domain.com.
2. Всякий раз, когда мне нужно изображение, генерирую число на основе хэша mod 5 имени файла и добавляю его к поддомену «img» (например, img1.domain.com, img4.domain.com, img3.domain.com и т. д.); хэш заставит любое имя файла всегда использовать один и тот же поддомен, и, следовательно, браузер должен иметь возможность кэшировать изображения.
3. Настройте динамическую запись виртуального хоста, чтобы указать все поддомены img#. на /var/www/img

Я ищу отзывы об этом плане. Мои опасения:

1. Буду ли я получать предупреждения, если на моей странице есть https:// ссылки на несколько поддоменов?
2. Возможна ли вообще динамическая запись виртуального хоста, о которой я говорю?
3. Учитывая объем обработки, который это потребует, вероятно ли, что это вообще даст какую-либо общую выгоду? Я, вероятно, в среднем использую полдюжины изображений на странице, и только половина из них будет меняться при каждом обновлении страницы.

Заранее спасибо за ваши отзывы.

Answer 1

Ваша схема возможна, если у вас есть wildcard DNS-запись, указывающая на ваш веб-сервер, и он настроен на ответ на всех возможных хостах, и у вас есть wildcard SSL-сертификат. Я вижу несколько проблем, хотя:

1. Размещая каждое изображение на отдельном имени хоста, вы увеличиваете количество DNS-запросов, необходимых для загрузки страницы.
2. Помещая их на разные имена хостов, вы исключаете возможность браузера повторно использовать существующее TCP-соединение для нескольких изображений. Установление TCP-соединений «дорого» и теперь должно быть установлено соединение для КАЖДОГО изображения, а не несколько, которые были бы установлены и повторно использованы, если бы изображения были под одним и тем же именем хоста.

В целом, некоторые полезные практики для сервисных образов включают в себя:

1. Загружайте изображения с другого имени хоста, отличного от основного домена, но ограничивайте их одним или двумя другими именами хостов (по указанным выше причинам).
2. Убедитесь, что на этих именах хостов не используются файлы cookie (это устраняет необходимость отправки браузером файлов cookie вместе с запросом).
3. Убедитесь, что кэширование включено для контента, обслуживаемого на этих именах хостов (хотя это обычно не применимо для SSL).
4. Объединяйте изображения и используйте CSS-спрайты там, где это возможно.
5. Множество других, которые были здоровызадокументировано в другом месте.

Answer 2

1. Нет, если все SSL и сертификат действительны, у вас не возникнет проблем.
2. Да, по крайней мере в Apache это так же просто, как задать одну строкуServerAlias *.domain.com
3. В нынешнем состоянии это не так.

Более подходящее решение:

Используйте легковесный сервер (например, lighttpd с другим доменом без загруженных тяжелых модулей (легковесные процессы) и используйте только один на сервер с соответствующими настройками. Или, что еще лучше, используйте nginx в качестве сервера, поскольку это позволит:

1. Не требуется другой домен/порт/сертификат.
2. nginx обслуживает статический контент и действует как обратный прокси-сервер для «динамических» запросов к вашему исходному, более тяжелому серверу, который работает локально на другом порту/IP-адресе, возможно, другого сервера, по вашему выбору
3. установите соответствующие настройки в nginx (например, keepalive, workers и т. д.)
4. не имеет проблем с обслуживанием HTTPS