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 會頻繁重連的問題。

參考鏈接: