我一直认为沿着实际stream的上游和下游，信息stream就像水一样。 所以上游是水/数据来自哪里（例如HTTP请求），下游是它去的地方（例如服务请求的底层系统）。
我最近一直在研究API网关，并注意到其中一些使用了这个定义的反面。 当时我把它当作一种古怪的东西。 然后我发现，一些API网关所基于的Nginx，也以相反的方式使用了我所期望的术语。 Nginx调用它向“上游服务器”发送请求的服务器，并且可能因此传入的请求将是“下游客户端”。
从概念上来说，如果Nginx似乎将要求“上坡”，如果去一个“上游服务器”，这是完全反直觉…重力逆向代理和API网关的土地，显然！
我已经看到其他讨论关于上游/下游代表系统之间的依赖关系，但是对于位于系统之间的中间件或基础架构组件，依赖关系的概念稍微宽松一些，而且我认为从信息stream的angular度来看，因为无论如何，这通常是你的依赖的来源。
为什么我没有从g ++得到“多重定义”的错误？
与机制分开的政策：这是什么意思？
ros :: init（…）抛出一个错误 – Windows roscpp
如何从TFS构build定义输出Windows服务项目
确定types的定义
我是否理解了stream类比从根本上是错误的，还是这些软件组件将概念倒退？
什么是Windows代码页？
在HTTP世界中，“上游服务器”术语是在HTTP / 1.0规范RFC 1945中引入的：
服务器作为网关或代理服务器 ，在尝试执行请求时从其所访问的上游服务器收到无效响应。
后来在RFC 2616中增加了正式的定义：
上游/下游
上游和下游描述消息流：所有消息从上游流向下游。
根据这个定义：
如果您正在查看请求，则客户端在上游，服务器在下游;
相反，如果您正在查看响应，则客户端在下游，服务器在上游。
与此同时，在HTTP中，大部分数据流不是用于请求，而是用于响应 。 所以，如果你考虑响应的流程，那么“上游服务器”这个词听起来很合理和合乎逻辑。 而这个术语又被用在502响应代码描述中（和HTTP / 1.0一样），以及其他一些地方。
在自然语言的“下载”和“上传”方面也可以看到相同的逻辑。 大部分数据流是从服务器到客户端的，这就是为什么“下载”意味着从服务器向客户端加载某些东西，以及从客户端向服务器“上传”的原因。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 [email protected] 举报，一经查实，本站将立刻删除。
