Плюсы и минусы отдельного сервера изображений (например, images.mydomain.com)?

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

Есть ли у кого-нибудь опыт работы с этим подходом?

Меня интересуют какие-либо «подводные камни» — например, проблемы с XSS и/или проблемы с браузером, доставляющим контент из альтернативного поддомена?


web-deployment subdomain
person qxotk    schedule 26.05.2009    source источник

Ответы (5)


arrow_upward
21
arrow_downward

Плюсы:

Многие браузеры выделяют только два сокета для загрузки ресурсов с одного хоста. Таким образом, если index.html загружен с www.domain.com и ссылается на 6 файлов изображений, 3 файла javascript и 3 файла CSS (все на www.domain.com), браузер загрузит их по 2 за раз, с другая блокировка, пока сокет не освободится.

Если вы вытащите 6 файлов изображений на отдельный хост, скажем, images.domain.com, вы получите два дополнительных сокета, предназначенных для загрузки ваших изображений. Это распараллеливает процесс загрузки ресурсов, поэтому теоретически ваша страница может отображаться в два раза быстрее.

Против:

Если вы используете SSL, вам потребуется либо получить дополнительный SSL-сертификат для одного хоста для images.domain.com, либо подстановочный SSL-сертификат для *.domain.com (соответствует любому поддомену). Если этого не сделать, в браузере появится предупреждение о том, что страница содержит как безопасный, так и небезопасный контент.

person Chris Sears    schedule 26.05.2009
comment
Если вы действительно заботитесь о производительности и загружаете большие ресурсы, вы можете поместить их в домен с * в DNS, а затем рандомизировать субдомен в вызове ресурса, например http(s)://‹randomstring›. imagesomain.com/image.gif и т. д. Это может дать вам столько сокетов, сколько есть ресурсов, и немного ускорить вашу загрузку. - person Eli; 27.05.2009
comment
На самом деле вы не хотите заходить слишком далеко, иначе вы можете увидеть чистую потерю производительности. Я бы не стал использовать более 4 хостов статических ресурсов (например, images1.domain.com, images2.domain.com, images3.domain.com, images4.domain.com) для большинства сайтов. Основные проблемы будут снижать производительность по мере увеличения количества хостов ресурсов, кэширующих и поддерживающих HTTP-активность. Один и тот же файл, загруженный с одного хоста актива, не будет считаться кэшированным на другом хосте актива. А проверки активности HTTP позволяют повторно использовать одно и то же соединение TCP для нескольких запросов. От 1 до 4 хостов дает вам хороший баланс. - person Chris Sears; 27.05.2009
comment
В январе SSL-сертификаты, выпущенные Let's Encrypt, должны одновременно поддерживать субдомены в дополнение к вершине. А современные браузеры теперь радостно разрываются от десятков параллельных загрузок ресурсов, а не по две за раз. - person Josh Habdas; 10.09.2017

arrow_upward
8
arrow_downward

Вы также, с другим доменом, не будете отправлять данные cookie с каждым запросом. Это может повысить производительность.

person alex    schedule 27.05.2009

arrow_upward
5
arrow_downward

Еще одна вещь, о которой еще не упоминалось, это то, что вы можете использовать разные веб-серверы для обслуживания разных видов контента. Например, ваш статический контент может обслуживаться через lighttpd или nginx, а динамический контент по-прежнему будет обслуживаться через Apache.

person ceejayoz    schedule 27.05.2009

arrow_upward
3
arrow_downward

Плюсы:

-балансировки нагрузки

- выделение другой функциональности

Минусы:

- больше работы (при создании страницы на основном сайте вам придется поддерживать ресурсы на отдельном сервере)

Такие вещи, как XSS, — это проблема кода, не очищающего ввод (или вывод, если уж на то пошло). Единственная проблема, которая может возникнуть, заключается в том, что у вас есть файлы cookie для поддоменов, которые используются для аутентификации... но это действительно тривиальное решение.

person Patrick Gryciuk    schedule 26.05.2009

arrow_upward
2
arrow_downward

Если вы обслуживаете HTTPS и обслуживаете изображение из домена HTTP, при его использовании вы будете получать всплывающие предупреждения безопасности браузера.

Так что, если вы используете HTTPS, вам нужно будет купить HTTPS для своего графического домена, если вы не хотите чертовски раздражать своих пользователей :)

Есть и другие способы обойти это, но это не входит в рамки этого ответа - это было просто предупреждение!

person joshcomley    schedule 26.05.2009
comment
Если Джеймс говорит то, что я думаю, то есть то, что изображение на самом деле доставляется сценарием, который выводит контент (т.е. тип контента: image/jpeg); затем, пока скрипт находится на защищенном сервере (secure.domain.com/somescript. php?i=4567aldh), это не должно быть проблемой. Опять же, я могу быть тем, кто неправильно понимает настройку.... - person Fran Corpier; 27.05.2009
comment
(упс, забыл экранировать часть https. Он превратился в ссылку. Извините. :/) - person Fran Corpier; 27.05.2009
comment
Есть и другие способы обойти это, имея в виду именно это - скрипт на HTTPS, который извлекает изображения с другого сервера. Так что вы абсолютно правы, это не настоящая проблема! - person joshcomley; 27.05.2009