透视 HTTP 协议
罗剑锋(Chrono)
前奇虎 360 技术专家,Nginx/OpenResty 开源项目贡献者
63943 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 48 讲
开篇词 (1讲)
透视 HTTP 协议
15
15
1.0x
00:00/00:00
登录|注册

28 | 连接太慢该怎么办:HTTPS的优化

Pre-shared Key (PSK)
Session Ticket
Session ID
OCSP Stapling
选择椭圆曲线(ECDSA)证书
选择AES_128_GCM
选择高性能的曲线
椭圆曲线的ECDHE算法
TLS1.3
协议优化
软件升级
SSL加速服务器
SSL加速卡
更快的CPU
对称加密报文传输
非对称加密握手
会话复用
证书优化
协议优化
软件优化
硬件优化
HTTPS连接慢的原因
HTTPS优化

该思维导图由 AI 生成,仅供参考

你可能或多或少听别人说过,“HTTPS 的连接很慢”。那么“慢”的原因是什么呢?
通过前两讲的学习,你可以看到,HTTPS 连接大致上可以划分为两个部分,第一个是建立连接时的非对称加密握手,第二个是握手后的对称加密报文传输
由于目前流行的 AES、ChaCha20 性能都很好,还有硬件优化,报文传输的性能损耗可以说是非常地小,小到几乎可以忽略不计了。所以,通常所说的“HTTPS 连接慢”指的就是刚开始建立连接的那段时间。
在 TCP 建连之后,正式数据传输之前,HTTPS 比 HTTP 增加了一个 TLS 握手的步骤,这个步骤最长可以花费两个消息往返,也就是 2-RTT。而且在握手消息的网络耗时之外,还会有其他的一些“隐形”消耗,比如:
产生用于密钥交换的临时公私钥对(ECDHE);
验证证书时访问 CA 获取 CRL 或者 OCSP;
非对称加密解密处理“Pre-Master”。
在最差的情况下,也就是不做任何的优化措施,HTTPS 建立连接可能会比 HTTP 慢上几百毫秒甚至几秒,这其中既有网络耗时,也有计算耗时,就会让人产生“打开一个 HTTPS 网站好慢啊”的感觉。
不过刚才说的情况早就是“过去时”了,现在已经有了很多行之有效的 HTTPS 优化手段,运用得好可以把连接的额外耗时降低到几十毫秒甚至是“零”。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文详细介绍了优化HTTPS连接速度的方法,包括硬件优化、软件优化和协议优化。主要针对HTTPS连接速度慢的问题,通过优化握手时的非对称加密过程,提出了多种解决方案。在硬件优化方面,建议选择内建AES优化的快速CPU、SSL加速卡或SSL加速服务器来加速加解密计算。在软件优化方面,建议升级至最新版本的软件以获得性能优化和错误修复。在协议优化方面,建议采用TLS1.3、选择椭圆曲线的ECDHE算法以及优化证书传输和验证过程。此外,还介绍了会话复用的两种方式:Session ID和Session Ticket,以及预共享密钥(PSK)的实现。总结指出,通过这些优化手段,可以有效缩短握手时间,提升连接速度,为读者提供了实用的技术细节和建议。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《透视 HTTP 协议》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(30)

  • 最新
  • 精选
  • -W.LI-
    Session ID:会话复用压力在服务端 Session Ticket:压力在客户端,客户端不安全所以要频繁换密钥文件 PSK:验证阶段把数据也带上,少一次请求 前两个都是缓存复用的思想,重用之前计算好的结果,达到降低CPU的目的。第三个就是少一次链接减少网络开销。 感觉都可以把开销大的东西缓存起来复用,缓存真个好东西,空间局部命中和时间局部命中定理太牛逼了。不过最关键的还是找性能瓶颈,精确定位性能瓶颈比较重要,然后针对瓶颈优化,空间换时间或者时间换空间。这个时候算法的价值就体现出来了。可惜这些我都不会╯﹏╰

    作者回复: psk实际上是Session Ticket的强化版,本身也是缓存,但它简化了Session Ticket的协商过程,省掉了一次RTT。 多在实践中学,多看些开源项目,就能逐渐掌握了。

    2019-07-31
    2
    16
  • 俊伟
    session id 把会话信息存在服务端 session ticket 把会话信息存在客户端 psk 在session ticket 的基础上,使用early data顺便再发送一下服务端的数据

    作者回复: 态度认真、积极,good。

    2020-01-17
    10
  • 前端西瓜哥
    1. 你能比较一下“Session ID”“Session Ticket”“PSK”这三种会话复用手段的异同吗? 答: (1)Session ID 类似网站开发中用来验证用户的 cookie,服务器会保存 Session ID对应的主密钥,需要用到服务器的存储空间。 (2)Session Ticket 貌似有点类似网站开发中的 JWT(JSON Web Token),JWT的做法是服务器将必要的信息(主密钥和过期时间)加上密钥进行 HMAC 加密,然后将生成的密文和原文相连得到 JWT 字符串,交给客户端。当客户端发送 JWT 给服务端后,服务器会取出其中的原文和自己的密钥进行 HMAC 运算,如果得到的结果和 JWT 中的密文一样,就说明是服务端颁发的 JWT,服务器就会认为 JWT 存储 的主密钥和有效时间是有效的。另外,JWT 中不应该存放用户的敏感信息,明文部分任何人可见(不知道 Session Ticket 的实现是不是也是这样?) (3)PSK 不是很懂,貌似是在 tcp 握手的时候,就直接给出了 Ticket(可是这样 Ticket 好像没有加密呢)。 总的来说,Session ID 需要服务器来存储会话;而 Session Ticket 则不需要服务器使用存储空间,但要保护好密钥。另外为了做到“前向安全”,需要经常更换密钥。PSK相比 Session Tick,直接在第一次握手时,就将 ticket 发送过去了,减少了握手次数。

    作者回复: 说的挺好,PSK其实就是Session Ticket的强化版,也有ticket,但应用数据随ticket一起发给服务器。

    2019-08-01
    7
  • Wr
    1、相同点:都是会话复用技术 区别: Seesion ID:会话数据缓存在服务端,如果服务器客户量大,对服务器会造成很大压力 Seeion Ticket:会话数据缓存在客户端 PAK:在Seesion Ticket的基础上,应用数据和Session Ticket一起发送给服务器,省去了中间服务器与客户端的确认步骤 2、暂无

    作者回复: 居然是三连……

    2020-01-14
    3
  • 饭粒
    1.抓包看了下 442 ,复用会话时 Client Hello session_ticket 确实有数据,Sessioin Id 好像也还会复用。 Transport Layer Security TLSv1.2 Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Length: 512 Handshake Protocol: Client Hello ... Random: 9474888cafdce89fd32eac247a8b464f842efbac706d8930… Session ID Length: 32 Session ID: a4a0caef10dee7a6f44aa522a35f6c799101d5eced01eb32… # Session ID ... Extension: session_ticket (len=192) # session_ticket Type: session_ticket (35) Length: 192 Data (192 bytes) ... Transport Layer Security TLSv1.2 Record Layer: Handshake Protocol: Server Hello Content Type: Handshake (22) Version: TLS 1.2 (0x0303) Length: 100 Handshake Protocol: Server Hello ... Random: e82519e9e8bfcbd40e1da7a202bd50ff993d5ef0cbc33378… Session ID Length: 32 Session ID: a4a0caef10dee7a6f44aa522a35f6c799101d5eced01eb32… # Session ID Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ... TLSv1.2 Record Layer: Change Cipher Spec Protocol: Change Cipher Spec TLSv1.2 Record Layer: Handshake Protocol: Finished 2.有个疑问:会话复用技术,保存会话数据的一端使用对端传过来的 Sessin Id 查询到之前的 master secret,但它如何安全的把这个 master secret 传递给对端(对端应该只有 Sessin Id 吧)? 3.抓包过程用 Chrome 发请求,前三次 Client Hello, Server Hello 握手过程都因为 Alert (Level: Fatal, Description: Certificate Unknown) 失败了,第四次才成功。 而使用 FireFox 发请则不会出现。这是因为 Chrome 内置的证书更少吗?

    作者回复: 1.有ticket就不会用id。 2.master secret都保存在两端各自的内存里,不需要,也不允许在网络上传递,两端用id对一下,一致就行了。 3.实验环境的证书是自签名证书,需要提前信任才行,不然就会告警。这个跟浏览器的安全策略有关,可能Firefox的处理逻辑不一样。

    2020-05-05
    2
    2
  • lesserror
    老师,以下问题麻烦请回答一下: 1.客户端有时还会再去访问 CA,下载 CRL 或者 OCSP 数据,这又会产生 DNS 查询、建立连接、收发数据等一系列网络通信,增加好几个 RTT。这个CRL 或者 OCSP是对应到某个网址上面的嘛?客户端根据网址访问? 2.它可以让服务器预先访问 CA 获取 OCSP 响应,然后在握手时随着证书一起发给客户端,免去了客户端连接 CA 服务器查询的时间。这里不是客户端自己去验证的会不会有问题?服务器自己代做了。

    作者回复: 1.crl和ocsp是一个很大的列表,包含所有过期或者作废的证书序列号,不关联到具体的网址。客户端只要在这个列表里查一下证书序列号是否在这里面就行。而证书里面是包含网址的。 2.ocsp都是经过ca签名的,所以不会被窜改,保证肯定是ca发出的。

    2019-12-21
    2
  • ifelse
    good good study,day day up.

    作者回复: nice

    2023-01-31归属地:浙江
    1
  • 路漫漫
    老师,文章里说,这后一次握手的重点是算出主密钥“Master Secret”,而主密钥每次连接都要重新计算,未免有点太浪费了。难道每次连接的主密钥是一样的?不是每次连接的ecdhe的公钥私钥都是不同的吗?怎么还可以缓存呢?

    作者回复: ecdhe的公钥私钥每次都是临时生成的,但它只是用在握手过程中。 而master secret是用在会话过程中的,由client random/server random/pre-master生成的,而这三个都是随机数,所以master secret必然每次都不同。 但算master secret需要握手,成本高,所以为了提高效率,就可以用session id、session ticket来复用,并不是简单的缓存。

    2021-11-23
    1
  • 1:你能比较一下“Session ID”“Session Ticket”“PSK”这三种会话复用手段的异同吗? 1-1:回话复用 核心是缓存主密钥,为啥要缓存?因为计算出主密钥比较费劲,如果能重复利用,重复计算的活就免了,这是在拿空间换时间。 1-2:Session ID 可以认为是缓存主密钥的key,在客户端和服务器都有存储,通过传递这个key来获取和重用主密钥。 缺点是太费服务器的村村资源,因为每一个客户端的回话数据都需要保存,如果客户端有百万甚至千万基本,那存储空间使用的就有些多啦! 1-3:Session ticket 这个方案可以解决服务器存储空间压力山大的问题,核心是把信息放在客户端存储,当然是加密后的信息,服务器侧需要解码后再使用。 1-44:PSK 和Session ticket类似,为了效率加大了一些安全风险,ticket中带上了应用数据的信息,这样能省去服务器的确认步骤。为了加强安全性,使用上做了一些限制。 有此可见,没有完美的解决方案,具体想要什么需要自己权衡对待。想要实现多快好省,那要么是一句口号,要么必须付出其他的代价。 2:你觉得哪些优化手段是你在实际工作中能用到的?应该怎样去用? 软件优化这个估计最常用,也能用到,一些安全漏洞或性能优化常这么玩。

    作者回复: psk理解的稍微有点偏差,ticket里是加密的会话密钥,应用数据在psk后面。

    2020-04-04
    1
  • 书生依旧
    PSK 在发送 Ticket 的同时会带上应用数据,免去了 1.2 里面的服务器确认步骤。 这句话有点不太理解,请问老师: 1. 看图上 pre_shared_key 是在 Hello 中发送的,Session Ticket 也是在 Hello 中发送的吗? 2. 带上应用数据是什么数据? 3. 1.2 里面的服务器验证指的是哪个步骤?

    作者回复: 1.是的,hello消息里有个pre_share_key扩展,就是ticket。 2.在https里应用数据就是http报文了。 3.在tls1.2的会话复用里,必须在服务器发送server hello确认建立加密连接之后才能发送应用数据,而tls1.3就不需要这个确认步骤。

    2019-10-16
    1
收起评论
显示
设置
留言
30
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部