HTTP/2逐跳流量控制是如何完成的？

Question

由於spec說：

流量控制是具體到一個連接。兩種類型的流量控制 都在單跳的端點之間，而不是整個端點到端路徑的整個 。

而且在6.9 WINDOW_UPDATE

兩種類型的流量控制是逐跳，也就是說，只有 兩個端點之間。 中介機構不會在相關連接之間轉發WINDOW_UPDATE幀 。但是，任何接收器都可以間接地引起流量控制信息向原始發送者的傳播。

但這怎麼可能？現在看來，這要求所有的中介機構瞭解h2或h2c協議，我有兩個問題：

1. HTTP/2是一個相對較新的標準，我見過很多網站已啓用它（我的博客包括在內）。雖然我可以毫無問題地訪問這些網站，但這是否意味着像路由器和集線器之類的每個中間設備都已經實現了自己的HTTP/2堆棧和流量控制算法（因爲RFC7540沒有規定流量控制算法）？

2. 大多數網站使用h2而不是h2c，它加密應用程序層數據。 HTTP/2的流量控制由發送WINDOW_UPDATE幀的接收器完成，該幀也是應用層數據，那麼中間設備如何知道這些數據是什麼？如果他們不能解密數據並看到Window Size Increment部分，他們如何完成流量控制而不轉發WINDOW_UPDATE幀？

Answer 1

首先，一些更正。

令牌h2c引用明文HTTP/2（因此c在h2c）。在你的第二個項目符號中，你說大多數網站都使用它，但實際上很少有這樣做，因爲瀏覽器沒有實現它。絕大多數網站使用h2。

令牌h2是指經過TLS加密的h2c或等效的h2c。

當客戶端和服務器協商發言h2時，客戶端發送的字節將被加密，並會一路傳輸到服務器。這意味着中介機構沒有機會解密流量（謝謝）。

在這種情況下，HTTP/2規範所指的「跳躍」是位於客戶端和服務器之間的整個網段。

但是，HTTP/2規範需要是通用的，而不必擔心瀏覽器和Web服務器在定義諸如HTTP/2之類的有線協議時如何進行交互。

想象其中客戶端執行的HTTP/2請求使用h2 的情況，並需要調用server2使用h2c以完成該請求，這一次。例如，可能是一個前端「代理」，根據某些邏輯將請求轉發到「右側」後端服務器。

在這種情況下，您有2跳：client-server1和server1-server2。

每一跳都應用自己的流量控制。

例如，想象客戶端將大文件上載到服務器。 通常，客戶端流量控制發送窗口很小，比如默認的65535個八位字節。在停止上傳之前，客戶端最多隻能發送65535個八位字節。

這些65535個八比特組是由收到的。現在成爲客戶端以便與server2進行通信。假設的客戶端在與server2進行通信時配置了更小的流量控制窗口，例如16384個八比特組。

在這個例子中，檔上載至server2後16384個八位位組，而且必須設法保持周圍的剩餘八位位組65535-16384等待server2通知（經由WINDOW_UPDATE幀），其上載的數據已經被消耗掉。

當的客戶端收到從server2的WINDOW_UPDATE時，它可以發送更多的數據到server2;還需要決定是否向客戶端發送一個WINDOW_UPDATE消息（因爲其流量控制窗口與客戶端現在有額外的16384個八比特組的空間）或者稍微等一會兒。例如，它可以發送另外的16384個八位字節到server2，並且只有在從server2接收到第二個WINDOW_UPDATE時纔可以決定向客戶端發送WINDOW_UPDATE（具有16384 + 16384個八比特組的更新）。

從上面的示例中可以看出，客戶端和之間的流量控制與和server2之間的流量控制有關但獨立。

您可能還想閱讀this answer，以獲得有關流量控制策略實施的討論。

Answer 2

這取決於啤酒花/媒介的含義。

如果中間層位於較低層（TCP網關，NAT，交換機等），那麼它們對於HTTP/2是透明的，因爲HTTP/2流控制在HTTP/2之間端到端地應用客戶端和服務器。它們之間的單個跳數可能使用較低級別的流量控制機制。

如果您的中介是一個HTTP代理，那麼基本上有兩個分開的HTTP請求正在進行，每個應用都使用它自己的流量控制。代理應用程序有責任在保留流量控制屬性的同時連接這些單個躍點。例如。通過不一次讀取來自第二跳的整個響應，並且僅通過流式傳輸合適的數據塊纔將其轉發到第一跳。

在HTTP代理的情況下，您甚至會遇到將HTTP/1.1代理爲HTTP/2並以其他方式代理的情況。在這些情況下，代理將使用HTTP/2流量控制機制來保證該跳的流量控制，並使用TCP流量控制來提供另一跳上的流量控制。如果協議類型被正確地封裝在代理應用程序中（這意味着它將提供關於Request和Response類型的流控制的流傳輸操作），那麼代理不同協議類型之間的流應該不會太難。