Thursday, June 27, 2013

[Gd] Experimenting with QUIC

| More

Chromium Blog: Experimenting with QUIC

At Google, we're always working to make the web faster. The SPDY protocol, which is now the foundation of the upcoming HTTP 2.0 protocol, is a significant step forward. However, despite increasing bandwidth, round trip time (RTT)--which is ultimately bounded by the speed of light--is not decreasing, and will remain high on mobile networks for the foreseeable future. To continue improving network performance we need to decrease the number of round trips, something that is difficult with protocols that currently rely on the Transmission Control Protocol (TCP).

QUIC (Quick UDP Internet Connections) is an early-stage network protocol we are experimenting with that runs a stream multiplexing protocol over a new flavor of Transport Layer Security (TLS) on top of UDP instead of TCP. QUIC combines a carefully selected collection of techniques to reduce the number of round trips we need as we surf the Internet. You can learn more in the design document, but here are some of the highlights:
  • High security similar to TLS
  • Fast (often 0-RTT) connectivity similar to TLS Snapstart combined with TCP Fast Open
  • Packet pacing to reduce packet loss
  • Packet error correction to reduce retransmission latency
  • UDP transport to avoid TCP head-of-line blocking
  • A connection identifier to reduce reconnections for mobile clients
  • A pluggable congestion control mechanism
We've been working on both a QUIC client implementation and prototype server implementation in the open source Chromium repository for the past few months. Early tests of UDP connectivity have been promising, but we have learned from past experience that real-world network conditions often differ considerably. Our next step is to test the pros and cons of the QUIC design in the real world by experimenting with using QUIC for a small percentage of Chrome dev and canary channel traffic to some Google servers, just as we did with SPDY. Users shouldn't notice any difference--except hopefully a faster load time. If we're able to identify clear performance wins, our hope is to collaborate with the rest of the community to develop the features and techniques of QUIC into network standards. 

You can learn more about QUIC in our FAQ. Our hope is that what we learn from QUIC will ultimately help us to deliver a much faster... er... QUICker Internet!

Posted by Jim Roskind, RTT Reduction Ranger, Google

No comments: