This YouTube video does a great job illustrating how well HTTP/2 works in practice.<p><a href="https://www.youtube.com/watch?v=QCEid2WCszM" rel="nofollow">https://www.youtube.com/watch?v=QCEid2WCszM</a><p>A lesser known *ownside to HTTP/2 over TCP solution was actually caused by one of the improvements - a single reusable (multiplexed) connection - that could end up stalled or blocked due to network issues. This behavior could go unnoticed over the legacy HTTP/1.1 connections due to browsers opening a hugh number of connections (~20) to a host, so when one would fail it wouldn't block everything.
What a great case study. Successfully shifting 80% of mobile traffic to QUIC for a 50% reduction in latency is amazing. QUIC and the ongoing work with multipath TCP/QUIC will be huge QoL improvements for mobile networking.
Experiment 1<p><i>While we used the NGINX reverse proxy to terminate TCP, it was challenging to find an openly available reverse proxy for QUIC. We built a QUIC reverse proxy in-house using the core QUIC stack from Chromium and contributed the proxy back to Chromium as open source.</i><p>Experiment 2<p><i>Once Google made QUIC available within Google Cloud Load Balancing, we repeated the same experiment setup with one modification: instead of using NGINX, we used the Google Cloud load balancers to terminate the TCP and QUIC connections...<p>Since the Google Cloud load balancers terminate the TCP connection closer to users and are well-tuned for performance, the resulting lower RTTs significantly improved the TCP performance.</i>
I recently moved and got internet with Spectrum. A 200/10 service yet my upload speeds were rarely above 5mbit. This was a business account with some web and dev servers behind it. I didn't even try to call customer service...<p>With a little more testing using UDP, I could see I was getting very spotty packetloss (<0.5%). I'd never tried changing the TCP algo before but I knew random packetloss is normally interpreted as congestion and hence causes a speed backoff.<p>I tried all of the ones available at the time but the one that stood out not only in performance but also simplicity was TCP-Illinois[0]. The stats provided by `ss -i` also seemed the most accurate with TCP-Illinois. I force enable it on every machine I come across now.<p>0:<a href="https://en.wikipedia.org/wiki/TCP-Illinois" rel="nofollow">https://en.wikipedia.org/wiki/TCP-Illinois</a>
Tcp was build for the internet long ago, even though there are changes added, the architecture of the protocol make it hard to do anything drastic. With UDP because it is so simple, you can basically create a new protocol on top, inside the payload and emulate TCP if you wanted to
I wish the mandated minimum MTUs of IP were just a bit bigger. Ubers traffic must be so transactional, they could really just use individual UDP packets for most messaging.
Isn't TLP[0] supposed to fix the largest cause (tail losses) of this issue? It should result in retransmits far sooner than the 30 seconds they mention.<p>> Recently developed algorithms, such as BBR, model the network more accurately and optimize for latency. QUIC lets us enable BBR and update the algorithm as it evolves.<p>Again this is available for TCP in recent linux kernels[1]. And it's sender-side, so it should be unaffacted by ancient android devices.<p>Are they using ancient linux kernels on their load balancers? Or are the sysctl knobs for these features turned off in some distros?<p>[0] <a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6ba8a3b19e764b6a65e4030ab0999be50c291e6c" rel="nofollow">https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...</a>
[1] <a href="https://kernelnewbies.org/Linux_4.9#BBR_TCP_congestion_control_algorithm" rel="nofollow">https://kernelnewbies.org/Linux_4.9#BBR_TCP_congestion_contr...</a>
I thought DDOS prevention was difficult with udp, compared to TCP. Is it not the case anymore. Does cloudflare provide DDOS prevention for QUIC/UDP.
I'm surprised the "alternatives considered" section doesn't have a "write something custom for core functionality using UDP". I would be curious to read why the decided not to go that way, given their scale and the potential gains from not using a general-purpose protocol.<p>(Something like, make the entire standard journey from opening to the app to requesting a car over something custom, and then leave the rest of the app using TCP)
This kind of latency improvement only matters if they are planning to do auto-pilot from the cloud? (that would be crazy, especially if they don't have a fallback)