ID:2151809
 
Applies to:Everything
Status: Open

Issue hasn't been assigned a status value.
Ok, so this is more of a Pie In The Sky idea then when domino's pizza started to literally put pies in the sky, but here it goes.


QUIC stands for Quick UDP Internet Connections, and is basically a layer on top of udp to do what tcp does that is useful that udp doesn't have, while not having all the baggage that tcp has and over all being better.

The biggest benefit is multiplexing, one "connection" can have multiple streams or channels, each with their own sequence checking and head of line blocking queue. So resource downloads could instead use a new stream for each file. The seperate "queue" you use for browse/browse_rsc could be removed and just be a stream where rather then check the queue and send things down the line one at a time waiting for a reply, you send it all down the line under the same stream for that client, and let quic handle ensuring order. A delayed or resent packet on one stream does not block the other streams, so by splitting up network code in to parts that don't actually rely on eachother, you can reduce latency spikes causing the whole connection to get delayed while stuff is resent.

Other benefits:

Forward Error Correction: Packets can contain parity bits for other packets, allowing for a dropped or garbled packet to be reconstructed from later packets without a packet re-transmission, lowering on latency shuttering.

Connection migration: The client can change IPs (from changing between wifi and data on a mobile phone or a dhcp re-lease on home routers) without losing the connection (optional)

Everything google uses QUIC (all of their websites, including youtube and backend data transfers like youtube streams/gmail ajax queries), mainly for them the session resuming, on connection you can just start sending data before waiting for the connection ack and resend it again if the connection needs to be (re-)negotiated. Chrome and firefox both support using QUIC instead of tcp for sites that request it.

It's designed around use for http, but thats not required, and it is at the core, a new transport layer that layers over udp. http://www.chromium.org/quic

Merge that with http/2 for the website stuff (and the webclient since http/2 allows you to start sending resources before the client requests them) and you should have one super optimized network setup.