En pratique, un même logiciel (Nginx, HAProxy, Traefik) peut assurer les deux fonctions. C'est pourquoi les deux termes sont souvent confondus. Mais, conceptuellement, ils résolvent des problèmes différents : le reverse proxy est un intermédiaire, le load balancer un répartiteur.
Différence conceptuelle
Tout load balancer peut être une forme de reverse proxy, mais tout reverse proxy n'est pas un load balancer. Un Nginx placé devant un serveur unique ne répartit pas la charge, mais remplit bien un rôle de reverse proxy.
Distinction couche 4 / couche 7
La répartition en couche 7 lit le contenu : elle peut envoyer les requêtes « /api » vers tel serveur et les requêtes « /statique » vers tel autre. La couche 4, elle, est plus rapide mais ignore le contenu.
Algorithmes de répartition de charge
L'IP hash s'utilise pour les applications nécessitant une stickiness de session : le même utilisateur est toujours dirigé vers le même serveur, ce qui évite d'avoir à partager les données de session.
Architecture type
Dans les systèmes réels, les deux fonctionnent ensemble. Les couches s'enchaînent ainsi :
| Couche | Composant | Rôle |
|---|---|---|
| 1 | DNS / Anycast | Dirige l'utilisateur vers la région la plus proche |
| 2 | CDN | Sert le contenu statique depuis l'edge |
| 3 | Load balancer (L4) | Répartit le trafic au sein de la région |
| 4 | Reverse proxy (L7) | Termine le TLS, applique les règles de routage |
| 5 | Serveurs applicatifs | Font le travail effectif |
Il n'y a de forward proxy nulle part dans cette architecture — car il se trouve à l'autre bout de la chaîne, du côté de l'utilisateur. La distinction dans notre article sur le forward proxy et le reverse proxy .
Health checks
C'est là que le load balancer se distingue le plus nettement du reverse proxy : il surveille en continu la santé des serveurs situés derrière lui et retire du pool ceux qui sont défaillants.
Cette logique est rigoureusement identique à celle de la gestion d'un pool de proxys. Dans notre article sur les pools nous avons décrit l'équivalent de ce même schéma côté client.
Pourquoi est-ce important lors de la collecte de données ?
Le load balancer du site cible peut répartir vos requêtes sur différents serveurs. Cela peut entraîner des résultats incohérents :
- Versions différentes : pendant un déploiement progressif, certains serveurs peuvent exécuter la nouvelle version.
- Perte de session : sans stickiness de session, vos cookies peuvent ne pas être reconnus sur un autre serveur.
- Temps de réponse variable : des écarts de performance peuvent exister entre les serveurs.
- Tests A/B : des requêtes différentes peuvent voir des variantes différentes.
Pour réduire ces incohérences, il est utile d'utiliser des sessions sticky et d'envoyer les requêtes consécutives depuis la même IP.
Résumé
Le reverse proxy est un intermédiaire qui reçoit les requêtes et les transmet ; le load balancer est un composant qui répartit ces requêtes entre plusieurs serveurs et surveille leur santé. Un même logiciel pouvant assumer les deux rôles, les termes se confondent. La répartition en couche 4 est rapide mais ignore le contenu, tandis que la répartition en couche 7 est consciente du contenu mais plus coûteuse. Lors d'une collecte de données, ces couches côté cible peuvent être la cause cachée de résultats incohérents et de sessions interrompues.