Category: CommunityNot Satisfied With SPDY, Google Aims To Reduce Layer 4 Latency With QUIC

Share this post...Tweet about this on TwitterShare on Google+0Share on Facebook0

SPDY QUICWe’ve talked about SPDY on this blog before. Originally developed to improve the performance of web connections at the application layer (Layer 7), SPDY implemented techniques to make connection and data transmission suitable for the modern web, including multiplexing of connections, server push, and header compression. SPDY has been absorbed into the development process of HTTP 2.0, which is likely to be submitted as a proposed standard at the end of this year.

Although it is a welcome progression, SPDY and HTTP 2.0 aren’t enough to make a significant improvement to latencies. Lengthy round-trip times remain a problem that can’t be fixed in the application layer. To tackle the problem of round-trip times, Google have directed their attention to the transport layer (Layer 4) and the Transmission Control Protocol (TCP).

QUIC, Quick UDP Internet Connections, is a new protocol intended to solve the problems with TCP.

Reduced Round-Trip Times

Not even Google can change the speed of light: the fundamental cause of round-trip times. Instead, Google wants to get rid of round-trip times altogether. TCP makes a connection and then waits for a response before sending more data. Creating an encrypted TLS connection takes extra round trips. QUIC makes its initial connection and then immediately sends data without waiting for a response — there is no round trip at all. It will rely on packet-level error correction to reduce the impact of lost packets.

Better Multiplexing

SPDY uses multiplexing to send several streams of data over one connection. TCP wasn’t designed with this in mind. When a packet from the TCP connection underlying multiplexed streams is dropped, all the streams stall. One of the reasons that QUIC is using UDP instead of TCP is so that it can implement out-of-order packet delivery. Dropped packets will impact only one of the multiplexed streams rather than making all of them wait.

Bandwidth Estimation To Reduce Packet Loss

QUIC is able to estimate the bandwidth at both ends of the connection and pace packet sending to reduce the number of dropped packets.

Encryption

QUIC includes a cryptographic protocol similar to TLS but more efficient. According to Google’s documentation, QUIC handshakes should be around 5 times more efficient than TLS handshakes and provide better security.

Will We See QUIC Gain Widespread Adoption Soon?

It’s unlikely that QUIC is going to be implemented widely any time soon. TCP is baked into most of the operating systems that underlie network infrastructure and run client devices. QUIC is an experimental protocol for Google to test ideas. Google chose UDP because they can’t reasonably modify TCP, but it’s possible that in the future many of the insights that are gleaned from QUIC will be applied to future iterations of TCP.

Image: Flickr/donkeyhotey

ServersSystem AdministrationWeb Server
Aug 13, 2014, 12:29 pmBy: Corey Northcutt (0) Comments

Leave a Reply
Surround code blocks with <pre>code</pre>

Your email address will not be published.

Newsletter

Sign up to receive periodic InterWorx news, updates and promos!

New Comments

Current Poll

  • This field is for validation purposes and should be left unchanged.

Forum Posts