会话
Http协议是无状态的协议,在网络传输中的每次连接断开后,需要重新再去连接,因此服务器端是无法判断此次连接的客户端是谁。如果每次数据传输都需要进行连接和断开,那造成的开销是很巨大的。并且网站有会员和非会员区别,同时,有浏览网站和登录账户购物等需求,因此就需要一种方法区别不同访问的用户是谁,于是会话就应运而生。会话是通过cookie和session实现的。
会话保持
负载均衡集群后面有多个节点,如果一个用户的多次请求被分配到多个不同节点,就会导致用户登录了网站后(假如分配到A节点),然后在点击进入其它页面后,就会出现未登录状态的问题,这显然是不行的。会话保持就是运行负载均衡集群时需要的一种机制,在负载均衡的同时还保证一系列相关连的访问请求都会分配到同一台机器上。一句话说明就是在一次会话过程中发起的多个请求都会落到同一台机器上。
cookie
为了解决网络访问的用户是谁的问题,因此cookie应运而生,当用户登陆成功后,服务器会在返回响应数据的同时也携带着cookie信息给到客户端浏览器,之后客户端每次发起请求只要携带着这个cookie信息,服务端就会验证这个cookie信息,进而判断用户是谁,用户则会处于登录的状态,无需再登录,同时也改善了网络传输效率。
但是由于cookie是保存在客户端浏览器的数据,因此也很容易被获取,存在安全方面隐患。
session
session本质是通过以cookie的方式向客户端发送随机字符串,每次客户端发起请求时只要携带
该随机字符串便可被服务端获取进而验证用户登录的身份。session的实现依赖于cookie。
session信息是保存在服务端的数据。
session和cookie的区别
cookie | session | |
---|---|---|
存放位置 | 客户端 | 服务端 |
作用 | 存放服务端下发的信息,sessionid等。 | 存放用户登录信息,用户名、密码、sessionid、购物车信息等 |
安全性 | 不安全,容易被伪造 | 安全 |
生产应用 | 其他信息可存放在cookie中 | 登录信息等重要信息放在session中 |
即采用将session集中存储到某一固定地点:
a.文件中存放(PHP服务默认)。
b.数据库中存放即采用将session存储至MySQL数据库中(例如:discuz论坛)
c.内存数据库(memcache,redis)中存放(推荐)
即采用统一的内存数据库存储方式,将session存储到redis或memcached中。中小企业推荐使用内存数据库实现。
优点:速度快。缺点:需要配置内存数据库,并且要配置Nginx动态服务配置文件。
在基于cookie模式下负载均衡器负责插入cookie,后端服务器无需作出任何修改。当客户端进行第一次请求时,客户端的HTTP request(不带cookie)进入负载均衡器, CLB根据负载平衡算法策略选择后端一台服务器,并将请求发送至该服务器;后端服务器的HTTP response(不带cookie)被发回给负载均衡器。接下来负载均衡器将向该会话插入cookie并将HTTP response返回到客户端。
当客户请求再次发生时,客户HTTP request(带有上次负载均衡器插入的cookie)进入CLB,然后CLB读出cookie里的会话保持数值,将HTTP request(带有与上面同样的cookie)发到指定的服务器,然后后端服务器进行请求回复;由于服务器并不写入cookie,HTTP response将不带cookie,该HTTP response再次经过进入CLB时,CLB将写入更新后的会话保持cookie。腾讯云CLB的7层会话保持能力,就是基于这样的cookie插入的方式实现的。Haproxy也支持cookie插入的方式,但是Nginx默认不支持此种方式。
优点:不需要后端服务和程序支持,只在负载均衡器配置即可(需要负载均衡器支持)。缺点:消耗负载均衡资源
即使用nginx ip_hash的调度算法,将同一用户的请求始终分配至同一服务器上。
优点:实现简单。缺点:导致负载失衡(特别是NAT上网的情况下)。
负载均衡器会为每一个处于保持状态中的会话设定一个时间值。若一个会话从上一次完成到下次再来之间的间隔时间小于超时值时,负载均衡器将会将新的连接进行会话保持;但如果这个间隔大于该超时值,负载均衡器会将新来的连接认为是新的会话然后进行负载平衡。
优点:实现简单。缺点:也会导致负载有一定的失衡,仅LVS等少数软件支持。
即采用复制的方法,当产生session时,同步复制到所有集群节点,比如tomcat集群功能。