我的 HAProxy 配置。
#HA-Proxy version 1.3.22 2009/10/14 Copyright 2000-2009 Willy Tarreau <[email protected]>
global
maxconn 10000
spread-checks 50
user haproxy
group haproxy
daemon
stats socket /tmp/haproxy
log localhost local0
log localhost local1 notice
defaults
mode http
maxconn 50000
timeout client 10000
option forwardfor except 127.0.0.1
option httpclose
option httplog
listen dcaustin 0.0.0.0:80
mode http
timeout connect 12000
timeout server 60000
timeout queue 120000
balance roundrobin
option httpchk GET /index.html
log global
option httplog
option dontlog-normal
server web1 10.10.10.101:80 maxconn 300 check fall 1
server web2 10.10.10.102:80 maxconn 300 check fall 1
server web3 10.10.10.103:80 maxconn 300 check fall 1
server web4 10.10.10.104:80 maxconn 300 check fall 1
listen stats 0.0.0.0:9000
mode http
balance
log global
timeout client 5000
timeout connect 4000
timeout server 30000
stats uri /haproxy
HAProxy 正在运行，并且套接字正在工作......
adam@dcaustin:/etc/haproxy# echo "show info" | socat stdio /tmp/haproxy
Name: HAProxy
Version: 1.3.22
Release_date: 2009/10/14
Nbproc: 1
Process_num: 1
Pid: 6320
Uptime: 0d 0h14m58s
Uptime_sec: 898
Memmax_MB: 0
Ulimit-n: 20017
Maxsock: 20017
Maxconn: 10000
Maxpipes: 0
CurrConns: 47
PipesUsed: 0
PipesFree: 0
Tasks: 51
Run_queue: 1
node: dcaustin
desiption:
错误没有显示套接字中的任何内容......
adam@dcaustin:/etc/haproxy# echo "show errors" | socat stdio /tmp/haproxy
adam@dcaustin:/etc/haproxy#
然而...
我的错误日志中充斥着“badrequests”，错误代码为 cR。cR（根据 1.3 文档）是客户端发送完整 HTTP 请求之前的“http 请求超时”错误。这有时是由于客户端的 TCP MSS 值太大（对于无法传输全尺寸数据包的 PPPoE 网络而言）或客户端手动发送请求且输入速度不够快，或忘记在请求末尾输入空行所致。此处的 HTTP 状态代码可能是 408。
408 错误是正确的，但我们每小时都会收到数千个此类请求。（此日志片段是一段约 10 秒的剪辑……）
Jun 30 11:08:52 localhost haproxy[6320]: 92.22.213.32:26448 [30/Jun/2011:11:08:42.384] dcaustin dcaustin/<NOSRV> -1/-1/-1/-1/10002 408 212 - - cR-- 35/35/18/0/0 0/0 "<BADREQ>"
Jun 30 11:08:54 localhost haproxy[6320]: 71.62.130.24:62818 [30/Jun/2011:11:08:44.457] dcaustin dcaustin/<NOSRV> -1/-1/-1/-1/10001 408 212 - - cR-- 39/39/16/0/0 0/0 "<BADREQ>"
Jun 30 11:08:55 localhost haproxy[6320]: 84.73.75.236:3589 [30/Jun/2011:11:08:45.021] dcaustin dcaustin/<NOSRV> -1/-1/-1/-1/10008 408 212 - - cR-- 35/35/15/0/0 0/0 "<BADREQ>"
Jun 30 11:08:55 localhost haproxy[6320]: 69.39.20.190:49969 [30/Jun/2011:11:08:45.709] dcaustin dcaustin/<NOSRV> -1/-1/-1/-1/10000 408 212 - - cR-- 37/37/16/0/0 0/0 "<BADREQ>"
Jun 30 11:08:56 localhost haproxy[6320]: 2.29.0.9:58772 [30/Jun/2011:11:08:46.846] dcaustin dcaustin/<NOSRV> -1/-1/-1/-1/10001 408 212 - - cR-- 43/43/22/0/0 0/0 "<BADREQ>"
Jun 30 11:08:57 localhost haproxy[6320]: 212.139.250.242:57537 [30/Jun/2011:11:08:47.568] dcaustin dcaustin/<NOSRV> -1/-1/-1/-1/10000 408 212 - - cR-- 42/42/21/0/0 0/0 "<BADREQ>"
Jun 30 11:08:58 localhost haproxy[6320]: 74.79.195.75:55046 [30/Jun/2011:11:08:48.559] dcaustin dcaustin/<NOSRV> -1/-1/-1/-1/10000 408 212 - - cR-- 46/46/24/0/0 0/0 "<BADREQ>"
Jun 30 11:08:58 localhost haproxy[6320]: 74.79.195.75:55044 [30/Jun/2011:11:08:48.554] dcaustin dcaustin/<NOSRV> -1/-1/-1/-1/10004 408 212 - - cR-- 45/45/24/0/0 0/0 "<BADREQ>"
Jun 30 11:08:58 localhost haproxy[6320]: 74.79.195.75:55045 [30/Jun/2011:11:08:48.554] dcaustin dcaustin/<NOSRV> -1/-1/-1/-1/10005 408 212 - - cR-- 44/44/24/0/0 0/0 "<BADREQ>"
Jun 30 11:09:00 localhost haproxy[6320]: 68.197.56.2:52781 [30/Jun/2011:11:08:50.975] dcaustin dcaustin/<NOSRV> -1/-1/-1/-1/10000 408 212 - - cR-- 49/49/28/0/0 0/0 "<BADREQ>"
从我在 Google 上看到的内容来看，如果我想查看哪些是错误请求，我可以向套接字显示错误，然后套接字就会将其吐出。我们确实运行了一个流量很大的网站，并且“BADREQS”占正常请求的比例相当低，但我希望能够了解该请求是什么，以便对其进行调试。
统计数据
# pxname,svname,qcur,qmax,scur,smax,slim,stot,bin,bout,dreq,dresp,ereq,econ,eresp,wretr,wredis,status,weight,act,bck,chkfail,chkdown,lastchg,downtime,qlimit,pid,iid,sid,throttle,lbtot,tracked,type,rate,rate_lim,rate_max,
dcaustin,FRONTEND,,,64,120,50000,88433,105889100,2553809875,0,0,4641,,,,,OPEN,,,,,,,,,1,1,0,,,,0,45,0,128,
dcaustin,web1,0,0,10,28,300,20941,25402112,633143416,,0,,0,3,0,0,UP,1,1,0,0,0,2208,0,,1,1,1,,20941,,2,11,,30,
dcaustin,web2,0,0,9,30,300,20941,25026691,641475169,,0,,0,3,0,0,UP,1,1,0,0,0,2208,0,,1,1,2,,20941,,2,11,,30,
dcaustin,web3,0,0,10,27,300,20940,30116527,635015040,,0,,0,9,0,0,UP,1,1,0,0,0,2208,0,,1,1,3,,20940,,2,10,,31,
dcaustin,web4,0,0,5,28,300,20940,25343770,643209546,,0,,0,8,0,0,UP,1,1,0,0,0,2208,0,,1,1,4,,20940,,2,11,,31,
dcaustin,BACKEND,0,0,34,95,50000,83762,105889100,2553809875,0,0,,0,34,0,0,UP,4,4,0,,0,2208,0,,1,1,0,,83762,,1,43,,122,
过去 20 分钟内有 88500 个“会话”和 4500 个错误。
答案1
您的超时时间太短。请增加超时时间。
timeout connect 30s
timeout client 30s
同一机架中两台服务器之间的通信绝对最短时间为 5 秒。如果出现任何数据包丢失，则 TCP 连接需要 3 秒才能打开，这种情况时有发生。
最小超时时间为 15 秒，以支持国际流量，例如来自澳大利亚的客户端连接到北美的服务器。世界上某些地方的延迟相当高，带宽也很低，比人们预期的要糟糕得多。合理的超时是开展全球业务的先决条件。
最小超时时间为 30 秒，以支持移动连接和接收效果较差的 WiFi。这种连接不可靠，可能会出现短时间的断网。
请记住。超时是为了处理连接的最坏情况，它们应该只捕获真正失败的连接。它们可以设置得稍微短一些，但这没有任何好处，除了在客户端和服务器上生成错误，这不是一个好处。
考虑一下，每 5 秒发出一次定期请求（例如健康检查或轮询 API）实际上每天有多达 17280 个请求。因此，良好的超时设置应导致少于 0.01% 的误报，否则每天都会无缘无故地产生错误。
过去 20 分钟内发生了 88500 次会话和 4500 个错误。
错误率为 5%。这是一个非常高的错误率。
考虑到平均每个网页需要超过 20 个子请求才能加载，这意味着您网站上的每个页面都无法部分加载。
答案2
尝试明确设置：
timeout http-request 20s
另一种可能性是 http 请求标头中存在无效字符，HAProxy 因此拒绝。如果它们是脚本编写不佳的机器人，拒绝可能是件好事。如果您想允许它们，请设置：option accept-invalid-http-request