浏览器思维导图模板_ProcessOn思维导图、流程图

cookie

.Cookie的来源

Cookie 的本职工作并非本地存储，而是“维持状态”。 因为HTTP协议是无状态的，HTTP协议自身不对请求和响应之间的通信状态进行保存

在 Web 开发的早期，人们亟需解决的一个问题就是状态管理的问题：HTTP 协议是一个无状态协议，服务器接收客户端的请求，返回一个响应，故事到此就结束了，服务器并没有记录下关于客户端的任何信息。那么下次请求的时候，如何让服务器知道“我是我”呢？ 在这样的背景下，Cookie 应运而生。 Cookie 说白了就是一个存储在浏览器里的一个小小的文本文件，它附着在 HTTP 请求上，在浏览器和服务器之间“飞来飞去”。它可以携带用户信息，当服务器检查 Cookie 的时候，便可以获取到客户端的状态。

什么是Cookie

Cookie指某些网站为了辨别用户身份而储存在用户本地终端上的数据(通常经过加密)。  cookie是服务端生成，客户端进行维护和存储

应用场景

<ul><li>记住密码，下次自动登录</li></ul><ul><li>购物车功能</li></ul><ul><li>记录用户浏览数据，进行商品（广告）推荐</li></ul>

原理

当用户第一次访问并登陆一个网站的时候， cookie的设置以及发送会经历以下4个步骤

1、客户端发送一个请求到服务器 2、服务器发送一个HttpResponse响应到客户端，其中包含Set-Cookie的头部  3、客户端保存cookie，之后向服务器发送请求时，HttpRequest请求中会包含一个Cookie的头部 4、服务器返回响应数据

图示

生成方式

生成方式一：http response header中的set-cookie

生成方式二：js中可以通过document.cookie可以读写cookie，以键值对的形式展示

缺陷

Cookie 不够大

当 Cookie 超过 4KB 时，它将面临被裁切的命运

很多浏览器对一个站点的cookie个数也是有限制的

注意

各浏览器的cookie每一个name=value的value值大概在4k， 所以4k并不是一个域名下所有的cookie共享的，而是一个name的大小

过多的 Cookie 会带来巨大的性能浪费

Cookie 是紧跟域名的。同一个域名下的所有请求，都会携带 Cookie。大家试想，如果我们此刻仅仅是请求一张图片或者一个 CSS 文件，我们也要携带一个 Cookie 跑来跑去（关键是 Cookie 里存储的信息并不需要），这是一件多么劳民伤财的事情。Cookie 虽然小，请求却可以有很多，随着请求的叠加，这样的不必要的 Cookie 带来的开销将是无法想象的。 cookie是用来维护用户信息的，而域名(domain)下所有请求都会携带cookie，但对于静态文件的请求，携带cookie信息根本没有用，此时可以通过cdn（存储静态文件的）的域名和主站的域名分开来解决

由于在HTTP请求中的Cookie是明文传递的，所以安全性成问题，除非用HTTPS

安全

HttpOnly

HttpOnly 不支持读写，浏览器不允许脚本操作document.cookie去更改cookie， 所以为避免跨域脚本 (XSS) 攻击，通过JavaScript的 Document.cookie API无法访问带有 HttpOnly 标记的Cookie，它们只应该发送给服务端。如果包含服务端 Session 信息的 Cookie 不想被客户端 JavaScript 脚本调用，那么就应该为其设置 HttpOnly 标记。 Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly

Secure

标记为 Secure 的Cookie只应通过被HTTPS协议加密过的请求发送给服务端。 但即便设置了 Secure 标记，敏感信息也不应该通过Cookie传输，因为Cookie有其固有的不安全性，Secure 标记也无法提供确实的安全保障。

存储

存储方式总结

sessionStorage 、localStorage 和 cookie 之间的区别

共同点：都是保存在浏览器端，且都遵循同源策略。 不同点：在于生命周期与作用域的不同

缓存

协商缓存强缓存

HTTP缓存图示

cache-control

跨域

什么是跨域

广义

跨域是指一个域下的文档或脚本试图去请求另一个域下的资源

狭义

由浏览器同源策略限制的一类请求场景

同源策略

"协议+域名+端口"三者相同

有什么用？

它是浏览器最核心也最基本的安全功能， 如果缺少了同源策略，浏览器很容易受到XSS、CSFR等攻击

解决方案

1. 通过jsonp跨域 2. document.domain + iframe跨域 3. location.hash + iframe 4. window.name + iframe跨域 5. postMessage + iframe 6. 跨域资源共享（CORS） 7. nginx代理跨域 8. nodejs中间件代理跨域 9. WebSocket协议跨域

常用解决方案

jsonp

原理

利用script标签不受跨域限制，向跨域服务接口发送一个带参数的请求； 参数中包括跨域回调函数的名称，服务端返回改函数执行的代码并将请求数据作为参数返回

缺点

1、它只支持GET请求而不支持POST等其它类型的HTTP请求 2、它只支持跨域HTTP请求这种情况，不能解决不同域的两个页面之间如何进行JavaScript调用的问题。 3、 jsonp在调用失败的时候不会返回各种HTTP状态码。 4、缺点是安全性。万一假如提供jsonp的服务存在页面注入漏洞，即它返回的javascript的内容被人控制的。 那么结果是什么？所有调用这个 jsonp的网站都会存在漏洞。

CORS

CORS需要浏览器和服务器同时支持

整个CORS通信过程，都是浏览器自动完成，不需要用户参与。 对于开发者来说，CORS通信与同源的AJAX通信没有差别，代码完全一样。 浏览器一旦发现AJAX请求跨源，就会自动添加一些附加的头信息，有时还会多出一次附加的请求，但用户不会有感觉。 因此，实现CORS通信的关键是服务器。

服务器响应头配置

● Access-Control-Allow-Origin: 'http://a.guazi.com:4000' // 允许请求域 ● Access-Control-Allow-Headers: 'name,Content-Type' // 允许携带请求头 ● Access-Control-Allow-Methods: 'GET,POST,PUT,DELETE,OPTIONS,HEAD' // 允许请求方法 ● Access-Control-Allow-Credentials: true // 允许携带cookie ● Access-Control-Expose-Headers: 'name' // 允许设置的响应头 ● Access-Control-Max-Age: '10' // OPTIONS预校验请求时效单位：秒

普通跨域请求

服务端设置Access-Control-Allow-Origin即可，前端无须设置， 若要带cookie请求：前后端都需要设置

常用头

通用头

请求头

响应头

实体头

状态码

状态码分类

常用状态码

请求方法

表格

HTTP1.0 定义了三种请求方法： GET, POST 和 HEAD方法。 HTTP1.1 新增了六种请求方法：OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。

两种请求

浏览器将CORS请求分成两类：简单请求（simple request）和非简单请求（not-so-simple request）

分类

简单请求

需要满足两大条件

请求方法是以下三种方法之一

HEAD GET POST

HTTP的头信息不超出以下几种字段

Accept Accept-Language Content-Language Last-Event-ID Content-Type：只限于三个值application/x-www-form-urlencoded、                        multipart/form-data、text/plain

复杂请求

凡是不同时满足上面两个条件，就属于非简单请求

get与post请求的区别

使用区别

<ol><li>GET请求参数放在URL上，POST请求参数放在请求体里</li><li>GET请求参数长度有限制，POST请求参数长度可以非常大</li><li>POST请求相较于GET请求安全一点点，因为GET请求的参数在URL上，且有历史记录</li><li>GET请求能缓存，POST不能</li></ol>

本质区别

5. GET和POST最大的区别主要是GET请求是幂等性的，POST请求不是。

由于GET请求是幂等的，在网络不好的环境中，GET请求可能会重复尝试，造成重复操作数据的风险， 因此，GET请求用于无副作用的操作(如搜索)，新增/删除等操作适合用POST

http https