推荐阅读 小林coding HTTP篇
文章目录
- HTTP 80
- HTTP 响应码
- 1xx：信息性状态码（Informational）
- 2xx：成功状态码（Success）
- 3xx：重定向状态码（Redirection）
- 4xx：客户端错误（Client Error）
- 5xx：服务器错误（Server Error）
- 常见字段
- GET POST
- HTTP/1 /2 /3
- HTTP/1.0
- HTTP/1.1
- HTTP/2
- HTTP/3 【QUIC】
- HTTPS 443
- 加密方式
- 混合加密
- 摘要算法 -> 数字签名
- 数字证书
- TLS 1.2 握手
- RSA 算法加密
- 过程：
- 原理：
- 为什么安全：
HTTP 80
超文本传输协议 HyperText Transfer Protocol
HTTP 响应码
1xx：信息性状态码（Informational）
表示请求已被接收，继续处理。
-
100 Continue：客户端应继续其请求。
-
101 Switching Protocols：服务器同意切换协议。
2xx：成功状态码（Success）
表示请求已成功被接收、理解并处理。
- 200 OK：请求成功。
- 201 Created：资源已成功创建，常用于 POST 请求。
- 204 No Content：请求成功，但无返回内容。
3xx：重定向状态码（Redirection）
客户端需要进一步操作才能完成请求。
- 301 Moved Permanently：永久重定向。
- 302 Found（或 Temporary Redirect）：临时重定向。
- 304 Not Modified：资源未修改，可使用缓存。
4xx：客户端错误（Client Error）
请求包含错误，客户端需修改。
- 400 Bad Request：请求无效，服务器无法理解。
- 401 Unauthorized：未授权，需要认证。
- 403 Forbidden：禁止访问，即使认证也无权。
- 404 Not Found：资源不存在。
- 405 Method Not Allowed：请求方法不被允许。
5xx：服务器错误（Server Error）
服务器在处理请求时出错。
- 500 Internal Server Error：服务器内部错误。
- 502 Bad Gateway：网关或代理收到无效响应。
- 503 Service Unavailable：服务器暂时不可用（如超载或维护）。
- 504 Gateway Timeout：网关超时未收到上游服务器响应。
常见字段
-
Host: www.xxx.com 请求中指定对方域名
-
Content-Length: 1000 回应数据长度
-
Connection: Keep-Alive 长连接
-
Content-Type: text/heml; charset=utf-8 数据格式
（请求方可以指定格式： Accept: /） -
Content-Encoding: gzip 编码，即压缩方法
（Accept-Encoding: gzip, deflate）
GET POST
-
GET 的语义是从服务器获取指定的资源
安全且幂等，因为是只读，服务器数据是安全的，每次请求结果是相同的。 -
POST 的语义是根据请求负荷（报文body）对指定的资源做出处理
不幂等，会修改资源。
HTTP/1 /2 /3
HTTP/1.0
每个请求都要新建一个TCP连接（三次握手），而且是串行请求 —— 发出A请求，并且收到回复后，四次挥手。接着三次握手开始发送B请求 … 【请求的队头阻塞】
HTTP/1.1
使用长连接的通信方式。
进而支持进行管道（pipeline）网络传输 —— 即 A 请求发送后，就可以发出B请求了。不过A请求的响应处理完之后才能处理B请求的响应。 【响应的队头阻塞】
其他缺点：
请求头部没有压缩，每次交互都会发送完整头部，而且是纯文本形式。
没有请求优先级控制。
请求只能从客户端开始，服务器只能被动响应。
HTTP/2
-
头部压缩
如果你同时发出多个请求，他们的头是一样的或是相似的，那么协议会帮你消除重复的部分。
HPACK 算法压缩：在客⼾端和服务器同时维护⼀张头信息表，所有字段都会存⼊这个表，⽣成⼀个索引号，以后就不发送同样字段了，只发送索引号，这样就提⾼速度了。 -
二进制格式
全面采用了二进制格式，头信息和数据体都是二进制，并且统称为帧（frame）：头信息帧（Headers Frame）和数据帧（Data Frame）。
如状态码200：由 ‘2’‘0’‘0’ 三个字符 -> HPACK 的静态表编码是 8，1个字节 10001000 -
并发传输
引出了 Stream 概念，多个 Stream 复用在一条 TCP 连接。
针对不同的 HTTP 请求用独一无二的 Stream ID 来区分，接收端可以通过 Stream ID 有序组装成 HTTP 消息，不同 Stream 的帧是可以乱序发送的 。
即可以并行交错地发送请求和响应。
-
服务器主动推送资源
客户端和服务器双方都可以建立 Stream，客户端建立的 Stream 必须是奇数号，而服务器建立的 Stream 必须是偶数号。
比如获取HTML文件后，还需要依赖的CSS来渲染，这时就不需要再次发送请求了，而是服务器主动推送相关资源。
不过，
因为是基于 TCP 协议传输数据，TCP层保证了收到的字节流数据是完整且连续的才会返回给应用层
—— 那么当「前 1 个字节数据」没有到达时，后收到的字节数据只能存放在内核缓冲区里等待 【HTTP/2 队头阻塞问题】
而且一旦发生丢包现象，就会触发TCP重传机制，连接中所有的HTTP请求仍然得接着等待
实际上 HTTP/2 的效率并不比 HTTP/1.1 快很多，对于多个数据流，HTTP/1.1 通过建立多个 TCP 连接的方式也能处理。
HTTP/3 【QUIC】
基于 UDP 的 QUIC 协议
-
无队头阻塞
QUIC 自己的机制可以保证传输的可靠性的。当某个流发生丢包时，只会阻塞这个流，其他流不会受到影响，因此不存在队头阻塞问题。
-
更快的连接建立
对于 HTTP/1 和 HTTP/2 协议，TCP 和 TLS 是分层的，分别属于内核实现的传输层、openssl 库实现的表示层，因此它们难以合并在一起，需要分批次来握手，先 TCP 握手，再 TLS 握手。
而 QUIC 协议握手会在QUIC帧内包含 TLS/1.3，只需要 1 RTT 就可以「同时」完成建立连接与密钥协商。
甚至，在第二次连接的时候（如会话恢复），应用数据包可以和 QUIC 握手信息一起发送，达到 0-RTT 的效果。
-
连接迁移
QUIC 协议通过连接 ID 来标记通信的两个端点。
即使设备网络变化，IP地址等变了，只要仍保有上下文信息（比如连接 ID、TLS 密钥等），就可以“无缝”地复用原连接，消除重连的成本，没有丝毫卡顿感，达到了连接迁移的功能。
基于 TCP 传输协议的 HTTP 协议，由于是通过四元组（源 IP、源端口、目的 IP、目的端口）确定一条 TCP 连接。
那么当移动设备的网络从 4G 切换到 WIFI 时，意味着 IP 地址变化了，那么就必须要断开连接，然后重新建立连接。而建立连接的过程包含 TCP 三次握手和 TLS 四次握手的时延，以及 TCP 慢启动的减速过程，给用户的感觉就是网络突然卡顿了一下，因此连接的迁移成本是很高的。
HTTPS 443
HTTP 是明文传输，不安全。
HTTPS 在 HTTP层与TCP层之间添加了TLS协议（传输层安全性协议 Transport Layer Security）
TCP三次握手后还要进行 TLS 握手
SSL ：安全套接层 Secure Sockets Layer
HTTPS 一定安全可靠
加密方式
以下几个结合，分别确保 消息加密，消息不被篡改，中间人无法伪造
混合加密
-
在通信建立前采用非对称加密的方式交换「会话秘钥」
RSA 算法 （非对称加密算法） -
在通信过程中全部使用对称加密的「会话秘钥」
摘要算法 -> 数字签名
用摘要算法（哈希函数）来计算出内容的哈希值
对方也对内容计算，比较两个哈希值。
通过「私钥加密，公钥解密」的方式，保证消息不会被冒充
（但是公钥仍可能是中间人冒充的 —— 中间人攻击 ！）
数字证书
Certificate Authority 证书授权
浏览器内置证书！里面有公钥
客户端验证流程：
证书信任链的问题：
如百度证书，可能证书是中间证书签发的
不是根证书，就无法根据本地已有的根证书中的公钥去验证 证书是否可信，于是向 CA 请求该中间证书，直到根证书。
电脑系统内置的根证书：
TLS 1.2 握手
基于 RSA 算法的 TLS 握手过程（TLS 1.2 with RSA key exchange）：
- ClientHello
客户端发起加密通信请求 【支持的TLS协议版本；加密用随机数；支持的加密算法】 - SeverHello
服务器回应客户端 【确认TLS版本；加密用随机数；确认使用的加密算法；服务器证书】 - 客户端回应
客户端先通过浏览器或操作系统内置的 CA 公钥，确认服务器的数字证书的真实性。
如果证书没有问题，客户端会从数字证书中取出服务器的公钥，然后使用它加密报文。
接着发送【 预主密钥 ；加密通信算法改变通知；客户端握手结束通知】，同时自己用前面两个随机数+预主密钥生成了本次通信用的公钥——会话密钥。 - 服务器的最后回应
服务器也通过同样的方式计算出会话密钥
也向客户端发送最后的信息：【加密通信算法改变通知；服务器握手结束通知】
之后通过 会话密钥 加密 HTTP 通信即可。
RSA 握手“不那么安全”
一旦服务器私钥泄露，历史通信就可以被解密（前向保密性差）
现在主流推荐使用的是 TLS 1.3 ECDHE（椭圆曲线 Diffie-Hellman Ephemeral），支持前向保密。
RSA 算法加密
需要先了解一些数论：
- 欧拉函数 φ ( n ) φ(n) φ(n) 表示小于等于 n 且与 n互质的正整数的个数。对质数而言就是 n-1
- 欧拉定理：对于任意两个互质的正整数 a, n , 有
a
φ
(
n
)
≡
1
(
m
o
d
n
)
a^{φ(n)} ≡1\pmod n
aφ(n)≡1(modn)
（≡ 是模意义下同余） - 费马小定理： 如果 p 是一个质数，a是一个整数且 a 与 p 互质，那么 a p − 1 ≡ 1 ( m o d p ) a^{p − 1} ≡ 1 \pmod p ap−1≡1(modp)
过程：
-
选择两个大质数 p , q p, q p,q
模数 n = p ∗ q n = p*q n=p∗q 作为我们的模数 -
n 的欧拉函数 φ ( n ) = ( p − 1 ) ( q − 1 ) φ (n) = (p-1)(q-1) φ(n)=(p−1)(q−1)
-
加密指数 e e e ，取数 e 与 φ (n) 互质
e 模逆元设为 d d d ，即 e d ≡ 1 ( m o d φ ( n ) ) ed ≡ 1 \pmod {φ(n)} ed≡1(modφ(n)) （逆元其实就是倒数，取模意义下的）
可得 ed 其实就是 k ∗ φ ( n ) + 1 k*φ(n) + 1 k∗φ(n)+1
-
加密明文 m ：
密文 c = m e m o d n c = m^e \mod n c=memodn
可以看到就是对原数据求幂 -
解密：
m = c d m o d n m = c^d \mod n m=cdmodn
原理：
整个过程就是先求明文 m 的 e 次幂，然后求 m^e 的 d 次幂
( m e ) d ( m o d n ) ({m^{e}})^{d} \pmod n (me)d(modn)
即
m
e
d
(
m
o
d
n
)
{m^{ed}} \pmod n
med(modn)
而由上可知 ed = k*φ(n) + 1 ，以及 欧拉定理中 m^φ(n) 取模n后为 1
所以上述表达式最终取模后为 m 本身 ✅
为什么安全：
模数 n 是公开的， e 是加密指数可作为公钥。
但是推出解密指数，需要得出 φ (n) ，这需要选择出正确的质数 p, q 。
“大整数分解难题” 将一个大整数 n 分解成两个质数 p 和 q 是非常困难的
当 n 是一个 2048 位的大整数时，它的两个因数 p 和 q 也是大质数（每个约 1024 位），在现有技术和算法下，分解这样的大整数需要数十亿年
