8 ms·

> HTTP/2 a.k.a. SPDY is a comically bloated Layer 4/5/7 mega-combo protocol designed to replace HTTP. It takes something simple and (most importantly!) comprehe

> HTTP/2 a.k.a. SPDY is a comically bloated Layer 4/5/7 mega-combo protocol designed to replace HTTP. It takes something simple and (most importantly!) comprehensible and debuggable for junior programmers and replaces it with an insanely over-complicated system that requires tens of thousands of lines of code to implement the most minimal version of, but which slightly reduces page load time and server costs once you reach the point of doing millions of requests per second. I am filled WITH RAGE just thinking about how we took a fundamental part of the Internet, simple enough that anyone can implement an HTTP server, and replaced it with this garbage protocol pushed by big megacorps that doesn't solve any real problems but will completely cut out future generations from system programming for the web This resonates with me, and I'd like to add HTTP/2 can only bring advantages if you actually go all the way to push/bundle resources into responses and have a strategy/priority when to push eagerly vs serve lazily; I'm even much more worried about upcoming QUIC (and DoH) because there's no impl in sight.

Xorlev 6y ago
https://github.com/cloudflare/quiche https://github.com/cloudflare/quiche
cheesecracker 6y ago
I procrastinated switching to CSS sprites until HTTP/2 came around and made it superfluous, so I don't agree.
derefr 6y ago
> HTTP/2 can only bring advantages if you actually go all the way to push/bundle resources into responses Compared to well-optimized HTTP/1 (e.g. using minified CSS and sprite-sheets), sure. Compared to most HTTP/1 deployments, though: no. HTTP/2 gives you tons of advantages "for free" that you need build-time processes to attain in HTTP/1. With HTTP/2, you can do "the naive thing" that'd you'd have done on the 1995 Web in Notepad, and it'll be the optimal thing. Also, HTTP/2 means less OS packet-switching overhead server-side if you have ancillary connections (e.g. websockets) open against the host, since those also get muxed into the same carrier socket. Also, mobile clients wake up less, because there's only one TCP socket to do idle-keepalive on. HTTP/2 also means that TCP's Nagling has more to work with, and so is less likely to end up needing to waste bandwidth on emitting many undersized packets—it can just pack N short requests into the same TCP jumbo frame, since they're all going to the same place. I would also point out an indirect "advantage": HTTP/2 makes it cheaper to serve ads proxied through the first-party host (as HTTP/2 flows) than for the client to hit the third-party ad servers directly. People can still block the ads/trackers either way, but served inline to the origin like this, the people who don't block ads, will get a better experience.
- secondcoming 6y ago
  What have CSS and sprite-sheets go to do with the HTTP protocol?
- tannhaeuser 6y ago
  I agree these things can be useful, but again none of these come out of the box (if I haven't overlooked or misunderstood something). Including "doing the naive thing"; I mean how do you expect your web server to automatically push CSS or SVG sprites/fonts unless you're relying on the server to intercept/parse your HTML for delivery-time optimizations a la PageSpeed and make heuristic scheduling decisions? Unless you're putting in the effort to optimize your payloads you will just result in as many roundtrips with HTTP/1.1 + keep-alive.
  - derefr 6y ago
    Web browsers are limited in the number of concurrent socket connections they'll open to a given origin. This matters not-at-all in HTTP/2, since everything is going over a single socket; while mattering quite a lot in HTTP/1, since dependent resources being loaded in parallel must be loaded on separate sockets. If you only have six parallel sockets to work with, then if your page is, say, an image gallery, then the Javascript file that makes it work (loaded at the bottom of the body) might be blocked waiting behind the loading of e.g. some large image higher up in the body. The previous requests need to entirely finish (= a round trip) before the next requests on the same socket can start. Keep-alive does nothing to fix that. HTTP/1.1 pipelining partially mitigates this, allowing the client to "queue up" a list of all the dependent resources it wants from each socket; but it suffers from head-of-line blocking. Which sounds like some arcane thing, but in practice it means that big things might block the loading of small things. (The browser doesn't know how big things are, so it can't effectively schedule them; and the server must dumbly queue results up in the same order the client requested them, because that's the only way the HTTP pipeline's implicit flow sequence counters will match up.) HTTP/2 is a full mitigation for this problem, since—even without a heuristic "prioritization strategy" for the delivery of dependent-resource flows—the "oblivious" strategy is still a good one: if you attempt to deliver all the resources in the queue concurrently; and you do so by delivering one fixed-size chunk of each flow per iteration, in a round-robin fashion; then you'll end up finishing delivery of resources smallest-to-largest—which means you'll usually deliver the most-critical resources first, no matter where in the dependent-resource queue they started. Or, in short: HTTP/1.0 = O(N) required roundtrips for a page with N resources. HTTP/1.1 with pipelining = O(1) required roundtrips for a page with N resources (followed by O(N) bytes streamed half-duplex), but the page can still take nearly the same amount of time to become interactive as if it were O(N) roundtrips, because of effectively worst-case scheduling. HTTP/1.2 = O(1) RTTs + O(N) half-duplex bytes for N resources, loading "intelligently" such that the page becomes interactive in O(log N) time.
finnthehuman 6y ago
>but will completely cut out future generations from system programming for the web There's so many things where my competence is based on understanding the simple preceding system plus a good intuition of how the class of systems tend to be bungled up over the years. We don't pay down the accumulated complexity, and newcomers don't get the same luxury I do. It really becomes noticeable with highschoolers and I have to chose between teaching useless but illustrative groundwork, or just explaining and expecting a combination of taking it on faith and memorization.
dnr 6y ago
The misconception is the idea that anyone can easily implement a compliant HTTP 1.1 server, or even client. The protocol may appear simple on paper but parsing it correctly and securely is quite tricky. IMO, one of the benefits of HTTP 2 and 3 is they force people to use libraries and remove the illusion that interacting with HTTP bytes on the wire is a reasonable thing to do.
- ninkendo 6y ago
  > IMO, one of the benefits of HTTP 2 and 3 is they force people to use libraries What a strange comment. "The benefit of this protocol is that it's so complex that nobody understands it, so they have to use an existing implementation."
  - vlowther 6y ago
    What a weird slippery slope argument. There is a world of difference between "so complex that nobody understands it" and "I can telnet to port 80 and fetch a webpage using keyboard and fingers"
  - tjalfi 6y ago
    Bram Cohen made a similar observation[0] years ago. Bram's Law - The easier a piece of software is to write, the worse it's implemented in practice. I'm not sure whether I agree with him but it's not obviously wrong. [0] https://web.archive.org/web/20170629144859/http://www.advogato.org/person/Bram/diary/68.html https://web.archive.org/web/20170629144859/http://www.advoga...
- tannhaeuser 6y ago
  That's pretty much in the "cut out future generations from system programming for the web" territory, and complexity for the sake of complexity. Also, you have to implement HTTP/2 in addition to HTTP/1.1.
  - dnr 6y ago
    It's a big jump to go from "this protocol is more complicated than the previous one" to "cut out future generations from system programming". It's not _that much_ more complicated that a competent programmer who's familiar with sockets and bytes can't ever accomplish it. As discussed at length in another sub-thread here, the complexity solves real problems, it's not for its own sake. But if you're not convinced of that, nothing I say here is going to change that. · If you've worked with me, you'd know that I take simplicity as a virtue to an extent that's almost detrimental to getting stuff done. I despise complexity for its own sake. I wish as much as anyone that we could start over and redesign IP, TCP, TLS, HTTP, HTML, JS, and a few more things, with all our accumulated knowledge, into a simple and clean application and content distribution system that's easy to understand and observe. But path dependence :( We have to work with what we've got. It's the picking out of HTTP 1.1 as some sort of golden age of clean and simple and observable that bothers me. It isn't.
cortesoft 6y ago
What I don't get with the complaint is that HTTP/1 still works fine. If you are hosting (or writing) your own server, you can stick with that and be fine. I have heard ZERO talk about browsers deprecating HTTP/1 support. For the companies implementing http/2, those improvements DO matter. They have different needs. Why is this bad?
treve 6y ago
We're working on a large internal web application, and got huge benefits out of HTTP/2. It allows us to make smaller purpose REST api endpoints and do many calls, instead of trying to bundle everything together in larger endpoints. Being able to parallelize cheaply greatly simplified our architecture and API design, and it costs us nothing.

Xorlev 6y ago

https://github.com/cloudflare/quiche https://github.com/cloudflare/quiche

cheesecracker 6y ago

I procrastinated switching to CSS sprites until HTTP/2 came around and made it superfluous, so I don't agree.

derefr 6y ago

> HTTP/2 can only bring advantages if you actually go all the way to push/bundle resources into responses Compared to well-optimized HTTP/1 (e.g. using minified CSS and sprite-sheets), sure. Compared to most HTTP/1 deployments, though: no. HTTP/2 gives you tons of advantages "for free" that you need build-time processes to attain in HTTP/1. With HTTP/2, you can do "the naive thing" that'd you'd have done on the 1995 Web in Notepad, and it'll be the optimal thing. Also, HTTP/2 means less OS packet-switching overhead server-side if you have ancillary connections (e.g. websockets) open against the host, since those also get muxed into the same carrier socket. Also, mobile clients wake up less, because there's only one TCP socket to do idle-keepalive on. HTTP/2 also means that TCP's Nagling has more to work with, and so is less likely to end up needing to waste bandwidth on emitting many undersized packets—it can just pack N short requests into the same TCP jumbo frame, since they're all going to the same place. I would also point out an indirect "advantage": HTTP/2 makes it cheaper to serve ads proxied through the first-party host (as HTTP/2 flows) than for the client to hit the third-party ad servers directly. People can still block the ads/trackers either way, but served inline to the origin like this, the people who don't block ads, will get a better experience.

secondcoming 6y ago
What have CSS and sprite-sheets go to do with the HTTP protocol?
tannhaeuser 6y ago
I agree these things can be useful, but again none of these come out of the box (if I haven't overlooked or misunderstood something). Including "doing the naive thing"; I mean how do you expect your web server to automatically push CSS or SVG sprites/fonts unless you're relying on the server to intercept/parse your HTML for delivery-time optimizations a la PageSpeed and make heuristic scheduling decisions? Unless you're putting in the effort to optimize your payloads you will just result in as many roundtrips with HTTP/1.1 + keep-alive.
- derefr 6y ago
  Web browsers are limited in the number of concurrent socket connections they'll open to a given origin. This matters not-at-all in HTTP/2, since everything is going over a single socket; while mattering quite a lot in HTTP/1, since dependent resources being loaded in parallel must be loaded on separate sockets. If you only have six parallel sockets to work with, then if your page is, say, an image gallery, then the Javascript file that makes it work (loaded at the bottom of the body) might be blocked waiting behind the loading of e.g. some large image higher up in the body. The previous requests need to entirely finish (= a round trip) before the next requests on the same socket can start. Keep-alive does nothing to fix that. HTTP/1.1 pipelining partially mitigates this, allowing the client to "queue up" a list of all the dependent resources it wants from each socket; but it suffers from head-of-line blocking. Which sounds like some arcane thing, but in practice it means that big things might block the loading of small things. (The browser doesn't know how big things are, so it can't effectively schedule them; and the server must dumbly queue results up in the same order the client requested them, because that's the only way the HTTP pipeline's implicit flow sequence counters will match up.) HTTP/2 is a full mitigation for this problem, since—even without a heuristic "prioritization strategy" for the delivery of dependent-resource flows—the "oblivious" strategy is still a good one: if you attempt to deliver all the resources in the queue concurrently; and you do so by delivering one fixed-size chunk of each flow per iteration, in a round-robin fashion; then you'll end up finishing delivery of resources smallest-to-largest—which means you'll usually deliver the most-critical resources first, no matter where in the dependent-resource queue they started. Or, in short: HTTP/1.0 = O(N) required roundtrips for a page with N resources. HTTP/1.1 with pipelining = O(1) required roundtrips for a page with N resources (followed by O(N) bytes streamed half-duplex), but the page can still take nearly the same amount of time to become interactive as if it were O(N) roundtrips, because of effectively worst-case scheduling. HTTP/1.2 = O(1) RTTs + O(N) half-duplex bytes for N resources, loading "intelligently" such that the page becomes interactive in O(log N) time.

finnthehuman 6y ago

>but will completely cut out future generations from system programming for the web There's so many things where my competence is based on understanding the simple preceding system plus a good intuition of how the class of systems tend to be bungled up over the years. We don't pay down the accumulated complexity, and newcomers don't get the same luxury I do. It really becomes noticeable with highschoolers and I have to chose between teaching useless but illustrative groundwork, or just explaining and expecting a combination of taking it on faith and memorization.

dnr 6y ago

The misconception is the idea that anyone can easily implement a compliant HTTP 1.1 server, or even client. The protocol may appear simple on paper but parsing it correctly and securely is quite tricky. IMO, one of the benefits of HTTP 2 and 3 is they force people to use libraries and remove the illusion that interacting with HTTP bytes on the wire is a reasonable thing to do.

ninkendo 6y ago
> IMO, one of the benefits of HTTP 2 and 3 is they force people to use libraries What a strange comment. "The benefit of this protocol is that it's so complex that nobody understands it, so they have to use an existing implementation."
- vlowther 6y ago
  What a weird slippery slope argument. There is a world of difference between "so complex that nobody understands it" and "I can telnet to port 80 and fetch a webpage using keyboard and fingers"
- tjalfi 6y ago
  Bram Cohen made a similar observation[0] years ago. Bram's Law - The easier a piece of software is to write, the worse it's implemented in practice. I'm not sure whether I agree with him but it's not obviously wrong. [0] https://web.archive.org/web/20170629144859/http://www.advogato.org/person/Bram/diary/68.html https://web.archive.org/web/20170629144859/http://www.advoga...
tannhaeuser 6y ago
That's pretty much in the "cut out future generations from system programming for the web" territory, and complexity for the sake of complexity. Also, you have to implement HTTP/2 in addition to HTTP/1.1.
- dnr 6y ago
  It's a big jump to go from "this protocol is more complicated than the previous one" to "cut out future generations from system programming". It's not _that much_ more complicated that a competent programmer who's familiar with sockets and bytes can't ever accomplish it. As discussed at length in another sub-thread here, the complexity solves real problems, it's not for its own sake. But if you're not convinced of that, nothing I say here is going to change that. · If you've worked with me, you'd know that I take simplicity as a virtue to an extent that's almost detrimental to getting stuff done. I despise complexity for its own sake. I wish as much as anyone that we could start over and redesign IP, TCP, TLS, HTTP, HTML, JS, and a few more things, with all our accumulated knowledge, into a simple and clean application and content distribution system that's easy to understand and observe. But path dependence :( We have to work with what we've got. It's the picking out of HTTP 1.1 as some sort of golden age of clean and simple and observable that bothers me. It isn't.

cortesoft 6y ago

What I don't get with the complaint is that HTTP/1 still works fine. If you are hosting (or writing) your own server, you can stick with that and be fine. I have heard ZERO talk about browsers deprecating HTTP/1 support. For the companies implementing http/2, those improvements DO matter. They have different needs. Why is this bad?

treve 6y ago

We're working on a large internal web application, and got huge benefits out of HTTP/2. It allows us to make smaller purpose REST api endpoints and do many calls, instead of trying to bundle everything together in larger endpoints. Being able to parallelize cheaply greatly simplified our architecture and API design, and it costs us nothing.