Terminologie amont / aval utilisée à l'envers? (Par exemple, nginx)
J'ai toujours pensé en amont et en aval le long des lignes d'un véritable cours d'eau, où le flux d'informations est comme l'eau. Ainsi, l'amont est d'où provient l'eau/les données (par exemple, une demande HTTP) et l'aval, c'est là où elles vont (par exemple le système sous-jacent qui répond à la demande).
J'ai récemment examiné les passerelles API et j'ai remarqué que certaines d'entre elles utilisaient l'inverse de cette définition. Je l'ai ignoré comme une bizarrerie à l'époque. J'ai ensuite découvert que nginx, sur lequel certaines passerelles API sont basées, utilise également la terminologie de la manière opposée à ce que j'attendais. nginx appelle les serveurs sur lesquels il envoie des requêtes aux "serveurs en amont", et vraisemblablement les requêtes entrantes seraient donc des "clients en aval".
D'un point de vue conceptuel, il semble que nginx pousse les requêtes "en amont" si vous allez sur un "serveur en amont", ce qui est totalement contre-intuitif ... La gravité est inversée au pays des proxys inverses et des passerelles API, apparemment!
J'ai vu d'autres discussions parler d'amont/aval représentant les dépendances entre les systèmes, mais pour les middleware ou les composants d'infrastructure qui se trouvent entre les systèmes, l'idée de dépendances est un peu plus lâche, et je trouve plus utile de penser en termes de flux d'informations - car C'EST généralement la source de vos dépendances de toute façon.
Ai-je une compréhension de l'analogie de flux fondamentalement erronée ou ces composants logiciels font-ils reculer les concepts?
Dans le monde HTTP, le terme "serveur en amont" a été introduit dans la spécification HTTP/1.0, RFC 1945 :
502 Mauvaise passerelle
Le serveur, tout en agissant en tant que passerelle ou proxy, a reçu une réponse non valide du serveur en amont auquel il a accédé pour tenter de répondre à la demande.
Une définition formelle a été ajoutée plus tard, dans RFC 2616 :
amont Aval
L'amont et l'aval décrivent le flux d'un message: tous les messages circulent de l'amont vers l'aval.
Selon cette définition:
- si vous regardez une demande, le client est en amont et le serveur en aval;
- en revanche, si vous regardez une réponse, le client est en aval et le serveur en amont.
Dans le même temps, en HTTP, la plupart du flux de données n'est pas pour les demandes, mais pour réponses. Donc, si vous considérez le flux de réponses, le terme "serveur en amont" semble assez raisonnable et logique. Et le terme est à nouveau utilisé dans la description du code de réponse 502 (il est identique à celui de HTTP/1.0), ainsi que dans d'autres endroits.
La même logique se retrouve également en termes de "téléchargement" et de "téléchargement" en langage naturel. La majeure partie du flux de données va des serveurs aux clients, et c'est pourquoi "télécharger" signifie charger quelque chose d'un serveur vers un client, et "télécharger" - d'un client vers un serveur.