Как узнать, использует ли веб-запрос / ответ QUIC и / или HTTP/2?
Я пытаюсь сделать некоторые тесты в Chromium с HTTP/2, HTTP1.1, QUIC и TCP. Я хочу попробовать разные комбинации протоколов. Я испытываю очень странное поведение в моем браузере, хотя. Когда я хочу попробовать HTTP1.1+QUIC, я запускаю свой браузер с:
chromium-browser --disable-http2 --enable-quic
И я вижу в chrome://net-internals/, что HTTP2 отключен, а QUIC включен. Однако, когда я делаю веб-запрос к серверу, поддерживающему HTTP2 и QUIC, я получаю это: 
Почему он говорит, что HTTP / 2 используется, когда он так ясно говорит, что http2 enabled: false в chrome://net-internals/?
Ранее я успешно запускал HTTP1.1 с QUIC. Был ли обновлен QUIC для работы только с HTTP/2? Или в поле "Протокол" отображается неверный протокол?
Я хотел бы, чтобы, если кто-то еще был успешным, использует QUIC с HTTP1.1
Большое спасибо!
2 ответа
QUIC работает только с HTTP/2 и не имеет смысла с HTTP/1.1.
HTTP/1.1 отправляет один запрос за раз по одному TCP-соединению. Браузеры открывают 6-8 соединений, чтобы обеспечить некоторый уровень распараллеливания, но, кроме этого хака, HTTP/1.1 в основном синхронный - вы отправляете запрос и не можете использовать это соединение снова, пока на этот запрос не будет получен полный ответ. Таким образом, HTTP/1.1 имеет проблему блокировки заголовка строки (HOL), поскольку медленный или отложенный ответ блокирует соединение, поэтому его нельзя использовать для ресурса, на который можно ответить.
HTTP/2 - это двоичный мультиплексный протокол, который в основном означает, что запросы и ответы разбиты на пакеты, которые могут быть отправлены по одному TCP-соединению и смешаны. Это замечательно, поскольку TCP-соединения относительно дороги через Интернет из-за времени, необходимого для установки TCP-соединения, возможной настройки HTTPS и последующего создания окна ограничения скорости медленного старта TCP до оптимального размера. Таким образом, возможность HTTP/2 отправлять и получать несколько HTTP-запросов и ответов по одному TCP-соединению является значительным улучшением и решает проблему блокировки HOL на уровне HTTP.
К сожалению, проблема блокировки HOL перемещена с уровня HTTP на уровень TCP. TCP является гарантированным протоколом - если потерян один пакет TCP, он повторно запрашивается, и все соединение ожидает возвращения этого пропущенного пакета. Это замечательно, поскольку протоколы более высокого уровня (например, HTTP) могут основываться на этом, не беспокоясь о проверке, сделали ли их части или нет, или в правильном порядке - об этом позаботится TCP. Недостатком этого является то, что протоколы, такие как HTTP/2, могут не нуждаться в этом строгом уровне гарантий. Если сервер отправляет 6 ответов HTTP/2 по одному соединению одновременно, и один TCP-пакет отбрасывается, это будет только для одного из этих ответов - остальные 5 теоретически могут продолжать отправляться и затем обрабатываться браузер. Но TCP запрещает это.
Поэтому QUIC стремится решить эту проблему, заменив часть TCP протоколом на основе UDP, который гарантирует доставку на уровне потока, а не на уровне соединения. Это можно было бы сделать, улучшив TCP, но он настолько встроен во многие серверы, клиенты, операционные системы, сетевую инфраструктуру и т. Д., Что вместо этого было проще создать UDP. В конечном счете, выводы из этого могут быть включены в TCP. До тех пор QUIC позволяет быстро экспериментировать и внедрять инновации, поскольку UDP очень и очень легок, и любые дополнения к нему (например, гарантии доставки) в основном реализуются в пространстве пользовательского пространства, а не на внутреннем уровне более низкого уровня, где его невозможно обновить. QUIC, вероятно, в конечном итоге будет использоваться для протоколов, отличных от HTTP, но на данный момент это основной вариант использования.
Таким образом, QUIC эффективно заменяет часть TCP, но ему также необходимо изменить части более низкого уровня HTTP/2, что означает, что ему также необходимо реализовать промежуточную часть TLS. Лучшая диаграмма для объяснения его места - это диаграмма (взята из этой презентации):
Ранее я успешно запускал HTTP1.1 с QUIC.
Я серьезно сомневаюсь в этом. Согласно вышеприведенному объяснению, QUIC имеет смысл только для мультиплексного протокола, такого как HTTP/2. Возможно, Chrome раньше называл это QUIC скорее, чем HTTP/2 + QUIC но он всегда использовал HTTP/2 (или его аналог SPDY).
Наконец, HTTP/2 действительно только меняет способ отправки сообщений по сети. На более высоком уровне, который используется веб-разработчиками и пользователями, он часто действует так же, как HTTP/1.1 с теми же глаголами (GET, POST... и т. Д.) И HTTP-заголовками (в основном). Так как QUIC просто улучшает способ отправки этих сообщений HTTP/2 по проводам, а не протокол "HTTP" более высокого уровня, на самом деле не имеет смысла обсуждать или измерять, каким образом HTTP/1.1 по сравнению с QUIC (если он существовал) мог бы отличаются от HTTP/2 по сравнению с QUIC - поскольку HTTP/1.1 по сравнению с QUIC в основном станет HTTP/2 по сравнению с QUIC.
Если вам нужен быстрый тест, перейдите на https://http3.is .
Это тестовый сайт, созданный fastly.