Qu'est-ce qui se trouve devant presque chaque service web
Bienvenue
Si vous tapez example.com dans un navigateur, vous n'arrivez presque jamais sur l'ordinateur qui exécute réellement l'application. Vous arrivez sur une machine qui redirige la demande vers celle qui le fait. Cette machine de redirection porte un nom : un proxy invers.
Cette leçon enseigne ce qu'un proxy invers fait, pourquoi presque chaque service web public se cache derrière un, & ce que trois emplois de la couche de bord gèrent en même temps.
Au final, vous comprendrez:
- La différence entre un client, un proxy & une origine
- Pourquoi un proxy devant une origine protège, échelle & permet de changer des pièces sans que personne ne s'en aperçoive
- Les trois emplois d'un proxy invers en même temps : cacher l'origine, terminer TLS & distribuer la charge entre les copies
- Comment une demande voyage d'un navigateur à un proxy, puis vers le haut & retour, étape par étape
Au final, vous raisonnez avec confiance sur la place des proxies, la séparation des préoccupations à la périphérie & pourquoi une couche de proxy étatique se multiplie à bon marché tandis qu'une seule origine ne le fait pas.
Proxy avant vs Proxy invers
Deux Directions Proxy
Les deux types de proxy se tiennent entre deux parties & transmettent le trafic. Ils diffèrent en la partie qu'ils représentent.
Proxy avant: se tient devant un groupe d'utilisateurs. Les utilisateurs connaissent un proxy; un serveur extérieur voit une adresse proxy, pas une adresse client. Les proxies de sortie d'entreprise, les filtres de contenu & les proxies SOCKS correspondent à ce modèle.
Proxy invers: se tient devant un groupe de serveurs. Le monde extérieur (les utilisateurs) parle d'une adresse proxy; les utilisateurs n'ont pas idée qu'un vrai serveur se cache derrière. Presque chaque service web public en utilise un.
Mnémonique: un proxy avant cache les clients par rapport aux serveurs. Un proxy invers cache les serveurs par rapport aux clients.
Pourquoi s'inquiéter de la direction? Le travail, les modes d'échec & la limite de sécurité diffèrent. Un proxy avant se soucie de qui ses utilisateurs contactent; un proxy invers se soucie de qui contacte ses serveurs.
Un client envoyant du trafic à travers les deux types à la fois voyage: client -> proxy_avant -> internet -> proxy_invers -> origine.
Pourquoi tant de choses vivent à la frontière
La Couche de Borda Gagne Son Bouche
Un proxy inverse effectue trois emplois en même temps. L'un d'entre eux justifie la couche ; effectuer tous les trois à la même adresse explique pourquoi presque toute architecture web de production a la même forme à l'avant.
Poste 1: Cacher l'origine. Le proxy répond sur une IP publique. Les backends se trouvent sur des IP privées auxquelles l'internet ne peut pas accéder. Un attaquant qui souhaite frapper l'origine doit d'abord compromettre le proxy.
Poste 2: Terminez TLS. Le proxy détient le certificat pour example.com et déchiffre les demandes HTTPS en provenance. Les backends parlent HTTP (ou une TLS plus simple) au proxy sur une segment de réseau fiable. La rotation, la renouvellement et la politique de chiffrement vivent dans un seul endroit.
Poste 3: Distribuer la charge. Le proxy choisit quel backend gère chaque demande. Les backends derrière un proxy forment une pool ; le proxy choisit un par demande en utilisant une stratégie (tournante, moindre nombre de connexions, hachage sur un en-tête). Ajouter de la capacité signifie ajouter un backend au pool, pas dire à chaque client une nouvelle adresse.
Chaque emploi est une petite application. Ensemble, ils expliquent pourquoi un niveau aussi simple que 'Caddy devant une application Python' transporte plus de poids de conception que l'application Python elle-même.
Conception pour Tous les Trois
Votre équipe gère une petite API sur une seule instance Python écoutant sur le port 8000 sur une seule VM. Le trafic a grandi assez pour qu'une seule VM ne puisse pas tenir, et une revue de sécurité a indiqué que la VM a une IP publique et gère son propre certificat TLS.
Vous décidez d'insérer un proxy inverse à l'avant. Esquissez la disposition : où pointe le DNS, où vit le certificat, comment la charge atteint les backends et ce qui change à la VM originelle?
Échanger une Composante Sans Que Personne Ne S'en Aperçoive
L'Indirection Achète de la Liberté
Une ancienne maxime de l'informatique affirme : chaque problème peut être résolu en ajoutant une couche d'indirection (sauf le problème de trop de couches d'indirection). La reverse proxy est l'une des indirections les plus utiles dans les systèmes distribués.
**Ce qu'elle vous achète :"
- Backends échangeables. Passer de Python à Go? Migrer d'un datacenter à un autre? Lancer une nouvelle version avec un arrêt zéro? Chacun se produit derrière une adresse publique stable. Rien ne change pour les utilisateurs.
- Échelle indépendante. Le niveau de proxy s'échelle en fonction de la bande passante et de la CPU au niveau TLS. Le niveau backend s'échelle en fonction du travail de l'application. Chacun grandit sur son propre axe car ils vivent sur des machines différentes.
- Contenu des pannes. Une mauvaise mise à jour sur le backend ne met pas à jour la adresse publique. Le proxy reste en place ; vous faites une correction ou effectuez un rollback ; le monde se reconnecte lorsque le backend se rétablit.
- Préoccupations transversales dans un seul endroit. Limitation des tarifs, blocage géo, enregistrement des demandes, modification des en-têtes, mise en cache, compression des réponses : toutes se trouvent sur le proxy. Le code du backend reste concentré sur l'application.
Sans le proxy chaque un de ces problèmes doit vivre à l'intérieur du processus d'application. Avec le proxy, ils vivent à une couche que l'équipe propriétaire gère.
Le coût : une autre couche à gérer. Les équipes expérimentées acceptent ce coût parce que la couche proxy elle-même fonctionne sans état et s'échelle horizontalement ; remplacer un proxy par un autre nécessite aucune coordination.
Un Déployement Bleu/Violet Par le Biais de la Proxy
Votre équipe exécute la version 1 de l'API sur trois VM de backend (pool bleu) derrière une proxy inverse. Vous souhaitez déployer la version 2 avec la capacité de faire marche arrière en moins de trente secondes si quelque chose se produit mal.
Vous lancez trois nouvelles VM de backend (pool vert) exécutant la version 2, côte à côte avec le pool bleu, mais vous n'avez pas encore orienté de trafic vers elles.
De Bureau à Arrière-plan et Retour
Suivez Une Requête de A à Z
Tracez une seule requête HTTPS https://api.example.com/users/42 à travers une passerelle inversée devant une pool de backends.
Saut 1: Résolution DNS. Le navigateur demande à un résolveur l'adresse api.example.com. Le résolveur retourne l'IP publique de la passerelle (par exemple, 203.0.113.10). Le navigateur ouvre une connexion TCP vers 203.0.113.10:443.
Saut 2: Échange TLS. La passerelle présente son certificat pour api.example.com. Le navigateur valide le certificat, les deux parties conviennent d'une clé de session et la canal chiffré s'ouvre.
Saut 3: Requête HTTP à l'intérieur du TLS. Le navigateur envoie GET /users/42 HTTP/1.1\nHost: api.example.com\n.... La passerelle déchiffre les octets de la requête.
Saut 4: Sélection du backend. La passerelle consulte son pool d'origine pour api.example.com et choisit un backend (par exemple 10.0.0.21:8000) en utilisant sa stratégie de charge équilibrée.
Saut 5: Requête vers l'amont. La passerelle ouvre (ou reutilise) une connexion HTTP normale vers 10.0.0.21:8000 et transmet la requête. La passerelle peut modifier les en-têtes en cours: ajouter X-Forwarded-For: <client-ip>, définir Host: correctement, supprimer les en-têtes de saut comme Connection.
Saut 6: Traitement du backend. L'application backend lit la requête, interroge sa base de données, construit une réponse JSON.
Saut 7: Réponse amont. Le backend envoie la réponse de retour à la passerelle sous forme de HTTP normale.
Saut 8: Réponse de bord. La passerelle peut modifier ou compresser la réponse, la chiffre à nouveau à travers la session TLS et l'envoyer au navigateur.
Saut 9: La vie de la connexion. La session TLS reste généralement ouverte pour la prochaine requête (HTTP/2 multiplexe plusieurs requêtes sur une seule connexion). La connexion proxy-backend s'ouvre souvent pour réutilisation.
Chaque service web public suit une variante de cette forme. Savoir les sauts vous permet de raisonner sur où la latence s'accumule, où les journaux doivent être placés et où une erreur peut se cacher.
Où est passé le temps?
Un utilisateur se plaint que l'API semble lente. Vous mesurez et vous constatez que la demande prend 850 ms de bout en bout. Les journaux du serveur sur le backend montrent que l'application a traité la demande en 40 ms. Les journaux du proxy montrent que le proxy a passé 50 ms de son côté (échange de TLS + routage + écriture de la réponse).
Concevez une architecture minimale pour un nouveau service
Synthèse
Vous avez appris la différence entre un proxy en avant et en arrière, les trois tâches qu'un proxy en arrière gère simultanément, pourquoi cacher l'origine rapporte des dividendes chaque fois que vous avez besoin de changer quelque chose, et comment une demande circule d'un hôp à l'autre à travers le bord.
Maintenant, appliquez.
Une petite équipe prépare pour lancer un nouveau service appelé notes.example.com. Les utilisateurs y verront des notes personnelles. L'équipe utilisera deux VM de backend au lancement et prévoit de passer à dix au cours de l'année. Ils souhaitent avoir HTTPS pour les utilisateurs, un déploiement progressif pour les nouvelles versions et ne pas exposer publiquement les adresses IP des backends.
Où va cette formation ensuite
Où va cette formation ensuite
Cette leçon a établi la forme de la couche bord. Quatre autres leçons de ce cours s'appuient dessus:
- Échelle horizontale sans état: pourquoi un niveau de proxy (& les backends derrière lui) se multiplie à bon marché, et la mathématique pour dimensionner les comptes de replicas en cas de surcharge.
- Séparation des entrées/sorties: pourquoi une seule boîte de proxy gérant à la fois les flux entrants et sortants finit par échouer de manière surprenante, et comment séparer les couches.
- Modes de panne et rayon d'action: comment une seule modification de configuration déclenche une panne, et comment écrire des actions sans reproche qui préviennent la récurrence.
- Observabilité et capacité: quelles mesures à l'extérieur pour découvrir que quelque chose est cassé avant que les utilisateurs ne le fassent.
Chaque leçon peut être suivie indépendamment. Prises ensemble, elles vous donnent un modèle mental de flotte à l'échelle web.
Leçon complémentaire: geometry_of_proxies_and_origins reformule tout dans cette leçon sous forme de graphe orienté et explore ce que la théorie des graphes vous dit sur un chemin de demande.
Bien fait. En avant.