HTTP2和NGINX - 何時使用keepalive指令？

Question

我正在嘗試遷移到http / 2。 我已經設置了一個Wordpress網站並配置了NGINX來使用http / 2（使用SSL / TLS）來提供服務。

我對http / 2的理解是，默認情況下，它使用一個連接來傳輸大量文件 - 而不是打開新連接並為每個文件重復SSL握手。

為了達到類似http / 1.x的效果，NGINX提供了keepalive指令。

那么在使用http / 2時使用keepalive指令是否有意義？ 使用“nginx -t”檢查我的配置文件時，如果包含它，則報告沒有錯誤。 但它有什么影響嗎？ 基准測試顯示沒有差異。

Answer 1

你誤解了它是如何工作的。

保持Alive 在請求之間的工作。

下載網頁時，它會下載HTML頁面並發現它需要另外20個資源（CSS文件，javascript文件，圖像，字體......等）。

在HTTP / 1.1下，您只能同時請求其中一個資源，因此通常Web瀏覽器會激活另外5個連接（總共提供6個連接）並請求這20個資源中的6個。 然后，當這些連接釋放時，它會請求剩余的14個資源。 是的，在這些請求之間保持聯系，但這不是它的唯一用途，我們將在下面討論。 設置這些連接的開銷很小但很明顯，並且只能一次請求這20個資源中的6個資源。 這就是為什么HTTP / 1.1對於今天使用網絡來說效率低的原因，其中典型的網頁由100個資源組成。

在HTTP / 2下，我們可以在同一個連接上同時觸發所有20個請求，因此可以獲得一些好處。 從技術上講，你並沒有真正受益於那些之間的保持活動，因為連接仍在使用，直到它們全部到達 - 盡管仍然受益於第一個HTML請求和其他20個請求之間的小延遲。

但是，在初始加載之后，可能會有更多請求。 要么是因為您正在瀏覽網站，要么是因為您與該頁面進行了交互，而且它會增加XHR api調用。 無論是在HTTP / 1.1還是HTTP / 2上，這些都將受益於保持活動。

所以HTTP / 2並不否定對保持活動的需求。 它不需要多個連接（除其他外）。

所以答案是始終使用keep-alives，除非你有充分的理由不這樣做。 您正在做什么類型的基准測試來說它沒有區別？