Подтвердить что ты не робот

Зачем перемещать файлы 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?

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

4b9b3361

ОТВЕТЫ

Ответ 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 и изображения нет. Абсолютный минимум может быть удален из полнофункционального веб-сервера, если вам нужно всего лишь сделать это.

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