HTTP2：內部服務 API 是否應該使用 http2

Question

我正在使用微服務架構，其中一個服務一次調用多個服務，服務器在 nodejs

我計划將 HTTP2 用於從一個服務到另一個服務的 API 調用，因為它僅使用一個 TCP 連接和 header 壓縮。

但是，HTTP2 需要 TLS 支持，這意味着服務向其他人發出的每個 API 調用都要進行 TLS 握手，從而增加了往返開銷。

盡管 TLS1.3 只需要一次往返，但它仍然會增加一些額外的開銷時間。

我的問題是，對於從一個服務到另一個服務的 API 調用，首先使用 HTTP2 是個好主意，還是繼續使用 HTTP1.1 更好

Answer 1

HTTP2 很可能不會比普通的 HTTP1.1 性能更高。 只有在 HTTPS 和並行請求的上下文中比較它們時才會更快。 HTTP2 允許重復使用相同的 TLS 握手，以及對多個並行請求（多路復用）使用相同的連接。

這就是您不會在 nginx 和您的應用服務器之間設置 HTTP2的原因 - 因為您通常不需要它們之間的 TLS。 因此，除非 a) 您需要在服務之間建立安全連接，並且 b) 您計划發出並行請求 - 使用 HTTP2 進行服務到服務通信似乎沒有意義。

Answer 2

HTTP/2 不需要 TLS 支持。

碰巧所有瀏覽器供應商（而且只有他們）決定不支持明文 HTTP/2，但其他客戶端（例如curl或 Java 客戶端等）確實支持明文 HTTP/2。

但是，對於服務器到服務器的通信，可以使用明文 HTTP/2，實際上這是一種非常常見的部署。

不幸的是，用作反向代理或負載均衡器的流行服務器不支持使用 HTTP/2 調用后端，但這只是一個實現限制。

例如， HAProxy允許卸載 TLS，然后使用明文 HTTP/2 調用后端。

如果你在前端收到很多多路復用的請求，你可以在后端利用 HTTP/2 多路復用，節省大量資源。 一個 web 頁面請求說 30 個多路復用資源到前端，在使用 HTTP/1 時需要打開或以其他方式使用 30 個到后端的不同連接（或更少的連接並且效率較低），而在使用時僅使用 1 個HTTP/2。 在后端使用 HTTP/2 時，您不僅限於 1 個連接，就像使用 HTTP/1 時不限於僅使用 6 個連接一樣（這些只是瀏覽器限制，不適用於 server-to -服務器通信）。

此外，使用 HTTP/2 功能（例如 HTTP/2 推送）的后端應用程序（盡管現在正在逐步淘汰）將使用純 HTTP/2 通信透明地工作，而在使用時將無法使用 HTTP/2 功能面向后端的 HTTP/1 通信。 對於任何其他 HTTP/2 功能（例如 PING 幀、SETTINGS 幀等）都是如此。在使用 HTTP/1 與后端應用程序通信時，所有這些功能都會丟失。

從資源的角度來看，智能反向代理或負載均衡器可以卸載 TLS，然后盲目地將 HTTP/2 明文字節轉發到后端——無需解釋任一方向的字節。 在接收到 HTTP/1 響應（從 HTTP/1 到 HTTP/2）時，不需要解析 HTTP/2 請求，將其轉換為 HTTP/1 格式，反之亦然。 這會導致不必要的 CPU 燒毀和 TCP 連接使用。

因此，原則上 HTTP/2 面向后端是非常可取的。

我曾使用過集群系統，其中用於服務器到服務器通信的 HTTP/2 是一個巨大的好處，只是因為整個集群使用的資源更少。

然而，現實情況是，最流行的前端服務器不支持后端的 HTTP/2（主要是出於非技術原因），所以大多數時候你只需要放棄並部署次優系統。