1103更新，为避免对大家造成困惑，姑且先澄清一下。
握手包过大的ssl证书确实会对握手效率造成负面影响，但讲道理只影响握手，不影响后续请求。
我们目前遇到的问题似乎已经不是证书范围了，是经过反代之后使用免费证书的服务整体都慢。
但奇怪的现象请参见附图。。

--------------------------
最近留意到使用ZeroSSL证书的新网站响应延时很严重，粗略看了一下高达450ms以上。
一开始以为是nginx反代的问题，换成haproxy也好不到哪儿去，依然高达400ms以上。
curl -w "TCP handshake: %{time_connect}, SSL handshake: %{time_appconnect}\n" -so /dev/null https://foo.net
TCP handshake: 0.276897, SSL handshake: 0.293364
TCP握手和SSL握手都接近300ms，HTTP无此问题，猜测是SSL证书导致的。
使用https://www.wormly.com/test_ssl/ 测试看到一个警告：
SSL Handshake Size        5257 bytes    The amount of data exchanged to establish a session with this server is large. This will result in a slower initial connection.

Using a certificate with fewer intermediate chains and / or a smaller public key size can reduce the amount of data.
----------------
TLS / SSL Handshake Size
Context: The Wormly SSL Tester reports the size of an SSL handshake with your HTTPS server.

One aspect which can have a significant impact on the perceived performance of your web secure server is the amount of data transfer required to establish a SSL/TLS session.

The Wormly SSL Tester reports the size of the initial handshake; and a payload of around 4kB seems to be fairly typical.

Whilst 4kB may not seem like much in an era of broadband connections, it’s important to remember that the slow start algorithm is employed by the TCP protocol.

If the size of the certificate payload exceeds the initial congestion window, then the server will have to wait until the client acknowledges receipt of the packets already sent before resuming transmission.

The practical upshot of this is increased round-trips incurred before the session is established; which results in a slower connection experience for the end user.

By minimizing the size of your servers’ certificate chain, you can reduce the likelihood of overflowing the initial congestion window and improving connection performance.
------------------

测了一下ZeroSSL的证书，SSL Handshake Size超过5K，证书链4层。。
R3证书稍微小一点，也接近5K，证书链3层（不能再短了）。。

大家有没有留意到这个问题呢？不知道怎样解决？
--
修改:i00i FROM 120.245.128.*
FROM 120.245.128.*

目前主流都是RSA2048吧。。
我测试了jd和taobao，他们的证书也超过4k，不过他们只是握手慢，实际访问体验并不慢，
而我这是每次请求都慢，明显感觉慢半拍。。
相同的haproxy配置，前几年也是letsencrypt，并没有慢的现象，就是这两年才感觉慢的。

【 在 oldwatch 的大作中提到: 】
: 这证书里都塞了啥玩意进去？
: 正常不就是几个属性字符串么，能塞到5k？
: 里头写了篇备忘录么？
: ...................
--
FROM 120.245.128.*

换ECDSA
--
FROM 101.24.92.*

我测试我的网站的结果
TCP handshake: 0.006, SSL handshake: 0.124

测试你这个foo.net的结果
TCP handshake: 0.055, SSL handshake: 0.272
感觉这个跟网速有关吧。

【 在 i00i 的大作中提到: 】
: 最近留意到使用ZeroSSL证书的新网站响应延时很严重，粗略看了一下高达450ms以上。
: 一开始以为是nginx反代的问题，换成haproxy也好不到哪儿去，依然高达400ms以上。
: curl -w "TCP handshake: %{time_connect}, SSL handshake: %{time_appconnect}\n" -so /dev/null https://foo.net
: ...................
--
FROM 202.98.17.*

服务端开启tls1.3，浏览器可以缓存session ticket，第二次访问会复用上次协商的密钥，避免完全握手，延迟会有很大改善。
  
【 在 i00i (烟灰·独孤求胖) 的大作中提到: 】
:  最近留意到使用ZeroSSL证书的新网站响应延时很严重，粗略看了一下高达450ms以上。
:  一开始以为是nginx反代的问题，换成haproxy也好不到哪儿去，依然高达400ms以上。
:  curl -w "TCP handshake: %{time_connect}, SSL handshake: %{time_appconnect}\n" -so /dev/null https://foo.net
:  TCP handshake: 0.276897, SSL handshake: 0.293364
--
FROM 197.156.88.*