江苏龙网

  1. 首页 > 资讯 > 资讯 > >

通信技术|从起源到发展 详说HTTP从1到3的演变( 七 )


TFO 使得 TCP 协议有可能变成 0-RTT，核心思想和 Session Ticket 的概念类似: 将当前会话的上下文缓存在客户端 。如果以后需要恢复对话，只需要将缓存发给服务器校验，而不必花费一个 RTT 去等待 。
结合 TFO 和 Session Ticket 技术，一个本来需要花费 3 个 RTT 才能完成的请求可以被优化到一个 RTT 。如果使用 QUIC 协议，我们甚至可以更进一步，将 Session Ticket 也放到 TFO 中一起发送，这样就实现了 0-RTT 的对话恢复 。
QUIC 是怎么做的
让我们看看 QUIC 是怎么做的 。
首先声明一点，如果一对使用 QUIC 进行加密通信的双方此前从来没有通信过，那么 0-RTT 是不可能的，即便是 QUIC 也是不可能的 。
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 的演变过程中，我们可以看到中间又累加了若干层 。不知道以后，又会是怎么样呢？
大家会发现，笔者在文中不止一次提到了演变这个词 。是的，这是来自达尔文进化论中的理论 。在笔者看来，“物竞天择，适者生存”的演变理论和计算机领域的技术变化是很类似的，只不过在这里，不是天择，而是人择 。由市场，由用户来选择 。不知道接下来，作为选择者的我们，又将怎样主导技术的走向？
访问:
【通信技术|从起源到发展 详说HTTP从1到3的演变】阿里云 - 最高1888元通用代金券立即可用


推荐阅读


上一篇： 铁令|凌晨1点，恒大重磅消息！曝许家印下铁令：球员私自外出必须开除

下一篇：通信技术|NTT高管：美国政府要求其加入Open RAN政策联盟