A communique directement avec B, ce qui signifie qu'il n'y a pas d'agence ;
Cependant, il y a un messager C au milieu. C est l'agent A qui transmet les informations à B via C, puis C relaie les commentaires de B à A.
Dans ce processus, A sait que la cible directe de la communication est B, mais pour diverses raisons, il ne peut pas se trouver directement face à face avec B et a besoin d'un intermédiaire C. C'est ce qu'on appelle « l'agent avancé ». , on parle rarement d'agence de transfert. Dans le texte anglais original, cela s'appelle Forward Proxy. Généralement, on l'appelle simplement proxy. Si vous le traduisez par « proxy de transfert » ou « proxy de transmission », c'est mieux que « proxy de transfert ». ". Cependant, ce n'est pas nécessaire, car tel est le sens originel du mot proxy.
Une autre situation est : A ne connaît pas l'existence de B. Il sait seulement trouver C pour obtenir la réponse qu'il veut. Pour A, s'il y a B ou combien de B, D, E, F... Ce n'est pas le cas. Peu importe, tant qu'il y a C, c'est suffisant. Et C reçoit un feedback en fonction de la situation puis répond à A.
C'est ce qu'on appelle un proxy inverse. Pour comprendre la différence, ne vous concentrez pas sur les deux antonymes de « positif et négatif ». Forward et Reverse en anglais ne sont pas une paire d'antonymes, mais Forward et Backward Cependant, Reverse et Backward ne signifient pas la même chose. . donc Pour les livres et documents techniques, vous devez toujours lire le texte original.
─────
Un ami m'a posé une question tout à l'heure car il était encore confus à ce sujet, je lui ai donné un exemple et il a compris. Je ne sais pas si ma réponse ci-dessus peut faire comprendre à tout le monde, alors j'ai aussi écrit cet exemple :
Proxy Forward
Je souhaite accéder à www.google.com, mais tout le monde sait qu'il est bloqué et je ne peux pas y accéder directement. Je me suis donc connecté à un service VPN et je l'ai défini comme proxy pour l'accès HTTP local (par exemple, sous Mac, cochez "Envoyer tout le trafic via la connexion VPN), puis j'ai accédé à www.google.com, et ma demande a été bloquée . Le service VPN me donne accès à www.google.com et me renvoie les résultats
.
Cet exemple est un scénario d'application du proxy, mais cela ne signifie pas que le proxy ne peut être utilisé que pour cela
La caractéristique la plus importante est que je connais l'existence de www.google.com, et l'URL que j'ai visitée est bien www.google.com, mais ma demande d'accès est transmise via un proxy VPN, et il en va de même pour le réponse
Dans ce cas, le proxy est transparent et l'utilisateur peut ne pas connaître son existence (généralement, il le sait, mais il ne peut pas configurer lui-même le proxy)
Proxy inversé
J'ai un service Nginx déployé sur le port 80 de www.mysite.com Lorsque les utilisateurs le visitent, ils peuvent voir le site Web que j'ai créé ; il y a des requêtes Ajax dans mon site Web pour obtenir des données JSON, mais le service API qui les fournit. les données sont déployées Le port 8000 sur le serveur est bloqué par le pare-feu et n'est pas directement accessible aux utilisateurs.
J'ai donc reconfiguré Nginx pour qu'il transmette toutes les demandes d'accès via :80/api/ à localhost:8000, puis renvoie la réponse au demandeur d'origine (c'est-à-dire : Origin Host). Mes utilisateurs peuvent désormais accéder normalement à www.mysite.com.
Comme ci-dessus, il s'agit d'un scénario d'application de proxy inverse, mais cela ne signifie pas qu'il ne peut être utilisé que de cette manière
La caractéristique la plus importante est que mes utilisateurs ne connaissent pas du tout l'existence du service localhost:8000, et même s'ils le connaissent, ils ne peuvent pas y accéder - ils ne peuvent pas y accéder même s'ils ouvrent un VPN. Ce sont deux choses différentes !
Pour les utilisateurs, la seule partie de « conversation » est www.mysite.com (port 80). Ils ne savent pas et n'ont pas besoin de savoir ce qui s'est passé ensuite
Le proxy inverse signifie que la cible derrière lui est fixe Les utilisateurs accédant à votre nginx équivaut à accéder au service Web derrière le proxy
Le proxy Forward signifie que la cible de son proxy n'est pas fixe Les utilisateurs peuvent accéder à n'importe quel service Web via le serveur proxy
La principale différence est de savoir si c'est le client ou le serveur qui fait office de proxy. Si le client utilise un proxy lors de l'envoi d'une requête, il s'agit d'un proxy direct Et lorsque le serveur reçoit la requête du client, il utilise un proxy pour transférer vers d'autres serveurs, ce qui est un proxy inverse ;
Forward proxy : vous devez définir activement l'adresse IP ou le nom de domaine du serveur proxy pour l'accès. Obtenez le contenu d'accès et renvoyez-le en fonction de l'adresse IP du serveur ou du nom de domaine défini.
Proxy inverse : vous n'avez besoin d'aucun paramètre pour accéder directement à l'adresse IP réelle ou au nom de domaine du serveur, mais le serveur sautera automatiquement et renverra le contenu en fonction du contenu consulté. Vous ne savez pas à quelles machines il accède finalement.
Pour l'exemple ABC, l'agent direct peut être compris comme : C va à B en tant qu'agent de A, tandis que C dans l'agent inverse ressemble plus à un agent de B, va donner un feedback à A.
Lorsque l'ordinateur accède au serveur et que le serveur ne connaît pas la véritable adresse IP de l'ordinateur, il existe un proxy direct entre les deux.
Si l'ordinateur accède au serveur et qu'il ne connaît pas la véritable adresse IP du serveur, il existe un proxy inverse entre les deux.
Bien sûr, de nombreux proxys directs peuvent également transmettre la véritable adresse IP de l'ordinateur via la tête http
Agent transitaire : Vous vous rendez au KFC pour manger du hamburger et des ailes de poulet. Le hamburger et les ailes de poulet sont obtenus au siège via les sous-centres « agents » à chaque niveau puis vous sont distribués. Procuration inverse : lorsque le siège social de KFC vous donne des hamburgers et des ailes de poulet, il peut d'abord attribuer des sous-centres dans différentes régions, puis se rendre dans les magasins et enfin vous les livrer, mais c'est transparent pour vous et vous n'avez pas besoin de le faire. Sachez s'il s'agit de la Chine de l'Est ou de la Chine du Nord. La succursale vous le livrera.
Lorsque nous allons en ligne, nous devons parfois configurer un serveur proxy (par exemple si nous sommes bloqués par un mur). Ce serveur proxy est un proxy direct lors du développement d'un système serveur, la requête proxy envoyée par le client/navigateur est distribuée. plusieurs entreprises réelles en arrière-plan, ce proxy est un proxy inverse.
Vous pouvez considérer le proxy direct comme côté client et le proxy inverse comme côté serveur.
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
A communique directement avec B, ce qui signifie qu'il n'y a pas d'agence ;
Cependant, il y a un messager C au milieu. C est l'agent A qui transmet les informations à B via C, puis C relaie les commentaires de B à A.
Dans ce processus, A sait que la cible directe de la communication est B, mais pour diverses raisons, il ne peut pas se trouver directement face à face avec B et a besoin d'un intermédiaire C. C'est ce qu'on appelle « l'agent avancé ». , on parle rarement d'agence de transfert. Dans le texte anglais original, cela s'appelle Forward Proxy. Généralement, on l'appelle simplement proxy. Si vous le traduisez par « proxy de transfert » ou « proxy de transmission », c'est mieux que « proxy de transfert ». ". Cependant, ce n'est pas nécessaire, car tel est le sens originel du mot proxy.
Une autre situation est : A ne connaît pas l'existence de B. Il sait seulement trouver C pour obtenir la réponse qu'il veut. Pour A, s'il y a B ou combien de B, D, E, F... Ce n'est pas le cas. Peu importe, tant qu'il y a C, c'est suffisant. Et C reçoit un feedback en fonction de la situation puis répond à A.
C'est ce qu'on appelle un proxy inverse. Pour comprendre la différence, ne vous concentrez pas sur les deux antonymes de « positif et négatif ». Forward et Reverse en anglais ne sont pas une paire d'antonymes, mais Forward et Backward Cependant, Reverse et Backward ne signifient pas la même chose. . donc Pour les livres et documents techniques, vous devez toujours lire le texte original.
─────
Un ami m'a posé une question tout à l'heure car il était encore confus à ce sujet, je lui ai donné un exemple et il a compris. Je ne sais pas si ma réponse ci-dessus peut faire comprendre à tout le monde, alors j'ai aussi écrit cet exemple :
Proxy Forward
Je souhaite accéder à www.google.com, mais tout le monde sait qu'il est bloqué et je ne peux pas y accéder directement. Je me suis donc connecté à un service VPN et je l'ai défini comme proxy pour l'accès HTTP local (par exemple, sous Mac, cochez "Envoyer tout le trafic via la connexion VPN), puis j'ai accédé à www.google.com, et ma demande a été bloquée . Le service VPN me donne accès à www.google.com et me renvoie les résultats
.Cet exemple est un scénario d'application du proxy, mais cela ne signifie pas que le proxy ne peut être utilisé que pour cela
La caractéristique la plus importante est que je connais l'existence de www.google.com, et l'URL que j'ai visitée est bien www.google.com, mais ma demande d'accès est transmise via un proxy VPN, et il en va de même pour le réponse
Dans ce cas, le proxy est transparent et l'utilisateur peut ne pas connaître son existence (généralement, il le sait, mais il ne peut pas configurer lui-même le proxy)
Proxy inversé
J'ai un service Nginx déployé sur le port 80 de www.mysite.com Lorsque les utilisateurs le visitent, ils peuvent voir le site Web que j'ai créé ; il y a des requêtes Ajax dans mon site Web pour obtenir des données JSON, mais le service API qui les fournit. les données sont déployées Le port 8000 sur le serveur est bloqué par le pare-feu et n'est pas directement accessible aux utilisateurs.
J'ai donc reconfiguré Nginx pour qu'il transmette toutes les demandes d'accès via :80/api/ à localhost:8000, puis renvoie la réponse au demandeur d'origine (c'est-à-dire : Origin Host). Mes utilisateurs peuvent désormais accéder normalement à www.mysite.com.
Comme ci-dessus, il s'agit d'un scénario d'application de proxy inverse, mais cela ne signifie pas qu'il ne peut être utilisé que de cette manière
La caractéristique la plus importante est que mes utilisateurs ne connaissent pas du tout l'existence du service localhost:8000, et même s'ils le connaissent, ils ne peuvent pas y accéder - ils ne peuvent pas y accéder même s'ils ouvrent un VPN. Ce sont deux choses différentes !
Pour les utilisateurs, la seule partie de « conversation » est www.mysite.com (port 80). Ils ne savent pas et n'ont pas besoin de savoir ce qui s'est passé ensuite
Le proxy inverse signifie que la cible derrière lui est fixe
Les utilisateurs accédant à votre nginx équivaut à accéder au service Web derrière le proxy
Le proxy Forward signifie que la cible de son proxy n'est pas fixe
Les utilisateurs peuvent accéder à n'importe quel service Web via le serveur proxy
La principale différence est de savoir si c'est le client ou le serveur qui fait office de proxy.
Si le client utilise un proxy lors de l'envoi d'une requête, il s'agit d'un proxy direct
Et lorsque le serveur reçoit la requête du client, il utilise un proxy pour transférer vers d'autres serveurs, ce qui est un proxy inverse ;
Forward proxy : vous devez définir activement l'adresse IP ou le nom de domaine du serveur proxy pour l'accès. Obtenez le contenu d'accès et renvoyez-le en fonction de l'adresse IP du serveur ou du nom de domaine défini.
Proxy inverse : vous n'avez besoin d'aucun paramètre pour accéder directement à l'adresse IP réelle ou au nom de domaine du serveur, mais le serveur sautera automatiquement et renverra le contenu en fonction du contenu consulté. Vous ne savez pas à quelles machines il accède finalement.
Pour l'exemple ABC, l'agent direct peut être compris comme : C va à B en tant qu'agent de A, tandis que C dans l'agent inverse ressemble plus à un agent de B, va donner un feedback à A.
Pour faire simple, cela dépend de qui vous représentez. Le proxy du client est un proxy direct et le proxy du serveur est un proxy inverse
Lorsque l'ordinateur accède au serveur et que le serveur ne connaît pas la véritable adresse IP de l'ordinateur, il existe un proxy direct entre les deux.
Si l'ordinateur accède au serveur et qu'il ne connaît pas la véritable adresse IP du serveur, il existe un proxy inverse entre les deux.
Bien sûr, de nombreux proxys directs peuvent également transmettre la véritable adresse IP de l'ordinateur via la tête http
Agent transitaire : Vous vous rendez au KFC pour manger du hamburger et des ailes de poulet. Le hamburger et les ailes de poulet sont obtenus au siège via les sous-centres « agents » à chaque niveau puis vous sont distribués.
Procuration inverse : lorsque le siège social de KFC vous donne des hamburgers et des ailes de poulet, il peut d'abord attribuer des sous-centres dans différentes régions, puis se rendre dans les magasins et enfin vous les livrer, mais c'est transparent pour vous et vous n'avez pas besoin de le faire. Sachez s'il s'agit de la Chine de l'Est ou de la Chine du Nord. La succursale vous le livrera.
Lorsque nous allons en ligne, nous devons parfois configurer un serveur proxy (par exemple si nous sommes bloqués par un mur). Ce serveur proxy est un proxy direct lors du développement d'un système serveur, la requête proxy envoyée par le client/navigateur est distribuée. plusieurs entreprises réelles en arrière-plan, ce proxy est un proxy inverse.
Vous pouvez considérer le proxy direct comme côté client et le proxy inverse comme côté serveur.
Voir /q/1010000003698318?_ea=331448