6e5aa16145
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. |
||
---|---|---|
.. | ||
ca-auth.crt | ||
cli_src_dst.vtc | ||
client1.pem | ||
common.pem | ||
dispatch.vtc | ||
h2_glitches.vtc | ||
http_reuse_aggressive.vtc | ||
http_reuse_always.vtc | ||
http_reuse_be_transparent.vtc | ||
http_reuse_conn_hash.vtc | ||
http_reuse_dispatch.vtc | ||
http_reuse_never.vtc | ||
http_reuse_safe.vtc | ||
proxy_protocol_random_fail.vtc | ||
proxy_protocol_send_generic.vtc | ||
proxy_protocol_send_unique_id.vtc | ||
proxy_protocol_send_unique_id_alpn.vtc | ||
proxy_protocol_tlv_validation.vtc | ||
reverse_connect_full.vtc | ||
reverse_server.vtc | ||
reverse_server_name.vtc | ||
tcp_to_http_upgrade.vtc |