Зачем перемещать файлы Javascript в другой основной домен, которым вы также владеете? - PullRequest
26 голосов
/ 02 октября 2008

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

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

За этим стоит объяснение.

Ответы [ 10 ]

39 голосов
/ 02 октября 2008

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

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

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

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

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

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

6 голосов
/ 02 октября 2008

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

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

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

4 голосов
/ 02 октября 2008

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

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

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

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

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


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

2 голосов
/ 02 октября 2008

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

1 голос
/ 11 августа 2009

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

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

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

0 голосов
/ 02 октября 2008

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

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

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

0 голосов
/ 02 октября 2008

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

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

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

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

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

Итак, менее чем за 10 лет:

  • Mosaic Communications Corporation
  • Netscape Communications Corporation
  • AOL
  • AOL Time Warner
  • Time Warner

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

0 голосов
/ 02 октября 2008

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

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

0 голосов
/ 02 октября 2008

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

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

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

0 голосов
/ 02 октября 2008

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

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

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

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

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

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

...