http之cookie&&session

[toc]

是什么

早期的 Web 应用面临的最大问题之一就是如何维持状态。简言之，服务器无法知道两个请求是否来自于同一个浏览器。当时，最简单的办法就是在请求的页面中插入一个 token，然后在下次请求时将这个 token 返回至服务器。后面就衍生出来cookie。简单地说，cookie 就是浏览器储存在用户电脑上的一小段文本文件。cookie 是纯文本格式，不包含任何可执行的代码。一个 Web 页面或服务器告知浏览器按照一定规范来储存这些信息，并在随后的请求中将这些信息发送至服务器，Web 服务器就可以使用这些信息来识别不同的用户。

创建cookie

Web 服务器通过发送一个称为 Set-Cookie 的 HTTP 消息头来创建一个 cookie，Set-Cookie消息头是一个字符串，其格式如下（中括号中的部分是可选的）

1	Set-Cookie: value[; expires=date][; domain=domain][; path=path][; secure]

服务器端框架通常包含解析 cookie 的方法，可以通过编程的方式获取 cookie 的值。

cookie过期时间

紧跟 cookie 值后面的每个选项都以分号和空格分开，每个选择都指定了 cookie 在什么情况下应该被发送至服务器。第一个选项是过期时间（expires），指定了 cookie 何时不会再被发送至服务器，随后浏览器将删除该 cookie。该选项的值是一个 Wdy, DD-Mon-YYYY HH:MM:SS GMT日期格式的值，例如：

1	Set-Cookie: name=Nicholas; expires=Sat, 02 May 2009 23:38:25 GMT

没有设置 expires 选项时，cookie 的生命周期仅限于当前会话中（会话cookie），关闭浏览器意味着这次会话的结束，所以会话 cookie 仅存在于浏览器打开状态之下。这就是为什么为什么当你登录一个 Web 应用时经常会看到一个复选框，询问你是否记住登录信息：如果你勾选了复选框，那么一个 expires 选项会被附加到登录 cookie 中（持久化cookie）。如果 expires 设置了一个过去的时间点，那么这个 cookie 会被立即删掉。

secure选项

最后一个选项是 secure。不像其它选项，该选项只是一个标记而没有值。只有当一个请求通过 SSL 或 HTTPS 创建时，包含 secure 选项的 cookie 才能被发送至服务器。这种 cookie 的内容具有很高的价值，如果以纯文本形式传递很有可能被篡改，例如：

1	Set-Cookie: name=Nicholas; secure

事实上，机密且敏感的信息绝不应该在 cookie 中存储或传输，因为 cookie 的整个机制原本都是不安全的。默认情况下，在 HTTPS 链接上传输的 cookie 都会被自动添加上 secure 选项。

expires 属性

Cookie 的expires 属性指定浏览器可发送Cookie 的有效期。当省略expires 属性时，Cookie仅在浏览器关闭之前有效。
另外，一旦Cookie 从服务器端发送至客户端，服务器端就不存在可以显式删除Cookie 的方法。但可通过覆盖已过期的Cookie，实现对客户端Cookie 的实质性删除操作。

path 属性

Cookie 的path 属性可用于限制指定Cookie 的发送范围的文件目录。不过另有办法可避开这项限制，看来对其作为安全机制的效果不能抱有期待。

domain 属性

通过Cookie 的domain 属性指定的域名可做到与结尾匹配一致。比如，当指定http://example.com 后，除http://example.com 以外，okr.example.com 或 www2.example.com 等都可以发送Cookie。因此，除了针对具体指定的多个域名发送Cookie 之外，不指定domain 属性显得更安全。

secure 属性

Cookie 的secure 属性用于限制Web 页面仅在HTTPS 安全连接时，才可以发送Cookie。发送Cookie 时，指定secure 属性的方法如下所示。
Set-Cookie: name=value; secure
以上例子仅当在https ：//Example Domain（HTTPS）安全连接的情况下才会进行Cookie 的回收。也就是说，即使域名相同时http : //Example Domain（HTTP）也不会发生Cookie 回收行为。当省略secure 属性时，不论HTTP 还是HTTPS，都会对Cookie 进行回收。

HttpOnly 属性

Cookie 的HttpOnly 属性是Cookie 的扩展功能，它使JavaScript 脚本无法获得Cookie。其主要目的为防止跨站脚本攻击（Cross-sitescripting，XSS）对Cookie 的信息窃取。
发送指定HttpOnly 属性的Cookie 的方法如下所示。
Set-Cookie: name=value; HttpOnly
通过上述设置，通常从Web 页面内还可以对Cookie 进行读取操作。但使用JavaScript 的document.cookie 就无法读取附加HttpOnly 属性后的Cookie 的内容了。因此，也就无法在XSS 中利用JavaScript 劫持Cookie 了。
虽然是独立的扩展功能，但Internet Explorer 6 SP1 以上版本等当下的主流浏览器都已经支持该扩展了。另外顺带一提，该扩展并非是为了防止XSS 而开发的。

session

介绍

cookie 虽然很方便，但是使用 cookie 有一个很大的弊端，cookie 中的所有数据在客户端就可以被修改，数据非常容易被伪造，那么一些重要的数据就不能存放在 cookie 中了，而且如果 cookie 中数据字段太多会影响传输效率。为了解决这些问题，就产生了 session，session 中的数据是保留在服务器端的。Session是另一种记录客户状态的机制，不同的是Cookie保存在客户端浏览器中，而Session保存在服务器上。客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上。这就是Session。客户端浏览器再次访问时只需要从该Session中查找该客户的状态就可以了。

session运作

session 的运作通过一个 session_id 来进行。session_id 通常是存放在客户端的 cookie 中。session可以存放在任何位置，一般是放内存或者缓存中。

初学者容易犯的一个错误是，忘记了 session_id 在 cookie 中的存储方式是 session cookie。即，当用户一关闭浏览器，浏览器 cookie 中的 session_id 字段就会消失。常见的场景就是在开发用户登陆状态保持时。假如用户在之前登陆了你的网站，你在他对应的 session 中存了信息，当他关闭浏览器再次访问时，你还是不懂他是谁。所以我们要在 cookie 中，也保存一份关于用户身份的信息。

总结

一、基于Session实现会话保持

基于Session实现会话保持的原理是：在会话的开始（即客户端第一次向服务器发送HTTP请求时），服务器会将会话状态保存起来（一般保存在本机内存，当然也可以保存在其他存储系统），然后分配一个会话标识（也叫SessionId）给客户端，这个会话标识一般保存在浏览Cookie里，以后每次浏览器发送HTTP请求的时候，都会带上这个会话标识到服务器，服务器拿到这个会话标识之后就可以把之前存储在服务端的状态信息与该会话联系起来，因此也就实现了会话保持。当然如果遇到浏览器禁用了Cookie的情况，则可以通过url重写的方式将会话标识放在url的参数里，这样也可以实现会话保持。

二、基于Cookie实现会话保持

基于Cookie实现会话保持与上述基于Session实现会话保持的最主要区别是前者完全将会话状态信息存储在浏览器Cookie中，这样一来每次浏览器发送HTTP请求的时候都会带上状态信息，因此也就可以实现状态保持。以上述购物车应用为例，服务端可以将商品信息加密（也可以不加密，但为了安全性，一般会此对状态信息进行加密处理）后保存在浏览器的Cookie中，这样一来服务端就能知道你在浏览的过程中添加了哪些商品到购物车中了。

三、两者的优缺点

基于Session的会话保持的优点是具有安全性，因为状态信息是保存在服务端的，缺点是不便于服务器的水平扩展。大型网站的后台一般都不止一台服务器，可能几台甚至上百台，浏览器发送的HTTP请求一般要先通过负载均衡器才能到达具体的后台服务器，这就会导致每次HTTP请求可能落到不同的服务器上，比如说第一次HTTP请求落到server1上，第二次HTTP请求落到server2上。而Session默认是存储在服务器本机内存的，当多次请求落到不同的服务器上时，上述方案就不能实现会话保持了。

基于Cookie的会话保持的优点是服务器不用保存状态信息，减轻服务端存储压力，也便于服务端做水平扩展。缺点是不够安全，因为状态信息是存储在客户端的，这意味着不能在会话中保存机密数据，另一个缺点是每次HTTP请求都需要发送额外的Cookie到服务端，会消耗更多带宽。

总结

通过这篇文章，你会知道。

cookie 是什么。
cookie 怎么使用
session
session怎么使用
一般来说，都是cookie中存储 session_id=”xxx”，请求服务端时，服务端拿到xxx中的信息后，去内存，或者缓存中拿存储的数据，所以不存在说水平扩展的问题，上面人的说法只是在特定的模式下成立。

参考

看云：https://www.kancloud.cn/kancloud/http-cookies-explained（全文摘录）

看云：https://www.kancloud.cn/codepan/cookie-session

微信：谈谈http的状态

是什么

Cookie