HTTP2: different domain but same IP, multiple connection or one connection?
As @mata says this is up to the client.
However one clear use case is in connection coalescing.
Under HTTP/1.1 domains were often sharded (e.g. www.example.com might also have a static.example.com domain for serving static assets). This was for two reasons:
- To break the 6-8 connection limit per domain that browsers often used and allow more downloads in parallel.
- To have so called "cookie-less" domains which saved on the overhead of sending these HTTP headers for static assets that didn't need them (e.g. images, css, javascript).
Under HTTP/2 there is one connection and the limit on parallel downloads is the stream limit which is much higher (usually 100-150 though can also be unlimited). Additionally with HPACK header compression large cookies cause less of a performance hit (though there can still be security issues which can be another reason for cookie-less domains).
So, should we just give up on sharded domains completely now? What about those clients that cannot support HTTP/2? While support is very good it is not universal and those behind proxy connections (e.g. corporate connections or antivirus software) often cannot use this even if their browsers can.
Connection coalescing is used by browsers to collapse near identical connections (usually those with the same IP address and same TLS certificate) into one connection rather than opening a single one when using HTTP/2 and allows HTTP/1.1 connections to continue seeing these as separate domains. Daniel Haxx has the best blog post on how this is actually implemented by browsers(though it's about a year and a half old at the time of writing so this may have changed). To summarise it, Chrome uses it as you'd expect, Firefox is (overly?) aggressive about coalescing in as many circumstances as it can (and maybe some that it shouldn't!) and Edge and Safari don't do coalescing at all.
If a connection is coalesced when it shouldn't be, the server can respond with a 421 HTTP Status code which basically means "What are you doing, that's not a request for me!!" and the browser can then try again with a separate connection.
It also looks like that HTTP/2 will shortly add the ORIGIN Frame which will allow the server to respond to any request with a "hey, I can also serve you api.example.com requests if you want" style message. Even if the IP address doesn't match (which has some people concerned about the security implications of that!).
While we're on the topic, it's not always the case that as single domain will always use one connection either. Read Jake Archibald's excellent post on HTTP/2 Push which shows that there are various circumstances when that's not the case (summarised as: for non-credentialed requests, when having the same domain open in a separate tab in Edge, or randomly even on the same tab for Safari).
That depends on the client.
http://httpwg.org/specs/rfc7540.html#HttpExtra
Clients SHOULD NOT open more than one HTTP/2 connection to a given host and port pair, where the host is derived from a URI, a selected alternative service [ALT-SVC], or a configured proxy.
...
A client MAY open multiple connections to the same IP address and TCP port using different Server Name Indication [TLS-EXT] values or to provide different TLS client certificates but SHOULD avoid creating multiple connections with the same configuration.
...
Connections that are made to an origin server, either directly or through a tunnel created using the CONNECT method (Section 8.3), MAY be reused for requests with multiple different URI authority components. A connection can be reused as long as the origin server is authoritative (Section 10.1). For TCP connections without TLS, this depends on the host having resolved to the same IP address.
So there's not really a hard requirement, so if a client has very good reasons for making multiple connections instead of reusing one it is allowed to do so.
Specially if both domains use a different TLS certificate (not one where both names are present as SubjectAltNames) I'd expect to see a separate connection for each.
We had issues with this
Test setup with multiple environments on different servers behind a load balancer
- test1.domain
- test2.domain
- testx.domain
e.g. switching from test1.domain.com to test2.domain.com gave a 404 error or not authorized
The issue occurs because the load balancer expects the client to add an SNI extension with the hostname contained, e.g. test1.domain.com
In the first call against the load balancer, SNI name is included, subsequently, the chrome browser is pointed to another environment test2.domain.com, chrome does not send SNI extension test2.domain.com and therefore the traffic is still routed test1.domain.com
Since the server that holds test1.domain.com does not know test2.domain.com, a 404 return is sent to chrome.
Either each service on the load balancer must be reconfigured with its own IP address or implementation of return code 421 needs to be done.See https://daniel.haxx.se/blog/2016/08/18/http2-connection-coalescing/Section: Surprises and a way to mitigate them (Implementation of HTTP status code 421)