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.
Наконец, когда QUIC завершил стандартизацию (в отличие от нестандартной версии Google QUIC, часто называемой gQUIC), он будет использовать модифицированную версию HTTP / 2 , которая будет называться HTTP / 3 . На данный момент браузеры будут использовать только gQUIC и HTTP / 2.