La couche application

Une application réseau se compose de programmes exécutés sur des systèmes terminaux : téléphones, ordinateurs portables et serveurs. Leurs processus échangent des messages à travers le réseau. Les routeurs et les commutateurs transfèrent les paquets ; il n’est pas nécessaire d’y installer un nouveau programme applicatif chaque fois qu’un nouveau service est créé.

Deux façons de répartir le travail

Une architecture applicative décrit la manière dont l’application répartit le travail entre les hôtes. Elle est distincte de l’architecture en couches du réseau. Le développeur choisit où les programmes s’exécutent en s’appuyant sur le réseau existant pour les connecter.

Dans une architecture client-serveur, les clients contactent un serveur toujours actif à une adresse connue. Un navigateur demande un document à un serveur web, qui le renvoie. Les autres navigateurs n’ont pas besoin d’être connectés pour que cet échange fonctionne. Un service populaire peut répartir son rôle de serveur sur des milliers de machines dans des centres de données ; un seul nom public peut représenter ce groupe. Le matériel, l’électricité, le refroidissement et les connexions Internet ont tous un coût.

Une architecture pair à pair, ou P2P, permet aux appareils des utilisateurs d’échanger directement des données. Un pair peut demander un fragment de fichier et envoyer aussi des fragments qu’il possède déjà. Les pairs peuvent se déconnecter ou changer d’adresse ; l’application doit donc trouver des pairs disponibles et continuer à fonctionner lorsque les participants changent.

Suis un échange

Supposons qu’un groupe de recherche distribue un grand jeu de données. Dans une architecture client-serveur, chaque chercheur télécharge une copie depuis le serveur du groupe. Dix nouveaux chercheurs représentent dix copies supplémentaires à envoyer pour ce serveur. Dans une architecture P2P, les chercheurs qui possèdent déjà certains fragments les envoient aux nouveaux arrivants. Chaque chercheur qui rejoint le réseau peut ajouter de la capacité en même temps que de la demande. C’est l’auto-extensibilité : les ressources de l’application augmentent avec la participation.

L’auto-extensibilité dépend toutefois de contributions utiles. Un pair dont la liaison d’envoi est lente ajoute moins de capacité qu’un pair doté d’une liaison rapide. De nombreuses liaisons résidentielles sont asymétriques : le téléchargement est plus rapide que l’envoi. Un pair qui se déconnecte ne contribue plus tant qu’il est hors ligne. Les logiciels P2P doivent aussi protéger les participants contre les pairs non fiables et encourager les utilisateurs à envoyer des données au lieu de se contenter d’en recevoir.

Coordination centrale et transfert direct

Une architecture hybride associe une coordination par serveur à un transfert de données en P2P. Un serveur de suivi BitTorrent renseigne un pair sur les autres pairs ; il n’a pas besoin d’envoyer le fichier lui-même. De même, un service d’appel peut localiser les participants par un serveur, laisser leurs appareils échanger directement les données audio et vidéo et utiliser un relais lorsqu’un chemin direct n’est pas disponible. Classe séparément le chemin qui transporte les données et celui qui sert à l’établir.

Les mots client et serveur désignent aussi des rôles dans un échange particulier. Si le pair Mira prend l’initiative d’envoyer une requête au pair Leo, Mira est le client et Leo le serveur pour cet échange. Ils peuvent inverser leurs rôles un instant plus tard. Le P2P supprime la dépendance à des serveurs de contenu dédiés ; il ne supprime pas les rôles de celui qui prend l’initiative et de celui qui répond.

Un programme applicatif en cours d’exécution est un processus. Les processus situés sur des hôtes différents échangent des messages par des sockets, les interfaces logicielles entre les couches application et transport. Le code de l’application détermine le sens du message ; le service de transport achemine ses octets ou ses datagrammes.

Trouver le processus récepteur

Une adresse IP identifie un hôte, mais celui-ci peut exécuter de nombreux services. Un numéro de port identifie un point de terminaison de transport sur cet hôte. Pour contacter un service HTTPS à l’adresse 203.0.113.10, un client vise normalement le port 443. Son propre système d’exploitation lui attribue généralement un port source temporaire, dit éphémère.

Les ports sont des valeurs sur 16 bits, allant de 0 à 65 535. Les ports système occupent la plage de 0 à 1023, les ports enregistrés celle de 1024 à 49 151 et les ports dynamiques celle de 49 152 à 65 535. Parmi les ports de service courants figurent HTTP 80, HTTPS 443, le transfert SMTP 25 et DNS 53. Un port fait partie de l’adressage : il n’indique pas que le trafic est chiffré ou digne de confiance.

Définir les messages

Un protocole de la couche application définit les types de messages, leur syntaxe, leur sémantique et les règles d’échange. Les types distinguent une requête d’une réponse. La syntaxe décrit les champs et les séparateurs. La sémantique indique à chaque participant ce que signifient ces champs. Les règles d’échange déterminent quand un processus envoie un message et comment le récepteur répond. Les spécifications publiques, souvent des RFC, permettent à des programmes écrits par différents développeurs de communiquer.

Un protocole est une composante d’une application. Le Web a aussi besoin de navigateurs, de serveurs et de documents. Définir HTTP ne suffit pas à construire un navigateur ni à décider de l’apparence de son interface.

Adapter le service au besoin

Considère quatre besoins : un acheminement correct, un débit effectif suffisant, un délai acceptable et la sécurité. Une pièce jointe à un courriel exige chaque octet. Un appel vocal peut tolérer la perte d’une partie du son, mais pâtit de l’arrivée trop tardive de données audio anciennes. Une vidéo stockée nécessite un débit effectif soutenu proche de son débit binaire encodé, tandis qu’un téléchargement élastique peut utiliser le débit disponible.

TCP comprend un contrôle de flux pour protéger le récepteur et un contrôle de congestion pour réduire la surcharge du réseau. Il ne garantit ni capacité minimale ni échéance d’acheminement. UDP lui-même n’ajoute ni fiabilité ni contrôle de congestion. Le choisir ne supprime pas la congestion sur le chemin.

Par exemple, un jeu qui envoie des positions 30 fois par seconde produit une nouvelle mise à jour environ toutes les 33 ms. Il peut utiliser UDP pour qu’une mise à jour perdue soit remplacée par une plus récente sans attendre sa retransmission. La messagerie du jeu a toutefois besoin d’un acheminement fiable, assuré soit par TCP, soit par un mécanisme de fiabilité ajouté à son propre protocole.

Ajouter la sécurité à la pile

Ni TCP ni UDP, utilisés seuls, ne chiffrent les données applicatives. HTTP/1.1 et HTTP/2 utilisent couramment TLS sur TCP pour HTTPS. TLS ajoute la confidentialité, l’intégrité et l’authentification du serveur. HTTP/3 utilise QUIC sur UDP ; QUIC fournit la fiabilité, le contrôle de congestion et TLS 1.3 intégré. Une vidéo stockée fournie par HTTP utilise donc TCP ou QUIC, tandis que les appels interactifs transportent souvent le son et la vidéo sur UDP.

Une page web comprend généralement plusieurs objets, chacun ayant sa propre URL. Le fichier HTML de base désigne les images, scripts et autres fichiers. Dans https://www.example.org/docs/intro.html, le schéma est https, l’hôte est www.example.org et le chemin est /docs/intro.html.

Lire une requête et une réponse

HTTP fonctionne par échanges de requêtes et de réponses. Une requête HTTP/1.1 commence par une méthode, un chemin et une version :

GET /docs/intro.html HTTP/1.1
Host: www.example.org
Connection: close

La ligne de requête et les lignes d’en-tête se terminent par CRLF. Une ligne vide marque la fin des en-têtes, suivie d’un corps facultatif. Host est obligatoire en HTTP/1.1, car plusieurs sites peuvent partager une adresse de serveur. Connection: close demande la fermeture après la réponse.

GET récupère un objet. HEAD demande les en-têtes de sa réponse sans le corps. POST envoie des données dans le corps d’une requête ; une requête GET peut aussi transporter des valeurs de formulaire dans la chaîne de requête de son URL. PUT stocke un objet à une URL donnée et DELETE supprime un objet.

La réponse commence par une ligne d’état comme HTTP/1.1 200 OK, suivie des en-têtes, d’une ligne vide et du corps. Content-Type identifie la représentation ; Content-Length donne sa longueur en octets. Les classes de codes d’état sont 1xx pour l’information, 2xx pour le succès, 3xx pour la redirection, 4xx pour les erreurs du client et 5xx pour les erreurs du serveur. Un code 301 indique une nouvelle URL dans Location ; 304 permet de réutiliser une copie en cache. Un code 404 signifie que le serveur a répondu que l’objet demandé était introuvable, et non que le serveur était inaccessible. D’autres codes utiles sont 400, 500 et 505.

HTTP est sans état : chaque requête peut être comprise sans les requêtes précédentes. Un site web peut tout de même conserver un état de connexion ou de panier au-dessus de HTTP. Une requête GET ordinaire répétée peut renvoyer à nouveau l’objet, tandis qu’une requête conditionnelle peut valider une copie enregistrée.

Compter les allers-retours

Pour un objet sur une nouvelle connexion TCP, compte un RTT pour l’établissement de la connexion et un autre pour la requête et le début de la réponse. Ajoute ensuite le temps de transmission de l’objet. Avec un RTT de 30 ms, une taille de 500 kB et un débit de 50 Mbps :

Le total est de 60 ms plus 80 ms, soit 140 ms. Ce modèle néglige DNS, TLS et le temps de traitement. Une négociation TLS 1.3 complète sur la nouvelle connexion TCP ajoute un RTT.

Réutiliser ou rouvrir la connexion

Une connexion non persistante transporte un objet. Une connexion persistante peut transporter des requêtes ultérieures sans nouvel établissement TCP. La persistance est le fonctionnement par défaut de HTTP/1.1, même si les connexions inactives finissent par être fermées.

Pour un objet HTML et huit petites images, un RTT de 20 ms et des temps de transmission négligeables :

Les requêtes d’images dépendent de la réception du HTML. Même avec une récupération parallèle, elles ne peuvent pas commencer avant que leurs URL soient connues. Compte ces étapes de dépendance avant de compter les négociations. Les navigateurs HTTP/1.1 utilisent couramment plusieurs connexions par hôte ; la transmission en pipeline est un modèle de calcul du temps, pas une condition de la persistance.

Les requêtes HTTP sont indépendantes, et pourtant une boutique peut se souvenir d’un panier. Un navigateur peut aussi réutiliser une image au lieu de la télécharger à nouveau. Les cookies permettent la reconnaissance d’une requête à l’autre ; les caches permettent la réutilisation des réponses.

Suivre un cookie

Lors d’une première visite, shop.example.com crée une entrée dans une base de données pour un visiteur et renvoie Set-Cookie: id=1678. Le navigateur stocke cette valeur. Les requêtes ultérieures correspondantes incluent Cookie: id=1678, ce qui permet au serveur de retrouver le panier. Le cookie est une donnée, pas du code exécutable, et le panier lui-même peut rester dans la base de données du serveur.

Les attributs d’un cookie contrôlent son utilisation. Expires ou Max-Age fixe une durée de vie ; un cookie sans l’un ni l’autre est un cookie de session. Domain et Path limitent les requêtes correspondantes. Secure limite l’envoi à HTTPS, HttpOnly empêche l’accès par les scripts de la page et SameSite contrôle l’envoi dans des contextes impliquant d’autres sites. La restauration d’une session peut conserver les cookies de session lorsqu’un navigateur restaure une session précédente.

Les cookies internes appartiennent au site visité. Un service tiers intégré peut utiliser des cookies sur différents sites pour reconnaître un navigateur. Safari bloque les cookies tiers par défaut ; Firefox les sépare par site ; Chrome fournit des commandes à l’utilisateur et les bloque en navigation privée. Les règles de l’Union européenne exigent un consentement pour les cookies qui ne sont pas strictement nécessaires à la fourniture d’un service demandé.

Suivre une requête avec un cache

Un cache web stocke des réponses HTTP. Un navigateur possède son propre cache. Un serveur mandataire avec cache se situe entre les clients et les serveurs d’origine : il fournit directement la réponse en cas de succès de cache, ou récupère, stocke et transmet une réponse en cas d’échec. Il joue le rôle de serveur auprès du navigateur et de client auprès du serveur d’origine. Un serveur mandataire peut exister sans mise en cache.

Un succès dans un cache proche réduit le délai, la charge du serveur d’origine et le trafic sur la liaison d’accès. Pour 90 requêtes par seconde portant sur des objets de 1 Mbit en moyenne, le trafic offert est de 90 Mbps. Sur une liaison d’accès à 100 Mbps, l’intensité du trafic est de 0,9, niveau auquel les files d’attente peuvent devenir importantes. Un taux de succès de 40 % laisse passer 60 % du trafic sur la liaison : 54 Mbps et une intensité de 0,54. Si les succès prennent 10 ms et les échecs 200 ms, le temps de réponse moyen est :

Ce calcul de trafic suppose que la taille moyenne des objets est la même dans les groupes correspondant aux succès et aux échecs. Un taux de succès mesuré uniquement selon le nombre de requêtes n’est pas nécessairement égal à la proportion d’octets économisés lorsque les tailles des objets diffèrent.

Vérifier l’actualité avant la réutilisation

Une requête GET conditionnelle envoie If-Modified-Since avec une date de modification enregistrée, ou If-None-Match avec un ETag enregistré. Un objet inchangé donne une réponse 304 Not Modified sans corps contenant l’objet. Le cache réutilise sa copie. Un objet modifié donne une réponse 200 OK avec l’objet de remplacement. La validation évite la transmission du corps, mais nécessite tout de même un aller-retour jusqu’au serveur d’origine.

Un serveur mandataire partagé ne peut normalement pas inspecter le contenu d’une connexion HTTPS qui le traverse. Les caches des navigateurs et les serveurs CDN qui fournissent du contenu pour le compte d’un site peuvent mettre en cache les réponses aux extrémités où elles sont disponibles sous une forme lisible.

Les versions de HTTP conservent le sens des méthodes, des codes d’état, des champs et des URL. Un code 404 signifie toujours que la ressource demandée est introuvable. Ce qui change, c’est la manière dont les requêtes et les réponses circulent : HTTP/1.1 utilise des messages textuels, tandis que HTTP/2 et HTTP/3 utilisent des trames binaires.

Permettre aux petites réponses d’avancer

Sur une connexion HTTP/1.1, l’ordre des réponses peut faire attendre un petit objet derrière un gros. C’est le blocage en tête de file au niveau applicatif. L’ouverture de plusieurs connexions TCP réduit cette attente, mais entraîne des coûts d’établissement supplémentaires et donne à la page plusieurs connexions concurrentes soumises au contrôle de congestion.

HTTP/2 divise les messages en trames et attribue un flux à chaque échange requête-réponse. L’émetteur entrelace les trames de différents flux sur une seule connexion TCP. La compression des en-têtes, appelée HPACK, réduit les données de champ répétées. Les priorités peuvent orienter le choix des réponses à traiter en premier.

Pour une comparaison simplifiée, une grande réponse comporte 1 000 trames et huit petites réponses comportent deux trames chacune. Envoie une trame par créneau de temps. Si la grande réponse est envoyée en premier, les petites se terminent aux créneaux 1 002 à 1 016, avec une moyenne de 1 009. L’envoi à tour de rôle d’une trame de chaque flux non terminé permet aux petites réponses de se terminer aux créneaux 11 à 18, avec une moyenne de 14,5. La grande réponse se termine au créneau 1 016. L’entrelacement modifie les temps d’achèvement sans augmenter le débit de transmission de la liaison.

HTTP/2 a aussi défini l’envoi anticipé par le serveur, qui envoie du contenu avant une requête. Les principaux navigateurs l’ont désactivé. Une réponse 103 Early Hints indique à la place des ressources que le navigateur peut commencer à demander.

Trouver le point de blocage restant

TCP fournit un seul flux d’octets ordonné. Si des octets manquent, les octets suivants attendent leur récupération, même lorsqu’ils contiennent des trames d’un autre flux HTTP/2. HTTP/2 supprime le blocage dû à l’ordre des réponses, mais conserve ce blocage au niveau du transport.

HTTP/3 fait fonctionner HTTP sur QUIC, un protocole de transport sur UDP, et compresse les en-têtes avec QPACK. QUIC fournit des flux fiables, le contrôle de flux et de congestion, ainsi que la sécurité de TLS 1.3. Chaque flux possède son propre ordre d’acheminement. Des données manquantes dans un flux n’empêchent pas, à elles seules, l’acheminement de données déjà reçues dans un autre. Le contrôle de congestion partagé et les dépendances de l’application peuvent néanmoins affecter plusieurs flux.

QUIC utilise des identifiants de connexion pour qu’une connexion puisse survivre à un changement d’adresse IP, par exemple lors du passage du Wi-Fi à un réseau cellulaire. Son implémentation peut être mise à jour avec une bibliothèque applicative, ce qui évite le déploiement lent des modifications de TCP dans les systèmes d’exploitation et les équipements intermédiaires.

Comparer une nouvelle connexion

Avec un RTT de 50 ms et sans coût DNS ni traitement, TCP associé à TLS 1.3 prend deux RTT avant l’envoi de la première requête HTTP/2. Une première réponse commence après environ 150 ms. QUIC combine l’établissement du transport et de la sécurité en un RTT, si bien qu’une réponse HTTP/3 peut commencer après environ 100 ms. Les connexions QUIC reprises peuvent utiliser des données 0-RTT, mais le risque de rejeu limite les requêtes qui peuvent être envoyées à l’avance sans danger.

Les navigateurs peuvent découvrir HTTP/3 grâce à Alt-Svc ou aux enregistrements DNS HTTPS. Si UDP est bloqué, ils peuvent se replier sur HTTP sur TCP. HTTP/3 reste fiable parce que QUIC fournit la fiabilité au-dessus d’UDP.

Un nom comme www.example.org est pratique pour une personne. Une connexion nécessite une adresse IP. Le système de noms de domaine, ou DNS, est à la fois la base de données distribuée des enregistrements de noms et le protocole applicatif utilisé pour l’interroger. Il utilise normalement le port 53 et fonctionne indépendamment de HTTP.

Répartir la gestion des noms

Lis www.example.org. de droite à gauche : la racine, org, example, puis www. Le point final représente la racine et est généralement omis dans l’usage courant. Un serveur centralisé pour tous les noms créerait un point de défaillance, un goulot d’étranglement pour le trafic et de longs chemins pour les clients éloignés.

Les serveurs racine orientent les résolveurs vers les serveurs de domaine de premier niveau. Les serveurs TLD les orientent vers les serveurs faisant autorité pour les domaines qui dépendent du TLD. Les serveurs faisant autorité publient les enregistrements effectifs d’un domaine. Les 13 identités nommées de serveurs racine sont répliquées sur de nombreuses instances physiques ; 13 n’est pas le nombre de machines qui assurent le fonctionnement du DNS mondial.

L’hôte envoie normalement sa question à un résolveur local, fourni par son organisation, son fournisseur d’accès à Internet ou un service public. Ce résolveur agit pour le compte de l’hôte. Il ne constitue pas un niveau supplémentaire entre la racine et le TLD dans la hiérarchie des noms.

Suivre une résolution avec un cache vide

Un ordinateur portable sur un campus a besoin de l’adresse IPv4 de www.example.org :

1. L’ordinateur demande la réponse finale à son résolveur local.
2. Le résolveur interroge un serveur racine, qui lui indique les serveurs .org.
3. Il interroge un serveur .org, qui lui indique les serveurs faisant autorité pour example.org.
4. Il interroge un serveur faisant autorité et reçoit 203.0.113.25.
5. Il renvoie l’adresse à l’ordinateur.

Il y a quatre paires requête-réponse, soit huit messages. La requête de l’hôte est récursive : elle demande d’obtenir la réponse pour lui. Les requêtes du résolveur sont itératives : chaque serveur contacté répond selon ce qu’il sait ou dirige le résolveur vers un autre serveur. La racine ne récupère pas l’adresse du serveur web pour le compte de l’ordinateur.

Réutiliser les réponses jusqu’à la fin de leur TTL

Un enregistrement de ressource comporte une durée de vie, ou TTL, mesurée en secondes. Les résolveurs conservent les enregistrements réutilisables dans des caches jusqu’à la fin de leur durée de validité. Ils peuvent mettre en cache les indications de serveurs aussi bien que les adresses finales. Une délégation de TLD ou de domaine mémorisée permet à une résolution ultérieure de sauter les premières étapes. Les systèmes d’exploitation et les navigateurs peuvent aussi avoir des caches.

Avec un RTT de 2 ms entre l’hôte et le résolveur et un RTT de 30 ms pour chacune des trois requêtes successives dans la hiérarchie, la résolution avec un cache vide prend environ 92 ms. Une adresse en cache chez le résolveur prend environ 2 ms. Les temps d’attente s’additionnent parce que chaque indication de serveur fournit les informations nécessaires à la requête suivante.

La mise en cache retarde aussi les changements. Si un résolveur a mis une adresse en cache avec un TTL d’une heure juste avant une mise à jour, il peut continuer à renvoyer l’ancienne adresse pendant le reste de sa durée de validité. Réduire le TTL avant un changement prévu limite cette période de coexistence ; modifier uniquement l’enregistrement faisant autorité ne remplace pas chaque copie en cache.

DNS ne se limite pas à la recherche d’une adresse à partir d’un nom. Il prend en charge les alias, trouve les serveurs de messagerie et répartit la charge en renvoyant plusieurs adresses pour un service. Ces rôles expliquent pourquoi l’acheminement des courriels et la sélection d’un CDN dépendent aussi de DNS.

DNS stocke des enregistrements de ressource comportant un nom, une valeur, un type et un TTL. Le type indique au résolveur comment interpréter la valeur. Un enregistrement d’adresse, un alias et un enregistrement de serveur de messagerie répondent à des questions différentes sur un même domaine.

Lire le type d’enregistrement

Par exemple, www.example.org. 3600 IN A 203.0.113.25 donne le nom auquel appartient l’enregistrement, le TTL, la classe Internet, le type et l’adresse. Une valeur NS est un nom, pas une adresse. Une indication de serveur peut inclure un enregistrement A distinct fournissant l’adresse du serveur de noms, souvent appelé enregistrement de liaison lorsqu’il est nécessaire pour résoudre la délégation.

Un CNAME tel que media.example.org pointant vers edge.cdn.example.net amène le résolveur à rechercher l’adresse de la cible. Un enregistrement MX dirige quant à lui l’acheminement des courriels. Avec les préférences 10 et 20, essaie d’abord le serveur de messagerie de préférence 10 ; un nombre plus grand ne signifie pas une priorité plus élevée.

Lire le message qui contient les enregistrements

Les requêtes et les réponses partagent un même format. L’en-tête de 12 octets contient un numéro d’identification, des drapeaux et le nombre d’entrées dans quatre sections. La réponse recopie l’identifiant de la requête pour que le demandeur puisse associer les deux messages.

La section question indique ce qui a été demandé. La section réponse contient les enregistrements correspondants. La section autorité peut contenir des indications de serveurs NS, tandis que la section supplémentaire fournit des enregistrements utiles comme les adresses des serveurs de noms. Dans la sortie affichée par dig, qr indique une réponse, rd signifie qu’une récursion a été demandée et ra qu’elle est disponible. NOERROR indique l’absence d’erreur DNS ; NXDOMAIN indique que le nom recherché n’existe pas. Une réponse sans erreur peut tout de même ne pas contenir d’enregistrement du type demandé.

Pour publier un nouveau domaine, son titulaire l’enregistre et fournit les informations sur ses serveurs faisant autorité. La délégation du domaine parent dirige les requêtes vers ces serveurs, qui publient les enregistrements d’hôte et de messagerie propres au domaine. Enregistrer le nom ne fait pas du bureau d’enregistrement le serveur qui détient tous les enregistrements.

Acheminement et protection

La plupart des petits échanges DNS utilisent le port UDP 53. Une réponse UDP tronquée a son drapeau TC activé ; le résolveur peut réessayer sur le port TCP 53. TCP prend aussi en charge les transferts de zone. DNS n’est donc pas limité à UDP.

Le trafic DNS classique expose les noms recherchés aux observateurs situés sur son chemin. DNS sur TLS ou DNS sur HTTPS chiffre l’échange entre le client et le résolveur, généralement sur les ports 853 et 443 respectivement. Le chiffrement de cet échange et l’authenticité d’un enregistrement sont deux propriétés distinctes.

Lors d’un empoisonnement du cache, un résolveur accepte une réponse falsifiée et envoie ensuite les utilisateurs vers une mauvaise adresse. Des identifiants et des ports sources imprévisibles rendent plus difficile l’association des réponses falsifiées aux requêtes. DNSSEC ajoute des signatures permettant de vérifier l’authenticité des enregistrements ; il ne masque pas la requête. Une inondation peut aussi rendre les serveurs DNS inaccessibles. La réplication et les indications de serveurs en cache réduisent la dépendance à la racine pour chaque requête, mais des défaillances chez un fournisseur de services faisant autorité largement utilisé peuvent encore perturber de nombreux sites.

La messagerie électronique sépare la rédaction d’un message de son acheminement. Un agent utilisateur est l’application ou la page web utilisée pour lire et écrire les courriels. Un serveur de messagerie stocke les courriels entrants dans des boîtes aux lettres et conserve les messages sortants dans une file d’attente. SMTP transfère les messages entre les systèmes.

Suivre l’acheminement après la soumission

Alice soumet à son propre serveur un message destiné à Bob. Ce serveur recherche les enregistrements MX du domaine de Bob, résout l’adresse du serveur choisi et ouvre une connexion TCP vers le port 25. Il transmet le message au serveur de Bob, qui le stocke dans sa boîte aux lettres. Le serveur d’Alice est le client SMTP pendant ce transfert, même s’il sert l’agent utilisateur d’Alice dans un autre échange.

Si la destination est temporairement indisponible, la file d’attente des messages sortants conserve le message pour de nouvelles tentatives. L’appareil d’Alice peut se déconnecter pendant que son serveur continue son travail. Après des échecs répétés, un avis de non-remise peut être renvoyé à l’expéditeur indiqué dans l’enveloppe.

Lire le dialogue

SMTP utilise des commandes textuelles et des réponses numériques. Voici un échange d’acheminement abrégé ; C: et S: identifient les deux interlocuteurs et ne sont pas transmis avec chaque commande.

S: 220 mail.example.net ready
C: EHLO mail.example.org
S: 250 mail.example.net
C: MAIL FROM:<alice@example.org>
S: 250 OK
C: RCPT TO:<bob@example.net>
S: 250 OK
C: DATA
S: 354 Send message
C: From: Alice <alice@example.org>
C: To: Bob <bob@example.net>
C: Date: Tue, 03 Mar 2026 10:02:44 +0100
C: Subject: Lab report
C:
C: The report is ready.
C: .
S: 250 Message accepted
C: QUIT
S: 221 Closing

EHLO présente l’hôte émetteur. MAIL FROM définit l’expéditeur de l’enveloppe ; chaque RCPT TO nomme un destinataire de l’enveloppe. DATA commence le message et une ligne contenant uniquement un point le termine. Une connexion peut transporter plusieurs messages. Les classes de réponse distinguent un succès (2xx), une demande de données supplémentaires (3xx), un échec temporaire (4xx) et un échec permanent (5xx). Une réponse 4xx appelle une nouvelle tentative ultérieure ; un échec 5xx nécessite un autre traitement, souvent un avis de non-remise.

Séparer les adresses d’acheminement des champs affichés

L’enveloppe contrôle l’acheminement. Les champs From: et To: à l’intérieur du message sont affichés au lecteur. Ils peuvent différer de l’enveloppe. Un destinataire en copie cachée peut apparaître dans RCPT TO sans figurer dans les en-têtes visibles du message. Répondre à un message et signaler un échec d’acheminement ne nécessitent pas forcément la même adresse.

Un utilisateur soumet normalement ses messages par SMTP authentifié sur le port 587 avec STARTTLS, ou sur le port 465 avec TLS dès le début. Le transfert entre serveurs utilise normalement le port 25 et peut négocier STARTTLS. La soumission et le transfert ont des rôles différents, même lorsqu’ils utilisent tous deux SMTP. HTTP récupère généralement les objets demandés ; SMTP transmet un message préparé à l’initiative de l’émetteur.

Vérifier le domaine de l’expéditeur

Un champ From: visible est facile à falsifier. SPF vérifie si l’hôte émetteur est autorisé pour le domaine de l’enveloppe. DKIM vérifie la signature d’un message à l’aide d’une clé publique publiée dans DNS. DMARC relie un résultat SPF ou DKIM positif au domaine visible dans From par l’alignement des domaines et publie une politique pour les échecs. Une vérification SPF positive pour un domaine d’enveloppe sans rapport ne valide pas à elle seule l’expéditeur visible.

Le transfert des courriels, le contenu des messages et l’accès à la boîte aux lettres sont des parties distinctes de la messagerie électronique. SMTP transfère un message vers un serveur de messagerie. Le message possède son propre format avec en-têtes et corps, et le destinataire accède plus tard à la boîte aux lettres stockée à l’aide d’un autre protocole.

Lire le message lui-même

Un message commence par des champs comme From:, To:, Date:, Subject: et Message-ID:. Une ligne vide sépare ces en-têtes du corps. Ils restent dans le message stocké ; les commandes SMTP MAIL FROM et RCPT TO ne deviennent pas des en-têtes du message.

Le format de base utilise des lignes de texte. MIME, Multipurpose Internet Mail Extensions, décrit des contenus plus riches à l’aide de champs supplémentaires. Content-Type: text/plain; charset=UTF-8 décrit du texte brut et son encodage de caractères. image/jpeg identifie une image. multipart/mixed décrit plusieurs parties séparées par une chaîne de délimitation, comme une note textuelle suivie d’une pièce jointe. Chaque partie peut avoir son propre type de contenu et son propre encodage de transfert.

Content-Transfer-Encoding décrit comment une partie est représentée pour le transfert. Base64 transforme chaque groupe de trois octets en quatre caractères ASCII. Pour une pièce jointe de 3 MB, 3 000 000 d’octets deviennent 4 000 000 de caractères avant les sauts de ligne et les en-têtes du message. L’encodage ajoute environ un tiers à la taille. La limite de taille totale des messages d’un serveur ne peut donc pas être comparée à la seule taille brute de la pièce jointe. Quoted-printable est un autre encodage adapté aux textes principalement lisibles.

Choisir un protocole d’accès à la messagerie

Le serveur du destinataire peut recevoir des courriels pendant que les appareils du destinataire sont hors ligne. À son retour, un protocole d’accès à la messagerie permet à un client de récupérer les messages stockés.

IMAP peut récupérer les en-têtes ou certaines parties d’un message sans télécharger toutes les pièces jointes. Il utilise couramment le port 143 avec STARTTLS ou le port 993 avec TLS dès le début. POP3 utilise couramment le port 110 ou le port 995 avec TLS. Ses marques de suppression prennent effet lorsque la session se termine normalement. Le mode télécharger et conserver laisse des copies sur le serveur, mais POP3 ne fournit pas les dossiers sur serveur et les indicateurs partagés d’IMAP.

Supposons que Bob consulte ses courriels sur un ordinateur portable avant de quitter son domicile, puis sur un téléphone. Si l’ordinateur utilise POP3 en mode télécharger et supprimer, le téléphone peut trouver une boîte aux lettres vide sur le serveur. Avec IMAP, marquer un message comme lu sur l’ordinateur modifie l’état sur le serveur, que le téléphone peut aussi voir. La différence concerne la synchronisation de la boîte aux lettres, et non l’acheminement SMTP.

Suivre un message de messagerie web au-delà du navigateur

Un navigateur soumet ou lit des courriels avec HTTPS. Le fournisseur de messagerie web utilise toujours SMTP pour transférer les courriels vers le serveur d’un autre domaine. Un trajet complet peut donc utiliser HTTPS entre l’expéditeur et le fournisseur, SMTP entre les fournisseurs, puis IMAP ou HTTPS à l’extrémité réceptrice. Appeler un service « messagerie web » décrit son interface utilisateur et sa connexion au navigateur, pas tous les protocoles utilisés sur le trajet du message.

Distribuer un fichier signifie que chaque destinataire doit en obtenir une copie complète. Le goulot d’étranglement n’est pas toujours le serveur : un téléchargement lent ou une capacité totale d’envoi insuffisante peuvent fixer le temps minimal. Le modèle standard suppose que les liaisons d’accès sont les goulots d’étranglement et que le cœur du réseau dispose d’une capacité suffisante.

Comparer les bornes inférieures

Soit un fichier contenant $F$ bits, avec $N$ destinataires. Le serveur envoie au débit $u_s$ ; le pair $i$ envoie au débit $u_i$ et télécharge au débit $d_i$. Le débit de téléchargement le plus faible parmi les pairs est $d_{min}$. Utilise des unités compatibles, comme Mbit et Mbps, pour que la division donne des secondes.

Avec une distribution client-serveur, le serveur doit envoyer $NF$ bits et le pair le plus lent doit recevoir $F$ bits :

En P2P, le serveur doit introduire chaque bit au moins une fois. Les pairs doivent toujours télécharger le fichier et l’ensemble du système doit envoyer assez de données pour toutes les copies :

Prends le maximum, car toutes les exigences doivent être satisfaites pendant la distribution. Additionner les termes supposerait à tort que ces activités d’envoi et de téléchargement se déroulent les unes après les autres. Ce sont des bornes inférieures ; la surcharge du protocole, des pairs indisponibles et d’autres goulots d’étranglement peuvent ralentir les transferts réels.

Étudier une comparaison

Pour un fichier de 2 Gbit, utilise 2 000 Mbit. Supposons que le débit d’envoi du serveur soit de 100 Mbps, le débit de téléchargement le plus faible de 20 Mbps et le débit d’envoi de chacun des 100 pairs de 5 Mbps.

Le terme du serveur en client-serveur est de 200 000 Mbit divisés par 100 Mbps, soit 2 000 s. Le terme du téléchargement le plus lent est de 100 s. La borne est donc de 2 000 s.

En P2P, l’introduction du fichier prend au moins 20 s. Le téléchargement le plus lent prend toujours 100 s. La capacité totale d’envoi est de 100 plus 500, soit 600 Mbps ; la distribution de 200 000 Mbit prend au moins environ 333 s. La borne P2P est d’environ 333 s. Avec 1 000 pairs, la borne client-serveur passe à 20 000 s, tandis que la borne P2P est d’environ 392 s. Lorsque les débits d’envoi des pairs sont égaux et que leur nombre devient grand, le terme correspondant à la capacité totale se rapproche de la taille du fichier divisée par le débit d’envoi d’un pair.

Échanger des fragments dans BitTorrent

Un torrent est un groupe qui partage un fichier. Les pairs échangent des fragments, découvrent leurs voisins par un serveur de suivi ou une table de hachage distribuée et peuvent envoyer des données avant la fin du téléchargement. Un semeur possède le fichier complet et continue à le partager.

La priorité aux fragments les plus rares choisit un fragment nécessaire détenu par le plus petit nombre de voisins, ce qui aide à préserver les fragments qui pourraient autrement disparaître lorsqu’un pair quitte le réseau. Elle détermine quoi demander. La règle du donnant-donnant encourage les échanges utiles en favorisant les voisins qui fournissent rapidement des données ; elle détermine à qui envoyer.

Dans la conception initiale, quatre voisins intéressés sont débloqués à la fois, dont un par déblocage optimiste. Le choix régulier est réexaminé environ toutes les 10 s et le pair bénéficiant du déblocage optimiste environ toutes les 30 s. Cette place réservée à l’exploration permet aux nouveaux arrivants d’obtenir leurs premiers fragments et aide à découvrir de meilleurs partenaires. Le serveur de suivi coordonne la découverte ; il n’est pas la source de données de chaque fragment.

Une vidéo se compose d’images affichées au fil du temps. La compression élimine les informations répétées à l’intérieur d’une image (redondance spatiale) et entre les images (redondance temporelle). Le résultat encodé possède un débit binaire : la quantité de données vidéo nécessaire pour chaque seconde de lecture.

Relier le débit, la taille et le temps de lecture

Une vidéo de deux heures à 5 Mbps contient 36 000 Mbit, soit 4,5 GB. Multiplie le débit par la durée pour obtenir des bits, puis divise par huit pour obtenir des octets. Si le débit effectif moyen du chemin est inférieur au débit vidéo choisi, tout tampon de capacité finie finit par se vider si la lecture se poursuit.

Un lecteur peut commencer avant d’avoir téléchargé toute la vidéo. Il stocke les données à venir dans un tampon, mesuré ici en secondes de vidéo lisible. La lecture consomme ce tampon tandis que les téléchargements le remplissent. Un tampon initial plus grand protège contre les baisses de débit effectif, mais augmente le délai de démarrage.

Demander un segment à la fois

DASH, Dynamic Adaptive Streaming over HTTP, stocke plusieurs versions encodées à différents débits et découpe chacune en segments. Un manifeste répertorie les versions disponibles et les URL des segments. Le client demande un segment avec HTTP GET et choisit de nouveau une version à la limite du segment suivant. HLS utilise une approche similaire avec des listes de lecture.

Le lecteur prend sa décision d’adaptation à partir du débit effectif mesuré et du niveau du tampon. Une estimation récente élevée du débit effectif favorise un débit plus élevé ; un tampon presque vide invite à la prudence. Choisir le débit le plus élevé observé une seule fois peut provoquer une interruption si le téléchargement suivant ralentit. Les lecteurs cherchent aussi à éviter des changements de qualité fréquents et gênants.

Calculer le téléchargement d’un segment

Considère des segments de 4 s encodés à 1, 2,5, 5 et 8 Mbps. Avec un débit effectif mesuré de 6 Mbps, le segment à 5 Mbps contient 20 Mbit. Il se télécharge en environ 3,33 s, ajoutant 4 s de contenu lisible pendant que la lecture en consomme environ 3,33 s. Si la lecture continue, le tampon augmente d’environ 0,67 s.

Un segment à 8 Mbps contient 32 Mbit et prend environ 5,33 s ; le tampon diminue donc d’environ 1,33 s. Les 6 Mbps du chemin correspondent à un débit de transfert ; ils ne transforment pas un encodage à 8 Mbps en un encodage à 6 Mbps.

Si le débit effectif tombe à 3 Mbps, le même segment à 5 Mbps prend environ 6,67 s. Le tampon perd environ 2,67 s par segment. Passer à la version à 2,5 Mbps produit un segment de 10 Mbit qui prend environ 3,33 s, ce qui permet au tampon d’augmenter à nouveau. Pour que la lecture se poursuive sans interruption pendant un téléchargement, le tampon initial doit aussi durer jusqu’à ce que de nouvelles données lisibles soient disponibles.

Vidéos stockées et appels interactifs

La diffusion en continu de vidéos stockées utilise des objets HTTP ordinaires, que les caches des navigateurs et les serveurs CDN peuvent fournir. Elle fonctionne donc sur TCP ou QUIC selon la version de HTTP. Les appels interactifs utilisent souvent un transport des données audio et vidéo fondé sur UDP, car attendre des données anciennes peut être plus préjudiciable que de les perdre.

Un événement en direct peut aussi utiliser la diffusion HTTP en continu par segments, mais le lecteur attend la production de chaque segment et conserve un tampon avec un décalage par rapport au direct. Des segments plus courts peuvent réduire ce délai tout en augmentant le nombre de requêtes. Se déplacer vers un passage qui n’est pas en mémoire tampon oblige aussi à remplir de nouveau le tampon du lecteur, ce qui peut brièvement réduire la qualité.

Un réseau de diffusion de contenu, ou CDN, fournit des copies de contenu depuis de nombreux lieux. Il évite d’envoyer chaque spectateur vers un seul centre de données distant et réduit les transferts répétés sur de longues distances. La répartition de la capacité de service réduit aussi la dépendance à un seul site.

Placer le contenu près de ses utilisateurs

Un CDN privé appartient à un fournisseur ; un CDN tiers dessert de nombreux clients. Tous deux peuvent fournir des images, scripts, logiciels et pages web ainsi que des vidéos. La source originale du contenu est l’origine. Les groupes de serveurs CDN conservent des copies pour que l’origine ne traite pas chaque requête.

Deux stratégies de placement sont utiles :

Le placement et le remplissage en contenu sont des choix distincts. Avec le placement à la demande, un groupe qui ne possède pas un objet le récupère auprès de l’origine ou d’un autre groupe, le stocke et le fournit. Avec le placement anticipé, le fournisseur envoie les objets à l’avance, souvent pendant les périodes creuses. Dans un CDN à placement à la demande, la première requête pour un objet absent du cache peut encore dépendre de l’origine.

Suivre le relais par DNS

Un utilisateur demande https://video.stream.example.com/v/6Y7B23V :

1. Le résolveur de l’utilisateur interroge DNS au sujet de video.stream.example.com.
2. Le serveur faisant autorité du fournisseur renvoie un CNAME vers l’espace de noms du CDN, comme a1105.cdn.example.net.
3. Le résolveur suit ce nom jusqu’au service DNS faisant autorité du CDN.
4. Le CDN choisit un groupe et renvoie une adresse comme 198.51.100.17.
5. Le client se connecte à ce serveur avec HTTPS et demande le contenu.

Le CNAME modifie l’endroit où la résolution du nom se poursuit. DNS renvoie des informations de nommage ; les octets de la vidéo arrivent ensuite par HTTP. Si le contenu est segmenté, de nombreuses requêtes ordinaires de segments suivent le même chemin général jusqu’au serveur choisi.

Choisir un emplacement adapté

Le groupe le plus proche sur une carte peut avoir un mauvais chemin réseau ou être surchargé. Une décision fondée sur DNS peut utiliser l’emplacement du résolveur, qui peut être loin de l’utilisateur. Une meilleure sélection peut tenir compte des délais et des pertes mesurés, de la charge actuelle et parfois d’informations sur le réseau du client.

La diffusion anycast IP offre un autre moyen d’accéder à un service proche : plusieurs emplacements annoncent la même adresse IP et le routage Internet choisit un chemin vers l’un d’eux. L’emplacement obtenu dépend du routage, et pas seulement de la distance physique. Un serveur proche du spectateur peut tout de même fournir une vidéo de mauvaise qualité si la liaison d’accès du spectateur constitue le goulot d’étranglement.

Open Connect de Netflix place des équipements dans les réseaux des fournisseurs d’accès et se connecte à des points d’échange. Le contenu est chargé avant la demande, ce qui réduit le trafic vers l’amont aux heures de pointe. Ses services applicatifs et la fourniture des vidéos encodées ne doivent pas nécessairement fonctionner sur la même infrastructure. D’autres architectures de CDN privés peuvent remplir les caches à la demande. Dans chaque cas, la diffusion adaptative en continu contrôle le débit demandé par le lecteur, tandis que le CDN contribue à déterminer le chemin et le serveur qui répondent à ces requêtes.

Les sockets Python envoient des octets. Encode une chaîne avant l’envoi et décode ensuite les octets reçus ; l’encodage de texte par défaut est UTF-8. AF_INET sélectionne IPv4 et SOCK_DGRAM sélectionne UDP. Commence par un service local pour que les deux processus puissent utiliser l’adresse de bouclage 127.0.0.1.

Lancer d’abord le récepteur

Ce serveur traite de courts datagrammes textuels et répond en majuscules :

from socket import socket, AF_INET, SOCK_DGRAM

with socket(AF_INET, SOCK_DGRAM) as server:
    server.bind(("127.0.0.1", 12000))
    while True:
        data, client_addr = server.recvfrom(2048)
        reply = data.decode().upper().encode()
        server.sendto(reply, client_addr)

bind donne à la socket son adresse et son port de réception. Une liaison à 127.0.0.1 n’accepte que le trafic local. La chaîne d’adresse vide "" lie au contraire la socket à toutes les interfaces IPv4, rendant le service accessible depuis d’autres hôtes lorsque le réseau le permet. Arrête le serveur en cours d’exécution avant d’en lancer une autre copie sur le même point de terminaison.

recvfrom bloque jusqu’à l’arrivée d’un datagramme. Il renvoie les données et l’adresse de l’émetteur, y compris son port. Le serveur utilise la paire renvoyée comme destination de sendto, ce qui lui permet de répondre à des clients dont il ne connaissait pas les ports éphémères à l’avance.

Envoyer une requête et limiter l’attente

from socket import socket, AF_INET, SOCK_DGRAM

with socket(AF_INET, SOCK_DGRAM) as client:
    client.settimeout(2.0)
    client.sendto(b"hello network", ("127.0.0.1", 12000))
    try:
        data, server_addr = client.recvfrom(2048)
        print(data.decode())
    except TimeoutError:
        print("No reply within 2 seconds")

Le préfixe b crée un littéral d’octets ; "hello network".encode() produit les mêmes octets. Le système d’exploitation attribue le port local du client lorsque c’est nécessaire. La réponse attendue est HELLO NETWORK. Aucun des deux programmes n’appelle listen ou accept, car UDP n’établit pas de connexion de transport.

Une absence de réponse n’indique pas au client exactement ce qui a échoué. La requête ou la réponse peut avoir été perdue ; il se peut aussi qu’aucun serveur ne soit à l’écoute. Le délai d’attente permet à l’application de reprendre le contrôle. Certains systèmes peuvent signaler un port de destination fermé comme une erreur ; Windows peut lever ConnectionResetError pendant la réception.

Respecter les limites des datagrammes

Chaque réception traite un datagramme. Deux datagrammes ne sont pas combinés en un seul message. Si le tampon de réception est trop petit, la partie excédentaire du datagramme est rejetée sur les systèmes Unix habituels ; Windows peut à la place signaler une erreur. Une autre réception ne récupère pas la fin manquante. Choisis un tampon assez grand pour les messages attendus par l’application.

La limite de charge utile UDP sur IPv4 est de 65 507 octets avec un en-tête IPv4 de taille minimale. C’est un maximum du protocole, pas une taille cible utile pour les datagrammes ordinaires. Un programme qui doit détecter les pertes peut numéroter les messages, enregistrer les heures d’envoi avec time.perf_counter() et compter les expirations du délai d’attente. Deux expirations sur dix requêtes donnent un taux de perte mesuré de 20 %. Réessayer une requête peut entraîner un traitement en double ; un système qui réessaie après expiration peut donc aussi avoir besoin de reconnaître les numéros de message répétés.

TCP fournit au programme un flux d’octets ordonné. Il ne conserve pas les limites des appels à sendall. Un court test complet peut arriver en un seul recv, mais un programme correct doit aussi gérer une requête répartie sur plusieurs réceptions.

Délimiter une requête textuelle

Choisis un saut de ligne comme délimiteur. Le client envoie une ligne UTF-8 et le serveur renvoie une ligne en majuscules. Ce serveur lit les données jusqu’à trouver ce délimiteur avant de les décoder :

from socket import socket, AF_INET, SOCK_STREAM

with socket(AF_INET, SOCK_STREAM) as server:
    server.bind(("127.0.0.1", 12000))
    server.listen(5)
    while True:
        conn, client_addr = server.accept()
        with conn:
            data = b""
            while b"\n" not in data:
                chunk = conn.recv(1024)
                if not chunk:
                    break
                data += chunk
            if b"\n" in data:
                line = data.split(b"\n", 1)[0]
                conn.sendall(line.decode().upper().encode() + b"\n")

listen crée une socket d’écoute. accept renvoie une nouvelle socket de connexion et l’adresse du client. Utilise conn pour les octets de ce client ; la socket initiale reste disponible pour accepter d’autres connexions. Ici, les clients sont servis un à la fois. La capacité de la file de cinq concerne les connexions en attente, et non cinq fils d’exécution actifs.

Compléter le côté client

from socket import create_connection

with create_connection(("127.0.0.1", 12000), timeout=2) as client:
    client.sendall(b"hello network\n")
    data = b""
    while b"\n" not in data:
        chunk = client.recv(1024)
        if not chunk:
            raise EOFError("Reply ended before its newline")
        data += chunk
    print(data.split(b"\n", 1)[0].decode())

Le résultat attendu est HELLO NETWORK. sendall poursuit l’envoi jusqu’à ce que tous les octets fournis aient été transmis ou qu’une erreur se produise. Un seul send peut n’en envoyer qu’une partie et indique le nombre d’octets acceptés. Aucun de ces appels ne fournit au récepteur les limites des messages applicatifs.

Ce service accepte une ligne par connexion. Un service persistant à plusieurs messages conserverait les octets situés après le premier saut de ligne pour son message suivant. Les préfixes de longueur et la fermeture du sens d’envoi sont d’autres choix de délimitation. Recevoir b"" signifie que le pair a terminé son côté émission ; ce n’est pas un fragment vide à lire de nouveau indéfiniment.

Relier le code aux protocoles réels

Une requête HTTP/1.1 est elle aussi une suite d’octets :

from socket import create_connection

request = ("GET / HTTP/1.1\r\n"
           "Host: example.com\r\n"
           "Connection: close\r\n\r\n")
with create_connection(("example.com", 80), timeout=5) as sock:
    sock.sendall(request.encode("ascii"))
    chunks = []
    while True:
        chunk = sock.recv(4096)
        if not chunk:
            break
        chunks.append(chunk)
print(b"".join(chunks).decode(errors="replace")[:200])

Ce code affiche le début de la réponse brute, y compris son état et ses en-têtes. Un serveur peut renvoyer une erreur ou une redirection ; le code ne suppose aucun corps de réponse particulier. HTTPS sur le port 443 nécessite une encapsulation TLS avec vérification du certificat et du nom d’hôte, et pas seulement un changement de numéro de port. Par exemple, ssl.create_default_context().wrap_socket(sock, server_hostname="example.com") encapsule une socket connectée après import ssl. Une connexion refusée signifie généralement que personne n’est à l’écoute ; un trafic rejeté silencieusement peut entraîner l’expiration du délai d’attente. Pour redémarrer rapidement un serveur sous Unix, définir SO_REUSEADDR avant bind peut permettre la réutilisation lorsqu’une ancienne connexion se ferme ; cela ne permet pas à deux sockets d’écoute actives d’occuper le même point de terminaison. Les serveurs concurrents utilisent des fils d’exécution ou des boucles d’événements et distinguent les connexions par les deux paires adresse-port des points de terminaison.