Moving the Web from TCP to UDP

Networks are increasingly reliable today and maybe there are features of the TCP protocol that they are no longer useful. At the beginning, UDP could only be used by fast, streaming and real time applications where it doesn't matter to loss packets. However, reliable networks, like we have today, can also use the UDP protocol to transmit data over Internet for applications other than fast, streaming or real time where we even can't loss any packets. How can we use the UDP protocol to transmit data over the Internet in a reliable way? We have discuss in this blog about how to accelerate applications with HTTP/2 and Multipath TCP, but this time we are going to talk about the new experimental transport layer protocol called QUIC and developed by Google in 2012.

Every network engineer knows that a TCP connection has to perform a 3-way handshake, which means three packets have to be transmitted to start to send data packets. In addtion, if we want to encrypt the communication, we need to negotiate TLS, which means more packtes have to be transmitted before sending data packets. Obviously, 3-way handshake and TLS negotiation spend time to make a connection. Although, TCP Fast Open (TFO) was developed to improve the establishment, it isn't widely adopted yet. Therefore, the QUIC protocol is beyond TFO because it can start a connection and negotiate all the TLS parameters in one or two packtes, and what's more, Google is behind this project.

Zero RTT Connection Establishment

How does the Internet stack look like? As we can see in the next image, QUIC replaces TLS and a little bit of the HTTP/2 protocol, and it is over the UDP transport protocol. QUIC replaces TLS because it can make the crypto handshake, and QUIC replaces a little bit of HTTP/2 because it can make multiplexing and connection management which was usually done by HTTP. QUIC works over the UDP protocol, thus it implements congestion control and loss recovery.

QUIC Stack Standardized

 

One of the advantages of QUIC is the multiplexing connection because while in the TCP protocol we had to wait (buffered) each packet to order it before giving it to the application layer, and if there are missing packets we have to ask them for retransmision, the QUIC protocol isn't dependent on the order in which packets are received and if a packet is lost, it will only impact to an individual resource and it doesn't need to retransmit the entire connection.

Multiplexing

Another advantage of QUIC is the Multipath UDP. Due to the fact we don't have to establish a TCP connection we, as clients, can transmit data over different networks and technologies at the same time incrising bandwidth and availability as we have with Multipath TCP.

Multipath UDP

 

Another advantage of QUIC is the Forward Error Correction (FEC) feature which is something like a RAID 5 in datastores because QUIC can send redundant data in each packet to prevent retransmision when a packet is lost.

Forward Error Correction

How does QUIC work? As we can see in the next pictures, the first one is from a TCP connection which perform the 3-way handshake before the Client Hello packet. However, in the second picture we can see, over the UDP port 443, QUIC requests and responses, sending the Client Hello packet from the beginning of the connection, which make QUIC protocol faster than TCP establishment connections.

TCP Communication

QUIC Communication

 

We'll see in the near future if QUIC is widely adopted but anyway what it is a fact is the implementation of HTTP/2 along with SPDY, Multipath and Multiplexing which are concepts and technologies that we have to take into account when we deploy new services today. All of them improve the content delivery and we should know how they work to adapt our services and networks to this new paradigm.

Regards my friend and remember, drop a line with the first thing you're thinking.