test-example-projects/c_projects/19wnuster/doc/design-thoughts/http2.txt

2014/10/23 - design thoughts for HTTP/2

- connections : HTTP/2 depends a lot more on a connection than HTTP/1 because a
  connection holds a compression context (headers table, etc...). We probably
  need to have an h2_conn struct.

- multiple transactions will be handled in parallel for a given h2_conn. They
  are called streams in HTTP/2 terminology.

- multiplexing : for a given client-side h2 connection, we can have multiple
  server-side h2 connections. And for a server-side h2 connection, we can have
  multiple client-side h2 connections. Streams circulate in N-to-N fashion.

- flow control : flow control will be applied between multiple streams. Special
  care must be taken so that an H2 client cannot block some H2 servers by
  sending requests spread over multiple servers to the point where one server
  response is blocked and prevents other responses from the same server from
  reaching their clients. H2 connection buffers must always be empty or nearly
  empty. The per-stream flow control needs to be respected as well as the
  connection's buffers. It is important to implement some fairness between all
  the streams so that it's not always the same which gets the bandwidth when
  the connection is congested.

- some clients can be H1 with an H2 server (is this really needed ?). Most of
  the initial use case will be H2 clients to H1 servers. It is important to keep
  in mind that H1 servers do not do flow control and that we don't want them to
  block transfers (eg: post upload).

- internal tasks : some H2 clients will be internal tasks (eg: health checks).
  Some H2 servers will be internal tasks (eg: stats, cache). The model must be
  compatible with this use case.

- header indexing : headers are transported compressed, with a reference to a
  static or a dynamic header, or a literal, possibly huffman-encoded. Indexing
  is specific to the H2 connection. This means there is no way any binary data
  can flow between both sides, headers will have to be decoded according to the
  incoming connection's context and re-encoded according to the outgoing
  connection's context, which can significantly differ. In order to avoid the
  parsing trouble we currently face, headers will have to be clearly split
  between name and value. It is worth noting that neither the incoming nor the
  outgoing connections' contexts will be of any use while processing the
  headers. At best we can have some shortcuts for well-known names that map
  well to the static ones (eg: use the first static entry with same name), and
  maybe have a few special cases for static name+value as well. Probably we can
  classify headers in such categories :

    - static name + value
    - static name + other value
    - dynamic name + other value

  This will allow for better processing in some specific cases. Headers
  supporting a single value (:method, :status, :path, ...) should probably
  be stored in a single location with a direct access. That would allow us
  to retrieve a method using hdr[METHOD]. All such indexing must be performed
  while parsing. That also means that HTTP/1 will have to be converted to this
  representation very early in the parser and possibly converted back to H/1
  after processing.

  Header names/values will have to be placed in a small memory area that will
  inevitably get fragmented as headers are rewritten. An automatic packing
  mechanism must be implemented so that when there's no more room, headers are
  simply defragmented/packet to a new table and the old one is released. Just
  like for the static chunks, we need to have a few such tables pre-allocated
  and ready to be swapped at any moment. Repacking must not change any index
  nor affect the way headers are compressed so that it can happen late after a
  retry (send-name-header for example).

- header processing : can still happen on a (header, value) basis. Reqrep/
  rsprep completely disappear and will have to be replaced with something else
  to support renaming headers and rewriting url/path/...

- push_promise : servers can push dummy requests+responses. They advertise
  the stream ID in the push_promise frame indicating the associated stream ID.
  This means that it is possible to initiate a client-server stream from the
  information coming from the server and make the data flow as if the client
  had made it. It's likely that we'll have to support two types of server
  connections: those which support push and those which do not. That way client
  streams will be distributed to existing server connections based on their
  capabilities. It's important to keep in mind that PUSH will not be rewritten
  in responses.

- stream ID mapping : since the stream ID is per H2 connection, stream IDs will
  have to be mapped. Thus a given stream is an entity with two IDs (one per
  side). Or more precisely a stream has two end points, each one carrying an ID
  when it ends on an HTTP2 connection. Also, for each stream ID we need to
  quickly find the associated transaction in progress. Using a small quick
  unique tree seems indicated considering the wide range of valid values.

- frame sizes : frame have to be remapped between both sides as multiplexed
  connections won't always have the same characteristics. Thus some frames
  might be spliced and others will be sliced.

- error processing : care must be taken to never break a connection unless it
  is dead or corrupt at the protocol level. Stats counter must exist to observe
  the causes. Timeouts are a great problem because silent connections might
  die out of inactivity. Ping frames should probably be scheduled a few seconds
  before the connection timeout so that an unused connection is verified before
  being killed. Abnormal requests must be dealt with using RST_STREAM.

- ALPN : ALPN must be observed on the client side, and transmitted to the server
  side.

- proxy protocol : proxy protocol makes little to no sense in a multiplexed
  protocol. A per-stream equivalent will surely be needed if implementations
  do not quickly generalize the use of Forward.

- simplified protocol for local devices (eg: haproxy->varnish in clear and
  without handshake, and possibly even with splicing if the connection's
  settings are shared)

- logging : logging must report a number of extra information such as the
  stream ID, and whether the transaction was initiated by the client or by the
  server (which can be deduced from the stream ID's parity). In case of push,
  the number of the associated stream must also be reported.

- memory usage : H2 increases memory usage by mandating use of 16384 bytes
  frame size minimum. That means slightly more than 16kB of buffer in each
  direction to process any frame. It will definitely have an impact on the
  deployed maxconn setting in places using less than this (4..8kB are common).
  Also, the header list is persistent per connection, so if we reach the same
  size as the request, that's another 16kB in each direction, resulting in
  about 48kB of memory where 8 were previously used. A more careful encoder
  can work with a much smaller set even if that implies evicting entries
  between multiple headers of the same message.

- HTTP/1.0 should very carefully be transported over H2. Since there's no way
  to pass version information in the protocol, the server could use some
  features of HTTP/1.1 that are unsafe in HTTP/1.0 (compression, trailers,
  ...).

- host / :authority : ":authority" is the norm, and "host" will be absent when
  H2 clients generate :authority. This probably means that a dummy Host header
  will have to be produced internally from :authority and removed when passing
  to H2 behind. This can cause some trouble when passing H2 requests to H1
  proxies, because there's no way to know if the request should contain scheme
  and authority in H1 or not based on the H2 request. Thus a "proxy" option
  will have to be explicitly mentioned on HTTP/1 server lines. One of the
  problem that it creates is that it's not longer possible to pass H/1 requests
  to H/1 proxies without an explicit configuration. Maybe a table of the
  various combinations is needed.

                           :scheme   :authority   host
       HTTP/2 request      present   present      absent
       HTTP/1 server req   absent    absent       present
       HTTP/1 proxy req    present   present      present

  So in the end the issue is only with H/2 requests passed to H/1 proxies.

- ping frames : they don't indicate any stream ID so by definition they cannot
  be forwarded to any server. The H2 connection should deal with them only.

There's a layering problem with H2. The framing layer has to be aware of the
upper layer semantics. We can't simply re-encode HTTP/1 to HTTP/2 then pass
it over a framing layer to mux the streams, the frame type must be passed below
so that frames are properly arranged. Header encoding is connection-based and
all streams using the same connection will interact in the way their headers
are encoded. Thus the encoder *has* to be placed in the h2_conn entity, and
this entity has to know for each stream what its headers are.

Probably that we should remove *all* headers from transported data and move
them on the fly to a parallel structure that can be shared between H1 and H2
and consumed at the appropriate level. That means buffers only transport data.
Trailers have to be dealt with differently.

So if we consider an H1 request being forwarded between a client and a server,
it would look approximately like this :

  - request header + body land into a stream's receive buffer
  - headers are indexed and stripped out so that only the body and whatever
    follows remain in the buffer
  - both the header index and the buffer with the body stay attached to the
    stream
  - the sender can rebuild the whole headers. Since they're found in a table
    supposed to be stable, it can rebuild them as many times as desired and
    will always get the same result, so it's safe to build them into the trash
    buffer for immediate sending, just as we do for the PROXY protocol.
  - the upper protocol should probably provide a build_hdr() callback which
    when called by the socket layer, builds this header block based on the
    current stream's header list, ready to be sent.
  - the socket layer has to know how many bytes from the headers are left to be
    forwarded prior to processing the body.
  - the socket layer needs to consume only the acceptable part of the body and
    must not release the buffer if any data remains in it (eg: pipelining over
    H1). This is already handled by channel->o and channel->to_forward.
  - we could possibly have another optional callback to send a preamble before
    data, that could be used to send chunk sizes in H1. The danger is that it
    absolutely needs to be stable if it has to be retried. But it could
    considerably simplify de-chunking.

When the request is sent to an H2 server, an H2 stream request must be made
to the server, we find an existing connection whose settings are compatible
with our needs (eg: tls/clear, push/no-push), and with a spare stream ID. If
none is found, a new connection must be established, unless maxconn is reached.

Servers must have a maxstream setting just like they have a maxconn. The same
queue may be used for that.

The "tcp-request content" ruleset must apply to the TCP layer. But with HTTP/2
that becomes impossible (and useless). We still need something like the
"tcp-request session" hook to apply just after the SSL handshake is done.

It is impossible to defragment the body on the fly in HTTP/2. Since multiple
messages are interleaved, we cannot wait for all of them and block the head of
line. Thus if body analysis is required, it will have to use the stream's
buffer, which necessarily implies a copy. That means that with each H2 end we
necessarily have at least one copy. Sometimes we might be able to "splice" some
bytes from one side to the other without copying into the stream buffer (same
rules as for TCP splicing).

In theory, only data should flow through the channel buffer, so each side's
connector is responsible for encoding data (H1: linear/chunks, H2: frames).
Maybe the same mechanism could be extrapolated to tunnels / TCP.

Since we'd use buffers only for data (and for receipt of headers), we need to
have dynamic buffer allocation.

Thus :
- Tx buffers do not exist. We allocate a buffer on the fly when we're ready to
  send something that we need to build and that needs to be persistent in case
  of partial send. H1 headers are built on the fly from the header table to a
  temporary buffer that is immediately sent and whose amount of sent bytes is
  the only information kept (like for PROXY protocol). H2 headers are more
  complex since the encoding depends on what was successfully sent. Thus we
  need to build them and put them into a temporary buffer that remains
  persistent in case send() fails. It is possible to have a limited pool of
  Tx buffers and refrain from sending if there is no more buffer available in
  the pool. In that case we need a wake-up mechanism once a buffer is
  available. Once the data are sent, the Tx buffer is then immediately recycled
  in its pool. Note that no tx buffer being used (eg: for hdr or control) means
  that we have to be able to serialize access to the connection and retry with
  the same stream. It also means that a stream that times out while waiting for
  the connector to read the second half of its request has to stay there, or at
  least needs to be handled gracefully. However if the connector cannot read
  the data to be sent, it means that the buffer is congested and the connection
  is dead, so that probably means it can be killed.

- Rx buffers have to be pre-allocated just before calling recv(). A connection
  will first try to pick a buffer and disable reception if it fails, then
  subscribe to the list of tasks waiting for an Rx buffer.

- full Rx buffers might sometimes be moved around to the next buffer instead of
  experiencing a copy. That means that channels and connectors must use the
  same format of buffer, and that only the channel will have to see its
  pointers adjusted.

- Tx of data should be made as much as possible without copying. That possibly
  means by directly looking into the connection buffer on the other side if
  the local Tx buffer does not exist and the stream buffer is not allocated, or
  even performing a splice() call between the two sides. One of the problem in
  doing this is that it requires proper ordering of the operations (eg: when
  multiple readers are attached to a same buffer). If the splitting occurs upon
  receipt, there's no problem. If we expect to retrieve data directly from the
  original buffer, it's harder since it contains various things in an order
  which does not even indicate what belongs to whom. Thus possibly the only
  mechanism to implement is the buffer permutation which guarantees zero-copy
  and only in the 100% safe case. Also it's atomic and does not cause HOL
  blocking.

It makes sense to chose the frontend_accept() function right after the
handshake ended. It is then possible to check the ALPN, the SNI, the ciphers
and to accept to switch to the h2_conn_accept handler only if everything is OK.
The h2_conn_accept handler will have to deal with the connection setup,
initialization of the header table, exchange of the settings frames and
preparing whatever is needed to fire new streams upon receipt of unknown
stream IDs. Note: most of the time it will not be possible to splice() because
we need to know in advance the amount of bytes to write the header, and here it
will not be possible.

H2 health checks must be seen as regular transactions/streams. The check runs a
normal client which seeks an available stream from a server. The server then
finds one on an existing connection or initiates a new H2 connection. The H2
checks will have to be configurable for sharing streams or not. Another option
could be to specify how many requests can be made over existing connections
before insisting on getting a separate connection. Note that such separate
connections might end up stacking up once released. So probably that they need
to be recycled very quickly (eg: fix how many unused ones can exist max).