1 Cookie机制

cookie的功能是有浏览器和服务器协商实现的。当然还是需要操作系统。

当用户使用浏览器访问一个支持Cookie的网站的时候，用户会提供包括用户名在内的个人信息并且提交至服务器；接着，服务器在向客户端回传相应的超文本的同时也会发回这些个人信息，当然这些信息并不是存放在HTTP响应体（Response Body）中Set-Cookie，而是存放于HTTP响应头（Response Header）；当客户端浏览器接收到来自服务器的响应之后，浏览器会将这些信息存放在一个统一的位置。

当客户端再向服务器发送请求的时候，都会把相应的Cookie再次发回至服务器。而这次，Cookie信息则存放在HTTP请求头（Request Header）了。服务器在接收到来自客户端浏览器的请求之后，就能够通过分析存放于请求头的Cookie得到客户端特有的信息，从而动态生成与该客户端相对应的内容。

浏览器不会对cookie做任何更改，会原封不动的发送回服务器

格式：

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

value 部分，通常是一个 name=value 格式的字符串，实际上，可以指定一个不含等号的字符串，它同样会被存储。

当存在多个cookie时，用分号和空格隔开：

Cookie: name=value; name1=value1; name2=value2

expires选项：不设置cookie过期时间，cookie会在会话结束后销毁，称为会话cookie。如果想将会话cookie设置为持久cookie，只需设置一下cookie的过期时间即可。持久cookie是无法改成会话cookie，除非删除这个cookie，然后重新建立这个cookie。

domian选项：设置了cookie的域，只有发向这个域的http请求才能携带这些cookie。一般情况下domain会被设置为创建该cookie的页面所在的域名。

像 Yahoo! 这种大型网站，都会有许多 name.yahoo.com 形式的站点（例如：my.yahoo.com, finance.yahoo.com 等等）。将一个 cookie 的 domain 选项设置为 yahoo.com，就可以将该 cookie 的值发送至所有这些站点。浏览器会把 domain 的值与请求的域名做一个尾部比较（即从字符串的尾部开始比较），并将匹配的 cookie 发送至服务器。

path选项：和domain选项类似，只有包含指定path的http请求才能携带这些cookie。这个比较通常是将 path 选项的值与请求的 URL 从头开始逐字符比较完成的。如果字符匹配，则发送 Cookie 消息头，

set-cookie:namevalue;path=/blog

所以包含/blog的http请求都会携带cookie信息。

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

事实上,机密且敏感的信息绝不应该在 cookie 中存储或传输，因为 cookie 的整个机制原本都是不安全的。

HTTP-Only：的意思是告之浏览器该 cookie 绝不能通过 JavaScript 的 document.cookie 属性访问。设计该特征意在提供一个安全措施来帮助阻止通过 JavaScript 发起的跨站脚本攻击 (XSS) 窃取 cookie 的行为。

过期时间：

会话 cooke (Session cookie) 在会话结束时（浏览器关闭）会被删除。
持久化 cookie（Persistent cookie）在到达失效日期时会被删除。
如果浏览器中的 cookie 数量达到限制，那么 cookie 会被删除以为新建的 cookie 创建空间。

问题：

实际上，Cookie中保存的用户名、密码等个人敏感信息通常经过加密，很难将其反向破解，但是可以直接通过偷取的Cookie骗取网站信任

跨站Cookie恰恰就是用户隐私泄露的罪魁祸首，所以限制网站使用跨站Cookie，给用户提供禁止跟踪(DNT)功能选项

2 Session机制

Session是服务器端使用的一种记录客户端状态的机制，使用上比Cookie简单一些，相应的也增加了服务器的存储压力。

Session技术则是服务端的解决方案，它是通过服务器来保持状态的。

通常，session是依赖cookie的，当用户访问某一站点时，服务器会为这个用户产生唯一的session_id,并把这个session_id以cookie的形式发送到客户端，以后的客户端的所有请求都会自动携带这个cookie（前提是浏览器支持并且没有禁用cookie）。

禁用cookie时如何使用session：

session没有单独的HTTP字段，因此他的传输是依赖于cookie的，但是当服务器禁用了cookie的时候，那么session在刚开始，第一次访问的时候，就没有办法做到自动登录。

但是在用户登录以后，服务器端找到对应的session，或是新生成一个session，然后将该session返回给客户端，然后修改客户端的请求连接，将所有的请求连接中都带上session，例如get中作为后缀加上。