Почему перемещают Ваши файлы JavaScript в другой основной домен, которым Вы также владеете?

Question

Почему перемещают Ваши файлы JavaScript в другой основной домен, которым Вы также владеете?

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

Общее правило для размещения typename в основном, когда вы используете параметр шаблона, и хотите получить доступ к вложенному typedef или с использованием псевдонима, например:

template
struct test {
    using type = T; // no typename required
    using underlying_type = typename T::type // typename required
};

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

template
struct test {
    // typename required
    using type = typename std::conditional::type;
    // no typename required
    using integer = std::conditional::type;
};

Общие правила добавления определителя template в основном аналогичны, за исключением они обычно включают шаблонные функции-члены (статические или другие) структуры / класса, которые сами шаблоны, например:

Учитывая эту структуру и функцию:

template
struct test {
    template
    void get() const {
        std::cout << "get\n";
    }
};

template
void func(const test& t) {
    t.get(); // error
}

Попытка доступа t.get() изнутри функции приведет к ошибке:

main.cpp:13:11: error: expected primary-expression before 'int'
     t.get();
           ^
main.cpp:13:11: error: expected ';' before 'int'

Таким образом, в этом контексте вам понадобится ключевое слово template заранее и вызвать его так:

t.template get()

Таким образом, компилятор будет анализировать это правильно, а не t.get < int.

27

whitelist provisioning cdn webserver javascript

задан Community 23 May 2017 в 12:08

10 ответов

Предельный трафик cookie?

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

, Который может сложить быстро.

6

ответ дан TonyOssa 28 November 2019 в 05:03

Много причин:

CDN - различное имя dns облегчает смещать статические активы к сети распределения контента

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

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

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

<час>

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

4

ответ дан loudej 28 November 2019 в 05:03

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

2

ответ дан Steve Jessop 28 November 2019 в 05:03

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

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

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

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

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

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

0

ответ дан Aaron Powell 28 November 2019 в 05:03

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

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

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

0

ответ дан Diodeus - James MacFarlane 28 November 2019 в 05:03

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

Dunno, просто мысль.

0

ответ дан Darryl Hein 28 November 2019 в 05:03

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

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

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

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

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

Так, который был бы, в меньше, чем 10-летний период:

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

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

0

ответ дан benc 28 November 2019 в 05:03

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

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

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

0

ответ дан Matt 28 November 2019 в 05:03

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

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