Layer 4 vs Layer 7 Load Balancing : Un guide pratique de décision

La distinction de couche OSI qui compte toujours

Le concept de répartition de charge est simple : distribuer les requêtes entrantes sur plusieurs instances de service pour qu'aucun serveur ne soit submergé et que l'application reste disponible. Ce qui est intéressant, c'est la manière dont vous prenez cette décision de distribution. La division la plus conséquente se situe entre Layer 4 et Layer 7.

Layer 4 Load Balancing fonctionne sur la couche transport du modèle OSI — TCP et UDP. Le load balancer voit l'IP source, l'IP de destination et les ports d'une connexion ; rien de plus. Il prend sa décision de distribution à partir de ces champs d'en-tête puis fait passer les octets sans inspecter la charge utile. Le protocole d'application peut être HTTP, MySQL, Kafka ou un protocole binaire personnalisé — le load balancer ne le sait pas et s'en moque.

Layer 7 Load Balancing fonctionne sur la couche application — HTTP, HTTPS, gRPC, WebSocket. Le load balancer analyse chaque requête, lit le chemin URL, les en-têtes, les cookies et la méthode, et prend des décisions de routage basées sur ce contenu. Il peut également transformer les requêtes au passage : compression, réécriture d'en-têtes, terminaison TLS, mise en cache.

Layer 7 est plus puissant que Layer 4 et plus coûteux que Layer 4. Le choix entre les deux dépend de la forme HTTP du protocole d'application et de la pertinence des capacités supplémentaires par rapport au coût par connexion.

Quand Layer 7 est le bon choix

Ce qui distingue L7, c'est sa capacité à prendre des décisions de routage et de transformation basées sur le contenu de l'application. Sans cette capacité, la plupart des applications web modernes ne fonctionneraient pas.

Le routage basé sur URL est le cas le plus courant. Envoyer différents chemins vers différents clusters de services — /api/v1/users vers un cluster, /api/v1/orders vers un autre, /static/* vers un CDN — n'est pas possible avec L4 car L4 ne voit pas les chemins.

Le routage basé sur en-tête ou cookie nécessite aussi L7. Tests A/B, fixation de version (X-Service-Version : 2.5 route vers un déploiement spécifique), affinité de session par ID de session d'application et routage par client via en-tête — tout cela exige de lire le contenu d'application.

La terminaison TLS est également un travail L7. SSL offload termine TLS au load balancer, libérant les services du travail cryptographique ; il permet la gestion centralisée des certificats ; il permet l'inspection WAF. La WAF a besoin de texte en clair pour voir les attaques ; cela n'arrive pas sans L7.

Les fonctionnalités conscientes de l'application — compression, mise en cache, réécriture de requêtes, health checks basés sur contenu (le service renvoie 200 sur /health, et n'accepte pas simplement une connexion) et rétrogradation HTTP/2 vers HTTP/1.1 pour les services hérités — nécessitent aussi L7.

L'observabilité au niveau application suit la même logique. Latence par endpoint, taux d'erreur par URL, détection de requêtes lentes — ces éléments nécessitent de voir les requêtes, pas les connexions. L7 expose ces données ; L4 ne voit que le niveau connexion.

Le point central est le suivant : si vous décidez sur la base du contenu d'application, L7 est obligatoire. Si vous ne décidez qu'au niveau connexion, L4 suffit.

Les déploiements modernes utilisent les deux

La décision est rarement « L4 ou L7 » pour toute une infrastructure. Elle se prend par application — parfois par listener.

Un schéma d'entreprise typique combine les deux modes. L7 en bordure pour le trafic HTTPS des utilisateurs ; L4 pour le trafic interne est-ouest où le protocole est nativement TCP et où le budget de latence est serré ; L7 à nouveau là où le trafic est-ouest passe par RPC sur HTTP, comme gRPC.

La question architecturale est de savoir si un seul déploiement de load balancer peut gérer les deux modes ou si l'organisation doit faire fonctionner des produits L4 et L7 séparés. L'approche par produits séparés était historiquement courante parce que L4 et L7 avaient des exigences d'implémentation différentes — L4 voulait un réseau kernel-bypass, L7 voulait une analyse HTTP riche. Les ADCs modernes ont comblé cet écart ; le même appareil gère les deux modes via une configuration par listener.

L'avantage opérationnel de les combiner est le même que pour toute consolidation : un produit à déployer, une surface d'observabilité, un ensemble de runbooks opérationnels, un chemin de mise à niveau. Pour les organisations qui faisaient auparavant fonctionner des produits L4 et L7 de fournisseurs séparés, la consolidation sur un seul ADC est souvent la plus grande simplification opérationnelle disponible.