Within HTTP2:
So when request one html page, with multiple domains(www.example.com, api.example.com...), it is said, there will be multiple connections.
but what if these domains share one same IP? Are there still multiple connections?
It is not possible to provide two domain names for the same Server IP address and get two different SSL certificates (one for each domain name). Also note that the use of Host Headers (which is how you can use a single IP for more than one SSL enabled domain) is not recommended for E-Commerce sites.
This is possible because when a web browser requests a resource from a web server using HTTP/1.1 it includes the requested hostname as part of the request. The server uses this information to determine which web site to show the user.
To speed up web performance, both HTTP/1.1 and HTTP/2 compress HTTP messages to make them smaller. However, HTTP/2 uses a more advanced compression method called HPACK that eliminates redundant information in HTTP header packets. This eliminates a few bytes from every HTTP packet.
HTTP2 is more secure as it uses binary protocol instead of plaintext. HTTP/2 allows the user to have a better web experience by reducing the page load time considerably. It needs the header to be sent just once in binary codes to increase speed.
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:
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With