В ночные сборки Firefox, которые лягут в основу выпуска Firefox 72, запланированного на 7 января, добавлена поддержка протокола HTTP/3. По умолчанию HTTP/3 отключён и требует активации опции "network.http.http3.enabled" в about:config...Подробнее: https://www.opennet.me/opennews/art.shtml?num=51807
Что-то я ещё вживую второй не видел, а они уже третий пихаютъ...
Второй сейчас во всех cdn. Реально сокращает трафик и задержки раза в 2.
главное, конечно же, верить, и ничего никогда самому не тестировать.
Если это подкол на тему маркетинговых брошурок, то я могу сказать, что реально видел очень значительную разницу. Ну, в консольке, и по результатам работы паучков сравнивал.
Были неоднократно и обратные ситуации когда http2 просили отключить, так верхний контент страницы грузился одновременно с нижним и время до полной отрисовки падало
Там вообще-то приоритеты есть и ими не запрещают пользоваться. Но если вам, как и в случае с SELinux, проще не разбираться, а просто отключить, это тоже не запрещено. Просто не говорите про ненужность для всех. Только для неосиляторов.
Ну так просвети меня как в nginx приоритеты настроить, конфиг что ли скинь.
Судя по https://github.com/andydavies/http2-prioritization-issues год назад большая часть мира приоритеты не осилила и подозреваю что сейчас картина не лучше.
От того что приоритеты описаны в стандарте и поддерживаются в единственном(?) веб-сервере, мир лучше не становится и приходится жить с тем что есть.
> Ну так просвети меня как в nginx приоритеты настроить, конфиг что ли
> скинь.
> Судя по https://github.com/andydavies/http2-prioritization-issues год назад большая
> часть мира приоритеты не осилила и подозреваю что сейчас картина не
> лучше.
> От того что приоритеты описаны в стандарте и поддерживаются в единственном(?) веб-сервере,
> мир лучше не становится и приходится жить с тем что есть.Nginx прекрасно поддерживает приоритеты, запрошенные клиентом. Конфигов ему никаких не надо.
Выползи из окопа, всё уже давно проверено и подтверждено.
На всех своих сайтах использую http2, разница заметная даже слепому. Старенький сервер ещё поживёт.
на всех своих сайтах? лол што? на своем твиттере или гугле? какие у тебя сайты шо узкое место в них имеено в http 1.1? сейчас даже в деревнях уже лет как пять есть 3g, не говоря о покрытие городов, какая разница? сколько 3 или 4 миллисекунды? разница в скорости отрисовки зависит от браузера, если он тормоз страница долго грузит(яркий пример IE 6,7), хоть у тебя 5G и ты стоишь под базовой станцией, какие же вы школьники блджад
вам же сказали - главное - свято верить.Гугель швятой, любая его поделка - совершенна, два лишних соединения единственного за день посетителя с васян-сайтом можно заметить без наносекундных измеризмов.
P.S. разница зависит, разумеется, не только от браузера, еще и от необходимости создания двух десятков разных (!) tls сессий с cdn для ресракта, для jquery (альтернативно-одаренный разработчик не уместился в апи ресракта и насопливил отдельно), cdn для шрифтиков (пяти разных), cdn для онлайн-чятика и т п - вполне видна невооруженным глазом, никакой 0rtt в этом случае, разумеется, не работает, поэтому волшебные протоколы панацеей, внезапно, не являются (если ты не гугль).
С остальными проблемами неплохо справляется протокол http версий старше 0.9
Вангую HTTP/4 на базе гипертекстового фидонета, чтобы совсем уж...
В 99% случаев таки от браузера, точнее от скорости парсинга HTML/CSS(потуги Mozilla запилить многопоточный парсер DOM и CSS), ну и конечно же производительности двигла JavaScript-а(V8 же! для сравнения с spidermonkey), не отломанное аппаратное ускорение после свистоперделок CSS3 и адских высеров в виде Angular/React/Vue.js просто мастхев(хромой со скоростью конкорда летает на винде и так же тормозит под линухом), многопроцессорный режим вообще тормоз по сравнению с потоками(OnlyOffice выполняющийся как -no sandbox летает, VS Code тормозит), блокировщики реклам типа AdBlock и uBlock заставляют браузер подтупливать, ну и тысячи их... причин
> В 99% случаев таки от браузера, точнее от скорости парсинга HTML/CSSдружище, у меня в качестве основного интернето-киоска - atom D2700 и совершенно немодный-нехрустящий браузер, ему вполне соответствующий по архитектуре.
Поверь, я отличу просто парсинг html от коннектов к cdn.Кстати, не забудь еще что вся эта красота ресолвится, а dns у нас тоже не мгновенный.
После того как соединения построены и сессии установлены - значительное время тупит только js. Даже css transforms на фоне установки сессий почти незаметны.
ublock при этом никаких визуально видимых тормозов не привносит, если не увлекаться развесистыми правилами. Если там и добавляется лагов, они полностью компенсируются НЕ созданием пары десяков коннектов к ненужно-трекерам и ненужно-cdn'ам.
у меня ничего не поменялось с введение HTTP/2, старый добрый bundling никто не отменялпроверял через network tools время загрузки не меняется (в пределах погрешности)
от сжатия gzip-ом в 100500 раз больше ускорения было, чем от этой бинарщины
> от сжатия gzip-ом в 100500 раз больше ускорения было, чем от этой
> бинарщинывы им что такое сжимаете-то? У меня вот от сжатия gzip'ом ускорение только на каналах с безобразными потерями (по понятным причинам - если сессия после 3way handshake укладывается в один пакет - шансы его потери минимальны, а если сам хэндшейк не пройдет - он быстро переустановится, без ожидания длинных таймаутов уже открытой сессии, хотя разницу между 1 и 2 пакетами без потерь - ты и на 2мегабит канале ни с каким секундомером не засечешь), но зачем так жить?
Потому что картинки и видосики, к сожалению, несжимаемы. А теперь откройте какой-нибудь гитхап, и посмотрите network monitor, ужаснитесь. Там сжимаемого траффика хорошо если 1% от всего того шлака.
Реальное ускорение дает разьве что принудительный expire куда-нибудь на двадцать лет вперед.
С понятными последствиями, если что-то пошло не так.
я даже больше скажуна тестовом сервере под CentOS 7 + nginx
клиент FF 71 (dev edition)
1.1 требует 2.9s до полной загрузки сайт, а 2 в среднем 3.2s (уже разгретое приложение, но холодный кеш браузера)
возможно имеет смысл что backend под nginx на 1.1, ну так и должно быть - это же localhost
А это всё равно разные звери. «/3» это обманка.
Да ладно. Он уже везде.
На lighttp никогда и не увидите.
На nginx уже сейчас через клодфлеерский костыль HTTP/3 есть, а в течение года нативно реализуют
я вообще не понимаю, что за хрень они выдумывают. Не проще заняться оптимизацией кода и сделать браузер человеческим? а не 2ГБ на вкладку? За что им там платят деньги?
Чисто интереса ради... а сколько ты заплатил?
Если не он лично, то его друзья и родственники слили гуглу столько ценной информации, что на несколько браузеров хватит.
А почему гоголь не делится со всеми с продажи всех данных?!
почему не делимся? Делимся. Вы на халяву пользуетесь нашим ютрупом, нашей почтой, нашим поиском и много чем еще о чем даже не догадываетесь, что они наши.Взамен мы получаем - вас, разумеется. Со всеми потрохами. Ну так вам же и не жалко, вы ж уже лет десять живете в домике со стеклянными стенами?
> Что-то я ещё вживую второй не видел, а они уже третий пихаютъ...Мы что, нашли человека ни разу не заходившего в последнее время на google?
https://www.google.com/
Host: www.google.com
<...>
GET: HTTP/2.0 200 OK
<...>
> ни разу не заходившего в последнее время на google?Есть такое, предпочитаю ddg.gg
$ curl -i 'https://ddg.gg'
HTTP/2 301
...
Так они его сами пишут??
А кто кроме Мозиллы реализацию на расте напишет? Всё правильно сделали.
Прям в новости сказано что ещё Клоудфларе
Тогда действительно странно. Фрагментация никому не нужна.
Это не фрагментация, это множественные реализации протокола. Крайне сложно или даже невозможно отделить тесты протокола от тестов реализации протокола, если у тебя нету нескольких реализаций.
Cloudflare модуль интеграции nginx с либой написали, если что.
У cf своя реализация на растёт так то.
Пишут его индусы за доллар в час
Ну это нормально. У них. У нас некоторые бюджетники тоже столько получают. И умудряются жить. На радость государству.
>0-RTTЭто отключается?
DDoSа боишься? Покупай CDN!
Только cdn он не от доса, даже клаудфлар это знает и у него для этого отдельная услуга
Почему я должен что то там покупать
Хром на моем тестовом сервере работает, но как то через раз может с h3 перейти на h2 при рефреше, но если добавить флаг --origin-to-force-quic-on=domain:443 но всегда будет на h3, но фокс вообще не грузит сайт если включить http3.
> ...тестовых сайтов, большая часть из которых ... не открывается в FirefoxЯсно, понятно. Про что новость?
>0-RTT, примерно в 75% случаях данные можно передавать сразу после отправки пакета установки соединения)Это усиленная версия Syn флуда? Теперь и канал можно забивать.
это udp флуд. Теперь ты не можешь использовать ни tcp cookies, ни хотя бы отфильтровать китайские сети - все пакеты придут с фейковых адресов твоих реальных посетителей.Полагаю, и канал забивать не придется, сайт ляжет от сравнительно небольшого числа этих "0rtt".
Ну, гуглю ведь пофиг на твои страдания. А нормальный http-протокол скоро запретят. Ишь чего выдумали, каждый васян может поднять свой веб-сервер! Веб -серверы должны быть только у достойных людей, способных заплатить за ненужные ресурсы и ненужные сервисы типа клаудфлери.
А попутно подарить инфу о своих пользователях всем подряд, конечно же.
У меня не http/3 конечно, но включил в nginx TLS 1.3 0-RTT и TCP Fast Open. Включил в настройках Firefox TCP Fast Open (0-RTT включено по умолчанию). Протестировал в wireshark - реально для повторных соединений на две транзакции меньше !Так что плюс от всего этого добра есть, минусов же никаких не вижу.
Да, это всё отлично работает. Но вроде rtt и fast open рекомендуют отключать в целях безопасности. У меня вообще венда и лтс фф в юзерагенте оказывается (в венде fastopen и не было, как сейчас не знаю, но она ворует успешные идеи).Security by obscurity всегда хорошо работает, если кто-то захочет использовать информацию во вред, можно его обломать немножко. Чем больше уровней обломов, тем дороже и не выгодней взлом. Тем более, что у фф песочница всегда проблемная была. Её регулярно ломают, у хрома с этим получше.
А для сервера это видимо возможность лечь под небольшой нагрузкой. Кажется я ложил случайно некторые, но это не точно. Приходилось себя ограничивать, чтобы не создавать проблем.
> в венде fastopen и не было, как сейчас
> не знаю, но она ворует успешные идеи.Давно уже в Edge есть - правда было по умолчанию а сейчас включать в настройках надо.
Еще htcp включи и буфера увеличь, вообще летать будет.
> Еще htcp включи и буфера увеличь, вообще летать будет.Не смог осилить вашу фразу - извините.
Про буферы, может быть это про то, чем занимался fasterfox? Как там более поздний вариант назывался, fasterfox lite кажется? Всё равно на сервера, главное, чтобы быстро грузилось.
Через сисцтл/прокфс увеличиваются буфера, рмем вмем ипр, там же выставляется tcp congestion control htcp или hybla вместо дефолтного кубика, перед этим нужно модули в ядро подгрузить. Подробности для копипасты в гугле есть.
> там же выставляется tcp congestion control htcp или hyblaС пониманием этой части вопросов и не было
А вот
>рмем вмем ипр
Слишком загадочно для меня :)
Ибо везде пишут что менять там что либо стоит на высокозагруженных проектах только. У меня при максимальной загрузке LA около 0 всегда и free -h свободными 50GB памяти показывает.
Не вижу смысла теребить эти настройки.
Он про это. https://wiki.archlinux.org/index.php/Sysctl#Increase_the_mem...
> Он про это. https://wiki.archlinux.org/index.php/Sysctl#Increase_the_mem...Спасибо - это понятно, но в моём случае не понимаю зачем их трогать - выше в посте описал ситуацию свою.
Это не для того чтобы у тебя проц не жрало а для того чтобы раздавало быстрее.
Ну добавил:net.ipv4.tcp_slow_start_after_idle=0
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216И выполнил sysctl -p: не увидел "убыстрения" на глаз :)
Это типа для торрентов нужно, если по utp раздавать.Есть ещё всякие
net.ipv4.tcp_fastopen = 3
#net.ipv4.tcp_max_syn_backlog = 30000
#net.ipv4.tcp_max_tw_buckets = 2000000
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 10
#net.ipv4.tcp_slow_start_after_idle = 0
net.ipv4.tcp_keepalive_time = 60
net.ipv4.tcp_keepalive_intvl = 10
net.ipv4.tcp_keepalive_probes = 6
net.ipv4.tcp_mtu_probing = 1
fast_open давно уже включил но толку то если в браузерах по умолчанию не включено.А остальное это больше к борьбе с ddos или к работе под большой нагрузкой а не убыстрению.
А такие? Но да, это всё скорее интересно под нагрузкой в роли сервера.net.core.rmem_default = 1048576
net.core.rmem_max = 16777216
net.core.wmem_default = 1048576
net.core.wmem_max = 16777216
net.core.optmem_max = 65536
net.ipv4.tcp_rmem = 4096 1048576 2097152
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.udp_rmem_min = 8192
net.ipv4.udp_wmem_min = 8192Это немножко поднятые дефолты, для многогигабитных сетей наверно ещё твикать придётся.
Не уверен что этого достаточно.
Убыстрение на глаз - это интересно :)
Обычно если на сервере поднят какой то тестер типа ноды спидтеста то такие тюнинги сразу становится видно по результатам, даже в локалке.
На мелких файлах оно не успевает разогнатся, а вот на больших заметно.
> все пакеты придут с фейковых адресов твоих реальных посетителей.Эти 0rtt адреса еще заполучить надо, для тысяч сервисов и сайтов. К тому же, полагаю, они будут тут же выброшены из списка 0rtt, если продолжение обмена далее не последует.
зачем? Подделывай сотнями тысяч, это ж udp, твоих затрат ноль. В кого-нибудь да попадешь.
> К тому же, полагаю, они будут тут же выброшены из списка 0rtt, если продолжение обмена далее
> не последует.это несказанно порадует легитимного пользователя. И ничуть не снизит нагрузку на твой сайт, ибо весь смысл 0rtt в том что никакого "обмена" толком и нет.
> это ж udp, твоих затрат нольСможешь хотя бы опеннет задудосить?
> В кого-нибудь да попадешь.Вся суть в усилении трафика сервисами. Вероятность попасть околонулевая.
> Добавили поддержку HTTPа вот когда добавят поддержку пользователей, разработчиков дополнений, и систем с <16 гигабайт оперативки?
что значит - "добавят"? Мы еще не закончили удалять этот ненужный устаревший хлам!
Не забудьте удалить блокировку рекламы!
то есть как это удалить? Мы, наоборот, блокируем "неприемлемую" рекламу - и еще половину интернета по усмотрению своей левой пятки, спискам каких-то васянов, которые вы не можете отключить или отредактировать, и ИИ, основанном на телеметрии. Все для вашей безопастносте и спокойствия.Вон, смотрите как мигает и переливается всякий мусор в(место) адресной строке! Это мы заботимся о вас!
А с этими вашими ублоками - ну что-нибудь придумаем. Не все сразу, должны же все немножко позабыть историю с xul.
Я до сих пор удивляюсь как можно пользователям давать пользоваться больше чем одной кнопкой мышь. Одной кнопки им должно хватить за глаза.
Зачем им мышь? Достаточно показывать им контекстную рекламу (с перерывом на игры и телевизор), а ИИ (в вебкамере) сам будет (по выражению лица) заказывать товары с интернет - магазина в кредит под залог квартиры
В HTTP/3 можно вставлять на лету только рекламу от Гугл?
Пропаганда а не техническая публикация. Все это было на швабре на неделе.
Пока не будет вменяемых тестов, инсирументов отладки (парсеры в тцпдумп и ваиршарке) и нормальных реализаций в виде сишных либ - это все так и будет бесполезным хламом от гугля ради гугля.
Проблема в том что гугль продвинет это во все браузеры раньше чем спецификации установится.
Если ничего глобального не всплывет, то орды мамкохостеров и маркетологов подхватят этот http3 и вознесут его на свой золотой унитаз.
Дальше уже тулзам придётся подстраиваться, ведь "сейчас все используют http3".
В общем в этом никчемном мире все нередко делается наоборот.
> парсеры в тцпдумп и ваиршаркеУдачи в парсинге зашифрованного трафика. Да, я в курсе про флаги для отладочного дампа ключей, но это всё очень неудобно и неуниверсально, так что пригождается только в качестве крайней меры.
Пускать не шифрованый или ключ ручками в тулзу сливать.
Ты же своё приложение шифруешь на своей машине и на своей же принимаешь.
У тебя в любом случае есть ключи для расшифровки вопрос только как их достать удобнее.
Чем он вообще от http2 отличается окромя 0-RTT?
В нем же уже есть мультиплексирование вродь, нет блокировок если использовать эти самые потоки, что еще нужно?
Он не от http/2 отличается, а от http/2 over TCP. Потому что это http/2 over QUIC (UDP).
https://blog.cloudflare.com/the-road-to-quic/
https://http3-explained.haxx.se/en/
Нужно им отказаться от проблем и костылей TCP.
Вот оно что. А 3 он потому что решили не использовать минорные версии, как я полагаю.
Тут пишут https://m.habr.com/ru/company/qrator/blog/416633/?_ga=2.7904... потому что внутри комитета не смогли договориться как его называть
О каких костылях TCP речь?QUIC (который по сути и есть userspace-реализация TCP) больше похож на костыли (хотя и необходимые в условиях нестабильной мобильной связи).
Не знаю как сейчас, а раньше было так:
К ip назначается id, якобы чтобы не (разрывать) создавать новое соединение при смене вафли на lte (не уверен).
Выполняется в пространстве пользователя (а значит медленнее и энергозатратнее, то же относится и к
) (в теории могут исправить, но гугл "не хочет ждать пока обновятся ос")
Нет защиты от флуда (syn Кук)
Хуже работает если пакеты приходят не в том порядке (это относительно частая ситуация)
Закрыт файрволами во многих (корпоративных) сетяхВ общем это как и http2 протокол от гугла и для специфичных гуглу юзкейсов, но и в них есть гигантские проблемы. Если внедрят чую будет очень много боли.
В каждой новости про HTTP/3 стоит дописывать, что при потере пакетов уже в 2% HTTP/3 становится медленее, чем HTTP/2.
Нафиг он тогда нужен? Его же ради работы при потере пакетов в беспроводных сетях и делали.
не хотел бы тебя расстраивать, но его делал гугль - у которого сети вполне себе проводные, и неограниченной пропускной способности. И решать он собирался свои проблемы, а вовсе не твои.Причем - за твой счет.
у гугла - проводные, а вот у пользователей ютьюба - как раз беспроводные.
ты правда думаешь что нас колебут проблемы пользователей?Нас колебет чтобы снизить нагрузку на наши серверы. А что от этого у них начнет глючить и лагать все что тянется параллельно ютубу, вырастет в разы нагрузка на инфраструктуру оператора и так далее - нам совершенно, вопиюще похрен.
Ну вот, еще оператора влепили. Проблемы операторов никого не волнуют. Передача трафика - это их прямая работа.
Повышение нагрузки от UDP в контексте клиентов незначительно. Вы выдумываете проблему на ровном месте.
> у которого сети вполне себе проводные, и неограниченной пропускной способностиЧто-то не замечал проводного соединения между моим мобильным и гуглом...
> И решать он собирался свои проблемы, а вовсе не твои.Это не так. А даже если и так, одно другому не мешает. Уменьшая частоту повторной буферизации, гугл имеет снижение трафика и нагрузки. А пользователь имеет более качественную услугу.
Откуда вы все лезете? Ещё в прошлой теме прожевали несколько презентаций этого квига с цифрами. И снова как в первый раз про более качественные услуги.
Принеси пруф.Я видел это утверждение в контексте HTTP/2 применительно к HTTP/1.1 – но не к HTTP/3
https://http3-explained.haxx.se/en/why-tcphol.html
> It becomes a TCP-based head of line block!
> As the packet loss rate increases, HTTP/2 performs less and less well. At 2% packet loss (which is a terrible network quality, mind you), tests have proven that HTTP/1 users are usually better off - because they typically have up to six TCP connections to distribute lost packets over. This means for every lost packet the other connections can still continue.
> Fixing this issue is not easy, if at all possible, with TCP.
Действительно так. Я был не прав. Спасибо за исправление!
Наоборот. HTTP/3 как раз решает эту проблему.
Только вот ЭТУ проблему сами и создали в http/2 - не нужно одно соединение было делать, и сравнивать квик надо не с отстойным 2 а с 1.1 на 5-10 конектах, и более чем уверен что квик тут мало чем сможет похвастатся для сайтов где много картинок, особенно тяжёлых.
Несколько коннектов накладно для сети и сервера, и в принципе является не решением проблемы, а только лишь костылем, позволяющем снизить ее негативное влияние.
Прошу прощения за неточность. Про потери действительно относилось к HTTP/2 vs 1.1. В голове перемешалось :-(
> решающей проблемы с большим временем установки и согласования соединений в TCP и устраняющей задержки при потере пакетов в процессе передачи данныхСлабо верится что это действительно такая проблема что бы городить всё это, кажется что причина в чём то другом.
> кажется что причина в чём то другом.Правильно кажется. Но это не достаточный повод прочитать статью целиком, верно?
Это чтобы куки встроить. Достаточно послать кривой пакет, чтобы получить данные. TCP даже не ответит, а тут - вот то самое вчерашнее наконец-то. И не отключишь как пинги. Чтобы сократить на 30% повторы трафика достаточно не удалять данные во время просмотра и отдавать в буфер на 30% меньше данных, а не создавать целый новый протокол поверх протокола.
Поддержку прокси они планируют? SOCKS5?
нет. А вот поддержка ipv6 как раз будет. Каждому устройству по персональному адресу для отслеживания.
Через пять лет:"В CloudFlare Firefox 735 появилась поддержка GoogleHTTP/27."
firefox не протянет эти 5 лет, если мозилла не перестанет дурью маяться.
Если она уже ступила на этот путь, и сделала по нему немало шагов, улучшений ждать не приходится. Былую функциональность уже не вернуть. Эра тинейджеров-домохозяек уже здесь.
Это снизит время отклика в облачных играх?
Зависит от того, какой протокол используется. Логично предположить, что было бы глупо использовать HTTP там, где критичны задержки.
В nginx когда завезут?
> В nginx когда завезут?Официально — обещают в течение 6-12 месяцев.
Неофициально — Cloudflare уже модуль и патчи сделали для линковки с либой на расте.
Хм... неужели сейчас мазила так хороша, что приходиться выбирать ее из всех известных браузеров (под Винду, имеется в виду)?!
Или здесь уже вступает другое правило - она наименее дерьмовая из всего остального шлака, что сейчас есть?