- GDoc: QUIC at 10k feet
- Medium: Why quick is not the next big thing
- YTVideo:QUIC: Replacing TCP for the Web by Jana Iyengar(2018)
- YTVideo:QUIC: in Theory and Practice - Robin Marx | DeltaV 2018
- YTVideo:Fixing HTTP/2 and preparing for HTTP/3 over QUIC - Robin Marx | O'Reilly Velocity Berlin 2019
- YTVideo: HTTP/3 and QUIC: the detials by Robi Marx (2019)
- GH: Implementations
- QUIC - Quick UDP Internet Connections
- PN - Packet Number
- AV - Attack Vector
- RTT - Round Trip Time (Or RTD(elay))
- ACK - Packet type (inTCP) or acknowledgement.
QUIC is "new" protocol that has been developed by google and is used by google to replace TCP + TLS + HTTP/2. and gives us QUIC/HTTP3.
There are multiple solutions that have accumulated over couple of years of TCP, that can not be deployed to the TCP because of its popularity. Also we can't deploy totally new protocol, because all the network infrastructure needs to support it, in order for it to work.
So what QUIC does is - build networking protocol on top of UDP. There are several downsides to this, but allows QUIC protocol to rapidly evolve because it is on the application layer instead of transport layer. (where things are sometimes built in the hardware)
- 1 or 0 RTT for request (Quick connection establishment).
- Send key for this session and next one as well. (Cache on server & client)
- 0-RTT - can have replay attacks (So avoid state-changes on backend)
- packet encryption + separate payload encryption
- Avoid middlebox ossification (they cant see content, cant do shit)
- Allows for protocol upgrades (middlebox wont do nasty shit)
- Dissallows company firewalls filtering/securing networks ?? (BS??)
- Optimized packets/Minimize overheads.
- After long packets, subsequent packets remove redundant data
- VarLen ints..
- "Seemless" network switching.
- Client/Server IDs (Not encrypted) - Resume the same connection.
- For privacy reasons server and client can share multiple IDs.
- Server can even encode LoadBalancer->InternalNode number or ProcessID.
- Of course they will encrypt these. :P
- Multiplexing against Head-of-line blocking.
- No strict ordering of streams!
- Better congestion control than TCP.
- Forward Error Correction
- Dynamic Packet Numbers that can be sent with DELTA(s) based on
acknowledgment, this way we save size for huge packet numbers.
- Even on retransmissions you always get new PN, so you
can drop packets with the same PN.
- AV?: Send packet with PN before user?
- Even on retransmissions you always get new PN, so you
can drop packets with the same PN.
- Better prioritization ? (May have been dropped from the spec?)
- No strict stream order, means no way to strictly define priorities over the streams.
- Possible solution: Control stream (That is always sync.)
- Does this lead to HOL again?
- Better push implementation than HTTP/2.
- Can minimize overhead with DUPLICATE_PUSH?
- Possible solution: 7 layered priority pushes.
- QLOG is good logging mechanism implemented by several clients
(can no longer pcap/wireshark because of encrypted packets)
- Has pretty neat visualizations, that can even track server state.
- UDP Related issues
- UDP Throttling in some middleboxes
- UDP syscalls are not optimized currently (CPU Overhead).
- UDP is blocked by several Router/ISP/Middleboxes, so you need to fallback.
- How do you figure out if server supports QUIC or not?
- Try TCP + QUIC in parallel?
- Connect to TCP to figure out server support ?
- Maybe use DNS to announce server QUIC support ?
- Cache servers that have QUIC support for 0-RTT benefits.
- How do you figure out if your ISP/Router allows QUIC?
- Cache network <=> server mapping when it succeeded in the past?
- Latency measurements can happen with ACK delays, where you specify the granularity of the measurement (negotiate) and measure: time taken from the packet + time spent between receiving and sending back the ack. Server can in the end know the latency of the connection.
- Several DOS mitigations implemented. E.g. It only allows 3x amplification.