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

Question

正如規范所說：

流控制特定於連接。 兩種類型的流控制都在單跳的端點之間，而不是在整個端到端路徑上。

並在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指的是加密的h2c或等效於TLS的h2c 。

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

在這種情況下，HTTP / 2規范所指的“躍點”是客戶端和服務器之間的整個網絡段。

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

想象一下這樣一種情況，客戶端使用h2向server1執行HTTP / 2請求，而server1需要調用server2來滿足該請求，這次是使用h2c 。 例如， server1可以是前端“代理”，它根據某些邏輯將請求轉發到“右”后端服務器。

在這種情況下，您有2個躍點：c​​lient-server1和server1-server2。

每個躍點都應用自己的流量控制。

例如，假設客戶端將一個大文件上傳到服務器。 通常，客戶端流控制發送窗口很小，例如默認的65535個八位位組。 客戶端最多只能發送65535個八位位組，然后再停止上傳。

這65535個八位位組由server1接收。 現在， server1成為客戶端以便與server2進行通信。 想象一下，當server1的客戶端與server2通信時，已經為它配置了一個較小的流控制窗口，例如16384個八位位組。

在此示例中， server1在16384個八位位組之后停止上載到server2 ，並且必須設法保留其余的65535-16384個八位位組，以等待server2通知（通過WINDOW_UPDATE幀）已使用了上載的數據。

當server1的客戶端從server2接收到WINDOW_UPDATE時，它可以向server2發送更多數據； 而且，它還必須決定是否向客戶端發送WINDOW_UPDATE（因為它與客戶端的流控制窗口現在可以再容納16384個八位字節了）還是還要再等待一點。 例如，它可以向server2發送另一個16384個八位位組，並且只有在從server2接收到第二個WINDOW_UPDATE時，才可以決定向客戶端發送WINDOW_UPDATE（更新為16384 + 16384個八位位組）。

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

您可能還需要閱讀此答案 ，以獲取有關流控制策略實現的討論。

Answer 2

它取決於啤酒花/中間體的含義。

如果中介位於較低級別（TCP網關，NAT，交換機等），則它們對HTTP / 2透明，因為HTTP / 2流控制是在HTTP / 2客戶端和服務器之間端對端應用的。 他們之間的單個躍點可能使用較低級別的流量控制機制。

如果您的中介是HTTP代理，則基本上有兩個單獨的HTTP請求正在進行，每個請求都應用它自己的流控制。 代理應用程序負責在保留流控制屬性的同時連接這些單獨的躍點。 例如，不立即讀取第二跳的整個響應，然后將其轉發到第一跳，而是通過流傳輸適當的數據塊。

如果使用HTTP代理，您甚至會遇到將HTTP / 1.1代理到HTTP / 2的情況，反之亦然。 在這些情況下，它們代理將使用HTTP / 2流控制機制來確保該躍點的流控制，並使用TCP流控制來提供另一躍點上的流控制。 如果協議類型正確封裝在代理應用程序中（這意味着它將提供尊重Request和Response類型的流控制的流操作），則代理不同協議類型之間的流應該不會太難。