我正在使用微服務架構，其中一個服務一次呼叫多個服務，服務器在 nodejs
我計劃將 HTTP2 用于從一項服務到另一項服務的 API 呼叫，因為它僅使用一個帶有標頭壓縮的 TCP 連接。
但是，HTTP2 需要 TLS 支持，這意味著服務向其他人發出的每個 API 呼叫都要進行 TLS 握手，從而增加了往返開銷。
盡管 TLS1.3 只需要一次往返，但它仍然會增加一些額外的開銷時間。
我的問題是，首先使用 HTTP2 進行從一個服務到另一個服務的 API 呼叫是個好主意，還是繼續使用 HTTP1.1 更好
uj5u.com熱心網友回復：
HTTP2 很可能不會比普通的 HTTP1.1 性能更高。只有在 HTTPS 和并行請求的背景關系中比較它們時才會更快。HTTP2 允許重復使用相同的 TLS 握手，以及對多個并行請求（多路復用）使用相同的連接。
這就是你不會在 nginx 和你的應用服務器之間設定HTTP2的原因——因為你通常不需要它們之間的 TLS。因此，除非 a) 您需要在服務之間建立安全連接，并且 b) 您計劃發出并行請求 - 使用 HTTP2 進行服務到服務通信似乎沒有意義。
PS：另請閱讀@sbordet 的答案 - 即使沒有 TLS，HTTP2 似乎也有好處。
uj5u.com熱心網友回復：
HTTP/2 不需要 TLS 支持。
碰巧所有瀏覽器供應商（而且只有他們）決定不支持明文 HTTP/2，但其他客戶端（如curl、Java 客戶端等）確實支持明文 HTTP/2。
但是，對于服務器到服務器的通信，可以使用明文 HTTP/2，實際上這是一種非常常見的部署。
不幸的是，用作反向代理或負載平衡器的流行服務器不支持使用 HTTP/2 呼叫后端，但這只是一個實作限制。
例如， HAProxy允許卸載 TLS，然后使用明文 HTTP/2 呼叫后端。
如果你在前端收到很多多路復用的請求，你可以在后端利用 HTTP/2 多路復用，節省大量資源。向前端請求 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（主要是出于非技術原因），所以大多數時候你只需要放棄并部署次優系統。
轉載請註明出處，本文鏈接：https://www.uj5u.com/qukuanlian/410950.html
標籤：
上一篇：超出自簽名證書路徑約束