Преимущества наличия поддоменов css, js и media - PullRequest
3 голосов
/ 16 июля 2011

В чем преимущества разделения папок css, js и media в поддоменах, таких как

css.domain-name.com
js.domain-name.com
media.domain-name.com

Я знаю, что масштабируемость начинается со статических / мультимедийных файлов, но имеет ли преимущество их обслуживание с субдомена?

Если да, то в какой степени я должен это делать? Например, если мне разрешено загружать фотографии, я должен поместить свою папку «загрузки» в субдомен media?

Спасибо

Ответы [ 3 ]

3 голосов
/ 16 июля 2011

Я бы отделил загрузки от статических файлов, используемых в общем макете (например, логотипы, значки и т. Д.), Поэтому намного проще очистить существующие файлы, чтобы загрузить новый дизайн, не заботясь о том, чтобы загрузки не былиудалены / перезаписаны.

Что касается доменных имен, я бы не разбивал файлы таким образом.Один поддомен для статических файлов, один для загрузки - отлично.Но я бы не стал добавлять его для сценариев или таблиц стилей.

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

Учитывая ваш пример, я бы использовал следующие субдомены:

www.domain-name.com (basic web presence)
static.domain-name.com or media.domain-name.com (serving support files like js, css, images, etc. - stuff that doesn't change and can be cached for a long time)
uploads.domani-name.com (serving uploaded files)

Не переусердствуйте, поскольку таким образом вы не получаете никакой дополнительной производительности (если вы не используете разные серверы и не ожидаете большой нагрузки).На самом деле загрузка страницы может быть медленнее (из-за дополнительных поисков DNS), и вы можете столкнуться с ограничениями безопасности, например, в отношении достоверности / доступности файлов cookie или междоменных сценариев.

1 голос
/ 16 июля 2011

Есть в основном две причины для этого

  1. Масштабирование - статический контент и динамический контент имеют другие параметры масштабирования. Чем больше вы можете отличаться между веб-серверами, обслуживающими динамическое и статическое содержимое. Исходя из этого, вы можете масштабировать по-разному в зависимости от требований ваших сайтов. Например, если вы разместите фото-сайт, у вас будет в 10 раз больше статических серверов, чем у динамических сайтов. Статические серверы обычно намного легче, чем полнофункциональные серверы приложений.
  2. Cookies - Cookies всегда отправляются на домен, которому они назначены. Таким образом, куки будут отправлены, например, на www.xyz.com а не sub.xyz.com

Вероятно, нет смысла вдаваться в подробности, чем в static [1-n] .xyz.com. Но это действительно зависит от того, что вы хотите сделать.

К вам «загрузить» папку вопрос. Предпочтительно, чтобы изображения, загруженные в ваш основной домен, обслуживались статическим сервером (обслуживающим содержимое на вашем поддомене).

0 голосов
/ 16 июля 2011

Для JS это кажется плохой идеей. Существуют ограничения безопасности в отношении того, что вы можете делать с помощью JS при работе с другим доменом, что может иметь место в данном случае.

Для медиа-файлов и загрузок, в основном для хранения больших двоичных объектов, история немного другая. Для сайтов с большим трафиком может потребоваться разделить это, чтобы создать хорошую структуру распределения нагрузки и избежать ненужной нагрузки на серверы веб-приложений (субдомен media может указывать на разные серверы, тем самым уменьшая нагрузку на серверах приложений, позволяя создавать массовую балансировку нагрузки только для обслуживания двоичных данных).

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...