IETF

The QUIC working group that was established to standardize the protocol withinthe IETF quickly decided that the QUIC protocol should be able to transferother protocols than “just” HTTP. Google-QUIC only ever transported HTTP -in practice it transported what was effectively HTTP/2 frames, using theHTTP/2 frame syntax.

It was also stated that IETF-QUIC should base its encryption and security onTLS 1.3 instead of the “custom” approach used by Google-QUIC.

In order to satisfy the send-more-than-HTTP demand, the IETF QUIC protocolarchitecture was split in two separate layers: the transport QUIC and the“HTTP over QUIC” layer (the latter sometimes referred to as “hq”).

This layer split, while it may sound innocuous, has caused the IETF-QUIC todiffer quite a lot from the original Google-QUIC.

The working group did however soon decide that in order to get the proper focusand ability to deliver QUIC version 1 on time, it would focus on deliveringHTTP, leaving non-HTTP transports to later work.

In March 2018 when we started working on this book, the plan was to ship thefinal specification for QUIC version 1 in November 2018; this was laterpostponed to July 2019.

While the work on IETF-QUIC has progressed, the Google team has incorporateddetails from the IETF version and has started to slowly progress their versionof the protocol towards what the IETF version might become. Google has continuedusing their version of QUIC in their browser and services.

Most new implementations under developmenthave decided to focus on the IETF version and are not compatible with the Google version.