Haproxy-proxies 部分翻译

Proxy 配置包含以下几个部分

• defaults
• frontend
• backend
• 列表内容
• listen

default

default 部分设置默认参数对于其他声明列表中的其他部分。default 部分会被下个声明的default 覆盖。 default 部分是可选的，但是设置了增强可读性。

frontend

frontend 部分描述了接受客户端连接的监听的socket的集合。

backend

backend 部分描述了服务器集合， 这个集合是前端连接的后端

listen

listen 部分定义了有前端和后端的完整的proxy的组合。 通常用于tcp传输
proxy 名称必须是大小写字符 数字 _ - . : 组成，acl 是大小写敏感型的， www 和WWW 是不同的。
历史上来说，所有proxy 的名字是可以重复的， 但在日志中会有麻烦。要求而非必须设置proxy 的名字不同地。
proxy 主要支持两种模式：L4 TCP && L7 HTTP。 在tcp层，haproxy 只做简单的两端的流量传输。在http层，haproxy 分析协议，根据任意规则，通过 允许，阻塞，切换，添加，修改，移除任意内容在请求和响应中。

在http模式中，进程应用到一个连接的请求和响应是根据前端和后端的参数选项的组合，Haproxy 支持5种连接模式：

• KAL： keep alive（”option http-keep-alive”）默认模式。所有的请求和响应都被处理， 在返回和新请求到来之前，连接空闲保持
• TUN : tunnel (“option http-tunnel”) 版本1.0-1.5 的默认模式。只处理第一个请求和响应。其他入向请求是不会被分析的。这种模式不该被使用因为对于http 处理和日志记录都不友好。
• PCL：passive close (“option httpclose”) 和tunnel 模式一样， 但是会在在两个方向上的结尾加上”Connection: close” 让两端都关闭在第一次请求和响应改变的时候。
• SCL：server close (“option http-server-close”) 在服务器端的response 接收到后，关闭服务器端的连接。前端的连接依旧保持。
• FCL：forced close (“option forceclose”) 在response 后连接就被结束了。
  前端和后端高效的连接模式是通过前端和后端在下面矩阵中模式共同决定的，矩阵是对称的，KAL 是最弱模式，FCL是最强模式。

Proxy 逐渐矩阵

下列主键都是支持的。下列中大部分是部分支持的。一些被标记为分开的“deprecated“ 是从老的语法上继承来的， 一些具有迷惑性和功能上的限制。有新的关键字替代他们。用*标记的主键都是可以用no 前缀逆转的。这些标记只有在默认呢启用时才生效。这些选项也可以加上default 前缀去修复那些默认设置 而忽略之前的指定的默认选项。

按字母排序的字符的查询

• acl

• appsession
  定义已经存在的应用cookie的会话

  • cookie cookie的名字和
  • length cookie 字符长度的最大值
  • holetime cookie 保持时间 如果过了这个时间cookie 一致未被使用，cookie 会被移除内存。如果没有特别指定，默认时间是ms
  • request-learn 如果此选项被指定，haproxy 会从请求中学习cookie当服务器端没有任何具体说明在response。即若服务端响应时间 超过session粘滞的时间，也不会导致session过期。 一般为提高系统的可信赖度会要求设置此参数
  • prefix 当这个选项被指定，haproxy 会匹配cookie的这个前缀，appsession 是跟在这个后面的。
  • mode 此参数允许改变URL的解析模式，两种模式是当前支持的：
    
    • path-parameters 解析器查找appsession 从路径参数部分（每一个参数被分号分割）。默认模式
    • query-string 解析器查找appsession 从查询字符串中。
  • backlog
    给的建议系统监听挤压的最大值。为保护系统不受sync flood的攻击，一种解决办法就是增大sync积压列表大小。有时可根据系统参数进行调节，有时是完全不可调节的，有时系统依赖应用给处的提示在listen 系统调用被调用的时候。 默认地，haproxy 忽略前端的最大连接值对于listen调用，在可以利用这个参数的系统上，有时有能力去指定一个不同的值对一个参数是很有用的。
  • balance
    定义使用在后端服务节点上的负载均衡算法， 只应用在没有坚持信息可用时（这里理解为会话保持），或者当一个连接被重新分发到另一台服务器上时（这里理解为面向连接的请求负载）
    
    • roundrobin： 每个server 被轮流使用，根据他们的权重，这是一种均匀的，公平的算法，当服务器端处理时间相同。 这种算法是动态的，这意味着server 权重是可调整的，在节点可以设为慢启动在运行中。限制后端4095个活跃的服务器。 注意在一些大型的工厂中，在一个服务器转换为up 状态从一个短时间的down 状态，有时这个服务器可能能收到上百个请求 使得它重新加入到这个工厂中并开始处理流量。这是正常的，虽然非常罕见，如果你有机会观察到这个现象， 不要担心。
    • static-rr: 每一个服务器都是被轮流选中的，根据他们的权重，这个算法和roundrobin算法很像，只是它是静态的，这意味着在运行中去改变一个server 的权重是不会起效的。另一方面，此算法没有设计上的限制对于后端节点的数量， 当一个服务器变为运行状态，它能快速重新加入到这个工厂中，一旦这个映射关系被建立（计算），运行需要很少的cpu。
    • leaseconn: 选择具有最小连接数的服务器接收连接。round-robin 是在具有相同负载服务器组内在负载 保证所有的服务器都能被使用到。 最小连接数算法，适合长会话的请求。但是不适合用于短会话的协议，例如http，此算法是动态的，意味这在运行中可被调整。
    • first: 可接受连接的第一个server 接收连接，被选择的服务器是从数字标符最低的到最高的（服务器Id），默认是服务器在工厂中的位置。一旦一个服务器到达了它的最大连接值，下一个服务器会被选择， 这个算法对没有设置最大连接数是不起作用地。这个算法的目的是总是使用服务器Id 最小的服务器以使其他服务器关机在空闲时间。这个算法忽略了服务器的权重，为长连接带来好处。为高效的使用此算法，建议加一个云管理器定期检查未使用的节点并关机，当请求队列快满的时候再将服务器开机。使用”http-check send-state”可以通知服务器的负载
    • source: 源IP地址被hash通过运行中服务节点的总的权重决定哪个节点可以接收请求。 这确保了相同的客户端IP地址将总是到达相同的服务器节点如果没有服务器down 或者up，如果hash结果改变是因为运行中服务器数量的改变，很多客户端会被指到不容的服务器上。此算法通常被用于tcp模式并且没有cookie被插入的时候。它在internet上使用来为拒绝会话cookie 的客户端提供高效的粘黏性。 此算法默认是静态的，意味着运行时改变权重不会起作用，但是可以通过“hash-type“改变。
    • uri 这个算法或者hash URI的左边部分或者整个URI 并将hash 值根据运行中节点的权重总值进行分配。结果决定了哪个server将被接收请求。这个算法确定了同一个URI请求会被分到同样的server 如果没有server down 或者up, 此算法被使用代理缓存和反病毒代理上，最大化缓存命中率。 此算法只用于http 模式。此算法是静态的。
      此算法支持两个可选参数，len 和depth，两个参数都是跟一个int 类型 这个选项在需要平衡在在URI刚开始的时候很有帮助的。len 参数指明考虑的URI的长度在计算hash结果的时候，设置len=1 基本是没有意义的因为大部分URI 都会以“／“开始。
      depth 参数指明了最大参数路径深度被用于hash的。如果两个参数都被指定了，如果两个参数都被设置，那两个中任一到达点就会停止。
      url_param: URL参数将在每个HTTP GET请求的查询字符串中被查找。如果修饰符“check_post“被使用，将在http post请求实体中查找这个参数， 当在？之后的url中没有查询到字符串时。消息体只有在这两种情况下才会被解析，大量数据被接收或者请求缓冲区满的时候。在使用chunked编码的不太可能的事件中，只有第一个块被扫描。参数值被chunk块边界了，如果参数值被chunk块分开了，就会选择随机负载了。 曾经还支持“max_wait“参数，现在已经被忽略了。
      如果参数被找到跟着一个=和一个值，这个值会被hash 和根据总运行中server的权重。
      此算法用于追踪请求中的用户描述符并确保同一个userId将总是被发送到同一个server 如果后端服务器没有up 和down。如果没找到值或者参数没找到，会应用round-robin算法。此算法只适用于http，此算法默认是静态的。
    • hdr http头将会被查询在每一个http 请求中。和acl hdr 是一样的。括号中header 的名字是大小写不敏感的。 如果没有头消息或者头消息没包含任何值 那么round-robin 算法会替上。
      可选参数use_domain_only 是有可用的，能减小主domin部分的hash能力通过指定header 例如“Host“。例如在“haproxy.1wt.et“中，只考虑1wt。 默认是静态的。
  • rdp cookie 会被查询对于每一个进来的tcp 请求 和acl 中req_rdp_cookie 是一样的，name 不是大小写敏感的，这种机制作为降级持久性模式非常有用，因为它能让同样的用户到同一个服务器，如果cookie 没找到，会使用round-robin算法。
    -这种工作模式，前端必须保证rdp cookie 已经在请求buffer 中。你还必须使用tcp-request content accept 规则并结合上 req_rdp_cookie_cnt acl, 此算法是静态算法。
    是一些算法需要的可选参数列表。当前，只有”url_param”和 “uri” 支持可选参数

  Note:
  在使用check_post 扩展url_param 时必须考虑下面的警告和限制。
  - 所有的post 请求都是值得被考虑的，因为没办法决定是否参数会被找到在body or entity里（可能包含二进制数据）。因此，另一种方式应该被严格考虑对于没有URL参数在body 中的post请求。
  - 使用比请求buffer 大的值是没意义的，buffersize 是在build 的时候被这是的，默认是16kb
  - content-encoding 是不被支持的，参数查找可能会失败，负载均衡算法降为轮询算法。
  - 估计：100-continue？？是不支持的，会将算法降为轮询。
  - Transfer-Encoding (RFC7230 3.3.1) 是不支持在第一个chunk块中的，如果整个参数值不出现在第一个chunk中，server 的选择就变为未决的。
  - 这些特性不支持100，411，501 一族返回的。
  - 在一些情况下，请求check-post 可能试图扫描真个消息体，扫描会被中断如果遇到空格和控制字符的时候。