HTTP和HTTPS协议

定义：超文本传输协议

• 超文本：嵌套了文本的超链接（例如html），能从一个超文本跳转到另一个超文本。

  • 文本：文字、图片、视频等。

• 传输：双向传输协议。

  • 数据从 a 传到 b ，但是 http 协议允许在a和b之间添加一个或多个中间节点，这些中间节点也必须遵守 http 协议，他们也可以在不干扰数据传输的情况下可以添加任何额外的东西。

• 协议：在计算机世界中确定了一种只能两个或两个以上的计算机之间通信交流的一种规范，以及相关的错误处理方式。

HTTP 协议是用于两个节点之间传输超文本的一种协议。

状态码：

1. 1xx 类状态码属于提示信息，是协议处理中的一种中间状态，实际用到的比较少。

2. 2xx 类状态码表示服务器成功处理了客户端的请求，也是我们最愿意看到的状态。

   • 「200 OK」是最常见的成功状态码，表示一切正常。如果是非 HEAD 请求，服务器返回的响应头都会有 body 数据

   • 「204 No Content」也是常见的成功状态码，与 200 OK 基本相同，但响应头没有 body 数据。

   • 「206 Partial Content」是应用于 HTTP 分块下载或断电续传，表示响应返回的 body 数据并不是资源的全部，而是其中的一部分，也是服务器处理成功的状态。

3. 3xx 类状态码表示客户端请求的资源发送了变动，需要客户端用新的 URL 重新发送请求获取资源，也就是重定向。

   • 「301 Moved Permanently」表示永久重定向，说明请求的资源已经不存在了，需改用新的 URL 再次访问。

   • 「302 Moved Permanently」表示临时重定向，说明请求的资源还在，但暂时需要用另一个 URL 来访问。301 和 302 都会在响应头里使用字段 Location，指明后续要跳转的 URL，浏览器会自动重定向新的 URL。

   • 「304 Not Modified」不具有跳转的含义，表示资源未修改，重定向已存在的缓冲文件，也称缓存重定向，用于缓存控制。

4. 4xx 类状态码表示客户端发送的报文有误，服务器无法处理，也就是错误码的含义。

   • 「400 Bad Request」表示客户端请求的报文有错误，但只是个笼统的错误。

   • 「403 Forbidden」表示服务器禁止访问资源，并不是客户端的请求出错。

   • 「404 Not Found」表示请求的资源在服务器上不存在或未找到，所以无法提供给客户端。

5. 5xx 类状态码表示客户端请求报文正确，但是服务器处理时内部发生了错误，属于服务器端的错误码。

   • 「500 Internal Server Error」与 400 类型，是个笼统通用的错误码，服务器发生了什么错误，我们并不知道。

   • 「501 Not Implemented」表示客户端请求的功能还不支持，类似“即将开业，敬请期待”的意思。

   • 「502 Bad Gateway」通常是服务器作为网关或代理时返回的错误码，表示服务器自身工作正常，访问后端服务器发生了错误。

   • 「503 Service Unavailable」表示服务器当前很忙，暂时无法响应服务器，类似“网络服务正忙，请稍后重试”的意思。

POST 和 GET ：

说一下 POST 方法和 GET 方法的区别

GET 方法：从服务器上获取资源（静态的文本、页面、图片等）。

POST 方法：和 GET 方法相反，它会向 URL 中指定的资源提交数据，数据就放在报文的 body 中。

POST 方法和 GET 方法是安全和幂等的吗？

在 HTTP 协议里，所谓的「安全」是指请求方法不会「破坏」服务器上的资源。所谓的「幂等」，意思是多次执行相同的操作，
结果都是「相同」的。

GET 方法是安全且幂等的。

• GET 方法都是只读操作，不论操作多少次，服务器上的数据都是安全的，并且每次访问服务器的结果都是相同的。

POST 方法是非安全且非幂等的。

• POST 方法有读操作，会修改服务器上的资源，所以是不安全的；多次提交数据，就会创建多个资源，每次访问的结果也就不是相同的，所以是不幂等的。

HTTP 协议的特性

你知道 HTTP/1.1 协议的优点是什么？是如何体现出来的？

HTTP最明显的优点就是简单，灵活，易于扩展，应用广泛，支持跨平台。

• 简单

  • HTTP 基本的报文格式就是 header + body，头部信息也是 key-value 简单文本的形式，易于理解。

• 灵活和易于扩展

  • HTTP协议里的各类请求方法、URI/URL、状态码、头字段等每个组成要求都没有被固定死，都允许开发人员自定义和扩充。

  • HTTP 由于是工作在应用层（ OSI 第七层），则它下层可以随意变化。

  • HTTPS 也就是在 HTTP 与 TCP 层之间增加了 SSL/TLS 安全传输层，HTTP/3 甚至把 TCP 层换成了基于 UDP 的 QUIC。

• 应用广泛和支持跨平台

那它的缺点呢？

无状态，明文传输，不安全。

• 无状态

  • 好处：服务器不会记忆 HTTP 的状态，所以不需要额外的资源去记录状态信息，这能减轻服务器的负担，可以让更多的 CPU 和内存来为外界提供服务。

  • 坏处：因为服务器没有记忆能力，所以在完成一些有关联的操作时会很麻烦（例如：登录→添加购物车→下单→结算→支付，这些都要知道用户的身份，每次都要问一遍身份信息）。

    如何解决

    使用 Cookie 技术

    Cookie 是在请求和响应报文中写入 Cookie 信息来控制客户端的状态。

• 明文传输

  • 好处：明文意味着信息是可以通过抓包工具来用肉眼观看的，为调试工作带来了极大的遍历。

  • 坏处：信息很容易被窃取。

• 不安全

  • 通信使用的是明文传输，内容可能会被窃听。

  • 不验证对方身份，可能会遭遇伪装。

  • 无法证明报文的完整性，有可能会被篡改。

那你说一下它的性能如何？

• 长连接（持久连接）

  • 在早期的 HTTP/1.0 中，客户端每发起一次请求，都要建立一次 TCP 连接（三次握手），而且是串行请求，增加了通信的开销。

  • HTTP/1.1 提出了长连接的通信方式

    • 好处：减少了 TCP 连接的重复建立和断开，减轻了服务器的负载。

    • 特点：只要客户端和服务器任意一端没有明确的提出断开连接，则一直保持 TCP 连接。

• 管道网络传输

  • 管道网络传输：在同一个 TCP 请求中，客户端可以发起多个请求，在第一个请求发出去之后，不必等待服务器的响应，就可以直接发出第二次请求，可以减少整体的响应时间。但是服务器还是**按照顺序回应请求，**要是前面的回应特别慢，后面就要很多请求在排队等候，这就是队头阻塞。

• 队头阻塞

  • 当顺序发起的其中一个请求阻塞了，后面很多排队等候的请求也就阻塞了，会导致客户端一直请求不到数据。

HTTP 和 HTTPS

HTTP 和 HTTPS 有哪些区别？

1. HTTP 协议的端口号是 80， HTTPS 协议的端口号是 443。

2. HTTP 协议是超文本传输协议，信息是明文传输，不安全；HTTPS 协议补全了这种缺陷，在 HTTP 和 TCP 之间加了一层 SSL/TLS安全协议，使得报文能够加密传输。

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

4. HTTP 建立连接相对来说比较简单，只需要 TCP 三次握手之后就可以进行报文的传输，而 HTTPS 协议要在 TCP 三次握手之后再进行一次 SSL/TLS 的握手过程才能进行报文的加密传输。

HTTPS 解决了 HTTP 的哪些问题？

窃听分险，篡改风险，冒充风险。

HTTPS 是如何做到解决上面三个风险的？

• 混合加密的方式保证了数据报文的加密安全性，解决了窃听的风险。

  • HTTPS 协议采取的是对称加密和非对称加密相结合的混合加密算法。

  • 使用非对称加密算法传输对称加密的公钥。

  • 使用对称加密算法传输数据。

• 以摘要算法的方式来实现数据完整性，解决了篡改的风险。

  • 客户端在发送数据报文之前，先用摘要算法对明文进行计算，算出此明文的“指纹”，发送的时候把“指纹”和明文一起加密成密文之后一齐发给服务器，服务器接收解密后通过相同的摘要算法计算，用计算出来的和发过来的“指纹”做比较，若相同，则证明数据是完整的。

• 把服务器的公钥放在数字证书中，解决了冒充的风险。

HTTPS 是如何建立连接的？其中交互发生了什么？

SSL/TLS 协议基本流程：

• 客户端向服务端索要并验证服务器的公钥。

• 双方协商产生“会话密钥”。

• 双方使用“会话密钥”进行通信。

前两步就是 SSL/TLS 加密协议的握手过程。

SSL/TLS 加密协议的具体握手过程：

1. 由客户端向服务器发起通信请求。

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

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

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

2. 服务器收到由客户端发起的请求后，向客户端发出响应。

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

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

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

   • 服务器的数字证书。

3. 客户端收到服务器的响应后，通过浏览器或者操作系统中的 CA 公钥确定服务器数字证书的真实性。如果真实性没问题，那就从服务器发来的证书中取出公钥，使用它加密报文并发送给服务器。

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

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

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

4. 服务器收到客户端发来的加密报文后，通过协商的加密算法计算出本次通信的“会话密钥”，最后在向客户端发送最后的信息。

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

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

HTTP/1.1 HTTP/2 HTTP/3演变

说说 HTTP/1.1 相比 HTTP/1.0 提高了什么性能？

• 使用长连接的方式改变了 HTTP 短连接所造成的性能开销。

• 支持管道网络传输，只要第一个请求发出去了，不必等待其回应，就可以发出第二个请求，可以减少整体的响应时间。

当然 HTTP/1.1 还有性能瓶颈：

• 请求头部/响应头部没有压缩就进行发送，首部信息越多延迟越大，只能压缩 body 的部分。

• 每次互相发送冗长的头部，所造成的资源浪费较大。

• 队头阻塞。

• 没有请求优先级控制。

• 请求只能从客户端发出，服务器只能被动响应。

那上面的 HTTP/1.1 的性能瓶颈，HTTP/2 做了什么优化？

• 头部压缩

  • 如果同时发出多个请求，他们的头部分是一样的或是相似的，协议会消除一部分（利用索引代替）

  • HPACK算法：在客户端和服务器同时维护一张头信息表，所有的字段都会存入这张信息表，生成一个索引号，之后发送时就不用发送相同的字段了，只发送索引号即可。

• 二进制格式

  • 报文用的是纯二进制形式。

  • 头信息和数据体都是二进制形式，统称为帧：头信息帧和数据帧。

  • 增加了数据传输的效率。

• 数据流

  • HTTP/2 的数据包不是顺序发送的，同一个 TCP 连接里连续的数据包，可能属于不同的回应，因此需要做出标记。

  • 每个请求或回应的数据包称为一个数据流(Stream)。

  • 每个数据流都有一个独一无二的编号，其中规定客户端发出的数据流编号为奇数，服务器发出的数据流编号为偶数。

  • 客户端可以指定数据流的优先级，优先级高的服务器就先响应处理。

• 多路复用

  • HTTP/2 可以在一个 TCP 连接中并发多个请求或回应，不用按照顺序一一对应。

  • 解决了队头阻塞问题，降低了延迟，大幅度提高了连接的利用率。

• 服务器推送

  • 服务器不再只是被动地响应，而是可以主动向客户端发送消息。

  • 可以减少延时的等待。

  • 缺点：

    • 如果客户端只是误点，服务器直接就把这些资源文件发送了过来，会占用服务器的资源和浏览器的缓存。

HTTP/2 有哪些缺陷？HTTP/3 做了哪些优化？

HTTP/2 的问题在于一旦有多个 HTTP 连接请求在复用一个 TCP 连接，下层的 TCP 协议也不清楚到底有多少个 HTTP 请求，一旦发生丢包现象，就会触发 TCP 协议的重传机制，这样的话在这个 TCP 连接中的所有 HTTP 连接都会被阻塞，等待这个丢了的包重传回来。

因为这是 TCP 的问题，所以 HTTP/3 把 TCP 换成了基于 UDP 的 QUIC 协议。

• QUIC 有自己的一套机制可以保证传输的可靠性的。当某个流发生丢包时，只会阻塞这个流，其他流不会受到影响。

• TL3 升级成了最新的 1.3 版本，头部压缩算法也升级成了 QPack。

• HTTPS 要建立一个连接，要花费 6 次交互，先是建立三次握手，然后是 TLS/1.3 的三次握手。QUIC 直接把以往的 TCP 和 TLS/1.3 的 6 次交互合并成了 3 次，减少了交互次数。

所以， QUIC 协议是一个在 UDP 之上的伪 TCP + TLS + HTTP/2 的多路复用的协议。