FPs

Articles with the haproxy tag

HAProxy 最佳实践笔记

haproxy_best_practice

这篇笔记内容主要来自Haproxy官方团队分享的一个幻灯片:《Haproxy best practice》,介绍了一些常规的配置方式和优化手段。

不要盲目使用文中出现的所有技巧。

Haproxy 是如何工作的

关于Haproxy 团队介绍,以及一些特性介绍直接看前面几张幻灯片即可。 Haproxy 的主要用作代理请求,工作流程如下:
haproxy_proxy_mode

client 和Haproxy 建立连接,Haproxy 再和对应的后端server 建立连接,然后作为中间人,转发请求。 在Haproxy 配置中,对一个代理,会划分为2层,frontend(前端) 和backend(后端),这和上文说的Haproxy 的工作流程也是对应的。
Continue ->


Haproxy 作为Shadowsocks 中继遇到的一个问题

之前用Haproxy 来转发Shadowsocks 的流量时遇到一个问题,现象是在使用Slack 的时候(聊天使用了Websocket),频繁重连。凭直觉是由于Haproxy 的某一项timeout 设置的不合理导致的。
Websocket 协议可以分为2个阶段,先用HTTP 握手,然后建立长连接,通过ws 协议进行通信。将Haproxy 作为中继时,在建立长连接之后,Haproxy 就转入tunnel 模式

TUN:tunnel(option http-tunnel):这是 1.0 ~ 1.5-dev21 的默认模式,类似于隧道,HAProxy 仅处理第一个请求和响应,剩余的报文将直接转发而不进行处理。尽量不要使用这个模式,因为它在日志记录和 HTTP 处理上有很多问题。 --来源:liaoph.com

涉及到的timeout 见下图:
timeout_websocket
图片来源:www.yuangguo.info

我们遇到的需要频繁重连的情况,其实是由于timeout tunnel 设置不合理导致的。官方给的关于timeout tunnel 的解释:

Set the maximum inactivity time on the client and server side for tunnels.

The tunnel timeout applies when a bidirectional connection is established between a client and a server, and the connection remains inactive in both directions. This timeout supersedes both the client and server timeouts once the connection becomes a tunnel. In TCP, this timeout is used as soon as no analyser remains attached to either connection (eg: tcp content rules are accepted). In HTTP, this timeout is used when a connection is upgraded (eg: when switching to the WebSocket protocol, or forwarding a CONNECT request to a proxy), or after the first response when no keepalive/close option is specified......

另外官方给出了一个配置示例:

defaults http
    option http-server-close
    timeout connect 5s
    timeout client 30s
    timeout client-fin 30s
    timeout server 30s
    timeout tunnel  1h    # timeout to use with WebSocket and CONNECT

把中继的Haproxy 的这项值设为1h,解决了Slack 会频繁重连的问题。

参考链接: