Répartiteur de charge : Load balancer
Infrastructure
Composant réseau qui reçoit les requêtes destinées à un service et les distribue entre plusieurs serveurs équivalents selon un algorithme donné. Il écarte au passage les serveurs qui ne répondent plus, ce qui apporte à la fois montée en charge et tolérance aux pannes.
Couche 4 ou couche 7 : En couche 4, il aiguille des connexions TCP ou UDP d'après les adresses et les ports, sans lire le contenu. En couche 7, il inspecte le HTTP (chemin, en-têtes, cookies) et route plus finement, au prix de davantage de calcul.
Algorithmes de répartition : Tourniquet (round-robin), moindre nombre de connexions, pondération ou hachage de l'adresse source : chacun correspond à un profil de trafic. Le tourniquet reste le choix par défaut, ce qui ne signifie pas que quelqu'un l'a choisi.
Sondes de santé : Il interroge régulièrement chaque serveur (port ouvert, URL de contrôle) et retire du pool ceux qui échouent. Une sonde trop laxiste continue d'envoyer du trafic vers un serveur déjà tombé.
Affinité de session : Quand l'application garde un état local, il faut renvoyer un même client vers le même serveur (sticky session), par cookie ou hachage. Cela dépanne, mais déséquilibre la charge et rend la perte d'un nœud plus douloureuse.
Ce qui arrive si on s'en passe
Sans répartiteur de charge, les clients s'adressent directement à un serveur unique, ou à plusieurs serveurs annoncés sans aucun contrôle d'état. La panne d'une machine rend alors le service indisponible, ou fait échouer la part des requêtes encore dirigées vers elle, tant qu'une intervention manuelle ou l'expiration d'un cache DNS ne l'a pas écartée. Un pic de trafic, qu'il soit légitime ou provoqué, se concentre sur un seul hôte : il suffit de saturer celui-ci pour interrompre le service, ce qui rend un déni de service plus facile à obtenir. Chaque serveur doit en outre être joignable directement, ce qui expose ses adresses et élargit la surface d'attaque. Enfin, une mise à jour ou un redémarrage entraîne une coupure visible, puisqu'aucun mécanisme ne permet de retirer un serveur du groupe pendant que les autres continuent de répondre.
Explication de la marmotte
Imagine une cantine avec cinq caisses. Si tout le monde fait la queue à la même caisse, c'est l'embouteillage pendant que les quatre autres caissiers s'ennuient. Alors on place à l'entrée une personne qui regarde les files et envoie chaque élève vers la caisse la moins chargée. Si un caissier part en pause ou tombe malade, elle arrête d'envoyer du monde vers lui, et personne ne reste bloqué. Sur internet, c'est pareil : quand des milliers de gens visitent le même site, un programme placé devant plusieurs ordinateurs identiques répartit les visiteurs entre eux, pour que le site reste rapide et continue de marcher même si une machine lâche.
Où ce terme est utilisé
- QUIC, HTTP moderne, TLS et proxys applicatifs (3 occurrences)
- Jetons d'accès liés au certificat client : ce que mTLS ajoute à OAuth (2 occurrences)
- NAT, translations et publication de services (2 occurrences)
- Sécuriser un load balancer cloud et la terminaison TLS (2 occurrences)
- Attaque cache deception CDN et contre-mesures (1 occurrence)
- Authentification défi-réponse, rejeu, relais et attaque hors ligne (1 occurrence)
- Calculer le coût d’un LLM local à grande échelle (1 occurrence)
- Cloud networking, VPC/VNet, CDN et équilibrage (1 occurrence)
- Démonstration de pollution de prototype JavaScript (1 occurrence)
- Diagnostiquer les erreurs de validation TLS en production (1 occurrence)