5 ms·
Five years ago, we built a company around HTTP/2 server push. Here is what we learned: - The interaction of HTTP/2 push with browser caches were left unspecifi
by dsign 6y ago
Five years ago, we built a company around HTTP/2 server push. Here is what we learned:
- The interaction of HTTP/2 push with browser caches were left unspecified for the most part, and browsers implemented different ad-hoc policies.
- Safari in particular was pretty bad.
- Since HTTP/2 Push worked at a different layer than the rest of a web application, our offering centered around reverse-engineering traffic patterns, with the help of statistics and machine learning. We would find the resources which were more often not cached, and push those.
- HTTP/2 Push, when well implemented, offered reductions in time to DOMContentLoaded in the order of 5 to 30%. However, web traffic is noisy and visitors fall in many different buckets by network connection type and latency. Finding that 5% to 30% performance gain required looking to those buckets. And, DOMContentLoaded doesn't include image
loading, and those dominated the overall page loading time.
- As the size of, say, Javascript increases, the gains from using HTTP/2 Push asymptotically tend to zero.
- The PUSH_PROMISE packets did indeed could increase loading time because they needed to be sent when the TCP connection was still cold. At that point in time, each byte costs more latency-wise.
- If a pushed resource was not matched or not needed, the loaded time increased again.
Being a tiny company, we eventually moved on and found other ways of decreasing loading times that were easier for us to implement and maintain and also easier to explain to our customers.
- littlecranky67 6y agoThis and so much this. I also worked with HTTP/2 (when it was still a SPDY draft) and came to the same conclusions: TCP peculiarities (most notably congestion control and its dynamic window scaling) mostly eradicate the benefits of HTTP/2. HTTP/1.1 was using 5-6 different TCP connections (which re-use OS level window scaling caches), while HTTP/2 you had to transfer all resources through a single TCP connection. People often claim HTTP/2 to be superior due to its multiplexing capabilities, but always reason with the mental model of having true stream-based flows and leaving TCP completely out of the argument loop. But guess what, that model is just a model, indeed you have packet-based TCP flows that are abstracted away to mimic a continuous stream as a socket - and those matter.
- im3w1l 6y agoWould it be possible to use a patched TCP stack to start up quicker?
- littlecranky67 6y agosure, this is basically increasing the initcwnd (the initial number of TCP segments allowed to be sent out before you received an ACK from the other end). Linux supports this through the `ip` command (look for initcwnd). This, however, requires root rights and affects the whole network device. Google submitted a patch to the linux kernel that would have allowed tweaking the initcwn from userspace for individual connections; however it got rejected and never made it upstream (for good reasons). See, the problem is, if the initcwnd is set higher on OSes by default, you risk introducing more packet loss, and at the same time reducing everybodys network throughput - if you send more data than the network path to your destination can handle (i.e. full router buffers along the way, more data than client can receive etc.). TCPs congestion control is pretty smart about avoiding congestion or increasing load in already congested networks. So yes, you can set a higher initcwnd, but if everybody was about to increase it by a significant factor, chances are networks become slower for everyone, without anyone benefiting. Long story short, the limitations of TCP for HTTP are known and the major motivation for QUIC (over UDP), that will allow Browser vendors (Google) and server operators (Google, but also other large players like Facebook etc.) to just "give a shit" about others and put as much pressure on the network as they want in order to bring latency down. Once Chrome rolls out with HTTP/3 support, Google couldn't care less what the linux kernel devs or IEEE network engineers have to say.
- im3w1l 6y agoIf I use wired internet, shouldn't it be the ISP's responsibility to throttle / apply backpressure? Like if I'm paying for a certain speed why shouldn't I try my best to make use of it from the start? (I get that mobile internet requires everyone to cooperate to avoid everyone stepping on each others' toes)
- 6y ago
- Thaxll 6y agoBuilding a compagny arround a very specific tech not finalized seems very risky.