[解決済み] アップストリーム/ダウンストリームの用語が逆に使われている？(例: nginx)

質問

私はいつも、情報の流れが水のようである、実際の流れに沿って上流と下流について考えてきました。つまり、上流は水/データが来る場所 (例: HTTP リクエスト)、下流はそれが行く場所 (例: リクエストを処理する基本システム) です。

最近、APIゲートウェイを見ていて、いくつかのゲートウェイがこの定義の逆を使用していることに気づきました。そのときは、奇妙なこととして受け流しました。nginx はリクエストを送信するサーバーを「上流サーバー」と呼び、おそらく入ってくるリクエストは「下流クライアント」であると思われます。

概念的には、nginx が上流サーバにリクエストを送る場合、quot;uphill" を押しているように見えますが、これは全く直感に反しています...。リバースプロキシとAPIゲートウェイの世界では重力が逆転しているようです!

システム間の依存関係を表す上流/下流について話している他の議論を見たことがありますが、システム間に位置するミドルウェアやインフラストラクチャのコンポーネントの場合、依存関係の概念は少し緩く、情報の流れという観点から考える方がより有用だと思います - 通常、これが依存関係のソースになるからです。

私はストリームアナロジーの理解を根本的に間違えているのでしょうか、それともこれらのソフトウェアコンポーネントはコンセプトを逆にしているのでしょうか?

どのように解決するのですか?

HTTP の世界では、HTTP/1.0 仕様で "upstream server" という用語が導入されました。 RFC 1945 :

502 不正なゲートウェイ

サーバーがゲートウェイまたはプロキシとして動作しているときに、無効な レスポンスを受け取りました。 上流サーバ から無効な応答を受け取りました。 レスポンスを返します。

正式な定義は、後で追加された RFC 2616 :

アップストリーム/ダウンストリーム

上流と下流は、メッセージの流れを表します。 メッセージは上流から下流に流れます。

この定義によると

• を見ている場合、クライアントは上流にあり、サーバーは下流にあります。
• 一方、レスポンスを見ている場合は、クライアントが下流で、サーバーが上流になります。

同時に、HTTP ではほとんどのデータフローがリクエストではなく レスポンスです。 . ですから、もしあなたがレスポンスの流れを考慮するのであれば、quot;上流サーバという用語はかなり合理的かつ論理的に聞こえます。 そして、この用語は 502 レスポンスコードの記述 (HTTP/1.0 のものと同じ) や他のいくつかの場所で再び使用されています。

同じ論理は、自然言語における "downloading" と "uploading" という用語でも見ることができます。 データの流れのほとんどはサーバーからクライアントへのもので、そのため、"downloading" はサーバーからクライアントへ何かをロードすること、そして "uploading" はクライアントからサーバーへ何かをロードすることを意味します。