加入收藏 | 设为首页 | 会员中心 | 我要投稿 厦门网 (https://www.xiamenwang.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 创业 > 正文

从起源到发展 详说HTTP从1到3的演变

发布时间:2020-07-23 06:16:28 所属栏目:创业 来源:互联网
导读:访问: 阿里云新用户福利专场 云服务器ECS低至102元/年 天翼云年中上云节 云主机1C2G 92元/年 实名注册送8888元大礼包 本文也无意于深挖 HTTP 中的某一点,这是像 《HTTP 权威指南》或者是 RFC 协议做的事。本文目标是帮助读者理清 HTTP 的演化过程,说说

QUIC 握手的过程需要一次数据交互,0-RTT 时延即可完成握手过程中的密钥协商,比 TLS 相比效率提高了 5 倍,且具有更高的安全性。在握手过程中使用 Diffie-Hellman 算法协商初始密钥,初始密钥依赖于服务器存储的一组配置参数,该参数会周期性的更新。初始密钥协商成功后,服务器会提供一个临时随机数,双方根据这个数再生成会话密钥。

具体握手过程如下:

(1) 客户端判断本地是否已有服务器的全部配置参数,如果有则直接跳转到(5),否则继续

(2) 客户端向服务器发送 inchoate client hello(CHLO) 消息,请求服务器传输配置参数

(3) 服务器收到 CHLO,回复 rejection(REJ) 消息,其中包含服务器的部分配置参数

(4) 客户端收到 REJ,提取并存储服务器配置参数,跳回到(1)

(5) 客户端向服务器发送 full client hello 消息,开始正式握手,消息中包括客户端选择的公开数。此时客户端根据获取的服务器配置参数和自己选择的公开数,可以计算出初始密钥。

(6) 服务器收到 full client hello,如果不同意连接就回复 REJ,同(3);如果同意连接,根据客户端的公开数计算出初始密钥,回复 server hello(SHLO)消息,SHLO 用初始密钥加密,并且其中包含服务器选择的一个临时公开数。

(7) 客户端收到服务器的回复,如果是 REJ 则情况同(4);如果是 SHLO,则尝试用初始密钥解密,提取出临时公开数

(8) 客户端和服务器根据临时公开数和初始密钥,各自基于 SHA-256 算法推导出会话密钥

(9) 双方更换为使用会话密钥通信,初始密钥此时已无用,QUIC 握手过程完毕。之后会话密钥更新的流程与以上过程类似,只是数据包中的某些字段略有不同。

写在最后

想起有一个名言:计算机领域没有什么问题是加一层解决不了的,如果有,就再加一层。网络模型本来就是层层累加,到了 Web 得以快速生动的展现给人们以丰富的内容。从 HTTP 的演变过程中,我们可以看到中间又累加了若干层。不知道以后,又会是怎么样呢?

大家会发现,笔者在文中不止一次提到了演变这个词。是的,这是来自达尔文进化论中的理论。在笔者看来,“物竞天择,适者生存”的演变理论和计算机领域的技术变化是很类似的,只不过在这里,不是天择,而是人择。由市场,由用户来选择。不知道接下来,作为选择者的我们,又将怎样主导技术的走向?

本文素材来自互联网

(编辑:厦门网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

热点阅读