The OpenNET Project / Index page

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

В Chrome добавлена экспериментальная поддержка протокола HTTP/3

20.09.2019 20:55

В экспериментальные сборки Chrome Canary добавлена поддержка протокола HTTP/3, реализующего надстройку для обеспечения работы HTTP поверх протокола QUIC. Непосредственно протокол QUIC был добавлен в браузер пять лет назад и с тех пор используется для оптимизации работы с сервисами Google. При этом применявшийся в Chrome вариант QUIC от Google в некоторых деталях отличался от варианта из спецификаций IETF, но теперь реализации синхронизированы.

HTTP/3 стандартизирует использование QUIC в качестве транспорта для HTTP/2. Для включения HTTP/3 и варианта QUIC из 23 черновика спецификаций IETF требуется запуск Chrome с опциями "--enable-quic --quic-version=h3-23", после чего при открытии тестового сайта quic.rocks:4433 в режиме инспектирования сети в инструментах для разработчиков активность по HTTP/3 будет отображаться как "http/2+quic/99".

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

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

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

Дополнение: Начальная поддержка QUIC и HTTP/3 также недавно была предложена в выпуске утилиты curl 7.66.0.

  1. Главная ссылка к новости (https://techdows.com/2019/09/g...)
  2. OpenNews: В состав Chrome включена поддержка блокировки сторонних Cookie в режиме инкогнито
  3. OpenNews: Компания Google представила основанный на UDP экспериментальный протокол QUIC для ускорения Web
  4. OpenNews: Google намерен использовать сетевой протокол QUIC в браузере Chrome по умолчанию
  5. OpenNews: Компания Cloudflare открыла код реализации протокола QUIC на языке Rust
  6. OpenNews: HTTP поверх протокола QUIC будет стандартизирован как HTTP/3
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/51526-chrome
Ключевые слова: chrome, quic, http3
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (104) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 21:03, 20/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    «Отсутствие проблем с блокировкой очереди TCP» — то есть если клиент не успевает обрабатывать данные с сервера, то это проблемы клиента? Или что?
     
     
  • 2.26, traktorist (?), 00:47, 21/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    HOL
     
  • 2.27, Аноним (-), 00:50, 21/09/2019 [^] [^^] [^^^] [ответить]  
  • +9 +/
    Я правильно понимаю - если я сервисами гугла не пользуюсь, то нaxpeн мне не нужОн этот ваш хттп3?
     
     
  • 3.67, Аноним (67), 14:03, 21/09/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    На данный момент да. Более того, очевидные преимущества протокол дает только при нестабильном канале. Это либо мобильный интернет, либо связь на большие расстояния через большое количество узлов.
     
  • 2.43, zanswer CCNA RS and S (?), 09:01, 21/09/2019 [^] [^^] [^^^] [ответить]  
  • +8 +/
    Не совсем так, в рамках одной TCP сессии могут передаваться данные разных потоков, для примера представьте, что данные первого потока передавались в сегментах 1 и 2,  а данные второго потока в сегментах 3 и 4. Сервер направил четыре эти сегмента последовательно, но клиент получил только сегменты 1, 3 и 4. Теперь, пока не будет получен сегмент 2, обработка сегментов 3 и 4 будет не возможна, значит второй поток будет заблокирован, пока не будет обработан первый. Это и имеется ввиду в данном случае, с точки зрения TCP это единственно верное решение, поскольку не каких механизмов для разделения сегментом внутри одной TCP сессии нет. Есть SCTP в котором реализован механизм идентификации потоков внутри одного соединения, что избавляет от описанной выше проблемы, но Google решил создать QUIC.
     

  • 1.2, Аноним (2), 21:08, 20/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > Заметный прирост производительности и пропускной способности, по сравнению с TCP.

    Только вот в ядре Linux у UDP diagram до сих пор высокий cpu-cost. Серверам нехило так поплохеет.

     
     
  • 2.4, Аноним (2), 21:09, 20/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    *datagram
    простите за опечатку
     
  • 2.5, Десятерной (?), 21:18, 20/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Это только в пахомии сервера работают для серверов. Во всем остальном мире сервера работают для людей, т.е. клиентов сервиса. Так что если клиентам похорошеет чуть более чем поплохеет серверам - это стоит того.
     
     
  • 3.9, пох. (?), 21:49, 20/09/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    во всем мире - может и работают. Только вот в гугле "клиентом сервиса" является NSA и прочие интересные ребята. А вы являетесь дойной коровой. И вас будут - доить.

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

     
     
  • 4.100, retop (?), 12:18, 23/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Пьяный что ли? С каких это пор udp стал затратнее tcp?
     
  • 2.68, Zulu (?), 14:07, 21/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Да. И это главная причина, почему у нас сейчас QUIC деплойнут для ~5% пользователей. Дорого.
     
  • 2.106, Аноним (106), 14:16, 23/09/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Если бы так было, то щас бы linux лежал бы на помойке и работал бы на серверах. Я не понимаю, какого хрена в вашем понимании у UDP, накладных расходов для процессора больше, чем у TCP? Кажется вы профан, который написал это от балды на волне хейта всего нового. Вы наверное не в курсе, что у UPD нет целостности данных, нет коррекции ошибок, нет "рукопожатий", он не устанавливает соединение и не проверяет готовности получателя, он просто отсылает пакет по адресу, и т.д. Отсутствие этих вещей у UDP, по сравнению с TCP, делает его более быстрым и менее затратным. Наобарот, UDP по дефолту даёт меньшую нагрузку на процессор, чем TCP.
     
     
  • 3.109, Аноним (109), 20:04, 23/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Если бы так было, то щас бы linux лежал бы на помойке и работал бы на серверах.

    Да ты похоже умнее гугля и всех его профессоров. Они то глупые уже несколько лет стек udp переписывали под этот квик, а тут ты пришел и объяснил как надо.
    Пдфка с описанием и результатами гуглится по словам Optimizing UDP for content delivery.
    Иди расскажи им какой он был быстрый, менее затратный и прочее.

     
     
  • 4.112, Анонимс (?), 11:59, 28/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    угумс. TCP - 2800 Mcycle/sec, UDP - 2801 Mcycle/sec
    для тебя специально переведу: УДП протокол на 0.036% потребляет больше цпу при траспортировке.
    там ни граммулечки сказано, про установку соединения  и обработку ошибок.
     
     
  • 5.113, Аноним (113), 23:10, 29/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    То есть ты наконец нашел документацию прочёл её и....ни хера не понял. Смотреть TCP tso - 618. Это то что уже было в ядре. А к удп стеку они прикручивали точно таки же методы работы.
    Иди дальше пдфку изучай.
     
     
  • 6.114, Аноним (106), 11:35, 30/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Шо ты тут рассказываешь? Тут изначально про TSO разговора не было.
     
     
  • 7.115, Аноним (115), 20:51, 01/10/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Да я самого начала не сомневался что у тебя дислексия ярко выраженная Где тут п... большой текст свёрнут, показать
     

  • 1.3, Аноним (3), 21:08, 20/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +12 +/
    Вот на словах все хорошо. И безопастно и быстро. Если бы это кто то другой, а не гугл бы разробатывал я бы поверил. А так прям жопой чую как зонд где то там припрятан.
     
     
  • 2.10, Аноним (10), 22:06, 20/09/2019 [^] [^^] [^^^] [ответить]  
  • +6 +/
    >  прям жопой чую как зонд где то там припрятан.

    И давно это у вас?

     
     
  • 3.21, Аноним (21), 23:20, 20/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    С чего вы взяли, что припрятан?
     
     
  • 4.46, Аноним (46), 09:33, 21/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Он не припрятан. Он извлечён и примкнут, и Гугл с этим зондом наперевес идет в атаку по всем фронтам.
     
  • 2.28, Аноним (-), 00:52, 21/09/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Зачем вообще использовать зонды от Google? Уже лет 5 как перешел на Duckduckgo и не жалею, поиск хорош.
     
     
  • 3.38, Аноним (-), 01:56, 21/09/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    https://SearX.me наше всё (буквально, включая ваших уток).
     
     
  • 4.48, Анононим (?), 10:22, 21/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ошибка! Движки не могут получить результаты.

    google (unexpected crash: CAPTCHA required)

    Пожалуйста, попробуйте позже или воспользуйтесь другим сервером searx.

     
     
  • 5.50, SR_team (?), 10:38, 21/09/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    выключи в настройках этот зонд и включи ддг, тогда searx станет удобной обвязкой с линками на веб архив и прокси. А для определенных сайтов будет ещё показывать количество сидеров, личеров и магнет-ссылку
     
     
  • 6.53, Анононим (?), 10:55, 21/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Какой зонд?
     
     
  • 7.99, Аноним (99), 11:45, 23/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    google.com
     
  • 5.81, qwerty (??), 15:30, 21/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    гугл не требует капчу на менее популярных инстансах
    https://github.com/asciimoo/searx/wiki/Searx-instances
     
  • 4.49, SR_team (?), 10:26, 21/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    и правда годнота, только в мобильный хромиум фиг добавишь его по дефолту
     
  • 2.29, vantoo (ok), 00:57, 21/09/2019 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > А так прям жопой чую как зонд где то там припрятан.

    Правильно чуете, именно там он и припрятан.

     
     
  • 3.40, Google (?), 06:53, 21/09/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    С чего вы взяли? Мы ничего не прячем, эонд установлен надежно и имеет 10 см ручку для удобства использования!
     

  • 1.6, Десятерной (?), 21:30, 20/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А лучше бы иногда мозгами думать а не чувствовать задним местом. Я ни в коем случае не пытаюсь обелить G, они все же компания которая работает ради прибыли, но у них в патентах и открытых проектах много весьма годных вещей которыми успешно пользуется весь Интернет.
     
     
  • 2.16, пох. (?), 22:39, 20/09/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    все компании работают ради прибыли, но не у всех прибыль - от 0 кредитцев спецс... большой текст свёрнут, показать
     
     
  • 3.20, Дон Ягон (ok), 23:06, 20/09/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > quick для уничтожения чужих браузеров ("чисто случайно чуть-чуть отличающийся от опубликованных стандартов, но мы уже исправили, через пять лет, когда конкурентов уже вообще не осталось")

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

     

  • 1.8, пох. (?), 21:47, 20/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    > Заметный прирост производительности и пропускной
    > способности, по сравнению с TCP.

    угу, его ж лохи изобретали - вот щас гугель всем покажет как надо.

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

     
     
  • 2.11, Аноним (11), 22:16, 20/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Кончите, оботрете - потом фотки вашей пьянки будете сохранять

    То есть ты зря время не теряешь и диваешь одним выстрелом зразу два зверя?))

     
  • 2.12, Аноним (11), 22:16, 20/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    То есть ты зря время не теряешь и убиваешь одним выстрелом зразу два зверя?))
     
     
  • 3.62, Дед Маздай (?), 12:05, 21/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Fix: То есть ты зря время не теряешь и убиваешь одним выстрелом зразу двух зайцев?))
     
     
  • 4.89, анним (?), 10:32, 22/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Первого ставим как глушитель и глушим второго
     
  • 2.51, Аноним (46), 10:47, 21/09/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > его ж лохи изобретали

    Когда в DARPA его изобретали, заботились о том, чтобы депеша из штаба полка в штаб дивизии дошла в целости и сохранности. а то, что миллиарды хомячков будут видосики на Ютубе смотреть - это тогда никому в голову не приходило.
    Новые времена - новые задачи, новые инструменты.

    > прирост производительности за счет засирания канала аккуратно работающим клиентам

    Про uTP в своё время то же самое говорили. И ничо, не умерли. Есть, правда, "нюанс" - финансовые возможности Гугла, Нетфлиха, Клаудфлары и кому там оно ещё будет нужно, немножко более другие, нежели у полулегальных торрент-помоек, у них наверняка найдётся чем простимулировать провайдеров и производителей железа прописать правильный QoS. Впрочем, пока живём, а там посмотрим.

     
     
  • 3.102, пох. (?), 13:09, 23/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    у твоей почты, к примеру, есть какие-то другие задачи Или вон у поста на опенне... большой текст свёрнут, показать
     
  • 2.69, Zulu (?), 14:09, 21/09/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Если б ты чуть меньше надрачивал на свою гениальность и почитал rationale, понял бы зачем оно надо.
     

  • 1.15, BlackRot (?), 22:34, 20/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Горгулья называет это HTTP/3?
    LOL. Я лучше на HTTP/2 останусь.
     
     
  • 2.17, гугель (?), 22:42, 20/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Горгулья называет это HTTP/3?

    весь мир его называет http/3, поскольку мы просто купили ietf.

    > LOL. Я лучше на HTTP/2 останусь.

    тоже неплохо, напомним, кто его придумал и зачем. (чьи на самом деле проблемы он решает - а кому, наоборот, создает)

     
  • 2.93, Аноним (93), 14:34, 22/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    А я останусь на HTTP/1.0 мне там удобно запросы делать и ответы получать прям в консоли из кода на Си обычным wget, а все эти приблуды вроде видео уже давно идут по UDP от провайдера по multicast.
     

  • 1.18, Аноним (18), 22:50, 20/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Иронично, конечно, до чего дошло развитие Интернета. Чтобы "сократить задержки" надо возвращаться к TDM и эмулировать его поведение поверх коммутации пакетов. Хотя стойте, где-то это уже было, ах, ну да, RTP.

    Ой, а ведь и для вебсокетов тут и там используются STUN/TURN/ICE. Что же это такое выходит WWW превращается в VoIP?

    > --quic-version=h3-23

    как бы намекает...

     
     
  • 2.24, Аноним (24), 23:56, 20/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    SCTP же. Просто заставить M$ запилить его поддержку в винде гуглу слабо, вот и навелосипедили что-то похожее поверх UDP.
     
     
  • 3.30, Аноним (18), 00:58, 21/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Мне казалось, что венда тут не главное, главное поддержка вообще во всем L4 оборудовании.
     
     
  • 4.34, fail (?), 01:26, 21/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >... главное поддержка вообще во всем L4 оборудовании.

    не, там вpoде чycтвительность к наличию NAT в силу много-хоминга

     
  • 4.36, fail (?), 01:30, 21/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    ... ну и к качеству "головы прокси" между креслом и кодом;
    тут насмотришься на код банальных сетевых TCP/UDP сервисов - волосы на ногтях начинают шевелиться
     
  • 3.37, fail (?), 01:45, 21/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Просто заставить M$ запилить его поддержку в винде гуглу слабо

    - это половина вопpoса, при желании могли бы пpoдaвить через куpaтopoфф
    - вторая половина, это наличие гвоно-роутеров в норах абонентов - вот это слабо, поменять за свой счет(шмyгля) - "Значит так… Убивать аборигенов нехорошо, да? Но больше всего на свете акционеры боятся не шумихи в прессе, а дыр в финансовых отчётах" (L)

    пошли наиболее простым путем, эти бизнюки засрут UDP, как до этого зaгaдили..

     
  • 3.70, Zulu (?), 14:11, 21/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это ж прямо было сказано: продавить изменения в ядра всех ОС а потом заставить всех проапдейтить железки, которые десять лет жужжат без человеческого внимания невозможно. Поэтому будем ваять в юзерленде.
     
  • 2.44, zanswer CCNA RS and S (?), 09:05, 21/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Эм, а в чём вы видите в HTTP/3 эмуляцию Time Devision Multiplexing?
     

  • 1.19, Ordu (ok), 22:54, 20/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Хехе Когда MAC адресов показалось мало для создания сетей, придумали IP адреса ... большой текст свёрнут, показать
     
     
  • 2.47, Инженеры (?), 10:05, 21/09/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    нормуль всё в ip4.
    IP v6 -оверинжиниринг явный.
    mac - вообще не причём и в разных медиа может быть разный
     
     
  • 3.58, Ordu (ok), 11:48, 21/09/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Да, конечно И необходимость запиливать в дополнение к MAC, IP и порту ещё и и... большой текст свёрнут, показать
     
     
  • 4.85, таненбаум (?), 18:28, 21/09/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    да ты офигел
    тут панимаешли люди сидят на триджы переписанном унипсе от дедов неосиляторов мультикса
    всем довольны и восхваляют его и пророчат вендокапец
     
  • 2.52, Аноним (46), 10:53, 21/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Переходить надо на ipv12, а лучше - сразу на ipv16 или даже (чего мелочиться) ipv256.
     
     
  • 3.60, Ordu (ok), 11:51, 21/09/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Переходить надо на ipv12, а лучше - сразу на ipv16 или даже
    > (чего мелочиться) ipv256.

    Сразу не получится. Теоретически можно было бы, но практически Internet огромен, чтобы изменить его требуются зиллионы человеко-часов. Интернет распределён, в том смысле что нет единой организации, которая владела бы всей инфраструктурой, и могла бы организовать быстрый (то есть за несколько месяцов) переход на другие технологии. Поэтому переход надо выполнять пошагово, так чтобы следующая итерация развития технологий могла бы сосуществовать с предыдущей. И поэтому _сразу_ на ipv256 не удастся, не удастся даже сразу на ipv8.

     
  • 3.97, Аноним (99), 11:30, 23/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >а лучше - сразу на ipv16 или даже (чего мелочиться) ipv256

    Под номер версии IP отведено всего 4 бита.

     

  • 1.22, Онаним (?), 23:29, 20/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    UDP это хорошо. DNSCrypt UDP даже с заблокированным мобильным интернетом работает, например.
     
     
  • 2.103, оператор (?), 13:13, 23/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > UDP это хорошо. DNSCrypt UDP даже с заблокированным мобильным интернетом работает, например.

    это не ваша заслуга, это наша недоработка.
    Как только мусорного udp-траффика станет заметное количество - youtube у вас работать будет (он с cdn коробки прямо в нашей стойке работает) а эта хрень - вообще перестанет.

     

  • 1.23, Аноним (23), 23:44, 20/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Да какого черта? Только недавно HTTP/2 пропихнули, а теперь тройка. Что ж им все неймется-то заменять работающие вещи. HTTP 1 был прекрасен и всегда будет в наших сердцах
     
     
  • 2.33, Аноним (33), 01:22, 21/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    HTTP/«3» это обманка.
     
  • 2.56, Онаним (?), 11:33, 21/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Да хрен с ними, пусть чего угодно пропихивают. На фронтендах для желающих можно прикрутить. А на бекенде как был HTTP/1.1 + Connection: close, так и останется.
     

  • 1.25, Аноним (25), 00:29, 21/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А сервера то с HTTP/3 есть, или только у гугля?
     
     
  • 2.32, xm (ok), 01:10, 21/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    H2O 2.3.0-devel должен уже работать. По-крайней мере вот здесь работает https://h2o.examp1e.net/
     
  • 2.71, Zulu (?), 14:12, 21/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Akamai, Cloudflare CDNs предлагают. Если у вас один сервер, то вам HTTP/3 вообоще ни к чему.
     
     
  • 3.75, Аноним (75), 14:30, 21/09/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Действительно, что это я о себе возомнил. "Официальные" стандарты решил использовать для работы и изучения. А оказывается оно мне ни-к-че-му. Понимаю:
    У кого нет миллиарда серверов - пусть идут в ж@пу(с)
     
     
  • 4.78, Zulu (?), 14:40, 21/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Действительно, что это я о себе возомнил. "Официальные" стандарты решил использовать для
    > работы и изучения. А оказывается оно мне ни-к-че-му. Понимаю:
    > У кого нет миллиарда серверов - пусть идут в ж@пу(с)

    Достаточно просто не использовать. Есть огромное множество стандартов, которые вы не используете, и ничего.

    Но удерживать от похода в ж@пу никто никого не будет, конечно.

     
     
  • 5.79, Аноним (75), 14:53, 21/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Нет я понимаю, глядя за кого топишь, - ты на подсосе у корпов. Но мог на опеннете такой камингаут не делать. А отсылка к полонскому была сделана не случайно. Он тоже подобное кричал и чем всё кончилось? Это намек таким как ты, чем всё может обернуться.

    > Есть огромное множество стандартов, которые вы не используете, и ничего.

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

     
     
  • 6.80, Zulu (?), 14:58, 21/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Так, шапочки из фольги это не ко мне. Да и кто такой Полонский, я понятия не имею.
     

  • 1.35, Аноним (25), 01:27, 21/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    Какое прекрасное нагуглилось пока искал по этой теме документацию и обсуждения https://habr.com/ru/company/qrator/blog/416633/
    Фееричный подход. Даже комментировать нечего. Там просто состояние всей ит-индустрии описано.
     
     
  • 2.66, xm (ok), 13:24, 21/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Угу. Абырвалг, agile, признание Америки, ещё парочку...
     

  • 1.39, Sega Dreamcast (?), 02:19, 21/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А ведь если по чесноку, то вся продукция гугла — конченный мусор. Начиная с наглухо зацензуренного поисковика, заканчивая хушей ОС всех времён и народов, ведроидом.
     
     
  • 2.57, Онаним (?), 11:37, 21/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Как раз таки поисковик и ведроид - хороши. Всё остальное - отстой.
     
     
  • 3.72, Аноним (75), 14:12, 21/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Что там хорошего? Поисковик за последние несколько лет испортился. Ведроид - по откручивали всё что можно и некоторые фичи для пользователей искоренили.
     
     
  • 4.94, Онаним (?), 16:39, 22/09/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Поисковик за последние несколько лет испортился

    Чем он испортился-то? Очень неплохо ищет то, что надо, гораздо лучше ряда альтернатив типа уткошлёпа и херандекса.

     
     
  • 5.95, Аноним (95), 17:05, 22/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Всем вообще-то испортился. У нескольких коллег спросил - такого же мнения придерживаются. Ту информацию что раньше гуглилась на первой, максимум второй странице, теперь совсем не видно. Ключевые слова те же, поисковик тот же - ссылки нужной нет. Смешно, но яндекс уже такой же по поиску если не лучше. И яндекс не зассал снизу ссылку поместить - поискать на гугле.
     
     
  • 6.101, retop (?), 12:40, 23/09/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Всегда найдется кучка маргиналов из многомилионной аудитории самого популярного сервиса, которые будут постоянно ныть, что всё испортилось, но при этом не давая конкретики. Напиши им отзыв, что у коллег плохо ищет цп, тут не сайт поддержки.
     
     
  • 7.108, Аноним (109), 19:00, 23/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Мамка то не заругает что ты с взрослыми дядьками в интернете общаешься? Ну вот судя по твоей идее искать ЦП в гугле уровень развития виден.
     
  • 5.104, пох. (?), 13:17, 23/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Поисковик за последние несколько лет испортился

    лет 7 - все еще "несколько", ога

    > Чем он испортился-то? Очень неплохо ищет то, что надо, гораздо лучше ряда

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

    сидя за натом с тысячей совершенно далеких от it хомячков и с параноидально настроенным браузером - периодически получаю просто пустую страницу на банальный запрос.

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

     
  • 5.110, Аноним84701 (ok), 21:31, 23/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Чем он испортился-то? Очень неплохо ищет то, что надо, гораздо лучше ряда
    > альтернатив типа уткошлёпа и херандекса.

    Плюсы-минусы, кавычки в запросах  – часто просто игнорируются.
    Так же заметен был "улучшайзинг", когда стали вместо "найдено 0" или "столько-то результатов по этому запросу - возможно вы имели в виду <видоизмененный запрос от гугла, нужно жмякнуть ссылку>" стали сразу подсовывать результат "альтернативного" запроса-предложения от самого гугла (того самого "возможно вы имели в виду").

    И теперь, сц*ко, невозможно отличить "0 результатов" по точному запросу, от выдачи "возможно вы искали вот это".
    Причем, есть  подозрение, что  срабатывает вот эта вот "умная выдача альтернативы" и при количестве найденного немного  > 0. При этом забивая эти точные результаты  поиска куда-то на пятую-десятую страницу общего. Зато теперь по запросу выдается сразу много всего, поиск улучшили , уррраа!

    Ну и по мелочи - фильтры без JS вообще уже никакие не выставить, фильтация по дате и языку становятся все более бесполезной, поиск по коду (удобнейшая штука: https://web.archive.org/web/20101112131244/http://www.google.com//codesearch ) так и не починили после 2011 (ну да, туда же рекламу продукта особо не впихнуть) ...

     

  • 1.41, Ivan_83 (ok), 06:57, 21/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    > решающей проблемы с большим временем установки и согласования соединений в TCP

    Такая проблема только в головах гугловцев.

    > и устраняющей задержки при потере пакетов в процессе передачи данных

    Опять враки.

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

     
     
  • 2.42, zanswer CCNA RS and S (?), 08:47, 21/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Что-то вроде такого:

    RFC 8446 The Transport Layer Security (TLS) Protocol Version 1.3

    «2.2.  Resumption and Pre-Shared Key (PSK)

    Although TLS PSKs can be established out of band, PSKs can also be established in a previous connection and then used to establish a new connection ("session resumption" or "resuming" with a PSK). Once a handshake has completed, the server can send the client a PSK identity that corresponds to a unique key derived from the initial handshake (see Section 4.6.1). The client can then use that PSK identity in future handshakes to negotiate the use of the associated PSK. If the server accepts the PSK, then the security context of the new connection is cryptographically tied to the original connection and the key derived from the initial handshake is used to bootstrap the cryptographic state instead of a full handshake. In TLS 1.2 and below, this functionality was provided by "session IDs" and "session tickets" [RFC5077]. Both mechanisms are obsoleted in TLS 1.3.

    PSKs can be used with (EC)DHE key exchange in order to provide forward secrecy in combination with shared keys, or can be used alone, at the cost of losing forward secrecy for the application data.»

    Или вы имеете ввиду что-то другое?

     
     
  • 3.64, suffix (ok), 13:00, 21/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Так tls 1.3 - 0-RTT (early_data) - именно про это !
     
  • 3.107, Ivan_83 (ok), 15:29, 23/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Что-то вроде такого:
    > RFC 8446 The Transport Layer Security (TLS) Protocol Version 1.3
    > «2.2.  Resumption and Pre-Shared Key (PSK)
    > Или вы имеете ввиду что-то другое?

    Да, видимо что то такое.
    Что вообще практически убивает все преимущества HTTP2.

     

  • 1.54, Аноним (54), 11:02, 21/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Краткое содержание новости: гугель добавил протокол, разработанный гугелем, в браузер, тоже разработанный гугелем.
     
     
  • 2.63, пох. (?), 12:34, 21/09/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Краткое содержание новости: гугель добавил протокол, разработанный гугелем, в браузер,
    > тоже разработанный гугелем.

    для решения проблем во внутренних процессах - гугля.


     

  • 1.61, lucentcode (ok), 11:58, 21/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    А nginx пока ни QUICK, ни HTTP/3 не умеет... Кому нужен протокол, для которого нет ни одного нормального фронтенд-сервера?
     
     
  • 2.65, suffix (ok), 13:04, 21/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    What’s Coming in NGINX 1.17

    Development has also started on support for QUIC and HTTP/3 – the next significant update to the transport protocols that will deliver websites, applications, and APIs. This is a significant undertaking, but likely to arrive during the NGINX 1.17 development cycle.

     
     
  • 3.74, Аноним (75), 14:22, 21/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Ну пусть пытаются, чё. Скорость с которой гугл может выкатывать новые версии quic-http/3 для пользователей очень большая. Что там делать то - обновил всем броузер, обновил свои сервачки и всё. У других компаний просто нет возможности повторения текущего "стандарта". А после обкатывания они в ietf всё примут, конечно. Только кроме гугля и нескольких приближенных компаний остальным ловить нечего.
     
  • 2.73, Zulu (?), 14:15, 21/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Выгоды HTTP/3 в более быстром прохождении last mile. Если у вас один сервер (10 серверов, 100 серверов), то он вам вообще не нужен. Он нужен CDN-ам.
     

  • 1.76, t28 (?), 14:33, 21/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > А nginx пока ни QUICK, ни HTTP/3 не умеет...

    Nginx разрабатывался не для этого.

     
  • 1.77, Аноним (54), 14:35, 21/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Пускай назовут ЭТО gHTTP и тогда пофиг какая версия -- никто не будет за ними гоняться,
     
  • 1.83, Аноним (83), 15:34, 21/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Forward Error Correction, насколько я знаю, так и остались красивой идеей, котор... большой текст свёрнут, показать
     
  • 1.86, Аноним (75), 22:04, 21/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    С сервером отдачи трафика ладно, не больно надо. А вот прокси для этого HTTP/3 уже есть у кого-нибудь в решениях? На что смотреть организациям для выпускания сотрудников в интернет?
     
     
  • 2.87, Zulu (?), 22:37, 21/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Нету. Почитай спецификацию, там много заморочек заточенных под мобильных пользователей, у которых меняется адрес, а пересогласовывать соединение не хочется, и у которых возможны потери. Офис это другое.

    Не смотри на HTTP/3 как на замену HTTP/1(.1), он скорее призван его дополнять.

     

  • 1.90, Аноним (90), 11:33, 22/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    https://habr.com/ru/company/qrator/blog/416633/ Это песец. Гугл принимает стандарты строго под себя.
     
     
  • 2.91, JL2001 (ok), 12:51, 22/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > https://habr.com/ru/company/qrator/blog/416633/ Это песец. Гугл принимает стандарты
    > строго под себя.

    в статье 2018 год и, например, упоминается, что QUIC плох для вайфая и мобильного инета, а в этой новости упоминается что как раз хорош для вайфая и мобильного
    видимо за это время сильно переписали протокол и, вероятно, статья стала (частично) не актуальной

     
     
  • 3.92, Аноним (95), 13:17, 22/09/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Вы статью-то внимательно прочитали? А соседние, по экспериментам других людей с udp? Да, там всё хорошо и быстро только в идеальном мире. В реальных условиях в куче ситуаций работает хуже чем "окаменевший" tcp. Это результаты реальных измерений, а не методички от гугля. А в данный момент просто смирились и никто ничего не тестирует. Пользуются рекламными проспектами и рассказывают - ну  гугл то не будет врать, в новости же написано. Кто вам наивным реальные данные то покажет, хех? Вот такие вещи практически не встречаются https://www.cisco.com/c/dam/en_us/solutions/industries/docs/gov/performance-co . Сейчас просто заказывают сторонним фирмам исследование и они выдают три листочка с словами вай-как-хорошо-стало. Круговое накидалово.
     
  • 3.105, гугель (?), 13:21, 23/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >> https://habr.com/ru/company/qrator/blog/416633/ Это песец. Гугл принимает стандарты
    >> строго под себя.
    > в статье 2018 год и, например, упоминается, что QUIC плох для вайфая
    > и мобильного инета, а в этой новости упоминается что как раз

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

    Все правильно - хорош, для НАС. А пользователя того вайфайя и тем более его оператора нам не жалко вот совсем.

     

  • 1.96, Аноним (96), 23:18, 22/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А как браузер понимает, что нужно именно по udp подключаться? Сначал по udp пытается, а потом по tcp? Разве это не будет к дополнительным задержкам при подключении к 99% сайтов?
     
     
  • 2.98, Аноним (83), 11:40, 23/09/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Браузер заходит по https, как обычно, и в ответ получает в заголовке информацию, что он также доступен через QUIC. Открой в браузере пустую вкладку, зайди в инструменты отладки и открой google.com. После редиректов увидишь при подключении по https в заголовке ответа:

    alt-svc: quic=":443"; ma=2592000; v="46,43,39"

    Дальше браузер сам решает оставаться ему на https или переключаться на QUIC (HTTP/3).

    Если хочется больше деталей - то ищи сам (статьи или читай спецификацию).

     

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



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

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