目录
HTTP1.0和HTTP1.1的区别
HTTP1.1相比HTTP1.0性能上的改进：
使用长连接的方式改善了HTTP1.0短链接的性能开销。
支持管道网络传输，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。
但是HTTP1.1还是有性能瓶颈：
- 请求/响应头部（header）未经压缩就发送，首部信息越多延迟越大。只能压缩Body部分；
- 发送冗长的首部。每次互相发送相同的首部造成的浪费较多；
- 服务器是按请求的顺序响应的，如果服务器响应慢，会导致客户端一直请求不到数据，也就是对头阻塞；
- 没有请求优先级控制；
- 请求只能从客户端开始，服务器只能被动响应。
HTTP/2做了什么优化？
HTTP/2协议是基于HTTPS的，所以HTTP/2的安全性也有保障的。
那HTTP/2相比HTTP/1.1性能上的改进：
- 头部压缩
- 二进制格式
- 并发传输
- 服务器主动推送资源
1.头部压缩：HTTP/2会压缩头（header）如果你同时发出多个请求，他们的头是一样的或相似的，那么，协议会帮你消除重复的部分。这就是所谓的HPACK算法：在客户端和服务器同时维护一张头信息表，所有的字段都会存入这个表，生成一个索引号，以后就不发送同样的字段了，只发送索引号，这就就提高速度了。
2.二进制格式：HTTP/2不在像HTTP1.1里的纯文本形式的报文，而是全面采用了二进制格式，头信息和数据体都是二进制，并且统称为帧：头信息帧和数据帧。这样虽然对人不友好，但是对计算机非常友好，因为计算机只懂二进制，那么接收到报文后，无需再将明文的报文转成二进制，而是直接解析二进制报文，这增加了数据传输的效率。
3.并发传输：引出了Stream的概念，多个Stream复用在一条TCP连接。解决了HTTP1.1对头阻塞的问题；
4.服务器主动推送资源：HTTP/2还在一定程度上改善了传统的请求-应答模型，服务端不再是被动的响应，可以总动像客户端发送消息
在 HTTP/2 中，多个请求的帧在同一个 TCP 连接上传输，若某个请求的帧在传输过程中丢失或延迟，导致接收方无法按序接收，就会阻塞该连接上所有请求帧的接收和处理。
HTTP/3的优点
HTTP/2通过头部压缩，二进制编码，多路复用，服务端推送等新特性大幅度提升了HTTP/1.1的性能，而美中不足的是HTTP/2协议是基于TCP实现的，于是存在三个缺陷。
- 对头阻塞
- TCP与TLS的握手延迟
- 网络迁移需要重新连接；
因为TCP是字节流协议，TCP层必须保证收到的字节数据是完整且有序的，如果我序列号较低的TCP段在网络传输中丢失了，即使序列号较高的TCP段已经被接收了，应用层无法从内核中读取到这部分数据
**网络迁移需要重新连接：**一个TCP由四元组（元ip地址，源端口，目标ip地址，目标端口）确定的，这意味着如果我ip地址或者端口变动了就要tcp与tls从新握手，这样不利于移动设备切换网络的场景，比如4g网络环境切换成wifi。
HTTP/3就将传输层从TCP替换成了UDP，并在UDP协议上开发了QUIC 协议，来保证数据的可靠传输。
无对头阻塞，QUIC连接上多个Stream之间并没有依赖，都是独立的，也不会由底层协议限制，某个流发送丢包了，只会影响该流，其他流不受影响；
建立连接速度快，因为QUIC内部包含了TLS1.3因此只需要1个RTT就可以同时完成建立连接和TLS密钥协商，甚至第二次连接的时候，应用数据包可以和QUIC握手信息
连接迁移
QUIC 支持通过连接 ID 保持会话，即便 IP 地址或网络切换（如 Wi - Fi 转 4G），连接仍然有效。这种特性特别适用于移动场景，能确保数据连接的稳定性，极大改善了移动设备用户的体验。
HTTP与HTTPS的区别
- HTTP是超文本传输协议，信息是明文传输，存在安全风险的问题。HTTPS则解决了HTTP不安全的缺陷，在TCP和HTTP网络层之间加入了SSL/TLS安全协议，使得报文能够加密传输。
- HTTP连接建立相对简单，TCP三次握手之后便可进行HTTP的报文传输。而HTTPS在TCP三次握手之后，还需进行SSL/TLS的握手过程，才可进入加密报文传输。
- 两者默认的端口不一样，HTTP默认端口号是80，HTTPS默认端口号是443.
- HTTPS协议需要先AC（证书权威机构）申请数字证书，来保证服务器的身份是可行的。
HTTPS的工作原理
1.ClientHello
首先，由客户端向服务器发起加密通信请求，也就是ClientHello请求。在这一步，客户端主要向服务器发送以下信息：
- 客户端支持的SSL/TLS协议版本，如TLS1.2版本
- 客户端生产的随机数Client Random，后面用于生产【会话密钥】
- 客户端支持的密码套件列表，如RSA加密算法。
2.ServerHello
服务器收到客户端请求后，向往客户端发出响应，也就是SeverHello。服务器回应的内容有如下内容：
- 确认SSL/TLS协议版本，如果浏览器不支持，则关闭加密通信。
- 服务器生产的随机数（Server Random），后面用于生产【会话密钥】
- 确认的密码套件列表，如RSA加密算法
- 服务器的数字证书
3.客户端回应
客户端收到服务器的回应后，首先通过浏览器或者操作系统中的CA公钥，确认服务器的数字证书的真实性。
如果证书没有问题，客户端会从数字证书中取出服务器的公钥，然后使用它加密报文，向服务器发送如下信息：
- 一个随机数。该随机数会被服务器公钥加密
- 加密通信算法改变通知，表示随后的信息都将用【会话密钥】加密通信
- 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时把之前所有内容的发送的数据做个摘要，用来供服务端校验。
上面第一项的随机数是整个握手阶段的第三个随机数，这样服务器和客户端就同时有三个随机数，接着用双方协商的加密算法，各自生成本次通信的【会话密钥】。
4.服务器的最后回应
服务器收到客户端的第三个随机数之后，就通过协商的加密算法，计算出本次通信的【会话密钥】。然后，向客户端发送最后的信息：
- 加密通信算法改变通知，表示随后的信息都将用【会话密钥】加密通信
- 服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供客户端校验。
至此，整个SSL/TLS的握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的HTTP协议，只不过使用【会话密钥】加密内容。
三、三者协同作用：确保密钥安全的核心逻辑
随机性叠加 ：
三个随机数的组合（
ClientRandom + ServerRandom + Pre-Master Secret）形成 高熵值的密钥材料，即使其中一个随机数被泄露，攻击者也无法推导出完整密钥（需同时破解三个随机数）。防止重放攻击 ：
每次通信的随机数唯一，即使攻击者截获旧通信数据，也无法用旧随机数重新生成当前会话的密钥。
双向验证与密钥协商：
- 客户端和服务端通过随机数确认对方的参与（确保不是单向伪造）。
- 预主密钥的安全传输（如通过服务端公钥加密）确保只有合法通信双方能计算出主密钥。
TCP与UDP的区别
1.连接
- TCP是面向连接的传输层协议，传输数据前先要建立连接。
- UDP是不需要连接，即刻传输数据。
2.服务对象
- TCP是一对一的两点服务，即一条连接只有两个端点。
- UDP支持一对一，一对多，多对多的交互通信。
3.可靠性
- TCP是可靠交付数据的，数据可以无差错，不丢失，不重复，按序到达。
- UDP是尽最大努力交付，不保证可靠交付数据。但是我们可以基于UDP传输协议实现一个可靠的传输协议，比如QUIC协议。
4.拥塞控制，流量控制
- TCP有拥塞控制和流量控制机制，保证数据传输的安全性。
- UDP则没有，即使网络非常拥堵了，也不会影响UDP的发生速率。
5.首部开销
- TCP首部长度较长，会有一定的开销。
- UDP首部只有8个字节，并且是固定不变的，开销较小。