HTTP网络状态码

1.TCP/IP的三次握手和四次挥手

三次握手:

第一次握手：客户端向服务端发送SYN码数据包，表示客户端要求和服务端建立连接；

第二次握手：服务端收到客户端的连接请求后，会发送ACK数据包给客户端，表示你的连接 请求已经收到，询问客户端是否真的需要建立连接；

第三次握手：客户端收到ACK码以后会检验是否正确，如果正确，客户端会再次发送ACK码给 服务端，表示确认建立连接；
(三次握手都成功以后才会建立连接，然后才会发送数据；)

四次挥手：

第一次挥手：当客户端发送数据结束后，会发送FIN码数据包给服务端，表示告知服务端客 户端的数据已经传递完了。

第二次挥手：当服务端收到FIN后，会发送ACK给客户端，表示服务端已经知道客户端传完
了。客户端收到ACK以后就会把传递数据给服务端的通道关闭；

第三次挥手：当服务端把响应的数据发送完毕后，会发送一个FIN给客户端，告知客户端响 应的数据已经发送完毕；

第四次挥手：当客户端收到FIN后，会发送一个ACK码数据包给服务端，告知服务端客户端已
经知道数据发送完毕；服务端收到ACK码后，可以安心的把数据传递通道关闭掉。

2.http常用状态码(http-status-code):

2xx:表示成功

• 200 OK 表示所有东西都正常

• 204 表示请求成功,但是服务端没有内容给你

3xx: 表示重定向

• 301，Moved Permanently。永久重定向(当访问一个永久重定向的网站的时候,一个域名被指向一个其他网站,且是永久的)，该操作比较危险，需要谨慎操作：如果设置了301，但是一段时间后又想取消，但是浏览器中已经有了缓存，还是会重定向。
• 302，Fount。临时重定向，但是会在重定向的时候改变 method: 把 POST 改成 GET，于是有了 307
• 304 走缓存(服务端觉得你之前请求过这个东西,而且服务器上的那一份没有发生变化,告诉客户端用缓存 就行)
• 307，Temporary Redirect。临时重定向，在重定向时不会改变 method

4xx: 表示客户端错误

• 400 参数传递不当,导致的错误

• 401 权限不够导致的

• 403 服务端已经理解请求,但是拒绝响应

• 404 客户端请求的资源或者数据不存在(发现请求接口404,有两种情况一种是咱们写错接口了或者服 务端还没部署)

5xx: 表示服务端错误(遇到以5开头的错误去找服务端错误)

• 500 服务端内部错误

• 502 网关错误

3.从浏览器输入URL按回车到页面显示都发生了什么?

1. 浏览器根据URL进行DNS查询

• 首先从DNS缓存中查询
• 若未在缓存中找到，则不停的向上一级级请求DNS服务器

2. 取得IP地址，建立TCP连接
3. 构造HTTP请求报

• 添加一些HTTP首部
• 根据同源政策添加cookie

4. 在TCP连接上发送HTTP报文，等待响应
5. 服务器处理HTTP请求报文，返回响应HTTP响应报文
6. 浏览器处理服务器返回的HTTP响应报文，若为HTML则渲染页面，不包括脚本的简单渲染流程如下

• 解析DOM、CSSOM
• 根据DOM、CSSOM计算render tree
• 根据render tree进行layout
• paint，至此，用户可以看到页面了

4.HTTPS和HTTP的区别主要如下?

HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全。

1、https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。

2、http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。

3、http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。

4、http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。

https主要解决三个安全问题：

• 内容隐私
• 防篡改
• 确认对方身份
  https并不是直接通过非对称加密传输过程，而是有握手过程，握手过程主要是和服务器做通讯，生成私有秘钥，最后通过该秘钥对称加密传输数据。还有验证证书的正确性。证书验证过程保证了对方是合法的，并且中间人无法通过伪造证书方式进行攻击。

5.浏览器缓存？

• 强缓存：不会向服务器发送请求，直接从缓存中读取资源，在chrome控制台的Network选项中可以看到该请求返回200的状态码，并且Size显示from
  disk cache或from memory cache。强缓存可以通过设置两种 HTTP Header 实现：Expires 和
  Cache-Control。

• 协商缓存：就是强制缓存失效后，浏览器携带缓存标识向服务器发起请求，由服务器根据缓存标识决定是否使用缓存的过程，主要有以下两种情况：

• 协商缓存生效，返回304和Not Modified

• 协商缓存失效，返回200和请求结果协商缓存可以通过设置两种 HTTP Header 实现：Last-Modified 和 ETag 。

强制缓存优先于协商缓存进行，若强制缓存(Expires和Cache-Control)生效则直接使用缓存，若不生效则进行协商缓存(Last-Modified / If-Modified-Since和Etag / If-None-Match)，协商缓存由服务器决定是否使用缓存，若协商缓存失效，那么代表该请求的缓存失效，返回200，重新返回资源和缓存标识，再存入浏览器缓存中；生效则返回304，继续使用缓存。

6.ajax四步

1. 创建 XMLHttpRequest 对象,也就是创建一个异步调用对象

2. 创建一个新的 HTTP 请求,并指定该 HTTP 请求的方法、URL 及验证信息

3. 设置响应 HTTP 请求状态变化的函数

4. 发送 HTTP 请求

你使用过哪些ajax?

• 从原生的XHR到jquery ajax，再到现在的axios和fetch。

• axios和fetch都是基于Promise的，一般我们在使用时都会进行二次封装

• 讲到fetch跟jquery ajax的区别，这也是它很奇怪的地方

• 当接收到一个代表错误的 HTTP 状态码时，从 fetch()返回的 Promise 不会被标记为 reject， 即使该 HTTP
  响应的状态码是 404 或 500。相反，它会将 Promise 状态标记为 resolve （但是会将 resolve 的返回值的 ok
  属性设置为 false ）， 仅当网络故障时或请求被阻止时，才会标记为 reject。 默认情况下, fetch 不会从服务端发送或接收任何cookies, 如果站点依赖于用户 session，则会导致未经认证的请求（要发送 cookies，必须设置 credentials选项）

一般我们再拦截器中都会写什么代码？

请求拦截中我们一半会把token写在这里，这样的话就不用每次请求都要写这个参数

还会做一个数据格式的处理，假如某个参数需要统一处理 可以放在这里，

响应拦截一半会做一个判断 请求失败的话直接调用失败提示框 这样不用每个接口都写同样的代码

也会再return时 return reponse.data;这样就可以不用每个数据接受的时候都加一个data.data

get请求和post请求有什么区别？什么时候使用post?

• GET：一般用于信息获取，使用 URL 传递参数，对所发送信息的数量也有限制，一般在 2000 个字符

• POST：一般用于修改服务器上的资源，对所发送的信息没有限制

• 在以下情况中，请使用 POST 请求：

1. 无法使用缓存文件（更新服务器上的文件或数据库）
2. 向服务器发送大量数据（POST 没有数据量限制）
3. 发送包含未知字符的用户输入时，POST 比 GET 更稳定也更可靠

• 实际上HTTP 协议从未规定 GET/POST的请求长度限制是多少。对get请求参数的限制是来源与浏览器或web服务器，浏览器或web服务器限制了url的长度。为了明确这个概念，我们必须再次强调下面几点:
  1、HTTP 协议 未规定 GET 和POST的长度限制
  2、GET的最大长度显示是因为 浏览器和 web服务器限制了 URI的长度
  3、不同的浏览器和WEB服务器，限制的最大长度不一样
  4、要支持IE，则最大长度为2083byte，若只支持Chrome，则最大长度 8182byte

Cookie 和 Session 的区别?

• 安全性： Session 比 Cookie 安全，Session 是存储在服务器端的，Cookie 是存储在客户端的。
• 存取值的类型不同：Cookie 只支持存字符串数据，想要设置其他类型的数据，需要将其转换成字符串，Session 可以存任意数据类型。
• 有效期不同： Cookie 可设置为长时间保持，比如我们经常使用的默认登录功能，Session 一般失效时间较短，客户端关闭（默认情况下）或者 Session 超时都会失效。
• 存储大小不同： 单个 Cookie 保存的数据不能超过 4K，Session 可存储数据远高于 Cookie，但是当访问量过多，会占用过多的服务器资源。

Token 相关？

1. 客户端使用用户名跟密码请求登录
2. 服务端收到请求，去验证用户名与密码
3. 验证成功后，服务端会签发一个 token 并把这个 token发送给客户端
4. 客户端收到 token 以后，会把它存储起来，比如放在 cookie 里或者 localStorage 里
5. 客户端每次向服务端请求资源的时候需要带着服务端签发的 token
6. 服务端收到请求，然后去验证客户端请求里面带着的 token，如果验证成功，就向客户端返回请求的数据

• 每一次请求都需要携带 token，需要把 token 放到 HTTP 的 Header 里
• 基于 token 的用户认证是一种服务端无状态的认证方式，服务端不用存放 token 数据。用解析 token 的计算时间换取 session 的存储空间，从而减轻服务器的压力，减少频繁的查询数据库
• token 完全由应用管理，所以它可以避开同源策略