Почему в сетях CDN используются разные доменные имена, а не субдомены? [закрыто]
Многие онлайн-сервисы конфигурируют CDN (сети доставки контента) для повышения производительности, позволяя предоставлять контент из географически близких мест. Я заметил, что очень часто CDN обслуживается с другого доменного имени, чем фактическая служба.
Например, посещение www.amazon.com будет включать получение контента с media-amazon.com.
www.facebook.com получает контент с fbcdn.com и т. Д.
У меня вопрос, почему эти службы не используют субдомены вместо совершенно разных доменных имен для своих CDN?
Например. почему бы не использовать cdn.facebook.com вместо fbcdn.com? Я редко замечаю, что это делается. Почти всегда это другое доменное имя, часто это базовый домен с добавлением к нему чего-то или аббревиатуры.
Единственное, о чем я могу думать, это то, что наличие другого доменного имени позволяет использовать разных DNS-провайдеров для распределения нагрузки DNS, но это не всегда так.
Есть ли конкретная техническая причина для такой практики? Если так, то, что это?
Уточнение: меня не интересует стоимость регистрации доменного имени. Я предполагаю, что любая компания, широко использующая CDN, может позволить себе несколько дополнительных доменных имен. У меня вопрос, почему использование поддоменов уступает использованию отдельных доменов с технической точки зрения. Тот факт, что эта практика настолько распространена, предполагает, что для этого есть веские причины.
Ответ на это может только быть предположением. Вероятная возможность -
Различные команды/системы сборки, обрабатывающие CDN и приложение (приложения). Путем разделения доменов скорее затем использование субдоменов это упрощает управление и автоматизацию, и делает вещи менее вероятно для повреждения. Стоимость, если доменное имя тривиально на общей картине.
В то время как каждый поставщик отличается и может иметь различные причины совершения того же выбора, одна общая причина, это сделано, из-за Cookie .
, Если Ваш веб-сайт использует cookie и Ваши cookie, возможно, должен использоваться для нескольких субдоменов, то Вы закончите тем, что отправили cookie наряду с каждым запросом CDN. Это вызывает две проблемы:
- , Если у Вас есть много cookie и/или очень больших cookie, Вы будете значительно увеличивать каждый запрос к CDN, израсходовав ценную пропускную способность ни по какой причине (так как CDN служит тому же содержанию всем). В масштабе Google, Facebook, Amazon, и т.д., каждого байта в количествах запроса, так как миллионы (или даже миллиарды) запросов складывают быстро.
- , Если Ваши cookie содержат пользовательские данные, Вы не можете хотеть, чтобы CDN смог видеть те данные. Это особенно верно, если Ваш CDN на самом деле полностью или частично размещается сторонними поставщиками услуг. Отправка cookie к CDN устраняет один возможный путь нападения на данные Ваших пользователей.
Другая общая причина пользовательский контент . Хорошими примерами этого являются вложения Gmail и код, размещенный в репозиториях GitHub. Если пользовательский контент размещается на субдомене, он смог оставаться информация пользователя от Cookie, LocalStorage, и т.д. и отправлять его третьему лицу. Хостинг на другом домене смягчает ту форму нападения.