Hacker News Reader

Comment by jakelarkin | Hacker News Reader

Couple gripes with HTTP2 ...

1) HTTP2 Server Push is a hobbled protocol. It was designed for serving static assets to desktop browsers for pre-caching. Most of the internet traffic now is moving to mobile apps or rich browser clients. Developers would greatly benefit from a true bi-directional API that could be fully leveraged by event-based or reactive frameworks. The community could even build it's own APIs if the browsers just exposed the DataFrame primitives of HTTP2. But they don't.

2) Open-source proxy servers like NGINX, HAProxy and many key IaaS providers like Cloudflare, Google Cloud do not support full duplex HTTP2 connections (one-side only at best, translated to HTTP1 on the backend). This is 1 year after RFC 7540 was officially released and 5 years after SPDY. Why even bother baking considerations for HTTP2 into your application layer when your edge infrastructure won't let you leverage it anyway.

View on HN

HTTP2 Server Push is "for what it's for"—it's not trying to be web sockets, or Server Sent Events, or WebRTC Data Channels; it's just trying to (transparently) make HTTP a little bit more optimized while completely keeping all current HTTP semantics.

1. you can use Server Push just as well to e.g. notice when JSON responses you're about to send out contain "hypermedia annotations" (i.e. "link" keys), and set up async self-subrequests to push the linked resources as well—then the backend can avoid ever having to think in terms of something like GraphQL's nested schemas, instead just answering queries for individual resources with fields and foreign key IDs; and the frontend can just dumbly consider responses to map directly to objects, instead of having to have a complex OSI-6 presentation layer that unpacks nested-schema messages into their resource-object equivalents. Suddenly HTTP PUT/PATCH has coherent semantics again, without losing any performance.

2. This is "a good problem to have"—and a good design decision on HTTP2's part, in my opinion. Most sites don't need HTTP2, and can stay HTTP1. While, if you realize that you need what HTTP2 provides, that need will probably be driven by an individual application you have (e.g. Google Search) that is at such huge scale that it has its own custom infrastructure driven by your scaling needs, of which "and supports HTTP2" will just be one more. (And this argument seems to hold water: according to https://www.searchdatalogy.com/blog/http2-on-top-sites/, a large percentage of the top bigcorps doing web traffic have switched.)

That argument hinges on whether you view the subset of legacy HTTP semantics as a useful and comprehensive abstraction for web client-server development in 2017. For a 2.0 release, and with Server Push specifically being an addition, they could have been more forward thinking than just the offering ... "hey here's a way to serve static resources slightly faster"

The phrase "for a 2.0 release" makes it sound like you think that this was some sort of big branded push, like a new major version of Microsoft Office that Microsoft wants you to buy.

The 2.0 in HTTP2 is just a semver version—it's 2 because it's not wire-compatible with 1. In terms of features, it's pretty much 1.2.

And besides, "serving static resources slightly faster" was enough to get a lot of big corporate players excited to switch. It might not excite you as a developer because it's "just" an infrastructure-level solution to an ops-time scaling problem, rather than a change in development-time workflows. But ops-time scaling problems are real problems, and Internet wire protocols change in response to those problems more than they ever do in response to developers' concerns. (There's a reason all current wire protocol standards are handled by the IETF—a body of data-center and NOC ops people, basically—rather than by developer-oriented groups like Khronos or WHATWG.)

Also, "slightly" is an understatement on severely latency-constrained links, like those of cellular or satellite internet connections, or over Tor(!). If you can turn 10 (tiny) HTTP requests into one request with 10 (tiny) responses, you can often turn five minutes' load time into 20-30 seconds.

The lack of HTTP/2 on the backend to origin connections is a big sad mystery.

If anything it would greatly increase performance, especially for smaller servers and longer distances, with the multiplexing and stream priority settings alone. Required TLS would also increase security.

>The lack of HTTP/2 on the backend to origin connections is a big sad mystery.

Sad, sure, but its not a mystery. As of HTTP/1.1 these proxies already pools TCP/IP connections between the proxy and its origin (the backend server), so it doesn't gain the same connection multiplexing/windowing/cardinality benefits that HTTP/2 to end client gets. This means for many proxy code bases H2 to origin is just a nice to have. Obviously, by prioritizing like that you miss other nice to haves like push.

HTTP/1 connections are limited to one request on the connection at a time and head-of-line blocking. HTTP/2 connections will also be pooled but are able to sustain many more concurrent requests because of multiplexing, while also setting certain requests as higher priority. It's a major improvement for high volume services.

The performance and features are why Google's gRPC uses it as the foundation for microservice communications at scale and low-latency.

>HTTP/1 connections are limited to one request on the connection at a time and head-of-line blocking.

This is true, however this limitation just increases the size of the connection tool needed for the same concurrency. I'm not saying HTTP/2 isn't better, I'm saying its less better for middleware than end user connection optimization.

If you have 100k people who've opened e.g. websocket connections to your backend, I doubt you're going to structure things as a 100k-socket connection pool open to your backend. You've probably either:

A. got that scaled across at least 100 backend servers, even if those servers' CPUs are almost entirely idle; or

B. have chosen a completely different, extremely roundabout architecture involving client async requests with HTTP 202 responses + client polling of a "status of server-side promises" endpoint; or

C. are effectively manually doing what HTTP2 does automatically, by having a "stateful-connection load-balancer server" (e.g. SocksJS) that mediates between long-lived client connections, and short-lived RPC requests with async responses from your backend.

Whereas, with HTTP2, that could very easily be one machine, taking in those 100k nearly-idle connections, and passing them over one TCP socket to one backend.

> Required TLS would also increase security.

TLS is not inherently required for HTTP/2 on the backend.

TLS is sort of required on the frontend mainly because browser vendors don’t want to deal with broken middleware that expects all traffic on TCP port 80 to be HTTP/1.x.

This is less of a concern on the backend, and there are practical implementations of cleartext HTTP/2 today, including nginx and Apache on the server side, libcurl on the client side, and others.

Sure, not absolutely required but it's the default way and most of the time you want all the links to be encrypted. What's the use of a secure last-mile when the origin isn't?

Since backend servers will usually be running internet-facing web-servers, HTTPS on HTTP/2 is already included. I'm sure the certificate checking can be skipped though in certain cases but the overall required by default mode is much better than HTTP/1 now.

Reply on news.ycombinator.com