http：cooike和session

推荐阅读：

RFC 2965
http协议之cookie标准RFC6265介绍
android-CookieHandler、CookieManager
Android中Cookie的使用
HTTP cookies 详解
HTTP Cookie 详解二

一、Cookie和Session的区别和联系

参考：比特博文 | 5分钟搞懂cookie和session的区别

举个例子：

在学校旁边的一家面馆，有消费三碗免费一碗的活动。然而一次性消费三碗的可能性很小，需要用某种方式来记录顾客的消费状态，这时就有两种方案：

cookie方案: 发给顾客一张卡（cooike），上面记录着消费量，一般还有个时限。每次消费的时候顾客只要出示这张卡，则此次消费的状态就被记录下来了。这就是在客户端保持状态。

session方案: 同样发给顾客一张卡（cooike），但是卡上只有一个卡号（session id），用来标识用户身份，其他什么都没有。每次顾客去消费时，只要出示这张卡，则店员就在店里的记录本（session）上找到卡号所对应的记录，并且添加一些消费信息。这就是在服务器端保存状态的方法。

由于session方案需要session id(卡号)将客户端和服务器端连接起来，所以一般session机制需要借助cookie来在客户端保存session id。当然除了cookie还有一种url重写的方法也能够实现session机制。

为什么有了cookie还要用session

使用 cookie 有两个的弊端：
1、cookie 中的所有数据在客户端就可以被修改。这就意味着数据非常容易被伪造，一些重要的数据就不能存放在 cookie 中
2、如果 cookie 中数据字段太多会影响传输效率。

为了解决这些问题，就产生了 session，那么 session 又是怎样工作的呢？

每个 session 都对应一个 session_id，通过 session_id 可以查询到对应的 session，session_id 通常是存放在客户端的 cookie 中，服务端存好 session 之后将对应的 session_id 设置在 cookie 中发送给客户端。当请求到来时，服务端检查 cookie 中保存的 session_id 并通过这个 session_id 与服务器端的 session 关联起来，进行数据的保存和修改。

这意思就是说，当你浏览一个网页时，服务端随机产生一个很长的字符串，然后存在你 cookie 中。当你下次访问时，cookie 会带有这个字符串，然后浏览器就知道你是上次访问过的某某某，然后从服务器的存储中取出上次记录在你身上的数据。由于字符串是随机产生的，而且位数足够多，所以也不担心有人能够伪造。

cookie机制采用的是在客户端保持状态的方案，而session机制采用的是在服务器端保持状态的方案。两者存储的都是用户登录信息，操作行为等等的数据。一般情况，登录信息等重要信息存储在session中，其他信息存储在cookie中。

区别：

会话（Session）跟踪是Web程序中常用的技术，用来跟踪用户的整个会话。
常用的会话跟踪技术是Cookie与Session。
Cookie通过在客户端记录信息确定用户身份，
Session通过在服务器端记录信息确定用户身份。

1，session 在服务器端，cookie 在客户端（浏览器）
2，session 默认被存在在服务器的一个文件里（不是内存）
3，session 的运行依赖 session id，而 session id 是存在 cookie 中的，也就是说，如果浏览器禁用了 cookie ，同时 session 也会失效（但是可以通过其它方式实现，比如在 url 中传递 session_id）
4，session 可以放在 文件、数据库、或内存中都可以。
5，用户验证这种场合一般会用 session 因此，维持一个会话的核心就是客户端的唯一标识，即 session id

Cookie是客户端请求服务端时服务器会将一些信息以键值对的形式返回给客户端，保存在浏览器中，交互的时候可以加上这些Cookie值。用Cookie就可以方便的做一些缓存。Cookie的缺点是大小和数量都有限制；Cookie是存在客户端的可能被禁用、删除、篡改，是不安全的；Cookie如果很大，每次要请求都要带上，这样就影响了传输效率。

Cookie可以弥补HTTP协议无状态的不足。在Session出现之前，基本上所有的网站都采用Cookie来跟踪会话。

如果你把Cookies看成为http协议的一个扩展的话，理解起来就容易的多了，其实本质上cookies就是http的一个扩展。有两个http头部是专门负责设置以及发送cookie的,它们分别是Set-Cookie以及Cookie。当服务器返回给客户端一个http响应信息时，其中如果包含Set-Cookie这个头部时，意思就是指示客户端建立一个cookie，并且在后续的http请求中自动发送这个cookie到服务器端，直到这个cookie过期。如果cookie的生存时间是整个会话期间的话，那么浏览器会将cookie保存在内存中，浏览器关闭时就会自动清除这个cookie。另外一种情况就是保存在客户端的硬盘中，浏览器关闭的话，该cookie也不会被清除，下次打开浏览器访问对应网站时，这个cookie就会自动再次发送到服务器端。
　　
参考：Cookie 和 Session 的使用简记

二、cooike

cooike特点：

Cookie 就是浏览器储存在用户电脑上的一小段文本文件
Cookie 是纯文本格式，不包含任何可执行的代码
Cookie 由键值对构成，由分号和空格隔开
Cookie 虽然是存储在浏览器，但是通常由服务器端进行设置
Cookie 的大小限制在 4kb 左右,单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。

cooike属性：

每个 Cookie 都有一定的属性，如什么时候失效，要发送到哪个域名，哪个路径等等。在设置任一个 Cookie 时都可以设置相关的这些属性，当然也可以不设置，这时会使用这些属性的默认值。

String name：该Cookie的名称。Cookie一旦创建，名称便不可更改。

Object value：该Cookie的值。如果值为Unicode字符，需要为字符编码。如果值为二进制数据，则需要使用BASE64编码。

int maxAge：该Cookie失效的时间，单位秒。如果为正数，则该Cookie在maxAge秒之后失效。如果为负数，该Cookie为临时Cookie，关闭浏览器即失效，浏览器也不会以任何形式保存该Cookie。如果为0，表示删除该Cookie。默认为–1。

boolean secure：该Cookie是否仅被使用安全协议传输。安全协议。安全协议有HTTPS，SSL等，在网络上传输数据之前先将数据加密。默认为false。
指定cookie的值如何通过网络在用户和web服务器之间传递。缺省情况下，这个属性为空，默认使用http传递数据。如果被标记为”secure”，则使用HTTPS传递数据。

String path：该Cookie的使用路径。如果设置为“/sessionWeb/”，则只有contextPath为“/sessionWeb”的程序可以访问该Cookie。如果设置为“/”，则本域名下contextPath都可以访问该Cookie。注意最后一个字符必须为“/”。

String domain：可以访问该Cookie的域名。如果设置为“.google.com”，则所有以“google.com”结尾的域名都可以访问该Cookie。注意第一个字符必须为“.”。

String comment：该Cookie的用处说明。浏览器显示Cookie信息的时候显示该说明。

int version：该Cookie使用的版本号。0表示遵循Netscape的Cookie规范，1表示遵循W3C的RFC 2109规范。

expires / max-age区别：

expires / max-age
expires / max-age 都是控制 Cookie 失效时刻的选项。如果没有设置这两个选项，则默认有效期为 session，即会话 Cookie。这种 Cookie 在浏览器关闭后就没有了。

expires
expires 选项用来设置 Cookie 什么时间内有效，expires 其实是 Cookie 失效日期。
expires 必须是 GMT 格式的时间（可以通过 new Date().toGMTString() 或者 new Date().toUTCString() 来获得）

max-age
expires 是 http/1.0 协议中的选项，在新的 http/1.1 协议中 expires 已经由 max-age 选项代替，两者的作用都是限制 Cookie 的有效时间。expires 的值是一个时间点 (Cookie 失效时刻 = expires)，而 max-age 的值是一个以秒为单位时间段 (Cookie 失效时刻 = 创建时刻 + max-age)

优先级

如果同时设置了 max-age 和 expires，以 max-age 的时间为准。

domain 和 path

name、domain 和 path 可以标识一个唯一的 Cookie。domain 和 path 两个选项共同决定了 Cookie 何时被浏览器自动添加到请求头部中发送出去。

如果没有设置这两个选项，则会使用默认值。domain 的默认值为设置该 Cookie
的网页所在的域名，path 默认值为设置该 Cookie 的网页所在的目录。

httpOnly

这个选项用来设置 Cookie 是否能通过 js 去访问。默认情况下，Cookie 不会带 httpOnly 选项(即为空)，客户端是可以通过 js 代码去访问（包括读取、修改、删除等）这个 Cookie 的。当 Cookie 带 httpOnly 选项时，客户端则无法通过 js 代码去访问（包括读取、修改、删除等）这个 Cookie。
客户端中无法设置 HttpOnly 选项。

设置 Cookie

明确一点：Cookie 可以由服务端设置，也可以由客户端设置。
一个 Set-Cookie 字段只能设置一个 Cookie，当你要想设置多个 Cookie，需要添加同样多的 Set-Cookie 字段
服务端可以设置 Cookie 的所有选项：expires、domain、path、secure、HttpOnly

删除 Cookie

Cookie 的 name、path 和 domain 是唯一标识一个 Cookie 的。我们只要将一个 Cookie 的 max-age 设置为 0，就可以删除一个 Cookie 了。

三、session

session 储存

session 的储存有四个常用选项：内存、 cookie、缓存、数据库

内存：开发环境存内存比较方便，问题是不能够共享状态（只能在本机访问）
cookie：使用 cookie 来储存 session 的话，session 保存在用户浏览器端，每次用户访问时，都会主动带上他自己的信息。安全性的话，只要遵照最佳实践来，也是有保证的。它的弊端是增大了数据量传输，好处是比较方便
缓存：可以共享
数据库：可以共享

signedCookie

如果非要使用 cookie 来记录登陆的用户凭证，也不是不可以，只需要做一些对 cookie 做一个哈希处理就好了。
这样一来，用户就没法伪造信息了。一旦它更改了 cookie 中的信息，则服务器会发现 hash 校验的不一致。
毕竟他不懂我们的 secret_string 是什么，而暴力破解哈希值的成本太高。

特点：

Session是基于Cookie来实现的，不同的是Session本身存在于服务端，但是每次传输的时候不会传输数据，只是把代表一个客户端的唯一ID（通常是JSESSIONID）写在客户端的Cookie中，这样每次传输这个ID就可以了。

Session的优势就是传输数据量小，比较安全。
但是Session也有缺点，就是如果Session不做特殊的处理容易失效、过期、丢失或者Session过多导致服务器内存溢出，并且要实现一个稳定可用安全的分布式Session框架也是有一定复杂度的。在实际使用中就要结合Cookie和Session的优缺点针对不同的问题来设计解决方案。

通讯过程：

第一次请求接口，我们看到 Request Headers 并没有 Cookie 这个字段
但是 Response Headers 有了 Set-Cookie 这个字段：

现在我们刷新一下页面，相当于重新向接口这个地址发起了一次请求。

现在我们就可以看到 Cookie 字段已经带上了，再刷新几次看 Cookie 也还是在的。

参考：Cookie 在前端中的实践
参考：Session是什么

session的实现原理

服务器会为每一个访问服务器的用户创建一个session对象，并且把session对象的id保存在本地cookie上，只要用户再次访问服务器时，带着session的id，服务器就会匹配用户在服务器上的session，根据session中的数据，还原用户上次的浏览状态或提供其他人性化服务。

浏览器禁用cookie后如何实现session

如果客户端浏览器将Cookie功能禁用，或者不支持Cookie怎么办？例如，绝大多数的手机浏览器都不支持Cookie。Java Web提供了另一种解决方案：URL地址重写。

URL地址重写

URL重写就是首先获得一个进入的URL请求然后把它重新写成网站可以处理的另一个URL的过程。举个例子来说，如果通过浏览器进来的URL是“UserProfile.aspx?ID=1”那么它可以被重写成 “UserProfile/1.aspx”，这样的URL，这样的网址可以更好的被网站所阅读。

如何通过URL地址重写实现session的id传输

URL地址重写的原理是将该用户Session的id信息重写到URL地址中。服务器能够解析重写后的URL获取Session的id。这样即使客户端不支持Cookie，也可以使用Session来记录用户状态。HttpServletResponse类提供了encodeURL(String url)实现URL地址重写，该方法会自动判断客户端是否支持Cookie。如果客户端支持Cookie，会将URL原封不动地输出来。如果客户端不支持Cookie，则会将用户Session的id重写到URL中。

四、session和cookie的有效时长

session的有效时长

服务器会把长时间没有活动的Session从服务器内存中清除，此时Session便失效。具体根据服务器设置，一般在二三十分钟左右。

cookie的有效时长

cookie的内容主要包括：名字，值，过期时间，路径和域。路径与域一起构成cookie的作用范围。通过过期时间可以设置cookie的有效时长.
若不设置过期时间: 表示这个cookie的生命周期为浏览器回话期间，关闭访问服务器的浏览器窗口，cookie就消失了。一般称为回话cookie，保存在内存中
若设置了过期时间：则cookie会存储在硬盘上，直到超过有效时间。