上游/下游术语向后使用？（例如nginx）

我一直在考虑实际流的上游和下游，那里的信息流就像水一样。因此，上游是水/数据的来源（例如，HTTP请求），下游是水/数据的来源（例如，为请求提供服务的基础系统）。

我最近一直在研究API网关，并注意到其中一些使用了与该定义相反的含义。当时我觉得有些奇怪。然后，我发现某些API网关所基于的nginx也以与我期望相反的方式使用了该术语。nginx将发送请求的服务器称为“上游服务器”，因此传入的请求可能是“下游客户端”。

从概念上讲，如果进入“上游服务器”，nginx似乎会将请求“推向上坡”，这完全是违反直觉的……在反向代理和API网关领域，重力是反向的，显然！

我已经看过其他讨论，它们讨论上游/下游代表系统之间的依赖性，但是对于位于系统之间的中间件或基础结构组件，依赖性的概念稍微宽松一些，并且我认为仍然可以从信息流的角度进行思考-因为无论如何，这通常是依赖项的来源。

我对流类比的理解是否从根本上错了，还是这些软件组件使概念倒退了？

在HTTP世界中，HTTP / 1.0规范RFC 1945中引入了“上游服务器”一词：

502错误的网关

该服务器在充当网关或代理的同时，从尝试访问该请求的上游服务器接收到无效响应。

稍后在RFC 2616中添加了正式定义：

上游/下游

上游和下游描述消息的流：所有消息从上游流向下游。

根据这个定义：

• 如果您正在查看请求，则客户端在上游，服务器在下游；
• 相反，如果您正在查看响应，则客户端在下游，服务器在上游。

同时，在HTTP中，大多数数据流不是用于请求，而是用于响应。因此，如果您考虑响应流，那么“上游服务器”一词听起来很合理且合乎逻辑。并且该术语在502响应代码描述中再次使用（与HTTP / 1.0相同），以及其他一些地方。

在自然语言中的“下载”和“上传”方面也可以看到相同的逻辑。大部分数据流是从服务器到客户端的，这就是为什么“下载”意味着将某些内容从服务器加载到客户端，并将“上传”-从客户端加载到服务器。