11 ms·

Blink: Intent to Remove: HTTP/2 and gQUIC server push

• est31 6y ago
  They quote a study by Akamai, a CDN company. Of course, if you run a CDN then you don't like products that help reduce latency when you don't have a CDN... Server push is most useful in cases where latency is high, i.e. server and client are at different ends of the globe. It helps reduce round trips needed to load a website. Any good CDN has nodes at most important locations so the latency to the server will be low. Thus server push won't be as helpful.
  • jaffathecake 6y ago
    CDNs loved the idea of HTTP/2 push. It's a complicated low level feature. To make it work, you'd need to figure out what to push, and the ideal way to prioritise and multiplex those streams to optimise for first render. CDNs are in the business of knowing this stuff better than anyone else, yet they still couldn't make it work. Remember, most sites using CDNs still go to the root server for HTML and other no-cache content. It's only the more optimised sites that figure out how to deliver those resources straight from the CDN without consulting the end server.
• xyzzy_plugh 6y ago
  This is pretty funny. After all the fuss, turns out that server push isn't really useful. I'm half impressed that they are able to actually admit they were wrong (implicitly of course) by removing it. I can't say I'm surprised, either. I could never think of a reasonable use case for it. With the variety of streaming options available now, it really seems antiquated.
  • stock_toaster 6y ago
    It's too bad they didn't realize it sooner, or it could have been removed from HTTP/3 before IETF finalizes it. Probably too late now?
    • tialaramex 6y ago
      It's currently in Last Call, but if there's consensus to modify HTTP/3 that can be done at any point, although obviously doing it after it's actually published would be in the form of errata or a -bis RFC that modifies the standard. It's not extraordinary for something which has consensus to get done really late, even in AUTH48 (a notional "48 hours" for the authors of the document to fix any last little things that often lasts rather longer than two Earth days) if that's what people decide is necessary. But "Blink doesn't want to do it" isn't consensus on its own, this page suggests other clients implement this and offers no opinion about whether they intend to likewise deprecate the feature.
  • gravypod 6y ago
    Server push is quite useful for bidirectional streaming of data which is heavily used in gRPC to help reduce latency and shovel large amounts of data.
    • Guthur 6y ago
      And the problem there is shoe horning RPC requirements into a hypermedia transport. I feel we've made a big mistake following Google's micro service requirements for what should be a ubiquitous hypermedia back bone. It's bewildering that so many smart people could end up conflating the two for our standard protocols.
    • ahupp 6y ago
      I think this is different than server push like WebSockets; this is all about pushing down resources the server suspects you'll need.
      • josephg 6y ago
        Websockets are different again from both server push and h2 streams. Server push was a feature added in http2 for populating the browser’s cache. Websockets are an http/1.1 extension for tcp-like bidirectional messaging. Server push, websockets, h2 steams and webtransport are all different things.
        • brabel 6y ago
          Don't forget Server Sent Events[1] as well, which is yet another different technology. [1] https://en.wikipedia.org/wiki/Server-sent_events https://en.wikipedia.org/wiki/Server-sent_events
          • techdragon 6y ago
            Yea but unlike http2 push, server sent events were actually useful! You could use it super easily and by holding open a connection and pushing down little json or XML payloads you could build all sorts of things easily in JavaScript. I even saw super basic chat functionally built using two Iframes a form in one and the chat log pushed back from the server as a stream of valid but open ended HTML abusing how lax the browser was about parsing missing certain closing tags at the time. SSE was and still is super easy to use and a very useful option if you can’t or don’t want to shift to web sockets.
  • baybal2 6y ago
    I will be very sceptical about all "real world usage" statistic claims from Google.
    • d2wa 6y ago
      They’re one of very few companies in the world that are in the position to actually measure this.
  • youngtaff 6y ago
    Even before HTTP/2 was standardised there were some strong arguments by Mike Belshe (co-creater of SPDY) and others that we should drop push But it never happened and so made it into the H2 standard
• seanwilson 6y ago
  So instead of pursuing the idea of server pushing your CSS so the top of your page renders fast, the best option is to inline CSS directly into the page but lose caching benefits between pages? Crafting a fast website is going to be messy and difficult for a good while still.
  • stock_toaster 6y ago
    Or use <link rel="preload"> I guess (bonus: local caching still works).
    • seanwilson 6y ago
      You then have to wait for the preload content to arrive before your page starts to display though.
  • userbinator 6y ago
    A "fast website" is super-easy to create if you don't add dozens of megabytes of useless crap to each page. Two decades ago: hardware was slower, bandwidth was far more constrained, and browsers didn't have so many features nor take up so much resources --- and yet the speed of page loading was often much better than it is today! Indeed, most of the "problems" web developers complain about are self-inflicted.
    • AnIdiotOnTheNet 6y ago
      Things weren't just slower, they were orders of magnitude slower. It's ridiculous how we've managed to make computers ludicrously fast and the developer response has been to keep adding garbage until they are slow again.
      • Lorin 6y ago
        Same with disk sizes and game file sizes, it's common to see 60gb+ installs for AAA titles.
• simscitizen 6y ago
  Server push never made any sense anyway for most subresources. The server doesn't know about the state of the browser's cache, so using server push for a subresource could cause it to needlessly push a subresource that was already cached by the browser. Maybe it is useful outside of the browser context, e.g. in gRPC.
  • psanford 6y ago
    gRPC does not use PUSH_PROMISE frames.
  • bawolff 6y ago
    I guess you could see if the client has a cookie, and infer cache state from that.
• The_rationalist 6y ago
  Do web-transport obscolete push? https://w3c.github.io/webtransport/ https://w3c.github.io/webtransport/ I had read a technical comment once that told that HTTP 2 push was superior to websocket but couldn't remember why. Also what's the difference between push and server sent events?
  • johncolanduoni 6y ago
    Web transport isn’t used for transferring HTTP requests/responses by the browser. It’s essentially an expansion of WebSockets to include multiple streams and optional UDP-like delivery, while still being encapsulated in HTTP/3 and suitable to be called by JS. Server sent events similarly only works if you have JS on the client receiving it, the browser doesn’t know how to render the events inherently.
    • peterwwillis 6y ago
      WebTransport is the kind of stuff that makes me lose faith in the capacity for humanity to consciously evolve. It's like your great-great-great-grandparents built a house out of brick. Each new generation there's more people. Everyone wants to live in the same house, but they can't all fit. They try to build the house larger, but it will only work so high with brick. So they start shoving tin and iron and steel into each new floor to reinforce it. Eventually you have a skyscraper where the top floors are built out of titanium, and the bottom floor is several-hundred-years-old brick. But hey, we have a taller building! You could say this is a perfect example of evolution, like big bright red baboon butts. But if the evolution were conscious, we'd want things to improve over time, not just make the same crap scale larger.
      • johncolanduoni 6y ago
        Or maybe, people want to do real-time networking in the browser without having to delve into the mess that is the all-singing, all-dancing WebRTC? Or they want battle tested protocol encryption libraries and flow control in their native app that can do unreliable and out of order delivery? It’s great fun to write these metaphors about HTTP/N and friends, but the last one improved network performance for mobile devices very substantially while half of HN was jeering at it. There are impractical, camel-like, and downright bizarre IETF standards but these are bad examples.
• deleted 6y ago
  [deleted]
• xeeeeeeeeeeenu 6y ago
  Sadly, HTTP 103 hints, which provide a much saner way to preload content, are still unimplemented in all major browsers.
  • xfalcox 6y ago
    And I can't understand why!
  • divbzero 6y ago
    For people like me who are unfamiliar with the proposal, 103 Early Hints [1] would work like this. Client request: GET / HTTP/1.1 Host: example.com Server response: HTTP/1.1 103 Early Hints Link: </style.css>; rel=preload; as=style Link: </script.js>; rel=preload; as=script HTTP/1.1 200 OK Date: Fri, 26 May 2017 10:02:11 GMT Content-Length: 1234 Content-Type: text/html; charset=utf-8 Link: </style.css>; rel=preload; as=style Link: </script.js>; rel=preload; as=script <!doctype html> [... rest of the response body is omitted from the example ...] [1]: https://tools.ietf.org/html/rfc8297 https://tools.ietf.org/html/rfc8297
    • nextaccountic 6y ago
      Do you mean that the same HTTP/1.1 GET request can have two different headers with two different status code? What's the reported status code of this response in typical libraries? Usually the status code is a single value and not a list.
      • banana_giraffe 6y ago
        Yep, two (or more, the spec allows for multiple 103 responses before the "real" response) responses returned from one request. The one library I threw a test server at didn't respond well. It treated the 103 as the response, and the actual 200 as the body. It was an older library, and the spec suggests using client sniffing to pick which clients to send 103 to. That's kinda when I stopped trying to figure it out, I'm not surprised to learn no one really implements it.
      • 6y ago
• Town0 6y ago
  What if on link hover, some javascript code notifies the server and the server pushes the page? When the user clicks the link the page will have already been downloaded. Would that not be possible and useful?
  • divbzero 6y ago
    There are libraries [1] that achieve what you describe. [1]: http://instantclick.io/ http://instantclick.io/ "InstantClick"
    • Town0 6y ago
      Yes and I'd describe them as unpopular hacks. Http2 push is not a hack.
      • ioquatix 6y ago
        Actually... I've implemented both client and server side HTTP/2 push and I'd say... it's a hack and we should deprecate it and remove it from the spec.
        • Town0 6y ago
          Here's another idea: A user is expected to flip quickly through pages after a quick evaluation of each page. Server push makes flipping the pages instant, and the hit rare is 80% at least. Server push is extremely elegant, though it competes with more complex (scripting) approaches which the Valley hipster crowd adores. Usually that crowd lacks any hint of imagination, but they're not the only ones building technology solutions.
    • earthboundkid 6y ago
      Yes, TurboLinks is another library that does this: https://github.com/turbolinks/turbolinks https://github.com/turbolinks/turbolinks
  • K2L8M11N2 6y ago
    “Notifying the server” is already done by browsers by just making a regular request. Prefetching links has been a thing for a while now. You don’t need HTTP/2 to do it.
• rektide 6y ago
  To me, the jury is very much still out on push. It's entirely in-determinate how useful it is, because only a handful of people have stepped up to try. There is a lot of trickery to getting the server to determine what resources to push, that it knows the client needs, but basics like "let's look at the main pages etag to figure it out" got very little experimentation & tries, certainly very few documented. > Chrome currently supports handling push streams over HTTP/2 and gQUIC, and this intent is about removing support over both protocols. Chrome does not support push over HTTP/3 and adding support is not on the roadmap. I am shocked & terrified that google would consider not supporting a sizable chunk of HTTP in their user-agent. I understand that uptake has been slow. That this is not popular. But I do not see support as optional. This practice, of picking & choosing what to implement of our core standards, of deciding to drop core features that were by concensus agreed upon- because 5 years have passed & we're not sure yet how to use it well yet- is something I bow my head to & just hope, hope we can keep on through.
  • toast0 6y ago
    Is there an example of http/2 push being used usefully? I haven't seen one, but would be happy to take a look. If it's not useful, why keep support for it? As I recall, Google added this push in spdy, so it makes sense for them to be the ones to push for it to be removed.
    • rektide 6y ago
      It's good enough for the Web Push Protocol[1], which underpins all the notification systems on the web. This is literally how every notification message that you do not ever accept in to your browser gets delivered. This also highlights the core missing WTF, which is that the server can PUSH a resource, but there is no way for the client page to tell. 5 years latter, we've talked & talked & talked about it[2], but no one has done a damned fucking thing. Useless fucking awful biased development. PUSH gets to be used by the high & mighty. But it's useless to regular web operators, because no one cares about making the feature usable. Now that the fuckwads can declare it's not useful, they're deleteing it. From the regular web. But not from Web Push Notifications. Which will keep using PUSH. In a way that websites have never been afforded. You'd think that if a resource got pushed, we could react to it. These !@#$@#$ have not allowed that to happen. They have denial of serviced the web, made this feature inflexible. Sad. So Sad. Even without the reacting to push, it seems obvious that there's just more work to do. That we haven't made progress in 3 years just seems like infantile terrible perception of time, of what the adoption curve looks like. A decade for critical serious change to start to take root is fine. The expectation for progress & adoption is way out of whack. So so sad. Everything is so wrong. You can't just unship the web like this. You need to support the HTTP features we agreed we wanted to create. None of this is happening. I hate what has happened to PUSH so bad. This is so critically terribly mismanaged, the browsers standards groups have fucked this up so so so bad, done so little, had such attrocious mismanagement of what the IETF wanted to do. It's embarassing. We are terrible, we have screwed the pooch so bad on this so many times, & pulling the plug is a colossal fuck up of unbelievable proportions, fucking up a very basic promise that we ought have made for the web, the ability to push things, that never got delivered in to any useful ability on the web to do anything about it. Fuck up, 1000000x fuck up, just fucking shit balls terrible work everyone. This one issue causes severe doubt in humanity for me. This is a fucked up terrible thing for all humanity, for the web. I can't believe we were so terrible at this. [1] https://developers.google.com/web/fundamentals/push-notifications/web-push-protocol https://developers.google.com/web/fundamentals/push-notifica... [2] https://github.com/whatwg/fetch/issues/65 https://github.com/whatwg/fetch/issues/65
• colinclerk 6y ago
  I'm surprised about the timing. The serverless/edge technologies becoming available at CDNs are making it easy to imagine "automatic push" could come soon. Any chance there are folks from Vercel or Netlify here and can shed light on why push hasn't been implemented in their platforms (or if it has)? At first glance, it seems like Next.js in particular (server rendering) is ripe for automatic push.
  • cagenut 6y ago
    you can push now using headers or custom vcl with fastly: https://docs.fastly.com/en/guides/http2-server-push https://docs.fastly.com/en/guides/http2-server-push
• _bjh 6y ago
  This is odd, since I thought Akamai was working on LL-HLS, and the spec recommends the use of HTTP/2 server push for periodic playlist updates.
  • sanxiyn 6y ago
    The post does say: > It is interesting to note that server push has been used in ways other than originally intended. One prominent example is to stream data from the server to the client, which will be better served by the upcoming WebTransport protocol.
  • elithrar 6y ago
    LL-HLS removed HTTP/2 Server Push from the spec back in January: https://mux.com/blog/low-latency-hls-part-2/ https://mux.com/blog/low-latency-hls-part-2/ This was driven by poor server + client support at large, and the complexity it introduced. LL-HLS instead uses byte ranges and open-ended ranges over HTTP/2 - almost Comet-style - to handle CMAF chunks.
• francislavoie 6y ago
  Well that sucks. Caddy has supported HTTP/2 push for a very long time (except for a few months after v2 was released since it was a total rewrite). https://caddyserver.com/docs/caddyfile/directives/push https://caddyserver.com/docs/caddyfile/directives/push
  • londons_explore 6y ago
    I just finished 3 weeks implementing server push for my web app which cuts typical load times in half :-(. I guess I'll have to go back to putting all the images base64 encoded into the html :-(
    • kevincox 6y ago
      Depending on how big your pages are and how fast they are generated preload is probably a better alternative. Instead of pushing the images just set headers for the images above the fold: Link: </img/1.jpg>; rel=preload; as=image The browser will then request the images it doesn't have cached already. The advantage to this method is that the browser can look up the images in its cache first and avoid transferring unnecessary data. The downside is that it will take at least one round trip for the browser to request them. So if your HTML is short and quick to generate the connection might go idle before your receive these requests.
      • kdunglas 6y ago
        Actually you should use Link: </img/1.jpg>; rel=preload; as=image; nopush Or it's likely that the web server will transform this hint in a Server Push (it's supported out of the box by Apache, NGINX, CloudFlare...).
        • kevincox 6y ago
          "should" is a strong word. If you have a very short and fast HTML page you might want to start pushing the assets just in case the user doesn't have them cached. But yet, the choice is yours. I wonder if the proxies would consider some sort of hybrid mode where they proactively fetch the link header and cache it (if it isn't already cached) but don't push it to the client. I can't find any indication that this has been implemented or considered anywhere. Of course if your edge was much closer to the user the the origin it wouldn't have much benefit. But it would still be nice.
• yc12340 6y ago
  HTTP/2 server push is odd. When you can get the most benefit out of it, you usually don't care, because your resources are small and load quickly anyway. And when you care (because your resources are big don't load quickly enough), HTTP push actually hurts you, because you are pushing the same big resource on every page load. I have tried to use it once, and the hassle of distinguishing between first time visits and repeated visits is simply not worth it. Even the hassle of using <link rel="preload"> is usually not worth it in large apps — if you have time for that, it can be better spent on reducing size of assets.
  • FeepingCreature 6y ago
    > your resources are small and load quickly Size is only semi-related to latency. For small resources, latency costs dominate. That's what push addresses.
  • londons_explore 6y ago
    I think the benefits are where some automated system writes your "preload" entries for you. For example, a webpack stage could render inside a sandbox each page of your site, detect which resources get loaded, and add all of those as preload/server push entries. The server itself can keep records of which resources have been pushed to a specific client, and not push them again. Writing preload lists by hand is never going to scale with today's web apps with hundreds or thousands of requests for a typical page.
• jaffathecake 6y ago
  I think this is the right decision. I looked at HTTP/2 push in 2017 and the design is very confusing, and the implementations are pretty bad. https://jakearchibald.com/2017/h2-push-tougher-than-i-thought/ https://jakearchibald.com/2017/h2-push-tougher-than-i-though.... Chrome's implementation was best, but the design of HTTP/2 push makes it really hard to do the right thing. Not just when it comes to pushing resources unnecessarily, but also delaying the delivery of higher priority resources. <link rel="preload"> is much simpler to understand and use, and can be optimised by the browser. Disclaimer: I work on the Chrome team, but I'm not on the networking team, and wasn't involved in this decision.
  • throwaway189262 6y ago
    Agree 100% . I never saw a use for server push. I'm glad to see unused features go, web browsers are far too bloated already. The web would be fine if they stopped adding features today for the next 10 years. The massive complexity of the browser will eventually be a detriment to the platform
    • DarkWiiPlayer 6y ago
      When Server Push became a thing, I liked the idea quite a lot, and I find it somewhat sad to see it disappear again, but realistically speaking, it wasn't used that much, so it might be for the best to just let it go.
      • cogman10 6y ago
        The big issue with it, IMO, is it simply doesn't work with load balancers. You HAVE to have sticky sessions which, unfortunately, really limits some of the best benefits of http2.
  • locallost 6y ago
    thanks for that post. that and some other resources convinced me then that my time is better spent elsewhere. in the post it says less then .1% connections in Chrome receive a push event. some people will always try out the cutting edge, but the fact it hasn't spread after several years is a pretty good indicator that it's not producing the expected results. I don't know why things that are "nice to have, but not essential" and at the same time not really working need to be kept, just because they're in a standard. if it was essential I'd view it differently, but in this case I hope it gets dropped.
• FeepingCreature 6y ago
  Why doesn't the client keep a bloom filter of already-requested URLs on that website and send it along to the server on the first request? That way, you'd get the less-space benefit of link rel, but the latency benefit of push. Also, this is very Google: "Well, few people have adopted it over five years, time to remove it." HTTPS is almost as old as HTTP and is only now starting to become universal. Google has no patience, seriously.
  • londons_explore 6y ago
    The bloom filter seems like the obvious solution! I even spent the best part of a week back in 2017 trying to build a bloom filter into Chrome's HTTP cache so each connection could send to the server a tiny filter of the resources already cached, and then the server could send back a package of "everything needed to render the page you have requested". Turns out the HTTP cache is complex so I gave up. If fully implemented, it ought to be able to cut render times dramatically, and to eclipse the performance benefit of cdn's (where the main benefit is reducing latency for static assets). There are potential privacy concerns, but no moreso than first party cookies.
  • sanxiyn 6y ago
    Bloom filter is indeed a sufficiently obvious idea that it got already proposed. But it wasn't accepted and was expired in 2019. See Cache Digests for HTTP/2. https://tools.ietf.org/html/draft-ietf-httpbis-cache-digest-05 https://tools.ietf.org/html/draft-ietf-httpbis-cache-digest-...
• tannhaeuser 6y ago
  What? Multiplexing HTTP and other traffic was the entire argument justifying HTTP/2 and 3 complexity with multistatus etc. That server push was never going to work was clear from even a cursory look at the protocol spec and a minimal use case involving two subsequent page loads with shared resources. Was it really necessary for Google to foobar HTTP?
• 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 ago
    This 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 ago
• randomtree 6y ago
  HTTP/2 Push allows to _really_ optimize first page load, giving a wow effect. (Especially when you can use a single server w/o geodns to serve the whole world with a really low latency!) I use it on my pet project website, and it allows for a remarkable first page load time. And I don't have to make all these old-school tricks, like inlining CSS & JS. HTTP/2 Push allows for such a pleasant website development. You can have hundreds of images on the page, and normally, you'd be latency-bound to load it in a reasonable amount of time. And the way to solve it old-school is to merge them all into a one big image, and use CSS to use parts of the image instead of separate image URLs. This is an ugly solution for a latency problem. Push is so much better! The fact that 99% of people are too lazy to learn a new trick shouldn't really hamstring people into using 30-year old tricks to get to a decent latency!
  • aitchnyu 6y ago
    Would inlining CSS and JS work on web sites (not apps)? I kinda feel inlined JS will bypass bytecode cache and the parsing costs have to be paid on each page load.
    • randomtree 6y ago
      Yep, inlining only optimizes first page load.
      • earthboundkid 6y ago
        The whole point of this discussion is that push only optimizes the first load, and then it pessimizes all subsequent loads. That's why no one adopted it.
    • sanxiyn 6y ago
      Inlined scripts do get cached, but cache is keyed to document's URL. Go https://v8.dev/blog/code-caching-for-devs https://v8.dev/blog/code-caching-for-devs and search for "inline".
  • darkwater 6y ago
• kdunglas 6y ago
  Server Push has a use case for web APIs. I just published a benchmark showing that under certain conditions APIs using Server Push (such as APIs implementing the https://vulcain.rocks https://vulcain.rocks specification) can be 4x times faster than APIs generating compound documents (GraphQL-like): https://github.com/dunglas/api-parallelism-benchmark https://github.com/dunglas/api-parallelism-benchmark They key point for performance is to send relations in parallel in separate HTTP streams. Even without Server Push Vulcain-like APIs are still faster than APIs relying on compound documents thanks to Preload links and to HTTP/2 / HTTP/3 multiplexing. Using Preload links also fixes the over-pushing problem (pushing a relation already in a server-side or client-side cache), some limitations regarding authorization (by default most servers don't propagate the Authorization HTTP header nor cookies in the push request), and and is easier to implement. (By the way Preload links were supported from day 1 by the Vulcain Gateway Server.) However, using Preload links introduce a bit more latency than using Server Push. Does the theoretical performance gain is worth the added complexity? To be honest I don't know. I guess it doesn't. Using Preload links combined with Early Hints (the 103 status code - RFC 8297) may totally remove the need for Server Push. And Early Hints are way easier than Server Push to implement (it's even possible in PHP!). Unfortunately browsers don't support Early Hints yet. - Chrome bug: https://bugs.chromium.org/p/chromium/issues/detail?id=671310 https://bugs.chromium.org/p/chromium/issues/detail?id=671310 - Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1407355 https://bugzilla.mozilla.org/show_bug.cgi?id=1407355 For the API use case, it would be nice that Blink adds support of Early Hints before killing Server Push!
  • littlecranky67 6y ago
    I'm sorry to disappoint you, but your benchmark methodology is flawed. You did not consider TCP congestion control/window scaling. TCP connections between to peers are "cold" (=slow) after the 3-way handshake, and it takes several roundtrips to "warm" them up (allow data to be sent at a level that saturates your bandwidth). The mistake you (and most other people performing HTTP load benchmarks) made, is that the Kernel (Linux, but also all other major OS Kernels) caches the state of the "warm" connection based on the IP adress. So basically, when you run this kind of benchmark with 1000 subsequent runs, only your first run uses a "cold" TCP connection. All other 999 runs will re-use the cached TCP congestion control send window, and start with a "hot" connection. The bad news: For website requests <2MB, you spend most of your time waiting for the round-trips to complete, say: you spend most of the time warming up the TCP connection. So its very likely that if you redo your benchmarks clearing the window cache between runs (google tcp_no_metrics_save) you will get completely different results. Here is an analogy: If you want to compare the acceleration of 2 cars, you would have race them from point A to point B starting at a velocity of 0mph at point A, and measure the time it takes to reach to point B. In your benchmark, you basically allowed the cars to start 100 meters before point A, and will measure the time it takes between passing point A and B. Frankly, for cars, acceleration decreases with increasing velocity; for TCP its the other way around: the amount of data allowed to send on a round trip gets larger with every rountrip (usually somewhat exponentially).
• bullen 6y ago
  I'm going to sound like a broken record but HTTP/1.1 comet-stream works fine, just use "transfer-encoding: chunked" header in your response, write the length in hex followed by \r\n and then write the content with trailing \r\n\r\n, rinse and repeat. It's simple, debuggable, inherently avoids cache-misses, scales (if you use non-blocking IO and joint concurrent capable language with OS threads). It also avoids HTTP/TCP head-of-line because you're using a separate socket for your pushes.