Привет, Хабр!
В последнее время замечаю огромное количество информации по поводу замедления Великого, но очень мало где видел конкретику о том, как именно это работает. Одно лишь отчаяние "мы все умрём".
Сразу скажу, что буду говорить обо всём, что известно на данный момент. Понятно, что с этим разбирался далеко не один я: огромное спасибо обывателям ntc party форума за проделанный ресёрч.
Так вот, начнём сначала, с злополучного GGC. Официальное заявление было, что кэш сервера устарели и долго не обновлялись, но у многих возникло такое скептическое чувство: "до этого работали, а тут в один момент всё поломалось". К тому же есть статья на википедии, которая утверждает, что разговоры про эти GGC шли еще с 2018 года. Да и если это были они, у нас бы плохо работала львиная доля гугл сервисов, включая Google Drive, Google PlayMarket, Google Images. А оно работает прекрасно, как и прежде.
Дальше рассмотрим идею, что это вообще гугл тестирует ограничение загрузчиков типа yt-dlp, потому что, в первую очередь, проблемы коснулись именно их. Идея на самом деле интересная, потому что действительно на современных протоколах (QUIC) всё хорошо работает, а проблемы есть только на старом добром TCP (сейчас ходят слухи, что и QUIC начали ограничивать, и, вроде как, я могу это подтвердить). Эту и предыдущую идеи мы опровергнем далее.
Как только я начал разбираться с этой проблемой и открыл Wireshark, меня ждали логи, состоящие наполовину из красных полос. Я не стал особо думать над тем, как именно замедляется ютуб со стороны TCP, но сразу стало понятно, что замедление искусственное, потому что если бы это были GGC, они бы либо не работали вообще, либо просто скорость была маленькая, а тут тонны потерянных пакетов. А еще забавно, что с QUIC, который автоматом работает в хроме такого вообще не происходило и скорость была в норме. Я начал искать и вспомнил про один очень крутой форум по обходу всяких подобных приколов с цензурой интернета, ntc party. Там я нашёл, как именно замедляется ютуб и контрпример, подтверждающий на 100%, что это проделки большого брата.
Но перед тем, как назвать способ замедления, давайте подумаем, а как они могут вообще определить, что я смотрю ютуб просто видя raw ip пакеты. Пойдём с самого низкого уровня, который может их заинтересовать, IP. Что тут есть? IP адрес. И это очень мощный инструмент, правда если их не тысячи, и если на них работает только один сервис, googlevideo. В случае огромной инфраструктуры гугла их банально сложно получить, я уже не говорю про то, что если на одном айпишнике работают, скажем гуглвидео и гугл плеймаркет, а ведь вероятность такая есть, это же GGC как никак. Тогда обрубая одно, обрубим и другое. Что делать? Посмотрим выше. На TCP мало чего интересного, поднимаемся еще выше. А дальше TLS. И это всё? Почти... Да, современные протоколы сделаны так, чтобы шифровать всё, что можно. Но есть только одно исключение. В спецификации TLS есть такая вещь, как SNI. Она передаётся серверу и говорит ему, к какому именно сайту мы хотим подключиться и, следовательно, какой именно сертификат нам давать. Что-то типа Host в HTTP, но для TLS. Так вот, этот самый SNI спокойно себе передаётся в незашифрованном виде. Было много спецификаций, предлагающих его зашифровать, но мэйнстримом оно не стало. К тому же, провайдеры блокировали такие подключения, чтобы не мешали следить за юзерами.
Так вот, SNI лежит в незашифрованном виде в Client Hello, и, обнаружив его, мы можем коннмарком пометить соединение и выкидывать рандомные пакеты.
Я знаю, что вы ждёте пруфов, господа, и вот они:
curl --connect-to ::speedtest.selectel.ru https://manifest.googlevideo.com/100MB -k -o/dev/null Что мы видим в этом curl запросе? У curl'a есть возможность подключаться к серверу с его именем, но вместо резолвинга DNS поставить какой-нибудь свой айпи. При этом вся информация более высокого уровня будет передаваться, как будто мы используем именно это имя. Такое поведение заставляет curl подменять тот самый SNI (ну еще и Host, но это нас не особенно интересует). -k флаг используется, чтобы отключить проверку сертификатов (она провалится, потому что speedtest.selectel.ru будет нам давать свой сертификат, но никак не желаемый от гуглвидео). И если запустить это запрос, то мы получим весёлую скорость в 120 килобайт на начале, и дальше она пойдёт на спад. Даже до нуля может дойти. А теперь замените любую букву в googlevideo на другую и скорость прыгнет до нормальной скорости интернета. Всё стало на свои места.
Как с этим бороться?
Конечно, способы борьбы существуют. Для этого будем думать в сторону манглинга (изменения) пакетов. Но если мы просто заменим googlevideo.com на yandex.ru, получим ошибку сертификатов. И не факт что браузер вообще позволит отключить эту проверку для гуглвидео и нормально будет с этим жить. Так что же делать?
Вспомнить про то, что ТСПУ - это всё-таки очень высоконагруженная штука, которая вряд ли будет запоминать, что и когда мы там отправляли в сеть, и, соответственно, если мы просто разобьем наш запрос на два в середине SNI, то О Чудо! Всё начинает работать. В моём случае не понадобились даже фейковые Client Hello или задержка между пакетами (но вроде как ему всё-таки нужен обратный порядок пакетов: сначала идёт хвост, потом голова).
Как разбивать? Есть два варианта: фрагментами IP и на уровне сегментации TCP. У меня лично фрагментация IP сначала работала на половину, а потом и вообще отвалилась. Возможно, провайдеру не понравилось. Идём выше, к TCP. И тут у них всё очень приятно работает. Даже несмотря на то, что я, казалось бы, из одного пакета сделал два, поменял размеры двух пакетов, я не нарушил никаких правил TCP соединения: Ack по количеству доставленных байт - вещь.
Готовые средства обхода. Ну и самое вкусненькое. Я лично написал своё решение под линукс, которое направлено только на ютуб. Также для Windows существует GoodbyeDPI от ValdikSS, под линукс еще есть zapret. Существует ByeDPI, который работает как прокси (Windows/Linux). Также есть версия ByeDPI под андройд, работает как "фейковый впн". Советую прочитать подробный комментарий от ValdikSS о том, как использовать эти средства. Если есть желание погрузиться глубже в эту тему, вот тут можно посмотреть подробнее: https://ntc.party/t/замедление-youtube-в-россии/8055/ and https://ntc.party/t/обсуждение-замедление-youtube-в-россии/8074/
Комментарии (77)
Succinate
31.07.2024 04:59"А оно работает прекрасно, как и прежде." - а где ссылка на исследование? Где пруфы? Получается доказательства на уровне БесогонТВ
UranusExplorer
31.07.2024 04:59+54А вы статью дальше вступления вообще читали? Тут вся статья состоит из пруфов, и приложены ссылки где можно найти дополнительную информацию. Или вам важнее громко покричать "рряяяя, пруфов нет!!!1", даже если на самом деле они есть, чтобы забить информационное поле своим шумом?
vikarti
31.07.2024 04:59+6А вот это - уже просто не вежливо.
Пруфы были в прошлых статьях по данной теме.
Да и тут - автор прямо привел что он тестировал.
И ссылок - куча прям в статье.
Да, нет ответа почему у некоторых как минимум провайдеров если видео популярное и прямо с GGC идет но тут чисто логики хватает понять что могут быть разные схемы подключения ТСПУ.
На момент начала всей истории - говорить что ну возможно это все же GGC посыпались еще имело какой то логичный смысл(хотя...все сразу? причем сначала заявления а потом взяли и посыпались?) но после прошлых статей и тут и не тут - какие ЕЩЕ вопросы? А тем кто пришел на Хабр не понимая что это технический все же ресурс и не понимает реально о чем вообще в статье речь - сам факт что кое кто из Выдающихся Партийных И Государственных Деятелей ДВАЖДЫ переобувался в прыжки в рассказе что происходит - сомнений прям никаких не вызывает?
p.s.
Ну зачем так грубо делать? Обоснования вида "да, замедляем, потому что не выполняет законы совсем и диалог вести не хочет, прекратим если хоть вид начнет делать что выполняет а для начала - разблокирует каналы" (которое И ТАК прозвучало) - хватило бы. Все и так привыкли что надо совершенствовать Технические Средства Предотвращения Угрозам Цензуры (ТСПУ-Ц) а у кого еще нет - ставить.
slinkinone
31.07.2024 04:59+4Вспомнить про то, что ТСПУ - это всё-таки очень высоконагруженная штука, которая вряд ли будет запоминать, что и когда мы там отправляли в сеть, и, соответственно, если мы просто разобьем наш запрос на два в середине SNI
Конечно будет. Это называется reassembling. После сборки сообщение и выдергивания из него нужных данных для классификации - буфер сборки просто очистится.
А какой у вас интернет провайдер, который не может из двух пакетов SNI собрать?)
Как разбивать? Есть два варианта
Еще есть фрагментация на уровне TLS, но она крайне редко встречается. Также есть фрагментация в DTLS протоколе, которая немного по другому работает. И
UranusExplorer
31.07.2024 04:59+10Конечно будет. Это называется reassembling
К счастью, как показывает практика, многие РКНовские ТСПУ реассемблинг ниасилили. Что впрочем не гарантирует, что рано или поздно их допилят и научат такому.
Waujito Автор
31.07.2024 04:59+8У меня Ростелеком. Он вроде как реассемблит, но если отправлять пакеты в обратном порядке, уже сдувается.
Допилить это, в принципе, не сложно: если у них уже есть технологии, позволяющие это всё нормально хранить, то им достаточно будет посмотреть на оффсет у TCP. В общем, пока работает - не трогаем, дальше будем думать.
Про фрагментацию на уровне TLS интересное замечание. Нашёл статью, которая предлагает именно для этих целей её и использовать.
0HenrY0
31.07.2024 04:59Допилить это, в принципе, не сложно.
А кто будет допиливать? После покупки RDP.RU Ростелекомом у них всё R-n-D по DPI встало. Официально, конечно, финансирование идёт, но до разработчиков не доходит.
ColdPhoenix
31.07.2024 04:59+9Конечно будет. Это называется reassembling. После сборки сообщение и выдергивания из него нужных данных для классификации - буфер сборки просто очистится.
Это дорого для транзитного траффика, на мелких сетях может и вытянет, но на крупных нет.
Итак столкнулись однажды с тем что при ДДОС-атаке легла ТСПУ))
slinkinone
31.07.2024 04:59+1Верно. Действительно это накладывает дополнительные издержки.
Но стоит учитывать что классификация происходит единожды и затем сетевой поток оффлоадится (offload), то есть, последующие пакеты больше не анализируются, а блокируются и/или шейпятся. Таким образом, достаточно лишь обработать от 1 (first packet classification), до примерно трех пакетов (при адекватной сегментации), чтобы определить сервис и затем освободить память.
От всего объема трафика, процент тех кто использует средства обхода крайне мал. То есть для системы (возьмем для примера один кластер), которая тянет допустим 10М потоков, 1к потоков мелко фрагментированного трафика не является значительным в плане перфоманса - это всего
0,0001%от общей нагрузки.ColdPhoenix
31.07.2024 04:59+2По-идее установка нового соединения самая тяжелая операция, потому и срезали где могли.(а даже без ДДОС могут быть скачки, например при работах в домах и тп)
Это немного нестандартное поведение вроде как, но легитимное.
Где-то писали что зачастую даже перестановка пакетов не обрабатывается ими.
Станет распространено, скорее всего доучат железку.
ADD: возможно еще из-за того что сделает легче атаку на саму железку, ей же придется выделять память под это.
slinkinone
31.07.2024 04:59Итак столкнулись однажды с тем что при ДДОС-атаке легла ТСПУ
Это вполне реально=) Но складывается впечатление, что это вина не ТСПУ, а системы DDOS защиты. Потому что сам DPI обычно не определяет DDOS. DDOS должен отлавливаться на смежном сервисе, и не допускать флуд пакеты до анализатора.
ColdPhoenix
31.07.2024 04:59+2не припомню чтоб с ТСПУ ставилась защита еще.
Провайдеры ж не будут ставить защиту за свой счет для клиентов.
redfox0
31.07.2024 04:59+7А какой у вас интернет провайдер, который не может из двух пакетов SNI собрать?)
Я посылаю довольно большой TLS ClientHello Padding Extension (12КБ+), тогда провайдер не видит SNI и пропускает трафик.
slinkinone
31.07.2024 04:59+2Такой сценарий действительно выглядит реальным. Особенно если
server_nameextension размещен в конце секцииextensions.Буфер не может собираться вечно и будет сброшен. Получится что SNI не был выхвачен из первых N пакетов. Последующие пакеты либо просто будут заофложены как для неизвестного сервиса, либо в уже будут возникать трудности с диссекцией.
hogstaberg
31.07.2024 04:59+3Только память не резиновая, поэтому можно либо большой padding вставить (больше, чем выделяется буфер на соединение), либо просто задержку между пакетом с первой половиной sni и пакетом со второй половиной вставлять. В какой-то момент dpi вынужден будет решить что соединение сдохло и буфер почистить по таймауту.
Самое приятное в том, что это чисто софтово не фиксится в общем-то, только закидыванием железом.
UranusExplorer
31.07.2024 04:59+1Либо просто начнут блочить полностью все, из чего не получилось выцепить SNI. А то что у юзеров что-то сломается из-за этого - проблемы индейцев шерифа не волнуют.
vikarti
31.07.2024 04:59Напрашивается вариант - дать найти что хотят и пусть успокоятся.
Например...какой то вариант domain fronting - точно не пройдет? Ну да - из браузера такое не задействуешь но если все равно уже GoodbyeDPI и аналоги пошли в ход...
А если ломаться будет что-то важное шерифу?
Ну и опять же вопрос - с не-HTTP-в-принципе что делать то? Тоже блочить?
UranusExplorer
31.07.2024 04:59А если ломаться будет что-то важное шерифу?
У самого шерифа будет нормальный нефильтрованный доступ, понятное дело. Что дозволено Юпитеру не дозволено быку.
какой то вариант domain fronting - точно не пройдет?
Проблема в том что сегодня все меньше и меньше платформ разрешают этот самый fronting. Такой чтобы нормальный, с выдачей правильного сертификата. Cloudflare не разрешает (только со своими собственными доменами), Amazon не разрешает, Fastly объявил что скоро запретит (возможно уже запретил)...
с не-HTTP-в-принципе что делать то? Тоже блочить?
Да, они уже так делали, в моменты обострения шизы тупо блокируя вообще все что не смогли опознать (в итоге у людей перестал работать Radmin, выяснилось что ТСПУ не знает его протокол). Китайцы таким тоже развлекаются, даже отчёт GFW-Report на эту тему есть.
slinkinone
31.07.2024 04:59+2Вспомнить про то, что ТСПУ - это всё-таки очень высоконагруженная штука, которая вряд ли будет запоминать, что и когда мы там отправляли в сеть, и, соответственно, если мы просто разобьем наш запрос на два в середине SNI
Конечно будет. Это называется reassembling. После сборки сообщение и выдергивания из него нужных данных для классификации - буфер сборки просто очистится.
А какой у вас интернет провайдер, который не может из двух пакетов SNI собрать?)
Как разбивать? Есть два варианта
Еще есть фрагментация на уровне TLS, но она крайне редко встречается. Также есть фрагментация в DTLS протоколе, которая немного по другому работает.
slinkinone
31.07.2024 04:59+14Было много спецификаций, предлагающих его зашифровать, но мэйнстримом оно не стало.
На мой взгляд, многие шифрованные штуки не вошли в постоянный обиход (IPv6, Encrypted SNI, DNS over TLS), по причине того, что это не выгодно с точки зрения бизнеса. Если убрать сигнатуры по которым можно определять сервис, то мобильные операторы не смогут разделать трафик, предлагать разные тарифы, "качественно" делать балансировку. Интернет принадлежит тем, кто его обслуживает.
Интернет провайдеры и мобильные операторы - это бизнес, который должен во-первых соблюдать законы государства, где он работает, а во-вторых, иметь возможность "гибко завлекать пользователей" и предоставлять конкурентноспособный уровень сервиса. Если убрать маркеры для классификации сервисов, то такой бизнес столкнется с большими трудностями. Есть ощущение что это работает плюс-минус одинаково во всех странах.
ogost
31.07.2024 04:59+10Нахожусь вне РФ, то бишь вне зоны действия "русского большого брата". yt-dlp и newpipe на андроиде отвалились у нас на (поза?)прошлой неделе, но после обновления всё опять заработало. Подозреваю, что в моём случае это борьба гугла с блокировщиками рекламы, которая в вашем случае ещё и наложилась на действия сами-знаете-кого.
shurakenas
31.07.2024 04:59у себя для обходов использую, keenetic + shadowsocks, добавил в unblock 142.250.0.0/15 (googlevideo.com), пока вроде работает, тормоза пропали
rendov
31.07.2024 04:59Вы хотели сказать: "keenetic + shadowsocks + vps"?
Просто не понятно, куда ваши "теневые носки" стучатся то по итогу.
Alexey2005
31.07.2024 04:59При наличии забугорного VPS обход блокировок вообще не проблема, банального ssh -D 8888 my_user@my_vps на клиенте хватает, чтобы трафик проксировать. Никак VPN'ов не надо, и вообще на сервер ничего дополнительно ставить и настраивать не нужно.
Вот только забугорный VPS - это дорого, плюс сложности с оплатой.
UranusExplorer
31.07.2024 04:59+1VPS - это дорого, плюс сложности с оплатой
Давно уже есть вполне прилично работающие варианты за ~80 рублей в месяц и оплатой российскими картами, куда уж дешевле и проще-то?
nicolas_d
31.07.2024 04:59+3В целом, ваш метод можно использовать и не только для youtube, а для всех доменов, на котором сработает такой трюк. Не обязательно замедление, но и просто блокирование по SNI. Достаточно будет из кода вынести список обрабатываемых доменов и добавить метод загрузки при инициализации.
nerudo
31.07.2024 04:59У меня остался ряд вопросов:
Откуда идут разговоры, что ютуб замедляют только на стационарных ПК, а на мобильных устройствах он продолжает работать?
Как это сделать технически — резать трафик в разных точках в зависимости от типа провайдера?
Зачем советуют менять user‑agent в браузере, если он передается в зашифрованном потоке и не должен быть доступен чекистам?
ColdPhoenix
31.07.2024 04:59+6Откуда идут разговоры, что ютуб замедляют только на стационарных ПК, а на мобильных устройствах он продолжает работать?
Из того что находил в комментариях, приходят разные доменные имена сервера отдачи видео для мобильного и десктопа.
Зачем советуют менять user‑agent в браузере, если он передается в зашифрованном потоке и не должен быть доступен чекистам?
Собственно выше, сам гугл отдает другое имя сервера(даже если ведет в тот же адрес) для мобильных.
а замедляют по SNI(который не шифрован)
Повторю: то что видел в комментариях.
Popadanec
31.07.2024 04:59У меня так. На ПК без средств борьбы с ТСПУ, ютуб работает в лучшем случае на 480р, на смартфонах и ТВ приставках всё в порядке с того же интернета. Когда начнут замедлять и их, придётся доставать кинетик и устанавливать решение на него.
Aelliari
31.07.2024 04:59+2Откуда идут разговоры, что ютуб замедляют только на стационарных ПК, а на мобильных устройствах он продолжает работать?
Отсюда, и, возможно от собственных тестов
Как это сделать технически — резать трафик в разных точках в зависимости от типа провайдера?
Да, на части линков в DPI включить шейпер, а на части - нет. Естественно это только в случае искусственного замедления
Waujito Автор
31.07.2024 04:59Мне лично кажется, что проблема в QUIC. Они к нему по-особому относятся. Ходили слухи, что и его начали резать, но тут тоже вопросы. Там чуть ли не разные способы кодирования сообщений у хрома и фаерфокса. Вот где-то тут мобилки и отсеиваются, скорее всего. Я сейчас свой подключил - в ваершарке обычные Client Hello с обычным SNI, но сам SNI extension лежит ниже и ютуб работает на QUIC.
Да и в принципе, как выше писали, на мобильную сеть могут быть другие ограничения по сравнению с проводом.
Shizarium
31.07.2024 04:59Как минимум анекдотичные свидетельства показывают, что режут на стационарных устройствах. У меня в дом заходит оптика МТС - ютуб работает на последнем издыхании. В телефоне сим карта МТС - никаких проблем с сайтом. Такая же информация от знакомых и коллег, ни от кого не слышал, что появились новые проблемы при подключении с телефонов.
AnyKey80lvl
31.07.2024 04:59+1Видимо, основная идея движа - что пользователи, замучавшись с тормозящим YT, плавно само переползут на другие площадки.
hogstaberg
31.07.2024 04:59+5Одна проблема: многие авторы не переползут. Одни потому, что на других площадках монетизации нет или она околонулевая. Другие потому, что контент так-то далеко не только российские авторы клепают. А нет контента - нет пользователей.
LinkToOS
31.07.2024 04:59Там я нашёл, как именно замедляется ютуб и контрпример, подтверждающий на 100%, что это проделки большого брата.
У меня Йутуб только в Firefox тормозит. В Opera все отлично. Не знаю кто ваш брат, но Firefox ему определенно не нравится.
Waujito Автор
31.07.2024 04:59+1Проблема в лисе (или в ютубе, может быть, они так хромиум продвигают). Он не всегда использует QUIC. Я бы даже сказал по-настроению. В хроме все стабильнее.
miksoft
31.07.2024 04:59И если запустить это запрос, то мы получим
Я правильно понимаю, что на адресе speedtest.selectel.ru:443 находится прокси, через который доступны другие сайты в интернете?
Иначе почему мы вообще что-то получим?
Waujito Автор
31.07.2024 04:59+2По-моему, название говорит само за себя. inline сервис для проверки скорости. Можно подключиться `curl speedtest.selectel.ru/100MB -o /dev/null` и мы получим скачивание 100MB файла на максимально возможной скорости интернета. Методом, который указан в curl запросе я подменяю Host и TLS SNI на те, которые нужны. speedtest.selectel.ru никак это не обрабатывает, зато ТСПУ видит googlevideo SNI и начинает шейпить данные.
Причём если ввести не *.googlevideo.com, а google.com, скорость восстанавливается.
miksoft
31.07.2024 04:59speedtest.selectel.ru никак это не обрабатывает
Выглядит как дыра в безопасности.
Selectel вы же в курсе, да? Это норм?
miksoft
31.07.2024 04:59+2А, понял, имеется в виду "Домен в url игнорируется", а не "Домен используется из url".
Тогда вроде не дыра...
Waujito Автор
31.07.2024 04:59+3Так они специально это сделали. Чтобы люди тестировали свою скорость. Там собственно и "дырить" нечего) Какой им смысл запрещать другие SNI или Host.
К слову, такое можно и с гуглвидео провернуть, в другую сторону. Я копировал огромный запрос из yt-dlp логов, подменял SNI на yandex.ru, Host header ставил обратно в googlevideo, и connect-to в ::.googlevideo.com. Всё работало. Я писал об этом где-то в yt-dlp issue. https://github.com/yt-dlp/yt-dlp/issues/10443#issuecomment-2237395791
UranusExplorer
31.07.2024 04:59Я копировал огромный запрос из yt-dlp логов, подменял SNI на yandex.ru, Host header ставил обратно в googlevideo, и connect-to в ::.googlevideo.com. Всё работало
вы изобрели domain fronting :)
Chelovechek1311
31.07.2024 04:59Адрес speedtest.selectel.ru:443 выбран просто как доступный в сети адрес, идея того curl запроса в том, что запросу принудительно присваивается ютубовский SNI, и, как следствие, ТСПУ по признаку этого SNI замедляет передачу данных. Также сайт спидтеста селектела удобен тем, что можно указывать размер файла и наглядно увидеть падение скорости(это можно заметить в SNI, в конце написано 100MB).
vikarti
31.07.2024 04:59Там находится сервер которые просто отвечает на запросы как должно (отдачей конкретных тестовых файлов) При этом на то, что было передано в заголовке host и TLS SNI - ему плевать.
Можно самостоятельно поднять свой тестовый сервер. Или найти другой такой же.
AlexEx70
31.07.2024 04:59Есть ли решение для телевизоров, в частности на WebOS?
Waujito Автор
31.07.2024 04:59Да, можно поставить OpenWRT на роутер и собрать для него один из пакетов из заключения (я свой тестировал, есть инструкция по кросс-компиляции)
Lastloony
31.07.2024 04:59а вот с этим по подробнее, можно ссылочку на инструкцию?
Waujito Автор
31.07.2024 04:59https://github.com/Waujito/youtubeUnblock?tab=readme-ov-file#openwrt-case
Для моего работает. Главное - чтобы тулкит было подходящим.
andreysam
31.07.2024 04:59"Любимый" WebOS не имеет функции прокси, поэтому пришлось поднимать zapret на openwrt как прозрачный прокси и через DHCP выдавать адрес этого роутера как шлюз. Ютуб летает, как бонус стали грузить Аватарки.
VADemon
31.07.2024 04:59+2GGC. Официальное заявление было, что кэш сервера устарели и долго не обновлялись
Нарушен новостно-временной континуум. Сначала есть проблема, а потом, после анализа, об этом становится известно на политическом уровне. А не наоборот или одновременно с появлением проблемы.
vikarti
31.07.2024 04:59+5Как бы вспоминается же :)
Горбачев звонит Рейгану:
— Примите наши соболезнования по поводу взрыва «Челленджера»!
— Но «Челленджер» взлетает только через минуту…
— А-а, извините, я позвоню позже.
maxtorchel
31.07.2024 04:59Я может что-то не понимаю, но разве DoH и ему подобные не должен помочь? Зачем огород городить, тем более это уже во многих браузерах и роутерах встроено.
SagePtr
31.07.2024 04:59+1DoH отвечает только за DNS-запросы, но никак не за запросы к серверу, которые и замедляются в данном случае.
igatrinit
31.07.2024 04:59Спасибо за статью, но есть претензии то ли к формулировке, то ли к логической цепочке в одном абзаце:
"Как только я начал разбираться с этой проблемой и открыл Wireshark, меня ждали логи, состоящие наполовину из красных полос... тут тонны потерянных пакетов." - Если вы не меняли цветовую схему Ваершарка (а что-то мне подсказывает, что не меняли), то красные полосы - это флаг TCP RST, который к потерям имеет только очень опосредованное отношение.
если бы это были GGC, они бы либо не работали вообще, либо просто скорость была маленькая, а тут тонны потерянных пакетов. " - Скорость не бывает "просто маленькая". С т.з. анализа трафика самая распространенная (разумеется, не единственная) причина низкой скорости - это именно потеря пакетов, которая может происходить по разным причинам.
Т.е. весь этот абзац, откуда я это скопировал, можно прочесть как "Я увидел кучу RST флагов, а это значит, что много потерь, а это значит, что занижение искусственное.". Нет, не значит, и нет, не значит.
Waujito Автор
31.07.2024 04:59+1RST это прям ярко красные. Я про всякие Out-of-order, Retransmission и им подобные.
"Скорость не бывает просто маленькая" - вообще, бывает. Сразу пришли на ум сервера эклипса. Месяца два назад скачивал jdtls на скорости 20 килобайт/с. Сейчас они их пофиксили чуть-чуть, я получил 1 мегабайт, но всё равно в вайршарке с точки зрения TCP никаких ошибок нет.
Dhowti
Одна поправка - ValdikSS правильно.
Waujito Автор
Ахах, я его года три как Vladik читаю, только что заметил, спасибо!)