HTTP2，NginX但仍然高TTFB

Question

无论我们做出什么改变，TTFB都很高！ 令人惊讶的是，服务器端的人坚持认为一切都设置正确，服务器运行得足够快，但webpagetest报告根本没有变化！ 经过这么多优化后，我无法相信它没有改变，我开始怀疑TLS，gZIP和重定向...... 我错过了什么吗？

Answer 1

看起来页面本身需要大约一秒钟才能生成。这是一个卷曲输出（using this to get timestamps），并注意time_appconnect

的值

$ curl -w "@curl_format.txt" -so /dev/null https://jimmydance.com/
    time_namelookup:  0.004
       time_connect:  0.217
    time_appconnect:  0.921
   time_pretransfer:  0.921
      time_redirect:  0.000
 time_starttransfer:  1.348
                    ----------
         time_total:  1.352

这表明瓶颈是生成页面的应用程序。查看页面本身，它不应该花这么长时间，我会查看您正在使用的框架或分配给服务器的资源。

Answer 2

使用@ frederik-deweerdt的答案和breakdown of curl timing figures

• 您的服务器花费了将近1秒的时间进行TLS握手（time_appconnect: 0.921）
• TTFB 是time_starttransfer - time_appconnect (1.348 - 0.921 = 0.427)
• 服务器用于生成html的时间为TTFB - (time_connect - time_namelookup) (0.427 - (0.217 - 0.004)) = 0.214

所以我要说的瓶颈不是应用程序，而是服务器的TLS协商缓慢以及网络中的某些延迟。

在这里查看这些卷曲时间图形的详细说明：https://blog.cloudflare.com/a-question-of-timing/

  

下图显示了针对典型的TLS 1.2连接上的HTTP（TLS 1.3设置需要少一趟往返路程）时，每个时序所涉及的内容：

     

     

  在此示例中，
• time_namelookup 需要很长时间。要从图中排除DNS解析器的性能，您可以解析cURL的IP：--resolve www.zasag.mn:443:218.100.84.167。寻找更快的解析器也可能是值得的：）。
  从客户端的角度来看，
• time_connect 是TCP三向握手。它在客户端发送ACK之后立即结束-不包括该ACK到达服务器所花费的时间。它应接近服务器的往返时间（RTT）。在此示例中，RTT大约为200毫秒。
  
• time_appconnect 这是TLS设置。然后，客户端就可以发送其HTTP GET请求了。
  
• time_starttransfer 就在cURL从网络读取第一个字节之前（它实际上尚未读取）。 time_starttransfer - time_appconnect实际上与来自此客户端的第一个字节的时间（TTFB）相同-在此示例情况下为250毫秒。这包括通过网络的往返行程，因此您可以通过计算TTFB-（time_connect - time_namelookup来更好地猜测服务器在请求上花费了多长时间，因此在这种情况下，服务器仅花费了几毫秒的时间进行响应，其余时间是网络。   time_total刚好在客户端发送FIN连接断开之后。