上游/下游术语向后使用？(例如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一个相同),以及其他一些地方.

在用自然语言"下载"和"上载"的术语中也可以看到相同的逻辑.大多数数据流是从服务器到客户端,这就是为什么"下载"意味着从服务器向客户端加载某些内容,以及"上传" - 从客户端到服务器.