Assume http2 connection by default, instead of http1

[ayush1794]

Since most of the servers now conform to http2, the change here updates the behaviour of assuming the connection to be http2 and not http1 by default. It will migrate to http1 if the server only supports http1.
One can set the httpVersion in ClientConfiguration to .http1Only which will start with http1 instead of http2.

Additional Changes:

• Fixed an off by one error in the maximum additional general purpose connection check
• Updated tests

[czechboy0]

@swift-server-bot test this please

[dnadoba]

@swift-server-bot add to allowlist

[dnadoba]

LGTM. I'm wondering if we need to expose this settings not only through .http1Only but rather as initial preference that starts with http1 but still allows http2. @weissi what do you think?

[weissi]

LGTM. I'm wondering if we need to expose this settings not only through .http1Only but rather as initial preference that starts with http1 but still allows http2. @weissi what do you think?

TIL that we're not already doing that. Seems sensible to default to HTTP/2.

Regarding the 'prefer H1' override in public API: Yes, we'll likely need that but that could also be a follow-up?

[dnadoba]

Yes, we'll likely need that but that could also be a follow-up?

agree

[ayush1794]

Regarding the 'prefer H1' override in public API: Yes, we'll likely need that but that could also be a follow-up?

Just out of curiosity what would be a real use case for this?
If we do this, we should likely also need to change the ALPN ordering in that case to prefer h1 over h2 when TLS is needed (though again not sure of a TLS use case on h1)

[weissi]

Regarding the 'prefer H1' override in public API: Yes, we'll likely need that but that could also be a follow-up?

Just out of curiosity what would be a real use case for this? If we do this, we should likely also need to change the ALPN ordering in that case to prefer h1 over h2 when TLS is needed (though again not sure of a TLS use case on h1)

Four reasons come to mind:

1. At the moment you can instruct AHC to create an arbitrary amount of HTTP/1.1 connections to a given host. That means you can for example have 1,000 concurrent requests to a given server. But at present, with H2, AHC will only ever do one connection which usually allows up to 100 concurrent requests (technically negotiated using MAX_CONCURRENT_STREAMS but in practice it's always 100)
2. Buggy software where HTTP/1.1 works better than HTTP/2 but the software claims to support HTTP/2
3. (very) Low-latency connections: HTTP/1.1 can be performant than HTTP/2 if you have essentially 0 latency (e.g. on localhost). HTTP/2 trades off more CPU usage on client & server for fewer roundtrips. That's usually a good tradeoff but the lower the latency, the worse it gets.
4. Integration tests for server software that wants to check that HTTP/1.x also works. Of course this means we shouldn't actually have a preferHTTP1: Bool but rather {prefer,require}HTTPProtocolVersion: .v1_1 | .v2 | .v1_0

though again not sure of a TLS use case on h1

Today, the vast vast majority of (non-localhost) HTTP/1.x connections are via TLS. I'm not even sure if HTTP/2 is actually more prevalent on the internet than HTTP/1.1, haven't checked. Addition: Actually H2 and H3 should actually be more prevalent given that most of the internet sits behind the same handful of CDNs/Edges which will support H2, even if the upstream servers may only do H1.

[ayush1794]

@swift-server-bot test this please

[fabianfett]

why did you remove el2 here?

[ayush1794]

This is because we now directly start with h2 rather than h1 and then migrating to h1.
h2 has checks to not allow creating connections for same EL. The second el2 just fails the test because the check fails.

[fabianfett]

Thanks for pushing this through!