上游/下游術語向後使用？ （例如nginx）

Question

我一直認爲沿着實際流的上游和下游，信息流就像水一樣。所以上游是水/數據來自哪裏（例如HTTP請求），下游是它去的地方（例如爲請求提供服務的底層系統）。

我一直在尋找最近的API網關，並注意到他們中的一些人使用了這個定義的反面。當時我把它當作怪事聳了聳肩。然後我發現，一些API網關所基於的nginx也以與我預期相反的方式使用術語。 nginx調用它向「上游服務器」發送請求的服務器，並且可能因此傳入的請求將是「下游客戶端」。

從概念上來說，如果轉到「上游服務器」，nginx似乎會推動請求「上坡」，這完全違反直覺......顯然，在反向代理和API網關的領域，重力被逆轉了！

我見過其他討論關於上游/下游表示系統之間依賴關係的討論，但對於位於系統之間的中間件或基礎架構組件，依賴關係的想法稍微寬鬆一點，我發現從流動角度思考更有幫助的信息仍然存在 - 因爲無論如何，這通常是您的依賴關係的來源。

我對流類比的理解有沒有根本的錯誤，或者這些軟件組件是否會讓概念向後退化？

Answer 1

在HTTP的世界中， 「上游服務器」 一詞在HTTP/1.0規範被引入，RFC 1945：

502錯誤網關

所述的服務器，而作爲網關或代理，接收一個無效的 響應自上游服務器它試圖在 履行請求。

正式定義後來加入，在RFC 2616：

上游/下游

上游和下游描述消息流：所有 消息從上游流動到下游。

根據這個定義：

• 如果你正在尋找的請求，則客戶端是上游，並且所述服務器是下游;
• 相比之下，如果您正在查看響應，則客戶端在下游，服務器在上游。

與此同時，在HTTP中大部分數據流不是針對請求的，而是針對響應。所以，如果你會考慮響應的流量，那麼「上游服務器」這個詞聽起來很合理和合乎邏輯。該術語再次用於502響應代碼描述（與HTTP/1.0相同）以及其他一些地方。

在自然語言的「下載」和「上傳」方面也可以看到相同的邏輯。大部分數據流是從服務器到客戶端的，這就是爲什麼「下載」意味着從服務器向客戶端加載某些內容，並且「上傳」 - 從客戶端到服務器。