open - ¿Terminología en sentido ascendente/descendente utilizada al revés?(Por ejemplo, nginx)

nginx wiki

Question

Siempre he pensado en el flujo ascendente y descendente a lo largo de las líneas de una corriente real, donde el flujo de información es como el agua. Así que aguas arriba es de donde provienen los datos / agua (por ejemplo, una solicitud HTTP) y aguas abajo es donde va (por ejemplo, el sistema subyacente que atiende la solicitud).

He estado buscando en las puertas de enlace de API recientemente y noté que algunas de ellas usaban el inverso de esta definición. Me encogí de hombros como una rareza en ese momento. Luego descubrí que nginx, en el que se basan algunas puertas de enlace API, también usa la terminología de forma opuesta a lo que esperaba. nginx llama a los servidores que envía solicitudes a "servidores ascendentes" y, presumiblemente, las solicitudes entrantes serían, por lo tanto, "clientes posteriores".

Conceptualmente, parece que nginx estaría empujando las solicitudes "cuesta arriba" si se dirigía a un "servidor ascendente", lo cual es totalmente contraintuitivo ... ¡La gravedad se invierte en el terreno de los proxies inversos y las puertas de enlace API, aparentemente!

He visto otras discusiones que hablan sobre la dependencia ascendente / descendente que representa las dependencias entre sistemas, pero para el middleware o los componentes de infraestructura que se ubican entre los sistemas, la idea de dependencias es un poco más flexible, y me parece más útil pensar en términos de flujo de información. porque esa es usualmente la fuente de tus dependencias de todos modos.

¿Tengo una comprensión errónea de la analogía de la transmisión o son estos componentes del software los que hacen que los conceptos retrocedan?

Answer 1

En el mundo HTTP, el término "servidor ascendente" se introdujo en la especificación HTTP / 1.0, RFC 1945 :

502 Puerta de enlace no válida

El servidor, mientras actuaba como una puerta de enlace o proxy, recibió una respuesta no válida del servidor ascendente al que accedió al intentar completar la solicitud.

La definición formal se añadió más tarde, en RFC 2616 :

río arriba Río abajo

Upstream y downstream describen el flujo de un mensaje: todos los mensajes fluyen desde upstream a downstream.

Según esta definición:

• si está buscando una solicitud, entonces el cliente está en sentido ascendente y el servidor está en sentido descendente;
• por el contrario, si está viendo una respuesta, entonces el cliente está en la parte inferior y el servidor está en la parte superior.

Al mismo tiempo, en HTTP, la mayor parte del flujo de datos no es para solicitudes, sino para respuestas . Entonces, si considera el flujo de respuestas, entonces el término "servidor ascendente" suena bastante razonable y lógico. Y el término se usa nuevamente en la descripción del código de respuesta 502 (es idéntico a HTTP / 1.0), así como en otros lugares.

La misma lógica se puede ver también en términos de "descarga" y "carga" en lenguaje natural. La mayor parte del flujo de datos es de servidores a clientes, y es por eso que "descargar" significa cargar algo de un servidor a un cliente, y "cargar" - de un cliente a un servidor.