Comment les serveurs identifient les requêtes de service client à travers les segments réseau
Lorsqu'un client sur un segment réseau communique avec un serveur sur un autre, le serveur identifie le service demandé via des structures de messages définies par protocole — pas par la topologie réseau.
Le contrat de protocole
Chaque interaction client-serveur suit un protocole de couche application (HTTP, DNS, SMTP, SSH, MySQL, etc.). Chaque protocole définit :
- Format message : Structure requête/réponse, en-têtes, champs
- Identifiants service : Numéros de port, verbes méthode, chemins ressource, paramètres requête
- Encodage : Binaire, texte, enveloppé TLS
Exemples concrets
HTTP/HTTPS (Web)
- Client → Serveur :
GET /api/users/123 HTTP/1.1\r\nHost: api.exemple.com\r\n... - Serveur analyse : Méthode=GET, Chemin=/api/users/123, Host=api.exemple.com → Route vers service utilisateur
DNS
- Client → Port 53 : Requête DNS (QNAME=www.exemple.com, QTYPE=A)
- Serveur : Analyse QNAME/QTYPE → Retourne enregistrement A
Base de données (PostgreSQL)
- Client → Port 5432 : Message démarrage (utilisateur, base) → Protocole requête (Parse/Bind/Execute)
- Serveur : Authentifie utilisateur, route vers backend base de données
Rôle de la couche réseau
Routeurs/switches transfèrent paquets IP selon IP destination. Ils n'inspectent pas les payloads applicatifs (sauf pare-feu DPI/load balancers). L'OS serveur livre les paquets à la socket d'écoute (port) → l'application lit et interprète.
Découverte de service (Moderne)
Dans microservices/kubernetes : Client → Service Mesh (Envoy/Linkerd) ou API Gateway → résout nom service logique en endpoint → ajoute en-têtes routage → serveur identifie via en-têtes + chemin.
Point clé
Le réseau livre des paquets. Le protocole définit le sens. L'application serveur implémente le protocole pour extraire l'intention. La segmentation (VLANs, sous-réseaux) est transparente à ce processus — gérée aux couches 2/3.