Hi Adam, On Wed, Apr 12, 2017 at 3:00 AM, Adam Spiers <[email protected]> wrote:
> Hi all, > > I've pored over the Configuration Manual again and again, and I'm > still struggling to fully understand sticky counters. This paragraph > seems to hold some important information: > > Once a "track-sc*" rule is executed, the key is looked up in the table > and if it is not found, an entry is allocated for it. Then a pointer to > that entry is kept during all the session's life, and this entry's > counters are updated as often as possible, every time the session's > counters are updated, and also systematically when the session ends. > Counters are only updated for events that happen after the tracking has > been started. As an exception, connection counters and request counters > are systematically updated so that they reflect useful > information. > > It seems that one of the key concepts here is "session". I'm assuming > that this actually means "TCP session", as in layer 5 of the OSI > model; is that correct? Just a correction here, see https://en.wikipedia.org/wiki/Session_layer#Comparison_with_TCP.2FIP_model > Unfortunately there is nowhere in the manual > which explicitly states this definition, despite countless uses of the > term, but there are some hints scattered around, e.g. in the > "tcp-request session" section: > > Once a session is validated, (ie. after all handshakes have been > completed), > > and in the "reject" part of the "tcp-request connection" section. > > It seems that each session can have a maximum of three entries > associated with it in stick-tables, because there is a maximum of 3 > sets of sticky counters per connection. And these entries could > potentially be in 1, 2, or 3 different stick-tables, depending on > where and how the track-scX directive is written, right? > > Thirdly, I'm struggling to understand these examples: > > Example: accept all connections from white-listed hosts, reject too fast > connection without counting them, and track accepted connections. > This results in connection rate being capped from abusive > sources. > > tcp-request connection accept if { src -f > /etc/haproxy/whitelist.lst } > tcp-request connection reject if { src_conn_rate gt 10 } > tcp-request connection track-sc0 src > > Example: accept all connections from white-listed hosts, count all other > connections and reject too fast ones. This results in abusive > ones > being blocked as long as they don't slow down. > > tcp-request connection accept if { src -f > /etc/haproxy/whitelist.lst } > tcp-request connection track-sc0 src > tcp-request connection reject if { sc0_conn_rate gt 10 } > > The stick-table directives are missing, but my experiments suggest > that not only they are mandatory, but also they must track conn_rate > samples, otherwise HAProxy has no way to know the duration of the > sliding time window which the connection rate relates to, and nothing > will get rejected. So I think the examples should include those > directives for clarity. When I added this, it worked for me: > > stick-table type ip size 100k store conn_rate(30s) > > Furthermore, I don't understand the explanation text which says > "without counting them". If they're not counted, how can the > connection rate be measured? So what is the real difference between > these two examples? > > I'd be really grateful for any light which can be shed here. I'm > normally pretty good at inhaling large, complex technical manuals, but > I've really been struggling with HAProxy's for some reason :-/ > > Thanks! > Adam > > -- Igor Cicimov | DevOps p. +61 (0) 433 078 728 e. [email protected] <http://encompasscorporation.com/> w*.* www.encompasscorporation.com a. Level 4, 65 York Street, Sydney 2000
