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 一般都会分开发送，因此是需要四次挥手。
