Сервер изображений для статических изображений и, возможно, других статических файлов (css, js и т. Д.). Они используются только для крупных / популярных веб-сайтов? Во-вторых, действительно ли они полезны только тогда, когда изображения подвергаются какой-либо обработке (например, изменению размера)? Я не официант, так что для меня это незнакомая территория. Я работаю с IIS. Есть ли существенные различия, если это делается на субдомене (images.mywebsite.com) на том же сервере или на другом отдельном компьютере?
Если ваш сайт не очень большой и один сервер может обрабатывать весь ожидаемый вами трафик. Просто добавьте что-то вроде static.yourdomain.com через DNS и свяжите весь свой статический контент, что может дать некоторые преимущества, потому что браузеры будут выполнять только две загрузки на одно DNS-имя одновременно.
Так что имея
может обеспечить 6 одновременных загрузок по HTTP. Это может вызвать дополнительные поиски DNS, но в идеале они будут очень быстрыми.
Эту настройку можно выполнить на одном сервере, просто с разными записями DNS, и когда ваш сайт достаточно большой, чтобы требовать отдельных серверов, вы можете изменить DNS и разместить только связанный контент в каждом поддомене.
Самым большим преимуществом является то, что вы можете взять свой статический контент (который обычно составляет основную часть трафика сайта) и обслуживать его с более быстрых серверов - возможно, thttpd вместо apache, поскольку вам не нужна вся дополнительная мощность apache, или вы можете отразить их на нескольких серверах, чтобы они обслуживались ближе к тому месту, откуда на самом деле находится ваш пользователь.
Обычно это не то, о чем вам нужно беспокоиться, пока ваш сайт не станет достаточно большим.
Использование сервера изображений позволяет обслуживать изображения из более коротких запросов. Все файлы cookie для домена удаляются. Это также упрощает установку политик кеширования. Если статический контент находится на отдельном сервере, вы можете установить для него политику кэширования без кеширования динамического контента.
Также проще защитить статический контент. Сервер может быть ограничен ответом только на запросы GET. Также могут быть добавлены ограничения реферера, хотя их легко обойти.
Анализ журнала также проще, поскольку вам не нужно фильтровать или обрабатывать записи журнала для изображений и другого содержимого, не являющегося страницей.