0

Sorry for what I think might be a silly question but:

My understanding of HTTP 2 is that you create a connection, establish TLS if you want to, then upgrade to 2, and do lots of little queries on that one connection :. getting a speed increase because you're not re-establishing connections and TLS.

If this is true, When it comes to sessions - is each request over the connection treated as an unique request and :. has cookies and headers, or whether they're all treated as sub-requests of the original request?

This has impact on proxies whether you could merge requests from clients into a single stream or not?

Jmons
  • 1,766
  • 17
  • 28

1 Answers1

1

My understanding of HTTP 2 is that you create a connection, establish TLS if you want to, then upgrade to 2

Not quite. If you use TLS then using HTTP/2 will be negotiated as part of the TLS negotiation. If you are not using TLS then you can upgrade but browsers only support HTTP/2 over HTTPS so that's the majority of the use cases.

When it comes to sessions - is each request over the connection treated as an unique request and :. has cookies and headers, or whether they're all treated as sub-requests of the original request?

Each request is part of what's call a stream in HTTP/2. It is a unique request, with it's own Cookies and Headers and is unrelated to the previous requests (though see note below for some caveats on this). Conceptually it's really no different than the fact that HTTP/1.1 allows you to send multiple unique, unrelated requests on the one connection - but unlike HTTP/1.1 multiple requests can all be in transit at the same time in HTTP/2 thanks to multiplexing.

This diagram might help explain it: https://freecontent.manning.com/mental-model-graphic-how-is-http-1-1-different-from-http-2/

This has impact on proxies whether you could merge requests from clients into a single stream or not?

I'm not sure what you mean by this?


Note: While HTTP/2 requests are independent of each other and HTTP is still stateless at a higher level, there are a few places when you go lower level where the strict wording of that could be challenged and where there is technically some connection between the requests. For example:

  • HTTP/2 actually uses HPACK header compression to compress HTTP headers so if the same header is sent twice on different requests (e.g. the same cookie) then the second call will include a reference to the previously received header, rather than repeat the data.
  • Each request has a unique stream id, which is an increasing integer which is either odd (client initiated) or even (server initiated) so of course the stream ids must be managed by the HTTP/2 implementation so arguable.
  • HTTP/2 push resources are pushed in response to a previous request stream id.

But these are all really just connection level issues and efficiencies. To a HTTP/2 user (e.g. a web developer) each HTTP/2 request is as independent as it was under HTTP/1.1 and HTTP is still stateless.

Barry Pollard
  • 40,655
  • 7
  • 76
  • 92
  • Thank you for that clear answer: So I think my understanding is right, even if my expression of it is a little fuzzy. What I am interested in is whether you can make a reverse-proxy, where the proxy -> server connection might be HTTP/2, but the client -> proxy connections may or may not be (i.e. you might have multiple clients connected to the proxy which has merged them into the same HTTP/2 connection, irrelevant of whether the first connection was HTTP/2 or not. – Jmons Sep 20 '18 at 12:49
  • Very few things allow backend connections (i..e reverse proxy to server) at the moment. Apache has an experimental mod_proxy_http2 but most others don't. So most connections are `Client-->HTTP/2-->Proxy-->HTTP/1.1-->Server`. As they are two connections they can be two different protocols. So client to reverse proxy can be all HTTP/2 or a mix of HTTP/2 and HTTP/1.1. A TCP loadbalancer would work differently and would just send on the TCP packets allowing HTTP/2 all the way through but then you wouldn't be sharing the same connection from reverse proxy to server with other connections. – Barry Pollard Sep 20 '18 at 12:58
  • Indeed. thats why this question is more theoretical at this point in time. I'm not convinced that anyone would ever *want* to make a merging one (if someone had insane performance requirements, I suspect the answer would be to flip from http to something else like the newer ASGI type stuff.) Thank you again though! – Jmons Sep 20 '18 at 13:21