29.11.2021

В ночных и бета сборках Firefox включена по умолчанию поддержка HTTP/3


  • 1.1, timur.davletshin (ok), 08:42, 21/03/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А про недостатки почему не пишут? Тот же congestion control теперь не от ядерной реализации какого-нибудь cubic, reno зависит, а от криворукости хромоделов. Была же уже драма когда-то с внедрением первой реализации uTP в торрентах и повсеместными «укладываниями» пропускной способности.

    Сообразительные по части сетевых протоколов ещё парочку накидают.

     
     
  • 2.5, Аноним (5), 08:51, 21/03/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Странный вы народ: в срачах про микроядро vs монолит вы вовсю кричите что надо все в юзерспейс. А сейчас (и ещё помню новость про FUSE) уже ярые противники этого подхода.
     
     
  • 3.9, timur.davletshin (ok), 09:00, 21/03/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > Странный вы народ: в срачах про микроядро vs монолит вы вовсю кричите

    > что надо все в юзерспейс. А сейчас (и ещё помню новость

    > про FUSE) уже ярые противники этого подхода.

    Для начала, я никогда не кричал такого. Есть просто имеющийся сетевой стек и в нём управление потоком для TCP в ядре, а UDP по дизайну не гарантирует доставку, поэтому там управление потоком и его целостностью должно быть выше. Дело даже не в том, что ядерные алгоритмы оттестированы и не страдают склонностью к вендорлоку, а в том, что процесс, управляющий потоком, работать будет с пользовательским приоритетом, что недопустимо для realtime задачи управления потоком. В загруженных условиях пользовательская реализация будет страдать от той же проблемы, на которую наступил когда-то pulseaudio. Сколько тут было орущих про «икание» звука после перехода на pulseaudio (сама идея вообще хороша)? Так вот, это банально из-за невозможности управления realtime задачей из пользовательского пространства в условиях высокой загрузки.

    Скрытый же мотив гугла в том, чтобы вынести по максимуму всё в зависящий только от cебя блоб. Даже то же обоснование о том, что мультиплексированный в HTTP/2 поток дропает всё в случае потери пакета, и повышенная пропускная способность UDP на беспроводных, нивелируется тем, что тот же оверхед, необходимый для контроля целостности потока, реализуется уже внутри самого QUIC. И он не меньше, а в реальности даже больше, чем у TCP vs UDP.

     
  • 2.6, Аноним (6), 08:55, 21/03/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Ну во-первых в мобильный браузер не залезть в about:config, а в новости про них почему-то тоже сказано. То естть включить никак, выключить никак. В гугле 1% разница в нагрузке от этой гугловской версии удп протокола.
     
     
  • 3.10, timur.davletshin (ok), 09:01, 21/03/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Ну во-первых в мобильный браузер не залезть в about:config, а в новости

    > про них почему-то тоже сказано. То естть включить никак, выключить никак.

    > В гугле 1% разница в нагрузке от этой гугловской версии удп

    > протокола.

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

     
  • 3.16, Аноним (16), 09:21, 21/03/2021 [^] [^^] [^^^] [ответить]  
  • +/
    И в Chrome (chrome://flags), и в Firefox (about:config) можно зайти в дополнительные настройки на Android.
     

  • 1.4, timur.davletshin (ok), 08:49, 21/03/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Заметный прирост производительности тоже пока под вопросом. На багзилле баг висит, в котором жалуются как-раз на затупы того же Google после включения.

    Но, зато, по Wi-Fi производительность действительно может вырасти. По TCP вафля в среднем из-за большого оверхеда в структуре фрейма (2346 на 1500 ethernet фрейм) и на служебных сообщениях даёт от 30 до 38% заявляемой (например около 2.2 мегабайт на 54 мегабитах), а вот по UDP около 45%.
     
     
  • 2.7, Аноним (6), 08:57, 21/03/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Его на деле нет. Просто вафля может иметь пинг 50+ даже при идеальной связи в AC. И там не важно сколько чего куда. Там только квадратичная модуляция снижает накладные расходы на передачу данных. Это все лапша для легковерных.
     
     
  • 3.17, timur.davletshin (ok), 09:31, 21/03/2021 [^] [^^] [^^^] [ответить]  
  • +/
    > Его на деле нет. Просто вафля может иметь пинг 50+ даже при

    > идеальной связи в AC. И там не важно сколько чего куда.

    > Там только квадратичная модуляция снижает накладные расходы на передачу данных. Это

    > все лапша для легковерных.

    Заходим на роутер и делаем iw dev wlan0 station dump и срём кирпичами от tx retries )))

     

  • 1.11, Аноним (11), 09:04, 21/03/2021 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Пускай пилят хоть на чем, главное чтобы был и был повсеместно. У этого протокола хорошая перспектива для маскировки VPN. То, что сейчас есть сильно тормозит — meek, например (да, это tor, но кому надо — приспособили).
     
     
  • 2.13, timur.davletshin (ok), 09:06, 21/03/2021 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Пускай пилят хоть на чем, главное чтобы был и был повсеместно. У

    > этого протокола хорошая перспектива для маскировки VPN. То, что сейчас есть

    > сильно тормозит — meek, например (да, это tor, но кому надо

    > — приспособили).

    Простите, чем он лучше для маскировки VPN’а? Да-да, я не про инкаспуляцию TCP в TCP, а именно про маскировку.

     
     
  • 3.14, Аноним (11), 09:13, 21/03/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Трафик неотличим от HTTP.

    К тому же сейчас с обычным TLS можно пописать в SNI какой-нибудь ненужный dropbox, facebook, или на что там ваш мобильный оператор безлимитку дает — и качайте себе весь интернет нахаляву.

    Как с этим в HTTP/3 не знаю, для меня это уже неактуально.
     

    Источник.