https://www.youtube.com/watch?v=QCEid2WCszM
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.
Generally images are the lowest priority download, so ensuring higher priority items get downloaded first is important and not all H2 implementations do it well
Our current load balancer doesn't support HTTP2 end-to-end (and we are dong gRPC), so we are load balancing TCP connections to the individual instances. And for certificates, we would use SANs to reduce the number of certificates being requested.
Put those two together, and browsers will assume that the first connection they make to serviceA.example.com can also be used for serviceB.example.com. Oops!
TLDR, certificates for HTTP2 need to be unique to each endpoint that terminates a browser connection.
basically we have a gitlab instance at IP .8 / external at .210 and a nexus instances at .210 internally/externally however we have IPv6 addresses pointed at gitlab.
In firefox sometimes you could end in the wrong location and I had no idea why that was happening. it just failed. And only in firefox.
(btw. the behavior of firefox is just stupid. https://bugzilla.mozilla.org/show_bug.cgi?id=1190136)
If the server_name is established in the TLS session handshake, the client SHOULD NOT attempt to request a different server name at the application layer.
Yeah, looks like the browsers are allowed to do that, although it's not recommended.
any kind of packet loss kneecaps the performance of the whole thing, unlike http1.1.
FWIW, I work on the Netflix CDN, and specialize in server-side efficiency; we have had 100G flash CDN nodes for years serving at 90G+ in production. None of that would be possible with QUIC as it stands. I suspect our max B/W on these machines would drop from ~95Gb/s to 20Gb/s or less if we were to switch to QUIC.
I was dissapointed that the article didn't get into any details about the HTTP-level differences, but I think that's basically because they didn't need to know or care about the transport at that level since they were using Google's "cronet" library to dispatch the requests, and Google Cloud Load balancers as the QUIC termination point, so nothing on their ends actually deals with the neccessary differences from HTTP/2.
> 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.
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.
Are they using ancient linux kernels on their load balancers? Or are the sysctl knobs for these features turned off in some distros?
[0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... [1] https://kernelnewbies.org/Linux_4.9#BBR_TCP_congestion_contr...
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.
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.
(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)
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.
Experiment 2
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...
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.
