Как обойти кеш провайдера

Обновлено: 21.11.2024

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

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

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

Есть несколько решений, позволяющих убедиться, что на вашем компьютере установлена последняя версия. Они сильно различаются по эффекту. Поймите различия.

Я. Очистите кеш
Самый радикальный шаг — очистить кеш. Это приведет к удалению всех временных файлов Интернета для всех веб-сайтов из очищаемого кеша.

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

Если вы работаете над проблемой, связанной с адресацией, отличной от BlogSpot (так называемые проблемы с DNS), например, с публикацией в личных доменах, вам также может помочь очистить кэш DNS.

II. Обновить эту веб-страницу
Или вы можете принудительно обновить эту страницу. Нажмите клавишу F5 или, удерживая нажатой клавишу Shift, нажмите кнопку «Обновить» на панели инструментов браузера. При этом будет удалена только эта веб-страница и все связанные с ней файлы, и каждый из них будет перезагружен в кеш.

III. Динамический вызов сервера
Наконец, вы можете временно игнорировать то, что находится в кеше, добавив "?" до конца целевого URL. Вы можете получить доступ к этой веб-странице, например, как (я добавил пробел в середине URL-адреса, чтобы разрешить разрыв строки и избежать другой проблемы с выравниванием поста / боковой панели).

Когда вы добавляете "?" в конец URL-адреса, вы заставляете свой браузер выполнять динамический вызов веб-сервера. Динамические вызовы (также известные как код активного сервера) не кэшируются, они должны оцениваться каждый раз, когда вы загружаете URL-адрес, браузером, связывающимся с веб-сервером. Это может или не может перезагрузить все файлы, связанные с веб-страницей. Это не изменит содержимое кеша везде.

Последнее может оказаться важным для вас. Если ваш интернет-провайдер кэширует веб-контент локально, чтобы повысить производительность для своих клиентов, и вы перезагружаете свой кэш или отдельную страницу (процедура I или процедура II, описанная выше), вы можете перезагрузить ее из кэша вашего интернет-провайдера. Если вы перезагрузите весь кеш, после динамической перезагрузки одной веб-страницы вы можете перезагрузить более старую копию с вашего интернет-провайдера. Если вы увидели новую веб-страницу при динамической загрузке страницы (процедура III выше), вы сделаете шаг назад во времени, когда загрузите кэшированную копию интернет-провайдера.

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

Это потому, что DNS моего провайдера кеширует?

6 ответов 6

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

Я столкнулся с той же проблемой и решил ее с помощью Google DNS

Откройте настройки сети/IP. Используйте DNS-серверы как:

Это Google DNS, и они решат вашу проблему, пока ваш интернет-провайдер не обновит ловушку

Отличное временное решение. Можно просто переключиться на DNS-серверы Google на день или два, пока их глупый интернет-провайдер (который не уважает TTL) не очистит кеш DNS. Я использую это, и это сработало отлично. Большое спасибо!

Здесь есть две вещи. Во-первых, это время, которое требуется вашему регистратору домена для размещения записей DNS, которые вы предоставили через какую-то веб-форму / панель управления, на DNS-серверах регистраторов. Этот процесс «обновления» обычно происходит в течение 15 минут.

Вы действительно можете проверить, кэшировал ли DNS-сервер вашего интернет-провайдера результат, явно запросив DNS-сервер интернет-провайдера с помощью команд:

TTL в поле ответа будет указывать, сколько времени RR кэшируется на сервере.

Да.Запись DNS вашего домена указывает значение TTL («время жизни»), которое предписывает клиентским компьютерам (и серверам имен интернет-провайдеров) кэшировать результаты в течение определенного периода времени, прежде чем запрашивать снова. Обычно используются значения по умолчанию от 24 до 48 часов.

Есть один хороший способ сделать будущие переходы более плавными: за несколько дней до даты перехода измените TTL на что-то очень короткое, например 300 секунд. Когда вы настраиваете новый IP-адрес, вы можете установить его обратно на 24 часа. С вашей точки зрения, главное преимущество длинного TTL заключается в том, что посетители вашего сайта получат преимущество в производительности кэшированных DNS-запросов. Это также снижает нагрузку на серверы имен вашего домена.

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

В настоящее время большая часть всего интернет-контента обслуживается с помощью сетей доставки контента (CDN). Несмотря на такую популярность, мало исследований о том, как онлайн-цензура влияет на эту технологию. Исследователи из Массачусетского технологического института проанализировали возможные методы блокировки контента, обслуживаемого CDN, на примере Китая. Они также разработали решение для обхода онлайн-цензуры с помощью кешированного контента.

Вот обзор основных идей их исследования.

Введение

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

Однако развитие Интернета привело к появлению новых технологий обмена информацией. Одним из них является кэширование контента, которое ускоряет общение и повышает производительность. Сегодня провайдеры CDN обрабатывают огромное количество веб-контента. Только компания Akamai отвечает за обработку 30 % мирового веб-трафика.

Сеть CDN – это распределенная система для лучшей доставки контента. Типичная CDN состоит из нескольких серверов по всему миру, где контент кэшируется, чтобы пользователь Интернета мог загрузить его с ближайшего кэширующего сервера вместо того, чтобы подключаться к источнику-назначению, где материал был первоначально сохранен. Это значительно увеличивает общую скорость связи и снижает нагрузку на веб-сайты, на которых изначально размещен контент.

Цензура контента на основе CDN

Несмотря на популярность технологии CDN, существует мало исследований о том, как цензоры во всем мире контролируют ее. Авторы первоначального расследования проанализировали популярные методы онлайн-цензуры и изучили их эффективность для блокировки трафика CDN. Кроме того, они сравнили свое исследование с практической ситуацией в Китае. Это страна с самыми передовыми системами государственной цензуры ("китайский брандмауэр").

IP-фильтрация

Самый популярный метод онлайн-цензуры из-за своей простоты. Этот подход предполагает обнаружение IP-адресов ресурсов с запрещенным контентом. Затем интернет-провайдеры, контролируемые цензурой, перестают доставлять пакеты, отправленные на эти адреса.

В настоящее время сетевое оборудование поддерживает фильтрацию IP-адресов, что упрощает использование этого метода цензуры. Однако он не совсем подходит для цензуры CDN. Сети CDN распределены (т.е. используют несколько IP-адресов), использование общих серверов (это означает, что блокировка будет затрагивать незапрещенный контент, размещенный на том же граничном сервере, что и запрещенный), динамическое назначение IP-адресов (даже если цензор обнаружит, что IP-адрес для блокировки, срок его действия очень скоро истечет, и контент будет размещен на другом адресе).

Вмешательство DNS

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

Вмешательство DNS — очень эффективный метод. Однако его можно обойти, используя нестандартные методы разрешения DNS, такие как внеполосные каналы. Таким образом, вмешательство DNS часто сочетается с IP-фильтрацией. Однако, как упоминалось выше, такая фильтрация неэффективна для цензуры CDN.

Фильтрация URL/ключевых слов с помощью DPI

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

Расширенный анализ DPI

Помимо использования DPI для поиска по определенным ключевым словам и URL-адресам, эту технологию можно использовать для более сложного анализа. К таким способам относятся статистический анализ онлайн/оффлайн трафика и протоколы идентификации. Это очень ресурсоемкие методы. Сведений об их активном использовании цензорами нет.

Самоцензура провайдеров CDN

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

Реальная цензура CDN: как работает китайский брандмауэр

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

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

Кроме того, в Китае есть собственные сети CDN (ChinaCache, ChinaNetCenter и CDNetworks). Все эти провайдеры соблюдают местные правила и блокируют контент, запрещенный в стране.

CacheBrowser: борьба с цензурой с помощью CDN

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

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

При попытке установить соединение с каким-либо веб-сайтом браузер запрашивает локальную базу данных DNS (LocalDNS), чтобы получить IP-адрес хоста. Обычный DNS запрашивается только для доменов, которых еще нет в LocalDNS. Модуль Scraper постоянно просматривает список запрошенных URL-адресов и ищет потенциально подвергнутые цензуре имена. Затем он отправляет запросы модулю Resolver для разрешения вновь найденных заблокированных доменов и помещения их в LocalDNS. После этого кеш браузера очищается, чтобы сбросить существующие записи DNS для заблокированного домена.

Если модуль Resolver не может понять, какому провайдеру CDN принадлежит домен, он отправляет запрос модулю Bootstrapper.

Как это работает в реальной жизни

Клиентское программное обеспечение разработано для Linux, но может быть перенесено и для Windows. Для просмотра контента используется современный браузер Mozilla Firefox. Модули Scraper и Resolver написаны на Python, а базы данных Customer-to-CDN и CDN-toIP хранятся в виде txt-файлов. В качестве базы данных LocalDNS используется обычный файл ОС Linux /etc/hosts.

NT 5.1; rv:14.0) Gecko/20100101 Firefox/14.0.1

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

Мы настоятельно рекомендуем вам обновить браузер до последней версии Internet Explorer или использовать другой браузер, например Google Chrome или Mozilla Firefox.

У вас еще нет учетной записи? Зарегистрируйтесь сейчас

15 января 2021 г., 15:59

Обход кэш-серверов Rogers YouTube

Есть много жалоб на то, что Роджерс "задушил" YouTube. Это не дросселирование, их кеш-серверы YouTube плохие или перегружены. Хотя у меня нет этой проблемы, мне любопытно, можно ли обойти эти серверы и выполнять потоковую передачу напрямую из Google вместо Rogers CDN. Интересно, знает ли кто-нибудь, как этого добиться. Я нашел старую ветку 2013 года, предлагающую следующее:

Однако эти диапазоны IP-адресов принадлежат Verizon/XO, и я не вижу, чем это может помочь. Я пробовал это, и это не имело никакого эффекта. На самом деле, я никогда не видел попыток подключения к этим IP-адресам.

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

Есть ли у кого-нибудь хотя бы теория, как этого добиться?

15 января 2021 г., 16:19

15 января 2021 г., 16:31

Самый простой способ решить эту проблему — использовать VPN для туннелирования трафика YouTube за пределы сети Роджерса.

Возможно написать подключаемый модуль для браузера (или прокси-сервер для перехвата TLS), который будет перенаправлять запросы YouTube на сайты CDN YouTube за пределами Rogers, но я не знаю ничего готового, что делает это.< /p>

15 января 2021 г., 16:53

middleofnowhere написал: ↑ Самый простой способ решить эту проблему — использовать VPN для туннелирования трафика YouTube за пределами сети Роджерса.

Известно, что VPN работает, но это довольно неудобно. Я не хочу использовать VPN ни для всей своей гигабитной сети, ни для отдельных устройств.

15 января 2021 г., 17:02

alpovs написал: ↑ Известно, что VPN работает, но это довольно неудобно. Я не хочу использовать VPN ни для всей своей гигабитной сети, ни для отдельных устройств.

Вы можете использовать маршрутизацию на основе политик, чтобы перенаправлять пакеты, предназначенные для диапазонов IP-адресов YouTube, в VPN, позволяя всем остальным проходить напрямую через Rogers.

15 января 2021 г., 17:20

middleofnowhere написал: ↑ Вы можете использовать маршрутизацию на основе политик, чтобы перенаправлять пакеты, предназначенные для диапазонов IP-адресов YouTube, в VPN, позволяя всему остальному проходить напрямую через Rogers.

Здесь есть проблема. Что такое IP-адреса YouTube? На Rogers соединения идут напрямую в CDN. Так что я действительно не знаю, как работает эта система. Я пробовал разные DNS, но ничего не изменилось. Кроме того, ваша идея требует постоянно включенного VPN, что возможно, но неудобно. Если бы у меня были настоящие проблемы, как у других, я бы это сделал. Сейчас я ищу более хитрое решение со статическими маршрутами.

15 января 2021 г., 22:45

Ааа, вот почему я заметил, что видео на YouTube иногда тяжело загружаются, когда большинство тестов скорости показывают 400–500 Мбит/с.
P.s. будет ли полезно проверить, по какому маршруту идут запросы к youtube?

15 января 2021 г., 23:25

alpovs написал: ↑ Здесь есть проблема. Что такое IP-адреса YouTube? На Rogers соединения идут напрямую в CDN. Так что я действительно не знаю, как работает эта система. Я пробовал разные DNS, но ничего не изменилось. Кроме того, ваша идея требует постоянно включенного VPN, что возможно, но неудобно. Если бы у меня были настоящие проблемы, как у других, я бы это сделал. Сейчас я ищу более хитрое решение со статическими маршрутами.

Хотя у меня нет этой проблемы, мне любопытно, можно ли обойти эти серверы и вести потоковую передачу напрямую из Google вместо Rogers CDN. Интересно, знает ли кто-нибудь, как этого добиться

Итак, о чем вы снова просите? Он знает. Это работа на 10 минут. если что.

Сменить интернет-провайдера? Пользуетесь Wi-Fi соседей? Создать собственный локальный кеш?

Я использую Windows-клиент PIA, у него есть раздельное туннелирование на основе приложений. Клиент PIA запускается с окнами и устанавливает туннель. Я использую Chrome для Youtube и Firefox для всего остального.

16 января 2021 г., 00:32

Я ищу решение, подобное упомянутому в ОП, например, iptables, возможно, хитрости DNS. Решение iptables работало в то время. Интересно, знает ли кто-нибудь, что изменилось.

Я смотрю YouTube в основном на STB, поэтому VPN не подходит для других приложений.

16 января 2021 г., 1:55

alpovs написал: ↑ Я ищу решение, подобное упомянутому в OP, например, iptables, возможно, трюки с DNS. Решение iptables работало в то время. Интересно, знает ли кто-нибудь, что изменилось.

Я смотрю YouTube в основном на STB, поэтому VPN не подходит для других приложений.

Направьте трафик YouTube на другой прокси-сервер. Вы уже рассматривали решения iptables, это то. но направить на прокси-сервер. (перенаправление)

пс. Кроме того, предполагается, что прокси-сервер принадлежит другому интернет-провайдеру, а не Rogers.

<р>
. но у вас нет этой проблемы. Пытаешься помочь какой-то девушке? (т.е. у вас нет проблемы, но вы зашли достаточно далеко, чтобы попробовать решение, о котором вы упомянули, и поняли, что оно не работает. и теперь спрашиваете решение и дали несколько ответов. И когда кто-то ответил с возможное решение, вы хотели что-то, что работает для вас, для вашей ситуации и удобства. Это больше, чем просто «любопытство».)

16 января 2021 г., 9:20

chatbox написал: ↑ Итак, о чем вы снова просите? Он знает. Это работа на 10 минут. если что.

Сменить интернет-провайдера? Пользуетесь Wi-Fi соседей? Создать собственный локальный кеш?

Я использую клиент PIA для Windows с раздельным туннелированием на основе приложений. Клиент PIA запускается с окнами и устанавливает туннель. Я использую Chrome для Youtube и Firefox для всего остального.

OP, я использую Windscribe (клиент на моем Amazon Fire TV), и у него есть аккуратный режим раздельного туннелирования, в котором вы можете выбрать либо список приложений для туннелирования, либо список приложений, которые нужно исключить из туннеля. Попробуйте

16 января 2021 г., 10:22

Что такое трафик YouTube? Большая часть уже идет в CDN Rogers, так что туда пойдет через прокси. Это ничего не изменит.

Я искал ответы у человека, который знает, как работает распределение трафика при использовании CDN.Должна быть возможность обойтись без оплаты VPN.

16 января 2021 г., 12:38

alpovs написал: ↑ Что такое трафик на YouTube? Большая часть уже идет в CDN Rogers, так что туда пойдет через прокси. Это ничего не изменит.

Я искал ответы у человека, который знает, как работает распределение трафика при использовании CDN. Должна быть возможность не платить за VPN.

ОП, ты многое теряешь, не желая использовать VPN. Много бесплатного телеконтента, фильмов и т. д., и все это легально. Кроме того, моя стоимость VPN составляет всего 2 доллара в месяц (только США и безлимитный трафик). Гораздо выгоднее и намного надежнее, чем интеллектуальная служба DNS, которой я пользовался раньше

16 января 2021 г., 13:41

Я искал ответы у человека, который знает, как работает распределение трафика при использовании CDN. Должна быть возможность обойтись без оплаты VPN.

Это сработает. Прокси-сервер просто должен иметь поставщика услуг Интернета, отличного от Rogers.

Вы--> Rogers CDN (Ваш провайдер) --> интернет-обмен (в другой стране) --> Какой бы ни был провайдер (ISP прокси-сервера) --> Прокси-сервер

Затем прокси-сервер видит запрос:
Proxy Server --> Какой бы ни был провайдер (ISP прокси-сервера) --> bounce, bounce, в конце концов youtube

Затем YouTube возвращается на прокси-сервер обратно к вам. Думайте не только о Канаде.

Если вы настаиваете на том, что это не работает, хорошо, мистер "У меня нет этой проблемы".

16 января 2021 г., 15:11

chatbox написал: ↑ Это сработает. Прокси-сервер просто должен иметь поставщика услуг Интернета, отличного от Rogers.

Затем YouTube возвращается на прокси-сервер обратно к вам. Думайте не только о Канаде.

Если вы настаиваете на том, что это не работает, хорошо, мистер "У меня нет этой проблемы".

Вы не поняли мой вопрос. Что такое трафик YouTube?

Определяется ли он IP или URL? У вас есть список IP-адресов и URL-адресов?

Если по IP, какой смысл отправлять трафик на Rogers CDN через прокси? В любом случае он попадет в Rogers CDN. Итак, это IP-адрес, с которого YouTube часто транслирует: 209.148.198.141 Он принадлежит Роджерсу. Как вы думаете, если я перенаправлю его на прокси, он подключится к другому IP-адресу, отличному от Rogers? ИП есть ИП. URL-адреса должны быть перенаправлены на прокси. Вероятно, все они заканчиваются на «googlevideo.com», но iptables работает с IP-адресами. Кроме того, различные DNS-серверы, не принадлежащие Rogers, по-прежнему волшебным образом преобразуют эти URL-адреса в IP-адреса Rogers.

16 января 2021 г., 15:42

alpovs написал: ↑ Вы не поняли мой вопрос. Что такое трафик YouTube?

Определяется ли он IP или URL? У вас есть список IP-адресов и URL-адресов?

Если по IP, какой смысл отправлять трафик на Rogers CDN через прокси? В любом случае он попадет в Rogers CDN. Итак, это IP-адрес, с которого YouTube часто транслирует: 209.148.198.141 Он принадлежит Роджерсу. Как вы думаете, если я перенаправлю его на прокси, он подключится к другому IP-адресу, отличному от Rogers? ИП есть ИП. URL-адреса должны быть перенаправлены на прокси. Вероятно, все они заканчиваются на «googlevideo.com», но iptables работает с IP-адресами. Кроме того, различные DNS-серверы, не относящиеся к Rogers, по-прежнему волшебным образом преобразуют эти URL-адреса в IP-адреса Rogers.

Я не знаю, какие вопросы вы задали первыми, но что касается вашего комментария о DNS, и Firefox, и Chrome теперь имеют встроенную поддержку DoH. Инструкции по включению и использованию DNS-серверов сторонних производителей в Firefox и Chrome можно найти здесь.

16 января 2021 г., 16:05

alpovs написал: ↑ Вы не поняли мой вопрос. Что такое трафик YouTube?

Определяется ли он IP или URL? У вас есть список IP-адресов и URL-адресов?

По IP — это все, с чем работает iptables. Я уже упоминал об этом в одном из предыдущих ответов.

Затем используйте локальный DNS или измените IP-адрес назначения. Нельзя это нельзя то. ты троллишь что ли? Вы поколение ложных кормлений? Иди и проведи небольшое исследование.

Как вы это описали. можно утверждать, что Роджерс в некотором роде «отравляет» DNS (вопрос перспективы). Если это так, просто используйте безопасную службу DNS на своем маршрутизаторе.

16 января 2021 г., 17:57

Было бы неплохо, если бы это было исправлено.Пытаюсь смотреть YouTube в 4K на Nvidia Shield в часы пик, и это буквально невозможно.

Вот короткий ролик, который я сделал, показывающий, насколько это раздражает и как это явно связано с Роджерсом. Вначале я проигрываю случайное 4K-видео на YouTube, и вы можете видеть, как оно постоянно буферизуется. Затем я включаю бесплатный VPN и снова проигрываю клип. Абсолютно без буфера.

16 января 2021 г., 19:51

Да, мне нужно решение этой проблемы. У меня гигабит от Роджера, и YouTube НЕ должен так буферизоваться. Любые рекомендации VPN для региона GTA? Тот, который достаточно быстр для гигабитных подключений?

16 января 2021 г., 20:06

Jruuu писал: ↑ Я не знаю, какие вопросы вы задали первыми, но что касается вашего комментария о DNS, то и Firefox, и Chrome теперь имеют встроенную поддержку DoH. Инструкции по включению и использованию DNS-серверов сторонних производителей в Firefox и Chrome можно найти здесь.

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

Читайте также: