HTTP1.0,HTTP2.0,HTTP3.0

本文深入解析了HTTP1.1到HTTP2的演进,包括持久连接、管道机制、HTTPS的加密流程、CA证书的作用,以及HTTP2的多路复用、报头压缩和QUIC技术。探讨了HTTPS的安全性,以及HTTP3的QUIC协议如何改进传输效率。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

HTTP

HTTP1.0

浏览器的每一次请求,都需要和服务器建立一个TCP连接。开销很大。影响服务器的性能。

HTTP1.1

  1. 持久连接:TCP连接默认不关闭,可以与多个请求共用

  2. 管道机制:同一个浏览器和服务器的多次请求可以在同一个TCP连接中,进行通信。

    • http请求头中加入Connection: keep-alive来告诉对方这个请求响应完成后不要关闭,下一次咱们还用这个请求继续交流。协议规定HTTP/1.0如果想要保持长连接,需要在请求头中加上Connection: keep-alive

  3. 分块传输编码:服务器每生成一个数据块,就传输一个数据,用流传输代替缓存传输。

  4. 端口是80

  • 缺点:

    1. TCP连接中的数据,必须按序到达。服务器只有处理完一个请求后,才可以继续处理下一个请求。这会带来堵塞的问题。

HTTPS

HTTPS是HTTP和TCP之间,增加了一条SSL加密层,端口是443。

  1. 浏览器发送HTTPS请求给服务器。

  2. 服务器收到请求以后,生成公钥和私钥,把公钥和证书一起发给浏览器。

  3. 浏览器校验证书后,利用公钥给密钥加密。并且把加密好的密钥发送给服务器。

  4. 服务器拿到密钥后,用私钥进行解密。

  5. 然后浏览器和服务器之间就建立了一条加密通道,数据都通过这个加密通道用密钥进行传输。

(1) https的CA机构有什么用

  • CA机构用于颁发证书。

  • CA会使用根证书的私钥加密请求文件,生成证书。

  • CA机构的数字签名使得攻击者不能伪造和篡改证书。可以有效避免中间人攻击。

(2) CA证书的验证过程

证书链

  • CA证书本身也包含一对非对称密钥对。

    • 私钥用于签发数字证书。

    • 公钥用于发布出去,给浏览器验证数字签名。

浏览器怎么知道证书是可信的?

  • 浏览器主要依据客户端操作系统保存的根证书列表判断CA的权威性。

    • 在Windows操作系统中,这个列表放在“受信任的根证书颁发机构存储区”中,这个列表实际上是CA机构的根证书集合,根证书包含CA机构的信息和公钥。只要是这个列表中的CA签发的证书,浏览器就认为可信。微软会动态维护根证书列表,用户需要管理员权限才能向这个列表中加入CA证书。

(3) https为什么同时使用对称密文和非对称密文

使用不同的场景。

  • 非对称加密传输数据:用于交换密钥,安全性更高。

  • 对称加密:用于传输数据,速度更快。

(4) 为什么不用非对称加密传输数据而是采用对称加密传输数据

  • 非对称加密传输数据:用于交换密钥

    • 私钥加密的密文只有公钥才能解开;公钥加密的密文只有私钥才能解开。

  • 对称加密:用于传输数据

对称加密是双方用同一个密钥进行加密和解密

  • 计算量小,效率高,速度快

  • 而 HTTPS 中传输数据是高频次的行为,需要快。

(5) 数字签名

  • 数字签名是只有信息发送者才能产生的别人无法伪造的一段文本,这段文本是对信息发送者发送信息真实性的一个有效证明,具有不可抵赖性。

    • 服务器根据报文文本生成 128 位散列值,然后用私钥对文本加密来形成数字签名。

    • client 收到以后,先生成散列值,再用服务器发来的公钥进行解密,然后比对报文结果是否一致。

(6) HTTPS 是绝对安全的吗?

  • https不一定全是安全的,一些网站会使用自签名证书。

  • 自签名证书可能会受到中间人攻击。

HTTP2

HTTP2 在 HTTP1.x 基础上进行升级,并且建立在 HTTPS 的基础上。

多路复用

  • HTTP1.1,client 发送一个请求后,要等待 server 返回后,再进行下一次请求。

  • HTTP2.0 的浏览器和服务器之间可以同时发送多个请求和回复,不要求TCP连接中的数据按序到达。client 可以发送请求1后,立刻发送请求2。等到数据都收到后,进行帧的组装。单条 TCP 连接上可以同时发送多个 HTTP 请求

报头压缩

  • HTTP2队头部信息进行了信息压缩,减少了头部信息。

HTTP2允许服务器未经请求,便向浏览器发送数据。

HTTP3

是最新的协议,利用 UDP+quic 代替 TCP+SSL/TLS 层。

QUIC

加密

  1. 1RTT: client 向 server 请求公钥,server返回公钥

  2. client 收到公钥后,缓存并生成自己的临时公私钥对,用 server 的公钥和 client 的私钥对密钥 k1 加密后,连同 client 的公钥返回给 server,并且同时有应用数据产生。

    • 这一步 client 返回密钥 k1(server 公钥和 client 私钥加密过) + 应用数据

  3. server 收到加密过的密钥和 client 公钥后,用 server 私钥和 client 公钥解密,获得密钥,并获得应用数据。

  4. server 生成服务器端新公私钥,用新 server 私钥和 client 的公钥对密钥 k2 加密,连同数据一起发送给 client。

  5. client 收到后,用 client 私钥和 server 新公钥加密,得到密钥 k2,和数据。

  6. 之后,client 和 server 之间用 k2 进行加密和解密。

如何设计基于 udp 的可靠传输?

  • 完整性和有序性

完整性:

  • QUIC:通过包号(PKN)和确认应答(SACK)

    • PKN 是单调递增的,重发的包也会先让 PKN 递增后,再重发,而不会选择原来的 PKN 的值。

(1)客户端:发送 3 个数据包给服务器(PKN = 1,2,3)

(2)服务器:通过 SACK 告知客户端已经收到了 1 和 3,没有收到 2

(3)客户端:重传第 2 个数据包(PKN=4)

有序性

  • QUIC:通过数据偏移量 offset

流量控制

拥塞控制

  • 拥塞控制是通过拥塞窗口限制发送方的数据量,避免整个网络发生拥塞。

    • 超时重传:定时器超时仍没有收到 ACK,所以引起了发送方超时重传。

    • 快速重传:发送方在收到重复 ACK 时,无法判断是由于数据包丢失还是仅仅因为延迟,收到三个重复 ACK,就启动快速重传机制

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值