grpc uses it for streaming. This means the if you use grpc for RPC, you are not limited to sending one request object and get one reply object but there can be

grpc uses it for streaming. This means the if you use grpc for RPC, you are not limited to sending one request object and get one reply object but there can be a stream of request and reply objects in each direction. You can e.g. make things like server-sent-events or some websocket use-cases superfluos with that. E.g. you send an empty request body (headers contain the method you want to call) and get a stream of status updates (events, chat messages, ...) in the response stream. However this is not something that is limited to HTTP/2. In principal you could do the same with HTTP/1 as the request and response bodies were also already streams. However there are some limitations to that: At first most HTTP/1 implementations do only allow a certain amount of parallel HTTP connections, which means long-running streams are not useful because they block off other requests. The second issue is that many HTTP library implementations (including XHR browser API and the current fetch API) do not allow to read the bodys in streaming form. This is also the blocker for having full grpc support in the browser. WIP browser APIs (fetch API with readable stream support) will allow to make use of these capabilities, for HTTP/2 and HTTP/1.