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.
The existing options --{read,write}-{rate,burst} are per connection.
The new options --worker-{read,write}-{rate,burst} are per worker
thread, which is overall rate limit of all connections worker handles.
This option specifies additional certificate and private key
file. Shrpx will choose certificates based on the hostname indicated
by client using TLS SNI extension. This option can be used multiple
times.
The -k, --insecure option is added to skip this verification. The
system wide trusted CA certificates will be loaded at startup. The
--cacert option is added to specify the trusted CA certificate file.
With --client-mode option, shrpx now accepts unencrypted HTTP
connections and communicates with backend server in SPDY. In short,
this is the "reversed" operation mode against normal mode. This may
be useful for testing purpose because it can sit between HTTP client
and shrpx "normal" mode.
To distinguish the to-be-installed programs and non-installable
example source code, the former programs, spdycat, spdydyd and shrpx,
were moved to src directory. spdynative was removed from Makefile
because it does not appeal to any users much.
Tatsuhiro Tsujikawa