好程序员 web 前端分享 Cookie 知识 ，今天小编为大家带来了一篇新手必看干货，接下来 让我们一起来看一看 吧 。

　　 一、 Cookie 的出现

　　 浏览器和服务器之间的通信少不了 HTTP 协议，但是因为 HTTP 协议是无状态的，所以服务器并不知道上一次浏览器做了什么样的操作，这样严重阻碍了交互式 Web 应用程序的实现。

　　 针对上述的问题，网景公司的程序员创造了 Cookie 。

　　 二、 Cookie 的传输

　　 服务器端在实现 Cookie 标准的过程中，需要对任意 HTTP 请求发送 Set-Cookie HTTP 头作为响应的一部分：

　　 1. Set-Cookie: name=value; expires=Tue, 03-Sep-2019 14:10:21 GMT; path=/; domain=.xxx.com;

　　 浏览器端会存储这样的 Cookie ，并且为之后的每个请求添加 Cookie HTTP 请求头发送回服务器：

　　 1. Cookie: name=value

　　 服务器通过验证 Cookie 值，来判断浏览器发送请求属于哪一个用户。

　　 三、浏览器中的 Cookie

　　 浏览器中的 Cookie 主要由以下几部分组成：

　　 · 名称： Cookie 唯一的名称，必须经过 URL 编码处理。 ( 同名会出现覆盖的情况 )

　　 · 值：必须经过 URL 编码处理。

　　 · 域 (domain) ：默认情况下 cookie 在当前域下有效，你也可以设置该值来确保对其子域是否有效。

　　 · 路径 (path) ：指定 Cookie 在哪些路径下有效，默认是当前路径下。

　　 · 失效时间 (expires) ：默认情况下，浏览器会话结束时会自动删除 Cookie; 也可以设置一个 GMT 格式的日期，指定具体的删除日期 ; 如果设置的日期为以前的日期，那么 Cookie 会立即删除。

　　 · 安全标志 (secure) ：指定之后只允许 Cookie 发送给 https 协议。

　　 浏览器在发送请求时，只会将名称与值添加到请求头的 Cookie 字段中，发送给服务端。

　　 浏览器提供了一个非常蹩脚的 API 来操作 Cookie ：

　　 1. document.cookie

　　 通过上述方法可以对该 Cookie 进行写操作，每一次只能写入一条 Cookie 字符串：

　　 1. document.cookie = 'a=1; secure; path=/'

　　 通过该方法还可以进行 Cookie 的读操作：

　　 1. document.cookie // "a=1"

　　 由于上述方法操作 Cookie 非常的不直观，一般都会写一些函数来简化 Cookie 读取、设置和删除操作。

　　 对于 Cookie 的设置操作中，需要以下几点：

　　 对于名称和值进行 URL 编码处理，也就是采用 JavaScript 中的 encodeURIComponent() 方法 ; expires 要求传入 GMT 格式的日期，需要处理为更易书写的方式，比如：设置秒数的方式 ; 注意只有的属性名的 secure;

　　 每一段信息需要采用分号加空格。

　　 1. function setCookie (key, value, attributes) {

　　 2. if (typeof document === 'undefined') {

　　 3. return

　　 4. }

　　 5. attributes = Object.assign({}, {

　　 6. path: '/'

　　 7. }, attributes)

　　 8.

　　 9. let { domain, path, expires, secure } = attributes

　　 10.

　　 11. if (typeof expires === 'number') {

　　 12. expires = new Date(Date.now() + expires * 1000)

　　 13. }

　　 14. if (expires instanceof Date) {

　　 15. expires = expires.toUTCString()

　　 16. } else {

　　 17. expires = ''

　　 18. }

　　 19.

　　 20. key = encodeURIComponent(key)

　　 21. value = encodeURIComponent(value)

　　 22.

　　 23. let cookieStr = `${key}=${value}`

　　 24.

　　 25. if (domain) {

　　 26. cookieStr += `; domain=${domain}`

　　 27. }

　　 28.

　　 29. if (path) {

　　 30. cookieStr += `; path=${path}`

　　 31. }

　　 32.

　　 33. if (expires) {

　　 34. cookieStr += `; expires=${expires}`

　　 35. }

　　 36.

　　 37. if (secure) {

　　 38. cookieStr += `; secure`

　　 39. }

　　 40.

　　 41. return (document.cookie = cookieStr)

　　 42.}

　　 Cookie 的读操作需要注意的是将名称与值进行 URL 解码处理，也就是调用 JavaScript 中的 decodeURIComponent() 方法：

　　 1. function getCookie (name) {

　　 2. if (typeof document === 'undefined') {

　　 3. return

　　 4. }

　　 5. let cookies = []

　　 6. let jar = {}

　　 7. document.cookie && (cookies = document.cookie.split('; '))

　　 8.

　　 9. for (let i = 0, max = cookies.length; i < max; i++) {

　　 10. let [key, value] = cookies[i].split('=')

　　 11. key = decodeURIComponent(key)

　　 12. value = decodeURIComponent(value)

　　 13. jar[key] = value

　　 14. if (key === name) {

　　 15. break

　　 16. }

　　 17. }

　　 18.

　　 19. return name ? jar[name] : jar

　　 20.}

　　 最后一个清除的方法就更加简单了，只要将失效日期 (expires) 设置为过去的日期即可：

　　 1. function removeCookie (key) {

　　 2. setCookie(key, '', { expires: -1 })

　　 3. }

　　 介绍 Cookie 基本操作的封装之后，还需要了解浏览器为了限制 Cookie 不会被恶意使用，规定了 Cookie 所占磁盘空间的大小以及每个域名下 Cookie 的个数。

　　 四、服务端的 Cookie

　　 相比较浏览器端，服务端执行 Cookie 的写操作时，是将拼接好的 Cookie 字符串放入响应头的 Set-Cookie 字段中 ; 执行 Cookie 的读操作时，则是解析 HTTP 请求头字段 Cookie 中的键值对。

　　 与浏览器最大的不同，在于服务端对于 Cookie 的安全性操碎了心

　　 signed

　　 当设置 signed=true 时，服务端会对该条 Cookie 字符串生成两个 Set-Cookie 响应头字段：

　　 1. Set-Cookie: lastTime=2019-03-05T14:31:05.543Z; path=/; httponly

　　 2. Set-Cookie: lastTime.sig=URXREOYTtMnGm0b7qCYFJ2Db400; path=/; httponly

　　 这里通过再发送一条以 .sig 为后缀的名称以及对值进行加密的 Cookie ，来验证该条 Cookie 是否在传输的过程中被篡改。

　　 httpOnly

　　 服务端 Set-Cookie 字段中新增 httpOnly 属性，当服务端在返回的 Cookie 信息中含有 httpOnly 字段时，开发者是不能通过 JavaScript 来操纵该条 Cookie 字符串的。

　　 这样做的好处主要在于面对 XSS(Cross-site scripting) 攻击时，黑客无法拿到设置 httpOnly 字段的 Cookie 信息。

　　 此时，你会发现 localStorage 相比较 Cookie ，在 XSS 攻击的防御上就略逊一筹了。 sameSite

　　 在介绍这个新属性之前，首先你需要明白：当用户从 http://a.com 发起 http://b.com 的请求也会携带上 Cookie ，而从 http://a.com 携带过来的 Cookie 称为第三方 Cookie 。

　　 虽然第三方 Cookie 有一些好处，但是给 CSRF(Cross-site request forgrey) 攻击的机会。

　　 为了从根源上解决 CSRF 攻击， sameSite 属性便闪亮登场了，它的取值有以下几种：

　　 · strict ：浏览器在任何跨域请求中都不会携带 Cookie ，这样可以有效的防御 CSRF 攻击，但是对于有多个子域名的网站采用主域名存储用户登录信息的场景，每个子域名都需要用户重新登录，造成用户体验非常的差。

　　 · lax ：相比较 strict ，它允许从三方网站跳转过来的时候使用 Cookie 。

　　 为了方便大家理解 sameSite 的实际效果，可以看这个例子：

　　 1. // a.com 服务端会在访问页面时返回如下 Cookie

　　 2. cookies.set('foo', 'aaaaa')

　　 3. cookies.set('bar', 'bbbbb')

　　 4. cookies.set('name', 'cccccc')

　　 5.

　　 6. // b.com 服务端会在访问页面时返回如下 Cookie

　　 7. cookies.set('foo', 'a', { sameSite: 'strict' })

　　 8. cookies.set('bar', 'b', { sameSite: 'lax' })

　　 9. cookies.set('baz', 'c')

　　 如何现在用户在 a.com 中点击链接跳转到 b.com ，它的请求头是这样的：

　　 1. Request Headers

　　 2.

　　 3. Cookie: bar=b; baz=c

　　 五、网站性能优化

　　 Cookie 在服务端和浏览器的通信中，主要依靠 HTTP 的响应头和请求头传输的，所以 Cookie 会占据一定的带宽。

　　 前面提到浏览器会为每一次 HTPP 请求自动携带上 Cookie 信息，但是对于同站内的静态资源，服务器并不需要处理其携带的 Cookie ，这无形中便浪费了带宽。

　　 在最佳实践中，一般都会将静态资源部署到独立的域名上，从而可以避免无效 Cookie 的影响。