透视HTTP协议
罗剑锋(Chrono)
奇虎360技术专家,Nginx/OpenResty开源项目贡献者
立即订阅
6077 人已学习
课程目录
已完结 44 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词|To Be a HTTP Hero
免费
破冰篇 (7讲)
01 | 时势与英雄:HTTP的前世今生
02 | HTTP是什么?HTTP又不是什么?
03 | HTTP世界全览(上):与HTTP相关的各种概念
04 | HTTP世界全览(下):与HTTP相关的各种协议
05 | 常说的“四层”和“七层”到底是什么?“五层”“六层”哪去了?
06 | 域名里有哪些门道?
07 | 自己动手,搭建HTTP实验环境
基础篇 (7讲)
08 | 键入网址再按下回车,后面究竟发生了什么?
09 | HTTP报文是什么样子的?
10 | 应该如何理解请求方法?
11 | 你能写出正确的网址吗?
12 | 响应状态码该怎么用?
13 | HTTP有哪些特点?
14 | HTTP有哪些优点?又有哪些缺点?
进阶篇 (8讲)
15 | 海纳百川:HTTP的实体数据
16 | 把大象装进冰箱:HTTP传输大文件的方法
17 | 排队也要讲效率:HTTP的连接管理
18 | 四通八达:HTTP的重定向和跳转
19 | 让我知道你是谁:HTTP的Cookie机制
20 | 生鲜速递:HTTP的缓存控制
21 | 良心中间商:HTTP的代理服务
22 | 冷链周转:HTTP的缓存代理
安全篇 (7讲)
23 | HTTPS是什么?SSL/TLS又是什么?
24 | 固若金汤的根本(上):对称加密与非对称加密
25 | 固若金汤的根本(下):数字签名与证书
26 | 信任始于握手:TLS1.2连接过程解析
27 | 更好更快的握手:TLS1.3特性解析
28 | 连接太慢该怎么办:HTTPS的优化
29 | 我应该迁移到HTTPS吗?
飞翔篇 (4讲)
30 | 时代之风(上):HTTP/2特性概览
31 | 时代之风(下):HTTP/2内核剖析
32 | 未来之路:HTTP/3展望
33 | 我应该迁移到HTTP/2吗?
探索篇 (5讲)
34 | Nginx:高性能的Web服务器
35 | OpenResty:更灵活的Web服务器
36 | WAF:保护我们的网络服务
37 | CDN:加速我们的网络服务
38 | WebSocket:沙盒里的TCP
总结篇 (2讲)
39 | HTTP性能优化面面观(上)
40 | HTTP性能优化面面观(下)
答疑篇 (2讲)
41 | Linux/Mac实验环境搭建与URI查询参数
42 | DHE/ECDHE算法的原理
结束语 (1讲)
结束语 | 做兴趣使然的Hero
透视HTTP协议
登录|注册

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

Chrono 2019-07-31
你可能或多或少听别人说过,“HTTPS 的连接很慢”。那么“慢”的原因是什么呢?
通过前两讲的学习,你可以看到,HTTPS 连接大致上可以划分为两个部分,第一个是建立连接时的非对称加密握手,第二个是握手后的对称加密报文传输
由于目前流行的 AES、ChaCha20 性能都很好,还有硬件优化,报文传输的性能损耗可以说是非常地小,小到几乎可以忽略不计了。所以,通常所说的“HTTPS 连接慢”指的就是刚开始建立连接的那段时间。
在 TCP 建连之后,正式数据传输之前,HTTPS 比 HTTP 增加了一个 TLS 握手的步骤,这个步骤最长可以花费两个消息往返,也就是 2-RTT。而且在握手消息的网络耗时之外,还会有其他的一些“隐形”消耗,比如:
产生用于密钥交换的临时公私钥对(ECDHE);
验证证书时访问 CA 获取 CRL 或者 OCSP;
非对称加密解密处理“Pre-Master”。
在最差的情况下,也就是不做任何的优化措施,HTTPS 建立连接可能会比 HTTP 慢上几百毫秒甚至几秒,这其中既有网络耗时,也有计算耗时,就会让人产生“打开一个 HTTPS 网站好慢啊”的感觉。
不过刚才说的情况早就是“过去时”了,现在已经有了很多行之有效的 HTTPS 优化手段,运用得好可以把连接的额外耗时降低到几十毫秒甚至是“零”。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《透视HTTP协议》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(10)

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

    作者回复: psk实际上是Session Ticket的强化版,本身也是缓存,但它简化了Session Ticket的协商过程,省掉了一次RTT。

    多在实践中学,多看些开源项目,就能逐渐掌握了。

    2019-07-31
    1
    4
  • Fstar
    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
    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
  • Luke
    老是,如果使用服务器集群来做专门的加解密运算,建立TSL链接时,客户端将数据发送给服务器集群计算密钥,服务端又是如何安全的将密钥返回?或者是在解密报文时,又如何将解密后的报文安全返回?

    作者回复: 由于都是内网,所以就不存在外网那么多的威胁,所以可以直接通信,无需其他安全手段。

    2019-08-30
    1
  • 一坛幽梦
    客户端再次访问的时候会携带session ticket,服务器解密后验证有效期,就可以恢复会话,开始加密通信;关于这句话,服务器解密后只是验证ticket的有效期吗?session ticket用于加密会话信息,如果不做其它验证,是怎么确定客户端的身份呢?

    作者回复: 除了有效期,ticket里还存有加密后的会话密钥,具体的内容在课程里没有详细介绍,你可以参考rfc。

    2019-08-18
  • 丶景
    老师好,问下使用了 OCSP Stapling 那客户端是不是就不要去 CA 验证证书了,那会不会导致不安全呢。

    作者回复: OCSP Stapling实际上是把请求CA验证证书有效性的过程由客户端转移到了服务器,它的本质没有变化,所以仍然是安全的。

    至于为什么安全,这就要去细看它的协议和数据格式了,不过一般不用关心这些细节。

    2019-08-02
  • 许童童
    老师你好,预共享密钥的0-RTT不是真的0-RTT吧。

    作者回复: 当然是0-rtt,不过是指在建立tcp连接后的0-rtt,也就是tcp握手之后立即发送应用数据,不需要再次tls握手。

    2019-07-31
  • 许童童
    老师你好,有什么好办法可以有效监控和调优Https连接建立的具体时间吗?

    作者回复: 可以看Chrome的开发者工具,每个uri的timing页里会有详细的延迟分布。

    2019-07-31
  • Geek_43174f
    你好,有个问题想请教一下,线上的项目,一个是生产环境,一个是测试环境,我在同一个浏览器上进行访问这两个环境,当我从测试上切换到生产上之后,生产环境需要重新进行登录,而且当我从生产上切换到测试上之后也需要进行登录,点击登录之后就报400错误,而且接口调用也改变了

    作者回复: 可以先用wireshark抓包看看,传输的数据有什么变化,是不是带上了cookie。

    2019-07-31
  • Leon📷
    TCP fast open开启算不算优化呢

    作者回复: 也算,不过属于tcp优化,不属于https优化。

    2019-07-31
收起评论
10
返回
顶部