|
|
|
|
|
|
by comex
4078 days ago
|
|
|
The first diagram, if I'm interpreting it correctly, shows two whole round trip times shaved off compared to TCP + TLS, and one compared to plain TCP (which is basically no longer acceptable). For a newly visited site, that becomes one and zero. The 100ms ping time in the diagram may be pretty high for connections to Google, with its large number of geographically distributed servers, but for J. Random Site with only one server... it's about right for US coast-to-coast pings, and international pings are of course significantly higher. [1] states that users will subconsciously prefer a website if it loads a mere 250ms faster than its competitors. If two websites are on the other coast, have been visited before, and are using TLS, one of them can get most of the way to that number (200ms) simply by adopting QUIC! Now, I'm a Japanophile and sometimes visit Japanese websites, and my ping time to Japan is about 200ms[2]; double that is 400ms, which is the delay that the same article says causes people to search less; not sure this is a terribly important use case, but I know I'll be happier if my connections load faster. Latency is more important than people think. [1] http://www.nytimes.com/2012/03/01/technology/impatient-web-u... [2] http://www.cloudping.info |
|
|
How does this work?
As a total guess, I assume the client gets a stream of packets, buffers them all up, waits for some threshold before re-requesting any missing sequence numbers. When that missing packet comes back in (all while the stream continued) with its new number, it puts in in place, and pushes the data up to the application and clears it's buffer. Client probably sends "I'm good up to sequence n" every once and a while so the server can clear it's re-transmit buffer.
That's pretty cool. Treat it as a lossy stream, rather than a "OH CRAP EVERYBODY STOP EVERYTHING, FRED FELL DOWN!". With this, FRED IS DED!