11月 172016
 

关于tcp代理涉及3个实体:

c: client

p: proxy

s: server

 

c  <—–> p <—–> s

c 和 p建立tcp连接, p 和 s 建立tcp连接;

对于tcp来讲,很可能不是http那样ask and answer then close的, 很有可能连接上长时间没有数据,那么会出现什么问题呢?

  1. 假如 c 和 p 之间的网线短了, c 不可能再关闭这个连接了,那么p如何释放这个连接呢?
    1. p 在该连接上设置keepalive,定期检查连接是否断开,一般系统设置的间隔时间为2小时
    2. 一定程度上,c也关心这个长时间没有使用的连接是否依然可用,那么,c也可以在该连接上设置keepalive
  2. 问题:
    1. p 是否会转发c 的keepalive 数据包?
      1. p 是tcp(传输层)的代理,只有接到数据才会转发,没有数据不会转发
      2. keepalive 实际上是一个数据长度为0的ip数据包
      3. 所以: p 不会转发keepalive
    2. 既然p不会转发keepalive,那么如果p和 s 之间的链路出现问题,c 将不知道其实连接已经不可用了,然后就会数据发送失败

总结:

  1. p 有必要和c、s keepalive
 Posted by at 下午 12:02
7月 212016
 

什么是http隧道代理?(自己搜吧)

haproxy的经典逻辑是:每个请求都分配给所配置的后端(backend)来处理;对于connect请求,原则上不需要添加配置backend的,但是这不符合haproxy的规则;测试+跟踪源代码发现: haproxy根本不能实现http隧道代理,之于option http-tunnel 配置也不过是生命不要解析第一个请求之后的数据而已,connect请求还是要原样转发给backend的

 Posted by at 下午 7:38
7月 202016
 

配置:

其中:

  1. check 说明要开启健康检查
  2. fall 100 rise 1: 失败100次才会被自动摘掉,对于被摘掉的机器,成功1次就能挂回来
  3. resolvers dns: 使用指定的dns 进行解析; 如果为开启健康检查(即: check) 则该配置将不生效(这叫什么逻辑?),参考: http://cbonte.github.io/haproxy-dconv/configuration-1.6.html#5.2-resolvers
  4. resolve-prefer ipv4: 参考ipv4地址,这个配置避免解析没有必要的ipv6, 参考: http://cbonte.github.io/haproxy-dconv/configuration-1.6.html#5.3.2

    字面意思来看:DNS总是会解析ipv4和ipv6的,只是Haproxy优先参考哪一个。
    实测的结果是:指定了ipv4后,就不会再去解析ipv6地址了(这样效率更好)
    或许dns类库也可以一下子解析出来ipv4和ipv6的

 

 Posted by at 下午 4:40
7月 192016
 
  1. mode health
    该模式用于健康检查,tcp层面的,只返回OK,如下:
  2. stats
    1. 通过http页面查看状态:
    2.  通过tcp socket查看状态:


      这个socket也可以是一个unix socket:(或者同时写两个都是可以的)


      使用nc也行:

      tcp(或unix模式)有很多命令可以使用
    3. 一个一般的配置

       

 

 

 

 

参考资料: http://www.ttlsa.com/linux/haproxy-study-tutorial/

 Posted by at 下午 12:12