Niveau 🟢 débutant
Durée estimée : 15 min · Prérequis : Processus et services
Un serveur, c'est un immeuble de bureaux avec plusieurs guichets numérotés. Chaque guichet
(un port) traite un type de demande précis, avec sa propre façon de parler (un
protocole) : le guichet 80 parle le langage du web en clair, le 443 le même mais chiffré, le
22 celui de l'administration à distance. Un client est quelqu'un qui vient frapper à l'un
de ces guichets avec une demande précise, dans la langue attendue. Une socket est la
conversation ouverte entre le visiteur et le guichetier, le temps de l'échange.
Le modèle client/serveur est le principe d'organisation de la quasi-totalité des échanges
réseau : un serveur est un programme qui attend passivement des demandes et y répond ; un
client est un programme qui initie une demande. Le navigateur qui affiche cette page est un
client ; le serveur web qui la lui a envoyée est un serveur. Le même mot « serveur » désigne
donc à la fois la machine physique (vue en page 1) et le rôle logiciel qu'un programme y joue —
une machine peut faire tourner plusieurs serveurs (services) à la fois.
Le port est un numéro (de 0 à 65535) qui identifie, sur une même machine, à quel service
une demande s'adresse. Une machine a une seule adresse IP mais peut faire tourner des dizaines
de services simultanément — le port est ce qui les distingue : le web sur le port 80/443, SSH
sur le 22, une base de données sur le 5432, etc. Certains ports sont réservés par convention
(0-1023, ports « bien connus » — well-known ports), les autres sont libres.
Le protocole est le langage utilisé pour cet échange : un ensemble de règles précises sur le
format des messages, l'ordre des échanges, la gestion des erreurs. HTTP (le web), SSH
(l'administration à distance), DNS (la résolution de noms, vue en M2) sont tous des protocoles,
chacun conçu pour un usage précis.
La socket est le point de terminaison concret d'une connexion réseau : la combinaison d'une
adresse IP et d'un port, côté client comme côté serveur. C'est ce qui permet à un serveur de
gérer des milliers de connexions simultanées sans les confondre : chaque connexion a sa propre
paire de sockets (client, serveur), même si plusieurs clients parlent au même port du même
serveur en même temps.
Le déroulé d'une requête, simplifié : le client ouvre une connexion vers adresse:port du
serveur → le serveur, qui « écoute » (listen) sur ce port, accepte la connexion → les deux
échangent selon le protocole convenu → la connexion se ferme (ou reste ouverte, selon le
protocole).
🧪 Concrètement, sur notre exemple : chaque service du serveur de ce wiki (reverse proxy,
supervision, monitoring) écoute sur son propre port, dans son propre conteneur Docker. Le
reverse proxy est le seul point d'entrée réseau commun : il reçoit les requêtes sur les ports
web standards et les redirige en interne vers le bon service selon le nom de domaine demandé
— ce mécanisme est détaillé en M2 (reverse proxy) une fois le réseau posé.
Le client initie toujours l'échange — un serveur n'appelle jamais un client de sa propre
initiative dans ce modèle. La socket matérialise la connexion active entre les deux, le temps de
l'échange.
ss -tulnp
# Liste les sockets en écoute (-l) sur la machine, TCP (-t) et UDP (-u),
# avec les numéros de port (-n) et le processus propriétaire (-p, nécessite sudo).
sudo ss -tulnp | grep :22
# Filtre sur le port 22 (SSH) -- confirme qu'un service y écoute, et lequel.
ss (socket statistics, successeur de l'ancien netstat) répond à la question « qui écoute
où, sur cette machine ? » — la première commande à lancer pour diagnostiquer « pourquoi je
n'arrive pas à joindre ce service ».
sudo ss -tulnp | grep LISTEN
Doit afficher au moins une ligne (souvent SSH sur le port 22). Chaque ligne indique le port
local, l'état (LISTEN), et si sudo a été utilisé, le nom du processus qui écoute.
| Symptôme | Cause probable | Solution |
|---|---|---|
| Confondre adresse IP et port | Les deux apparaissent souvent ensemble (ip:port) |
L'IP identifie la machine sur le réseau ; le port identifie le service sur cette machine |
| « Le service ne répond pas » sans vérifier s'il écoute | Diagnostic qui saute une étape | ss -tulnp d'abord : le service écoute-t-il seulement sur le port attendu ? |
| Croire qu'un serveur peut initier une connexion vers un client | Confusion avec d'autres modèles (peer-to-peer) | Dans le modèle client/serveur classique, c'est toujours le client qui ouvre la connexion |
ss -tulnp est l'outil de base pour voir ce qui écoute où sur une machine.Oui — c'est justement le rôle du port : distinguer les services sur une même adresse IP. Chaque
service écoute sur un port différent.
Toujours le client. Le serveur reste passif, en écoute, jusqu'à ce qu'une demande arrive.
À lister les sockets en écoute sur la machine : quels ports sont ouverts et quel processus les
occupe — la première commande pour diagnostiquer un service injoignable.
Sur une machine Linux à disposition, lance sudo ss -tulnp et identifie au moins deux services
différents en écoute, avec leur port et le nom du processus associé.
port ·
socket ·
protocole ·
client ·
HTTP
Cette formation est proposée par Deladev, studio web de Loïc D. — création de sites et d'applications, accompagnement et formation sur mesure.
Les projets réalisés · Prestations et tarifs · Le blog tech · Me contacter
Écrite par Loïc D. avec l'assistance de Claude (Anthropic) — un travail à deux.
© 2026 Deladev — publiée sous licence CC BY-NC-ND 4.0. Vous pouvez la lire, y renvoyer par un lien, la partager et la citer en créditant la source. La revendre, l'utiliser dans une prestation ou une formation payante, la republier même partiellement ailleurs, en diffuser une version modifiée ou l'exploiter pour entraîner un modèle d'IA nécessitent une autorisation écrite — pour un usage interne en entreprise, c'est souvent oui, il suffit de demander.