写点什么

为什么 HTTPS 需要 7 次握手以及 9 倍时延?

2020 年 2 月 28 日

为什么 HTTPS 需要 7 次握手以及 9 倍时延?

为什么这么设计(Why’s THE Design)是一系列关于计算机领域中程序设计决策的文章,我们在这个系列的每一篇文章中都会提出一个具体的问题并从不同的角度讨论这种设计的优缺点、对具体实现造成的影响。如果你有想要了解的问题,可以在文章下面留言。


HTTP 协议(Hypertext Transfer Protocol)已经成为互联网上最常用的应用层协议,然而其本身只是用于传输超文本的网络协议,不会提供任何安全上的保证,使用明文在互联网上传输数据包使得窃听和中间人攻击成为可能,通过 HTTP 传输密码其实与在互联网上裸奔也差不多。



图 1 - HTTPS 协议


网景(Netscape)在 1994 年设计了 HTTPS 协议,使用安全套接字层(Secure Sockets Layer,SSL)保证数据传输的安全1,随着传输层安全协议(Transport Layer Security,TLS)的发展,目前我们已经使用 TLS 取代了废弃的 SSL 协议,不过仍然使用 SSL 证书一词2


HTTPS 是对 HTTP 协议的扩展,我们可以使用它在互联网上安全地传输数据3,然而 HTTPS 请求的发起方第一次从接收方获取响应需要经过 4.5 倍的往返延迟(Round-Trip Time,RTT)。本文将详细介绍请求发起和响应的过程,分析为什么 HTTPS 协议需要通过 4.5-RTT 的时间获得服务提供方的响应:


  • TCP 协议 — 通信双方通过三次握手建立 TCP 连接4

  • TLS 协议 — 通信双方通过四次握手建立 TLS 连接5

  • HTTP 协议 — 客户端向服务端发送请求,服务端发回响应;


这里的分析建立在特定版本的协议实现以及常见场景上,随着网络技术的发展,我们能够减少需要的网络通信次数,本文会在对应章节中提到一些常见的优化方案。


TCP

HTTP 协议作为应用层协议,它需要底层的传输层协议为其提供基本的数据传输功能,HTTP 协议一般都会使用 TCP 协议作为底层协议。为了阻止错误的建立历史连接,TCP 协议通信的双方会通过三次握手建立 TCP 连接6,我们在这里简单回顾一下 TCP 连接建立的整个过程。



图 2 - TCP 三次握手


  1. 客户端向服务端发送带有 SYN 的数据段以及客户端开始发送数据段(Segment)的初始序列号 SEQ = 100

  2. 服务端收到数据段时,向客户端发送带有 SYNACK 的数据段;

  3. 通过返回 ACK = 101 确认客户端数据段的初始序列号;

  4. 通过发送 SEQ = 300 通知客户端,服务端开始发送数据段的初始序列号;

  5. 客户端向服务端发送带有 ACK 的数据段,确认服务端的初始序列号,其中包含 ACK = 301


TCP 连接的双方会通过三次握手确定 TCP 连接的初始序列号、窗口大小以及最大数据段,这样通信双方就能利用连接中的初始序列号保证双方数据段的不重不漏、通过窗口大小控制流量并使用最大数据段避免 IP 协议对数据包的分片7


最初版本的 TCP 协议确实会通过三次通信建立 TCP 连接,在目前的大多数场景下,三次握手也是无法避免的,不过在 2014 年提出的 TCP 快启(TCP Fast Open,TFO)却可以在某些场景下通过一次通信建立 TCP 连接8



图 3 - TCP 快启


TCP 快启策略使用存储在客户端的 TFO Cookie 与服务端快速建立连接。TCP 连接的客户端向服务端发送 SYN 消息时会携带快启选项,服务端会生成一个 Cookie 并将其发送至客户端,客户端会缓存该 Cookie,当其与服务端重新建立连接时,它会使用存储的 Cookie 直接建立 TCP 连接,服务端验证 Cookie 后会向客户端发送 SYNACK 并开始传输数据,这也就能减少通信的次数。


TLS

TLS 的作用是在可靠的 TCP 协议上构建安全的传输通道,其本身是不提供可靠性保障的,我们还是需要下层可靠的传输层协议。在通信双方建立可靠的 TCP 连接之后,我们就需要通过 TLS 握手交换双方的密钥了,在这里我们将介绍 TLS 1.2 的连接建立过程9



图 4 - TLS 1.2 建立连接


  1. 客户端向服务端发送 Client Hello 消息,其中携带客户端支持的协议版本、加密算法、压缩算法以及客户端生成的随机数

  2. 服务端收到客户端支持的协议版本、加密算法等信息后;

  3. 向客户端发送 Server Hello 消息,并携带选择特定的协议版本、加密方法、会话 ID 以及服务端生成的随机数

  4. 向客户端发送 Certificate 消息,即服务端的证书链,其中包含证书支持的域名、发行方和有效期等信息;

  5. 向客户端发送 Server Key Exchange 消息,传递公钥以及签名等信息;

  6. 向客户端发送可选的消息 CertificateRequest,验证客户端的证书;

  7. 向客户端发送 Server Hello Done 消息,通知服务端已经发送了全部的相关信息;

  8. 客户端收到服务端的协议版本、加密方法、会话 ID 以及证书等信息后,验证服务端的证书;

  9. 向服务端发送 Client Key Exchange 消息,包含使用服务端公钥加密后的随机字符串,即预主密钥(Pre Master Secret);

  10. 向服务端发送 Change Cipher Spec 消息,通知服务端后面的数据段会加密传输;

  11. 向服务端发送 Finished 消息,其中包含加密后的握手信息;

  12. 服务端收到 Change Cipher Spec 和 Finished 消息后;

  13. 向客户端发送 Change Cipher Spec 消息,通知客户端后面的数据段会加密传输;

  14. 向客户端发送 Finished 消息,验证客户端的 Finished 消息并完成 TLS 握手;


TLS 握手的关键在于利用通信双方生成的随机字符串和服务端的公钥生成一个双方经过协商后的密钥,通信的双方可以使用这个对称的密钥加密消息防止中间人的监听和攻击,保证通信的安全。


在 TLS 1.2 中,我们需要 2-RTT 才能建立 TLS 连接10,但是 TLS 1.3 通过优化协议,将两次往返延迟降低至一次,大幅度减少建立 TLS 连接所需要的时间,让客户端可以在 1-RTT 之后就能向服务端传输应用层数据。


这里就不展开介绍 TLS 1.3 建立连接的过程了,除了减少常规握手下的网络开销,TLS 1.3 还引入了 0-RTT 的连接建立过程;60% 的网络连接都是用户在第一次访问网站或者间隔一段时间后访问时建立的,剩下的 40% 可以通过 TLS 1.3 的 0-RTT 策略解决11,然而该策略与 TFO 的实现原理比较相似,都是通过重用会话和缓存来实现的,所以存在一定的安全风险,使用时也应该结合业务的具体场景。


HTTP

在已经建立好 TCP 和 TLS 通道上传输数据是比较简单的事情,HTTP 协议可以直接利用下层建立的可靠的、安全的通道传输数据。客户端通过 TCP 的套接字接口向服务端写入数据,服务端在接收到数据、进行处理后通过相同的途径返回。因为整个过程需要客户端发送请求以及服务端返回响应,所以耗时是 1-RTT。



图 5 - HTTP 请求和响应


HTTP 协议的数据交换只会消耗 1-RTT,当客户端和服务端仅处理一次 HTTP 请求时,从 HTTP 协议本身我们已经无法进行优化。不过随着请求的数量逐渐增加,HTTP/2 就可以复用已经建立的 TCP 连接减少 TCP 和 TLS 握手带来的额外开销。


总结

当客户端想要通过 HTTPS 请求访问服务端时,整个过程需要经过 7 次握手并消耗 9 倍的延迟。如果客户端和服务端因为物理距离上的限制,RTT 约为 40ms 时,第一次请求需要 ~180ms;不过如果我们想要访问美国的服务器,RTT 约为 200ms 时,这时 HTTPS 请求的耗时为 ~900ms,这就是一个比较高的耗时了。我们来总结一下 HTTPS 协议需要 9 倍时延才能完成通信的原因:


  1. TCP 协议需要通过三次握手建立 TCP 连接保证通信的可靠性(1.5-RTT);

  2. TLS 协议会在 TCP 协议之上通过四次握手建立 TLS 连接保证通信的安全性(2-RTT);

  3. HTTP 协议会在 TCP 和 TLS 上通过一次往返发送请求并接收响应(1-RTT);


需要注意的是,本文对往返延时的计算都基于特定的场景以及特定的协议版本,网络协议的版本在不断更新和演进,过去忽略的问题最开始都会通过补丁的方式更新,但是最后仍然会需要从底层完成重写。


HTTP/3 就是一个这样的例子,它会使用基于 UDP 的 QUIC 协议进行握手,将 TCP 和 TLS 的握手过程结合起来,把 7 次握手减少到了 3 次握手,直接建立了可靠并且安全的传输通道,将原本 ~900ms 的耗时降低至 ~500ms,我们会在后面的文章介绍 HTTP/3 协议相关的内容。到最后,我们还是来看一些比较开放的相关问题,有兴趣的读者可以仔细思考一下下面的问题:


  • 作为传输层协议,QUIC 协议和 TCP 协议之间有什么异同?

  • 为什么可以通过 0-RTT 建立客户端和服务端的连接?


本文转载自 Draveness 技术网站。


原文链接:https://draveness.me/whys-the-design-https-latency


2020 年 2 月 28 日 17:24269

评论

发布
暂无评论
发现更多内容

揭秘人民日报创作大脑:百度大脑智能创作平台助力打造“十八般武艺”

百度大脑

更新完IOS14,网络工程师又开始背锅了

波场链智能合约DAPP系统开发技术

薇電13242772558

智能合约 dapp

区块链技术如何真实有效的赋能智慧交通?

CECBC区块链专委会

区块链

别无分号只此一家,Python3接入支付宝身份认证接口( alipay.user.certify)体系(2021年最新攻略)

刘悦的技术博客

Python 支付宝 身份认证 刷脸 实名认证

量化机器人管理系统开发|市值管理机器人模式系统开发

W13902449729

市值管理机器人开发 市值管理系统开发

区块链:能源行业出现破坏性创新的基础?

CECBC区块链专委会

区块链 能源

全球台式机CPU市场二八分定型,英特尔仍旧占据全球最大份额

商业资讯

通过 Oracle 变量更新公司名称

Flychen

ml-agents项目实践(一)

行者AI

模型训练

OpenYurt 入门 - 在树莓派上玩转 OpenYurt

阿里巴巴云原生

阿里云 开源 容器 云原生 中间件

真牛!成功跳槽百度工资从15K涨到28K,附赠课程+题库

欢喜学安卓

android 程序员 面试 移动开发

涨知识!Android面试真题解析火爆全网,搞懂这些直接来阿里入职

欢喜学安卓

android 程序员 面试 移动开发

简述CAP原理

andy

获奖公布|构建基于容器技术,承载数据类有状态工作负载的数据云平台,技术挑战有哪些?

花斯基

话题讨论 活动专区

大作业2

走走,停停……

阿里巴巴2020首发136道Java高级岗面试题(含答案)

Crud的程序员

Java 程序员 程序员面试

视频混剪怎么准备素材?会声会影视频消音操作步骤详解!

奈奈的杂社

视频剪辑 视频后期 混剪 视频消音

如何使用ClickHouse实现时序数据管理和挖掘?

京东科技开发者

数据库 数据采集 数据库管理工具

全球台式机CPU市场份额AMD超越Intel?别再混淆视听,误导消费者了!

商业资讯

阿里云技术专家解读:2021 年六大容器技术发展趋势

阿里巴巴云原生

云计算 阿里云 容器 云原生 k8s

有奖话题 | 2021 新年Flag,牛转乾坤!

InfoQ写作平台官方

话题讨论 活动专区

同城快递系统设计文档

业哥

接口测试--获取动态参数进阶

测试人生路

接口测试

实物资产卡片多数量拆分流程整理2021.01.06

Flychen

干货速递,百度BML自动超参搜索技术原理揭秘与实战攻略!

百度大脑

使用Github Actions部署静态网站

玉龙BB

GitHub Pages Hugo Github Actions

性能测试思考分析

andy

MySQL蜜罐获取攻击者微信ID

Java架构师迁哥

区块链推动电力能源管理新一轮技术变革

CECBC区块链专委会

区块链

这些面试题你会吗?为什么有人说Android开发不再吃香?最全的BAT大厂面试题整理

欢喜学安卓

android 程序员 面试 移动开发

为什么 HTTPS 需要 7 次握手以及 9 倍时延?-InfoQ