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

Posted 2023-03-04

【中文标题】上游/下游术语向后使用？ （例如 nginx）

【英文标题】：Upstream / downstream terminology used backwards? (E.g. nginx)

【发布时间】：2015-11-28 15:16:01

【问题描述】：

我一直认为上游和下游沿着一条实际的河流，信息的流动就像水一样。所以上游是水/数据的来源（例如 HTTP 请求），下游是它的去处（例如为请求提供服务的底层系统）。

我最近一直在研究 API 网关，并注意到其中一些使用了与此定义相反的定义。当时我把它当作一个奇怪的东西耸了耸肩。然后我发现一些 API 网关所基于的 nginx 也以与我预期相反的方式使用该术语。 nginx 调用它向“上游服务器”发送请求的服务器，因此传入的请求可能是“下游客户端”。

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

我已经看到其他关于上游/下游表示系统之间依赖关系的讨论，但是对于位于系统之间的中间件或基础架构组件，依赖关系的概念有点松散，我发现从流程的角度思考更有帮助信息仍然存在 - 因为这通常是您的依赖项的来源。

我对流类比的理解是否根本错误，或者这些软件组件是否让概念倒退了？

【问题讨论】：

好问题，这困扰了我很久。

【参考方案1】：

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

502 网关错误

服务器在充当网关或代理时，收到一个无效的 上游服务器的响应，它试图访问 完成请求。

正式定义是后来添加的，在RFC 2616:

上游/下游

上游和下游描述消息的流向：全部 消息从上游流向下游。

根据这个定义：

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

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

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

【讨论】：

谢谢，这确实有道理。作为具有集成背景的人，我必须承认，我倾向于将方向视为发起通信的人，而不是传输的数据量。我现在可以在 HTTP 定义的上下文中理解这一点，但鉴于 HTTP 本质上是请求/响应（即朝两个方向发展），我希望他们完全避免使用该术语，因为它并不能真正帮助理解方向！ :)

如果“上游和下游描述了一条消息的流向：所有消息都从上游流向下游。”，那么这意味着不能谈论“上游/下游API”——总会有请求和响应。如果（比如说）下游始终是服务器，而上游始终是客户端（即关注点是请求，而不是响应）会更好。