TCP May Lose Out To Faster QUIC

The 20-year-old Internet transport protocol, HTTP over TCP, is in dire need of an update. We all want faster Internet, and several organizations are working on Internet protocols -- including Google's QUIC and Fujitsu's modified UDP -- to potentially replace it.

The last major revision to the HTTP protocol came out in 1999, so a new version should not come as a major surprise. Our current protocol, designed for poor connection environments (remember modems?), is sequential in operation. That means lost or bad blocks are cleaned up before the next block is transferred. This leads to hiccups in transmission whenever a lost block occurs. These can be very noticeable, especially when setting up connections to a web page. Moreover, these delays can occur across all the connections being built, and your browser just appears to stop until the mess is cleared up.

HTTP over TCP was devised to guarantee data in an environment when the web was a small part of the traffic. With the rise of the Internet and the vast expansion of memory and horsepower in everything from phones to servers, some of the constraints on protocols can be eased, giving us some new and potentially much faster options.

We are close to getting HTTP 2.0, which will speed up connections considerably and break the logjams caused by a single request error. As such, it addresses the part of the problem related to failures to an extent, but it is still bedeviled by round-trip time (RTT) delays. 

Fujitsu Ltd. and Google have proposed going beyond this and replacing TCP with a modified UDP. This protocol has been something of a backburner in the mainstream of the Internet, because there is no guarantee of delivery or block sequence, but it is used extensively in streaming media, and switch gear supports it.

The guaranteed delivery issue can be fixed by extending UDP. Computers have enough memory to take blocks out of sequence, and they can wait for bad or lost blocks to be retransmitted. Essentially, this is the key to the modifications. Sending a request for whole large chunks of a file at one time, and re-requesting anything that's not received properly, avoids the large number of RTTs from back-and-forth transmission.

Earlier this year, Fujitsu claimed a 30-fold improvement over TCP in long-haul testing of its modified UDP through submarine cables between Japan and the US. Overall latencies due to RTT were reduced to just one-sixth of their previous levels. Fujitsu is planning to commercialize the solution as middleware in the second half of this year.

Google is taking an activist role in network speed. It is driving both HTTP 2.0, with a protocol enhancement called SPDY, and a UDP-based solution similar to the Fujitsu product, called Quick UDP Internet Connections (QUIC). The company incorporated QUIC into Chrome at Release 29, but servers also have to adopt the method, and it has to broaden out to all browsers before becoming mainstream. In that respect, it is experimental, and Google acknowledges this by offering a turnoff feature in Chrome.

Google hasn't published analysis of the performance benefits yet. Anecdotally, searches I run on Google Chrome do seem much faster than those I run on Firefox. Google says that QUIC can be installed with the browser, avoiding the longer OS upgrade requirement for HTTP 2.0. If it is accepted as reliable and secure, which seems likely, QUIC will likely supplant Fujitsu's efforts and may overtake HTTP 2.0.

Any way you look at it, we should see better response times and less hiccupping from our Internet connections -- with all that implies. But the benefits won't be limited to the client-server links. Datacenter traffic internally and across the WAN can use the faster protocols, leading to more efficient connection processes and lower overhead.

Again, this is an unknown from a performance point of view, but given the high internal connection quality, a UDP protocol like QUIC makes more sense than TCP. A point of reference is a DataExpedition UDP middleware product that claims a sevenfold performance boost in WAN file transfers.

In the long run (perhaps a year or two), it seems like we may begin moving on from TCP. QUIC could become the primary protocol for both data and streaming.