HTTP

说一下 Http 缓存策略，有什么区别，分别解决了什么问题

浏览器缓存策略

浏览器每次发起请求时，先在本地缓存中查找结果以及缓存标识，根据缓存标识来判断是否使用本地缓存。如果缓存有效，则使用本地缓存；否则，则向服务器发起请求并携带缓存标识。根据是否需向服务器发起HTTP请求，将缓存过程划分为两个部分： 强制缓存和协商缓存，强缓优先于协商缓存。

• 强缓存，服务器通知浏览器一个缓存时间，在缓存时间内，下次请求，直接用缓存，不在时间内，执行比较缓存策略。
• 协商缓存，让客户端与服务器之间能实现缓存文件是否更新的验证、提升缓存的复用率，将缓存信息中的Etag和Last-Modified 通过请求发送给服务器，由服务器校验，返回304状态码时，浏览器直接使用缓存。

HTTP缓存都是从第二次请求开始的：

• 第一次请求资源时，服务器返回资源，并在response header中回传资源的缓存策略；

• 第二次请求时，浏览器判断这些请求参数，击中强缓存就直接200，否则就把请求参数加到request header头中传给服务器，看是否击中协商缓存，击中则返回304，否则服务器会返回新的资源。这是缓存运作的一个整体流程图:

  

强缓存

• 强缓存命中则直接读取浏览器本地的资源，在network中显示的是from memory或者from disk
• 控制强制缓存的字段有：Cache-Control（http1.1）和Expires（http1.0）
• Cache-control是一个相对时间，用以表达自上次请求正确的资源之后的多少秒的时间段内缓存有效。
• Expires是一个绝对时间。用以表达在这个时间点之前发起请求可以直接从浏览器中读取数据，而无需发起请求
• Cache-Control的优先级比Expires的优先级高。前者的出现是为了解决Expires在浏览器时间被手动更改导致缓存判断错误的问题。 如果同时存在则使用Cache-control。

强缓存-expires

• 该字段是服务器响应消息头字段，告诉浏览器在过期时间之前可以直接从浏览器缓存中存取数据。
• Expires 是 HTTP 1.0 的字段，表示缓存到期时间，是一个绝对的时间 (当前时间+缓存时间)。在响应消息头中，设置这个字段之后，就可以告诉浏览器，在未过期之前不需要再次请求。
• 由于是绝对时间，用户可能会将客户端本地的时间进行修改，而导致浏览器判断缓存失效，重新请求该资源。此外，即使不考虑修改，时差或者误差等因素也可能造成客户端与服务端的时间不一致，致使缓存失效。
• 优势特点
  • 1、HTTP 1.0 产物，可以在HTTP 1.0和1.1中使用，简单易用。
  • 2、以时刻标识失效时间。
• 劣势问题
  • 1、时间是由服务器发送的(UTC)，如果服务器时间和客户端时间存在不一致，可能会出现问题。
  • 2、存在版本问题，到期之前的修改客户端是不可知的。

强缓存-cache-control

• 已知Expires的缺点之后，在HTTP/1.1中，增加了一个字段Cache-control，该字段表示资源缓存的最大有效时间，在该时间内，客户端不需要向服务器发送请求。
• 这两者的区别就是前者是绝对时间，而后者是相对时间。下面列举一些 Cache-control 字段常用的值：(完整的列表可以查看MDN)
  • max-age：即最大有效时间。
  • must-revalidate：如果超过了 max-age 的时间，浏览器必须向服务器发送请求，验证资源是否还有效。
  • no-cache：不使用强缓存，需要与服务器验证缓存是否新鲜。
  • no-store: 真正意义上的“不要缓存”。所有内容都不走缓存，包括强制和对比。
  • public：所有的内容都可以被缓存 (包括客户端和代理服务器， 如 CDN)
  • private：所有的内容只有客户端才可以缓存，代理服务器不能缓存。默认值。
• Cache-control 的优先级高于 Expires，为了兼容 HTTP/1.0 和 HTTP/1.1，实际项目中两个字段都可以设置。
• 该字段可以在请求头或者响应头设置，可组合使用多种指令：
  • 可缓存性
    • public：浏览器和缓存服务器都可以缓存页面信息
    • private：default，代理服务器不可缓存，只能被单个用户缓存
    • no-cache：浏览器器和服务器都不应该缓存页面信息，但仍可缓存，只是在缓存前需要向服务器确认资源是否被更改。可配合private， 过期时间设置为过去时间。
    • only-if-cache：客户端只接受已缓存的响应
  • 到期
    • max-age=：缓存存储的最大周期，超过这个周期被认为过期。
    • s-maxage=：设置共享缓存，比如can。会覆盖max-age和expires。
    • max-stale[=]：客户端愿意接收一个已经过期的资源
    • min-fresh=：客户端希望在指定的时间内获取最新的响应
    • stale-while-revalidate=：客户端愿意接收陈旧的响应，并且在后台一部检查新的响应。时间代表客户端愿意接收陈旧响应 的时间长度。
    • stale-if-error=：如新的检测失败，客户端则愿意接收陈旧的响应，时间代表等待时间。
  • 重新验证和重新加载
    • must-revalidate：如页面过期，则去服务器进行获取。
    • proxy-revalidate：用于共享缓存。
    • immutable：响应正文不随时间改变。
  • 其他
    • no-store：绝对禁止缓存
    • no-transform：不得对资源进行转换和转变。例如，不得对图像格式进行转换。
• 优势特点
  • 1、HTTP 1.1 产物，以时间间隔标识失效时间，解决了Expires服务器和客户端相对时间的问题。
  • 2、比Expires多了很多选项设置。
• 劣势问题
  • 1、存在版本问题，到期之前的修改客户端是不可知的。

协商缓存

• 协商缓存的状态码由服务器决策返回200或者304
• 当浏览器的强缓存失效的时候或者请求头中设置了不走强缓存，并且在请求头中设置了If-Modified-Since 或者 If-None-Match 的时候，会将这两个属性值到服务端去验证是否命中协商缓存，如果命中了协商缓存，会返回 304 状态，加载浏览器缓存，并且响应头会设置 Last-Modified 或者 ETag 属性。
• 对比缓存在请求数上和没有缓存是一致的，但如果是 304 的话，返回的仅仅是一个状态码而已，并没有实际的文件内容，因此 在响应体体积上的节省是它的优化点。
• 协商缓存有 2 组字段(不是两个)，控制协商缓存的字段有：Last-Modified/If-Modified-since（http1.0）和Etag/If-None-match（http1.1）
• Last-Modified/If-Modified-since表示的是服务器的资源最后一次修改的时间；Etag/If-None-match表示的是服务器资源的唯一标 识，只要资源变化，Etag就会重新生成。
• Etag/If-None-match的优先级比Last-Modified/If-Modified-since高。

协商缓存-协商缓存-Last-Modified/If-Modified-since

• 1.服务器通过 Last-Modified 字段告知客户端，资源最后一次被修改的时间，例如 Last-Modified: Mon, 10 Nov 2018 09:10:11 GMT
• 2.浏览器将这个值和内容一起记录在缓存数据库中。
• 3.下一次请求相同资源时时，浏览器从自己的缓存中找出“不确定是否过期的”缓存。因此在请求头中将上次的 Last-Modified 的值写入到请求头的 If-Modified-Since 字段
• 4.服务器会将 If-Modified-Since 的值与 Last-Modified 字段进行对比。如果相等，则表示未修改，响应 304；反之，则表示修改了，响应 200 状态码，并返回数据。
• 优势特点
  • 1、不存在版本问题，每次请求都会去服务器进行校验。服务器对比最后修改时间如果相同则返回304，不同返回200以及资源内容。
• 劣势问题
  • 2、只要资源修改，无论内容是否发生实质性的变化，都会将该资源返回客户端。例如周期性重写，这种情况下该资源包含的数据实际上一样的。
  • 3、以时刻作为标识，无法识别一秒内进行多次修改的情况。 如果资源更新的速度是秒以下单位，那么该缓存是不能被使用的，因为它的时间单位最低是秒。
  • 4、某些服务器不能精确的得到文件的最后修改时间。
  • 5、如果文件是通过服务器动态生成的，那么该方法的更新时间永远是生成的时间，尽管文件可能没有变化，所以起不到缓存的作用。

协商缓存-Etag/If-None-match

• 为了解决上述问题，出现了一组新的字段 Etag 和 If-None-Match
• Etag 存储的是文件的特殊标识(一般都是 hash 生成的)，服务器存储着文件的 Etag 字段。之后的流程和 Last-Modified 一致，只是 Last-Modified 字段和它所表示的更新时间改变成了 Etag 字段和它所表示的文件 hash，把 If-Modified-Since 变成了 If-None-Match。服务器同样进行比较，命中返回 304, 不命中返回新资源和 200。
• 浏览器在发起请求时，服务器返回在Response header中返回请求资源的唯一标识。在下一次请求时，会将上一次返回的Etag值赋值给If-No-Matched并添加在Request Header中。服务器将浏览器传来的if-no-matched跟自己的本地的资源的ETag做对比，如果匹配，则返回304通知浏览器读取本地缓存，否则返回200和更新后的资源。
• Etag 的优先级高于 Last-Modified。
• 优势特点
  • 1、可以更加精确的判断资源是否被修改，可以识别一秒内多次修改的情况。
  • 2、不存在版本问题，每次请求都回去服务器进行校验。
• 劣势问题
  • 1、计算ETag值需要性能损耗。
  • 2、分布式服务器存储的情况下，计算ETag的算法如果不一样，会导致浏览器从一台服务器上获得页面内容后到另外一台服务器上进行验证时现ETag不匹配的情况。

前端安全，中间人安全

XSS：跨站脚本攻击

就是攻击者想尽一切办法将可以执行的代码注入到网页中。

存储型（server端）：

• 场景：见于带有用户保存数据的网站功能，如论坛发帖、商品评论、用户私信等。
• 攻击步骤：
  • i）攻击者将恶意代码提交到目标网站的数据库中
  • ii）用户打开目标网站时，服务端将恶意代码从数据库中取出来，拼接在HTML中返回给浏览器
  • iii）用户浏览器在收到响应后解析执行，混在其中的恶意代码也同时被执行
  • iv）恶意代码窃取用户数据，并发送到指定攻击者的网站，或者冒充用户行为，调用目标网站的接口，执行恶意操作

反射型（Server端）

与存储型的区别在于，存储型的恶意代码存储在数据库中，反射型的恶意代码在URL上

• 场景：通过 URL 传递参数的功能，如网站搜索、跳转等。
• 攻击步骤：
  • i）攻击者构造出特殊的 URL，其中包含恶意代码。
  • ii）用户打开带有恶意代码的 URL 时，网站服务端将恶意代码从 URL 中取出，拼接在 HTML 中返回给浏览器。
  • iii）用户浏览器接收到响应后解析执行，混在其中的恶意代码也被执行。
  • iv）恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。

Dom 型(浏览器端）

DOM 型 XSS 攻击中，取出和执行恶意代码由浏览器端完成，属于前端 JavaScript 自身的安全漏洞，而其他两种 XSS 都属于服务端的安全漏洞。

• 场景：通过 URL 传递参数的功能，如网站搜索、跳转等。
• 攻击步骤：
  • i）攻击者构造出特殊的 URL，其中包含恶意代码。
  • ii）用户打开带有恶意代码的 URL。
  • iii）用户浏览器接收到响应后解析执行，前端 JavaScript 取出 URL 中的恶意代码并执行。
  • iv）恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。

预防方案：（防止攻击者提交恶意代码，防止浏览器执行恶意代码）

• i）对数据进行严格的输出编码：如HTML元素的编码，JS编码，CSS编码，URL编码等等
  • 避免拼接 HTML；Vue/React 技术栈，避免使用 v-html / dangerouslySetInnerHTML
• ii）CSP HTTP Header，即 Content-Security-Policy、X-XSS-Protection
  • 增加攻击难度，配置CSP(本质是建立白名单，由浏览器进行拦截)
  • Content-Security-Policy: default-src 'self'-所有内容均来自站点的同一个源（不包括其子域名）
  • Content-Security-Policy: default-src 'self' *.trusted.com-允许内容来自信任的域名及其子域名 (域名不必须与CSP设置所在的域名相同)
  • Content-Security-Policy: default-src https://yideng.com-该服务器仅允许通过HTTPS方式并仅从yideng.com域名来访问文档
• iii）输入验证：比如一些常见的数字、URL、电话号码、邮箱地址等等做校验判断
• iv）开启浏览器XSS防御：Http Only cookie，禁止 JavaScript 读取某些敏感 Cookie，攻击者完成 XSS 注入后也无法窃取此 Cookie。
• v）验证码

CSRF：跨站请求伪造

攻击者诱导受害者进入第三方网站，在第三方网站中，向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获取的注册凭证，绕过后台的用户验证，达到冒充用户对被攻击的网站执行某项操作的目的。

攻击流程举例

• i）受害者登录 a.com，并保留了登录凭证（Cookie）
• ii）攻击者引诱受害者访问了b.com
• iii）b.com 向 a.com 发送了一个请求：a.com/act=xx浏览器会默认携带a.com的Cookie
• iv）a.com接收到请求后，对请求进行验证，并确认是受害者的凭证，误以为是受害者自己发送的请求
• v）a.com以受害者的名义执行了act=xx
• vi）攻击完成，攻击者在受害者不知情的情况下，冒充受害者，让a.com执行了自己定义的操作

攻击类型

• i）GET型：如在页面的某个 img 中发起一个 get 请求
• ii）POST型：通过自动提交表单到恶意网站
• iii）链接型：需要诱导用户点击链接

预防方案：

CSRF通常从第三方网站发起，被攻击的网站无法防止攻击发生，只能通过增强自己网站针对CSRF的防护能力来提升安全性。）

• i）同源检测：通过Header中的Origin Header 、Referer Header 确定，但不同浏览器可能会有不一样的实现，不能完全保证
• ii）CSRF Token 校验：将CSRF Token输出到页面中（通常保存在Session中），页面提交的请求携带这个Token，服务器验证Token是否 正确
• iii）双重cookie验证：
  • 流程：
    • 步骤1：在用户访问网站页面时，向请求域名注入一个Cookie，内容为随机字符串（例如csrfcookie=v8g9e4ksfhw）
    • 步骤2：在前端向后端发起请求时，取出Cookie，并添加到URL的参数中（接上例POST https://www.a.com/comment?csrfcookie=v8g9e4ksfhw）
    • 步骤3：后端接口验证Cookie中的字段与URL参数中的字段是否一致，不一致则拒绝。
  • 优点：
    • 无需使用Session，适用面更广，易于实施。
    • Token储存于客户端中，不会给服务器带来压力。
    • 相对于Token，实施成本更低，可以在前后端统一拦截校验，而不需要一个个接口和页面添加。
  • 缺点： -Cookie中增加了额外的字段。 -如果有其他漏洞（例如XSS），攻击者可以注入Cookie，那么该防御方式失效。 -难以做到子域名的隔离。 -为了确保Cookie传输安全，采用这种防御方式的最好确保用整站HTTPS的方式，如果还没切HTTPS的使用这种方式也会有风险。
• iv）Samesite Cookie属性：Google起草了一份草案来改进HTTP协议，那就是为Set-Cookie响应头新增Samesite属性，它用来标明这个 Cookie是个“同站 Cookie”，同站Cookie只能作为第一方Cookie，不能作为第三方Cookie，Samesite 有两个属性值，Strict 为任何情况下都不可以作为第三方 Cookie ，Lax 为可以作为第三方 Cookie , 但必须是Get请求

iframe 安全

说明：

• i）嵌入第三方 iframe 会有很多不可控的问题，同时当第三方 iframe 出现问题或是被劫持之后，也会诱发安全性问题
• ii）点击劫持
  • 攻击者将目标网站通过 iframe 嵌套的方式嵌入自己的网页中，并将 iframe 设置为透明，诱导用户点击。
• iii）禁止自己的 iframe 中的链接外部网站的JS

预防方案：

• i）为 iframe 设置 sandbox 属性，通过它可以对iframe的行为进行各种限制，充分实现“最小权限“原则
• ii）服务端设置 X-Frame-Options Header头，拒绝页面被嵌套，X-Frame-Options 是HTTP 响应头中用来告诉浏览器一个页面是否可以嵌入 iframe 中
  • eg.X-Frame-Options: SAMEORIGIN
  • SAMEORIGIN: iframe 页面的地址只能为同源域名下的页面
  • ALLOW-FROM: 可以嵌套在指定来源的 iframe 里
  • DENY: 当前页面不能被嵌套在 iframe 里
• iii）设置 CSP 即 Content-Security-Policy 请求头
• iv）减少对 iframe 的使用

错误的内容推断

说明：

文件上传类型校验失败后，导致恶意的JS文件上传后，浏览器 Content-Type Header 的默认解析为可执行的 JS 文件

预防方案：

设置 X-Content-Type-Options 头

第三方依赖包

减少对第三方依赖包的使用，如之前 npm 的包如：event-stream 被爆出恶意攻击数字货币；

HTTPS

描述：

黑客可以利用SSL Stripping这种攻击手段，强制让HTTPS降级回HTTP，从而继续进行中间人攻击。

预防方案：

使用HSTS（HTTP Strict Transport Security），它通过下面这个HTTP Header以及一个预加载的清单，来告知浏览器和网站进行通信的时候强制性的使用HTTPS，而不是通过明文的HTTP进行通信。这里的“强制性”表现为浏览器无论在何种情况下都直接向务器端发起HTTPS请求，而不再像以往那样从HTTP跳转到HTTPS。另外，当遇到证书或者链接不安全的时候，则首先警告用户，并且不再 用户选择是否继续进行不安全的通信。

本地存储数据

避免重要的用户信息存在浏览器缓存中

静态资源完整性校验

描述

使用 内容分发网络 (CDNs) 在多个站点之间共享脚本和样式表等文件可以提高站点性能并节省带宽。然而，使用CDN也存在风险，如果攻击者获得对 CDN 的控制权，则可以将任意恶意内容注入到 CDN 上的文件中 （或完全替换掉文件），因此可能潜在地攻击所有从该 CDN 获取文件的站点。

预防方案

将使用 base64 编码过后的文件哈希值写入你所引用的 <script> 或 标签的 integrity 属性值中即可启用子资源完整性能。

网络劫持

描述：

• DNS劫持（涉嫌违法）：修改运行商的 DNS 记录，重定向到其他网站。DNS 劫持是违法的行为，目前 DNS 劫持已被监管，现在很少见 DNS 劫持
• HTTP劫持：前提有 HTTP 请求。因 HTTP 是明文传输，运营商便可借机修改 HTTP 响应内容（如加广告）。

预防方案

全站 HTTPS

中间人攻击：

中间人攻击（Man-in-the-middle attack, MITM），指攻击者与通讯的两端分别创建独立的联系，并交换其所收到的数据，使通讯的两端认为他们正在通过一个私密的连接与对方直接对话，但事实上整个会话都被攻击者窃听、篡改甚至完全控制。没有进行严格的证书校验是中间人攻击着手点。目前大多数加密协议都提供了一些特殊认证方法以阻止中间人攻击。如 SSL （安全套接字层）协议可以验证参与通讯的用户的证书是否有权威、受信任的数字证书认证机构颁发，并且能执行双向身份认证。攻击场景如用户在一个未加密的 WiFi下访问网站。在中间人攻击中，攻击者可以拦截通讯双方的通话并插入新的内容。

场景

• i）在一个未加密的Wi-Fi 无线接入点的接受范围内的中间人攻击者，可以将自己作为一个中间人插入这个网络
• ii）Fiddler / Charles （花瓶）代理工具
• iii）12306 之前的自己证书

过程

• i）客户端发送请求到服务端，请求被中间人截获
• ii）服务器向客户端发送公钥
• iii）中间人截获公钥，保留在自己手上。然后自己生成一个【伪造的】公钥，发给客户端
• iv）客户端收到伪造的公钥后，生成加密hash值发给服务器
• v）中间人获得加密hash值，用自己的私钥解密获得真秘钥,同时生成假的加密hash值，发给服务器
• vi）服务器用私钥解密获得假密钥,然后加密数据传输给客户端

使用抓包工具fiddle来进行举例说明

• 1. 首先通过一些途径在客户端安装证书
• 1. 然后客户端发送连接请求，fiddle在中间截取请求，并返回自己伪造的证书
• 1. 客户端已经安装了攻击者的根证书，所以验证通过
• 1. 客户端就会正常和fiddle进行通信，把fiddle当作正确的服务器
• 1. 同时fiddle会跟原有的服务器进行通信，获取数据以及加密的密钥，去解密密钥

常见攻击方式

• 1. 嗅探：嗅探是一种用来捕获流进和流出的网络数据包的技术，就好像是监听电话一样。比如：抓包工具
• 1. 数据包注入：在这种，攻击者会将恶意数据包注入到常规数据中的，因为这些恶意数据包是在正常的数据包里面的，用户和系统都很难发现这个内容。
• 1. 会话劫持：当我们进行一个网站的登录的时候到退出登录这个时候，会产生一个会话，这个会话是攻击者用来攻击的首要目标，因为这个会话，包含了用户大量的数据和私密信息。
• 1. SSL剥离：HTTPS是通过SSL/TLS进行加密过的，在SSL剥离攻击中，会使SSL/TLS连接断开，让受保护的HTTPS，变成不受 保护的HTTP（这对于网站非常致命）
• 1. DNS欺骗，攻击者往往通过入侵到DNS服务器，或者篡改用户本地hosts文件，然后去劫持用户发送的请求，然后转发到攻击者想要转发到的服务器
• 1. ARP欺骗，ARP(address resolution protocol)地址解析协议，攻击者利用APR的漏洞，用当前局域网之间的一台服务器，来冒充客户端想要请求的服务端，向客户端发送自己的MAC地址，客户端无从得到真正的主机的MAC地址，所以，他会把这个地址当作真正 的主机来进行通信，将MAC存入ARP缓存表。
• 1. 代理服务器

预防方案：

• i）用可信的第三方CA厂商
• ii）不下载未知来源的证书，不要去下载一些不安全的文件
• iii）确认你访问的URL是HTTPS的，确保网站使用了SSL，确保禁用一些不安全的SSL，只开启：TLS1.1，TLS1.2
• iv）不要使用公用网络发送一些敏感的信息
• v）不要去点击一些不安全的连接或者恶意链接或邮件信息

sql 注入

描述

就是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串，最终达到欺骗数据库服务器执行恶意的SQL命令,从而达到和服务器 进行直接的交互

预防方案：

• i）后台进行输入验证，对敏感字符过滤。
• ii）使用参数化查询，能避免拼接SQL，就不要拼接SQL语句。

前端数据安全：

描述

反爬虫。如猫眼电影、天眼查等等，以数据内容为核心资产的企业

预防方案

• i）font-face拼接方式：猫眼电影、天眼查
• ii）background 拼接：美团
• iii）伪元素隐藏：汽车之家
• iv）元素定位覆盖式：去哪儿
• v）iframe 异步加载：网易云音乐

其他建议

• i）定期请第三方机构做安全性测试，漏洞扫描
• ii）使用第三方开源库做上线前的安全测试，可以考虑融合到CI中
• iii）code review 保证代码质量
• iv）默认项目中设置对应的 Header 请求头，如 X-XSS-Protection、 X-Content-Type-Options 、X-Frame-Options Header、Content-Security-Policy 等等
• v）对第三方包和库做检测：NSP(Node Security Platform)，Snyk

图解前端安全

Options请求

为什么发生两次请求

http请求发生了两次（options请求） (opens new window)

http的请求方式，包括OPTIONS、GET、HEAD、POST、PUT、DELETE、TRACE和CONNECT等八种请求方式。其中，get与post只是我们常用的请求方式。

我们能在图一里看到，第一条的请求方式为options，第二条请求，才是我们预想中的请求。所以为什么发生两条请求的原因就变成了为什么发生options请求。

options请求

options请求的官方定义：OPTIONS方法是用于请求获得由Request-URI标识的资源在请求/响应的通信过程中可以使用的功能选项。通过这个方法，客户端可以在采取具体资源请求之前，决定对该资源采取何种必要措施，或者了解服务器的性能。

用白话说就是：在发生正式的请求之前，先进行一次预检请求。看服务端返回一些信息，浏览器拿到之后，看后台是否允许进行访问。

如何产生options请求

产生options请求的原因包括以下几条：

1：产生了复杂请求。复杂请求对应的就是简单请求。简单请求的定义是：

1. 请求方法是GET、HEAD或者POST，并且当请求方法是POST时，Content-Type必须是application/x-www-form-urlencoded, multipart/form-data或着text/plain中的一个值。
2. 请求中没有自定义HTTP头部。

所谓的自定义头部，在实际的项目里，我们经常会遇到需要在header头部加上一些token或者其他的用户信息，用来做用户信息的校验。

2：发生了跨域。

options请求有什么作用

官方将头部带自定义信息的请求方式称为带预检（preflighted）的跨域请求。在实际调用接口之前，会首先发出一个options请求，检测服务端是否支持真实的请求进行跨域的请求。真实请求在options请求中，通过request-header将 Access-Control-Request-Headers与Access-Control-Request-Method发送给后台，另外浏览器会自行加上一个Origin请求地址。服务端在接收到预检请求后，根据资源权限配置，在response-header头部加入access-control-allow-headers（允许跨域请求的请求头）、access-control-allow-methods（允许跨域请求的请求方式）、access-control-allow-origin（允许跨域请求的域）。另外，服务端还可以通过Access-Control-Max-Age来设置一定时间内无须再进行预检请求，直接用之前的预检请求的协商结果即可。浏览器再根据服务端返回的信息，进行决定是否再进行真实的跨域请求。这个过程对于用户来说，也是透明的。

另外在HTTP响应头，凡是浏览器请求中携带了身份信息，而响应头中没有返回Access-Control-Allow-Credentials: true的，浏览器都会忽略此次响应。

总结：只要是带自定义header的跨域请求，在发送真实请求前都会先发送OPTIONS请求，浏览器根据OPTIONS请求返回的结果来决定是否继续发送真实的请求进行跨域资源访问。所以复杂请求肯定会两次请求服务端。

options请求如何避免

其实通过以上的分析，我们能得出以下解决方案：

1：使用代理，避开跨域。

2：将复杂跨域请求更改为简单跨域请求。

3：不使用带自定义配置的header头部。

Cookie的作用是什么?和Session有什么区别？

Cookie 和 Session都是用来跟踪浏览器用户身份的会话方式，但是两者的应用场景不太一样。

Cookie 一般用来保存用户信息

比如

①我们在 Cookie 中保存已经登录过得用户信息，下次访问网站的时候页面可以自动帮你登录的一些基本信息给填了；

②一般的网站都会有保持登录也就是说下次你再访问网站的时候就不需要重新登录了，这是因为用户登录的时候我们可以存放了一个 Token 在 Cookie 中，下次登录的时候只需要根据 Token 值来查找用户即可(为了安全考虑，重新登录一般要将 Token 重写)；

③登录一次网站后访问网站其他页面不需要重新登录。

Session 的主要作用就是通过服务端记录用户的状态。

典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了。

Cookie 数据保存在客户端(浏览器端)，Session 数据保存在服务器端。

Cookie 存储在客户端中，而Session存储在服务器上，相对来说 Session 安全性更高。如果要在 Cookie 中存储一些敏感信息，不要直接写入 Cookie 中，最好能将 Cookie 信息加密然后使用到的时候再去服务器端解密。

TCP 三次握手和四次挥手

如下图所示，下面的两个机器人通过3次握手确定了对方能正确接收和发送消息(图片来源：《图解HTTP》)。

简单示意图

• 客户端–发送带有 SYN 标志的数据包–一次握手–服务端
• 服务端–发送带有 SYN/ACK 标志的数据包–二次握手–客户端
• 客户端–发送带有带有 ACK 标志的数据包–三次握手–服务端

为什么要三次握手

三次握手的目的是建立可靠的通信信道，说到通讯，简单来说就是数据的发送与接收，而三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。

第一次握手：Client 什么都不能确认；Server 确认了对方发送正常，自己接收正常

第二次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：对方发送正常，自己接收正常

第三次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：自己发送、接收正常，对方发送、接收正常

所以三次握手就能确认双发收发功能都正常，缺一不可。

第2次握手传回了ACK，为什么还要传回SYN？

接收端传回发送端所发送的ACK是为了告诉客户端，我接收到的信息确实就是你所发送的信号了，这表明从客户端到服务端的通信是正常的。而回传SYN则是为了建立并确认从服务端到客户端的通信。

SYN 同步序列编号(Synchronize Sequence Numbers) 是 TCP/IP 建立连接时使用的握手信号。在客户机和服务器之间建立正常的 TCP 网络连接时，客户机首先发出一个 SYN 消息，服务器使用 SYN-ACK 应答表示接收到了这个消息，最后客户机再以 ACK(Acknowledgement）消息响应。这样在客户机和服务器之间才能建立起可靠的 TCP 连接，数据才可以在客户机和服务器之间传递。

为什么要四次挥手

断开一个 TCP 连接则需要“四次挥手”：

• 客户端-发送一个 FIN，用来关闭客户端到服务器的数据传送
• 服务器-收到这个 FIN，它发回一 个 ACK，确认序号为收到的序号加1 。和 SYN 一样，一个 FIN 将占用一个序号
• 服务器-关闭与客户端的连接，发送一个FIN给客户端
• 客户端-发回 ACK 报文确认，并将确认序号设置为收到序号加1

任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候，则发出连接释放通知，对方确认后就完全关闭了TCP连接。

举个例子：A 和 B 打电话，通话即将结束后，A 说“我没啥要说的了”，B回答“我知道了”，但是 B 可能还会有要说的话，A 不能要求 B 跟着自己的节奏结束通话，于是 B 可能又巴拉巴拉说了一通，最后 B 说“我说完了”，A 回答“知道了”，这样通话才算结束。

上面讲的比较概括，推荐一篇讲的比较细致的文章：https://blog.csdn.net/qzcsu/article/details/72861891

HTTPS

Client发起一个HTTPS（https:/demo.linianhui.dev）的请求，根据RFC2818的规定，Client知道需要连接Server的443（默认）端口。 Server把事先配置好的公钥证书（public key certificate）返回给客户端。 Client验证公钥证书：比如是否在有效期内，证书的用途是不是匹配Client请求的站点，是不是在CRL吊销列表里面，它的上一级证书是否有效，这是一个递归的过程，直到验证到根证书（操作系统内置的Root证书或者Client内置的Root证书）。如果验证通过则继续，不通过则显示警告信息。 Client使用伪随机数生成器生成加密所使用的会话密钥，然后用证书的公钥加密这个会话密钥，发给Server。 Server使用自己的私钥（private key）解密这个消息，得到会话密钥。至此，Client和Server双方都持有了相同的会话密钥。 Server使用会话密钥加密“明文内容A”，发送给Client。 Client使用会话密钥解密响应的密文，得到“明文内容A”。 Client再次发起HTTPS的请求，使用会话密钥加密请求的“明文内容B”，然后Server使用会话密钥解密密文，得到“明文内容B”。 简单总结下，HTTPS是使用了证书的一个混合密码系统，其中证书的作用在于传递会话密钥，以及验证网站的真实性；而HTTPS真正的加密操作是由对称密码这个工具负责的。

HTTP 状态码

服务器返回的 响应报文 中第一行为状态行，包含了状态码以及原因短语，用来告知客户端请求的结果。

状态码	类别	含义
1XX	Informational（信息性状态码）	接收的请求正在处理
2XX	Success（成功状态码）	请求正常处理完毕
3XX	Redirection（重定向状态码）	需要进行附加操作以完成请求
4XX	Client Error（客户端错误状态码）	服务器无法处理请求
5XX	Server Error（服务器错误状态码）	服务器处理请求出错

1XX 信息

• 100 Continue ：表明到目前为止都很正常，客户端可以继续发送请求或者忽略这个响应。

2XX 成功

• 200 OK
• 204 No Content ：请求已经成功处理，但是返回的响应报文不包含实体的主体部分。一般在只需要从客户端往服务器发送信息，而不需要返回数据时使用。
• 206 Partial Content ：表示客户端进行了范围请求，响应报文包含由 Content-Range 指定范围的实体内容。

3XX 重定向

• 301 Moved Permanently ：永久性重定向
• 302 Found ：临时性重定向
• 303 See Other ：和 302 有着相同的功能，但是 303 明确要求客户端应该采用 GET 方法获取资源。
• 注：虽然 HTTP 协议规定 301、302 状态下重定向时不允许把 POST 方法改成 GET 方法，但是大多数浏览器都会在 301、302 和 303 状态下的重定向把 POST 方法改成 GET 方法。
• 304 Not Modified ：如果请求报文首部包含一些条件，例如：If-Match，If-Modified-Since，If-None-Match，If-Range，If-Unmodified-Since，如果不满足条件，则服务器会返回 304 状态码。
• 307 Temporary Redirect ：临时重定向，与 302 的含义类似，但是 307 要求浏览器不会把重定向请求的 POST 方法改成 GET 方法。

4XX 客户端错误

• 400 Bad Request ：请求报文中存在语法错误。
• 401 Unauthorized ：该状态码表示发送的请求需要有认证信息（BASIC 认证、DIGEST 认证）。如果之前已进行过一次请求，则表示用户认证失败。
• 403 Forbidden ：请求被拒绝。
• 404 Not Found

5XX 服务器错误

• 500 Internal Server Error ：服务器正在执行请求时发生错误。
• 503 Service Unavailable ：服务器暂时处于超负载或正在进行停机维护，现在无法处理请求