HTTP

HTTP缓存技术

• 强制缓存
  只要浏览器判断缓存没用过期，则直接使用浏览器的本地缓存，决定是否使用缓存的主动性在浏览器

利用两个HTTP响应头部字段实现，用来表示资源在客户端缓存的有效期：
(1) Cache Control，是一个相对时间，优先级高于Expire
(2) Expire，是一个绝对时间

• 协商缓存
  通过服务端告知客户端是否可以使用缓存的方式称为协商缓存
  协商缓存可以基于两种头部来实现：
  (1) 基于时间来实现的，请求头部的If-Modified-Since字段与响应头部的Last-Modified字段实现
  (2) 基于唯一标识来实现的，请求头部的If-None-Match字段与响应头部的ETag字段实现

注意：协商缓存的这两个字段需要配合强制缓存的Cache-Control字段来使用，只有在未命中强制缓存的时候，才能发起带有协商缓存字段的请求

对称加密算法和非对称加密算法

• 对称加密算法
  数据的加密和解密都是使用同一个秘钥
• 非对称加密算法
  使用两个秘钥，一个是公钥，一个私钥，这两个秘钥可以双向加解密，比如可以用公钥加密内容，然后用私钥解密，也可以用私钥加密内容，公钥解密内容。

流程的不同，意味着目的也不相同：

• 公钥加密，私钥解密。这个目的是为了保证内容传输的安全，因为被公钥加密的内容，其他人是无法解密的，只有持有私钥的人，才能解密出实际的内容；
• 私钥加密，公钥解密。这个目的是为了保证消息不会被冒充，因为私钥是不可泄露的，如果公钥能正常解密出私钥加密的内容，就能证明这个消息是来源于持有私钥身份的人发送的。

一般我们不会用非对称加密来加密实际的传输内容，因为非对称加密的计算比较耗费性能的。

HTTPS

HTTPS是在HTTP和TCP层之间加入了SSL/TLS协议，可以解决HTTP明文传输的窃听风险、篡改风险、冒充风险。
HTTPS是通过以下三个方式解决上面三个风险的：
(1) 混合加密的方式实现信息的机密性，解决了窃听的风险
采用的是对称加密和非对称加密结合的「混合加密」方式

• 在通信建立前采用非对称加密的方式交换「会话秘钥」，后续就不再使用非对称加密。
• 在通信过程中全部使用对称加密的「会话秘钥」的方式加密明文数据。

采用「混合加密」的方式的原因：

• 对称加密只使用一个密钥，运算速度快，密钥必须保密，无法做到安全的密钥交换。
• 非对称加密使用两个密钥：公钥和私钥，公钥可以任意分发而私钥保密，解决了密钥交换问题但速度慢。

image.png

(2) 摘要算法的方式来实现完整性，它能够生成独一无二的指纹，指纹用于校验数据的完整性，解决了篡改的风险
为了保证传输的内容不被篡改，我们需要对内容计算出一个「指纹」，然后同内容一起传输给对方。
对方收到后，先是对内容也计算出一个「指纹」，然后跟发送方发送的「指纹」做一个比较，如果「指纹」相同，说明内容没有被篡改，否则就可以判断出内容被篡改了。
那么，在计算机里会用摘要算法（哈希函数）来计算出内容的哈希值，也就是内容的「指纹」，这个哈希值是唯一的，且无法通过哈希值推导出内容。
通过哈希算法可以确保内容不会被篡改，但是并不能保证「内容 + 哈希值」不会被中间人替换，因为这里缺少对客户端收到的消息是否来源于服务端的证明。
私钥是由服务端保管，然后服务端会向客户端颁发对应的公钥。如果客户端收到的信息，能被公钥解密，就说明该消息是由服务器发送的。

image.png

(3) 将服务器公钥放入到数字证书中，解决了冒充的风险

image.png

HTTP/1.1 、HTTP/2.0、HTTP/3.0

image.png

HTTP/1.1

优点：

• 简单
• 灵活和易于扩展
• 应用广泛和跨平台

缺点：
- 无状态
- 明文传输
- 不安全

性能：
- 长连接
- 管道网络传输
即可在同一个 TCP 连接里面，客户端可以发起多个请求，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。
但是服务器必须按照接收请求的顺序发送对这些管道化请求的响应。
如果服务端在处理 A 请求时耗时比较长，那么后续的请求的处理都会被阻塞住，这称为「队头堵塞」。
HTTP/1.1 管道解决了请求的队头阻塞，但是没有解决响应的队头阻塞。
- 队头阻塞

性能瓶颈：

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

HTTP/2.0

HTTP/2 协议是基于 HTTPS 的，所以 HTTP/2 的安全性也是有保障的
HTTP/2 相比 HTTP/1.1 性能上的改进：

• 头部压缩
• 二进制格式
  HTTP/2 不再像 HTTP/1.1 里的纯文本形式的报文，而是全面采用了二进制格式，头信息和数据体都是二进制，并且统称为帧（frame）：头信息帧（Headers Frame）和数据帧（Data Frame）
• 并发传输
  我们都知道 HTTP/1.1 的实现是基于请求-响应模型的。同一个连接中，HTTP 完成一个事务（请求与响应），才能处理下一个事务，也就是说在发出请求等待响应的过程中，是没办法做其他事情的，如果响应迟迟不来，那么后续的请求是无法发送的，也造成了队头阻塞的问题。
  而 HTTP/2 就很牛逼了，引出了 Stream 概念，多个 Stream 复用在一条 TCP 连接
• 服务器主动推送资源
  HTTP/2 还在一定程度上改善了传统的「请求 - 应答」工作模式，服务端不再是被动地响应，可以主动向客户端发送消息。
  客户端和服务器双方都可以建立 Stream， Stream ID 也是有区别的，客户端建立的 Stream 必须是奇数号，而服务器建立的 Stream 必须是偶数号。

HTTP/3.0

HTTP/1.1 和 HTTP/2 都有队头阻塞的问题：

• HTTP/1.1 中的管道（ pipeline）虽然解决了请求的队头阻塞，但是没有解决响应的队头阻塞，因为服务端需要按顺序响应收到的请求，如果服务端处理某个请求消耗的时间比较长，那么只能等响应完这个请求后， 才能处理下一个请求，这属于 HTTP 层队头阻塞。
• HTTP/2 虽然通过多个请求复用一个 TCP 连接解决了 HTTP 的队头阻塞 ，但是一旦发生丢包，就会阻塞住所有的 HTTP 请求，这属于 TCP 层队头阻塞。

HTTP/2 队头阻塞的问题是因为 TCP，所以 HTTP/3 把 HTTP 下层的 TCP 协议改成了 UDP！

UDP 发送是不管顺序，也不管丢包的，所以不会出现像 HTTP/2 队头阻塞的问题。大家都知道 UDP 是不可靠传输的，但基于 UDP 的 QUIC 协议 可以实现类似 TCP 的可靠性传输。

QUIC 有以下 3 个特点。

• 无队头阻塞
• 更快的连接建立
• 连接迁移

TCP三次握手&四次挥手

image.png

三次握手的原因：

• 三次握手才可以阻止重复历史连接的初始化（主要原因）
• 三次握手才可以同步双方的初始序列号
• 三次握手才可以避免资源浪费

双方都可以主动断开连接，断开连接后主机中的「资源」将被释放，四次挥手的过程如下图：

image.png

• 客户端打算关闭连接，此时会发送一个 TCP 首部 FIN 标志位被置为 1 的报文，也即 FIN 报文，之后客户端进入 FIN_WAIT_1 状态。
• 服务端收到该报文后，就向客户端发送 ACK 应答报文，接着服务端进入 CLOSE_WAIT 状态。
• 客户端收到服务端的 ACK 应答报文后，之后进入 FIN_WAIT_2 状态。
• 等待服务端处理完数据后，也向客户端发送 FIN 报文，之后服务端进入 LAST_ACK 状态。
• 客户端收到服务端的 FIN 报文后，回一个 ACK 应答报文，之后进入 TIME_WAIT 状态
• 服务端收到了 ACK 应答报文后，就进入了 CLOSE 状态，至此服务端已经完成连接的关闭。
• 客户端在经过 2MSL 一段时间后，自动进入 CLOSE 状态，至此客户端也完成连接的关闭。

你可以看到，每个方向都需要一个 FIN 和一个 ACK，因此通常被称为四次挥手。

这里一点需要注意是：主动关闭连接的，才有 TIME_WAIT 状态。

四次挥手原因：

• 关闭连接时，客户端向服务端发送 FIN 时，仅仅表示客户端不再发送数据了但是还能接收数据。
• 服务端收到客户端的 FIN 报文时，先回一个 ACK 应答报文，而服务端可能还有数据需要处理和发送，等服务端不再发送数据时，才发送 FIN 报文给客户端来表示同意现在关闭连接。

从上面过程可知，服务端通常需要等待完成数据的发送和处理，所以服务端的 ACK 和 FIN 一般都会分开发送，因此是需要四次挥手。