http常见状态码有哪些？

• 状态码分类
  1xx 服务器接受到请求
  2xx 请求成功 例如：200
  3xx 重定向 例如：302临时重定向
  4xx 客户端错误 例如：404
  5xx 服务端错误 例如：500
• 常见状态码
  200：请求成功
  301：永久重定向（配合location响应头，使浏览器自动跳转）如果浏览器接受到301码那么它会记住这个新URL，以后再有一样请求时候它就会自动去新URL上进行请求
  302：临时重定向（配合location请求头，使浏览器自动跳转）如果浏览器接受到302码那么它不会记住新的URL，下次请求还是会请求原来的URL，因为浏览器也不知道请求地址是否已经换回来了，所以它只能不厌其烦的请求老URL。
  304：资源未被修改（这个配合着后边的（协商缓存）来看效果更佳）
  404：资源未找到
  403：没有权限
  500：服务器错误
  504：网关超时

http常见的header有哪些

常见的请求头

常见的响应头

缓存相关的headers

在下边http缓存机制中有介绍

什么是restful API

• 一种新的API设计方法
• 传统的API设计：把每个URL当成一个功能
• restful API：把每个URL当做一个唯一的资源

如何设计成一个资源？

尽量不用URL参数
传统API设计是把API当成方法（会传参）
restfulAPI是吧API当成资源的唯一表示来设计
用method（post get delete patch）表示操作类别

http缓存机制（重点）

哪些资源可以被缓存

js css img都可以被缓存

这是因为如果这些资源被修改了那么他的文件名也就会变，在webpack打包时候当内容发生更改时候，他们后边的哈希值就会变，所以即使他们变了那请求数据的名字也就会改变从而不会再使用之前缓存的数据

强制缓存

强制缓存的响应头

协商缓存

每次请求时候服务端都会去判断一下这个资源现在是否和你本地一样，如果可以复用就返回304告诉客户端这个资源你就用原来的就行，我就不给你发了。

HTTP 与 HTTPS 有哪些区别？

1. HTTP 是超文本传输协议，信息是明文传输，存在安全风险的问题。HTTPS 则解决 HTTP 不安全的缺陷，在 TCP 和 HTTP 网络层之间加入了 SSL/TLS 安全协议，使得报文能够加密传输。

2. HTTP 连接建立相对简单， TCP 三次握手之后便可进行 HTTP 的报文传输。而 HTTPS 在 TCP 三次握手之后，还需进行 SSL/TLS 的握手过程，才可进入加密报文传输。

3. HTTP 的端口号是 80，HTTPS 的端口号是 443。

4. HTTPS 协议需要向 CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的。

https工作流程

1. 建立TCP连接
2. 客户端向服务器索要并验证服务器的公钥。
3. 双方协商生产「会话秘钥」。
4. 双方采用「会话秘钥」进行加密通信。

SSL/TLS 协议建立的详细流程：

1. ClientHello

   首先，由客户端向服务器发起加密通信请求，也就是 ClientHello 请求。

   在这一步，客户端主要向服务器发送以下信息：

   （1）客户端支持的 SSL/TLS 协议版本，如 TLS 1.2 版本。

   （2）客户端生产的随机数（Client Random），后面用于生产「会话秘钥」。

   （3）客户端支持的密码套件列表，如 RSA 加密算法。

2. SeverHello

   服务器收到客户端请求后，向客户端发出响应，也就是 SeverHello。服务器回应的内容有如下内容：

   （1）确认 SSL/ TLS 协议版本，如果浏览器不支持，则关闭加密通信。

   （2）服务器生产的随机数（Server Random），后面用于生产「会话秘钥」。

   （3）确认的密码套件列表，如 RSA 加密算法。

   （4）服务器的数字证书。

3. 客户端回应

   客户端收到服务器的回应之后，首先通过浏览器或者操作系统中的 CA 公钥，确认服务器的数字证书的真实性。

   如果证书没有问题，客户端会从数字证书中取出服务器的公钥，然后使用它加密报文，向服务器发送如下信息：

   （1）一个随机数（pre-master key）。该随机数会被服务器公钥加密。

   （2）加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。

   （3）客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供服务端校验。

   上面第一项的随机数是整个握手阶段的第三个随机数，这样服务器和客户端就同时有三个随机数，接着就用双方协商的加密算法，各自生成本次通信的「会话秘钥」。

4. 服务器的最后回应

   服务器收到客户端的第三个随机数（pre-master key）之后，通过协商的加密算法，计算出本次通信的「会话秘钥」。然后，向客户端发生最后的信息：

   （1）加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。

   （2）服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供客户端校验。

   至此，整个 SSL/TLS 的握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的 HTTP 协议，只不过用「会话秘钥」加密内容。

HTTP/1.1、HTTP/2、HTTP/3 演变

HTTP/1.1 与 HTTP/1.0

改进：

1. 使用 TCP 长连接的方式改善了 HTTP/1.0 短连接造成的性能开销。
2. 支持 管道（pipeline）网络传输，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。

待改进：

1. 请求 / 响应头部（Header）未经压缩就发送，首部信息越多延迟越大。
2. 发送冗长的首部。每次互相发送相同的首部造成的浪费较多；
3. 队头阻塞：服务器是按请求的顺序响应的，如果服务器响应慢，会招致客户端一直请求不到数据，也就是队头阻塞；
4. 没有请求优先级控制；
5. 请求只能从客户端开始，服务器只能被动响应。

HTTP/2 与 HTTP/1.1

改进：

1. 头部压缩
2. 二进制格式
3. 数据流：每个请求或者响应就是一次数据流，因为他们可能是分成多次发给服务端就想流水一样，客户端还可以`指定数据流的优先级``。
4. 多路复用: HTTP/2 是可以在一个连接中并发多个请求或回应，而不用按照顺序一一对应。（解决了队头阻塞）
5. 服务器推送

待改进：

1. 多个 HTTP 请求在复用一个 TCP 连接，下层的 TCP 协议是不知道有多少个 HTTP 请求的。所以一旦发生了丢包现象，就会触发 TCP 的重传机制，这样在一个 TCP 连接中的所有的 HTTP 请求都必须等待这个丢了的包被重传回来。

HTTP/3 与 HTTP/2

改进：

1. 解决http2丢包后引起所有请求都必须等待这个丢了的包被重传回来的问题：HTTP/3 把 HTTP 下层的 TCP 协议改成了 基于UDP的QUIC （可以保证不像UDP一样丢包）协议！

https如何保证传输信息的安全

1.混合加密

2.摘要（哈希）算法+数字签名

它可以生成数据独一无二的《指纹》，指纹用于校验数据的完整性，解决了数据被篡改的风险
但是此时也会有一个问题，你无法确定这个内容和指纹是来自你想要的服务端给你发送过来的
所以就需要数字签名了：通过「私钥加密，公钥解密」的方式，来确认消息的身份，也就是数字签名算法。只有公钥能正常解密私钥加密的内容，这样也就能证明内容是来自于私钥的持有者（服务器）。
注：数字签名加密的可不是内容本身，而是哈希值。因为非对称加密速度慢

3.公钥存放在数字证书中

前面两个解决了：

• 可以通过哈希算法来保证消息的完整性；
• 可以通过数字签名来保证消息的来源可靠性（能确认消息是由持有私钥的一方发送的）；

还存在的问题：

• 如果公钥也是伪造的呢？因为坏人可以伪造公钥和私钥然后把公钥发给你。

这个时候就需要一个权威机构来证明了
权威机构会用自己的私钥 给数字证书的hash 进行加密（数字签名）然后放到CA证书中，并且CA证书的公钥事先就放在浏览器/操作系统中。
等服务器把证书发给客户端，客户端用事先存好的CA证书公钥去确认CA证书的真实性（CA证书公钥解密出hash与自己计算出来的hash记性比较，相同就说明可信），并且拿到服务器的公钥。这样就可以解决冒出的风险

如何优化http/1.1

1. 尽量避免发送重复的 HTTP 请求

对于重复性的请求可以使用缓存

2. 减少 HTTP 请求次数

1. 减少重定向次数：当你中间要经过代理服务器时那重定向工作可以直接交给代理服务器去做，就能减少http请求了
   
2. 合并请求: 例如使用雪碧图，将一个个小图片合成一个大图片，只需要一次传输就够了
3. 延迟发送请求： 图片懒加载啊

减少服务器的 HTTP 响应的数据大小（压缩）