Ce qui se trouve devant presque chaque service web
Bienvenue
Si vous tapez example.com dans un navigateur, vous ne réglez presque jamais l'appareil qui exécute réellement l'application. Vous atteignez un appareil qui transmet la demande vers celui qui le fait. Cet appareil de redirection s'appelle un proxy inverse.
Cette leçon enseigne ce que fait un proxy inverse, pourquoi presque chaque service web public en cache un, et ce que trois emplois la couche de bord gère en même temps.
À la fin, vous comprendrez:
- La différence entre un client, un proxy et une origine
- Pourquoi un proxy devant une origine protège, échelle et permet de remplacer des pièces sans que personne ne s'en aperçoive
- Les trois emplois d'un proxy inverse en même temps : cacher l'origine, terminer TLS et distribuer la charge sur plusieurs exemplaires
- Comment une demande voyage d'un navigateur à un proxy, puis vers le haut et retour, étape par étape
À la fin, vous raisonnerez avec confiance sur l'emplacement des proxies, la séparation des préoccupations à la couche de bord et pourquoi un niveau de proxy étatique se multiplie facilement tandis qu'une seule origine ne le fait pas.
Proxy Forward vs Proxy Inverse
Deux directions de proxy
Les deux types de proxy se trouvent entre deux parties et transmettent le trafic. Ils diffèrent en quelle partie ils représentent.
Proxy forward: se trouve entre un groupe de clients. Les clients connaissent un proxy; un serveur extérieur voit une adresse proxy, pas une adresse client.
Proxy inverse: se trouve entre un groupe de serveurs. Le monde extérieur (les clients) parle à une adresse proxy; les clients n'ont pas idée qu'un serveur réel se cache derrière.
Mnémonique: un proxy forward cache les clients des serveurs. Un proxy inverse cache les serveurs des clients.
Pourquoi s'inquiéter de la direction? L'emploi, les modes d'échec et la limite de sécurité diffèrent. Un proxy forward s'inquiète de qui ses utilisateurs contactent; un proxy inverse s'inquiète de qui contacte ses serveurs.
Un client envoyant du trafic à travers les deux types à la fois voyage: client -> proxy_forward -> internet -> proxy_inverse -> origin.
Pourquoi Il Y A Si Beaucoup à L'Edge
Le Niveau Edge Gagne Sa Vie
Un proxy inverse effectue trois tâches en même temps. Chacune d'entre elles justifie le niveau; effectuer toutes les trois au même adresse explique pourquoi presque chaque architecture web de production a la même forme à l'avant.
Tâche 1 : Cacher l'origine. Le proxy répond sur une IP publique. Les backends se trouvent sur des IPs privées que l'internet ne peut pas atteindre. Un attaquant qui souhaite atteindre l'origine doit d'abord compromettre le proxy.
Tâche 2 : Terminer TLS. Le proxy détient le certificat pour example.com et déchiffre les demandes HTTPS entrantes. Les backends parlent HTTP non chiffré (ou un TLS plus simple) au proxy sur un segment de réseau fiable. La rotation, la renouvellement et la politique de chiffrement vivent tous dans un seul endroit.
Tâche 3 : Distribuer le charge. Le proxy choisit quel backend gère chaque demande. Les backends derrière un proxy forment une pool; le proxy choisit un pour chaque demande en utilisant une stratégie (en rondin, moindre nombre de connexions, hachage sur une en-tête). Ajouter de la capacité signifie ajouter un backend au pool, pas dire à chaque client une nouvelle adresse.
Chaque tâche est un petit programme. Ensemble, elles expliquent pourquoi un niveau aussi simple que 'Caddy devant une application Python' porte plus de poids dans la conception que l'application Python elle-même.
Conception pour Toutes les Trois
Votre équipe gère une petite API sur un seul processus Python en écoute sur le port 8000 sur une seule VM. Le trafic a grandi assez pour que une seule VM ne puisse pas tenir le rythme et une revue de sécurité a signalé que la VM a une IP publique et gère son propre certificat TLS.
Vous décidez d'insérer un proxy inverse devant. Esquissez le plan : où pointe DNS, où vit le certificat, comment la charge atteint les backends et ce qui change concernant la VM d'origine?
Échanger une Composante Sans Que Personne Ne S'en Aperçoive
L'Indirection Achète de la Liberté
Une vieille maxime de l'informatique stipule : chaque problème peut être résolu en ajoutant une couche d'indirection (sauf le problème de trop de couches d'indirection). Le proxy inversé est l'une des indirections les plus utiles dans les systèmes distribués.
Ce qu'elle vous donne :
- Backends échangeables. Passer de Python à Go ? Migrer d'un autre centre de données ? Déployer une nouvelle version avec un arrêt zéro ? Chaque opération se déroule 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 du layer TLS. Le niveau backend s'échelle en fonction du travail de l'application. Chacun grandit selon son propre axe car ils vivent sur des machines différentes.
- Contenu de faute. Une mauvaise mise à jour sur le backend ne fait pas tomber l'adresse publique. Le proxy reste en ligne ; vous faites une correction ou un retrait ; le monde se reconnecte lorsque le backend se rétablit.
- Préoccupations transversales en un seul endroit. Limitation de vitesse, blocage géo, enregistrement des demandes, modification des en-têtes, mise en cache, compression des réponses : tout cela se trouve sur le proxy. Le code backend reste concentré sur l'application.
Sans le proxy chaque problème doit vivre à l'intérieur du processus de l'application. Avec le proxy, ils vivent à un layer qui est gérée par une seule équipe.
Le coût : une autre couche à gérer. Les équipes expérimentées acceptent ce coût car le niveau de proxy lui-même fonctionne sans état et s'échelle horizontalement ; remplacer un proxy par deux nécessite aucune coordination.
Un Déploiement Bleu/Vert À Travers le Proxy
Votre équipe utilise la version 1 de l'API sur trois VM de backend (pool bleu) derrière un proxy inversé. Vous souhaitez déployer la version 2 avec la possibilité de revenir en arrière en moins de trente secondes si quelque chose se passe 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 routé de trafic vers eux.
De Navigateur à Backend et Retour
Suivez une Demande HTTPS de A à Z
Suivez une seule requête GET HTTPS https://api.example.com/users/42 à travers un proxy inversé devant une pool de backends.
Étape 1: Résolution DNS. Le navigateur demande un résolveur api.example.com. Le résolveur retourne l'IP publique du proxy (par exemple, 203.0.113.10). Le navigateur ouvre une connexion TCP vers 203.0.113.10:443.
Étape 2: Main de clé TLS. Le proxy présente son certificat pour api.example.com. Le navigateur valide le certificat, les deux parties conviennent d'une clé de session et le canal chiffré est ouvert.
Étape 3: Envoi de la requête HTTP à l'intérieur du TLS. Le navigateur envoie GET /users/42 HTTP/1.1\nHost: api.example.com\n.... Le proxy déchiffre les octets de la requête.
Étape 4: Sélection du backend. Le proxy consulte sa pool d'origine pour api.example.com et choisit un backend (par exemple 10.0.0.21:8000) en utilisant sa stratégie de balance de charge.
Étape 5: Demande vers le haut. Le proxy ouvre (ou réutilise) une connexion HTTP en clair vers 10.0.0.21:8000 et renvoie la demande. Le proxy peut modifier les en-têtes en cours: ajouter X-Forwarded-For: <client-ip>, définir Host: correctement, supprimer les en-têtes comme Connection qui doivent être ré-écris à chaque étape.
Étape 6: Traitement du backend. L'application backend lit la demande, interroge sa base de données et construit une réponse JSON.
Étape 7: Réponse vers le haut. Le backend envoie la réponse de retour au proxy en HTTP en clair.
Étape 8: Réponse de bord. Le proxy peut modifier ou compresser la réponse, la chiffre à nouveau via la session TLS et l'envoyer au navigateur.
Étape 9: Cycle de vie de la connexion. La session TLS reste généralement ouverte pour la prochaine demande (HTTP/2 multiplexe plusieurs demandes sur une seule connexion). La connexion proxy-vers-backend est souvent partagée pour réutilisation.
Chaque service web public suit une variante de cette forme. Savoir les étapes vous permet de raisonner sur où la latence s'accumule, où la journalisation doit être placée 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 requête prend 850 ms du début à la fin. Les journaux serveur sur le back-end indiquent que l'application a servi la requête en 40 ms. Les journaux du proxy montrent que le proxy a passé 50 ms de son temps pour travailler (échange TLS + routage + écriture de la réponse).
Concevez une architecture minimale d'edge pour un nouveau service
Synthèse
Vous avez appris la différence entre un proxy en avant et un proxy 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 requête circule d'un saut à l'autre à travers l'edge.
Appliquez cela maintenant.
Un petit équipe prévoit de lancer un nouveau service appelé notes.example.com. Les utilisateurs lirent et écrivent des notes personnelles. L'équipe prévoit de démarrer avec deux VM back-end et s'attend à les échelonner jusqu'à dix au cours de l'année à venir. Ils souhaitent disposer de HTTPS pour les utilisateurs, un déploiement progressif pour les nouvelles versions et ne pas exposer publiquement les adresses IP back-end.
Où va ce cours à la prochaine
Où va ce cours à la prochaine
Cette leçon a établi la forme de la couche edge. Quatre autres leçons de ce cours s'appuient dessus:
- Échelle horizontale sans état: pourquoi un niveau de proxy (& les backends derrière lui) peut être multiplié à bon marché, et la mathématique pour dimensionner les comptes de replicas sous haubanage.
- Séparation des flux entrants et sortants: pourquoi une boîte proxy unique qui gère à la fois le trafic entrant et sortant finit par échouer de manière surprenante, et comment diviser les couches.
- Modes de panne et rayon d'action: comment une modification de configuration se propage en panne, et comment écrire des éléments d'action sans faute qui préviennent la récurrence.
- Observabilité et capacité: ce qu'il faut mesurer à l'extrémité pour découvrir que quelque chose ne marche pas avant que les utilisateurs ne le fassent.
Chaque leçon peut se passer individuellement. Prises ensemble, elles vous donnent un modèle mental de flotte à échelle web.
Leçon complémentaire: geometry_of_proxies_and_origins reformule tout dans cette leçon en tant que graphe orienté et explore ce que la théorie des graphes vous dit sur le chemin d'une demande.
Bien fait. En avant.