HAproxy中的Session

酒千殇

于 2021-02-25 19:03:00 发布

阅读量753

点赞数

CC 4.0 BY-SA版权

分类专栏： HAproxy 文章标签： HAproxy sticky session cookie 粘性会话

本文链接：https://blog.youkuaiyun.com/qq_40492048/article/details/114062145

HAproxy 专栏收录该内容

1 篇文章

订阅专栏

本文介绍了Session和Cookie的概念及其区别，Session用于服务器端保持状态，而Cookie在客户端保存状态。当使用HAproxy进行负载均衡时，为了解决用户会话数据的问题，可以启用粘性会话（sticky session）。HAproxy通过配置文件实现这一功能，确保用户请求始终被路由到同一服务器，以保持会话连续性。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

一.什么是Session？

一个session是一次短暂的信息交流。交换对象可以是两个或多个设备，或者计算机和用户之间。session的生命历程：建立->撤销->终结。一个建立好的session在每一方都可能不止要交换一个信息。session是有状态的，即交流方至少有一方需要保持状态信息和保存session历史信息。任何一个单向传输都不是一个session。

区分：TCP连接描述的是分散的事件。TCP session描述的是一个持续的状态，它跟踪各种元数据。
session机制采用的是一种在服务器端保持状态
采用服务器端保持状态的方案在客户端也需要保存一个标识，所以session机制可能需要借助于cookie机制来达到保存标识的目的。而session提供了方便管理全局变量的方式。
session是针对每一个用户的，变量的值保存在服务器上，用一个sessionID来区分是哪个用户session变量,这个值是通过用户的浏览器在访问的时候返回给服务器，当客户禁用cookie时，这个值也可能设置为由get来返回给服务器。
客户端请求创建一个session时，服务器检查是否已经为他创建过session id；若有，就用此id；否则，为它新创session id。

二.什么是Cookie

Cookies是服务器在本地机器上存储的小段文本。
它随每一个请求发送至同一个服务器。网络服务器用HTTP头向客户端发送cookies，在客户终端，浏览器解析这些cookies并将它们保存为一个本地文件，它会自动将同一服务器的任何请求缚上这些cookies 。

cookie机制采用的是在客户端保持状态。

正统的cookie分发是通过扩展HTTP协议来实现的，服务器通过在HTTP的响应头中加上一行特殊的指示以提示浏览器按照指示生成相应的cookie。而cookie的使用是由浏览器按照一定的原则在后台自动发送给服务器的

cookie的内容主要包括：名字，值，过期时间，路径和域。路径与域一起构成cookie的作用范围。这种生命期为浏览器会话期的cookie被称为会话cookie。会话cookie一般不存储在硬盘上而是保存在内存里，当然这种行为并不是规范规定的。若设置了过期时间，浏览器就会把cookie保存到硬盘上，关闭后再次打开浏览器，这些cookie仍然有效直到超过设定的过期时间。存储在硬盘上的cookie可以在不同的浏览器进程间共享，比如两个IE窗口。而对于保存在内存里的cookie，不同的浏览器有不同的处理方式。
详见此文

三.利用HAproxy实现粘性会话(sticky session)

HAproxy可以实现负载均衡，当HAproxy配置文件中负载均衡算法为：roundrobin时，可以实现服务请求的轮流分配。从而实现负载均衡。

而另外一种情况是：一个web服务器使用php的默认session处理时，所以的session数据都会保存在那台服务器上。如果用户A登录服务器A，则服务器A会保存它的session数据。此时，如果负载均衡器把用户请求派发给服务器B，则服务器B不能读取session数据。因为用户A的session数据保存在服务器A上。该如何解决呢？(此处两服务器可提供和对方一样的功能)

用粘性会话配置Haproxy负载均衡器可以解决这个问题。当启动一个粘性会话时，一个客户端会锁定在某个服务器上。也就是说，用户一旦登录服务器B，它将锁定在服务器B上，直到会话停止。

以上的实现通过修改配置文件即可完成。配置完成后一定记得重启服务。
配置文件如下：实现关键是对backend模块的配置。

global
        log /dev/log    local0
        log /dev/log    local1 notice
        chroot /var/lib/haproxy
        stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners
        stats timeout 30s
        user haproxy
        group haproxy
        daemon

        # Default SSL material locations
        ca-base /etc/ssl/certs
        crt-base /etc/ssl/private

        # Default ciphers to use on SSL-enabled listening sockets.
        # For more information, see ciphers(1SSL). This list is from:
        #  https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/
        # An alternative list with additional directives can be obtained from
        #  https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=haproxy
        ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS
        ssl-default-bind-options no-sslv3

defaults
        log     global
        mode    http
        retries 3
        option  httplog
        option  dontlognull
        timeout connect 5000
        timeout client  50000
        timeout server  50000
        errorfile 400 /etc/haproxy/errors/400.http
        errorfile 403 /etc/haproxy/errors/403.http
        errorfile 408 /etc/haproxy/errors/408.http
        errorfile 500 /etc/haproxy/errors/500.http
        errorfile 502 /etc/haproxy/errors/502.http
        errorfile 503 /etc/haproxy/errors/503.http
        errorfile 504 /etc/haproxy/errors/504.http
###########################################
frontend app01
        bind *:8081
        default_backend app01_backend
backend app01_backend
        balance roundrobin
        cookie SERVICEID insert nocache#设置cookie SERVICEID。客户端的第一次请求按照轮询的方式，发给服务器。然后cookie就被设置在那个客户端了。
        server web1 10.32.203.79:8080 cookie SA check#服务器web1收到请求，
        server web2 10.32.201.102:8080 cookie SB check
######################################################
listen stats
       bind *:8083
       stats enable
       stats uri /haproxy
       stats auth admin:admin
       stats admin if TRUE
       stats refresh 1ms