Google Chrome uses QUIC to boost transfer speeds

chrome_compQUIC is a new transport protocol being developed by Google. It is experimental at the time of writing and aims to reduce the data transfer latency over TCP+TLS+SPDY. TCP being a very well-established protocol, and most of the time implemented by the operating system, Google couldn’t change it significantly. However, it developed QUIC, which is based on UDP and has plans to propose HTTP-2 over QUIC as the new standard to IETF.


  • Dramatically reduced connection establishment time: QUIC handshakes frequently require zero roundtrips before sending payload, as compared to 1-3 roundtrips for TCP+TLS.
  • Improved congestion control: has pluggable congestion control, and provides richer information to the congestion control algorithm than TCP. For example, each packet, both original and retransmitted, carries a new sequence number. This allows a QUIC sender to distinguish ACKs for retransmissions from ACKs for originals and avoids TCP’s retransmission ambiguity problem.
  • Multiplexing without head of line blocking: QUIC is designed from the ground up for multiplexed operation, lost packets carrying data for an individual stream generally only impact that specific stream..
  • Forward error correction: In order to recover from lost packets without waiting for a retransmission, QUIC can complement a group of packets with an FEC packet. Much like RAID-4, the FEC packet contains parity of the packets in the FEC group.
  • Connection migration: connections are identified by a 64 bit connection ID, randomly generated by the client. On the event of an IP address change, a QUIC client can continue to use the old connection ID from the new IP address without interrupting any in-flight requests.

To check out how Chrome is using QUIC, try the HTTP/2 and SPDY indicator extension.

Leave a Reply

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