HTTP2，NginX，但TTFB仍然很高

Question

無論我們對TTFB進行了哪些更改，它都是很高的！ 令人驚訝的是，服務器端人員堅持認為一切設置正確，服務器運行速度足夠快，但是webpagetest報告完全沒有改變！ 經過如此多的優化，我無法相信它不會改變，並且我開始懷疑TLS，gZIP和重定向……我錯過了什么嗎？

Answer 1

看起來頁面本身大約需要一秒鍾的時間來生成。 這是curl輸出（ 使用它來獲取時間戳 ），並注意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的答案和卷曲時間數字的細分

• 您的服務器花費了將近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毫秒。 這包括通過網絡的往返，因此您可以通過計算time_connect - time_namelookup （ time_connect - time_namelookup ）更好地猜測服務器在請求上花費了多長時間，因此在這種情況下，服務器僅花費了幾毫秒的響應時間，其余時間是網絡。 time_total剛好在客戶端發送FIN連接斷開之后。