Google’s QUIC protocol: moving the web from TCP to UDP

Mattias Geniar, Saturday, July 30, 2016 - last modified: Sunday, December 4, 2016

The QUIC protocol (Quick UDP Internet Connections) is an entirely new protocol for the web developed on top of UDP instead of TCP.

Some are even (jokingly) calling it TCP/2.

I only learned about QUIC a few weeks ago while doing the curl & libcurl episode of the SysCast podcast.

The really interesting bit about the QUIC protocol is the move to UDP.

Now, the web is built on top of TCP for its reliability as a transmission protocol. To start a TCP connection a 3-way handshake is performed. This means additional round-trips (network packets being sent back and forth) for each starting connection which adds significant delays to any new connection.

tcp_3_way_handshake

(Source: Next generation multiplexed transport over UDP (PDF))

If on top of that you also need to negotiate TLS, to create a secure, encrypted, https connection, even more network packets have to be sent back and forth.

tcp_3_way_handshake_with_tls

(Source: Next generation multiplexed transport over UDP (PDF))

Innovation like TCP Fast Open will improve the situation for TCP, but this isn't widely adopted yet.

UDP on the other hand is more of a fire and forget protocol. A message is sent over UDP and it's assumed to arrive at the destination. The benefit is less time spent on the network to validate packets, the downside is that in order to be reliable, something has to be built on top of UDP to confirm packet delivery.

That's where Google's QUIC protocol comes in.

The QUIC protocol can start a connection and negotiate all the TLS (HTTPs) parameters in 1 or 2 packets (depends on if it's a new server you are connecting to or a known host).

udp_quic_with_tls

(Source: Next generation multiplexed transport over UDP (PDF))

This can make a huge difference for the initial connection and start of download for a page.

Why is QUIC needed?

It's absolutely mind boggling what the team developing the QUIC protocol is doing. It wants to combine the speed and possibilities of the UDP protocol with the reliability of the TCP protocol.

Wikipedia explains it fairly well.

As improving TCP is a long-term goal for Google, QUIC aims to be nearly equivalent to an independent TCP connection, but with much reduced latency and better SPDY-like stream-multiplexing support.

If QUIC features prove effective, those features could migrate into a later version of TCP and TLS (which have a notably longer deployment cycle).

QUIC

There's a part of that quote that needs emphasising: if QUIC features prove effective, those features could migrate into a later version of TCP.

The TCP protocol is rather highly regulated. Its implementation is inside the Windows and Linux kernel, it's in each phone OS, ... it's pretty much in every low-level device. Improving on the way TCP works is going to be hard, as each of those TCP implementation needs to follow.

UDP on the other hand is relatively simple in design. It's faster to implement a new protocol on top of UDP to prove some of the theories Google has about TCP. That way, once they can confirm their theories about network congestion, stream blocking, ... they can begin their efforts to move the good parts of QUIC to the TCP protocol.

But altering the TCP stack requires work from the Linux kernel & Windows, intermediary middleboxes, users to update their stack, ... Doing the same thing in UDP is much more difficult for the developers making the protocol but allows them to iterate much faster and implement those theories in months instead of years or decades.

Where does QUIC fit in?

If you look at the layers which make up a modern HTTPs connection, QUIC replaces the TLS stack and parts of HTTP/2.

The QUIC protocol implements its own crypto-layer so does not make use of the existing TLS 1.2.

tcp_udp_quic_http2_compared

It replaces TCP with UDP and on top of QUIC is a smaller HTTP/2 API used to communicate with remote servers. The reason it's smaller is because the multiplexing and connection management is already handled by QUIC. What's left is an interpretation of the HTTP protocol.

TCP head-of-line blocking

With SPDY and HTTP/2 we now have a single TCP connection being used to connect to a server instead of multiple connections for each asset on a page. That one TCP connection can independently request and receive resources.

spdy_multiplexed_assets

(Source: QUIC: next generation multiplexed transport over UDP)

Now that everything depends on that single TCP connection, a downside is introduced: head-of-line blocking.

In TCP, packets need to arrive be processed in the correct order. If a packet is lost on its way to/from the server, it needs to be retransmitted. The TCP connection needs to wait (or "block") on that TCP packet before it can continue to parse the other packets, because the order in which TCP packets are processed matters.

spdy_multiplexed_assets_head_of_line_blocked

(Source: QUIC: next generation multiplexed transport over UDP)

In QUIC, this is solved by not making use of TCP anymore.

UDP is not dependent on the order in which packets are received. While it's still possible for packets to get lost during transit, they will only impact an individual resource (as in: a single CSS/JS file) and not block the entire connection.

quic_multiplexing

(Source: QUIC: next generation multiplexed transport over UDP)

QUIC is essentially combining the best parts of SPDY and HTTP2 (the multiplexing) on top of a non-blocking transportation protocol.

Why fewer packets matter so much

If you're lucky enough to be on a fast internet connection, you can have latencies between you and a remote server between the 10-50ms range. Every packet you send across the network will take that amount of time to be received.

For latencies < 50ms, the benefit may not be immediately clear.

It's mostly noticeable when you are talking to a server on another continent or via a mobile carrier using Edge, 3G/4G/LTE. To reach a server from Europe in the US, you have to cross the Atlantic ocean. You immediately get a latency penalty of +100ms or higher purely because of the distance that needs to be traveled.

network_round_trip_europe_london

(Source: QUIC: next generation multiplexed transport over UDP)

Mobile networks have the same kind of latency: it's not unlikely to have a 100-150ms latency between your mobile phone and a remote server on a slow connection, merely because of the radio frequencies and intermediate networks that have to be traveled. In 4G/LTE situations, a 50ms latency is easier to get.

On mobile devices and for large-distance networks, the difference between sending/receiving 4 packets (TCP + TLS) and 1 packet (QUIC) can be up to 300ms of saved time for that initial connection.

Forward Error Correction: preventing failure

A nifty feature of QUIC is FEC or Forward Error Correction. Every packet that gets sent also includes enough data of the other packets so that a missing packet can be reconstructed without having to retransmit it.

This is essentially RAID 5 on the network level.

Because of this, there is a trade-off: each UDP packet contains more payload than is strictly necessary, because it accounts for the potential of missed packets that can more easily be recreated this way.

The current ratio seems to be around 10 packets. So for every 10 UDP packets sent, there is enough data to reconstruct a missing packet. A 10% overhead, if you will.

Consider Forward Error Correction as a sacrifice in terms of "data per UDP packet" that can be sent, but the gain is not having to retransmit a lost packet, which would take a lot longer (recipient has to confirm a missing packet, request it again and await the response).

Session resumption & parallel downloads

Another exciting opportunity with the switch to UDP is the fact that you are no longer dependent on the source IP of the connection.

In TCP, you need 4 parameters to make up a connection. The so-called quadruplets.

To start a new TCP connection, you need a source IP, source port, destination IP and destination port. On a Linux server, you can see those quadruplets using netstat.

$ netstat -anlp | grep ':443'
...
tcp6       0      0 2a03:a800:a1:1952::f:443 2604:a580:2:1::7:57940  TIME_WAIT   -
tcp        0      0 31.193.180.217:443       81.82.98.95:59355       TIME_WAIT   -
...

If any of the parameters (source IP/port or destination IP/port) change, a new TCP connection needs to be made.

This is why keeping a stable connection on a mobile device is so hard, because you may be constantly switching between WiFi and 3G/LTE.

quic_parking_lot_problem

(Source: QUIC: next generation multiplexed transport over UDP)

With QUIC, since it's now using UDP, there are no quadruplets.

QUIC has implemented its own identifier for unique connections called the Connection UUID. It's possible to go from WiFi to LTE and still keep your Connection UUID, so no need to renegotiate the connection or TLS. Your previous connection is still valid.

This works the same way as the Mosh Shell, keeping SSH connections alive over UDP for a better roaming & mobile experience.

This also opens the doors to using multiple sources to fetch content. If the Connection UUID can be shared over a WiFi and cellular connection, it's in theory possible to use both media to download content. You're effectively streaming or downloading content in parallel, using every available interface you have.

While still theoretical, UDP allows for such innovation.

The QUIC protocol in action

The Chrome browser has had (experimental) support for QUIC since 2014. If you want test QUIC, you can enable the protocol in Chrome. Practically, you can only test the QUIC protocol against Google services.

The biggest benefit Google has is the combination of owning both the browser and the server marketshare. By enabling QUIC on both the client (Chrome) and the server (Google services like YouTube, Google.com), they can run large-scale tests of new protocols in production.

There's a convenient Chrome plugin that can show the HTTP/2 and QUIC protocol as an icon in your browser: HTTP/2 and SPDY indicator.

You can see how QUIC is being used by opening the chrome://net-internals/#quic tab right now (you'll also notice the Connection UUID mentioned earlier).

quic_net_internals_sessions

If you're interested in the low-level details, you can even see all the live connections and get individual per-packet captures: chrome://net-internals/#events&q=type:QUIC_SESSION%20is:active.

quic_debug_packets_chrome

Similar to how you can see the internals of a SDPY or HTTP/2 connection.

Won't someone think of the firewall?

If you're a sysadmin or network engineer, you probably gave a little shrug at the beginning when I mentioned QUIC being UDP instead of TCP. You've probably got a good reason for that, too.

For instance, when we at Nucleus Hosting configure a firewall for a webserver, those firewall rules look like these.

firewall_http_https_incoming_allow

Take special note of the protocol column: TCP.

Our firewall isn't very different from the one deployed by thousands of other sysadmins. At this time, there's no reason for a webserver to allow anything other than 80/TCP or 443/TCP. TCP only. No UDP.

Well, if we want to allow the QUIC protocol, we will need to allow 443/UDP too.

For servers, this means opening incoming 443/UDP to the webserver. For clients, it means allowing outgoing 443/UDP to the internet.

In large enterprises, I can see this be an issue. Getting it past security to allow UDP on a normally TCP-only port sounds fishy.

I would've actually thought this to be a major problem in terms of connectivity, but as Google has done the experiments -- this turns out to not be the case.

quic_connection_statistics

(Source: QUIC Deployment Experience @Google)

Those numbers were given at a recent HTTP workshop in Sweden. A couple of key-pointers;

  • Since QUIC is only supported on Google Services now, the server-side firewalling is probably OK.
  • These numbers are client-side only: they show how many clients are allowed to do UDP over port 443.
  • QUIC can be disabled in Chrome for compliance reasons. I bet there are a lot of enterprises that have disabled QUIC so those connections aren't even attempted.

Since QUIC is also TLS-enabled, we only need to worry about UDP on port 443. UDP on port 80 isn't very likely to happen soon.

The advantage of doing things encrypted-only is that Deep Packet Inspection middleware (aka: intrusion prevention systems) can't decrypt the TLS traffic and modify the protocol, they see binary data over the fire and will -- hopefully -- just let it go through.

Running QUIC server-side

Right now, the only webserver that can get you QUIC is Caddy since version 0.9.

Both client-side and server-side support is considered experimental, so it's up to you to run it.

Since no one has QUIC support enabled by default in the client, you're probably still safe to run it and enable QUIC in your own browser(s). (Update: since Chrome 52, everyone has QUIC enabled by default, even to non-whitelisted domains)

To help debug QUIC I hope curl will implement it soon, there certainly is interest.

Performance benefits of QUIC

In a 2015 blogpost Google has shared several results from the QUIC implementation.

As a result, QUIC outshines TCP under poor network conditions, shaving a full second off the Google Search page load time for the slowest 1% of connections.

These benefits are even more apparent for video services like YouTube. Users report 30% fewer rebuffers when watching videos over QUIC.
A QUIC update on Google’s experimental transport (2015)

The YouTube statistics are especially interesting. If these kinds of improvements are possible, we'll see a quick adoption in video streaming services like Vimeo or "adult streaming services".

Conclusion

I find the QUIC protocol to be truly fascinating!

The amount of work that has gone into it, the fact that it's already running for the biggest websites available and that it's working blow my mind.

I can't wait see the QUIC spec become final and implemented in other browsers and webservers!

Update: comment from Jim Roskind, designer of QUIC

Jim Roskind was kind enough to leave a comment on this blog (see below) that deserves emphasising.

Having spent years on the research, design and deployment of QUIC, I can add some insight. Your comment about UDP ports being blocked was exactly my conjecture when we were experimenting with QUIC’s (UDP) viability (before spending time on the detailed design and architecture). My conjecture was that the reason we could only get 93% reachability was because enterprise customers were commonly blocking UDP (perchance other than what was needed for DNS).

If you recall that historically, enterprise customers routinely blocked TCP port 80 "to prevent employees from wasting their time surfing," then you know that overly conservative security does happen (and usability drives changes!). As it becomes commonly known that allowing UDP:443 to egress will provide better user experience (i.e., employees can get their job done faster, and with less wasted bandwidth), then I expect that usability will once again trump security ... and the UDP:443 port will be open in most enterprise scenarios.

... also ... your headline using the words “TCP/2” may well IMO be on target. I expect that the rate of evolution of QUIC congestion avoidance will allow QUIC to track the advances (new hardware deployment? new cell tower protocols? etc.) of the internet much faster than TCP.

As a result, I expect QUIC to largely displace TCP, even as QUIC provides any/all technology suggestions for incorporation into TCP. TCP is routinely implemented in the kernel, which makes evolutionary steps take 5-15 years (including market penetration!… not to mention battles with middle-boxes), while QUIC can evolve in the course of weeks or months.

-- Jim (QUIC Architect)

Thanks Jim for the feedback, it's amazing to see the original author of the QUIC protocol respond!

Further reading

If you're looking for more information, have a look at these resources:

Many thanks to Google for leading the efforts here!



Hi! My name is Mattias Geniar. I'm a Support Manager at Nucleus Hosting in Belgium, a general web geek, public speaker and podcaster. Currently working on DNS Spy. Follow me on Twitter as @mattiasgeniar.

I respect your privacy and you won't get spam. Ever.
Just a weekly newsletter about Linux and open source.

SysCast podcast

In the SysCast podcast I talk about Linux & open source projects, interview sysadmins or developers and discuss web-related technologies. A show by and for geeks!

cron.weekly newsletter

A weekly newsletter - delivered every Sunday - for Linux sysadmins and open source users. It helps keeps you informed about open source projects, Linux guides & tutorials and the latest news.

Share this post

Did you like this post? Will you help me share it on social media? Thanks!

Comments

Serge van Ginderachter Monday, August 1, 2016 at 10:59

I’m pretty sure most enterprises never heard of QUIC yet.

Reply


Anselm Hannemann Monday, August 1, 2016 at 11:17

Hey thanks for this interesting explanation of the protocol. Is there any insight yet on if/when other clients will support QUIC, such as Opera, Firefox, Edge, other Blink implementations? And what about Apache and nginx on the server-side? Also, is there a plan on when/if QUIC will be standardized by e.g. the IETF or so?

Reply


Mattias Geniar Monday, August 1, 2016 at 11:23

Google proposed the QUIC protocol to the IETF: https://tools.ietf.org/html/draft-tsvwg-quic-protocol-00

In terms of browsers:
– I’m guessing Chrome will be alone for another year
– Firefox will follow as soon as the IETF SPEC becomes more “final”

As for webservers:
– Nginx will be the first major webserver/proxy to implement QUIC in their mainline repository (= beta channel)
– Apache will follow shortly after with a mod_quic module, similar to their mod_h2 module
– This may be, just like in the case of HTTP/2, the perfect time for “smaller” webservers to gain market share by beating the big players to the implementation.

I like what Caddy is doing by leading the way, I hope many others follow!

Reply


Jason Kiddle Monday, August 1, 2016 at 11:53

Nice.
One typo: ‘Getting it passed security to allow UDP…’ => ‘past’

Reply


Mattias Geniar Monday, August 1, 2016 at 13:56

Well spotted, fixed!

Reply


ms Monday, August 1, 2016 at 14:21

You wrote:
In TCP, packets need to arrive in the correct order.

Are you sure ? wiki say:
Ordered data transfer — the destination host rearranges according to sequence number

Best Regards
ms

Reply


Laurent Oliva Monday, August 1, 2016 at 15:06

Thanks for blogging.

I have a simple question : what about SCP “Session Control Protocol” ?
https://www.w3.org/Protocols/HTTP-NG/http-ng-scp.html

QUIC isn’t it redundant with SCP ?

Reply


zav Monday, August 1, 2016 at 15:11

> It’s implementation is inside the Windows and Linux kernel

Its* implementation is inside

its = the next word or phrase belongs to it
it’s = it is or it has

Reply


Mattias Geniar Monday, August 1, 2016 at 16:31

Corrected, thanks!

Reply


Eduardo Bragatto Monday, August 1, 2016 at 17:07

With UDP amplification DDoS attacks becoming more popular everyday, how does QUIC prevent a fake request with a spoofed IP address from being answered?

Reply


Nairebis Monday, August 1, 2016 at 17:15

Someone mentioned on Reddit that Google Maps gets much faster when you turn off QUIC. I decided to try it, because I’ve actually noticed sometimes Maps hangs and was sometimes slow.

OMG! What a difference! Everything is noticeably snappier. I’ll just repeat a comment I made on Reddit: How did Google screw this up so badly? I’m in Southern California on a 100mb connection, so I should never be having issues with communicating with Google, but QUIC is *clearly* not ready for prime-time and Google should not be pushing this out. It has serious problems in the real world.

I’m just one anecdotal case, but it sure seems like QUIC has some problems.

Reply


Bruce Epper Monday, August 1, 2016 at 17:15

The order in which they arrive is irrelevant, but they can only be processed in sequence number order. So, if a packet is missing, the processing of all subsequent packets will be delayed until the missing packet is successfully received and processed.

Reply


Scott Monday, August 1, 2016 at 19:02

TCP packets must be READ in the correct order by the application,, but do not need to be RECEIVED in the correct order. If a packet is lost, you can not read any further than the lost packet because of this ordering constraint, thus causing the head of line blocking mentioned. It sounds like with quic each connection will have separate channels, and each can be recovered independently thus solving this issue.

Reply


Tsar Bomba Monday, August 1, 2016 at 20:41

If by now they haven’t, I’d have to seriously question their future viability.

Reply


Chris Adams Monday, August 1, 2016 at 23:08

“With QUIC, since it’s now using UDP, there are no quadruplets.” is confusing as written since UDP uses the same source and destination address and port metadata as TCP. The difference, as the next paragraph explains, is that there’s no standard session protocol on top of that and the QUIC authors were free to build something different.

Reply


Jim Roskind Tuesday, August 2, 2016 at 00:50

Nice write up!

Having spent years on the research, design and deployment of QUIC, I can add some insight. Your comment about UDP ports being blocked was exactly my conjecture when we were experimenting with QUIC’s (UDP) viability (before spending time on the detailed design and architecture). My conjecture was that the reason we could only get 93% reachability was because enterprise customers were commonly blocking UDP (perchance other than what was needed for DNS). If you recall that historically, enterprise customers routinely blocked TCP port 80 “to prevent employees from wasting their time surfing,” then you know that overly conservative security does happen (and usability drives changes!). As it becomes commonly known that allowing UDP:443 to egress will provide better user experience (i.e., employees can get their job done faster, and with less wasted bandwidth), then I expect that usability will once again trump security… and the UDP:443 port will be open in most enterprise scenarios.

…also… your headline using the words “TCP/2” may well IMO be on target. I expect that the rate of evolution of QUIC congestion avoidance will allow QUIC to track the advances (new hardware deployment? new cell tower protocols? etc.) of the internet much faster than TCP. As a result, I expect QUIC to largely displace TCP, even as QUIC provides any/all technology suggestions for incorporation into TCP. TCP is routinely implemented in the kernel, which makes evolutionary steps take 5-15 years (including market penetration!… not to mention battles with middle-boxes), while QUIC can evolve in the course of weeks or months.

–Jim (QUIC Architect)

p.s., It is always nice for write-ups to include a link to the document I published about the “Design and Rationale of QUIC.” Though I’m not updating it these days, it provides a lot of underlying thought that supports the many elements of QUIC. The more recent IETF QUIC draft (a.k.a., Google’s QUIC Wire Spec) was derived from that QUIC design document, and offers far less justification and motivation for decisions. For instance, that design document addresses the DDOS Amplification Attack problem that was raised by a reader… and many other things ;-).

Reply


Mattias Geniar Tuesday, August 2, 2016 at 09:05

Hi Jim!

Thanks for leaving a response, it’s great to see the original creator still remain so involved!
I hope you don’t mind, but I added your comment directly in the post for emphasis – I feel it’s of great value to the readers.

I also added additional links to the design documents you mentioned, thanks for the tip.

Take care,

Mattias

Reply


bob Tuesday, August 2, 2016 at 09:20

Why not use multiple TCP connections, one for each resource? instead of creating a new protocol.
TCP has 30+ years of bug fixing against a lot of attacks (spoofing, DoS…)
TCP also automatically adjusts to both the server and the client capabilities (actually to the slowest, more memory/CPU restricted of the two)… thanks to its windowing system (with QUIC, a client that can hold less than 10 frames (think IoT) will start dropping and retransmitting, it just doesn’t happen with TCP!)
Google QUIC adds a redundancy frame every 10 frames: looks good on a LAN or broadband, not so great on a mobile connection. With TCP you don’t retransmit as much as 10% (or TCP wouldn’t be used)
Session resumption seems like a nice idea, but when do you actually need it?
On the LAN/broadband, your IP doesn’t change.
On mobile, I never download large files using my mobile phone/tablet (due to dataplan and slowness). With TCP the next XHR will reconnect using the new roaming IP address. So all in all, session resumption is a gadget feature.
At the end of the day, QUIC seems to improve only for very slow/congested connection, which I believe is a very small amount in developed countries. In these countries where QUIC isn’t useful at all, isn’t it better to improve the existing architecture: the server (use a fast 10k like nginx instead of Apache for example, use gzip…), use efficient caching (there was a good conference by Tim Perry at Voxxed Days (last Feb) on caching BBC Newsbeat) and more importantly optimize the website load time?

Reply


wideem Tuesday, August 2, 2016 at 09:39

Wow! QUIC is so cool! It’s surprising I never even hear about this protocol before your blog post. I tested it and it’s working perfectly for google services, hope that it will be implemented to other web-servers soon

Reply


bob Tuesday, August 2, 2016 at 09:44

It seems useful only for streaming on slow brandwidth… quite a limited use really.

Maybe it’d just be more simple and efficient to categorize resources (static=fast / dynamic=slow) and have a TCP connection per slow resource and one for all the fast resources.

Reply


Joris Schepers Tuesday, August 2, 2016 at 11:55

Reblogged at http://www.itnmore.be/2016/08/02/googles-new-protocol-moving-web-tcp-to-udp/

Added credits to this site

Reply


Adam Zadura Tuesday, August 2, 2016 at 23:15

What about the SCTP? What’s wrong with it? It’s widely used in telecom area.

Reply


Emile van Bergen Wednesday, August 3, 2016 at 14:05

Was DTLS ever considered? (TLS over unreliable datagram services like UDP). Or is QUIC built on top of that?

Reply


Tem Corner Thursday, August 4, 2016 at 07:27

Misspelled “even” in “those connections aren’t event attempted”.

Reply


Mattias Geniar Thursday, August 4, 2016 at 09:08

Fixed that typo, thanks!

Reply


Curious Friday, August 5, 2016 at 07:35

“I find the QUIC protocol to be truly fascinating!”

Sounds like bs to me.

How about just saying “I find the QUIC protocol to be fascinating!”, and stick with that instead of looking like you are lining up for this ironic distancing, by being unclear about what you say.

Reply


Mattias Geniar Friday, August 5, 2016 at 10:11

That’s up for interpretation, but I meant what I wrote in that sentence (without BS or sarcasme): I do find the QUIC protocol fascinating.

Reply


AmaZili Friday, August 5, 2016 at 18:18

Long time ago, we used UDP protocols for file transfers….
So I would guess doors are still wide open in a lot of companies for UDP protocol in their firewall :-)
Since this is a “proven fact” given the current tests, we may see a faster adoption of QUIC than the delivery of HTTP/2 has been.
That’s our hope.

Reply


me@evertpot.com Friday, August 26, 2016 at 03:31

Tiny correction, UUID is not the same as UID.

Aside from that, I think this is one of the best introductions I’ve seen to QUIC and answered a bunch of my questions. Sounds like a major innovation.

Reply


vans163 Friday, August 26, 2016 at 22:44

” they see binary data over the fire ”

Reminded me of The IT Crowd, https://www.youtube.com/watch?v=H3HFOlYba-4.

The error correction is quite impressive, I wonder if there’s more details of how it works.

Reply


Mitra dray Tuesday, November 1, 2016 at 18:44

I dont know if it would be used world widely
But its something ive wondered about many years now (well not every day, but from time to time it came) :)

Sounds exciting . anticipated.

Reply


ktst Saturday, November 5, 2016 at 00:42

Sorry to have to report that this “feature” is apparently causing sluggish responses on my home W10 computers. I am getting “Failed to load resource: net::ERR_QUIC_PROTOCOL_ERROR” in developers console for gmail and google maps. By disabling this feature in chrome://flags/#enable-quic my response times drastically improve and I no longer see the errors. Version 54.0.2840.87 m (64-bit). I am not seeing this behavior on a centos7 vm running Version 56.0.2906.0 dev (64-bit). I would like to know how Google finds out about these issues and how a casual user would be able to find out why his email and maps are sluggish. I initially thought my internet provider was the problem. Related UDP history, we ran 6 bit Airline Link Control over UDP in the 80’s to provide 1.5 second domestic response times across 1200 bps connections serving 45 terminals or printers.

Reply


Moep Tuesday, November 8, 2016 at 08:55

thx for your blog entry very interesting topic

Reply


Aart Wednesday, November 16, 2016 at 00:10

Bob I don’t think you’ve read the article properly.
The benefits are huge and can solve a lot of issues we are facing today.

TCP is latency and packet loss sensitive. UDP is not sensitive to latency and packet loss has limited impact.
Aspera is one of such applications that works over UDP and works very well.
Example: Remote site A has a shared link of 1Gb towards Remote site B. The latency between the sites is 300ms.

TCP will give you around 490Mbps max while UDP can saturate the link.
For a transfer of a 1GB file it will take TCP around 18sec and UDP around 8.5sec.
That’s 2x faster already.
If you add packet loss of 1% you need to wait 5 hours for the 1Gb file to transfer over TCP.

I think most people see use cases for this sort of technology,

Reply


Bennet Saturday, December 3, 2016 at 17:36

Great explanation fellow inhabitant of Belgium :).
There is a small typo just above the figure of QUIC Deployment Experience @Google.
You wrote “I would’ve actually though” and forgot the letter “t” at the end of “thought”.

Reply


Mattias Geniar Sunday, December 4, 2016 at 11:07

Fixed, ty!

Reply


Samuel Smith Tuesday, December 13, 2016 at 04:50

You might be interested in the RAET (Reliable Asynchronous Event Transport) protocol. RAET is a Reliable Secure UDP based protocol designed to support distributed applications and reactive data flow systems. It is not limited to replacing HTTP/TCP.

https://github.com/RaetProtocol/raet
https://github.com/RaetProtocol/raet/blob/master/docs/topics/tutorial.rst

Two production systems now use RAET.

SaltStack
https://github.com/saltstack/raet

Plenum
https://github.com/evernym/p…

Reply


David Redekop Saturday, February 11, 2017 at 22:07

What about UDP reflection attacks? I read through your article but I didn’t see any mention of it. The recent DYN DDOS attack was made possible because of UDP reflection. Compromised host A pretends to be host B and sends a request to host C (only in UDP can you fake the sender). Now enrol a botnet to all pretend to be the same host B where host B is your attack target and it’s one of the easiest attacks to deliver.

I certainly see tremendous value in QUIC and from a defensive security perspective I would probably elect to listen on UDP only if I had an auto-shutdown facility at UDP inbound attack detection.

Reply


pcunite Friday, February 17, 2017 at 16:41

UDP packets can not (to my knowledge) be shaped. This will become a big issue when everyone is starts doing this. So, please don’t.

Reply


Leave a Reply

Your email address will not be published. Required fields are marked *

Inbound links