I've always thought of upstream and downstream along the lines of an actual stream, where the flow of information is like water. So upstream is where water/data comes from (e.g. an HTTP request) and downstream is where it goes (e.g. the underlying system that services the request).
I've been looking at API gateways recently and noticed that some of them used the inverse of this definition. I shrugged it off as an oddity at the time. I then discovered that nginx, which some API gateways are based on, also uses the terminology in the opposite way to what I expected. nginx calls the servers that it sends requests to "upstream servers", and presumably the incoming requests would therefore be "downstream clients".
Conceptually it seems like nginx would be pushing the requests "uphill" if going to an "upstream server", which is totally counter-intuitive... Gravity is reversed in the land of reverse proxies and API gateways, apparently!
I've seen other discussions talking about upstream / downstream representing dependencies between systems but for middleware or infrastructure components that sit between systems the idea of dependencies is a little looser, and I find it more helpful to think in terms of flow of information still - because THAT'S usually the source of your dependencies anyway.
Have I got my understanding of the stream analogy fundamentally wrong or are these software components getting the concepts backwards?
nginx calls the servers that it sends requests to "upstream servers", and presumably the incoming requests would therefore be "downstream clients".
The servers that Nginx proxies requests to are known as upstream servers. Nginx can proxy requests to servers that communicate using the http(s), FastCGI, SCGI, and uwsgi, or memcached protocols through separate sets of directives for each type of proxy.
It is a web server that can be used as a reverse proxy, mail proxy, or an HTTP cache. Upstream is a module used in NGINX to define the servers to be load balanced.
Upstream refers to the material inputs needed for production, while downstream is the opposite end, where products get produced and distributed.
In HTTP world, the "upstream server" term was introduced in the HTTP/1.0 specification, RFC 1945:
502 Bad Gateway
The server, while acting as a gateway or proxy, received an invalid response from the upstream server it accessed in attempting to fulfill the request.
Formal definition was added later, in RFC 2616:
upstream/downstream
Upstream and downstream describe the flow of a message: all messages flow from upstream to downstream.
According to this definition:
At the same time, in HTTP most of the data flow is not for requests, but for responses. So, if you'll consider flow of responses, then the "upstream server" term sounds pretty reasonable and logical. And the term is again used in the 502 response code description (it is identical to HTTP/1.0 one), as well as some other places.
The same logic can be also seen in terms "downloading" and "uploading" in natural language. Most of the data flow is from servers to clients, and that's why "downloading" means loading something from a server to a client, and "uploading" - from a client to a server.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With