请问一般开启 HTTPS 延迟增加多少正常?
现在机器无负载,访问相同接口,http 方式为 60ms ~ 80ms,https 方式 140ms ~ 160ms,我个人觉得性能下降挺厉害的,这样算是正常水平么?还是有一些优化我没做的?
针对 SSL 我用了以下优化
- 开启了 http2
- 开启了 ssl_stapling ( OCSP Stapling )
- 开启了 ssl_prefer_server_ciphers
但是感觉作用都不是很明显,各位大佬可以告知一下方向么?
现在机器无负载,访问相同接口,http 方式为 60ms ~ 80ms,https 方式 140ms ~ 160ms,我个人觉得性能下降挺厉害的,这样算是正常水平么?还是有一些优化我没做的?
针对 SSL 我用了以下优化
但是感觉作用都不是很明显,各位大佬可以告知一下方向么?
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 的时间。
经过实验,我发现**一个 curl 命令跑多个链接**的话,只要在一个会话里面,就可以用 keep-alive 长连接,因此跑了 20 多条数据的总时间换算一下延迟确实是忽略不计的,但是用 postman 点击发送或者 **多个 curl 命令,每个 curl 跑 1 个链接**的话,就没有用到 keep-alive,每个都是单独会话
因此我猜想 ssl 第一次请求都很慢,但是如果是长连接保持,接下来的连接就不用计算证书合法性了,所以还是要在一个会话里才能看出问题。
是否可以这样理解?
感谢这么晚回复,我要睡了,你们也早点睡吧,谢谢各位指导!!!
也可以尝试一下 http3,使用的 quic 协议,0RTT,在建立连接时性能提升不少
也谢谢你们的建议
@louiswang002
@zhuzhibin