请问一般开启 HTTPS 延迟增加多少正常？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

› DigitalOcean

这是一个创建于 1365 天前的主题，其中的信息可能已经有所发展或是发生改变。

现在机器无负载，访问相同接口，http 方式为 60ms ～ 80ms，https 方式 140ms ～ 160ms，我个人觉得性能下降挺厉害的，这样算是正常水平么？还是有一些优化我没做的？

针对 SSL 我用了以下优化

开启了 http2
开启了 ssl_stapling （ OCSP Stapling ）
开启了 ssl_prefer_server_ciphers

但是感觉作用都不是很明显，各位大佬可以告知一下方向么？

第 1 条附言 · 2021-02-28 00:33:17 +08:00

服务器是 Linux + Nginx
测试方法是在 Postman 连续点击 Send 按钮，查看请求成功后的延迟时间

第 2 条附言 · 2021-02-28 14:28:07 +08:00

附加一个大佬提供测算延迟的好方法，我又稍微修改了一下，用 http code 代替 curl 输出的内容，输出看起来更简洁了，希望能帮助到检索到这个帖子的人

```
curl -X GET -w "\nhttp_code: "%{http_code}", ndns_resolution: %{time_namelookup}, tcp_established: %{time_connect}, ssl_handshake_done: %{time_appconnect}, TTFB: %{time_starttransfer}, total: %{time_total}\n" \
-o /dev/null "https://www.qq.com" \
-o /dev/null "https://www.qq.com" \
-o /dev/null "https://www.qq.com" \
-o /dev/null "https://www.taobao.com" \
-o /dev/null "https://www.baidu.com"
```

开启

OCSP

SSL

stapling

19 条回复 • 2021-04-06 20:57:35 +08:00

dzdh

2021-02-28 00:05:30 +08:00

win? linux?

Phishion

2021-02-28 00:16:59 +08:00

@dzdh linux

keyfunc

2021-02-28 00:22:20 +08:00

开启 HTTPS 后客户端与服务器第一次通讯会增加延迟的，具体多少不好说，但单独测一次访问的延迟其实没太大意义，加点并发和多次访问，看看效果，H2 的特征对性能提升效果听明显的。

Phishion

2021-02-28 00:25:21 +08:00

@keyfunc 我用 postman 连续点击的 send，延迟就是上面的延迟，还是说我每次点击 send 都算单独的一次访问？

Zhuzhuchenyan

2021-02-28 01:42:37 +08:00

可以看一下直接 ping 机器的延迟是多少，或者 tcp ping 一下了解一下平均 RTT 是多少，开启 HTTPS 加密带来的性能损失和网络延迟相比可以先忽略

HTTP 理想情况下只需要一次 RTT 的时间就可以发送数据，
HTTPS 理想情况下则多得多，TLS1.2 需要 4 个 RTT 时间，TLS1.3 需要 3 个 RTT 时间。

所以如果本身延迟就很高，那么开启 HTTPS 带来的延迟增长的确也会很高。

是否开启 HTTP2 对解决这个问题没啥帮助，但是对于网站的基准性能会有比较大的提升。
ssl_prefer_server_ciphers 这个选项只是推荐客户端选定你指定的 cipher，毕竟某些 cipher 过时，慢，并且有可能不安全
如果你的证书的 OCSP 服务器没有被墙，那么是否开启 ssl_stapling 对这个问题没有帮助。

我才疏学浅，唯一能建议的是开启 ssl session 重用，SSL-Session-Cache，这个能帮你节省 1 个 RTT 的时间。

watzds

2021-02-28 01:43:45 +08:00 via Android

用长连接，否则网络延迟增加两三倍很正常

Phishion

2021-02-28 02:12:25 +08:00

@Zhuzhuchenyan @watzds 感谢那么晚回复，我服务器在某大厂云的香港服务器，ping 也就 40ms 左右，我在想总不能开启 https 能增加 90ms 延迟，要么我的 postman 点击按钮的验证延迟的测算方法有问题，要么就是配置上的问题，
@watzds 我抓包看 Header Connection: keep-alive 都是默认开启的

Phishion

2021-02-28 02:49:00 +08:00

@keyfunc
@Zhuzhuchenyan
@watzds

经过实验，我发现**一个 curl 命令跑多个链接**的话，只要在一个会话里面，就可以用 keep-alive 长连接，因此跑了 20 多条数据的总时间换算一下延迟确实是忽略不计的，但是用 postman 点击发送或者 **多个 curl 命令，每个 curl 跑 1 个链接**的话，就没有用到 keep-alive，每个都是单独会话

因此我猜想 ssl 第一次请求都很慢，但是如果是长连接保持，接下来的连接就不用计算证书合法性了，所以还是要在一个会话里才能看出问题。

是否可以这样理解？

MeteorCat

2021-02-28 02:50:21 +08:00 via Android

有没有套 cdn ？

lostberryzz

2021-02-28 02:51:51 +08:00

TTFB 需要 4.5 个 RTT，也就是 9x 延迟

Phishion

2021-02-28 02:55:40 +08:00

@MeteorCat 套了 cdn，不过我本地修改 hosts 直连的服务器，跟 cdn 没关系，cdn 大概会在原有延迟数字上加 60ms 吧

unixeno

2021-02-28 02:58:28 +08:00 via Android

@Phishion 基本没啥问题，延迟的增加主要就是 ssl 握手产生的，如果重用连接，不仅没有 ssl 握手的开销，也没有 tcp 握手的开销
你可以试一下用浏览器的开发者工具，里面可以看到每个请求的连接建立时间和实际接收数据的时间之类的数据

Phishion

2021-02-28 03:02:57 +08:00

@MeteorCat
@lostberryzz
@unixeno

感谢这么晚回复，我要睡了，你们也早点睡吧，谢谢各位指导！！！

watzds

2021-02-28 10:43:51 +08:00 via Android

@Phishion 另外 curl 测试的话还有启动时间开销，我一般是 www.baidu.com test.com test.com

watzds

2021-02-28 10:50:29 +08:00 via Android

@Phishion curl -X POST -w "\ndns_resolution: %{time_namelookup}, tcp_established: %{time_connect}, ssl_handshake_done: %{time_appconnect}, TTFB: %{time_starttransfer}, total: %{time_total}\n" -s "https://www.baidu.com" "https://test.com" "https://test.com"

louiswang002

2021-02-28 11:10:13 +08:00 via iPhone

@Phishion 几位大佬解释的很清楚，http2 默认开启 keep-alive，还可以查一下多路复用。

也可以尝试一下 http3，使用的 quic 协议，0RTT，在建立连接时性能提升不少

zhuzhibin

2021-02-28 11:18:23 +08:00 via iPhone

ssl 开销挺大的可以做个压测就知道了

Phishion

2021-02-28 11:27:48 +08:00

@watzds 这个不错，比我的抓包目测清楚，感谢！

也谢谢你们的建议
@louiswang002
@zhuzhibin

panwork

2021-04-06 20:57:35 +08:00

@louiswang002 目前 http3 几乎还没办法用吧，各种不兼容