Henry Pan (HP) wrote:
*1. HTTP/2 multiplexing*
|src_conn_cur| counts /streams/, not TCP connections.
So in your example, if a client opens a single TCP connection and
issues 20 parallel HTTP/2 streams, |src_conn_cur| will indeed show
*20*. This is expected, since the counter reflects concurrent request
streams associated with the source, not the underlying transport
connection.
If you want a metric that reflects only the number of TCP connections,
the counters to look at are the ones tied to connection-level tracking
(e.g., stick tables using |conn_rate|, |conn_cur|, etc.), which
operate strictly at the TCP layer and won’t multiply with HTTP/2 streams.
On the topic of this distinction between streams within a multiplexed
connection and separate connection, I hope someone can help me to
understand how this can work for HTTP/3.
For HTTP/1.1 and HTTP/2, one can use something along the lines of
"tcp-request connection track-sc" even on a HTTP-mode frontend to get a
count of parallel open TCP connections from a certain IP address (or a
number of IP addresses, using "src,ipmask()", for that matter). This
way, abnormal amounts of parallel TCP connections can be detected and
handled, as is often necessary in case of Layer 7 DDoS attacks. I've
found that these may involve massive numbers of parallel HTTP/2
connections from the same IP addresses.
However, for QUIC-based connections, I have not found a way to determine
the number of parallel HTTP/3 connections that may be active from a
certain IP address (or set of IP addresses). So my question is how
others are handling this? Am I overlooking a way to limit unwanted
parallel QUIC connections here? Ideally, I would like to do something
like "quic-initial reject if too_many_connections" to limit the number
of parallel HTTP/3 connections per IP address, before the TLS handshake
occurs. I know that established QUIC connections could migrate to
another source IP address while in use, so it's not easy to make an
exact count of QUIC connections per IP address, but for purposes of
rejecting massive parallel QUIC connections, a rough estimate per IP
address would probably suffice.
Jens
