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

针对 SSL 我用了以下优化

• 开启了 http2
• 开启了 ssl_st大带宽服务器apling （ OCSP Stapling ）
• 开启了 ssl_prefer_server_ciphers

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

win? linux?

linux

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

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

可以看一下直接 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 的时间。

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

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




经过实验，我发现**一个 curl 命令跑多个链接**的话，只要在一个会话里面，就可以用 keep-alive 长连接，因此跑了 20 多条数据的总时间换算一下延迟确实是忽略不计的，但是用 postman 点击发送或者 **多个 curl 命令，每个 curl 跑 1 个链接**的话，就没有用到 keep-alive，每个都是单独会话
因此我猜想 ssl 第一次请求都很慢，但是如果是长连接保持，接下来的连接就不用计算证书合法性了，所以还是要在一个会话里才能看出问题。
是否可以这样理解？

有没有套 cdn ？

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

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

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




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

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

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"

几位大佬解释的很清楚，http2 默认开启 keep-alive，还可以查一下多路复用。
也可以尝试一下 http3，使用的 quic 协议，0RTT，在建立连接时性能提升不少

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

这个不错，比我的抓包目测清楚，感谢！
也谢谢你们的建议

@zhuzhibin

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