The --backend-tls-sni-field is deprecated in favor of sni keyword.
--backend-tls-sni-field still works, and it overrides all sni keyword
in --backend option. But it will be removed in the future release.
Previously, we use one Http2Session object per DownstreamAddrGroup.
This is not flexible, and we have to provision how many HTTP/2
connection is required in advance. The new strategy is we add
Http2Session object on demand. We measure the number of attached
downstream connection object and server advertised concurrency limit.
As long as former is smaller than the latter, we attach new downstream
connection to it. Once the limit is reached, we create new
Http2Session object. If the number lowers the limit, we start to
share Http2Session object again.
To achieve host-path backend routing, we changed behaviour of
--backend-http2-connections-per-worker. It now sets the number of
HTTP/2 physical connections per pattern group if pattern is used in -b
option.
Fixes GH-292
-b option syntax is now <HOST>,<PORT>[;<PATTERN>[:...]]. The optional
<PATTERN>s specify the request host and path it is used for. The
<PATTERN> can contain path, host + path or host. The matching rule is
closely designed to ServeMux in Go programming language.
Currently, we use same number of HTTP/2 sessions per worker with given
backend addresses. New option to specify the number of HTTP/2 session
per worker will follow.
When same SSL_CTX is used by multiple thread simultaneously we have to
setup some number of mutex locks for it. We could not check how this
locking affects scalability since we have 4 cores at best in our
development machine. Good side of sharing SSL_CTX across threads is
we can share session ID pool.
If --tls-ctx-per-worker is enabled, SSL_CTX is created per thread
basis and we can eliminate mutex locks. The downside is session ID is
no longer shared, which means if session ID generated by one thread
cannot be acceptable by another thread. But we have now session
ticket enabled and its keys are shared by all threads.
For HTTP/1 backend, -b option can be used several times to specify
multiple backend address. HTTP/2 backend does not support multiple
addresses and only uses first address even if multiple addresses are
specified.