The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

В ночных сборках Firefox появилась поддержка HTTP/3

04.11.2019 09:35

В ночные сборки Firefox, которые лягут в основу выпуска Firefox 72, запланированного на 7 января, добавлена поддержка протокола HTTP/3. По умолчанию HTTP/3 отключён и требует активации опции "network.http.http3.enabled" в about:config.

Поддержка HTTP/3 в Firefox основана на развиваемом компанией Mozilla проекте neqo, предоставляющем реализацию клиента и сервера для протокола QUIC. Код компонентов для поддержки HTTP/3 и QUIC написан на языке Rust. Из клиентского ПО экспериментальная поддержка HTTP/3 также уже добавлена в Chrome и curl, а для серверов доступна в форме модуля для nginx и тестового сервера на базе библиотеки quiche (реализация QUIC и HTTP/3 на языке Rust от компании Cloudflare). Для проверки работы клиентов HTTP/3 запущено несколько тестовых сайтов, большая часть из которых пока корректно не открывается в Firefox (HTTP/3 находится на стадии черновой спецификации и окончательно не стандартизирован).

Напомним, что HTTP/3 стандартизирует использование протокола QUIC в качестве транспорта для HTTP/2. Протокол QUIC (Quick UDP Internet Connections) c 2013 года развивается компанией Google в качестве альтернативы связке TCP+TLS для Web, решающей проблемы с большим временем установки и согласования соединений в TCP и устраняющей задержки при потере пакетов в процессе передачи данных. QUIC представляет собой надстройку над протоколом UDP, поддерживающую мультиплексирование нескольких соединений и обеспечивающую методы шифрования, эквивалентные TLS/SSL.

Основные особенности QUIC:

  • Высокая безопасность, аналогичная TLS (по сути QUIC предоставляет возможность использования TLS поверх UDP);
  • Контроль за целостностью потока, предотвращающий потерю пакетов;
  • Возможность мгновенно установить соединение (0-RTT, примерно в 75% случаях данные можно передавать сразу после отправки пакета установки соединения) и обеспечить минимальные задержки между отправкой запроса и получением ответа (RTT, Round Trip Time);
  • Не использование при повторной передаче пакета того же номера последовательности, что позволяет избежать двусмысленности при определении полученных пакетов и избавиться от таймаутов;
  • Потеря пакета влияет на доставку только связанного с ним потока и не останавливает доставку данных в параллельно передаваемых через текущее соединение потоках;
  • Средства коррекции ошибок, минимизирующие задержки из-за повторной передачи потерянных пакетов. Использование специальных кодов коррекции ошибок на уровне пакета для сокращения ситуаций, требующих повторной передачи данных потерянного пакета.
  • Границы криптографических блоков выравнены с границами пакетов QUIC, что уменьшает влияние потерь пакетов на декодирование содержимого следующих пакетов;
  • Отсутствие проблем с блокировкой очереди TCP;
  • Поддержка идентификатора соединения, позволяющего сократить время на установку повторного соединения для мобильных клиентов;
  • Возможность подключения расширенных механизмов контроля перегрузки соединения;
  • Использование техники прогнозирования пропускной способности в каждом направлении для обеспечения оптимальной интенсивности отправки пакетов, предотвращая скатывание в состояние перегрузки, при которой наблюдается потеря пакетов;
  • Заметный прирост производительности и пропускной способности, по сравнению с TCP. Для видеосервисов, таких как YouTube, применение QUIC показало сокращение операций повторной буферизации при просмотре видео на 30%.


  1. Главная ссылка к новости (https://techdows.com/2019/11/m...)
  2. OpenNews: Компания Cloudflare реализовала модуль для поддержки HTTP/3 в NGINX
  3. OpenNews: Новая версия curl 7.66.0 с начальной поддержкой HTTP/3
  4. OpenNews: В Chrome добавлена экспериментальная поддержка протокола HTTP/3
  5. OpenNews: HTTP поверх протокола QUIC будет стандартизирован как HTTP/3
  6. OpenNews: Компания Cloudflare открыла код реализации протокола QUIC на языке Rust
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/51807-http3
Ключевые слова: http3, mozilla, firefox
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (113) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 09:39, 04/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Что-то я ещё вживую второй не видел, а они уже третий пихаютъ...
     
     
  • 2.2, Аноним (2), 09:42, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +12 +/
    Второй сейчас во всех cdn. Реально сокращает трафик и задержки раза в 2.
     
     
  • 3.15, мурзилла (?), 11:44, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    главное, конечно же, верить, и ничего никогда самому не тестировать.

     
     
  • 4.23, Аноним (2), 12:38, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Если это подкол на тему маркетинговых брошурок, то я могу сказать, что реально видел очень значительную разницу. Ну, в консольке, и по результатам работы паучков сравнивал.
     
     
  • 5.35, Аноним (35), 14:20, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Были неоднократно и обратные ситуации когда http2 просили отключить, так верхний контент страницы грузился одновременно с нижним и время до полной отрисовки падало
     
     
  • 6.66, xl32 (ok), 17:44, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Там вообще-то приоритеты есть и ими не запрещают пользоваться. Но если вам, как и в случае с SELinux, проще не разбираться, а просто отключить, это тоже не запрещено. Просто не говорите про ненужность для всех. Только для неосиляторов.
     
     
  • 7.73, Аноним (73), 18:57, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ну так просвети меня как в nginx приоритеты настроить, конфиг что ли скинь.
    Судя по https://github.com/andydavies/http2-prioritization-issues год назад большая часть мира приоритеты не осилила и подозреваю что сейчас картина не лучше.
    От того что приоритеты описаны в стандарте и поддерживаются в единственном(?) веб-сервере, мир лучше не становится и приходится жить с тем что есть.
     
     
  • 8.75, xl32 (ok), 19:15, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Nginx прекрасно поддерживает приоритеты, запрошенные клиентом Конфигов ему ника... текст свёрнут, показать
     
  • 4.47, BlackRot (ok), 15:20, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Выползи из окопа, всё уже давно проверено и подтверждено.
    На всех своих сайтах использую http2, разница заметная даже слепому. Старенький сервер ещё поживёт.
     
     
  • 5.93, j3t (?), 01:45, 05/11/2019 [^] [^^] [^^^] [ответить]  
  • –5 +/
    на всех своих сайтах? лол што? на своем твиттере или гугле? какие у тебя сайты шо узкое место в них имеено в http 1.1? сейчас даже в деревнях уже лет как пять есть 3g, не говоря о покрытие городов, какая разница? сколько 3 или 4 миллисекунды? разница в скорости отрисовки зависит от браузера, если он тормоз страница долго грузит(яркий пример IE 6,7), хоть у тебя 5G и ты стоишь под базовой станцией, какие же вы школьники блджад
     
     
  • 6.101, пох. (?), 12:44, 05/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    вам же сказали - главное - свято верить.

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

    P.S. разница зависит, разумеется, не только от браузера, еще и от необходимости создания двух десятков разных (!) tls сессий с cdn для ресракта, для jquery (альтернативно-одаренный разработчик не уместился в апи ресракта и насопливил отдельно), cdn для шрифтиков (пяти разных), cdn для онлайн-чятика и т п - вполне видна невооруженным глазом, никакой 0rtt в этом случае, разумеется, не работает, поэтому волшебные протоколы панацеей, внезапно, не являются (если ты не гугль).

    С остальными проблемами неплохо справляется протокол http версий старше 0.9

     
     
  • 7.113, j3t (?), 02:58, 08/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Вангую HTTP/4 на базе гипертекстового фидонета, чтобы совсем уж...
     
  • 7.114, j3t (?), 03:13, 08/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    В 99% случаев таки от браузера, точнее от скорости парсинга HTML/CSS(потуги Mozilla запилить многопоточный парсер DOM и CSS), ну и конечно же производительности двигла JavaScript-а(V8 же! для сравнения с spidermonkey), не отломанное аппаратное ускорение после свистоперделок CSS3 и адских высеров в виде Angular/React/Vue.js просто мастхев(хромой со скоростью конкорда летает на винде и так же тормозит под линухом), многопроцессорный режим вообще тормоз по сравнению с потоками(OnlyOffice выполняющийся как -no sandbox летает, VS Code тормозит), блокировщики реклам типа AdBlock и uBlock заставляют браузер подтупливать, ну и тысячи их... причин
     
     
  • 8.120, пох. (?), 11:37, 09/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    дружище, у меня в качестве основного интернето-киоска - atom D2700 и совершенно ... текст свёрнут, показать
     
  • 3.85, хотел спросить (?), 21:16, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    у меня ничего не поменялось с введение HTTP/2, старый добрый bundling никто не отменял

    проверял через network tools время загрузки не меняется (в пределах погрешности)

     
     
  • 4.115, j3t (?), 03:17, 08/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    от сжатия gzip-ом в 100500 раз больше ускорения было, чем от этой бинарщины
     
     
  • 5.121, пох. (?), 11:45, 09/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    вы им что такое сжимаете-то У меня вот от сжатия gzip ом ускорение только на ка... большой текст свёрнут, показать
     
  • 3.90, хотел спросить (?), 22:27, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    я даже больше скажу

    на тестовом сервере под CentOS 7 + nginx

    клиент FF 71 (dev edition)

    1.1 требует 2.9s до полной загрузки сайт, а 2 в среднем 3.2s (уже разгретое приложение, но холодный кеш браузера)

    возможно имеет смысл что backend под nginx на 1.1, ну так и должно быть - это же localhost

     
  • 2.6, Аноним (6), 10:32, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    А это всё равно разные звери. «/3» это обманка.
     
  • 2.7, Аноним (7), 10:33, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Да ладно. Он уже везде.
     
  • 2.17, Ilya Indigo (ok), 11:54, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    На lighttp никогда и не увидите.
    На nginx уже сейчас через клодфлеерский костыль HTTP/3 есть, а в течение года нативно реализуют
     
  • 2.37, Кек (?), 14:30, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    я вообще не понимаю, что за хрень они выдумывают. Не проще заняться оптимизацией кода и сделать браузер человеческим? а не 2ГБ на вкладку? За что им там платят деньги?
     
     
  • 3.72, Аномномномнимус (?), 18:55, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Чисто интереса ради... а сколько ты заплатил?
     
     
  • 4.74, Аноним (73), 18:58, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Если не он лично, то его друзья и родственники слили гуглу столько ценной информации, что на несколько браузеров хватит.
     
     
  • 5.79, Аноним (79), 19:51, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А почему гоголь не делится со всеми с продажи всех данных?!
     
     
  • 6.102, гугель (?), 12:46, 05/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    почему не делимся? Делимся. Вы на халяву пользуетесь нашим ютрупом, нашей почтой, нашим поиском и много чем еще о чем даже не догадываетесь, что они наши.

    Взамен мы получаем - вас, разумеется. Со всеми потрохами. Ну так вам же и не жалко, вы ж уже лет десять живете в домике со стеклянными стенами?

     
  • 2.92, pda (?), 00:35, 05/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Что-то я ещё вживую второй не видел, а они уже третий пихаютъ...

    Мы что, нашли человека ни разу не заходившего в последнее время на google?

    https://www.google.com/
    Host: www.google.com
    <...>
    GET: HTTP/2.0 200 OK
    <...>

     
     
  • 3.103, Аноним (1), 12:55, 05/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >  ни разу не заходившего в последнее время на google?

    Есть такое, предпочитаю ddg.gg

     
     
  • 4.108, Аноним (108), 23:10, 05/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    $ curl -i 'https://ddg.gg'
    HTTP/2 301
    ...
     

  • 1.3, enik (ok), 10:16, 04/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Так они его сами пишут??
     
     
  • 2.5, Аноним (7), 10:26, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    А кто кроме Мозиллы реализацию на расте напишет? Всё правильно сделали.
     
     
  • 3.18, Алекс (??), 11:57, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • –5 +/
    Прям в новости сказано что ещё Клоудфларе
     
     
  • 4.21, Аноним (7), 12:27, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Тогда действительно странно. Фрагментация никому не нужна.
     
     
  • 5.77, Ordu (ok), 19:20, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Это не фрагментация, это множественные реализации протокола. Крайне сложно или даже невозможно отделить тесты протокола от тестов реализации протокола, если у тебя нету нескольких реализаций.
     
  • 4.67, xl32 (ok), 17:46, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Cloudflare модуль интеграции nginx с либой написали, если что.
     
  • 3.19, Весельчак У (?), 12:10, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    У cf своя реализация на растёт так то.
     
  • 2.39, Кек (?), 14:31, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Пишут его индусы за доллар в час
     
     
  • 3.80, Аноним (79), 19:53, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ну это нормально. У них. У нас некоторые бюджетники тоже столько получают. И умудряются жить. На радость государству.
     

  • 1.4, Аноним (7), 10:25, 04/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    >0-RTT

    Это отключается?

     
     
  • 2.20, CloudFlare (?), 12:19, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    DDoSа боишься? Покупай CDN!
     
     
  • 3.58, Аноним (35), 16:55, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Только cdn он не от доса, даже клаудфлар это знает и у него для этого отдельная услуга
     
  • 3.69, SOska (?), 17:57, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Почему я должен что то там покупать
     

  • 1.8, Аноним (8), 10:38, 04/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Хром на моем тестовом сервере работает, но как то через раз может с h3 перейти на h2 при рефреше, но если добавить флаг --origin-to-force-quic-on=domain:443 но всегда будет на h3, но фокс вообще не грузит сайт если включить http3.
     
  • 1.9, Аноним (9), 11:09, 04/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    > ...тестовых сайтов, большая часть из которых ... не открывается в Firefox

    Ясно, понятно. Про что новость?

     
  • 1.10, Sw00p aka Jerom (?), 11:23, 04/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    >0-RTT, примерно в 75% случаях данные можно передавать сразу после отправки пакета установки соединения)

    Это усиленная версия Syn флуда? Теперь и канал можно забивать.

     
     
  • 2.13, мурзилла (?), 11:43, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    это udp флуд. Теперь ты не можешь использовать ни tcp cookies, ни хотя бы отфильтровать китайские сети - все пакеты придут с фейковых адресов твоих реальных посетителей.

    Полагаю, и канал забивать не придется, сайт ляжет от сравнительно небольшого числа этих "0rtt".

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

    А попутно подарить инфу о своих пользователях всем подряд, конечно же.

     
     
  • 3.22, suffix (ok), 12:32, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    У меня не http/3 конечно, но включил в nginx TLS 1.3 0-RTT и TCP Fast Open. Включил в настройках Firefox TCP Fast Open (0-RTT включено по умолчанию). Протестировал в wireshark - реально для повторных соединений на две транзакции меньше !

    Так что плюс от всего этого добра есть, минусов же никаких не вижу.

     
     
  • 4.27, Аноним (2), 13:33, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Да, это всё отлично работает. Но вроде rtt и fast open рекомендуют отключать в целях безопасности. У меня вообще венда и лтс фф в юзерагенте оказывается (в венде fastopen и не было, как сейчас не знаю, но она ворует успешные идеи).

    Security by obscurity всегда хорошо работает, если кто-то захочет использовать информацию во вред, можно его обломать немножко. Чем больше уровней обломов, тем дороже и не выгодней взлом. Тем более, что у фф песочница всегда проблемная была. Её регулярно ломают, у хрома с этим получше.

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

     
     
  • 5.30, suffix (ok), 13:52, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > в венде fastopen и не было, как сейчас
    > не знаю, но она ворует успешные идеи.

    Давно уже в Edge есть - правда было по умолчанию а сейчас включать в настройках надо.

     
  • 4.29, Аноним (29), 13:48, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Еще htcp включи и буфера увеличь, вообще летать будет.
     
     
  • 5.31, suffix (ok), 13:52, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Еще htcp включи и буфера увеличь, вообще летать будет.

    Не смог осилить вашу фразу - извините.

     
     
  • 6.32, Аноним (2), 13:59, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Про буферы, может быть это про то, чем занимался fasterfox? Как там более поздний вариант назывался, fasterfox lite кажется? Всё равно на сервера, главное, чтобы быстро грузилось.
     
  • 6.36, Аноним (36), 14:29, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Через сисцтл/прокфс увеличиваются буфера, рмем вмем ипр, там же выставляется tcp congestion control htcp или hybla вместо дефолтного кубика, перед этим нужно модули в ядро подгрузить. Подробности для копипасты в гугле есть.
     
     
  • 7.41, suffix (ok), 14:38, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > там же выставляется tcp congestion control htcp или hybla

    С пониманием этой части вопросов и не было

    А вот

    >рмем вмем ипр

    Слишком загадочно для меня :)

    Ибо везде пишут что менять там что либо стоит на высокозагруженных проектах только. У меня при максимальной загрузке LA около 0 всегда и free -h свободными 50GB памяти показывает.

    Не вижу смысла теребить эти настройки.

     
     
  • 8.42, Аноним (2), 14:47, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Он про это https wiki archlinux org index php Sysctl Increase_the_memory_dedi... текст свёрнут, показать
     
     
  • 9.43, suffix (ok), 14:50, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Спасибо - это понятно, но в моём случае не понимаю зачем их трогать - выше в пос... текст свёрнут, показать
     
  • 8.45, Аноним (36), 15:06, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это не для того чтобы у тебя проц не жрало а для того чтобы раздавало быстрее ... текст свёрнут, показать
     
     
  • 9.60, suffix (ok), 17:03, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ну добавил net ipv4 tcp_slow_start_after_idle 0 net core rmem_max 16777216 ne... текст свёрнут, показать
     
     
  • 10.63, Аноним (2), 17:26, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Это типа для торрентов нужно, если по utp раздавать Есть ещё всякие net ipv4 tc... текст свёрнут, показать
     
     
  • 11.65, suffix (ok), 17:36, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    fast_open давно уже включил но толку то если в браузерах по умолчанию не включен... текст свёрнут, показать
     
     
  • 12.70, Аноним (2), 18:17, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А такие Но да, это всё скорее интересно под нагрузкой в роли сервера net core ... текст свёрнут, показать
     
  • 10.96, Ivan_83 (ok), 07:27, 05/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не уверен что этого достаточно Убыстрение на глаз - это интересно Обычно есл... текст свёрнут, показать
     
  • 3.33, Аноним (33), 14:06, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > все пакеты придут с фейковых адресов твоих реальных посетителей.

    Эти 0rtt адреса еще заполучить надо, для тысяч сервисов и сайтов. К тому же, полагаю, они будут тут же выброшены из списка 0rtt, если продолжение обмена далее не последует.

     
     
  • 4.53, пох. (?), 16:33, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    зачем? Подделывай сотнями тысяч, это ж udp, твоих затрат ноль. В кого-нибудь да попадешь.
    > К тому же, полагаю, они будут тут же выброшены из списка 0rtt, если продолжение обмена далее
    > не последует.

    это несказанно порадует легитимного пользователя. И ничуть не снизит нагрузку на твой сайт, ибо весь смысл 0rtt в том что никакого "обмена" толком и нет.

     
     
  • 5.76, Аноним (76), 19:18, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > это ж udp, твоих затрат ноль

    Сможешь хотя бы опеннет задудосить?

     
  • 5.83, Аноним (33), 21:10, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > В кого-нибудь да попадешь.

    Вся суть в усилении трафика сервисами. Вероятность попасть околонулевая.

     

  • 1.11, Блокнот.exe (?), 11:27, 04/11/2019 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • –2 +/
     

     ....ответы скрыты (5)

  • 1.24, Аноним (25), 12:52, 04/11/2019 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • –1 +/
     
  • 1.28, Аноним (29), 13:45, 04/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Пропаганда а не техническая публикация. Все это было на швабре на неделе.
    Пока не будет вменяемых тестов, инсирументов отладки (парсеры в тцпдумп и ваиршарке) и нормальных реализаций в виде сишных либ - это все так и будет бесполезным хламом от гугля ради гугля.
     
     
  • 2.38, Аноним (35), 14:30, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Проблема в том что гугль продвинет это во все браузеры раньше чем спецификации установится.
    Если ничего глобального не всплывет, то орды мамкохостеров и маркетологов подхватят этот http3 и вознесут его на свой золотой унитаз.
    Дальше уже тулзам придётся подстраиваться, ведь "сейчас все используют http3".
    В общем в этом никчемном мире все нередко делается наоборот.
     
  • 2.44, h31 (ok), 14:58, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > парсеры в тцпдумп и ваиршарке

    Удачи в парсинге зашифрованного трафика. Да, я в курсе про флаги для отладочного дампа ключей, но это всё очень неудобно и неуниверсально, так что пригождается только в качестве крайней меры.

     
     
  • 3.49, Аноним (36), 16:05, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Пускать не шифрованый или ключ ручками в тулзу сливать.
     
  • 3.57, Аноним (35), 16:52, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ты же своё приложение шифруешь на своей машине и на своей же принимаешь.
    У тебя в любом случае есть ключи для расшифровки вопрос только как их достать удобнее.
     

  • 1.34, Аноним (34), 14:09, 04/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Чем он вообще от http2 отличается окромя 0-RTT?
    В нем же уже есть мультиплексирование вродь, нет блокировок если использовать эти самые потоки, что еще нужно?
     
     
  • 2.40, Аноним (76), 14:32, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Он не от 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.46, Аноним (34), 15:10, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Вот оно что. А 3 он потому что решили не использовать минорные версии, как я полагаю.
     
     
  • 4.56, Аноним (35), 16:50, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Тут пишут https://m.habr.com/ru/company/qrator/blog/416633/?_ga=2.79041872.535499156.157 потому что внутри комитета не смогли договориться как его называть
     
  • 3.95, KonstantinB (ok), 07:21, 05/11/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    О каких костылях TCP речь?

    QUIC (который по сути и есть userspace-реализация TCP) больше похож на костыли (хотя и необходимые в условиях нестабильной мобильной связи).

     
  • 2.54, Аноним (35), 16:34, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Не знаю как сейчас, а раньше было так:
    К ip назначается id, якобы чтобы не (разрывать) создавать новое соединение при смене вафли на lte (не уверен).
    Выполняется в пространстве пользователя (а значит медленнее и энергозатратнее, то же относится и к
    ) (в теории могут исправить, но гугл "не хочет ждать пока обновятся ос")
    Нет защиты от флуда (syn Кук)
    Хуже работает если пакеты приходят не в том порядке (это относительно частая ситуация)
    Закрыт файрволами во многих (корпоративных) сетях

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

     

  • 1.48, mumu (ok), 16:02, 04/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    В каждой новости про HTTP/3 стоит дописывать, что при потере пакетов уже в 2% HTTP/3 становится медленее, чем HTTP/2.
     
     
  • 2.50, Аноним (7), 16:06, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Нафиг он тогда нужен? Его же ради работы при потере пакетов в беспроводных сетях и делали.
     
     
  • 3.55, пох. (?), 16:34, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    не хотел бы тебя расстраивать, но его делал гугль - у которого сети вполне себе проводные, и неограниченной пропускной способности. И решать он собирался свои проблемы, а вовсе не твои.

    Причем - за твой счет.

     
     
  • 4.61, Аноним (7), 17:24, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    у гугла - проводные, а вот у пользователей ютьюба - как раз беспроводные.
     
     
  • 5.68, гугель (?), 17:50, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ты правда думаешь что нас колебут проблемы пользователей?

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

     
     
  • 6.87, Аноним (33), 21:21, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну вот, еще оператора влепили. Проблемы операторов никого не волнуют. Передача трафика - это их прямая работа.
    Повышение нагрузки от UDP в контексте клиентов незначительно. Вы выдумываете проблему на ровном месте.
     
  • 4.86, Аноним (33), 21:16, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > у которого сети вполне себе проводные, и неограниченной пропускной способности

    Что-то не замечал проводного соединения между моим мобильным и гуглом...
    > И решать он собирался свои проблемы, а вовсе не твои.

    Это не так. А даже если и так, одно другому не мешает. Уменьшая частоту повторной буферизации, гугл имеет снижение трафика и нагрузки. А пользователь имеет более качественную услугу.

     
     
  • 5.117, Аноним (117), 00:44, 09/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Откуда вы все лезете? Ещё в прошлой теме прожевали несколько презентаций этого квига с цифрами. И снова как в первый раз про более качественные услуги.
     
  • 2.78, Аноним (78), 19:42, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Принеси пруф.

    Я видел это утверждение в контексте 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.

     
     
  • 3.99, mumu (ok), 08:38, 05/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Действительно так. Я был не прав. Спасибо за исправление!
     
  • 2.84, Аноним (33), 21:13, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Наоборот. HTTP/3 как раз решает эту проблему.
     
     
  • 3.97, Ivan_83 (ok), 07:30, 05/11/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Только вот ЭТУ проблему сами и создали в http/2 - не нужно одно соединение было делать, и сравнивать квик надо не с отстойным 2 а с 1.1 на 5-10 конектах, и более чем уверен что квик тут мало чем сможет похвастатся для сайтов где много картинок, особенно тяжёлых.
     
     
  • 4.118, Аноним (33), 01:35, 09/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Несколько коннектов накладно для сети и сервера, и в принципе является не решением проблемы, а только лишь костылем, позволяющем снизить ее негативное влияние.
     
  • 2.98, mumu (ok), 08:37, 05/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Прошу прощения за неточность. Про потери действительно относилось к HTTP/2 vs 1.1. В голове перемешалось :-(
     

  • 1.51, Аноним (51), 16:13, 04/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    > решающей проблемы с большим временем установки и согласования соединений в TCP и устраняющей задержки при потере пакетов в процессе передачи данных

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

     
     
  • 2.88, Аноним (33), 21:24, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > кажется что причина в чём то другом.

    Правильно кажется. Но это не достаточный повод прочитать статью целиком, верно?

     
  • 2.91, Аноним (91), 00:30, 05/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Это чтобы куки встроить. Достаточно послать кривой пакет, чтобы получить данные. TCP даже не ответит, а тут - вот то самое вчерашнее наконец-то. И не отключишь как пинги. Чтобы сократить на 30% повторы трафика достаточно не удалять данные во время просмотра и отдавать в буфер на 30% меньше данных, а не создавать целый новый протокол поверх протокола.
     

  • 1.52, Аноним (51), 16:25, 04/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Поддержку прокси они планируют? SOCKS5?
     
     
  • 2.62, Аноним (7), 17:26, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    нет. А вот поддержка ipv6 как раз будет. Каждому устройству по персональному адресу для отслеживания.
     

  • 1.59, Аноним (59), 16:56, 04/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Через пять лет:

    "В CloudFlare Firefox 735 появилась поддержка GoogleHTTP/27."

     
     
  • 2.64, Аноним (7), 17:27, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    firefox не протянет эти 5 лет, если мозилла не перестанет дурью маяться.
     
     
  • 3.81, Аноним (79), 19:59, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Если она уже ступила на этот путь, и сделала по нему немало шагов, улучшений ждать не приходится. Былую функциональность уже не вернуть. Эра тинейджеров-домохозяек уже здесь.
     

  • 1.71, Аноним (71), 18:21, 04/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Это снизит время отклика в облачных играх?
     
     
  • 2.89, Аноним (33), 21:28, 04/11/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Зависит от того, какой протокол используется. Логично предположить, что было бы глупо использовать HTTP там, где критичны задержки.
     

  • 1.82, Какаянахренразница (ok), 20:26, 04/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    В nginx когда завезут?
     
     
  • 2.100, xl32 (ok), 11:17, 05/11/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > В nginx когда завезут?

    Официально — обещают в течение 6-12 месяцев.
    Неофициально — Cloudflare уже модуль и патчи сделали для линковки с либой на расте.

     

  • 1.106, Аноним (79), 16:48, 05/11/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Хм... неужели сейчас мазила так хороша, что приходиться выбирать ее из всех известных браузеров (под Винду, имеется в виду)?!
    Или здесь уже вступает другое правило - она наименее дерьмовая из всего остального шлака, что сейчас есть?
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру