DH 算法迪菲-赫尔曼算法

QUIC协议和HTTP3.0

QUIC协议详解

队头阻塞问题

RTT 建链

首次连接和非首次连接

首次连接

非首次连接

前向安全问题

前向纠错

连接迁移

QUIC的应用和前景

DH 算法迪菲-赫尔曼算法

是 Diffie和Hellman两位作者于1976年提出了一种的密钥交换协议。这种加密算法主要用于密钥的交换，能够实现了在非安全网络下通信双方密钥的安全建立，从而使通信双方能够使用这个密钥进行消息的加密解密，从而实现通信的安全。

1）对资料打包并加密
2）将加密后的压缩包通过邮件发给Bob
3）将解密的密码用短信发给了Bob。
4）Bob在收到压缩包后，用短信收到的密钥解开。
这样一来，无论是邮件还是短信在传输的过程中泄露，别人都无法破解资料的内容（假定加密算法是可靠的）。

QUIC协议和HTTP3.0

QUIC其实是Quick UDP Internet Connections的缩写，直译为快速UDP互联网连接。

QUIC协议最初由Google的Jim Roskind设计，实施并于2012年部署，在2013年随着实验的扩大而公开宣布，并向IETF进行了描述。

QUIC提高了当前正在使用TCP的面向连接的Web应用程序的性能。它在两个端点之间使用用户数据报协议（UDP）建立多个复用连接来实现此目的。

QUIC的次要目标包括减少连接和传输延迟，在每个方向进行带宽估计以避免拥塞。它还将拥塞控制算法移动到用户空间，而不是内核空间，此外使用前向纠错（FEC）进行扩展，以在出现错误时进一步提高性能。

HTTP3.0又称为HTTP Over QUIC，其弃用TCP协议，改为使用基于UDP协议的QUIC协议来实现。

QUIC协议详解

择其善者而从之，其不善者而改之。

HTTP3.0既然选择了QUIC协议，也就意味着HTTP3.0基本继承了HTTP2.0的强大功能，并且进一步解决了HTTP2.0存在的一些问题，同时必然引入了新的问题。

QUIC协议必须要实现HTTP2.0在TCP协议上的重要功能，同时解决遗留问题，我们来看看QUIC是如何实现的。

队头阻塞问题

队头阻塞 Head-of-line blocking（缩写为HOL blocking）是计算机网络中是一种性能受限的现象，通俗来说就是：一个数据包影响了一堆数据包，它不来大家都走不了。

队头阻塞问题可能存在于HTTP层和TCP层，在HTTP1.x时两个层次都存在该问题。

HTTP2.0协议的多路复用机制解决了HTTP层的队头阻塞问题，但是在TCP层仍然存在队头阻塞问题。

TCP协议在收到数据包之后，这部分数据可能是乱序到达的，但是TCP必须将所有数据收集排序整合后给上层使用，如果其中某个包丢失了，就必须等待重传，从而出现某个丢包数据阻塞整个连接的数据使用。

QUIC协议是基于UDP协议实现的，在一条链接上可以有多个流，流与流之间是互不影响的，当一个流出现丢包影响范围非常小，从而解决队头阻塞问题。

RTT 建链

衡量网络建链的常用指标是RTT Round-Trip Time（往返时间），也就是数据包一来一回的时间消耗。

RTT包括三部分：往返传播时延、网络设备内排队时延、应用程序数据处理时延。

一般来说HTTPS协议要建立完整链接包括:TCP握手和TLS握手，总计需要至少2-3个RTT，普通的HTTP协议也需要至少1个RTT才可以完成握手。

然而，QUIC协议可以实现在第一个包就可以包含有效的应用数据，从而实现0RTT，但这也是有条件的。

简单来说，基于TCP协议和TLS协议的HTTP2.0在真正发送数据包之前需要花费一些时间来完成握手和加密协商，完成之后才可以真正传输业务数据。

但是QUIC则第一个数据包就可以发业务数据，从而在连接延时有很大优势，可以节约数百毫秒的时间。

QUIC的0RTT也是需要条件的，对于第一次交互的客户端和服务端0RTT也是做不到的，毕竟双方完全陌生。

因此，QUIC协议可以分为首次连接和非首次连接，两种情况进行讨论。

首次连接和非首次连接

使用QUIC协议的客户端和服务端要使用1RTT进行密钥交换，使用的交换算法是DH(Diffie-Hellman)迪菲-赫尔曼算法。

DH算法开辟了密钥交换的新思路，在之前的文章中提到的RSA算法也是基于这种思想实现的，但是DH算法和RSA的密钥交换不完全一样，感兴趣的读者可以看看DH算法的数学原理。

首次连接

简单来说一下，首次连接时客户端和服务端的密钥协商和数据传输过程，其中涉及了DH算法的基本过程：

客户端对于首次连接的服务端先发送client hello请求。服务端生成一个素数p和一个整数g，同时生成一个随机数 (笔误-此处应该是Ks_pri)为私钥，然后计算出公钥 = mod p，服务端将，p，g三个元素打包称为config，后续发送给客户端。客户端随机生成一个自己的私钥，再从config中读取g和p，计算客户端公钥 = mod p。客户端使用自己的私钥和服务端发来的config中读取的服务端公钥，生成后续数据加密用的密钥K = mod p。客户端使用密钥K加密业务数据，并追加自己的公钥，都传递给服务端。服务端根据自己的私钥和客户端公钥生成客户端加密用的密钥K = mod p。为了保证数据安全，上述生成的密钥K只会生成使用1次，后续服务端会按照相同的规则生成一套全新的公钥和私钥，并使用这组公私钥生成新的密钥M。服务端将新公钥和新密钥M加密的数据发给客户端，客户端根据新的服务端公钥和自己原来的私钥计算出本次的密钥M，进行解密。之后的客户端和服务端数据交互都使用密钥M来完成，密钥K只使用1次。

非首次连接

前面提到客户端和服务端首次连接时服务端传递了config包，里面包含了服务端公钥和两个随机数，客户端会将config存储下来，后续再连接时可以直接使用，从而跳过这个1RTT，实现0RTT的业务数据交互。

客户端保存config是有时间期限的，在config失效之后仍然需要进行首次连接时的密钥交换。

前向安全问题

前向安全是密码学领域的专业术语

前向安全或前向保密Forward Secrecy是密码学中通讯协议的安全属性，指的是长期使用的主密钥泄漏不会导致过去的会话密钥泄漏。

前向安全能够保护过去进行的通讯不受密码或密钥在未来暴露的威胁，如果系统具有前向安全性，就可以保证在主密钥泄露时历史通讯的安全，即使系统遭到主动攻击也是如此。

通俗来说，前向安全指的是密钥泄漏也不会让之前加密的数据被泄漏，影响的只有当前，对之前的数据无影响。

前面提到QUIC协议首次连接时先后生成了两个加密密钥，由于config被客户端存储了，如果期间服务端私钥泄漏，那么可以根据K = mod p计算出密钥K。

如果一直使用这个密钥进行加解密，那么就可以用K解密所有历史消息，因此后续又生成了新密钥，使用其进行加解密，当时完成交互时则销毁，从而实现了前向安全。

前向纠错

前向纠错是通信领域的术语

前向纠错也叫前向纠错码Forward Error Correction 简称FEC 是增加数据通讯可信度的方法，在单向通讯信道中，一旦错误被发现，其接收器将无权再请求传输。

FEC 是利用数据进行传输冗余信息的方法，当传输中出现错误，将允许接收器再建数据。

听这段描述就是做校验的，看看QUIC协议是如何实现的：

QUIC每发送一组数据就对这组数据进行异或运算，并将结果作为一个FEC包发送出去，接收方收到这一组数据后根据数据包和FEC包即可进行校验和纠错。

连接迁移

网络切换几乎无时无刻不在发生。

TCP协议使用五元组来表示一条唯一的连接，当我们从4G环境切换到wifi环境时，手机的IP地址就会发生变化，这时必须创建新的TCP连接才能继续传输数据。

QUIC协议基于UDP实现摒弃了五元组的概念，使用64位的随机数作为连接的ID，并使用该ID表示连接。

基于QUIC协议之下，我们在日常wifi和4G切换时，或者不同基站之间切换都不会重连，从而提高业务层的体验。

QUIC的应用和前景

通过前面的一些介绍我们看出来QUIC协议虽然是基于UDP来实现的，但是它将TCP的重要功能都进行了实现和优化，否则使用者是不会买账的。

QUIC协议的核心思想是将TCP协议在内核实现的诸如可靠传输、流量控制、拥塞控制等功能转移到用户态来实现，同时在加密传输方向的尝试也推动了TLS1.3的发展。

但是TCP协议的势力过于强大，很多网络设备甚至对于UDP数据包做了很多不友好的策略，进行拦截从而导致成功连接率下降。

主导者谷歌在自家产品做了很多尝试，国内腾讯公司也做了很多关于QUIC协议的尝试。

其中腾讯云对QUIC协议表现了很大的兴趣，并做了一些优化然后在一些重点产品中对连接迁移、QUIC成功率、弱网环境耗时等进行了实验，给出了来自生产环境的诸多宝贵数据。

简单看一组腾讯云在移动互联网场景下的不同丢包率下的请求耗时分布：

任何新生事物的推动都是需要时间的，出现多年的HTTP2.0和HTTPS协议的普及度都没有预想高，IPv6也是如此，不过QUIC已经展现了强大的生命力，让我们拭目以待吧！

DH 算法迪菲-赫尔曼算法QUIC协议和HTTP3.0相关推荐

密钥交换算法: 迪菲-赫尔曼算法
概述迪菲-赫尔曼算法用于通信双方交换密钥. 还记得之前介绍HTTPS协议的时候, 提到需要先通过对方公钥来进行密钥的交换, 然后再通过密钥对通信内容进行加密. 迪菲-赫尔曼算法就是用于交换密钥的. ...
DH算法 | 迪菲-赫尔曼Diffie–Hellman 密钥交换及RSA（学习笔记）
DH算法 | 迪菲-赫尔曼Diffie–Hellman 密钥交换(学习笔记),来自B站: [不懂数学没关系]DH算法 | 迪菲-赫尔曼Diffie–Hellman 密钥交换_哔哩哔哩_bilibili ...
Diffe_Hellman（迪菲-赫尔曼）算法
Diffe_Hellman算法 1.Diffe_Hellman算法概念 Diffe_Hellman(迪菲-赫尔曼)算法也叫DH算法是Whitefield Diffie和Martin Hellman在1 ...
java dh密钥交换_java-信息安全（八）-迪菲-赫尔曼（DH）密钥交换
概述信息安全基本概念: DH(Diffie–Hellman key exchange,迪菲-赫尔曼密钥交换) DH 是一种安全协议,,一种确保共享KEY安全穿越不安全网络的方法,它是OAKLEY的一 ...
Diffie-Hellman(迪菲-赫尔曼)秘钥交换协议
1. 协议背景对称密码体制: Bob利用对称密钥K对信息进行加密并将加密结果发送给Alice,Alice收到信息之后,用同样的密钥进行解密. 问题1:Alice是如何知道对称密钥K的?------即 ...
2015年图灵奖--惠特菲尔特·迪菲和马丁·赫尔曼简介
大家好,我是执念斩长河.今天讲述的是2015年图灵奖获得者惠特菲尔特·迪菲和马丁·赫尔曼,图灵奖奖励他们为密码学做出开拓贡献.读完本篇博问大家可以收获的是: 赫尔曼的博士论文迪菲是赫尔曼的助手经典 ...
python 3标准库道格_《PYTHON 3标准库 [美] 道格·赫尔曼》[美] 道格·赫尔曼（Doug Hellmann）著【摘要书评在线阅读】-苏宁易购图书...
商品参数作者: [美] 道格·赫尔曼(Doug Hellmann)著出版社:机械工业出版社出版时间:. 版次:. 印次:. 印刷时间:. 页数:. 开本:. ISBN:9787111608950 ...
西门子大中华区总裁兼CEO赫尔曼:智能自主制造将重塑工业格局！
西门子大中华区总裁兼首席执行官赫尔曼(Lothar Herrmann) 2020年9月10日,西门子中国数字化创新峰会召开.会上,西门子展示了其在数字化解决方案和人工智能.边缘计算.5G.工业云等前沿 ...
歪写数学史（数学界的花木兰——苏菲﹒热尔曼）
已经第十六章了,我终于可以荣幸的介绍这个系列中的第一位女性主人公,来自时尚之都同时也是数学家聚居地法国巴黎的---苏菲﹒热尔曼.在本章中我将用first name苏菲而不是last name热尔曼来称 ...
灵魂书籍 | 《记忆力心理学 | 赫尔曼·艾宾浩斯》
余生很长, 一定要学会对自己好一点; 余生很短, 请不要带着遗憾离场; 余生很贵, 请努力地活成自己喜欢的模样! 目录 <记忆力心理学 | 赫尔曼·艾宾浩斯> 1.1 作者介绍 1.2 核 ...

DH 算法迪菲-赫尔曼算法QUIC协议和HTTP3.0

DH 算法迪菲-赫尔曼算法

QUIC协议和HTTP3.0

QUIC协议详解

队头阻塞问题

RTT 建链

首次连接和非首次连接

首次连接

非首次连接

前向安全问题

前向纠错

连接迁移

QUIC的应用和前景

DH 算法迪菲-赫尔曼算法QUIC协议和HTTP3.0相关推荐

最新文章

热门文章