QUIC And Its Application Protocol-HTTP/3

Brief Introduction of QUIC and HTTP/3

QUIC is the latest internet transport protocol developed upon UDP, which is faster, more responsive, secure, and flexible than the traditionally and most commonly used TCP. QUIC pronounced as ‘quick’ is a general-purpose transport layer developed by Jim Roskind of Google. It was strictly a Google product when it was first implemented in 2012 in Chrome, Google Search, YouTube, and other Google products. It exhibited excellent speed increase and better user experience at low-quality networks. In June 2015, a QUIC IETF draft proposed integration of QUIC as a formulized standard. IETF approved a QUIC and HTTP/3 working group in 2016. In 2017, according to Google, around 7% of internet traffic was being routed through QUIC. The current variant being used today is the Google version of QUIC, and it is quickly adopting the IETF standards with each iteration. HTTP/3 is the first application of QUIC. It is the version of HTTP, which is designed to take maximum advantage of the QUIC’s feature.

What Makes QUIC the Best?

Speed

It offers both 0-RTT and 1-RTT handshakes which are helpful to reduce the time of negotiation and setting up a new connection, as compared to 3-way handshake used by TCP. And the stream concept allows it to establish another logical connection to the same host without waiting until the earlier connection ends. It also allows a client to add data already available in the 0-RTT handshake, which increase the speed. Google observed 16.7 % reduction in end-to-end search latency.

Head-of-line Blocking

TCP and HTTP/2 allow multiple parallel transfers on a single TCP connection. In this case if a single packet drops, the entire connection is brought to halt until the lost packet is re-transmitted towards its destination. QUIC setup two different streams over single connection, which are treated independently. If any link drops, only associated stream has to pause, other continue transmitting data. And this way there is still a connection setup between two end points that make it more reliable.

Protocol Ossification

Internet ecosystem does not allow TCP updates. Especially the middle boxes halt it significantly, even if both the server and clients allow it. This phenomenon is called protocol Ossification. It means that even smaller changes to transport protocol are impossible to deploy without unintended consequences. QUIC design shines her too. It encrypts and cryptographically authenticates both the transport data and protocol, and bypass the middlebrow inspection resultantly. Hence, it is proposing the regular updates and versioning.

TLS 1.3 Security

QUIC is always secure. It Uses the machinery of TLS 1.3 to ensure that connections are authenticated, confidential, and integrity protected. TSL was used to protect the data of HTTPS before, but is QUIC it protects both that data and the transport protocol itself. There are only a few initial handshake packages that are transmitted clearly before the encryption protocols have been negotiated.

In Order Delivery

QUIC guarantees in-order delivery of streams, but not between the streams. It means the data over a stream would be delivered in order but each stream is independent thus it may reach the destination in a different order than with that application sent it.

Support Switching Between Networks

Traditional TCP expect you to stay connected with same connection and show delay in receiving the data while you switch between the networks, say it wi-fi to cellular network. QUIC, on the other hand is developed by keeping in mind the modern mobility patterns. The data handover would be much faster and smoother.

User Space

The QUIC is implemented in user space that helps enable quick iteration of the protocol. It makes it comparatively easy to evolve protocols without updating the operating system kernel of servers and clients to deploy new version. There is no chance of any QUIC property that can prevent it from being implementing and of feed by any operation system.

What is HTTP-over-QUIC or HTTP/3?

The IETF QUIC protocol is a transport protocol, and another application protocol can be used over it. That application protocol is HTTP/3. HTTP/3 is the next iteration of the HTTP family. It is designed to replace the HTTP/2 protocol by overcoming the flaws of this previously used protocol. HTTP/3 still maintains the same paradigms and concepts. There are headers, body, request, response., verbs, cookies, and caches. The primary change is the way how the bits are transmitted to the other end of communication.  The major flaw found in HTTP/1 and HTTP/2 was head-of-line blocking as they were built over TCP. HTTP/3, built over QUIC, utilized multiplexing technology to solve this issue. It is able to bypass the strict, narrow definition of traffic by middle boxes and NAT. It does HTTP-style transports. For instance, its HTTP header compression using QPACK is similar to the HTTP/2 compression with HPACK. The HPACK algorithm depends on an ordered delivery of streams so it was not an option for HTTP/3 without modification. QPACK is a QUIC-adapted version of HPACK, that allows out of order delivery. It would use HTTP:/ URLs. The world wide web is filled with these URLs and it seems really impractical and unreasonable to introduce another URL scheme.

Futuristic QUIC and HTTP/3

In order to focus on the core properties of the protocol, several initially-planned features are postponed to be incorporated in the second version of the QUIC.  One of them is Forward Error Correction that is a method to obtain error control in data transmission. Google has tried it on its own QUIC, but failed. The other proposed feature is Multipart. It means that the transport itself can use multiple network paths to maximize resource usage and improved redundancy. Non-HTTP adoptions are also postponed to be added to the upcoming version of QUIC.

Conclusion

There are large number of users behind poorly connected networks. QUIC is developed to improve internet performance by mitigating last mile issues of loss and latency. If it lives up to the promise most websites and users especially in poorly served parts of the world will see better results. Its value would grow with the increasing penetration of the internet globally.