上流/下流の用語は逆に使用されていますか？ （例：nginx）
情報の流れが水のようである実際の流れの線に沿って、上流と下流を常に考えてきました。したがって、上流は水/データの送信元（HTTPリクエストなど）であり、下流は送信元（リクエストを処理する基盤となるシステムなど）です。
私は最近APIゲートウェイを見ており、そのうちのいくつかがこの定義の逆を使用していることに気付きました。私はその時、奇妙なものとして肩をすくめた。その後、一部のAPIゲートウェイのベースであるnginxも、予想とは逆の用語を使用していることを発見しました。 nginxは、要求を「上流サーバー」に送信するサーバーを呼び出します。したがって、おそらく着信要求は「下流クライアント」になります。
概念的には、完全に直感に反する「アップストリームサーバー」に行くと、nginxがリクエストを「上り坂」に押し上げているように見えます。
システム間の依存関係を表すアップストリーム/ダウンストリームに関する他の議論を見てきましたが、システム間にあるミドルウェアまたはインフラストラクチャコンポーネントの場合、依存関係の概念は少し緩いです。とにかく、それが通常あなたの依存関係のソースだからです。
ストリームの類推について根本的に間違っていることを理解しましたか、またはこれらのソフトウェアコンポーネントは概念を逆にしていますか？
HTTPの世界では、「アップストリームサーバー」という用語がHTTP/1.0仕様で導入されました RFC 1945 ：
502不正なゲートウェイ
サーバーは、ゲートウェイまたはプロキシとして機能しているときに、リクエストを処理しようとしてアクセスした上流サーバーから無効な応答を受信しました。
正式な定義は、後で追加されました RFC 2616 ：
上流/下流
アップストリームとダウンストリームはメッセージの流れを表します。すべてのメッセージはアップストリームからダウンストリームに流れます。
この定義によると：
- リクエストを見ている場合、クライアントはアップストリームであり、サーバーはダウンストリームです。
- 対照的に、応答を見ている場合、クライアントはダウンストリームであり、サーバーはアップストリームです。
同時に、HTTPでは、データフローのほとんどは要求用ではなく、応答用です。したがって、応答のフローを考慮すると、「上流サーバー」という用語はかなり合理的で論理的に聞こえます。また、この用語は、502応答コードの説明（HTTP/1.0の説明と同じ）および他の場所でも使用されています。
同じロジックは、自然言語の「ダウンロード」および「アップロード」という用語でも見ることができます。データフローのほとんどはサーバーからクライアントへの流れであるため、「ダウンロード」とは、サーバーからクライアントに何かをロードし、クライアントからサーバーに「アップロード」することを意味します。