5 ms·

Http 1.1 is still awesome. Even with all the incoming changes on front-end like js modules and all that, it feels a great fit that is also simple and reliable.

Http 1.1 is still awesome. Even with all the incoming changes on front-end like js modules and all that, it feels a great fit that is also simple and reliable. Not only that but in a way http 1.1 makes http 2.0 look like the typical over-engineering approach to a non-existing problem, for the most part.

Jonnax 6y ago
The problem doesn't exist for you. But plenty of people have high latency internet connections. Either due to technology (Mobile network, satellite) or due to them being very far from internet exchanges and the server's they want to connect to. Here is an example of the speed advantage on a low latency connection: https://youtu.be/QCEid2WCszM https://youtu.be/QCEid2WCszM Of course with my 1gbps broadband in a capital city both are pretty much instant when doing the test: https://imagekit.io/demo/http2-vs-http1 https://imagekit.io/demo/http2-vs-http1 But that's not the majority, it's not most cases. Especially if you leave a city and are on mobile internet with poor signal.
- littlecranky67 6y ago
  That example seems to be arbitrarily constructed to benefit from parallel connections and does not reflect typical HTTP transfer payloads. In reality, Google mostly failed to show scientific proof that HTTP/2.0 provides beneficial on typical connections - one major reasoning why even introducing QUIC in HTTP/3. A lot of "amateur benchmarks" float the net claiming HTTP/2 speed superiority, but often the measurements are flawed (not taking TCP peculiarity like congestion control into account or even including it in the analysis; classic fault is failure to disable TCP initcwnd caching or flushing the cache when doing benchmarks).
  - heipei 6y ago
    Anecdotal, but I've encountered so many legacy HTTP/1 applications on typical corporate VPN networks where the latency was horrible (due to the VPN and also due to the backend responses adding even more latency). What I've done in some cases is just thrown an HTTP/2 proxy in front of these and saw an immediate and very user-perceptible performance improvement for the user. So much so that people kept asking why using the proxied version I stood up was so much faster than going directly to the origin server.
    - ktpsns 6y ago
      This is actually quite a good example that websites are bloated and this problem is tried to be solved or worked-around at the protocol level. Which is adding even more bloat and craft in terms of code complexity. These are the two sides of complexity: It can create marvelous web applications and it can create no visible advantage.
      - heipei 6y ago
        Yes, some websites are certainly bloated and for those it is simply a band-aid. But other websites really do make dozens of requests and there is no way to bundle or reduce these. Just think about a photo-sharing website or forum which loads thumbnails or user avatars for dozens of users in a discussion. This is not something that you can sprite together.
        labawi 6y ago
        Sure you can. Even without javascript. If you really wanted to, you could even make it work in IE 5, in a single request (I think). I we're discussing whether is reasonable - 9/10 slow pages I have encountered are slow because of "content" they push on you and would add even more garbage if they could get away with it. Of the rest - most were the opposite of engineered. Tiny minority that can't be bothered to optimize - I don't mind. You mention sites with sprites, but I would really like to see an example of a sites that are slow on HTTP<2 for good reasons, i.e. not 90% of data being ads, trackers, popups, auto-playing videos and generating content via multi-MB javascript libraries, because that's how it's done these days.
  - Nullabillity 6y ago
    It is a bit over the top, but the patterns are still indicative of the naive approaches you'd typically start out with. Yes, there are hacks to work around it (bundling and spritesheets), but they have other tradeoffs, like losing ~all of your cache granularity.
  - cogman10 6y ago
    I've seen a lot of compromises around REST because of http 1.1 overhead. A great example of this happens when someone wants to query for a list of resources. The rest way for this would be to do requests like this get /foo/1 get /foo/2 get /foo/3 However, unless you spin up a bunch of parallel connections (wasting a bunch of resources both in the servers and the client), you are going to experience performance issues. The compromise is to create endpoints that look like this post /foo [1,2,3] That saves the connection problem but creates a bunch of new issues. The client can send arbitrary request sizes to single servers (making LBing more difficult). It's not idiomatic, which means things like Http caching simply can't be used (or at least are less effective). A lot of http clients will do auto-retry but only for idempotent verbs, that's gone, you now need to implement all that stuff yourself. http2 fixes all that. Making parallel requests for n datapoints isn't nearly as big an issue. Those requests can be fanned out to a bunch of servers and those servers can be in charge of figuring how how much batching thing should be doing before reaching out to the DB. Making it impossible for a single client to really tank the system. Certainly you can work around this, usually by having the service farm out work over a message bus so you don't run into the problem of a single server going down due to a big request. However, the reason those message buses work and are fast is precisely because they are similar to Http2. All of these have major consequences for backend services. If I have a fleet of apps talking to another fleet of apps, then it matters, a LOT, if each of those apps are creating 20 TCP connections to the other fleet. Get the wrong kind of load storm and your backend will topple over. Now, is this super scientific? No. Rather it's based on what I've seen in the field. Http2 has a ton of benefits when doing a lot of small message communication.
- baybal2 6y ago
  > But plenty of people have high latency internet connections. The problem with HTTP 2.0 is it does not really improve the performance in real life as in Google's "real life benchmarks," it especially does not improve the situation on lossy, and throttled connections, and may actually lead to a degradation over HTTP 1.1. The "real life benchmarks" data from Google about QUIC is put under doubt in this light.
- patrec 6y ago
  I never followed it that closely, but from afar HTTP/2 always seemed like an amazingly stupid idea to me, and I always wondered if I was missing something -- apart from all the bloat and complexity, multiplexing several streams over TCP is a typical networking rookie mistake, because chances are you will be caught out by head-of-line blocking. First there was all this hype how awesome HTTP2 would be, no mention of head of line blocking. Then, several years later, lo and behold HTTP3 is hyped next, and one big motivation is that HTTP2 turned out to have a head of line blocking problem. What on earth is going on here? Google obviously has great engineering talent and HTTP2 must have been high profile enough to not leave to a bunch of interns. So there must be more nuance to this, does anyone know the score?
  - lemagedurage 6y ago
    As explained in the article, HTTP/2 solves a HTTP-level head-of-line blocking issue over HTTP/1.1, but retains TCP-level head-of-line blocking, which is later solved by HTTP/3. The alternative to TCP head-of-line blocking is either using a separate connection per request (which was the original performance bottleneck) or using UDP (which would've been a rather big change coming from HTTP/1.1). Now these problems are solved incrementally, and HTTP/2 plays a part in that. Which part is stupid?
    - throw0101a 6y ago
      > The alternative to TCP head-of-line blocking is either using a separate connection per request (which was the original performance bottleneck) or using UDP (which would've been a rather big change coming from HTTP/1.1). And of course SCTP (nor DCCP) are usable on the general Internet.
      - patrec 6y ago
        I sometimes idly wonder if one of the last favors Google and the other IT behemoths could do the open web before being broken up is just announcing a plan to just use SCTP for Important Thing, and fuck people who are sitting behind broken middleware and if they don't like it complain to the idiots who block SCTP upstream (mutatis mutandis for a zillion other things that are only there to work around broken middleware). Of course there is zero chance of this happening (for one thing, it would probably greatly increase the chances of getting broken up earlier rather than later), but it's kind of nice to imagine someone of sufficient size throwing their weight around to stop socializing costs and shake up the useable protocol stack a bit again, and retire a lot of horrible hacks and complexity in one fell swoop.
formerly_proven 6y ago
HTTP/2 seems to be a fairly typical instance of second-system syndrome, with HTTP/3 being the engineers doubling down.

Jonnax 6y ago

The problem doesn't exist for you. But plenty of people have high latency internet connections. Either due to technology (Mobile network, satellite) or due to them being very far from internet exchanges and the server's they want to connect to. Here is an example of the speed advantage on a low latency connection: https://youtu.be/QCEid2WCszM https://youtu.be/QCEid2WCszM Of course with my 1gbps broadband in a capital city both are pretty much instant when doing the test: https://imagekit.io/demo/http2-vs-http1 https://imagekit.io/demo/http2-vs-http1 But that's not the majority, it's not most cases. Especially if you leave a city and are on mobile internet with poor signal.

littlecranky67 6y ago
That example seems to be arbitrarily constructed to benefit from parallel connections and does not reflect typical HTTP transfer payloads. In reality, Google mostly failed to show scientific proof that HTTP/2.0 provides beneficial on typical connections - one major reasoning why even introducing QUIC in HTTP/3. A lot of "amateur benchmarks" float the net claiming HTTP/2 speed superiority, but often the measurements are flawed (not taking TCP peculiarity like congestion control into account or even including it in the analysis; classic fault is failure to disable TCP initcwnd caching or flushing the cache when doing benchmarks).
- heipei 6y ago
  Anecdotal, but I've encountered so many legacy HTTP/1 applications on typical corporate VPN networks where the latency was horrible (due to the VPN and also due to the backend responses adding even more latency). What I've done in some cases is just thrown an HTTP/2 proxy in front of these and saw an immediate and very user-perceptible performance improvement for the user. So much so that people kept asking why using the proxied version I stood up was so much faster than going directly to the origin server.
  - ktpsns 6y ago
    This is actually quite a good example that websites are bloated and this problem is tried to be solved or worked-around at the protocol level. Which is adding even more bloat and craft in terms of code complexity. These are the two sides of complexity: It can create marvelous web applications and it can create no visible advantage.
    - heipei 6y ago
      Yes, some websites are certainly bloated and for those it is simply a band-aid. But other websites really do make dozens of requests and there is no way to bundle or reduce these. Just think about a photo-sharing website or forum which loads thumbnails or user avatars for dozens of users in a discussion. This is not something that you can sprite together.
      - labawi 6y ago
        Sure you can. Even without javascript. If you really wanted to, you could even make it work in IE 5, in a single request (I think). I we're discussing whether is reasonable - 9/10 slow pages I have encountered are slow because of "content" they push on you and would add even more garbage if they could get away with it. Of the rest - most were the opposite of engineered. Tiny minority that can't be bothered to optimize - I don't mind. You mention sites with sprites, but I would really like to see an example of a sites that are slow on HTTP<2 for good reasons, i.e. not 90% of data being ads, trackers, popups, auto-playing videos and generating content via multi-MB javascript libraries, because that's how it's done these days.
- Nullabillity 6y ago
  It is a bit over the top, but the patterns are still indicative of the naive approaches you'd typically start out with. Yes, there are hacks to work around it (bundling and spritesheets), but they have other tradeoffs, like losing ~all of your cache granularity.
- cogman10 6y ago
  I've seen a lot of compromises around REST because of http 1.1 overhead. A great example of this happens when someone wants to query for a list of resources. The rest way for this would be to do requests like this get /foo/1 get /foo/2 get /foo/3 However, unless you spin up a bunch of parallel connections (wasting a bunch of resources both in the servers and the client), you are going to experience performance issues. The compromise is to create endpoints that look like this post /foo [1,2,3] That saves the connection problem but creates a bunch of new issues. The client can send arbitrary request sizes to single servers (making LBing more difficult). It's not idiomatic, which means things like Http caching simply can't be used (or at least are less effective). A lot of http clients will do auto-retry but only for idempotent verbs, that's gone, you now need to implement all that stuff yourself. http2 fixes all that. Making parallel requests for n datapoints isn't nearly as big an issue. Those requests can be fanned out to a bunch of servers and those servers can be in charge of figuring how how much batching thing should be doing before reaching out to the DB. Making it impossible for a single client to really tank the system. Certainly you can work around this, usually by having the service farm out work over a message bus so you don't run into the problem of a single server going down due to a big request. However, the reason those message buses work and are fast is precisely because they are similar to Http2. All of these have major consequences for backend services. If I have a fleet of apps talking to another fleet of apps, then it matters, a LOT, if each of those apps are creating 20 TCP connections to the other fleet. Get the wrong kind of load storm and your backend will topple over. Now, is this super scientific? No. Rather it's based on what I've seen in the field. Http2 has a ton of benefits when doing a lot of small message communication.
baybal2 6y ago
> But plenty of people have high latency internet connections. The problem with HTTP 2.0 is it does not really improve the performance in real life as in Google's "real life benchmarks," it especially does not improve the situation on lossy, and throttled connections, and may actually lead to a degradation over HTTP 1.1. The "real life benchmarks" data from Google about QUIC is put under doubt in this light.
patrec 6y ago
I never followed it that closely, but from afar HTTP/2 always seemed like an amazingly stupid idea to me, and I always wondered if I was missing something -- apart from all the bloat and complexity, multiplexing several streams over TCP is a typical networking rookie mistake, because chances are you will be caught out by head-of-line blocking. First there was all this hype how awesome HTTP2 would be, no mention of head of line blocking. Then, several years later, lo and behold HTTP3 is hyped next, and one big motivation is that HTTP2 turned out to have a head of line blocking problem. What on earth is going on here? Google obviously has great engineering talent and HTTP2 must have been high profile enough to not leave to a bunch of interns. So there must be more nuance to this, does anyone know the score?
- lemagedurage 6y ago
  As explained in the article, HTTP/2 solves a HTTP-level head-of-line blocking issue over HTTP/1.1, but retains TCP-level head-of-line blocking, which is later solved by HTTP/3. The alternative to TCP head-of-line blocking is either using a separate connection per request (which was the original performance bottleneck) or using UDP (which would've been a rather big change coming from HTTP/1.1). Now these problems are solved incrementally, and HTTP/2 plays a part in that. Which part is stupid?
  - throw0101a 6y ago
    > The alternative to TCP head-of-line blocking is either using a separate connection per request (which was the original performance bottleneck) or using UDP (which would've been a rather big change coming from HTTP/1.1). And of course SCTP (nor DCCP) are usable on the general Internet.
    - patrec 6y ago
      I sometimes idly wonder if one of the last favors Google and the other IT behemoths could do the open web before being broken up is just announcing a plan to just use SCTP for Important Thing, and fuck people who are sitting behind broken middleware and if they don't like it complain to the idiots who block SCTP upstream (mutatis mutandis for a zillion other things that are only there to work around broken middleware). Of course there is zero chance of this happening (for one thing, it would probably greatly increase the chances of getting broken up earlier rather than later), but it's kind of nice to imagine someone of sufficient size throwing their weight around to stop socializing costs and shake up the useable protocol stack a bit again, and retire a lot of horrible hacks and complexity in one fell swoop.

formerly_proven 6y ago

HTTP/2 seems to be a fairly typical instance of second-system syndrome, with HTTP/3 being the engineers doubling down.