Зачем переносить ваши файлы Javascript в другой основной домен, которым вы также владеете?

Question

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

Это не просто распараллеливание

Теперь существует хорошо известный метод распространения компонентов вашей страницы по нескольким доменам для распараллеливания загрузки. Yahoo рекомендует это как и многие другие.Например, www.example.com это место, где размещается ваш HTML-код, затем вы размещаете изображения на images.example.com и javascripts на scripts.example.com.Это связано с тем фактом, что большинство браузеров ограничивают количество одновременных подключений к серверу, чтобы быть хорошими пользователями сети.

Вышесказанное является нет то, о чем я говорю.

Это не просто перенаправление в сеть доставки контента (или, может быть, так и есть - см. нижнюю часть вопроса)

То, о чем я говорю, - это размещение Javascripts конкретно в совершенно другом домене.Позвольте мне быть конкретным.Только за последний год или около того я заметил, что:

youtube.com переместил свои файлы .JS в ytimg.com

cnn.com переместил свои файлы .JS в cdn.turner.com

weather.com переместил свои файлы .JS в j.imwx.com

Теперь я знаю о таких сетях доставки контента, как Акамай которые специализируются на аутсорсинге этого для крупных веб-сайтов.(Название "cdn" в специальном домене Тернера указывает нам на важность этой концепции здесь).

Но обратите внимание на эти примеры, что у каждого сайта есть свой собственный домен, специально зарегистрированный для этой цели, и это не домен сети доставки контента или другого поставщика инфраструктуры.Фактически, если вы пытаетесь загрузить домашнюю страницу с большинства из этих скриптовых доменов, они обычно перенаправляются обратно на основной домен компании.И если вы выполните обратный поиск по соответствующим IP-адресам, они иногда иногда они указывают на серверы CDN-компании, иногда нет.

Почему меня это волнует?

Ранее я работал в двух разных охранных компаниях, и у меня возникла паранойя из-за вредоносных Javascripts.

В результате я придерживаюсь практики внесения в белый список сайтов, на которых я разрешаю запускать Javascript (и другой активный контент, такой как Java).В результате, чтобы сделать сайт похожим cnn.com работайте правильно, я должен вручную поставить cnn.com в список.Это заноза в заднице, но я предпочитаю это альтернативе.

Когда люди использовали такие вещи, как scripts.cnn.com для распараллеливания это прекрасно работало с соответствующим подстановочным знаком.И когда люди использовали поддомены из доменов компании CDN, я мог просто разрешить основной домен компании CDN также с подстановочным знаком впереди и убить многих зайцев одним выстрелом (например, *.edgesuite.net и *.akamai.com).

Теперь я обнаружил, что (по состоянию на 2008 год) этого недостаточно.Теперь мне нужно покопаться в исходном коде страницы, которую я хочу внести в белый список, и выяснить, какой "секретный" домен (или домены) этот сайт использует для хранения своих Javascripts.В некоторых случаях я обнаружил, что мне приходится разрешать работу сайта трем разным доменам.

Почему все эти крупные сайты начали это делать?

Редактировать:ОК как отметил "onebyone", похоже, это действительно связано с доставкой контента CDN.Поэтому позвольте мне немного видоизменить вопрос, основываясь на его исследованиях...

Почему это weather.com используя j.imwx.com вместо того, чтобы twc.vo.llnwd.net?

Почему это youtube.com используя s.ytimg.com вместо того, чтобы static.cache.l.google.com?

За этим должно стоять какое-то обоснование.

Answer 1

Ваш последующий вопрос, по сути, таков:Предполагая, популярный сайт является используете CDN, то почему бы им использовать свои собственные дву, как imwx.com вместо субдомена (static.weather.com), или серверов домена?

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

Итак, зачем использовать бессмысленные доменные имена?Ну, важная особенность вспомогательных файлов, таких как .js и .css, заключается в том, что вы хотите, чтобы они кэшировались прокси-серверами и браузерами пользователей как можно чаще.Если пользователь нажимает gmail.com и весь файл .js загружается из кэша его браузера, сайт кажется ему намного более быстрым, а также это экономит пропускную способность на стороне сервера (выигрывают все).Проблема в том, что как только вы отправляете HTTP-заголовки для действительно агрессивного кэширования (т.е.кэшируйте меня на неделю, или год, или навсегда), эти файлы больше никогда не будут надежно загружены с сервера, и вы не сможете вносить в них изменения / исправления, потому что что-то сломается в браузерах людей.

Итак, что должны сделать компании, так это инсценировать эти изменения и фактически изменить URL-адреса всех этих файлов, чтобы заставить браузеры пользователей перезагружать их.Циклический переход по доменам типа "a.imwx.com", "b.imwx.com" и т.д.вот как это делается.

Используя бессмысленное доменное имя, разработчики Javascript и их коллеги по связям с системными администраторами Javascript / CDN могут иметь свое собственное доменное имя / DNS, с помощью которого они продвигают эти изменения, за которые они подотчетны / автономны.

Затем, если в TLD начинает происходить какая-либо блокировка файлов cookie или скриптов, они просто меняются с одного бессмысленного TLD на kyxmlek.com или что-то еще.Им не нужно беспокоиться о том, что они случайно совершат что-то злое, что приведет к побочным эффектам противодействия для всех *.google.com .

Answer 2

Ограничить трафик файлов cookie?

После установки файла cookie в определенном домене при каждом запросе к этому домену файл cookie будет отправляться обратно на сервер.Каждая просьба!

Это может быстро сложиться.

Answer 3

Причин много:

CDN - другое DNS-имя упрощает передачу статических ресурсов в сеть распространения контента.

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

Трафик файлов cookie - абсолютно корректен, особенно для сайтов, которые имеют привычку хранить в файлах cookie гораздо больше, чем простой идентификатор сеанса

Формирование нагрузки - даже без CDN все еще есть веские причины размещать статические ресурсы на меньшем количестве веб-серверов, оптимизированных для чрезвычайно быстрого реагирования на огромное количество запросов URL-адресов файлов, в то время как остальная часть сайта размещается на большем количестве серверов, отвечающих на динамические запросы с большей нагрузкой на процессор

---

обновление - две причины, по которым вы не используете DNS-имя CDN.DNS-имя клиента действует как ключ к соответствующему "улью" активов, которые кэширует CDN.Кроме того, поскольку ваш CDN является обычным сервисом, вы можете сменить поставщика, изменив запись dns, чтобы избежать каких-либо изменений страницы, перенастройки или перераспределения на вашем сайте.

Answer 4

Я думаю, что в теории CDN что-то есть:

Например:

$ host j.imwx.com
j.imwx.com              CNAME   twc.vo.llnwd.net
twc.vo.llnwd.net        A       87.248.211.218
twc.vo.llnwd.net        A       87.248.211.219
$ whois llnwd.net
<snip ...>
Registrant:
  Limelight Networks Inc.
  2220 W. 14th Street
  Tempe, Arizona 85281-6945
  United States

Центр внимания - это CDN.

Тем временем:

$ host s.ytimg.com
s.ytimg.com             CNAME   static.cache.l.google.com
static.cache.l.google.com       A       74.125.100.97

Я предполагаю, что это CDN для статического контента, запускаемого внутри Google.

$ host cdn.turner.com
cdn.turner.com A record currently not present

Ну что ж, я не могу победить их всех.

Кстати, если вы используете Firefox с надстройкой NoScript, то это автоматизирует процесс поиска по исходному коду и графический интерфейс для внесения в белый список.По сути, нажмите на значок NoScript в строке состояния, и вам будет предоставлен список доменов с возможностью временного или постоянного внесения в белый список, включая "все на этой странице".

Answer 5

Я внедрил это решение около двух-трех лет назад у предыдущего работодателя, когда веб-сайт начал перегружаться из-за устаревшей реализации веб-сервера.Переместив CSS и изображения макета на сервер Apache, мы уменьшили нагрузку на основной сервер и бесконечно увеличили скорость.

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

Кто-нибудь может подсказать мне, почему это возможно сейчас, когда этого не было пару лет назад?

Answer 6

Вы можете перенести в разные домены не только javascript, но и как можно больше ресурсов, что приведет к повышению производительности.

Большинство браузеров имеют ограничение на количество одновременных подключений, которые вы можете установить к одному домену (я думаю, что это около 4), Поэтому, когда у вас много изображений, js, css и т.д., Загрузка каждого файла часто задерживается.

Вы можете использовать что-то вроде YSlow и FireBug для просмотра того, когда каждый файл загружается с сервера.

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

Недавно мы запустили веб-сайт realestate, на котором есть много изображений (домов, да : P), который использует этот принцип для изображений, поэтому намного быстрее составлять список данных.

Мы также использовали это на многих других веб-сайтах с большим объемом ресурсов.

Answer 7

Я думаю, вы сами ответили на свой вопрос.

Я полагаю, что ваша проблема связана с безопасностью, а не с ПРИЧИНОЙ.

Возможно, нужен новый МЕТА-тег, который описывал бы действительные CDN для рассматриваемой страницы, тогда все, что нам нужно, это надстройка для браузера, чтобы читать их и вести себя соответствующим образом.

Answer 8

Может быть, это из-за блокировки спамом и контент-фильтрами?Если они используют странные домены, то это сложнее понять, и / или вы в конечном итоге заблокируете то, что хотите.

Не знаю, просто мысль.

Answer 9

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

В текущей бизнес-модели Интернета домены - это бренды, а не сетевые названия.Если вас покупают или выделяют бренды, вы в конечном итоге часто меняете домен.Это проблема даже для самых известных сайтов.

Все еще есть ссылки, указывающие на полезные документы в * .netscape.com и * .mcom.com, которых давно нет.

Википедия для Netscape ( Сетевой ландшафт ) говорит:

"12 октября 2004 года популярный веб-сайт разработчика Netscape DevEdge был закрыт компанией AOL.DevEdge был важным ресурсом по технологиям, связанным с Интернетом, поддерживая полную документацию по браузеру Netscape, документацию по связанным технологиям, таким как HTML и JavaScript, а также популярные статьи, написанные лидерами отрасли и технологическими лидерами, такими как Дэнни Гудман.Некоторый контент из DevEdge был переиздан на веб-сайте Mozilla ".

Таким образом, это произойдет менее чем за 10-летний период:

• Корпорация Mosaic Communications Corporation
• Коммуникационная корпорация Netscape
• AOL
• AOL Тайм Уорнер
• Тайм Уорнер

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

Answer 10

Я работал с компанией, которая занимается этим.Они находятся в центре обработки данных с довольно хорошим пирингом, поэтому аргументация CDN для них не такая уж большая (возможно, это помогло бы, но они не делают этого по этой причине).Их причина в том, что они запускают несколько веб-серверов параллельно, которые коллективно обрабатывают их динамические страницы (PHP-скрипты), и они обслуживают изображения и некоторый javascript из отдельного домена, на котором они используют быстрый, легкий веб-сервер, такой как lighttpd или thttpd, для обслуживания изображений и статического javascript.

PHP требует использования PHP.Статический Javascript и изображения этого не делают.Многое можно извлечь из полнофункционального веб-сервера, когда все, что вам нужно сделать, - это абсолютный минимум.

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