A lot of traffic over the Internet goes through secure https connections. Under the hood this requires a 3-way handshake to establish a TCP connection, followed by even more packets exchanged between the client and server to negotiate TLS in order to establish a secure connection. Google is now working one the new experimental QUIC protocol that uses the “send and forget” UDP protocol, together with its own crypto, and its own way to making sure the connection is properly establish.
The whole idea about QUIC is to reduce the effect of latency (e.g. ping time) by exchanging less messages to achieve the same secure connectivity. For example, if there’s a 200ms latency between a server and a client, and if a TCP connection requires 4 packets, while a QUIC/UDP connection requires only 1 packet, you’ll save about 600ms.
One downside with UDP according to Jim Roskind, designer of QUIC, is that UDP ports are blocked by some enterprise customers, however he expects that to change overtime, as in the past they also blocked TCP port 80 (used to browse the web), and that eventually QUIC could displace TCP, potentially becoming “TCP/2”. This would require a lot of work, as it would have to supported in Windows, Linux, and other kernels/operating systems to really take of.
You can find a detailed technical write up on QUIC on Mattias Geniar blog. You may also want to check out QUIC Chromium page, as well as the code for proto-quic standalone library for QUIC, currently only working with Linux, and tested on Google’s Ubuntu clone.
Thanks to Nanik for the tip.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
Huh? UDP and TCP are entirely different animals that are used for entirely different reasons. TCP is an acknowledgement protocol that attempts guaranteed delivery, UDP has no end-to-end acknowledgement and guarantees nothing. So if QUIC replaces TCP what is gained by stacking it on top of UDP? At a minimum treating an acknowledgement protocol (QUIC) as a non-acknowledgement protocol (UDP) over the network is at-best going to be a bunch of poor compromises. Then there are things like header compression – what’s Google going to do, make some kind of Frankenstein out of UDP’s cRTP dictionary-based compression? And how’s QUIC going to maintain connection state when some along-the-way router treats it like UDP and picks new paths willy-nilly whenever it wants?
@Drone Perhaps you could try reading about QUIC. As the article mentioned, you can find a detailed technical write up on QUIC on Mattias Geniar blog (https://ma.ttias.be/googles-quic-protocol-moving-web-tcp-udp/).
Actually there is a trend of shipping userspace network stacks instead of relying on the kernel one:
https://lwn.net/Articles/691887/
Network stacks are stuck in the middleages, improvements like mptcp can’t be mainlined because too many people depends on a sane tcp/ip stack.
And a lot of code is going into the linux kernel tcp stack, compile a simple kernel without a tcp stack it is 300KB, with it is 7000KB, so 400KB difference just to be able to send packets over the network.
Last Fosdem, the guys from picotcp showed their tcpip stack on a linux kernel, with only 21KB size.
And then we are “ossified” with TCP and UDP only, because the middleboxes that ISPs have setuped only speaks those:
https://lwn.net/Articles/667059/
– I think describing it as TCP/2 is a little mis-leading. It doesn’t have to be implemented in the kernel to be cross-platform. It’s better to think of it as moving the TCP functionality into openssl, which is a cross platform library that sits on top of the OS. Can the OS implement it? Yes, does it have to? Nope. (grumpy old guys like me will remember the old third-party WinSock stacks).
– There’s nothing that says packet reordering or acknowledgement has to be done at the transport level. And for a lot of applications there’s additional layers of ordering on top of that (e.g. Web pages that have Javascript, you can’t execute the javascript until the DOM is rendered so putting the javascript at the top of the web page is conceptually out of order … granted it allows browsers to start buffering them before their needed but you get the basic idea). With most modern wired connections, packet loss is low enough that from a performance standpoint it makes sense to dump the overhead of TCP and have the QUIC stack handle reordering during the exceptional case that it happens. If the browser detects you’re on a noisy/bad connection (e.g. cellular) it can fall back to TCP if it needs to.
– Other than the potential of out of order packets, multi-path is a none issue, as long as you get the packet, you don’t care how it got there (and carriers are only generally only going to switch your route if a backbone goes down), it happens a lot less often than you think. The only situation I can think of where it happens frequently is cellular in a fast moving vehicle … but even then the cellular backends do a good job of making it transparent.
– cRTP compression/decompression is done at the transport layer, so the packet would be decompressed before it’s passed up to QUIC.
I was just trying to visit youtube with Chromium and got this error:
“This site can’t be reached
The webpage at https://www.youtube.com/ might be temporarily down or it may have moved permanently to a new web address.
ERR_QUIC_PROTOCOL_ERROR”
@zoobab
So it’s already in use… Somebody mentioned Chromium and Chrome support to me in Google+. I’d assume it’s only working on Google websites right now, as other servers would not support QUIC protocol.
Default enable Chrome 52 🙂