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

Я заметил, что только за последний год или около того многие крупные веб-сайты внесли такие же изменения в способ структурирования своих страниц. Каждый из них перемещал свои файлы 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

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

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

Почему меня это беспокоит?

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

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

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

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

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

ИЗМЕНИТЬ: OK как указано "onebyone" , похоже, это связано с доставкой содержимого CDN. Поэтому позвольте мне немного изменить вопрос, основанный на его исследованиях...

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

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

Для этого нужно рассуждать.

Ответ 1

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

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

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

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

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

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

Ответ 2

Ограничить трафик cookie?

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

Это может складываться быстро.

Ответ 3

Множество причин:

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

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

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

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


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

Ответ 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

Limelight - это 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, тогда он автоматизирует процесс поиска через источник, а GUI-fy - процесс "белого списка". В основном, щелкните значок NoScript в строке состояния, вам будет предоставлен список доменов с параметрами временного или постоянного белого списка, включая "все на этой странице".

Ответ 5

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

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

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

Ответ 6

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

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

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

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

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

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

Ответ 7

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

Я считаю, что ваша проблема связана с безопасностью, а не с ПОЧЕМУ.

Возможно, новый тег META предназначен для описания действительных CDN для рассматриваемой страницы, тогда все, что нам нужно, это надстройка для браузера, чтобы читать их и вести себя соответственно.

Ответ 8

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

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

Ответ 9

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

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

По-прежнему существуют ссылки, указывающие на полезные документы в *.netscape.com и *.mcom.com, которые давно прошли.

Википедия для Netscape говорит:

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

Итак, это было бы менее чем за 10 лет:

  • Мозаичная коммуникационная корпорация
  • Корпорация Netscape Communications
  • AOL
  • AOL Time Warner
  • Время Warner

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

Ответ 10

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

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

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