The HTTP limits must be extended by stream_rate, stream_burst and concurrent_streams just similar to equal connection limits.

Tempesta should send SETTINGS_MAX_CONCURRENT_STREAMS in SETTINGS frame when initializing connection with client.

Please enable http2_general.test_h2_streams.TestH2Stream.test_max_concurrent_stream test after fixes

During developing this task we should don't forget to change

if (closed_streams->num <= TFW_MAX_CLOSED_STREAMS
    || (max_streams == ctx->streams_num
	&& closed_streams->num))
``
in `tfw_h2_closed_streams_shrink`

Related CVE and security advisory GHSA-93p3-5r25-4p75

1. First of all we must not implement stream_rate, stream_burst, we have request_rate/burst that works the same.
2. response_timeout it's very doubtful. It can help us only if limit whole connection lifetime, without any updates during connection lifetime. For example: Slow read client opens connection with 100 streams, stream 1 sends request, Tempesta scheduled it to upstream. Start response_timeout, if response timeout exceeded, reset connection.
   Cons of this method:
   1. We always must know how many time will take transferring of largest file with slowest client.
   2. It's per-connection not per-stream.

However, it seems in current task we must implement rate limits for SETTINGS, PING and maybe WINDOW_UPDATE frame. But let's start from SETTINGS and PING. WINDOW_UPDATE requires some discussion, because it's not so easy and maybe it not worth it. For instance, client can send unlimited number of WINDOW_UPDATE frames to closed streams, that also not good.

After some discussion, we came to the conclusion that we need one timer per connection and bitfield that indicates stream stream being read in the timer interval. On every shot timer clears bitfield. However this doesn't look like complete solution.

For "slow read":
The slow-read attack affects the CPU, memory, and incoming connection pool. So #498 does not cover the issue.

A simple solution:

1. define a frang limit: client_read_timeout <timeout> <min_rate>
2. HEADERS/CONTINUATION/DATA frames sending will count the sending bytes of the current stream
3. reuse the keep-alive timer, and set it as 1 second resolution
4. in the timer callback, we iterate all streams and update their rates, if the rate of any stream is lower than the <min_rate>, we increase the duration, and if the accumulated duration is over <timeout>, we abort the connection and stop the iteration.
5. works for any response slow-read cases (e.g. tcp-level slow-read, small sockbuf) and HTTP versions.

It works similarly to apache httpd, but here we aim at the response direction and use and condition to combine the <timeout> and <min_rate>.

For "HTTTP/2 flood prevention":
I doubt the low-rate service frames like PING can form the DOS, so maybe we just focus on the high-rate case? That is the PING flood, as well as SETTING (as suggested by @const-t, we can postpone handling WINDOW_UPDATE).

A simple solution:
We add timing history for service frames (so far, only PING and SETTING) just like HEADERS and enforce it in frang.

In this issue must be implemented fixes for following CVEs:
CVE-2019-9511 “Data Dribble”
CVE-2019-9517 “Internal Data Buffering”
CVE-2019-9512 “Ping Flood”
CVE-2019-9515 “Settings Flood”

Crucial since DDoS affects our installation