9 ms·

When HTTP/2 came out, I was wondering how long it would take for the billions of websites/APIs/webservices/... out there to migrate from HTTP/1.1 HTTP/2 came o

• xyzzy_plugh 5y ago
  If you use Go or gRPC, then you're probably using HTTP/2. I've seen both used, at least somewhat, by every company I've done work for in the last 5-6 years.
  • halpert 5y ago
    The default Go http server is 1.1, no?
    • ferdowsi 5y ago
      The default Go server supports HTTP/2. https://pkg.go.dev/net/http https://pkg.go.dev/net/http > Starting with Go 1.6, the http package has transparent support for the HTTP/2 protocol when using HTTPS.
  • linkdd 5y ago
    > If you use Go or gRPC I'm not. My go-to web frameworks are Elixir/Phoenix, Python/Django, NodeJS/ApolloServer. I have an irrational hatred for the Go language, but still use it to develop quickly some CLI tools.
    • topicseed 5y ago
      > I have an irrational hatred for the Go language Do you mind sharing why?
      • serverholic 5y ago
        Not the same person but I share his sentiment. Go is terribly designed from a language perspective. It's weird and doesn't follow normal language conventions. The tooling and package manager is terrible. Eventually I think it'll be seen as the next PHP. A language that people love to hate.
        • eyelidlessness 5y ago
          I haven’t written any Go, but having read through some tutorials I find this a little hard to believe. Besides, Node has already been the next PHP, in terms of reputation and ridicule, for almost its entire lifespan. I do expect Go will become more esoteric over time, but mostly because it’s a Google thing (with all the unpredictability that implies), and because it overlaps a couple rapidly evolving use case targets.
          • azurelake 5y ago
            It's not. For the niche it has found success in (infra type backend stuff), it's by far the best option available. `if err != nil` is a godsend in that world.
            • ciupicri 5y ago
              What's so great about `if err != nil` ?
              • linkdd 5y ago
                In theory: explicit error handling. An error should be taken care of immediately, or propagated with some additional context. Returning the error instead of throw/catch makes this explicit and forces the developer to think about it. In practice: a lot of boilerplate code. Rust does this better with the Result type and the ? operator.
                • eyelidlessness 5y ago
    • eyelidlessness 5y ago
      I don’t know what’s common for serving BEAM web services, but unless I’m mistaken nginx is still a safe assumption for Python. If you’re using nginx for either, transitioning to HTTP/2 should be a couple small config changes away.
      • linkdd 5y ago
        I deploy on Kubernetes, so it will be behind an Ingress controller (NGinX, Istio, ...) if it needs to be exposed to the outer world. If I was deploying to baremetal, I would either have a HAProxy/Keepalived reverse-proxy, or a load balancer that most probably supports it. But HTTP/1.1 have not yet failed me, so I have not yet considered the migration. If it's not broken, don't fix it :)
        • eyelidlessness 5y ago
          > Istio Also looks like a trivial config change. I’m not familiar with it but I don’t see any red flags. > If it's not broken, don't fix it :) This seems exceedingly myopic in this context. Why migrate to broadband from 56k modem? That modem connects to the internet too! Why upgrade to a browser version which supports HSTS? You can just manually type https in the location field. Why try anything with new features at all? You can just never have new features if they work. I’m not saying there’s never a trade-off with any of these things. But you’ve preemptively ruled out any benefit without exploring them… or whether they even have any meaningful (to you) cost. “Cutting off your nose to spite your face” is the phrase my family uses for this.
          • linkdd 5y ago
            There is a difference between switching protocol, and: - not migrating to broadband from 56k modem - not upgrading to a browser version which supports HSTS - not trying anything with new features at all HTTP/1.1 still serves its purpose, successfully, without any impact on performance/usability. I'm not Google, I'm not serving a webpage to 8 billions devices at the same time. Sure I can try HTTP/2 (and I did), and HTTP/3 (and I will). But when it comes to distributing an application/service to customers, I'll automatically choose the battle-tested 30 years old technology which is supported by everyone and every device.
    • tokumei 5y ago
      Elixir/Phoenix used to be my go to as well. I’ve since switched to Rust with actix-web for backend web projects. I’m really happy with the transition.
• eyelidlessness 5y ago
  It really depends on your deployment, but a lot of us have adopted HTTP/2 without lifting a finger, or with routine dependency updates. It’s possible (probable) that those migrations have not resulted in optimal usage, but neither have specially tailored migrations (see: the sad slow death of Server Push). As far as whether you should consider migrating, it’s worth doing a quick spike to determine level of effort. I expect the number of use cars which: - can’t trivially update - aren’t directly providing HTTP functionality to users who expect that … is a rather small niche.
• tashoecraft 5y ago
  I just recently got my company to switch over to http2 and halved our load time across the board. It might go down as the greatest improvement in customer experience for the simplest action I’ll ever do.
  • pottertheotter 5y ago
    What caused this? I don’t know much about http
    • cogman10 5y ago
      http2's biggest advantage is it's multiplexed over a single tcp connection. So if your site has a bunch of resources on it, then http2 will allow your clients to request all their required resources at once without establishing a bunch of TCP connections. Browsers allow for somewhere around 6 simultaneous TCP connections (which means around 6 concurrent requests with http1.1). Http2 allows for http requests at the speed of the clients upload connection (effectively unlimited).
      • jart 5y ago
        HTTP/1.1 can do this. It's called pipelining. But browsers refuse to implement it.
        • bigbonch 5y ago
          Would still be constrained to head-of-line blocking which HTTP/3 aims to solve.
          • baybal2 5y ago
            HTTP/3 will not be adopted because it's a downgrade from HTTP/2 for CDN companies. HTTP/2 has indeed massively benefitted CDNs by providing more effective capacity per buck, but UDP based 3.0/QUIC will singlehandedly destroy it, and bring it to below HTTP 1.1.
• jakub_g 5y ago
  If your website has a lot of small files served, H2 and H3 offer dramatic improvements: browser says "gimme those 100 files" and server sends them all over a single connection in a streaming fashion. Whereas with H1 browser opens up to 6 connections, downloads 1 file on each, then once the response comes it tells "ok now gimme another file" etc. (Another RTT until it comes back). That's many round-trips saved. This is probably mostly useful when downloading many small images. It can be also useful for splitting JS into smaller bundles to favor cache hits for returning visitors. (An be also useful to serve ES modules without or with minimal bundling; however in practice bundling is still useful given that modern JS apps have 100s/1000s of files and small files overhead still matters at such numbers).
  • linkdd 5y ago
    Yes, it basically render webpack obsolete :P I've not yet created a product used by so many people that this optimization was needed, maybe tomorrow? > If your website has a lot of small files served What about JSON/GraphQL APIs?
  • jakub_g 5y ago
    Just to add a few bits: I'm not an infra person so can't tell about managing a H2 deployment, but from frontend web performance perspective H2 is very interesting and somehow not used to its full potential. H2 has built-in support for interesting concepts like prioritization and re-prioritization of requests. Unfortunately, most impls in clients and servers are either not full or not very good: I recommend googling "http/2 prioritization" and checking blogs and talks from Andy Davies and Pat Meenan. The subject is super interesting and inherently hard; browsers need to make certain assumptions whether scripts, fonts or CSS are more important and should be prioritized and it's non-obvious how to handle it best. https://github.com/andydavies/http2-prioritization-issues https://github.com/andydavies/http2-prioritization-issues https://medium.com/dev-channel/javascript-loading-priorities-in-chrome-57c54cfa6672 https://medium.com/dev-channel/javascript-loading-priorities...
  • aseipp 5y ago
    > This is probably mostly useful when downloading many small images. It's useful for much more than that; I'd actually argue stream multiplexing is most useful outside of the browser in bespoke HTTP APIs, because that's a place where you can just stumble on cases where high fan-out requests are useful. For the browser case you're often limited by things like pagination, while JS/CSS can be amalgamated. Not that it isn't good for small images too! But APIs benefit a lot as well and I think that's easily forgotten.
• aseipp 5y ago
  A big thing is that you may be using HTTP/2 or HTTP/3 already if you use something that terminates HTTP for you. This doesn't have to be Cloudflare or whatever; if you run Nginx in front of your Rails server, you can just have Nginx handle HTTP/2 for you. Many deployments or services like AWS, Heroku, S3, etc already enable HTTP/2 for you and it's transparent on the client end. The widespread deployment of caching utilities and other frontend application middleware was, in a paradoxical way, a huge boon that lead to easy success for HTTP/2 (and now /3) while making it appear a bit bland to everyone else. "Nobody uses this, right? I mean, I've never changed anything." You weren't supposed to! For many purposes this is intended: service providers, operational admins etc can largely tweak this all independently at the caching service layer, for instance. Taken together it's mostly just "free performance" for the case of a user who has a reasonably reliable network. Now, don't get me wrong, you need to understand caching and the HTTP connection lifecycle. There are aspects of newer HTTP versions that do impact the development experience. For example if you're sure you're using HTTP/2, you can rely on multiplexing. That means that, for instance, if your user has a dashboard with many panels, and each panel is doing independent requests to get metrics data (like Grafana, for instance), then all of those HTTP requests for data happen over 1 TCP connection. If you had to use many connections, you'd either have to throttle/serialize updates, use pipelining, or it might not work at all since the browser will refuse to open too many at once. But you can rely on this working with HTTP/2. If you rely on multiplexing, the penalty of having many small files on a single domain is much smaller. So those user avatars hosted on mybusiness-static-content.net will load much faster for all users too. That's just free performance on the table. But you have to design with it in mind. So to answer your question: why should you migrate? Well, in general the answer is simple: better performance and better security (HTTP/2 and HTTP/3 both mandate TLS, for example), and HTTP/3 handles flaky mobile connections much better than either v1 or v2. That might really help for something like an API endpoint that mobile device clients access, for instance. If you start a new project, should you consider anything except HTTP/1.1? Yes! Because HTTP/2 and HTTP/3 are here to stay, so it's not like you're betting the farm on something untested. You do need to consider client library availability; you can't get away with a half-baked "HTTP/2" implementation as easily as you could with HTTP/1.1 (this is the dark side of people who complain about binary-vs-text formats: it was very easy to get HTTP/1.1 very wrong). But they have tangible benefits for end users, and, taken into consideration, can help you do some stuff you couldn't before. Ignoring any claims it's a sign of website bloat, "download a lot of small files" is actually a legitimate, huge use case you couldn't do efficiently before in the browser or otherwise! Some non-browser workloads I've had see incredible performance improvement just from this alone. And if you're writing server software? Well, a good reason is "because it's easy to deploy". You might only need to change a configuration in your existing terminator. Will there be an HTTP/4? I guess nothing is impossible here but I wouldn't bet on it. HTTP/2 was the big change. HTTP/3 was a "big" change not for HTTP, but because fixing HOL blocking at the TCP layer can only be done by, well, not using TCP! It's otherwise the exact same thing you know already, just in binary form, over a different transport stream. There could of course be other things down the line, but it seems like if anything continues to evolve, it will be QUIC itself, and less-so for HTTP.
• tialaramex 5y ago
  > since then I still haven't seen it used in production in the jobs I worked at How do you know? Most of the Alexa top 100k web sites are HTTP/2 but I suspect a great many of the people working on those web sites have no idea HTTP/2 exists, it simply has no impact on their work. It probably has no impact on your work.
  • linkdd 5y ago
    Because I mostly worked with teams who built internal tools, be it monitoring solutions, or APIs consumed by BI tools, or custom CMDBs, custom CMS, etc... Every single one of them was deploying the projects on the internal infrastructure, sometimes a small Kubernetes cluster, some other times just an EC2 instance, most of the time just one or two VMs. Each employee was given a computer with a VPN client pre-installed, to connect to the internal infra. The biggest company I've worked with had 10k employees, still not enough to see any impact on performance on the slowest single-threaded service we made. When deploying, we were simply adding to the internal DNS server an A record "service.internal-domain.tld" pointing to the IP of our server. No load balancer, no reverse proxies, no HTTP/2 in the stack. It's cheap, it works, it's certainly not something you would do if you were serving a SaaS application to millions of user on the world wide web, but it's definitely enough for internal stuff. Even Google does not have more than 100k of employees.
    • darrenf 5y ago
      > Even Google does not have more than 100k of employees. Alphabet has over 150k employees. https://www.sec.gov/Archives/edgar/data/1652044/000165204422000019/goog-20211231.htm https://www.sec.gov/Archives/edgar/data/1652044/000165204422...
    • jeeeb 5y ago
      If you’re primarily writing internal tooling then http2 is unlikely to be particularly relevant or beneficial to you (unless using gRPC or similar). However, turning on http2 for an org might mean nothing more than toggling some settings on a reverse proxy, no code changes required and little to no visibility or fuss for developers.
• WalterSobchak 5y ago
  Have you seen this yet? https://portswigger.net/research/http2 https://portswigger.net/research/http2
• gsich 5y ago
  >The real question here is, what are the arguments in favor of a migration? When starting a new web project, should you really consider anything else than HTTP/1.1? Depends on what you mean with web project. How the server delivers data might not be of importance.
• jiggawatts 5y ago
  That’s because HTTP/2 broke every capability that was not used by Google. NTLM auth… broken. Client cert auth (mTLS)… broken. Etc… Monopolies are dangerous because they can accidentally lock out their competition without even trying. They just have to focus on their own problems and ignore other people’s problems… because they can.
  • AceSlash 5y ago
    Indeed, I was surprised when we tried to move a B2B application using mtls to http2 and realised that it simply was not implemented! I know that's not used a lot but it is still used sometime when accessing critical systems. I suppose that in the long run, mtls will completely disappear because of that, strange for a protocol that advertise itself as more secure to remove this option.
    • p_l 5y ago
      Client cert authentication (aka mutual tls) works perfectly fine on HTTP/2 (as it happens on a completely unrelated protocol layer), so my question is just what did you deploy that broke it?
      • jiggawatts 5y ago
        It doesn't "just work", because it's a HTTP authentication flavour that happens to occur at the Transport layer. Because it crosses layers like this, HTTP has to know about the transport. For example, it's possible in HTTP 1.1 to have a page trigger cert auth even though the initial transport didn't use it! This is common for logging on to pages using Smart Cards but leaving an option to use alternate authentication modes. This was just... abandoned in HTTP/2 (and HTTP/3) as "too hard". Or more accurately, every authentication mode not used by Google was abandoned and does not work. I've tried HTTP/2 with products from numerous vendors, and without fail anything Google doesn't use... didn't work.
        • p_l 5y ago
          Are you talking about mutual TLS, or are you talking about Negotiate? Because the only way to trigger cert auth (under mtls) if the initial transport didn't use it is to force a TLS renegotiation, as it's handled by sending a CertificateRequest message at TLS layer. Windows Integrated Authentication however triggers authentication by sending Negotiate header and performing HTTP-level exchange. N.B. Every example of page triggering cert login later on that I have encountered in the wild forced a fresh connection and thus mutual authentication.
• josephcsible 5y ago
  > When starting a new web project, should you really consider anything else than HTTP/1.1? This makes it sound like the HTTP version you use is as major of a decision as the programming language you use, but can't you change HTTP versions basically by just flipping a switch?
  • josefx 5y ago
    If you like to ignore the security implications that come with every switch? Some services use HTTP/2 frontends for their HTTP/1 backend services. This resulted in a large amount of tunneling attacks that the HTTP/2 spec. predicted, it is almost as if every implementation of HTTP/2 just ignored an entire section of its spec. . HTTP/3 is also already off to a good start, it requires changes in how encryption libraries interact with the protocol and that has already resulted in people pressuring OpenSSL to adopt experimental changes (marked do not use) by Google well before that part of the HTTP/3 spec was even done.
    • josephcsible 5y ago
      To be clear, I don't think HTTP version is an unimportant decision. I'm just saying it's one that's easily changeable and so doesn't need to be set in stone when you first start building a web project.
• fivea 5y ago
  > HTTP/2 came out in 2014, and since then I still haven't seen it used in production in the jobs I worked at. I'd already be happy if I could use IPv6.
• jillesvangurp 5y ago
  Anything using Google, AWS, or load balancers from other major cloud providers will likely end up being early adopters for this stuff. In our case, since we were targeting mobile, we actually used nginx with SPDY support before HTTP/2 was even stabilized. It wasn't that hard. We just had to get a recent build and fiddle with a few lines of configuration. That was 2014. HTTP/2 standardization came later, as I recall. We already have an HTTP/2 and HTTP/3 capable load balancer because we host on GCP these days. Mostly this stuff just happens without intervention. HTTP/1.1 is a fallback for people with crappy network infrastructure. If you are starting a web project, you should probably use one of the major cloud providers unless you have a good reason not to. You'll use this stuff by default mostly unless you explicitly turn this off. But why would you want to do that? If you are managing your own load balancers; consider using something modern/up to date that would be able to support this. Also from a security point of view probably not something you should skip. And if you are using something modern, it shouldn't be that hard to turn on the feature. If you manage some legacy stuff that just doesn't matter; don't bother of course. HTTP 1.1 will continue working just fine. If you have mobile users though, you are not doing them any favors by making things needlessly slow and this would probably be an easy upgrade.
• happymellon 5y ago
  We will switch about 6 months after adoption of IP6 is complete.