我一直认为沿着实际stream的上游和下游，信息stream就像水一样。 所以上游是水/数据来自哪里（例如HTTP请求），下游是它去的地方（例如服务请求的底层系统）。
我最近一直在研究API网关，并注意到其中一些使用了这个定义的反面。 当时我把它当作一种古怪的东西。 然后我发现，一些API网关所基于的nginx，也以相反的方式使用了我所期望的术语。 nginx调用它向“上游服务器”发送请求的服务器，并且可能因此传入的请求将是“下游客户端”。
从概念上来说，如果nginx似乎将要求“上坡”，如果去一个“上游服务器”，这是完全反直觉…重力逆向代理和API网关的土地，显然！
我已经看到其他讨论关于上游/下游代表系统之间的依赖关系，但是对于位于系统之间的中间件或基础架构组件，依赖关系的概念稍微宽松一些，而且我认为从信息stream的angular度来看，因为无论如何，这通常是你的依赖的来源。
我是否理解了stream类比从根本上是错误的，还是这些软件组件将概念倒退？
在HTTP世界中，“上游服务器”术语是在HTTP / 1.0规范RFC 1945中引入的：
502错误的网关
服务器作为网关或代理服务器 ，在尝试执行请求时从其所访问的上游服务器收到无效响应。
后来在RFC 2616中增加了正式的定义：
上游/下游
上游和下游描述消息流：所有消息从上游流向下游。
根据这个定义：
与此同时，在HTTP中，大部分数据流不是用于请求，而是用于响应 。 所以，如果你考虑响应的流程，那么“上游服务器”这个词听起来很合理和合乎逻辑。 而这个术语又被用在502响应代码描述中（和HTTP / 1.0一样），以及其他一些地方。
在自然语言的“下载”和“上传”方面也可以看到相同的逻辑。 大部分数据流是从服务器到客户端的，这就是为什么“下载”意味着从服务器向客户端加载某些东西，以及从客户端向服务器“上传”的原因。