The internet has evolved dramatically in the last few years, with a billion people online posing groundbreaking challenges to the existing architecture. From latency to security, distributed systems to serverless, the web has evolved significantly to meet these challenges. Even underlying architectures are undergoing smart refabrication.
The fundamental of the modern web is the HTTP Protocol Stack. Especially HTTP over TCP has fulfilled every requirement till now. Due to its implementation and philosophical limitation, it may not be the better choice for the future web.
Latency
The immense growth in latency-sensitive web services is placing enormous demand for reducing it. As the internet rapidly shifts towards secure data transmission, this is adding another layer of delays. Additionally, Middleboxes have become vital control points of the Internet’s architecture. Firewalls, NATs have made it incapable to upgrade to a new protocol without explicit support.
Handshake Delay
HTTPS stack on TCP connection commonly incurs one Round Trip Delay of connection setup before transmitting data. Unnecessary round trips most impact most connections on the internet. Especially short transmissions become heavy and slow.
Head-Of-Line(HOL) Blocking Delay
HTTP recommends limiting the number of connections to reduce latency and overhead cost of using multiple TCP connections. HTTP/2 multiplexes various objects to reduce transaction latency further, and suggests using a single TCP connection to any server.
TCP’s byte stream abstraction, however, prevents applications from controlling the framing of their communications and imposes a “latency tax” on application frames whose delivery must wait for retransmissions of previously lost TCP segments.
And to modify all these, it’s essential to coordinate between OS developers, application developers, network vendors, middlebox vendors, which seems a mount-moving task.
Jim Roskind, in the year 2012 at Google, developed a new protocol that was built upon UDP (User Datagram Protocol) and named it Quick UDP Internet Connections. IETF’s use of the word QUIC is not an acronym; it is merely the name of the protocol.
QUIC is designed to meet several goals, which include all the above-mentioned issues. It combines its cryptographic and transport handshake to minimize setup RTT.
Connection Establishment
Initially, when the client has no idea about the server, the client sends an inchoate hello message (CHLO) encrypted to elicit a reject response. Along with this reject response, the server sends its configuration, public key chain, and a source address token.
A new connection request is now prepared, along with the provided data. Here QUIC saves one trip of establishing a secure connection, as in this final request, it encrypts the data as per the server’s requirement.
QUIC provides two levels of secrecy of data: i) Initial client data is encrypted using primary keys ii) Subsequent client data, and all server data are encrypted using forward-secure keys.
Stream Multiplexing
QUIC supports multiple streams within a connection; it ensures that a lost UDP packet only affects those streams which were carrying those packets. QUIC streams are lightweight and bidirectional byte streams. QUIC stream multiplexing is done by encapsulating stream data in stream frames. A typical QUIC frame can carry multiple stream frames from one or more stream.
Authentication and Encryption
QUIC packets are fully authenticated and mostly encrypted. QUIC packet headers are although not encrypted. These headers are mostly required for routing or decrypting the packets. Any information sent in unencrypted handshake packets, like the Version Negotiation packet, is included in the final connection keys. In-network tampering of these handshake packets causes the final connection keys to be different at the peers, causing the connection to eventually fail without successful decryption of any application data by either peer. Reset packets are sent by a server that does not have the state for the connection, which may happen due to a routing change or due to a server restart.
Loss Recovery
Every QUIC packet carries a new packet number, including those carrying retransmitted data. This design omits the need for a separate mechanism to distinguish the ACK transmission and original transmission, thus avoiding TCP’s retransmission ambiguity problem. Stream offsets in-stream frames are used for delivery orders, separating the two functions that TCP conflates.
Flow Control
Similar to HTTP/2, QUIC employs credit-based flow control. As data is sent, received, and delivered on a particular stream, the receiver periodically sends window update frames that increase the advertised offset limit for that stream, allowing the peer to send more data on that stream.
QUIC Performance
The Google Search and YouTube apps were developed independently from Chrome; they are tuned specifically for the mobile environment. Google Search app retrieves smaller responses, whose content has been tailored to have reduced latency in mobile networks. Similarly, the YouTube app pre-warms connections to reduce video playback latency and uses an Adaptive Bit Rate (ABR) algorithm that is optimized for mobile screens.
QUIC’s performance benefits over TLS/TCP are thus not uniformly distributed across geography or network quality: benefits are greater in networks and regions that have higher average RTT and higher network loss.
The QUIC implementation was initially written with a focus on rapid feature development and ease of debugging, not CPU efficiency. It has been found that QUIC’s server CPU utilization was about 3.5 times higher than TLS/TCP.
QUIC was designed and launched as an experiment, and it has now become a core part of our serving infrastructure. One of QUIC’s most important features is its ability to be used as a platform for wide-scale experimentation with transport mechanisms, both at the server and at the client. Ongoing experimentation and work are continuing on several fronts.
Last Updated: Wed May 08 2024