(Dis-) 使用 HTTP/2 或 HTTP/3 進行後端連接的優勢（反向代理 -> 後端）？
使用 HTTP/2 甚至 HTTP/3 進行反向代理和後端之間的連接有哪些優點和缺點？
我還沒有真正遇到過這種情況，只看到 H2 和 H2 部署在反向代理和 CDN 前面。ASFIK H2 和 H3 通常（H2C 是一回事，對嗎？）需要 TLS，如果您想遠離後端進行 TLS 終止，這將使其不適合。
H2 也可能比基本的 HTTP/1.1 後端更難設置和配置。從好的方面來說，多路復用不是對通過 n 個 TCP 連接獲得的固定並發請求數量的改進，反向代理將為 HTTP/1.1 後端連接打開嗎？
在 CPU、記憶體和 IO 上的負載方面有哪些節省和成本？
有沒有人有這方面的實際經驗？
我在 Stack Overflow上寫了這個答案，它仍然非常相關。
HTTP/2（和 HTTP/3）的好處主要在於前端。您不太可能在後端看到任何真正的、明顯的好處。而且，鑑於這些較新的協議通常缺乏支持，我不會欺騙自己以很少的收穫來啟用它。
一個有趣的點（正如我連結答案底部的編輯所指出的那樣）是在將前端的 HTTP/2（或 3）降級到後端的 HTTP/1.1 時可能出現的安全問題。這些主要是由於 HTTP/1.1 中的問題（2 和 3 旨在解決）和這些邊緣情況的錯誤實現，但它仍然提供了一個充分的理由，盡可能避免使用 HTTP/1.1。
說目前 HTTP/3 肯定是有成本的，我不會在後端推薦它（或者甚至是你設法誠實的前端 - 通過 CDN 使用是恕我直言的方式）。它仍然太新（最終的 RFC 甚至還沒有發布！）而且我們花了數年時間在作業系統和整個網路堆棧中優化 TCP。QUIC 在使用者空間而不是核心中這一事實對未來有很多優勢，但速度和效率並不是其中之一。差距正在縮小（正如Fastly 的這份報告所示），但它仍然存在。
所以一旦 HTTP/2 變得無處不在（這發生的速度比大多數人想像的要快！）我會去做，但我不會在後端強調它（這是值得在前端付出額外努力的事情） ）。HTTP/3 落後了 5 年，才剛剛完成，所以現在更不用說在後端推薦它了。但老實說，我相信 QUIC 和 HTTP/3 將在未來令人興奮，因此絕對值得關注。