# HTTP/2 --- ### HTTP/2 * A take on improving on HTTP/1.1 downsides * Mixed success: still uses TCP, does not always speed things up * Designed to be interoperable with HTTP/1.1 (same message semantics) * GRPC uses HTTP/2 as its main transport --- | Aspect | HTTP/2 | HTTP/1.1 | |--------|--------|----------| | Encoding | Binary | Text | | Headers | Compressed | Plain | | Parallelism | Streams inside a connection^1^ | No^2^ | | Prioritization and flow control | Yes^3^ | No^4^ | | Server-pushed requests | Yes^5^ | No^6^ | | Message cancellation | Yes | No^7^ | ---- #### Footnote 1: TCP in HTTP/2 HTTP/2 uses TCP, so a few lost/misordered/delayed packets in a TCP connection would slow down every in-flight request inside This is why HTTP/2 does not always win in latency A/B tests ---- #### Footnote 2: Parallelism in HTTP/1.1 Parallelism in HTTP/1.1 can be achieved by opening multiple connections Browsers have strict limits on how many TCP connections can be opened at once These limits can be avoided by using multiple domains ---- #### Footnote 3: Prioritization in HTTP/2 The HTTP/2 standard defines a response prioritization mechanism It is essential to web page load performance Most real-world implementations do not fully implement the standard ---- #### Footnote 4: Prioritization in HTTP/1.1 Browsers prioritize downloads in HTTP/1.1 by choosing which resources to request and/or receive first ---- #### Footnote 5: Server-side pushes in HTTP/2 HTTP/2 server-side push mechanism is a part of the Web Push standard Despite marketing it is mostly useless as a web page optimization Some browsers have already deprecated it Also, server-side pushes are not used in GRPC ---- #### Footnote 6: Ways to do server-side pushes Ways to emulate server-pushed communication: * Polling * ServiceWorker Sync * Long Polling * Server Sent Events * Websocket * Web/Mobile Pushes All these things can also be done in HTTP/2 ---- #### Footnote 7: Cancelling a message in HTTP/1.1 Usually done by closing the TCP stream This is why HTTP/2 TCP connections are much more long-lived than in HTTP/1.1 It means less TCP+TLS handshakes and avoiding the "slow-start" TCP mode --- ### Binary framing  --- ### Streams, messages, and frames  --- ### Header Compression  --- ### Parallel requests in HTTP/1.1  --- ### Same parallel requests in HTTP/2  --- ### Server push  --- ### Links * ["High Performance Browser Networking"](https://hpbn.co/) book which I highly recommend as an introdution to the end-user networking perspective * [RFC 7540](https://www.rfc-editor.org/rfc/rfc7540) * [GRPC on HTTP/2](https://grpc.io/blog/grpc-on-http2/) ---- ### Also used pictures from * ["HTTP/2 In Action"](https://livebook.manning.com/book/http2-in-action/) book * [HTTP/2 presentation by Ilya Gorelik](https://docs.google.com/presentation/d/1r7QXGYOLCh4fcUq0jDdDwKJWNqWK1o4xMtYpKZCJYjM/present)