3 ms·

What HTTP/2 features make it desirable for general RPC (no browser involved)? In the past I've found HTTP (1.1) to be okay, but not great for server->server RP

by cespare 12y ago

What HTTP/2 features make it desirable for general RPC (no browser involved)? In the past I've found HTTP (1.1) to be okay, but not great for server->server RPC. The semantics are fine (but overkill) and the overhead sort of sucks. With HTTP/2 I guess the performance should be a lot better (with a binary protocol); I'm still unsure about the HTTP semantics in a general RPC context. Anyone with deeper knowledge of HTTP/2 care to enlighten me? (Following up on a twitter conversation I had with @bradfitz: https://twitter.com/calebspare/status/571049339541270529 https://twitter.com/calebspare/status/571049339541270529)

a11r 12y ago
gRPC uses the following features from HTTP/2: Framing (needed to multiplex different RPCs on the same TCP connection), Flow Control (both intra-stream and connection-wide), HPAC (for compressing metadata that tends to be common across requests), and GoAway (to gracefully drain backends).
- cespare 12y ago
  Thanks! This is a good list.
dsymonds 12y ago
Streaming RPCs in both directions (client to server, and server to client) is one big feature. It's not really possible to do client-side streaming with HTTP/1.1, especially if you have proxies in the way. Independently framed messages make it a lot more feasible to implement other important RPC features like flow control too.
- cespare 12y ago
  Yeah, it's certainly more compelling than trying to build on HTTP 1.1. The alternative I had in mind was not using HTTP, though (for instance building some custom framed protocol on TCP, or open-sourcing some version of whatever Google uses internally for protobuf RPC.) a11r pointed out several interesting features of HTTP/2 that are put to good use in gRPC, though.
  - dsymonds 12y ago
    gRPC is based on the internal Stubby RPC system, and that works over HTTP/1.1 based on CONNECT and switching to raw TCP. That works well enough, but the HTTP/2 goodies are too good to pass up.
    - cespare 12y ago
      Great context, thanks. I'm excited to start using it :)
    - ejona86 12y ago
      And using HTTP/2 directly allows using HTTP/2-based load balancers and reverse proxies, which is a huge bonus.

by cespare 12y ago

a11r 12y ago

gRPC uses the following features from HTTP/2: Framing (needed to multiplex different RPCs on the same TCP connection), Flow Control (both intra-stream and connection-wide), HPAC (for compressing metadata that tends to be common across requests), and GoAway (to gracefully drain backends).

cespare 12y ago
Thanks! This is a good list.

dsymonds 12y ago

Streaming RPCs in both directions (client to server, and server to client) is one big feature. It's not really possible to do client-side streaming with HTTP/1.1, especially if you have proxies in the way. Independently framed messages make it a lot more feasible to implement other important RPC features like flow control too.

cespare 12y ago
Yeah, it's certainly more compelling than trying to build on HTTP 1.1. The alternative I had in mind was not using HTTP, though (for instance building some custom framed protocol on TCP, or open-sourcing some version of whatever Google uses internally for protobuf RPC.) a11r pointed out several interesting features of HTTP/2 that are put to good use in gRPC, though.
- dsymonds 12y ago
  gRPC is based on the internal Stubby RPC system, and that works over HTTP/1.1 based on CONNECT and switching to raw TCP. That works well enough, but the HTTP/2 goodies are too good to pass up.
  - cespare 12y ago
    Great context, thanks. I'm excited to start using it :)
  - ejona86 12y ago
    And using HTTP/2 directly allows using HTTP/2-based load balancers and reverse proxies, which is a huge bonus.