為什麼在 Apache 上創建新的 TCP 會話時，請求的 TTFB 長 5 倍？

在對使用 提供的圖像進行測試時apache，我注意到創建新會話時：

Waiting (TTFB): 1.09s Initial connection + SSL handshake: 370ms DNS Lookup: 165ms

但隨後使用持久連接：

Waiting (TTFB): 187ms Content Download: 4ms

因此，我們發現TTFB新連接的平均時間是非持久連接的 5 倍。這是正常的嗎？

附帶問題：為什麼只有在有新連接時才進行新的 DNS 查找？

是的，非持久連接需要更長的時間來發送數據的第一個字節是正常的。

這是因為必須從 DNS 解析 IP 地址，必須建立 TCP 連接，然後必須初始化 SSL/TLS 層，然後才能發送實際數據。

DNS 查找不會在持久連接上執行，因為客戶端和伺服器 IP 地址之間已經存在活動的 TCP 連接，因此無需將域名解析為 IP 地址。

關於 ApacheKeepAlive和KeepAliveTimeout指令。KeepAlive指定 Apache 是否應為後續對同一站點上其他資源的請求保持客戶端連接打開。這些是持久連接，可以避免前面提到的延遲。

但是，保持連接活動使用伺服器上的資源，因為每個 TCP 連接都需要記憶體來維持狀態。因此，使用KeepAliveTimeout指令可以指定空閒連接在 Web 伺服器關閉之前保持打開多長時間。這也使得惡意客戶端更難通過打開 HTTP 連接並無限期地保持它們打開來耗盡伺服器資源。

MaxKeepaliveRequests表示每個 KeepAlive 連接允許多少個請求。我無法想像人們想要限制請求數量的情況。為了獲得最佳性能，我會使用0，即無限數量的請求。

這些指令與訪問者和 Web 伺服器之間的 HTTP(S) 會話有關。PHP-FPM 與此介面無關。然而，在 FastCGI 介面的 nginx 中也有類似的 keepalive 機制。我不知道 Apache 中是否有類似的機制。

引用自：https://serverfault.com/questions/802596