HTTP/3

The protocol that’s been called HTTP-over-QUIC for quite some time has now changed name and will officially become HTTP/3. This was triggered by this original suggestion by Mark Nottingham.

The QUIC Working Group in the IETF works on creating the QUIC transport protocol. QUIC is a TCP replacement done over UDP. Originally, QUIC was started as an effort by Google and then more of a “HTTP/2-encrypted-over-UDP” protocol.

When the work took off in the IETF to standardize the protocol, it was split up in two layers: the transport and the HTTP parts. The idea being that this transport protocol can be used to transfer other data too and its not just done explicitly for HTTP or HTTP-like protocols. But the name was still QUIC.

People in the community has referred to these different versions of the protocol using informal names such as iQUIC and gQUIC to separate the QUIC protocols from IETF and Google (since they differed quite a lot in the details). The protocol that sends HTTP over “iQUIC” was called “hq” (HTTP-over-QUIC) for a long time.

Mike Bishop scared the room at the QUIC working group meeting in IETF 103 when he presented this slide with what could be thought of almost a logo…

On November 7, 2018 Dmitri of Litespeed announced that they and Facebook had successfully done the first interop ever between two HTTP/3 implementations. Mike Bihop’s follow-up presentation in the HTTPbis session on the topic can be seen here. The consensus in the end of that meeting said the new name is HTTP/3!

No more confusion. HTTP/3 is the coming new HTTP version that uses QUIC for transport!

33 thoughts on “HTTP/3”

  1. Could I translate this excellent article into Japanese and publish on my blog or somewhere?

    If I have done, I promise to leave a comment with the link.

        1. QUIC and HTTP/3 are scheduled to get done this year. It is work that’s been going on for a few years already. So even if it slips a bit, it is still not far away…

  2. Is UDP reliable enough for this?
    For example, some clients and APIs could try to transfer some valuable payload over this protocol and they need to have it transferred without any corruption.

  3. Would like to know if there is any data on performance comparison between HTTP/3 and HTTP/2. (with both lossy and loss-less channel).

  4. well, I was building a p2p instant messenger 5 years ago and decided upon using udp + multiplexing thing just like QUIC.

    Guess what, the code worked quite well on local system and on LAN network except for my old Belkin wifi router which would force update udp source port mapping after a few hundred packet getting exchanged.

    This totally made it impossible to use udp streaming and that is when I realized that there are such devices in millions of homes that would do this thing.

    tl;dr; low end home routers suck big time at UDP NAT and so you always use TCP.

    1. I read few more details on QUIC and they happen to solve this above issue using connection ID such that even if IP address or source port changes, the ID remains same and the server end would handle it correctly by keeping track of the latest client source port & IP address.

      However, this issue happens too frequently on low end routers and thus you will always have some UDP packets en-route to the wrong/old port thus getting lost/dropped at client router NAT and needing re-transmission to the correct/latest port the last packet was received from.

      This issue could potentially take away any optimization advantage QUIC brings to the table. Only positive thing that QUIC brings is avoiding the head of line issue that TCP has when doing multiplexing.

      NAT was a bad idea which has set back Internet research by decades. Without NAT, everyone would have been forced on IPv6 by now for sure.

  5. Interesting trend, with UDP, is to move responsibilities from the network layer up to the application. Chrome will handle the reliability, connexion, session and else instead of TCP.
    – Application may have more context to know what is best
    – Application evolve faster, they are not “ossifying”

    1. Another concern is that UDP is wildly used for volumetric DDoS attacks by using spoofed IP adreses etc. and in many places it is can be filtered or rate-limited on ISP levels. It is easy to protect against UDP volumetric attack by just blocking it with ACL on the ISP side. But, now, with QUIC it will make the situation worse because ACL that blocks UDP on port 80 will block legitimite traffic.

  6. Could I translate this article to Simplified Chinese?
    Surely there will be a link refering this article.
    Thanks for your response!

  7. Indeed. We haven’t even seen adoption of HTTP/2 > 75% and we have the “big players” trying to push another version.

    I suspect in three years when they realise that we HTTP/2 just got to to normal, they will begin to wonder again what to do with HTTP/3.

    HTTP/3 and IPv5. Together forever.

  8. Coming from a spacecraft operations background, I am interested in resilience to high latency (more than 1 sec, 10 sec, or 100 sec) in both HTTP/3 and QUIC at low-ish bandwidth (10s, 100s, or 1000s of kbps), also in combination with varying packet loss (sometimes very high, sometimes low). I am no expert on protocols, but it appears to me that at least QUIC could provide a sensible basis to interoperate well with the CCSDS Space Packet (or other protocols from CCSDS), at least for short latencies (i.e. in the order of 1s of sec). I am unsure how well the parameters selected for HTTP/3 fit above mentioned use cases. Do you have any pointers on that (other than reading the spec itself)?

Comments are closed.