[Cryptography] replacing the whole sodding lot
ianG
iang at iang.org
Mon May 4 20:09:34 EDT 2015
One of the snarky predictions I made to the SSL/PKI/CA cabal when they
refused to respond to security issues was that at some point the whole
lot would be replaced. It took a while, but there are now some green
shoots. This is spectacularly good, and I will say that all of the
nasty things I've said about this company are forgiven. I'll still say
them, but ALL is FORGIVEN:
https://blog.chromium.org/2015/04/a-quic-update-on-googles-experimental.html?m=1
A QUIC update on Google’s experimental transport
Last year we announced QUIC, a UDP-based transport protocol for the
modern Internet. Over the last quarter, we’ve been increasing the
amount of traffic to Google services that is served over QUIC and
analyzing QUIC performance at scale. Results so far are positive, with
the data showing that QUIC provides a real performance improvement over
TCP thanks to QUIC's lower-latency connection establishment, improved
congestion control, and better loss recovery.
For latency-sensitive services like web search, the largest gains come
from zero-round-trip connection establishment. The standard way to do
secure web browsing involves communicating over TCP + TLS, which
requires 2 to 3 round trips with a server to establish a secure
connection before the browser can request the actual web page. QUIC is
designed so that if a client has talked to a given server before, it can
can start sending data without any round trips, which makes web pages
load faster. The data shows that 75% percent of connections can take
advantage of QUIC’s zero-round-trip feature. Even on a well-optimized
site like Google Search, where connections are often pre-established, we
still see a 3% improvement in mean page load time with QUIC.
Another substantial gain for QUIC is improved congestion control and
loss recovery. Packet sequence numbers are never reused when
retransmitting a packet. This avoids ambiguity about which packets have
been received and avoids dreaded retransmission timeouts. 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. This means less time spent staring at the spinner and more time
watching videos.
Where do we go from here? Today, roughly half of all requests from
Chrome to Google servers are served over QUIC and we’re continuing to
ramp up QUIC traffic, eventually making it the default transport from
Google clients — both Chrome and mobile apps — to Google servers. We
plan to formally propose QUIC to the IETF as an Internet standard but we
have some housekeeping to do first, like changing the wire format and
updating our reference implementation from SPDY-over-QUIC to
HTTP2-over-QUIC. In the coming months, we also plan to work on lowering
handshake overhead to allow better server-side scalability, improving
forward error correction and congestion control, and adding support for
multipath connections.
More information about the cryptography
mailing list