啸月抹茶怎么加盟:HAProxy 配置手册 4.2. session粘连相关

appsession len timeout
           [request-learn] [prefix] [mode ]
  在已有的应用程序cookie上定义会话粘连 session stickiness。
  可用的 sections :   defaults | frontend | listen | backend
                                   no    |    no    |   yes  |   yes
  Arguments :
      应用程序的cookie名字，对于每个新的会话，HAProxy都需要了解。
       在内存中保存和检查的每个cookie值的最大字符数。
    未使用的cookie等待多久后从内存中删除，单位默认毫秒。

    request-learn  声明该选项，当服务端没有指出任何响应时，haproxy仍能够了解在请求中发现的cookie。这通常是PHPSESSID的cookies发生的，或当haproxy的会话在应用会话之前超时并选择了正确的服务器。建议声明这个选项提升可靠性。

    prefix     声明该选项，haproxy会匹配cookie前缀（或URL参数前缀），appsession的值是带前缀的数据。
               例如：  appsession ASPSESSIONID len 64 timeout 3h prefix
               匹配cookie为 ASPSESSIONIDXXXX=XXXXX，appsession的值为 XXXX=XXXXX。

    mode     该选项允许修改URL解析器模式，当前支持2种模式：
               - path-parameters : 该模式下，解析器在path参数部分查找appsession（每个参数由分号分隔），例如对于JSESSIONID就很方便。如果不设置mode，则默认为该模式。
               - query-string : 该模式下，解析器会在查询字符串中查找appsession。
  当后端定义了应用cookie，HAProxy会检查服务器设置的这个cookie，并把值存储在一个表中，并与这个服务器的标识符相关联。值只保留小于的字符。对于每个连接，haproxy都会在"Cookie:"头中查找cookie，并作为一个URL参数 (依赖于mode)。如果发现了已知的值，客户端会重定向到关联这个值的服务器上，否则使用负载均衡算法。超过时间一直没有被使用的Cookies，会自动从内存中删除。
  每个后端的应用cookie的定义是有限的。
  注意：多进程模式下 (nbproc > 1) 不考虑使用这个特性，除非你知道你在做什么，因为多个进程之间没有共享内存，这会造成随机的行为。

  Example :
        appsession JSESSIONID len 52 timeout 3h
  See also : "cookie", "capture cookie", "balance", "stick", "stick-table","ignore-persist", "nbproc" and "bind-process"。

cookie [ rewrite | insert | prefix ] [ indirect ] [ nocache ]
              [ postonly ] [ preserve ] [ domain ]*
              [ maxidle ] [ maxlife ]
  启用后端基于cookie的持久性。
  可用的 sections :   defaults | frontend | listen | backend
                                  yes   |    no    |   yes  |   yes
  Arguments :
    cookie的名称，用于持久性的监视、修改和增加。cookie在response中通过"Set-Cookie"头发送给客户端，并由客户端的所有request的"Cookie"头返回。尤其注意不要与应用cookie重名。另外，如果相同客户端使用了相同的后端（如HTTP/HTTPS），如果不希望跨后端的持久性，也要注意使用不同的cookie名称。

    rewrite   表示cookie由服务器提供，haproxy必定要修改它的值，以包含服务器的标识符。这种模式便于应用来管理 "Set-cookie" 和 "Cache-control"头的复杂组合。应用可以决定是否适合发出一个持久性cookie。如果所有的响应都要被监控，则该模式只能工作在 HTTP close模式下。除非应用的行为很复杂和/或破碎（broken?），否则建议不要启动这个新的配置模式。关键字不能与"insert" 和 "prefix"共用。             
    insert    表示如果客户端还没有允许访问服务器的cookie，haproxy会在服务器响应中插入持久性cookie。
                 如果服务器发送了一个同名的cookie，当没有同时声明 "preserve" 选项时，它会在处理前被删掉。因此，这个模式可以用于升级“rewrite”模式下的已有配置。cookie只是一个会话cookie，而且不保存在客户端的磁盘中。 默认的，除非有选项 "indirect" ，服务器才会看到客户端发出的cookie。由于缓存的影响，通常明智的做法是添加关键字"nocache" or "postonly" 。关键字不能与 "rewrite" 和 "prefix"共用。

    prefix    持久性基于现有的cookie就可以，而不必依赖专门的cookie。在一些特殊的环境下需要使用，如客户端不支持多于一个cookie，而应用已经需要了。这种情况下，每当服务器设置了cookie名字，haproxy就会在名字前添加一个服务器标识符和分隔符的前缀。前缀在所有客户端的请求中会被去掉，所以服务器还是会找到发送的cookie。既然所有的响应和请求都要被修改，这个模式则需要运行在HTTP close模式下。关键字不能与 "rewrite" 和 "insert"共用。

    indirect   声明了该选项，没有cookie会被发送给客户端，即使客户端已经有一个合法的cookie给处理响应的服务器。如果服务器本身设置了这样一个cookie，也会被删除，除非同时设置了选项"preserve"。在"insert"模式下，还会删除发送给服务器的request的cookie。持久机制对应用是完全透明的。

    nocache  如果在客户端和HAProxy之间有缓存，那么该选项建议与"insert"模式结合使用，如果需要新增cookie，确保可缓存的response标记为非缓存的。这很重要，因为所有可持久的cookie都被加在实例的一个可缓存的主页上，那么所有客户会从外部缓存获取页面，并都共享同样的持久cookie，导致一个服务器处理了太多的负载。参见"insert" 和 "postonly"选项。

    postonly  该选项使cookie只能增加在POST请求的响应中。与 "nocache"选项只能二选一，因为POST响应是不可缓存的，所以持久cookie是绝不会被缓存的。第一个POST一般都是登录请求，大部分站点在此之前不需要任何持久性的排序，这可以避免在缓存中查找持久cookie，以有效优化缓存。参见"insert" 和 "nocache" 选项。

    preserve  该选项可以与 "insert" 和/或 "indirect"一起使用。允许服务器自己发送持久cookie。在这种情况下，如果在response中发现有cookie，则HAProxy会对其保持不变。在实例的注销请求之后，需要用它来结束持久性。此时，服务器只需要发送一个带有无效值（如：empty）或过去日期的cookie。与"disable-on-404"检查选项相结合，可以实现一个完全正常的关闭，因为用户注销后一定会离开服务器。

    domain   该选项用于指定cookie插入的域，后跟一个合法的域名参数。如果域名以点开头，浏览器允许任何以域名结尾的主机使用它。还可以通过多此调用此选项来指定多个域名，但要注意有的浏览器对域的个数是有限制的。有记录说在MSIE6或Firefox2上发送10个域是可以的。

    maxidle   该选项允许在闲置时间后忽略插入的cookie，只对insert模式的cookie有效。当cookie发送到客户端，cookie的日期也被发送过去。进一步讲，如果日期早于参数（秒）表示的延迟，cookie会被忽略，否则会根据发送给客户端的响应进行刷新。尤其是用户一直不关闭浏览器，可以避免在一台服务器上占用太长时间 (eg: after a farm size change)。如果设置了选项，但是cookie没有日期，这种情况是允许的，只是会一直在响应中刷新。这维护了管理员访问他们站点的能力。cookie的日期如果超过未来24小时也会被忽略掉，使管理员可以在修复时区问题时不必把用户踢下线。

    maxlife   该选项允许在生存时间过后忽略插入的cookie，不管是否还在使用，只对insert模式的cookie有效。当cookie发送到客户端，cookie的日期也被发送过去。进一步讲，如果日期早于参数（秒）表示的延迟，cookie会被忽略。如果request中的cookie没有日期，则会被设置一个日期。cookie的日期如果超过未来24小时也会被忽略掉，使管理员可以在修复时区问题时不必把用户踢下线。与maxidle不同，这个值是不刷新的，只在第一次访问日期计数。maxidle和maxlife可以一起使用，尤其是用户一直不关闭浏览器，可以避免在一台服务器上占用太长时间 (eg: after a farm size change)。与maxidle的超时后强行重新分配相比，这个要更好一些。

    每个HTTP后端可以只有一个持久cookie，并定义在default部分，cookie的值可以是"server"声明中"cookie"关键字后面的值。如果服务器没有指定cookie，则不会设置。

   Examples :
        cookie JSESSIONID prefix
        cookie SRV insert indirect nocache
        cookie SRV insert postonly indirect
        cookie SRV insert indirect nocache maxidle 30m maxlife 8h

  See also : "appsession", "balance source", "capture cookie", "server"  and "ignore-persist".

ignore-persist { if | unless }
  定义一个忽略持久性的条件。
  May be used in sections:    defaults | frontend | listen | backend
                                  no   |    yes   |   yes  |   yes
  默认情况下，如果启用了cookie持久性，每个请求的cookie都会无条件的持久化(假设目标服务器正常运行）。 "ignore-persist" 允许声明各种基于ACL的条件，可以使请求忽略持久性。对静态文件的均衡负载是很有用的，一般都不需要持久性。还可以用于对特定的用户代理User-Agent (如：一些网络爬虫机器人)禁用所有持久性。
  与 "appsession" 结合，还可以帮助减少HAProxy内存占用，如果忽略持久性，appsession表将不会增长。
  "if"条件满足时忽略持久性，或者非"unless"条件满足时。
  See also : "force-persist", "cookie", and section 7 about ACL usage.

force-persist { if | unless }
  定义一个强制持久性的条件给宕机的服务器。
  May be used in sections:    defaults | frontend | listen | backend
                                  no   |    yes   |   yes  |   yes
  默认情况下，请求不会发送给宕机的服务器。可以强制使用"option persist"发送请求，但这是无条件的，并且如果设置了"option redispatch"，还会重定向到一个可用的服务器。还有很少的情况下，需要将一些请求强制发送到一个服务器，如一些维护操作，此时服务器已经人为标记为宕机了。 "ignore-persist" 允许声明各种基于ACL的条件，可以使请求忽略服务器的宕机状态，并仍然尝试连接。这样可以使启动的服务器对健康检查返回错误，并运行专门配置的浏览器来测试服务。方便的方法就是用一个特定的源IP地址或特定的cookie。cookie还可以很容易的在浏览器的一个测试页上新增或删除。当服务可用时，可以返回正常的健康检查，重新对外提供服务。
    "if"条件满足时启用强制持久性，或者非"unless"条件满足时。使用了该选项，则会禁用重定向。
  See also : "option redispatch", "ignore-persist", "persist", and section 7 about ACL usage.