0

This passage claims that the binary frame layer becomes the base for multiplexing in http for TCP connection, which is confusing to me.

https://developers.google.com/web/fundamentals/performance/http2#design_and_technical_goals

The confusing part is the HTTP client can just send more requests in one TCP connection without waiting for the response and receive the response for the corresponding request. That is the "frame" is the request and response. So why should it add the binary frame?

maki
  • 477
  • 2
  • 12

1 Answers1

2

Let's have a look at what you're suggesting:

the HTTP client can just send more requests in one TCP connection without waiting for the response

So far, so good: I can send "GET /foo" and then immediately "GET /bar" on the same connection.

and receive the response for the corresponding request

So, the server replies "200 OK" with some HTML content, and ... wait, is that for "/foo" or "/bar"? The key word in your own description is "corresponding" - we need some way of saying "this response corresponds to request #1".

And then, halfway through sending the first response, the server finishes handling the other request, and is ready to send part of a different response; but if it jumps in with "200 OK", that's going to appear to be part of the response it's already sending. So we also need to be able to say "this is the start of a new response", and "this content is the continuation of response #2".

To do that, we need a new abstraction: a frame, with a header which can encode details like "the next 100 bytes are the start of response #2, which corresponds to request #1". (I'm not sure if that's exactly how an HTTP/2 frame works, but I think it's roughly the principle.)

We could do that and still keep the protocol human readable (which is what we really mean by "text-based" vs "binary") but there's going to be a lot of these frame headers, so the shorter we can make them, the better. So if we're interested in performance, we can give up on "human readable" as a requirement, and we end up with a binary framing protocol like HTTP/2.

IMSoP
  • 89,526
  • 13
  • 117
  • 169
  • Great answer! I might also have touched on the asynchronicity between request and response with HTTP2, i.e the server may well respond to requests completely out of order, or may not respond until several requests have been filed, the framing is important to match request to response. – Tom Mettam Jan 13 '22 at 10:20
  • thanks, and your explanation seems very reasonable to me! – maki Jan 13 '22 at 10:23
  • I have a follow-up question about the "binary", so the binary has nothing to do with the content-encoding just the frame headers? Because we can use just pb encoding with HTTP 1.1, and I cannot tell what the binary frame of h2 helps with it. – maki Jan 13 '22 at 10:25
  • 1
    @makiXIE As I say in the answer, "binary" just means "not making an effort to be human readable". If you're designing a new protocol to be as efficient as possible, you don't bother building it in ASCII and then looking for clever compression; you just define something like "the first byte is the frame type, then next 2 bytes are the frame size, ..." The _content_ is not HTTP's responsibility - it can't redefine HTML to be a binary format; nor can it easily replace the existing text-based headers, so it just compresses them (HPACK). – IMSoP Jan 13 '22 at 10:27