To the centre of everything we know

November 18, 2022 The Editorial Board - Teamware Solutions

QUIC protocol

Internet is built upon TCP/IP. This is the case for nearly over half a century and since inception of internet. TCP served the purpose by being the reliable backbone by having something called 3-way handshake. Three-way handshake ensures data packets that are sent is received by the recipients and makes way to robust error handling. 3-way handshake in TCP protocol involves sending SYN, SYN ACK, and ACK packets in sequence. We as application developers would have never bothered about these except for during our formative years of formal education in colleges. But for all our benefits – SYN is the synchronization sequence number, ACK standards for Acknowledge packet. The SYN ACK is an optimization where both the Synchronization and Acknowledge packet is sent from server to client. Needless to say, client starts the session with SYN packet. This dance was to be done before first packet of data was ever exchanged between client and server. Fast forward few decades, with increasing number of devices getting connected, in the last decade of past century TLS or in other words security came in. It required few more tap dancing to be done before data is exchanged between client and server over and above the 3-way handshake. All of this was okay as devices were all connected and stationary. Now add mobility 😃. We reach to present days and start getting pinched by the bureaucracy involved in establishing connections.

As developers no matter how fast you could process JSON, or no matter how fast you could query database, you will end up wrangling with the limitation that the infrastructure offers the infrastructure of the internet – TCP/IP.

Enter the world of QUIC.

QUIC

The abbreviation stands for nothing per the RFC standard. However, when this was first experimented in Google around 2012, it stood for Quick UDP Internet Connection. If you remember your boring lectures from the college, it must have raised your eyebrows. UDP was taught as unreliable broadcast-oriented fire and forget protocol. How can such protocol ever support… let us say my banking website? QUIC was engineered to answer that question not by using 3-way handshake but by mimic it with efficiency. First level of efficiency is introduced by multiplexing; thus, reducing number of packets exchanged before actual data is sent. Second level of efficiency is to use TLS by default instead of as a bolt on like in TCP which earlier introduced delays. QUIC enables modern streaming requirements by riding on HTTP/2 it can compensate for higher potential data loss by parallel streams between client and server instead of exchanging loss recovery specific packets over still fragile network. One of the major beneficiaries of this style (if we could add some swag to the boring protocol) is mobility; yes, mobile devices and your relentless need to binge watch your favorite series while you are on the move to work place or to your nearest cafe. We will add just one more sentence to make you see why we say so, yes mobile’s internet connection hops between mobile signal towers, TCP’s 3-way handshake and TLS adds more overhead on network and consumes battery from the networking component. Moving to QUIC lowers all those stresses on the mobile.

Impact on applications

When we started this keying in this dispatch, we were getting entangled on the usage of the word application. One thing you must remember when diving to the centre of everything we know i.e., internet is the word application here means protocol implementation. A protocol implementation has two ends. One that serves known as server and the one that consumes known as client and more popularly as application. But in the title of this section, we have used the word in the context we know as Line of Business application developer. For us application is used to describe software the is either installed on desktops / mobile or is browsed using web browser.

With that taxonomy gotcha out of our way; let us ask the question how does this matter to us who write Line of Business application? We are miles and miles away from protocol implementations. If you believe so, read the following code –

The above one was in C#. Being a high-level language many of the protocol handling is abstracted and only thing that drives it here is the option to the HttpClient property initializer. What we are doing there is asking the framework to use Http/3 strictly and instructing to not fall back to any other version. How does that relate to QUIC if you ask, in Windows and version 10 onwards where HTTP/3 is supported you have QUIC running at Schannel with MSQuic’s http.sys copy in the system. Let us look at a python. It might not be as fluent and as abstracted as C#’s version but potentially could be similar and yet somewhat familiar to you –

If you have glanced on these you will agree it is the center piece of many applications these days. We could not practically remember any code in the recent past decade that would not have used HttpClient to fulfill an operation. QUIC sits right there for us application developers on the HttpClient. The nuances in each language could form a part of a separate dispatch. Until then enjoy writing code and solving problem the world faces… Happy coding.