Зачем перемещать файлы 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" в специальном домене Тернера подсказывает нам важность этой концепции здесь).
Но обратите внимание, что с этими примерами у каждого сайта есть собственный специально зарегистрированный домен для этой цели, а не домен сети доставки контента или другого поставщика инфраструктуры. Фактически, если вы пытаетесь загрузить домашнюю страницу с большинства этих доменов сценариев, они обычно перенаправляются обратно в основной домен компании. И если вы обращаетесь к 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 ответов
Ваш последующий вопрос по сути: если предположить, что популярный веб-сайт использует 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 и их коллеги по связям Javascript sysadmin / CDN могут иметь свое собственное доменное имя / DNS, через которое они проталкивают эти изменения, за которые они несут ответственность / автономны.
Затем, если на ДВУ начинает происходить какая-либо блокировка файлов cookie или сценариев, они просто переходят с одного бессмысленного ДВУ на kyxmlek.com или любой другой. Им не нужно беспокоиться о том, чтобы случайно сделать что-то злое, что имеет побочные эффекты противодействия на всех сайтах.
Ограничить трафик cookie?
После того, как файл cookie установлен в определенном домене, каждый запрос к этому домену будет отправлять файл cookie на сервер. Каждый запрос!
Это может сложить быстро.
Множество причин:
CDN - другое имя DNS облегчает перенос статических ресурсов в сеть распространения контента
Параллелизм - изображения, таблицы стилей и статический javascript используют два других соединения, которые не будут блокировать другие запросы, такие как обратные вызовы ajax или динамические изображения.
Трафик cookie - точно правильный - особенно на сайтах, которые имеют привычку хранить гораздо больше, чем простой идентификатор сессии в cookie
Формирование нагрузки - даже без CDN все еще есть веские причины размещать статические ресурсы на меньшем количестве веб-серверов, оптимизированных для чрезвычайно быстрого реагирования на огромное количество запросов URL-адресов файлов, тогда как остальная часть сайта размещается на большем количестве отвечающих серверов на более ресурсоемкие динамические запросы
обновление - две причины, по которым вы не используете имя dns CDN. Имя DNS-клиента действует как ключ к правильному "кусту" активов, которые кэширует CDN. Кроме того, поскольку ваш CDN является обычной услугой, вы можете сменить провайдера, изменив запись DNS, чтобы избежать любых изменений страниц, перенастройки или повторного размещения на вашем сайте.
Я думаю, что есть кое-что в теории 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 в строке состояния, и вы получите список доменов с вариантами для временного или постоянного белого списка, включая "все на этой странице".
Я внедрил это решение два-три года назад у предыдущего работодателя, когда веб-сайт начал перегружаться из-за устаревшей реализации веб-сервера. Переместив CSS и изображения макетов на сервер Apache, мы снизили нагрузку на главный сервер и увеличили конечную скорость.
Однако у меня всегда было впечатление, что доступ к функциям Javascript возможен только из того же домена, что и сама страница. Новые сайты, похоже, не имеют такого ограничения: как вы упоминаете, многие из них имеют файлы Javascript в отдельных поддоменах или даже в полностью отключенных доменах.
Кто-нибудь может дать мне указание на то, почему это теперь возможно, когда это не было пару лет назад?
Если бы я был известной мультибрендовой компанией, я думаю, что такой подход был бы целесообразен, потому что вы хотите сделать код 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
- Тайм Уорнер
Если вы размещаете код в домене, который НЕ является торговой маркой, вы сохраняете большую гибкость, и вам не нужно реорганизовывать все точки входа, контроль доступа и ссылки на код при переименовании веб-сайтов.
Будет ли это из-за блокировки спамом и фильтрами контента? Если они используют странные домены, тогда сложнее разобраться, и / или вы в конечном итоге заблокируете то, что хотите.
Не знаю, просто мысль.
Я работал с компанией, которая делает это. Они находятся в центре обработки данных с довольно хорошим пирингом, поэтому рассуждения CDN для них не так уж велики (возможно, это поможет, но по этой причине они этого не делают). Их причина в том, что они запускают несколько веб-серверов параллельно, которые совместно обрабатывают их динамические страницы (скрипты PHP), и они обслуживают изображения и некоторый javascript вне отдельного домена, на котором они используют быстрый и легкий веб-сервер, такой как lighttpd или thttpd, для обслуживания изображения и статический JavaScript.
PHP требует PHP. Статического Javascript и изображений нет. Многое может быть удалено из полнофункционального веб-сервера, когда все, что вам нужно сделать, это абсолютный минимум.
Конечно, они могли бы использовать прокси-сервер, который перенаправляет запросы в конкретный подкаталог на другой сервер, но проще обрабатывать весь статический контент на другом сервере.
Я думаю, что вы ответили на свой вопрос.
Я считаю, что ваша проблема связана с безопасностью, а не ПОЧЕМУ.
Возможно, нужен новый тег META, который бы описывал действительные CDN для рассматриваемой страницы, тогда все, что нам нужно, это надстройка браузера, чтобы читать их и вести себя соответственно.
Это не просто javascript, который вы можете перемещать в разные домены, но как можно больше ресурсов приведет к повышению производительности.
Большинство браузеров имеют ограничение на количество одновременных подключений к одному домену (я думаю, что это около 4), поэтому, когда у вас много изображений, js, css и т. Д., При загрузке каждого файла часто возникает задержка.
Вы можете использовать что-то вроде YSlow и FireBug для просмотра, когда каждый файл загружается с сервера.
Располагая ресурсами в отдельных доменах, вы уменьшаете нагрузку на основной и можете иметь больше одновременных соединений и загружать больше файлов в любой момент времени.
Недавно мы запустили веб-сайт по продаже недвижимости, на котором много изображений (домов, да:P), который использует этот принцип для изображений, так что намного быстрее вывести список данных.
Мы также использовали это на многих других сайтах с большим объемом активов.