RepoMirrors
/
haproxy
mirror of http://git.haproxy.org/git/haproxy.git/
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
haproxy/reg-tests/connection/h2_glitches.vtc

118 lines
2.2 KiB
Plaintext
Raw Normal View History

MINOR: connection: add sample fetches to report per-connection glitches Now with fc_glitches and bc_glitches we can retrieve the number of detected glitches on a front or back connection. On the backend it can indicate a bug in a server that may induce frequent reconnections hence CPU usage in TLS reconnections, and on the frontend it may indicate an abusive client that may be trying to attack the stack or to fingerprint it. Small non-zero values are definitely expected and can be caused by network glitches for example, as well as rare bugs in the other component (or maybe even in haproxy). These should never be considered as alarming as long as they remain low (i.e. much less than one per request). A reg-test is provided.
2024-01-17 17:00:21 +00:00
# This test verifies that H2 anomalies counted as glitches are properly detected
# and fetched.
varnishtest "h2 glitches"
feature ignore_unknown_macro
# haproxy frontend
REGTESTS: enable -dW on almost all tests to fail on warnings Now that warnings were almost all removed, let's enable zero-warning via -dW. All tests were adjusted, but two: - mcli/mcli_start_progs.vtc: the programs section currently cannot be silenced - stats/stats-file.vtc: the warning comes from the stats file itself on comment lines. All other ones are now OK.
2024-11-19 06:11:02 +00:00
haproxy hap -arg '-dW' -conf {
MINOR: connection: add sample fetches to report per-connection glitches Now with fc_glitches and bc_glitches we can retrieve the number of detected glitches on a front or back connection. On the backend it can indicate a bug in a server that may induce frequent reconnections hence CPU usage in TLS reconnections, and on the frontend it may indicate an abusive client that may be trying to attack the stack or to fingerprint it. Small non-zero values are definitely expected and can be caused by network glitches for example, as well as rare bugs in the other component (or maybe even in haproxy). These should never be considered as alarming as long as they remain low (i.e. much less than one per request). A reg-test is provided.
2024-01-17 17:00:21 +00:00
defaults
REGTESTS: add missing timeouts to 30 tests No less than 30 tests were missing timeouts, preventing them from being started with zero-warning. Since they were not supposed to trigger, they have been set to 30s so as never to trigger, and now they do not produce any warning anymore.
2024-11-19 06:43:04 +00:00
timeout client 30s
timeout server 30s
timeout connect 30s
MINOR: connection: add sample fetches to report per-connection glitches Now with fc_glitches and bc_glitches we can retrieve the number of detected glitches on a front or back connection. On the backend it can indicate a bug in a server that may induce frequent reconnections hence CPU usage in TLS reconnections, and on the frontend it may indicate an abusive client that may be trying to attack the stack or to fingerprint it. Small non-zero values are definitely expected and can be caused by network glitches for example, as well as rare bugs in the other component (or maybe even in haproxy). These should never be considered as alarming as long as they remain low (i.e. much less than one per request). A reg-test is provided.
2024-01-17 17:00:21 +00:00
mode http
listen fe1
bind "fd@${fe1}" proto h2
MEDIUM: mux-h2: update session trackers with number of glitches We now update the session's tracked counters with the observed glitches. In order to avoid incurring a high cost, e.g. if many small frames contain issues, we batch the updates around h2_process_demux() by directly passing the difference. Indeed, for now all functions that increment glitches are called from h2_process_demux(). If that were to change, we'd just need to keep the value of the last synced counter in the h2c struct instead of the stack. The regtest was updated to verify that the 3rd client that does not cause issue still sees the counter resulting from client 2's mistakes. The rate is also verified, considering it shouldn't fail since the period is very long (1m).
2024-01-19 16:33:27 +00:00
tcp-request session track-sc0 src
http-request return status 200 hdr x-glitches %[fc_glitches] hdr x-glitch-cnt %[sc0_glitch_cnt] hdr x-glitch-rate %[sc0_glitch_rate]
stick-table type ip size 10 store glitch_cnt,glitch_rate(1m)
MINOR: connection: add sample fetches to report per-connection glitches Now with fc_glitches and bc_glitches we can retrieve the number of detected glitches on a front or back connection. On the backend it can indicate a bug in a server that may induce frequent reconnections hence CPU usage in TLS reconnections, and on the frontend it may indicate an abusive client that may be trying to attack the stack or to fingerprint it. Small non-zero values are definitely expected and can be caused by network glitches for example, as well as rare bugs in the other component (or maybe even in haproxy). These should never be considered as alarming as long as they remain low (i.e. much less than one per request). A reg-test is provided.
2024-01-17 17:00:21 +00:00
} -start
# valid request: no glitch
client c1 -connect ${hap_fe1_sock} {
txpri
stream 0 {
txsettings
rxsettings
txsettings -ack
rxsettings
expect settings.ack == true
} -run
stream 1 {
txreq \
-method "GET" \
-scheme "http" \
-url "/"
rxresp
expect resp.status == 200
expect resp.http.x-glitches == 0
} -run
stream 3 {
txreq \
-method "GET" \
-scheme "http" \
-url "/"
rxresp
expect resp.status == 200
expect resp.http.x-glitches == 0
} -run
} -run
# invalid path: => req decoding error => glitch++
client c2-path -connect ${hap_fe1_sock} {
txpri
stream 0 {
txsettings
rxsettings
txsettings -ack
rxsettings
expect settings.ack == true
} -run
stream 1 {
txreq \
-method "GET" \
-scheme "http" \
-url "hello-world"
rxrst
} -run
stream 3 {
txreq \
-method "GET" \
-scheme "http" \
-url "/"
rxresp
expect resp.status == 200
expect resp.http.x-glitches == 1
MEDIUM: mux-h2: update session trackers with number of glitches We now update the session's tracked counters with the observed glitches. In order to avoid incurring a high cost, e.g. if many small frames contain issues, we batch the updates around h2_process_demux() by directly passing the difference. Indeed, for now all functions that increment glitches are called from h2_process_demux(). If that were to change, we'd just need to keep the value of the last synced counter in the h2c struct instead of the stack. The regtest was updated to verify that the 3rd client that does not cause issue still sees the counter resulting from client 2's mistakes. The rate is also verified, considering it shouldn't fail since the period is very long (1m).
2024-01-19 16:33:27 +00:00
expect resp.http.x-glitch-cnt == 1
expect resp.http.x-glitch-rate == 1
MINOR: connection: add sample fetches to report per-connection glitches Now with fc_glitches and bc_glitches we can retrieve the number of detected glitches on a front or back connection. On the backend it can indicate a bug in a server that may induce frequent reconnections hence CPU usage in TLS reconnections, and on the frontend it may indicate an abusive client that may be trying to attack the stack or to fingerprint it. Small non-zero values are definitely expected and can be caused by network glitches for example, as well as rare bugs in the other component (or maybe even in haproxy). These should never be considered as alarming as long as they remain low (i.e. much less than one per request). A reg-test is provided.
2024-01-17 17:00:21 +00:00
} -run
} -run
# invalid scheme: blocked at HTX layer, not counted
client c3-scheme -connect ${hap_fe1_sock} {
txpri
stream 0 {
txsettings
rxsettings
txsettings -ack
rxsettings
expect settings.ack == true
} -run
stream 1 {
txreq \
-method "GET" \
-scheme "http://localhost/?" \
-url "/"
rxresp
expect resp.status == 400
} -run
stream 3 {
txreq \
-method "GET" \
-scheme "http" \
-url "/"
rxresp
expect resp.status == 200
expect resp.http.x-glitches == 0
MEDIUM: mux-h2: update session trackers with number of glitches We now update the session's tracked counters with the observed glitches. In order to avoid incurring a high cost, e.g. if many small frames contain issues, we batch the updates around h2_process_demux() by directly passing the difference. Indeed, for now all functions that increment glitches are called from h2_process_demux(). If that were to change, we'd just need to keep the value of the last synced counter in the h2c struct instead of the stack. The regtest was updated to verify that the 3rd client that does not cause issue still sees the counter resulting from client 2's mistakes. The rate is also verified, considering it shouldn't fail since the period is very long (1m).
2024-01-19 16:33:27 +00:00
expect resp.http.x-glitch-cnt == 1
expect resp.http.x-glitch-rate == 1
MINOR: connection: add sample fetches to report per-connection glitches Now with fc_glitches and bc_glitches we can retrieve the number of detected glitches on a front or back connection. On the backend it can indicate a bug in a server that may induce frequent reconnections hence CPU usage in TLS reconnections, and on the frontend it may indicate an abusive client that may be trying to attack the stack or to fingerprint it. Small non-zero values are definitely expected and can be caused by network glitches for example, as well as rare bugs in the other component (or maybe even in haproxy). These should never be considered as alarming as long as they remain low (i.e. much less than one per request). A reg-test is provided.
2024-01-17 17:00:21 +00:00
} -run
} -run