haproxy运行过程时间发生跳变时，通过curl IPv6 IP访问异常会报错“connection reset by peer”

<h3>【测试步骤】：详细描述可以复现该问题的测试步骤</h3>1、haproxy服务配置需增加：tcp-request connection reject if { fe_sess_rate gt 100 }，启动haproxy服务2、执行时间跳变脚本：<pre data-lang="c" class="lang-c"><code class="lang-c">while :; do sleep 1 date -s &#x27;30year&#x27; sleep 1 date -s &#x27;-30year&#x27; sleep 1 date -s &#x27;30day&#x27; sleep 1 date -s &#x27;-30day&#x27; sleep 1 date -s &#x27;30hour&#x27; sleep 1 date -s &#x27;-30hour&#x27; sleep 1 date -s &#x27;30min&#x27; sleep 1 date -s &#x27;-30min&#x27; sleep 1 date -s &#x27;30sec&#x27; sleep 1 date -s &#x27;-30sec&#x27; done</code></pre>2、wrk打流    wrk -c 1000 -d 1000000 https://${ipv4} &amp;     wrk -c 1000 -d 1000000 https://[${ipv6}] &amp;3、curl访问haproxy服务配置的监听ipcurl -k https://${ipv4}curl -k https://[${ipv6}] 【结果输出】：根据上述测试步骤执行后，系统的实际输出<pre data-lang="bash" class="lang-bash"><code class="lang-bash"># curl -k https://xx.xx.xx.xx curl: (35) OpenSSL SSL_connect: Connection reset by peer in connection to xx.xx.xx.xx:443</code></pre> 【预期输出】：系统在上述测试步骤操作后，按照系统设计应该输出的结果不返回curl错误码，curl访问正常<h3>原因分析:</h3>社区对于haproxy的限速计算方式存在异常，对于时间跨越过大场景，会导致速率跳跃式变大，导致一直触发haproxy的限速机制，社区暂无解决方案，自研补丁解决https://github.com/haproxy/haproxy/issues/2704在haproxy的会话处理流程中，会在每轮会话开始时刷新全局时间，在会话过程中进行流量统计与规则匹配，最后在会话完成以后进行curr_tick值的刷新。src/freq_ctr.c<pre data-lang="c" class="lang-c"><code class="lang-c"> remain = tick + period - HA_ATOMIC_LOAD(&amp;global_now_ms); if (unlikely(remain &lt; 0)) { /* We&#x27;re past the first period, check if we can still report a * part of last period or if we&#x27;re too far away. */ remain += period; past = (remain &gt;= 0) ? curr : 0; curr = 0; } if (pend &lt; 0) { /* enable flapping correction at very low rates */ pend = 0; if (!curr &amp;&amp; past &lt;= 1) return past * period; } /* compute the total number of confirmed events over the period */ return past * remain + (curr + pend) * period; </code></pre>其中remain为int类型，curr_tick与global_now_ms为unsigned int类型，单位均为毫秒msint类型正数上限可以表示的最大值换算为天数为24.8天，最小值为 -24.9天 ，uint类型最大值换算成天数为49.7天现在考虑如下异常情况：在上一次会话过后30天，第二次会话到来，此时curr_tick - global_now_ms 为 -30天，超过int类型负数下限，此时会发生整形下溢出翻转，导致remain值变为超大数，从而导致计算出超大速率值，进而导致规则匹配失败，会话被误限流，而异常退出以后curr_tick值不会更新，于是问题无法自愈自研方案：通过curr_tick与global_now_ms的绝对值，与时间周期period进行比较，符合社区原本设计意图自研补丁如下：fix-timehopping-in-freq_ctr_total.patch<pre data-lang="c" class="lang-c"><code class="lang-c">From 638b8b2fe4163a85815424549a629a6c9b113d1d Mon Sep 17 00:00:00 2001 From: zhongxuan &lt;zhongxuan2@huawei.com&gt; Date: Fri, 6 Sep 2024 18:42:49 +0800 Subject: [PATCH] fix timehopping in freq_ctr_total --- src/freq_ctr.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/src/freq_ctr.c b/src/freq_ctr.c index 54aa78f..66397a0 100644 --- a/src/freq_ctr.c +++ b/src/freq_ctr.c @@ -28,6 +28,7 @@ ullong freq_ctr_total(const struct freq_ctr *ctr, uint period, int pend) { 	ullong curr, past, old_curr, old_past; 	uint tick, old_tick; +	uint toofar = 0; 	int remain; 	tick = HA_ATOMIC_LOAD(&amp;ctr-&gt;curr_tick); @@ -75,13 +76,18 @@ ullong freq_ctr_total(const struct freq_ctr *ctr, uint period, int pend) 		__ha_cpu_relax(); 	}; +	if (((tick + 2 * period) &lt; HA_ATOMIC_LOAD(&amp;global_now_ms)) || ((HA_ATOMIC_LOAD(&amp;global_now_ms) + 2 * period) &lt; tick)) +		toofar = 2; +	else if (((tick + period) &lt; HA_ATOMIC_LOAD(&amp;global_now_ms)) || ((HA_ATOMIC_LOAD(&amp;global_now_ms) + period) &lt; tick)) +		toofar = 1; + 	remain = tick + period - HA_ATOMIC_LOAD(&amp;global_now_ms); -	if (unlikely(remain &lt; 0)) { +	if (unlikely(remain &lt; 0 || toofar)) { 		/* We&#x27;re past the first period, check if we can still report a 		 * part of last period or if we&#x27;re too far away. 		 */ 		remain += period; -		past = (remain &gt;= 0) ? curr : 0; +		past = (toofar != 2) ? curr : 0; 		curr = 0; 	} -- 2.33.0</code></pre>

src-openEuler/haproxy

内容风险标识

评论 (1)

src-openEuler/haproxy .gitee-modal { width: 500px !important; }

内容风险标识