12. Programmation Internet

Prérequis : la version 8 de l'application [Impots], présentée à la fin de ce chapitre, réutilise les modules [impots-dao], [impots-metier] et [impots-ui] de la version 5 (chapitre 6). Avant de construire ou d'ouvrir ses projets, il faut avoir installé la version 5 dans le dépôt Maven local par la commande [mvn install] tapée dans le dossier [06-architectures/ImpotsV5] (cf. chapitre 6, section sur [mvn install]).

12.1. Généralités

12.1.1. Les protocoles de l'Internet

Nous donnons ici une introduction aux protocoles de communication de l'Internet, appelés aussi suite de protocoles TCP/IP (Transmission Control Protocol / Internet Protocol), du nom des deux principaux protocoles. Il est utile que le lecteur ait une compréhension globale du fonctionnement des réseaux, et notamment des protocoles TCP/IP, avant d'aborder la construction d'applications distribuées. Cette présentation s'inspire d'un texte du guide d'administration « Lan Workplace for DOS » de Novell (début des années 1990), dont elle garde la structure et l'esprit, mis à jour : l'Internet de 2026 n'est plus tout à fait celui de 1990.

Le concept général de créer un réseau d'ordinateurs hétérogènes vient de recherches effectuées par le DARPA (Defense Advanced Research Projects Agency) aux États-Unis. Le DARPA a développé la suite de protocoles connue sous le nom de TCP/IP qui permet à des machines hétérogènes de communiquer entre elles. Ces protocoles ont été testés sur un réseau appelé ARPAnet, réseau qui devint ultérieurement l'Internet (ARPAnet adopte TCP/IP le 1er janvier 1983). Les protocoles TCP/IP définissent des formats et des règles de transmission et de réception indépendants de l'organisation des réseaux et des matériels utilisés.

Le réseau conçu par le DARPA et géré par les protocoles TCP/IP est un réseau à commutation de paquets. Un tel réseau transmet l'information en petits morceaux appelés paquets. Ainsi, si un ordinateur transmet un gros fichier, celui-ci sera découpé en petits morceaux qui seront envoyés sur le réseau pour être recomposés à destination. TCP/IP définit le format de ces paquets, à savoir notamment :

l'origine du paquet ;
sa destination ;
sa longueur ;
son type.

Les protocoles de l'Internet sont décrits par des documents publics appelés RFC (Request For Comments), publiés par l'IETF (Internet Engineering Task Force) et consultables sur www.rfc-editor.org. Nous citerons quelques-uns de ces documents au fil du chapitre.

12.1.2. Le modèle OSI

Les protocoles TCP/IP suivent à peu près le modèle de réseau ouvert appelé OSI (Open Systems Interconnection Reference Model) défini par l'ISO (International Organization for Standardization). Ce modèle décrit un réseau idéal où la communication entre machines peut être représentée par un modèle à sept couches :

Chaque couche reçoit des services de la couche inférieure et offre les siens à la couche supérieure. Supposons que deux applications situées sur des machines A et B différentes veulent communiquer : elles le font au niveau de la couche Application. Elles n'ont pas besoin de connaître tous les détails du fonctionnement du réseau : chaque application remet l'information qu'elle souhaite transmettre à la couche du dessous, la couche Présentation. L'application n'a donc à connaître que les règles d'interfaçage avec la couche Présentation. Une fois l'information dans la couche Présentation, elle est passée selon d'autres règles à la couche Session et ainsi de suite, jusqu'à ce que l'information arrive sur le support physique et soit transmise physiquement à la machine destination. Là, elle subira le traitement inverse de celui qu'elle a subi sur la machine expéditrice.

À chaque couche, le processus expéditeur chargé d'envoyer l'information l'envoie à un processus récepteur, sur l'autre machine, appartenant à la même couche que lui. Il le fait selon certaines règles que l'on appelle le protocole de la couche. Le dialogue réel descend les couches de la machine A, traverse le réseau physique puis remonte les couches de la machine B ; mais chaque couche a l'impression de dialoguer directement avec la couche de même niveau de l'autre machine.

Le rôle des différentes couches est le suivant :

Couche	Rôle
Physique	Assure la transmission de bits sur un support physique (câble cuivre, fibre optique, ondes radio). Les points d'intérêt à ce niveau sont le codage de l'information en signaux et le mode de transmission.
Liaison de données	Masque les particularités physiques de la couche Physique. Découpe l'information en trames, détecte (et parfois corrige) les erreurs de transmission, gère l'accès au support partagé.
Réseau	Gère le chemin que doivent suivre les informations envoyées sur le réseau. On appelle cela le routage : déterminer la route à suivre par une information pour qu'elle arrive à son destinataire.
Transport	Permet la communication entre deux applications alors que les couches précédentes ne permettaient que la communication entre machines. Un service fourni par cette couche est le multiplexage : la couche transport utilise une même liaison réseau (de machine à machine) pour transmettre des informations appartenant à plusieurs applications.
Session	Fournit des services permettant à une application d'ouvrir et de maintenir une session de travail sur une machine distante.
Présentation	Uniformise la représentation des données sur les différentes machines. Des données provenant d'une machine A vont être « habillées » par la couche Présentation de la machine A selon un format standard avant d'être envoyées sur le réseau. Parvenues à la couche Présentation de la machine destinatrice B, qui les reconnaîtra grâce à leur format standard, elles seront habillées d'une autre façon afin que l'application de la machine B les reconnaisse.
Application	On trouve à ce niveau les applications généralement proches de l'utilisateur, telles que la messagerie électronique, le Web ou le transfert de fichiers.

12.1.3. Le modèle TCP/IP

Le modèle OSI est un modèle de référence qui n'a jamais été réalisé tel quel. La suite de protocoles TCP/IP, qui s'est imposée, s'organise en quatre couches seulement :

Les couches Session et Présentation n'existent pas en tant que telles dans TCP/IP : leurs fonctions, quand elles sont nécessaires, sont assurées par les applications elles-mêmes ou par des protocoles intermédiaires comme TLS (chiffrement des échanges), qui s'insère entre TCP et l'application.

La couche Accès réseau

En réseau local, la technologie dominante est aujourd'hui Ethernet pour les liaisons filaires et le Wi-Fi (normes IEEE 802.11) pour les liaisons sans fil. D'autres technologies, comme Token-Ring, ont aujourd'hui disparu.

Ethernet est le nom donné à une technologie de réseaux locaux à commutation de paquets inventée au PARC de Xerox au début des années 1970 et normalisée par Xerox, Intel et Digital Equipment en 1980, puis par l'IEEE (norme 802.3). L'Ethernet d'origine était constitué d'un câble coaxial auquel toutes les machines étaient raccordées (topologie en bus), avec un débit de 10 mégabits par seconde :

Ce réseau était diffusant : une machine qui émettait plaçait sur le câble des informations portant l'adresse de la machine destinatrice ; toutes les machines raccordées les recevaient et seule celle à qui elles étaient destinées les conservait. Comme plusieurs machines pouvaient décider d'émettre en même temps, il fallait détecter les collisions : c'était la méthode d'accès CSMA/CD (Carrier Sense Multiple Access / Collision Detect). Chaque transmetteur écoutait le câble avant d'émettre (CSMA) et, pendant qu'il émettait, vérifiait que ce qui passait sur le câble était bien ce qu'il avait émis ; sinon, il y avait collision (CD) : chacun cessait d'émettre et réessayait après un temps aléatoire.

L'Ethernet actuel a beaucoup évolué : les machines sont reliées par des câbles à paires torsadées ou des fibres optiques à un commutateur (switch) qui aiguille chaque trame vers le seul port de son destinataire. Les liaisons sont en duplex intégral (émission et réception simultanées) : il n'y a plus de collisions et CSMA/CD est devenu inutile. Les débits courants vont de 1 à 10 gigabits par seconde, et bien davantage dans les centres de données.

Ce qui n'a pas changé, c'est l'adressage sur 48 bits : chaque carte réseau a une adresse, appelée adresse physique ou adresse MAC (Media Access Control), notée en général sous la forme de six octets hexadécimaux (par exemple [00:1A:2B:3C:4D:5E]). Elle est inscrite par le fabricant dans la carte, mais, contrairement à ce que l'on a longtemps affirmé, elle peut être modifiée par logiciel : les systèmes d'exploitation actuels utilisent même des adresses MAC aléatoires sur les réseaux Wi-Fi, pour éviter qu'un appareil puisse être suivi de réseau en réseau.

La couche Internet (couche Réseau)

Nous trouvons au niveau de cette couche les protocoles suivants :

Protocole	Rôle
IP (Internet Protocol)	délivre des paquets entre deux nœuds du réseau, en version 4 (IPv4) ou 6 (IPv6)
ICMP (Internet Control Message Protocol)	réalise la communication entre le programme du protocole IP d'une machine et celui d'une autre machine. C'est donc un protocole d'échange de messages de contrôle à l'intérieur même du protocole IP
ARP (Address Resolution Protocol)	fait la correspondance adresse IP d'une machine → adresse physique de la machine (en IPv6, ce rôle est tenu par le protocole NDP, Neighbor Discovery Protocol)

On cite parfois aussi RARP (Reverse Address Resolution Protocol), qui faisait la correspondance inverse. Il est abandonné depuis longtemps au profit de DHCP, que nous présentons plus loin.

La couche Transport

Dans cette couche, on trouve les protocoles suivants :

Protocole	Rôle
TCP (Transmission Control Protocol)	assure une remise fiable et ordonnée d'informations entre deux applications
UDP (User Datagram Protocol)	assure une remise non fiable d'informations entre deux applications

Le protocole QUIC (2021), sur lequel repose HTTP/3, est un protocole de transport fiable et chiffré construit au-dessus d'UDP.

La couche Application

On trouve ici divers protocoles, que nous détaillerons un peu plus loin :

Protocole	Rôle
HTTP, HTTPS (HyperText Transfer Protocol)	le protocole du Web : un client (navigateur, application) demande des ressources à un serveur web. HTTPS est HTTP chiffré par TLS
DNS (Domain Name System)	transforme un nom de machine en adresse IP
SMTP (Simple Mail Transfer Protocol)	permet l'envoi de courriers électroniques
POP3, IMAP	permettent de lire le courrier électronique stocké sur un serveur
SSH (Secure Shell)	permet de se connecter à une machine distante et d'y exécuter des commandes, de façon chiffrée. Il a remplacé TELNET, qui faisait la même chose sans chiffrement
FTP (File Transfer Protocol), SFTP	permettent des transferts de fichiers
DHCP (Dynamic Host Configuration Protocol)	permet à une machine d'obtenir automatiquement son adresse IP et sa configuration réseau

12.1.4. Fonctionnement des protocoles de l'Internet

Les applications développées dans l'environnement TCP/IP utilisent généralement plusieurs des protocoles de cet environnement. Un programme d'application communique avec la couche la plus élevée des protocoles. Celle-ci passe l'information à la couche du dessous et ainsi de suite jusqu'à arriver sur le support physique. Là, l'information est physiquement transférée à la machine destinatrice où elle retraversera les mêmes couches, en sens inverse cette fois-ci, jusqu'à arriver à l'application destinatrice des informations envoyées. Le schéma suivant montre le parcours de l'information :

Prenons un exemple : une application qui envoie un fichier à une autre machine en utilisant TCP.

l'application délivre une suite d'octets à transmettre à la couche transport ;
la couche transport découpe cette suite d'octets en segments TCP et ajoute au début de chaque segment un en-tête contenant notamment les numéros de port source et destination ainsi qu'un numéro de séquence. Les segments sont passés à la couche Réseau gouvernée par le protocole IP ;
la couche IP crée un paquet encapsulant le segment TCP reçu. En tête de ce paquet, elle place les adresses IP des machines source et destination. Elle détermine également l'adresse physique de la machine à qui remettre le paquet (le destinataire lui-même ou un routeur). Le tout est passé à la couche Accès réseau, c'est-à-dire à la carte réseau qui couple la machine au réseau physique ;
là, le paquet IP est encapsulé à son tour dans une trame physique et envoyé à son destinataire sur le support ;
sur la machine destinatrice, la couche Accès réseau fait l'inverse : elle désencapsule le paquet IP de la trame physique et le passe à la couche IP ;
la couche IP vérifie que le paquet est correct : elle calcule une somme de contrôle (checksum) de son en-tête, qu'elle doit retrouver dans l'en-tête du paquet. Si ce n'est pas le cas, celui-ci est rejeté ;
si le paquet est déclaré correct, la couche IP désencapsule le segment TCP qui s'y trouve et le passe au-dessus, à la couche transport ;
la couche TCP vérifie elle aussi une somme de contrôle du segment. S'il est correct, elle envoie un accusé de réception à la machine source, sinon le segment est ignoré (et sera réémis par la source) ;
grâce aux numéros de séquence, la couche TCP remet les segments dans le bon ordre ;
il ne reste plus à la couche TCP qu'à transmettre la partie données des segments à l'application destinatrice de celles-ci, identifiée par le numéro de port destination.

12.1.5. Les problèmes d'adressage dans l'Internet

Un nœud d'un réseau peut être un ordinateur, une imprimante, un téléphone, un objet connecté, n'importe quoi en fait pouvant communiquer à l'aide des protocoles TCP/IP. Chaque nœud a une adresse physique ayant un format dépendant du type du réseau. Sur un réseau Ethernet ou Wi-Fi, l'adresse physique est codée sur 6 octets.

L'adresse Internet d'un nœud (adresse IP) est une adresse logique : elle est indépendante du matériel et du réseau utilisé. En IPv4, c'est une adresse sur 4 octets identifiant à la fois un réseau et un nœud de ce réseau. Elle est habituellement représentée sous la forme de 4 nombres, valeurs des 4 octets, séparés par un point. Ainsi, l'adresse de la machine Lagaffe de la faculté des Sciences d'Angers a longtemps été 193.49.144.1 et celle de la machine Liny 193.49.144.9. On en déduisait que l'adresse du réseau local était 193.49.144.0 et que l'on pouvait avoir jusqu'à 254 nœuds sur ce réseau.

Parce que les adresses IP sont indépendantes du réseau physique, une machine d'un réseau A peut communiquer avec une machine d'un réseau B sans se préoccuper du type de réseau sur lequel cette dernière se trouve : il suffit qu'elle connaisse son adresse IP. Le protocole IP de chaque réseau se charge de faire la conversion adresse IP ↔ adresse physique, dans les deux sens.

Les adresses IP publiques doivent être toutes différentes. Leur attribution est hiérarchique : l'IANA (Internet Assigned Numbers Authority) distribue des blocs d'adresses à cinq registres régionaux, dont le RIPE NCC pour l'Europe, qui les redistribuent aux opérateurs et aux grandes organisations. Ceux-ci les affectent ensuite à leurs clients. L'administrateur d'un réseau qui a reçu le bloc 193.49.144.0 à 193.49.144.255 peut affecter les adresses 193.49.144.1 à 193.49.144.254 comme il l'entend. En France, c'est longtemps l'INRIA qui a affecté les adresses ; ce n'est plus le cas depuis longtemps.

12.1.5.1. Les classes d'adresses IP et la notation CIDR

Une adresse IPv4 est une suite de 4 octets notée I1.I2.I3.I4, qui contient en fait deux informations :

l'adresse du réseau (les bits de poids fort) ;
l'adresse d'un nœud dans ce réseau (les bits de poids faible).

À l'origine, la taille de ces deux champs était fixée par la valeur du premier octet. Les adresses IP étaient divisées en trois classes principales :

Classe	Premier octet	Réseau / nœud	Nombre de réseaux et de nœuds
A	1 à 126 (bit de poids fort 0)	R1.N1.N2.N3 : réseau sur 1 octet (7 bits utiles), nœud sur 3 octets	126 réseaux de 2²⁴ - 2 nœuds (environ 16 millions)
B	128 à 191 (bits de poids fort 10)	R1.R2.N1.N2 : réseau sur 2 octets (14 bits utiles), nœud sur 2 octets	2¹⁴ = 16 384 réseaux de 2¹⁶ - 2 = 65 534 nœuds
C	192 à 223 (bits de poids fort 110)	R1.R2.R3.N1 : réseau sur 3 octets (21 bits utiles), nœud sur 1 octet	2²¹ réseaux (environ 2 millions) de 254 nœuds

L'adresse de la machine Lagaffe étant 193.49.144.1, l'octet de poids fort vaut 193, c'est-à-dire en binaire 11000001 : le réseau était de classe C.

Ce découpage s'est révélé beaucoup trop rigide : une organisation de 300 machines devait demander un réseau de classe B et en gaspillait plus de 65 000 adresses. Depuis 1993 (RFC 1518 et 1519), les classes ont été abandonnées au profit du routage sans classe CIDR (Classless Inter-Domain Routing). La frontière entre la partie réseau et la partie nœud peut être placée sur n'importe quel bit ; on l'indique par la longueur du préfixe réseau, après une barre oblique :

193.49.144.0/24 : les 24 premiers bits désignent le réseau, les 8 derniers le nœud. Ce réseau contient les adresses 193.49.144.0 à 193.49.144.255 ;
10.0.0.0/8 : un réseau de 2²⁴ adresses ;
192.168.1.0/26 : un réseau de 2⁶ = 64 adresses, de 192.168.1.0 à 192.168.1.63.

On rencontre encore l'ancienne notation du masque de sous-réseau, qui exprime la même chose : le préfixe /24 correspond au masque 255.255.255.0. Les termes « classe A, B, C » survivent dans le langage courant, mais ne correspondent plus à aucun mécanisme réel.

12.1.5.2. Adresses réservées, adresses privées et NAT

Certaines adresses ont un rôle particulier :

l'adresse dont la partie nœud ne comporte que des 0 désigne le réseau lui-même : 193.49.144.0 est l'adresse du réseau 193.49.144.0/24 ;
l'adresse dont la partie nœud ne comporte que des 1 est une adresse de diffusion : 193.49.144.255 désigne tous les nœuds du réseau 193.49.144.0/24. Ces deux adresses ne peuvent donc pas être affectées à un nœud : un réseau /24 de 256 adresses n'offre que 254 adresses utilisables ;
les adresses 127.0.0.0/8, et en pratique 127.0.0.1, sont les adresses de bouclage (loopback) : une machine les utilise pour se désigner elle-même, sans passer par le réseau. Le nom [localhost] leur est associé ;
les blocs 10.0.0.0/8, 172.16.0.0/12 et 192.168.0.0/16 (RFC 1918) sont réservés aux réseaux privés : ils peuvent être utilisés librement à l'intérieur d'une entreprise ou d'une maison, mais ne sont pas routés sur l'Internet ;
les blocs 192.0.2.0/24, 198.51.100.0/24 et 203.0.113.0/24 (RFC 5737) sont réservés à la documentation et aux exemples.

Le nombre d'adresses IPv4 (2³², soit un peu plus de 4 milliards) est insuffisant pour toutes les machines connectées. Le stock central de l'IANA a été épuisé en 2011, celui du RIPE NCC en 2019. La pénurie a été contournée par la traduction d'adresses NAT (Network Address Translation) : les machines d'une maison ont des adresses privées (192.168.1.x par exemple) et la box qui les relie à l'Internet les « traduit » en sa propre adresse publique, unique. La solution durable est IPv6.

12.1.5.3. Les adresses IPv6

IPv6 (RFC 2460 en 1998, aujourd'hui RFC 8200) code les adresses sur 128 bits, ce qui en offre 2¹²⁸, soit environ 3,4 × 10³⁸ : plus de pénurie à craindre. Une adresse IPv6 s'écrit sous la forme de huit groupes de quatre chiffres hexadécimaux séparés par le caractère deux-points :

1	`2001:0db8:0000:0000:8a2e:0000:0370:7334`

Les zéros de tête de chaque groupe peuvent être omis, et une seule suite de groupes nuls peut être remplacée par [::]. L'adresse précédente s'écrit donc [2001:db8::8a2e:0:370:7334]. L'adresse de bouclage, équivalent de 127.0.0.1, est [::1]. Dans une URL, une adresse IPv6 est placée entre crochets pour ne pas confondre ses deux-points avec celui qui précède le port : [http://[::1]:8080/].

IPv6 apporte d'autres simplifications : l'en-tête des paquets est de taille fixe, la configuration automatique des adresses est prévue d'origine et la traduction d'adresses NAT n'est plus nécessaire. Son déploiement a été lent, mais une part importante et croissante du trafic de l'Internet passe aujourd'hui par IPv6 (Google publie par exemple la proportion de ses utilisateurs qui y accèdent en IPv6), et les principaux opérateurs français le fournissent à leurs abonnés. Les deux versions cohabitent : la plupart des machines ont à la fois des adresses IPv4 et IPv6 (on parle de double pile, dual stack), et les programmes doivent savoir traiter les deux.

12.1.5.4. Les protocoles de conversion adresse IP ↔ adresse physique

Nous avons vu que lors d'une émission d'informations d'une machine vers une autre, celles-ci, à la traversée de la couche IP, étaient encapsulées dans des paquets. Ceux-ci ont la forme suivante :

Le paquet IP contient donc les adresses IP des machines source et destination. Lorsque ce paquet va être transmis à la couche chargée de l'envoyer sur le réseau physique, d'autres informations lui sont ajoutées pour former la trame physique qui sera finalement envoyée sur le réseau. Par exemple, le format d'une trame sur un réseau Ethernet est le suivant :

Les 8 premiers octets (préambule) servent à la synchronisation ; le champ de 2 octets qui précède les données indique, dans la forme la plus répandue de la trame Ethernet, le type du protocole transporté (IPv4, IPv6, ARP…) plutôt que la longueur du paquet. Dans la trame finale, il y a les adresses physiques des machines source et destination (dans la trame réelle, l'adresse destination précède l'adresse source, contrairement à l'ordre du schéma). Comment sont-elles obtenues ?

La machine expéditrice, connaissant l'adresse IP de la machine avec qui elle veut communiquer, obtient l'adresse physique de celle-ci en utilisant le protocole ARP (Address Resolution Protocol) :

elle envoie un paquet d'un type spécial, appelé paquet ARP, contenant l'adresse IP de la machine dont on cherche l'adresse physique. Elle a pris soin également d'y placer sa propre adresse IP ainsi que son adresse physique ;
ce paquet est envoyé à tous les nœuds du réseau local (diffusion) ;
ceux-ci reconnaissent la nature spéciale du paquet. Le nœud qui reconnaît son adresse IP dans le paquet répond en envoyant à l'expéditeur son adresse physique. Il le peut car il a trouvé dans le paquet les adresses IP et physique de l'expéditeur ;
l'expéditeur reçoit donc l'adresse physique qu'il cherchait. Il la stocke dans un cache afin de pouvoir l'utiliser ultérieurement si d'autres paquets sont à envoyer au même destinataire.

En IPv6, le même service est rendu par le protocole NDP (Neighbor Discovery Protocol), qui s'appuie sur des messages ICMPv6.

Reste à savoir comment une machine connaît sa propre adresse IP. Elle peut être inscrite dans un fichier de configuration de la machine : c'est ce qu'on fait encore pour les serveurs. Mais lorsque l'administrateur doit réorganiser son réseau, modifier un à un les fichiers de configuration de toutes les machines est fastidieux et source d'erreurs. Le protocole RARP permettait autrefois à une machine de demander son adresse IP à un serveur à partir de son adresse physique. Il a été remplacé par DHCP (Dynamic Host Configuration Protocol, RFC 2131) : au démarrage, la machine diffuse une demande sur le réseau ; un serveur DHCP (la box d'un particulier, un serveur dédié dans une entreprise) lui attribue une adresse IP pour une durée limitée (un bail), ainsi que le reste de sa configuration : préfixe du réseau, adresse du routeur, adresses des serveurs DNS. L'administrateur n'a plus qu'à configurer le serveur DHCP. En IPv6, une machine peut aussi construire elle-même son adresse à partir du préfixe annoncé par le routeur (autoconfiguration SLAAC).

12.1.6. La couche réseau dite couche IP de l'Internet

Le protocole IP définit la forme que les paquets doivent prendre et la façon dont ils doivent être gérés lors de leur émission ou de leur réception. Ce type de paquet particulier est appelé un datagramme IP. Nous l'avons déjà présenté :

L'important est qu'outre les données à transmettre, le datagramme IP contient les adresses IP des machines source et destination. Ainsi la machine destinatrice sait qui lui envoie un message.

À la différence d'une trame de réseau, qui a une longueur déterminée par les caractéristiques physiques du réseau sur lequel elle transite, la longueur du datagramme IP est fixée par le logiciel et sera donc la même sur différents réseaux physiques. Nous avons vu qu'en descendant de la couche réseau dans la couche physique, le datagramme IP était encapsulé dans une trame physique.

Les trames physiques circulent de nœud en nœud vers leur destination, qui peut ne pas être sur le même réseau physique que la machine expéditrice. Le paquet IP peut donc être encapsulé successivement dans des trames physiques différentes au niveau des nœuds qui font la jonction entre deux réseaux de types différents. Il se peut aussi que le paquet IP soit trop grand pour être encapsulé dans une trame physique (la charge utile d'une trame Ethernet est limitée à 1 500 octets). En IPv4, le nœud où se pose ce problème décompose alors le paquet IP en fragments, qui ne seront réassemblés qu'à leur ultime destination. En IPv6, les routeurs ne fragmentent plus : c'est l'émetteur qui doit découvrir la taille maximale acceptée sur le chemin et adapter la taille de ses paquets.

12.1.6.1. Le routage

Le routage est la méthode d'acheminement des paquets IP à leur destination. Il y a deux méthodes : le routage direct et le routage indirect.

Routage direct

Le routage direct désigne l'acheminement d'un paquet IP directement de l'expéditeur au destinataire à l'intérieur du même réseau :

la machine expéditrice d'un datagramme IP a l'adresse IP du destinataire ;
elle obtient l'adresse physique de ce dernier par le protocole ARP, ou dans son cache si cette adresse a déjà été obtenue ;
elle envoie le paquet sur le réseau à cette adresse physique.

Routage indirect

Le routage indirect désigne l'acheminement d'un paquet IP à une destination se trouvant sur un autre réseau que celui auquel appartient l'expéditeur. Dans ce cas, les parties « réseau » des adresses IP des machines source et destination sont différentes ; la machine source le constate en comparant l'adresse destination à son propre préfixe réseau. Elle envoie alors le paquet à un nœud spécial appelé routeur (router), qui connecte le réseau local aux autres réseaux et dont elle connaît l'adresse IP (on l'appelle la passerelle par défaut ; elle est en général fournie par DHCP). Un routeur est attaché à au moins deux réseaux et possède une adresse IP dans chacun d'eux :

Dans notre exemple ci-dessus :

le réseau n° 1 a l'adresse 193.49.144.0/24 et le réseau n° 2 l'adresse 193.49.145.0/24 ;
à l'intérieur du réseau n° 1, le routeur a l'adresse 193.49.144.6 et l'adresse 193.49.145.3 à l'intérieur du réseau n° 2.

Le routeur a pour rôle de prendre le paquet IP qu'il reçoit, contenu dans une trame physique du réseau n° 1, et de le placer dans une trame physique pouvant circuler sur le réseau n° 2. Si l'adresse IP du destinataire du paquet est dans le réseau n° 2, le routeur lui enverra le paquet directement, sinon il l'enverra à un autre routeur, connectant le réseau n° 2 à un réseau n° 3, et ainsi de suite. Les routeurs de l'Internet s'échangent en permanence des informations sur les réseaux qu'ils savent atteindre (protocoles de routage comme BGP entre opérateurs) pour construire leurs tables de routage.

12.1.6.2. Messages d'erreur et de contrôle

Toujours dans la couche réseau, au même niveau donc que le protocole IP, existe le protocole ICMP (Internet Control Message Protocol). Il sert à envoyer des messages sur le fonctionnement interne du réseau : nœud injoignable, paquet ayant traversé trop de routeurs, etc. Les messages ICMP sont encapsulés dans des paquets IP et envoyés sur le réseau. Les couches IP des différents nœuds prennent les actions appropriées selon les messages ICMP qu'elles reçoivent. Ainsi, une application elle-même ne voit jamais ces problèmes propres au réseau. Les commandes [ping] (qui envoie des messages ICMP « Echo Request » et attend les « Echo Reply ») et [traceroute] / [tracert] (qui affiche les routeurs traversés) sont fondées sur ICMP.

12.1.7. La couche transport : les protocoles UDP et TCP

12.1.7.1. Le protocole UDP : User Datagram Protocol

Le protocole UDP permet un échange non fiable de données entre deux points, c'est-à-dire que le bon acheminement d'un paquet à sa destination n'est pas garanti, pas plus que l'ordre d'arrivée des paquets. L'application, si elle le souhaite, peut gérer cela elle-même, en attendant par exemple, après l'envoi d'un message, un accusé de réception avant d'envoyer le suivant.

Jusqu'à présent, au niveau réseau, nous avons parlé d'adresses IP de machines. Or, sur une machine, peuvent coexister en même temps différents processus qui tous peuvent communiquer. Il faut donc indiquer, lors de l'envoi d'un message, non seulement l'adresse IP de la machine destinatrice, mais également le « nom » du processus destinataire. Ce nom est en fait un numéro sur 16 bits (de 1 à 65 535), appelé numéro de port. Certains numéros sont réservés à des applications standard : port 53 pour DNS, 80 pour HTTP, 443 pour HTTPS, 25 pour SMTP, etc. Les ports inférieurs à 1024 sont dits « bien connus » ; sous Linux, il faut des privilèges particuliers pour ouvrir un service sur l'un d'eux. Les exemples de ce chapitre utilisent des ports des plages 27100-27199 et 27200-27299.

Les paquets gérés par le protocole UDP sont appelés des datagrammes. Ils ont la forme suivante :

Ces datagrammes sont encapsulés dans des paquets IP, puis dans des trames physiques. UDP est utilisé quand la rapidité compte plus que la fiabilité, ou quand l'application gère elle-même les pertes : DNS (une question, une réponse), diffusion audio et vidéo en direct, jeux en réseau, et le protocole QUIC de HTTP/3.

12.1.7.2. Le protocole TCP : Transmission Control Protocol

Pour des communications sûres, le protocole UDP est insuffisant : le développeur d'applications doit élaborer lui-même un protocole lui permettant de détecter le bon acheminement des paquets. Le protocole TCP évite ces problèmes. Ses caractéristiques sont les suivantes :

le processus qui souhaite émettre établit tout d'abord une connexion avec le processus destinataire des informations qu'il va émettre. Cette connexion se fait entre un port de la machine émettrice et un port de la machine réceptrice, par un échange de trois segments (SYN, SYN-ACK, ACK : la « poignée de main en trois temps »). Il y a entre les deux ports un circuit virtuel qui est ainsi créé et qui sera réservé aux deux seuls processus ayant réalisé la connexion ;
tous les octets émis par le processus source arrivent à destination dans l'ordre où ils ont été émis, ce qui n'est pas garanti par le protocole UDP puisque les paquets peuvent suivre des chemins différents ;
l'information émise a un aspect continu : c'est un flux d'octets. Le processus émetteur envoie des informations à son rythme. Celles-ci ne sont pas nécessairement envoyées tout de suite : le protocole TCP peut attendre d'en avoir assez pour les envoyer. Elles sont placées dans une structure appelée segment TCP. Ce segment, une fois rempli, sera transmis à la couche IP où il sera encapsulé dans un paquet IP. Conséquence importante pour le programmeur : une « ligne » envoyée en une fois peut arriver en plusieurs morceaux, et plusieurs lignes peuvent arriver ensemble. C'est à l'application de retrouver les limites de ses messages (nous utiliserons pour cela la fin de ligne) ;
chaque segment envoyé par le protocole TCP est numéroté. Le protocole TCP destinataire vérifie qu'il reçoit bien les segments en séquence. Pour chaque segment correctement reçu, il envoie un accusé de réception à l'expéditeur ;
si, au bout d'un certain temps, le protocole TCP ayant émis un segment ne reçoit pas d'accusé de réception, il retransmet le segment en question, garantissant ainsi la qualité du service d'acheminement de l'information ;
le circuit virtuel établi entre les deux processus qui communiquent est full-duplex : l'information peut transiter dans les deux sens simultanément. Ainsi le processus destination peut envoyer des accusés de réception alors même que le processus source continue d'envoyer des informations. Cela permet par exemple au protocole TCP source d'envoyer plusieurs segments sans attendre d'accusé de réception. S'il réalise au bout d'un certain temps qu'il n'a pas reçu l'accusé de réception d'un certain segment n° n, il reprendra l'émission des segments à ce point ;
TCP régule aussi son débit pour ne pas saturer le destinataire (contrôle de flux) ni le réseau (contrôle de congestion).

12.1.8. La couche Applications

Au-dessus des protocoles UDP et TCP existent divers protocoles standard :

TELNET et SSH

TELNET permet à un utilisateur d'une machine A de se connecter sur une machine B (appelée souvent machine hôte) comme s'il disposait d'un terminal connecté à cette machine. TELNET s'appuie sur TCP. Ses échanges, mots de passe compris, circulent en clair : il a été remplacé par SSH (Secure Shell), qui rend le même service de façon chiffrée et sert aussi au transfert sécurisé de fichiers (SFTP, SCP) et à la création de tunnels. Le programme client [telnet] a longtemps été un outil commode pour dialoguer « à la main » avec un serveur TCP : nous verrons comment le remplacer.

FTP (File Transfer Protocol)

Ce protocole permet l'échange de fichiers entre deux machines distantes ainsi que des manipulations de fichiers telles que des créations de répertoire. Il s'appuie sur le protocole TCP. Comme TELNET, il transmet les mots de passe en clair ; il est en voie de disparition au profit de SFTP et de HTTPS.

TFTP (Trivial File Transfer Protocol)

Ce protocole est une variante simplifiée de FTP. Il s'appuie sur le protocole UDP. Il sert encore au démarrage de machines par le réseau.

DNS (Domain Name System)

Lorsqu'un utilisateur désire échanger des informations avec une machine distante, il doit connaître l'adresse IP de cette machine. Il est bien plus agréable de désigner une machine par un nom que par son adresse IP. Se pose alors le problème de l'unicité du nom : il y a des milliards de machines interconnectées. On pourrait imaginer qu'un organisme centralisé attribue les noms : ce serait très lourd. Le contrôle des noms a été distribué dans des domaines. Chaque domaine est géré par un organisme qui a toute liberté quant au choix des noms à l'intérieur de son domaine. Ainsi les machines en France appartiennent souvent au domaine [fr], géré par l'AFNIC (l'INRIA l'a géré jusqu'à la création de l'AFNIC en 1997). Pour continuer à simplifier les choses, on distribue encore le contrôle : des domaines sont créés à l'intérieur du domaine [fr]. Ainsi l'université d'Angers possède le domaine [univ-angers.fr] ; le service qui le gère a toute liberté pour nommer les machines du réseau de l'université et pour créer des sous-domaines.

Le nom complet d'une machine (FQDN, Fully Qualified Domain Name) précise la hiérarchie des domaines auxquels elle appartient, du plus spécifique au plus général : [www.univ-angers.fr]. À l'intérieur d'un domaine, on peut souvent utiliser des noms relatifs, complétés automatiquement par le système.

Une application peut donc référencer une machine par son nom. Au bout du compte, il faut quand même obtenir l'adresse IP de cette machine. Supposons que d'une machine A on veuille communiquer avec une machine B :

la machine A consulte d'abord un fichier local de correspondances ([/etc/hosts] sous Linux et macOS, [C:\Windows\System32\drivers\etc\hosts] sous Windows), puis son cache ;
sinon, elle interroge le serveur DNS dont l'adresse figure dans sa configuration (fournie en général par DHCP). Elle lui envoie une requête DNS contenant le nom de la machine recherchée. Si le serveur interrogé connaît la réponse, ou l'a en cache, il renvoie à la machine A l'adresse IP correspondante. Sinon, il interroge à son tour, en partant des serveurs racine, les serveurs responsables du domaine [fr], puis de [univ-angers.fr], etc., jusqu'à obtenir la réponse, qui redescendra jusqu'à la machine A.

Le DNS associe à un nom des enregistrements de différents types : A (adresse IPv4), AAAA (adresse IPv6), CNAME (alias vers un autre nom), MX (serveurs de courrier du domaine), etc.

HTTP et HTTPS (HyperText Transfer Protocol)

C'est le protocole du Web, et de loin le plus utilisé aujourd'hui : non seulement par les navigateurs, mais aussi par les applications qui échangent des données (les services web du chapitre suivant). Nous l'étudierons en détail. HTTPS est HTTP transporté dans une connexion chiffrée par TLS (Transport Layer Security) ; c'est aujourd'hui la forme normale du Web.

SMTP, POP3 et IMAP

SMTP sert à envoyer des courriers électroniques, POP3 et IMAP à lire ceux qui sont stockés sur un serveur. Nous les présenterons également.

XDR, RPC, NFS

Citons enfin trois protocoles définis par Sun Microsystems, l'entreprise qui a créé Java : XDR (eXternal Data Representation), qui spécifie une représentation standard des données indépendante des machines ; RPC (Remote Procedure Call), protocole d'appel de procédures distantes qui s'appuie sur XDR ; NFS (Network File System), qui permet à une machine de « voir » le système de fichiers d'une autre machine et s'appuie sur RPC. NFS reste utilisé dans le monde Unix. L'idée d'appel de procédure distante a été reprise par de nombreux successeurs, aujourd'hui les services web REST (sur HTTP) et gRPC (sur HTTP/2).

12.1.9. Conclusion

Nous avons présenté dans cette introduction quelques grandes lignes des protocoles Internet. Pour approfondir ce domaine, on pourra lire l'ouvrage de référence de Douglas Comer, « Internetworking with TCP/IP, Volume 1 » (Pearson, 6e édition), dont des éditions antérieures ont été traduites en français, ainsi que les RFC citées dans ce chapitre. Pour HTTP, la documentation de Mozilla developer.mozilla.org/fr/docs/Web/HTTP est une excellente introduction.

12.2. Les classes Java de la gestion des adresses IP

Une machine du réseau Internet est désignée par une adresse IP qui peut prendre deux formes :

IPv4 : codée sur 32 bits et représentée par une chaîne de la forme "I1.I2.I3.I4" où In est un nombre entre 0 et 255 ;
IPv6 : codée sur 128 bits et représentée par une chaîne de huit groupes de chiffres hexadécimaux séparés par des deux-points, comme "2001:db8::8a2e:370:7334". On ne peut plus aujourd'hui ignorer ces adresses : nos programmes les accepteront.

Une machine peut être aussi désignée par un nom. Ce nom n'est pas obligatoire, les applications utilisant toujours au final les adresses IP des machines. Les noms sont là pour faciliter la vie des utilisateurs : il est plus facile de demander à un navigateur l'URL [https://dev.java] que l'URL formée avec l'une des adresses IP de ce site, qui d'ailleurs change selon le lieu d'où on l'interroge.

Une machine peut avoir plusieurs adresses IP : une adresse de bouclage, une adresse par réseau auquel elle est connectée, des adresses IPv4 et IPv6.

Une adresse IP peut être représentée de deux façons en Java :

sous la forme d'une chaîne de caractères "I1.I2.I3.I4" ou "2001:db8::1" ;
sous la forme d'un objet de type [InetAddress] (paquetage [java.net], importé automatiquement dans un fichier source compact puisqu'il fait partie du module [java.base]).

La classe InetAddress

La classe [InetAddress] n'a pas de constructeur public : on obtient ses instances par des méthodes statiques de fabrication. Elle a deux classes dérivées, [Inet4Address] et [Inet6Address], une pour chaque version d'IP. Parmi ses méthodes, on trouve les suivantes :

Méthode	Rôle
static InetAddress ofLiteral(String chaine)	(Java 22) transforme une adresse IPv4 ou IPv6 écrite en chiffres en objet [InetAddress], sans jamais interroger le DNS ; lance une [IllegalArgumentException] si la chaîne n'est pas une adresse IP. [Inet4Address.ofLiteral] et [Inet6Address.ofLiteral] n'acceptent que l'une des deux versions
static InetAddress getByName(String nomOuAdresse)	rend l'adresse d'une machine désignée par son nom ou par son adresse IP. Si la chaîne n'est pas une adresse IP, le nom est cherché dans le DNS ; lance une [UnknownHostException] si la machine ne peut être trouvée
static InetAddress[] getAllByName(String nomOuAdresse)	idem, mais rend toutes les adresses IP de la machine
static InetAddress getLocalHost()	l'adresse de la machine sur laquelle s'exécute le programme, avec son nom
static InetAddress getLoopbackAddress()	l'adresse de bouclage (127.0.0.1 ou ::1). Un service associé à cette adresse n'accepte que les clients situés sur la même machine que lui
byte[] getAddress()	rend les octets de l'adresse (4 en IPv4, 16 en IPv6)
String getHostAddress()	rend l'adresse sous sa forme textuelle
String getHostName(), String getCanonicalHostName()	le nom de la machine ; si l'objet a été créé à partir d'une adresse IP, ce nom est obtenu par une recherche « inverse » dans le DNS (l'adresse elle-même est rendue si cette recherche échoue)
boolean isLoopbackAddress(), isSiteLocalAddress(), isAnyLocalAddress()…	rendent [true] si l'adresse est une adresse de bouclage, une adresse privée (10.x.y.z, 172.16.x.y à 172.31.x.y, 192.168.x.y), l'adresse « joker » 0.0.0.0 ou :: …

Deux autres classes complètent [InetAddress] :

[InetSocketAddress] représente un point de connexion : une adresse IP et un numéro de port. Ses méthodes [getAddress] et [getPort] donnent ces deux informations. Le constructeur [InetSocketAddress(int port)] associe le port à l'adresse joker 0.0.0.0, qui désigne toutes les adresses de la machine ;
[NetworkInterface] représente une interface réseau de la machine (une carte Ethernet, une carte Wi-Fi, l'interface de bouclage…), avec ses adresses IP.

Java n'a pas, en revanche, de classe représentant un réseau en notation CIDR, comme 193.49.144.0/24 : nous l'écrirons nous-mêmes. Le programme [Internet01.java] illustre ces classes :

// les classes InetAddress et InetSocketAddress ; un réseau en notation CIDR

void main() {
    // des adresses IPv4 et IPv6, correctes ou non
    List<String> adresses = List.of("193.49.144.1", "127.0.0.1", "192.168.1", "::1",
            "2001:db8::8a2e:370:7334", "256.1.1.1", "machine");
    for (String chaine : adresses) {
        try {
            // ofLiteral (Java 22) : analyse d'une adresse IP écrite en chiffres, sans interroger le DNS
            InetAddress adresse = InetAddress.ofLiteral(chaine);
            String famille = adresse instanceof Inet4Address ? "IPv4" : "IPv6";
            byte[] octets = adresse.getAddress();
            String hexa = HexFormat.of().withUpperCase().formatHex(octets);
            IO.println("[%s] -> %s (%s, %d octets : %s, bouclage : %b, privée : %b)".formatted(chaine,
                    adresse.getHostAddress(), famille, octets.length, hexa,
                    adresse.isLoopbackAddress(), adresse.isSiteLocalAddress()));
        } catch (IllegalArgumentException e) {
            IO.println("[" + chaine + "] n'est pas une adresse IP");
        }
    }

    // getByName accepte une adresse IP ou un nom de machine : ce dernier est cherché dans le DNS
    try {
        InetAddress.getByName("256.1.1.1");
    } catch (UnknownHostException e) {
        IO.println("getByName(\"256.1.1.1\") : " + e.getClass().getSimpleName() + " : " + e.getMessage());
    }

    // l'adresse de bouclage et l'adresse joker (toutes les adresses de la machine)
    IO.println("Bouclage=" + InetAddress.getLoopbackAddress());
    IO.println("Joker=" + new InetSocketAddress(27100).getAddress());

    // un point de connexion = une adresse IP + un port
    var point = new InetSocketAddress(InetAddress.getLoopbackAddress(), 27100);
    IO.println("InetSocketAddress : %s (adresse=%s, port=%d)".formatted(point,
            point.getAddress().getHostAddress(), point.getPort()));
    var point6 = new InetSocketAddress(InetAddress.ofLiteral("::1"), 27100);
    IO.println("InetSocketAddress IPv6 : %s (adresse=%s, port=%d)".formatted(point6,
            point6.getAddress().getHostAddress(), point6.getPort()));

    // un réseau en notation CIDR : adresse du réseau / longueur du préfixe
    Reseau reseau = Reseau.parse("193.49.144.0/24");
    for (String chaine : List.of("193.49.144.1", "193.49.145.3")) {
        boolean appartient = reseau.contient(InetAddress.ofLiteral(chaine));
        IO.println(chaine + " appartient à " + reseau + " : " + appartient);
    }
}

// un réseau IP : l'adresse du réseau et la longueur de son préfixe (Java n'a pas de classe pour cela)
record Reseau(InetAddress adresse, int prefixe) {

    // analyse d'une chaîne de la forme adresse/préfixe
    static Reseau parse(String cidr) {
        String[] champs = cidr.split("/");
        return new Reseau(InetAddress.ofLiteral(champs[0]), Integer.parseInt(champs[1]));
    }

    // une adresse appartient au réseau si ses [prefixe] premiers bits sont ceux du réseau
    boolean contient(InetAddress machine) {
        byte[] r = adresse.getAddress();
        byte[] m = machine.getAddress();
        if (r.length != m.length) {
            return false;
        }
        for (int bit = 0; bit < prefixe; bit++) {
            // le bit n° [bit] de l'adresse, en partant du bit de poids fort du premier octet
            int masque = 0x80 >> (bit % 8);
            if ((r[bit / 8] & masque) != (m[bit / 8] & masque)) {
                return false;
            }
        }
        return true;
    }

    @Override
    public String toString() {
        return adresse.getHostAddress() + "/" + prefixe;
    }
}

Résultats :

> java Internet01.java
[193.49.144.1] -> 193.49.144.1 (IPv4, 4 octets : C1319001, bouclage : false, privée : false)
[127.0.0.1] -> 127.0.0.1 (IPv4, 4 octets : 7F000001, bouclage : true, privée : false)
[192.168.1] -> 192.168.0.1 (IPv4, 4 octets : C0A80001, bouclage : false, privée : true)
[::1] -> 0:0:0:0:0:0:0:1 (IPv6, 16 octets : 00000000000000000000000000000001, bouclage : true, privée : false)
[2001:db8::8a2e:370:7334] -> 2001:db8:0:0:0:8a2e:370:7334 (IPv6, 16 octets : 20010DB80000000000008A2E03707334, bouclage : false, privée : false)
[256.1.1.1] n'est pas une adresse IP
[machine] n'est pas une adresse IP
getByName("256.1.1.1") : UnknownHostException : 256.1.1.1: Name or service not known
Bouclage=localhost/127.0.0.1
Joker=0.0.0.0/0.0.0.0
InetSocketAddress : localhost/127.0.0.1:27100 (adresse=127.0.0.1, port=27100)
InetSocketAddress IPv6 : /[0:0:0:0:0:0:0:1]:27100 (adresse=0:0:0:0:0:0:0:1, port=27100)
193.49.144.1 appartient à 193.49.144.0/24 : true
193.49.145.3 appartient à 193.49.144.0/24 : false

Commentaires :

lignes 5-6 : les chaînes à analyser ;
ligne 10 : [InetAddress.ofLiteral] (Java 22) transforme la chaîne en objet [InetAddress] si elle est une adresse IPv4 ou IPv6, et lance une [IllegalArgumentException] sinon (ligne 17) ;
ligne 11 : l'opérateur [instanceof] distingue les deux versions d'IP : l'objet rendu est une instance de [Inet4Address] ou de [Inet6Address] ;
lignes 12-13 : [getAddress] rend les octets de l'adresse, que la classe [HexFormat] (Java 17) affiche en hexadécimal. On voit (ligne 2 des résultats) que 193.49.144.1 est formée des quatre octets C1, 31, 90, 01 et (ligne 5) que ::1 est formée de 15 octets nuls suivis d'un octet valant 1 ;
ligne 16 : [isLoopbackAddress] et [isSiteLocalAddress] reconnaissent les adresses de bouclage et les adresses privées de la RFC 1918 ;
ligne 4 des résultats : une surprise. La chaîne "192.168.1" a été acceptée et transformée en 192.168.0.1. [ofLiteral] accepte en effet les formes abrégées historiques des adresses IPv4 (le dernier nombre occupe alors tous les octets restants). Pour vérifier qu'une saisie est une adresse IPv4 complète, il faut donc contrôler en plus qu'elle comporte quatre nombres ;
lignes 5-6 des résultats : les adresses IPv6 sont réaffichées par [getHostAddress] sous une forme complète, sans l'abréviation [::] ni les zéros de tête : [0:0:0:0:0:0:0:1] pour [::1]. Le préfixe 2001:db8::/32 est, comme 192.0.2.0/24 en IPv4, réservé à la documentation ;
lignes 23-27 : la méthode plus ancienne [getByName] accepte une adresse IP ou un nom de machine. La chaîne "256.1.1.1" n'étant pas une adresse IP valide (256 ne tient pas dans un octet), [getByName] la prend pour un nom de machine et interroge le DNS, qui ne la connaît pas : on obtient une [UnknownHostException] (ligne 9 des résultats). C'est pour éviter cette interrogation inattendue du DNS que [ofLiteral] a été ajoutée en Java 22. Le message de l'exception vient ici de la bibliothèque système de Linux ;
ligne 30 : l'adresse de bouclage. L'affichage d'un objet [InetAddress] par [toString] a la forme [nom/adresse], le nom étant vide s'il n'est pas connu ;
ligne 31 : l'adresse joker 0.0.0.0, obtenue ici par un [InetSocketAddress] sans adresse ;
lignes 34-39 : des objets [InetSocketAddress] associant une adresse et un port. Leur affichage (lignes 12-13 des résultats) a la forme [nom/adresse:port] ; en IPv6, l'adresse est entourée de crochets ;
lignes 50-79 : un enregistrement ([record], chapitre 4) qui représente un réseau en notation CIDR. Dans un fichier source compact, il peut être déclaré à la suite de la méthode [main] ;
lignes 53-56 : la méthode statique [parse] analyse une chaîne de la forme [adresse/préfixe] ;
lignes 59-73 : une adresse appartient au réseau si ses [prefixe] premiers bits sont ceux de l'adresse du réseau. Le bit n° [bit] se trouve dans l'octet n° [bit / 8] ; le masque [0x80 >> (bit % 8)] l'isole dans cet octet. Les lignes 14-15 des résultats montrent que 193.49.144.1 appartient au réseau 193.49.144.0/24 et que 193.49.145.3 (l'adresse du routeur de notre schéma, sur son second réseau) n'en fait pas partie. C'est exactement le test que fait une machine pour choisir entre routage direct et routage indirect.

Le DNS et les interfaces réseau

L'association adresse IP ↔ nom de machine est assurée par le DNS. On l'interroge avec les méthodes statiques [getByName] et [getAllByName] de [InetAddress], déjà présentées ; dans l'autre sens, [getHostName] et [getCanonicalHostName] font une recherche inverse. Ces méthodes sont bloquantes : une requête DNS peut demander plusieurs dizaines de millisecondes, voire plusieurs secondes si un serveur ne répond pas, pendant lesquelles le thread appelant est immobilisé. Java n'offre pas de version asynchrone de ces méthodes ; depuis Java 21, la solution est simplement de les appeler dans un thread virtuel (chapitre 8), qui ne coûte presque rien pendant qu'il attend. Depuis Java 18, on peut aussi remplacer le mécanisme de résolution des noms utilisé par [InetAddress] en fournissant sa propre implémentation de l'interface [InetAddressResolver], ce qui est utile pour les tests.

La classe [NetworkInterface] donne, avec sa méthode statique [networkInterfaces], un flux ([Stream]) des interfaces réseau de la machine ; pour chacune, [getName] donne son nom, [isUp] indique si elle est active et [inetAddresses] donne le flux de ses adresses IP.

Le programme [Internet02.java] affiche le nom et les interfaces réseau de la machine sur laquelle il s'exécute, puis donne interactivement les correspondances nom de machine ↔ adresses IP :

// affiche le nom et les interfaces réseau de la machine locale
// puis donne interactivement des infos sur les machines du réseau
// identifiées par un nom ou une adresse IP

void main() throws IOException {
    // machine locale
    InetAddress locale = InetAddress.getLocalHost();
    IO.println("Machine locale = " + locale.getHostName() + " (" + locale.getHostAddress() + ")");
    // ses interfaces réseau actives, avec leurs adresses
    for (NetworkInterface carte : NetworkInterface.networkInterfaces().filter(this::active).toList()) {
        String ips = carte.inetAddresses().map(InetAddress::getHostAddress).collect(Collectors.joining(", "));
        IO.println("Interface " + carte.getName() + " : " + ips);
    }

    // questions-réponses interactives
    while (true) {
        // saisie du nom ou de l'adresse IP de la machine recherchée
        String saisie = IO.readln("Machine recherchée (rien pour arrêter) : ");
        String machine = saisie == null ? "" : saisie.strip().toLowerCase();
        // fini ?
        if (machine.isEmpty()) {
            break;
        }
        try {
            // interrogation du DNS : toutes les adresses IP de la machine
            InetAddress[] adresses = InetAddress.getAllByName(machine);
            // le nom de la machine : recherche inverse si l'on a donné une adresse IP
            IO.println("Machine : " + adresses[0].getHostName());
            // ses adresses IP
            String ips = Arrays.stream(adresses).map(InetAddress::getHostAddress)
                    .collect(Collectors.joining(", "));
            IO.println("Adresses IP : " + ips);
        } catch (UnknownHostException e) {
            // la machine n'a pas été trouvée
            IO.println("Impossible de trouver la machine [" + machine + "] : " + e.getMessage());
        }
    }
}

// une interface réseau est-elle active ? (isUp peut lancer une SocketException)
boolean active(NetworkInterface carte) {
    try {
        return carte.isUp();
    } catch (SocketException e) {
        return false;
    }
}

Résultats :

> java Internet02.java
Machine locale = vm (127.0.0.1)
Interface eth0 : 192.0.2.2
Interface lo : 127.0.0.1
Machine recherchée (rien pour arrêter) : localhost
Machine : localhost
Adresses IP : 127.0.0.1
Machine recherchée (rien pour arrêter) : vm
Machine : vm
Adresses IP : 127.0.0.1
Machine recherchée (rien pour arrêter) : 127.0.0.1
Machine : localhost
Adresses IP : 127.0.0.1
Machine recherchée (rien pour arrêter) : ::1
Machine : 0:0:0:0:0:0:0:1
Adresses IP : 0:0:0:0:0:0:0:1
Machine recherchée (rien pour arrêter) : xx
Impossible de trouver la machine [xx] : xx: Name or service not known
Machine recherchée (rien pour arrêter) :

Commentaires :

lignes 7-8 : le nom et l'adresse de la machine locale. Notre machine de test est une machine virtuelle Linux nommée [vm] ; chez le lecteur, ce sera bien sûr le nom de son propre ordinateur ;
lignes 10-13 : les interfaces réseau actives et leurs adresses. Le filtre [filter(this::active)] utilise une référence à la méthode [active] de l'objet courant (chapitre 7) ; on ne peut pas écrire [isUp] directement dans une référence de méthode, car elle lance une exception contrôlée ([SocketException]), que l'interface fonctionnelle [Predicate] n'autorise pas : la méthode [active] (lignes 41-47) l'intercepte ;
ligne 18 : [IO.readln] (Java 25) affiche l'invite et lit une ligne au clavier ; elle rend [null] si l'entrée standard est fermée ;
ligne 26 : l'interrogation du DNS. Si le nom (ou l'adresse) est inconnu, une [UnknownHostException] est lancée (ligne 33) ;
ligne 28 : le nom de la machine. Si l'on a donné une adresse IP, [getHostName] fait une recherche inverse ;
lignes 30-31 : les adresses IP de la machine sont réunies en une seule chaîne par l'API Stream.

Les résultats appellent quelques remarques. Ils dépendent de la configuration de la machine : ne vous attendez pas à obtenir exactement les mêmes chez vous.

lignes 2-4 : la machine de test a deux interfaces actives : [eth0], reliée au réseau, et [lo], l'interface de bouclage. Le nom de la machine est associé à l'adresse 127.0.0.1 par le fichier [/etc/hosts] ;
lignes 5-7 : le nom [localhost] correspond à l'adresse de bouclage 127.0.0.1. Sur une machine où IPv6 est actif, on obtiendrait aussi ::1 ;
ligne 12 : avec une adresse IP, [getHostName] a fait une recherche inverse et rendu le nom associé à l'adresse ;
ligne 15 : la recherche inverse de ::1 a échoué, parce que le fichier [/etc/hosts] de notre machine de test n'associe aucun nom à cette adresse : [getHostName] a rendu l'adresse elle-même. Sous Windows, on obtiendrait le nom de la machine ;
ligne 18 : le nom [xx] est inconnu. Le message de l'exception vient de la bibliothèque système de Linux ; il serait différent sous Windows.

Sur une machine reliée à l'Internet, on peut aussi interroger un nom public comme [dev.java]. On obtient alors des adresses qui varient selon le lieu et le moment de la requête. Nous ne reproduisons pas ce résultat, notre machine de test n'ayant pas accès à l'Internet.

12.3. Les bases de la programmation Internet

12.3.1. Généralités

Considérons la communication entre deux machines distantes A et B :

Lorsqu'une application AppA d'une machine A veut communiquer avec une application AppB d'une machine B de l'Internet, elle doit connaître plusieurs choses :

l'adresse IP ou le nom de la machine B ;
le numéro du port avec lequel travaille l'application AppB. En effet, la machine B peut héberger de nombreuses applications qui travaillent sur l'Internet. Lorsqu'elle reçoit des informations provenant du réseau, elle doit savoir à quelle application elles sont destinées. Les applications de la machine B ont accès au réseau via des guichets appelés ports de communication. Le numéro du port destinataire est contenu dans le segment reçu par la machine B afin que celui-ci soit délivré à la bonne application ;
les protocoles de communication compris par la machine B. Dans notre étude, nous utiliserons uniquement les protocoles TCP/IP ;
le protocole de dialogue accepté par l'application AppB. En effet, les machines A et B vont se « parler ». Ce qu'elles vont dire va être encapsulé dans les protocoles TCP/IP. Néanmoins, lorsqu'au bout de la chaîne l'application AppB va recevoir l'information envoyée par l'application AppA, il faut qu'elle soit capable de l'interpréter. C'est analogue à la situation où deux personnes A et B communiquent par téléphone : leur dialogue est transporté par le téléphone, mais si A parle français et que B ne comprend pas cette langue, A et B ne pourront dialoguer utilement. Les deux applications communicantes doivent donc être d'accord sur le type de dialogue qu'elles vont adopter. Par exemple, le dialogue avec un serveur web n'est pas le même qu'avec un serveur de courrier : ces deux services n'acceptent pas les mêmes commandes. Ils ont des protocoles de dialogue différents.

12.3.2. Les caractéristiques du protocole TCP

Nous n'étudierons ici que des communications réseau utilisant le protocole de transport TCP. Rappelons ses caractéristiques essentielles pour le programmeur :

une connexion est d'abord établie entre un port de la machine cliente et un port de la machine serveur. Elle est identifiée par quatre informations : adresse IP et port du client, adresse IP et port du serveur ;
la connexion transporte deux flux d'octets, un dans chaque sens (full-duplex). Les octets arrivent dans l'ordre où ils ont été émis, sans perte ni duplication ;
TCP ne connaît pas la notion de message : c'est au protocole de dialogue de l'application de délimiter les demandes et les réponses (par une fin de ligne, une longueur annoncée, la fermeture de la connexion…) ;
l'un des deux partenaires ferme la connexion ; l'autre le constate lorsqu'il arrive à la fin du flux en lecture.

12.3.3. La relation client-serveur

Souvent, la communication sur Internet est dissymétrique : la machine A initie une connexion pour demander un service à la machine B. Elle précise qu'elle veut ouvrir une connexion avec le service SB1 de la machine B. Celle-ci accepte ou refuse. Si elle accepte, la machine A peut envoyer ses demandes au service SB1. Celles-ci doivent se conformer au protocole de dialogue compris par le service SB1. Un dialogue demande-réponse s'instaure ainsi entre la machine A, qu'on appelle machine cliente, et la machine B, qu'on appelle machine serveur. L'un des deux partenaires fermera la connexion.

12.3.4. Architecture d'un client

L'architecture d'un programme réseau demandant les services d'une application serveur sera la suivante :

ouvrir la connexion avec le service SB1 de la machine B
si réussite alors
    tant que ce n'est pas fini
        préparer une demande
        l'émettre vers la machine B
        attendre et récupérer la réponse
        la traiter
    fin tant que
finsi
fermer la connexion

12.3.5. Architecture d'un serveur

L'architecture d'un programme offrant des services sera la suivante :

ouvrir le service sur la machine locale
tant que le service est ouvert
    se mettre à l'écoute des demandes de connexion sur un port dit port d'écoute
    lorsqu'il y a une demande, l'accepter et faire traiter la connexion obtenue
        (connexion de service) par un autre thread
fin tant que

Le programme serveur traite différemment la demande de connexion initiale d'un client et ses demandes ultérieures visant à obtenir un service. Le programme d'écoute n'assure pas le service lui-même : s'il le faisait, pendant la durée du service il ne serait plus à l'écoute des demandes de connexion et les autres clients ne seraient pas servis. Il procède donc autrement : dès qu'une demande de connexion est reçue sur le port d'écoute puis acceptée, le serveur confie à un autre thread le soin de rendre le service demandé par le client, sur la connexion de service qui vient d'être établie. On peut ainsi servir plusieurs clients en même temps :

On lit parfois que la connexion de service utilise, côté serveur, un autre port, choisi au hasard. C'est inexact : toutes les connexions de service utilisent le port d'écoute du serveur ; elles se distinguent les unes des autres par l'adresse et le port du client, qui eux sont différents. Nous le constaterons dans les affichages de notre serveur d'écho.

Un thread de service aura la structure suivante :

tant que le service n'a pas été rendu totalement
    attendre une demande sur la connexion de service
    lorsqu'il y en a une, élaborer la réponse
    transmettre la réponse via la connexion de service
fin tant que
fermer la connexion de service

12.4. Découvrir les protocoles de communication de l'Internet

12.4.1. Introduction

Lorsqu'un client s'est connecté à un serveur, un dialogue s'établit entre eux. La nature de celui-ci forme ce qu'on appelle le protocole de communication du serveur. Parmi les protocoles les plus courants de l'Internet, on trouve les suivants :

HTTP : HyperText Transfer Protocol, le protocole de dialogue avec un serveur web (serveur HTTP) ;
SMTP : Simple Mail Transfer Protocol, le protocole de dialogue avec un serveur d'envoi de courriers électroniques (serveur SMTP) ;
POP : Post Office Protocol, le protocole de dialogue avec un serveur de stockage du courrier électronique (serveur POP). Il s'agit là de récupérer les courriers électroniques reçus et non d'en envoyer. IMAP joue le même rôle ;
FTP : File Transfer Protocol, le protocole de dialogue avec un serveur de stockage de fichiers (serveur FTP).

Ces protocoles, dans leurs versions historiques, ont la particularité d'être des protocoles à lignes de texte : le client et le serveur s'échangent des lignes de texte terminées par les deux caractères \r\n (retour chariot, passage à la ligne). Si on dispose d'un client capable de :

créer une connexion avec un serveur TCP ;
afficher à la console les lignes de texte que le serveur lui envoie ;
envoyer au serveur les lignes de texte qu'un utilisateur tape au clavier,

alors on est capable de dialoguer avec un serveur TCP ayant un protocole à lignes de texte, pour peu qu'on connaisse les règles de ce protocole.

Le programme [telnet], qu'on trouvait sur les machines Unix et Windows, est un tel client ; l'outil PuTTY, configuré en mode de connexion brute (Raw), en est un autre. Le client [telnet] n'est plus installé par défaut sous Windows et la plupart des serveurs publics n'acceptent plus de dialogue en clair. Nous procéderons autrement :

pour HTTP, nous utiliserons l'outil [curl], disponible en standard sous Windows 10 et 11, macOS et Linux, qui affiche le détail des échanges, puis le client TCP générique que nous écrirons plus loin dans ce chapitre. Sous Windows PowerShell, [curl] est un alias de la commande [Invoke-WebRequest] : il faut taper [curl.exe] ;
comme nous n'avons pas accès à de vrais serveurs, nous interrogerons un petit serveur web que nous écrivons nous-mêmes et qui s'exécute sur la machine locale ;
pour SMTP, POP et FTP, nous présenterons des dialogues types, conformes aux RFC qui définissent ces protocoles.

12.4.2. Un serveur web de test

Notre serveur web de test utilise le petit serveur HTTP fourni avec le JDK, dans le module [jdk.httpserver] (paquetage [com.sun.net.httpserver]). Malgré son nom de paquetage, c'est une API publique et documentée, présente depuis Java 6 ; elle suffit pour écrire un serveur de test en un seul fichier, sans aucune bibliothèque. Les vrais services web utilisent plutôt un serveur complet comme Tomcat, que nous rencontrerons avec Spring Boot au chapitre suivant. Il n'est pas nécessaire de comprendre ce programme en détail pour l'instant : il suffit de savoir ce qu'il répond. Le programme [Internet03.java] est le suivant :

import com.sun.net.httpserver.HttpExchange;
import com.sun.net.httpserver.HttpServer;

import static java.nio.charset.StandardCharsets.UTF_8;

// un petit serveur web local qui servira de cible à nos clients HTTP
// il utilise le serveur HTTP fourni par le JDK (module jdk.httpserver)
// appel : java Internet03.java [port]   (port 27110 par défaut) ; arrêt par Ctrl-C

// la page d'accueil : un document HTML
final String ACCUEIL = """
        <!DOCTYPE html>
        <html lang="fr">
        <head><meta charset="utf-8"><title>Serveur de test</title></head>
        <body><h1>Bienvenue sur le serveur de test du cours Java</h1></body>
        </html>
        """;

int port;

void main(String[] args) throws IOException {
    port = args.length == 1 ? Integer.parseInt(args[0]) : 27110;
    // le serveur écoute sur l'adresse de bouclage : il n'est accessible que depuis la machine elle-même
    HttpServer serveur = HttpServer.create(new InetSocketAddress(InetAddress.getLoopbackAddress(), port), 0);
    // toutes les URL sont traitées par la méthode [traiter]
    serveur.createContext("/", this::traiter);
    serveur.start();
    IO.println("Serveur web lancé sur http://localhost:" + port);
}

// traitement d'une requête : choix de la réponse selon l'URL, puis suivi console
void traiter(HttpExchange echange) throws IOException {
    try (echange) {
        String methode = echange.getRequestMethod();
        String chemin = echange.getRequestURI().getPath();
        if (!methode.equals("GET") && !methode.equals("HEAD")) {
            // les URL n'acceptent que les méthodes GET et HEAD
            echange.sendResponseHeaders(405, -1);
        } else {
            switch (chemin) {
                // la page d'accueil, avec sa taille
                case "/" -> envoyer(echange, ACCUEIL, "text/html; charset=utf-8", true);
                // un document texte construit à partir d'un paramètre de l'URL, envoyé par morceaux
                case "/bonjour" -> envoyer(echange, "Bonjour " + parametre(echange, "nom", "inconnu") + " !",
                        "text/plain; charset=utf-8", false);
                // redirection temporaire (302) vers une adresse relative
                case "/ancienne" -> rediriger(echange, 302, "/bonjour?nom=visiteur");
                // redirection permanente (301) vers une adresse absolue
                case "/deplacee" -> rediriger(echange, 301, "http://localhost:" + port + "/");
                // une redirection qui boucle sur elle-même
                case "/boucle" -> rediriger(echange, 302, "/boucle");
                // toute autre URL : 404 Not Found, sans document (-1)
                default -> echange.sendResponseHeaders(404, -1);
            }
        }
        // suivi console : la requête et le code de statut de sa réponse
        IO.println("%s %s %s -> %d".formatted(methode, echange.getRequestURI(), echange.getProtocol(),
                echange.getResponseCode()));
    }
}

// envoi d'un document texte : avec sa taille (Content-length) ou par morceaux (chunked)
void envoyer(HttpExchange echange, String texte, String type, boolean avecTaille) throws IOException {
    byte[] octets = texte.getBytes(UTF_8);
    echange.getResponseHeaders().set("Content-Type", type);
    if (echange.getRequestMethod().equals("HEAD")) {
        // HEAD : les entêtes seulement ; on indique la taille qu'aurait le document
        echange.getResponseHeaders().set("Content-Length", String.valueOf(octets.length));
        echange.sendResponseHeaders(200, -1);
        return;
    }
    // taille 0 : document envoyé par morceaux, de taille inconnue à l'avance
    echange.sendResponseHeaders(200, avecTaille ? octets.length : 0);
    echange.getResponseBody().write(octets);
}

// une redirection : code 301 ou 302 et entête Location, sans document
void rediriger(HttpExchange echange, int code, String adresse) throws IOException {
    echange.getResponseHeaders().set("Location", adresse);
    echange.sendResponseHeaders(code, -1);
}

// la valeur d'un paramètre de l'URL (?nom=valeur&...), décodée
String parametre(HttpExchange echange, String nom, String defaut) {
    String requete = echange.getRequestURI().getRawQuery();
    if (requete == null) {
        return defaut;
    }
    for (String paire : requete.split("&")) {
        String[] champs = paire.split("=", 2);
        if (champs[0].equals(nom) && champs.length == 2) {
            return URLDecoder.decode(champs[1], UTF_8);
        }
    }
    return defaut;
}

Commentaires :

lignes 1-2 : le module [jdk.httpserver] ne fait pas partie du module [java.base], importé automatiquement dans un fichier source compact : ses classes doivent être importées. La ligne 4 est une importation statique : elle permet d'écrire [UTF_8] au lieu de [StandardCharsets.UTF_8] ;
lignes 11-17 : la page d'accueil, un petit document HTML écrit avec un bloc de texte [""" ... """] (Java 15), qui évite d'échapper les guillemets ;
ligne 22 : le port d'écoute, 27110 par défaut ;
ligne 24 : le serveur écoute sur l'adresse de bouclage 127.0.0.1 : il n'est accessible que depuis la machine elle-même. Le second paramètre de [create] est la taille de la file d'attente des connexions (0 : valeur par défaut du système) ;
ligne 26 : toutes les URL commençant par [/], donc toutes les URL, sont confiées à la méthode [traiter]. Le second paramètre de [createContext] est un [HttpHandler], interface fonctionnelle dont l'unique méthode [handle(HttpExchange)] reçoit l'échange en cours : la requête du client et la réponse à construire ;
ligne 27 : le serveur démarre dans ses propres threads ; la méthode [main] se termine, mais le programme continue de s'exécuter jusqu'à ce qu'on l'arrête par Ctrl-C ;
ligne 33 : un [HttpExchange] doit être fermé une fois la réponse envoyée : le [try] avec ressources s'en charge ;
lignes 36-38 : seules les méthodes [GET] et [HEAD] sont acceptées ; les autres reçoivent la réponse 405 (méthode non autorisée) ;
ligne 42 : l'URL [/] rend la page d'accueil ;
ligne 44 : l'URL [/bonjour?nom=xx] rend le texte [Bonjour xx !] ;
ligne 47 : l'URL [/ancienne] provoque une redirection temporaire (code 302) vers l'adresse relative [/bonjour?nom=visiteur] ;
ligne 49 : l'URL [/deplacee] provoque une redirection permanente (code 301) vers l'adresse absolue [http://localhost:27110/] ;
ligne 51 : l'URL [/boucle] redirige vers elle-même : un client qui suivrait aveuglément les redirections ne s'arrêterait jamais ;
ligne 53 : toute autre URL reçoit la réponse 404 (document introuvable). La méthode [sendResponseHeaders(code, taille)] envoie la ligne de statut et les entêtes ; une taille de -1 signifie qu'aucun document ne suit ;
lignes 57-58 : chaque requête traitée est affichée sur la console avec le code de statut de la réponse ;
lignes 63-75 : l'envoi d'un document texte. Les entêtes de la réponse sont fixés avec [getResponseHeaders().set] (ligne 65), puis [sendResponseHeaders] les envoie avec la taille du document ; le document est ensuite écrit dans le flux [getResponseBody()] (ligne 74). Une taille de 0 (ligne 73) signifie « taille inconnue » : le document est alors envoyé par morceaux, ce que nous observerons plus loin. Pour une requête [HEAD], aucun document n'est envoyé, mais on indique la taille qu'il aurait eue (lignes 66-71) ;
lignes 78-81 : une redirection, faite d'un code de statut et d'un entête [Location] donnant la nouvelle adresse ;
lignes 84-96 : la valeur d'un paramètre de l'URL. [getRawQuery] rend la partie de l'URL qui suit le [?], encore encodée ; [URLDecoder.decode] décode chaque valeur (nous verrons plus loin pourquoi les valeurs sont encodées).

Le serveur est lancé dans une première fenêtre de commandes. Il affiche :

> java Internet03.java
Serveur web lancé sur http://localhost:27110
GET / HTTP/1.1 -> 200
GET /inconnu HTTP/1.1 -> 404

Les lignes 3-4 sont apparues pendant les essais du paragraphe suivant. Le serveur s'arrête par Ctrl-C.

12.4.3. Le protocole HTTP (HyperText Transfer Protocol)

Pendant que le serveur s'exécute, nous demandons, dans une seconde fenêtre de commandes, la racine [/] du site [http://localhost:27110] avec l'outil [curl]. Son option [-v] (verbose) affiche tout le dialogue HTTP ; l'option [-s] (silent) supprime l'affichage de la progression du transfert :

> curl -sv http://localhost:27110/
* Host localhost:27110 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
*   Trying 127.0.0.1:27110...
* Connected to localhost (127.0.0.1) port 27110
> GET / HTTP/1.1
> Host: localhost:27110
> User-Agent: curl/8.5.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Date: Sat, 03 Oct 2026 17:40:04 GMT
< Content-type: text/html; charset=utf-8
< Content-length: 176
< 
{ [176 bytes data]
* Connection #0 to host localhost left intact
<!DOCTYPE html>
<html lang="fr">
<head><meta charset="utf-8"><title>Serveur de test</title></head>
<body><h1>Bienvenue sur le serveur de test du cours Java</h1></body>
</html>

Commentaires :

les lignes commençant par [*] sont des informations de [curl] ; les lignes commençant par [>] ont été envoyées au serveur, celles commençant par [<] ont été reçues du serveur ; la ligne [{ [176 bytes data]] signale l'arrivée des 176 octets du document, qui est affiché à la fin ;
lignes 2-6 : [curl] a obtenu les adresses de [localhost] (::1 en IPv6 et 127.0.0.1 en IPv4) et s'est connecté au port 27110 de l'adresse 127.0.0.1 ;
lignes 7-11 : la requête du client. Elle est formée d'une première ligne de syntaxe [méthode URL version] (ici, on demande avec la méthode [GET] le document [/], c'est-à-dire la racine du site, en HTTP/1.1), puis d'entêtes HTTP de la forme [Nom: valeur], et se termine par une ligne vide ;
ligne 8 : l'entête [Host] indique la machine et le port interrogés ; il est obligatoire en HTTP/1.1 car un même serveur peut héberger plusieurs sites ;
ligne 9 : l'identité du logiciel client ;
ligne 10 : les types de documents acceptés par le client, ici tous ;
lignes 12-16 : la réponse du serveur : une ligne de statut et des entêtes, terminés eux aussi par une ligne vide ;
ligne 12 : la ligne de statut, de syntaxe [version code message]. Le code 200 indique que le document demandé a été trouvé ;
ligne 13 : la date et l'heure du serveur, toujours en temps universel (GMT) ;
ligne 14 : la nature du document (un document HTML) et son encodage (UTF-8) ;
ligne 15 : la taille du document en octets. C'est grâce à elle que le client sait où s'arrête le document. On remarque que le serveur du JDK écrit les noms d'entêtes avec une seule majuscule ([Content-type], [Content-length]) : c'est sans importance, les noms d'entêtes HTTP étant insensibles à la casse. Il n'envoie pas non plus l'entête facultatif [Server], que la plupart des serveurs utilisent pour se présenter ([Server: Apache], [Server: nginx]…) ;
ligne 18 : en HTTP/1.1, la connexion reste ouverte par défaut après la réponse (mode « keep-alive ») afin de pouvoir servir d'autres requêtes ; [curl] la laisse ouverte puis la ferme en se terminant ;
lignes 19-23 : le document envoyé par le serveur.

Demandons maintenant un document qui n'existe pas :

> curl -sv http://localhost:27110/inconnu
* Host localhost:27110 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
*   Trying 127.0.0.1:27110...
* Connected to localhost (127.0.0.1) port 27110
> GET /inconnu HTTP/1.1
> Host: localhost:27110
> User-Agent: curl/8.5.0
> Accept: */*
> 
< HTTP/1.1 404 Not Found
< Date: Sat, 03 Oct 2026 17:40:04 GMT
< Content-length: 0
< 
* Connection #0 to host localhost left intact

ligne 7 : on a demandé un document inexistant ;
ligne 12 : le serveur a répondu avec le code 404, qui signifie que le document demandé n'a pas été trouvé ;
ligne 14 : le document envoyé est vide. Notre serveur, comme beaucoup d'autres, ne joint aucun document à une réponse 404 ; d'autres serveurs envoient une petite page HTML d'explication. Un navigateur qui reçoit une réponse 404 sans document affiche sa propre page d'erreur.

Les codes de statut sont répartis en cinq familles : 1xx (information), 2xx (succès, 200 OK), 3xx (redirection, 301 et 302 que nous rencontrerons plus loin), 4xx (erreur du client : 404 Not Found, 401 Unauthorized, 403 Forbidden…), 5xx (erreur du serveur : 500 Internal Server Error…).

Le navigateur fait la même chose que [curl] : il envoie une requête HTTP, reçoit les entêtes et le document, puis affiche le document. Les outils de développement des navigateurs (touche F12, onglet Réseau) permettent de voir les entêtes échangés.

Quelques remarques sur l'état actuel de HTTP :

HTTPS est aujourd'hui la règle : les navigateurs signalent comme « non sécurisé » un site en HTTP simple. Avec HTTPS, une négociation TLS précède le dialogue HTTP, et tout ce qui suit est chiffré. On ne peut donc plus dialoguer « à la main » avec un serveur HTTPS au moyen d'un simple client TCP. On peut en revanche toujours observer le dialogue avec [curl], qui fait la négociation TLS et affiche ensuite les entêtes en clair. À titre d'illustration seulement (nous ne reproduisons pas le résultat, notre machine de test n'ayant pas accès à l'Internet), la commande serait [curl -v https://dev.java/] ;
HTTP/1.1 (RFC 9112 aujourd'hui) est un protocole à lignes de texte, celui que nous étudions. HTTP/2 (2015, aujourd'hui RFC 9113) garde les mêmes méthodes, entêtes et codes de statut, mais les transmet sous une forme binaire compressée et fait circuler plusieurs requêtes simultanément sur une seule connexion TCP. HTTP/3 (2022, RFC 9114) fait la même chose au-dessus de QUIC, donc d'UDP. Navigateurs et serveurs choisissent automatiquement la version la plus récente qu'ils ont en commun ; [curl], sans option particulière, utilise HTTP/1.1 pour une URL [http://].

12.4.4. Le protocole SMTP (Simple Mail Transfer Protocol)

Les serveurs SMTP échangent le courrier entre eux sur le port 25. Un logiciel de messagerie qui envoie un courrier le confie, lui, au serveur SMTP de son fournisseur sur le port 587 (soumission, avec passage en mode chiffré par la commande [STARTTLS]) ou 465 (connexion chiffrée d'emblée), après s'être authentifié. Les fournisseurs d'accès bloquent en général les connexions sortantes vers le port 25 depuis les box de leurs abonnés, pour limiter l'envoi de pourriels par des machines infectées : un dialogue en clair avec un serveur SMTP n'est plus guère réalisable depuis un poste personnel.

Voici, à titre d'illustration, un dialogue SMTP type conforme à la RFC 5321. Ce n'est pas une exécution : les lignes préfixées par [C:] sont envoyées par le client, celles préfixées par [S:] par le serveur, et les domaines [example.org] et [example.com] sont réservés aux exemples :

S: 220 mail.example.com ESMTP prêt
C: EHLO poste.example.org
S: 250-mail.example.com
S: 250-SIZE 10240000
S: 250-STARTTLS
S: 250 8BITMIME
C: MAIL FROM:<alice@example.org>
S: 250 2.1.0 Ok
C: RCPT TO:<bob@example.com>
S: 250 2.1.5 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: From: alice@example.org
C: To: bob@example.com
C: Subject: essai
C:
C: ligne1
C: ligne2
C: .
S: 250 2.0.0 Ok: queued as 4F2A81C0
C: QUIT
S: 221 2.0.0 Bye

ligne 1 : message d'accueil du serveur. Chaque réponse du serveur commence par un code à trois chiffres : 2xx signifie succès, 3xx « continuez », 4xx et 5xx une erreur ;
ligne 2 : le client se présente. La commande [EHLO] a remplacé l'ancienne commande [HELO] : elle demande au serveur la liste des extensions qu'il offre ;
lignes 3-6 : la réponse du serveur, sur plusieurs lignes. Le tiret qui suit le code indique que la réponse continue ; la dernière ligne a un espace à la place. Le serveur annonce ici qu'il accepte des messages de 10 Mo au plus, le passage en mode chiffré et les caractères sur 8 bits ;
ligne 7 : l'adresse de l'expéditeur ;
ligne 9 : l'adresse du destinataire (la commande peut être répétée pour plusieurs destinataires) ;
ligne 11 : le client annonce le message ;
ligne 12 : le serveur l'invite à l'envoyer et lui rappelle comment le terminer ;
lignes 13-19 : le message, formé d'entêtes ([From], [To], [Subject]…), d'une ligne vide et du corps, et terminé par une ligne contenant uniquement un point ;
ligne 20 : le serveur a accepté le message et l'a placé dans sa file d'attente ;
lignes 21-22 : le client signale qu'il a terminé ; le serveur ferme la connexion.

12.4.5. Le protocole POP (Post Office Protocol)

Les serveurs POP3 opèrent sur le port 110, ou sur le port 995 pour une connexion chiffrée par TLS, la seule que proposent aujourd'hui la plupart des fournisseurs, puisque le mot de passe circule dans le dialogue. Voici un dialogue POP3 type, conforme à la RFC 1939, présenté avec les mêmes conventions que le précédent :

S: +OK POP3 serveur prêt
C: USER bob
S: +OK
C: PASS ********
S: +OK Logged in.
C: LIST
S: +OK 2 messages:
S: 1 1205
S: 2 1916
S: .
C: RETR 2
S: +OK 1916 octets
S: Return-Path: <alice@example.org>
S: Delivered-To: bob@example.com
S: ...
S: Date: Sat, 03 Oct 2026 10:59:25 +0200
S: From: alice@example.org
S: To: bob@example.com
S: Subject: essai
S:
S: ligne1
S: ligne2
S: .
C: QUIT
S: +OK Logging out.

ligne 1 : message de bienvenue du serveur. Les réponses POP3 commencent par [+OK] (succès) ou [-ERR] (erreur) ;
ligne 2 : le client donne son identifiant, c'est-à-dire le nom avec lequel il lit son courrier ;
ligne 4 : le mot de passe du client (masqué ici) ;
ligne 6 : le client demande la liste de ses courriers ;
lignes 7-10 : la liste des messages de la boîte aux lettres du client, sous la forme [n° du message, taille en octets], terminée par une ligne contenant uniquement un point ;
ligne 11 : on demande le message n° 2 ;
lignes 12-23 : le message n° 2, avec ses entêtes, une ligne vide et son corps, terminé lui aussi par un point ;
lignes 24-25 : le client indique qu'il a fini ; le serveur ferme la connexion.

POP3 est conçu pour télécharger le courrier sur le poste de l'utilisateur. Il est aujourd'hui largement concurrencé par IMAP (port 143, ou 993 avec TLS ; RFC 9051), qui laisse les messages sur le serveur et permet de les consulter et de les classer depuis plusieurs appareils, et par les messageries web.

12.4.6. Le protocole FTP (File Transfer Protocol)

Le protocole FTP (RFC 959) est plus complexe que ceux présentés précédemment : le dialogue (les commandes et leurs réponses) se fait sur une connexion de contrôle ouverte vers le port 21 du serveur, et chaque transfert de fichier ou de liste de fichiers utilise une seconde connexion, ouverte pour l'occasion. Voici un dialogue type sur la connexion de contrôle :

S: 220 Service FTP prêt
C: USER anonymous
S: 331 Please specify the password.
C: PASS invite@example.org
S: 230 Login successful.
C: PWD
S: 257 "/" is the current directory
C: EPSV
S: 229 Entering Extended Passive Mode (|||40312|)
C: RETR lisezmoi.txt
S: 150 Opening BINARY mode data connection for lisezmoi.txt (1250 bytes).
S: 226 Transfer complete.
C: QUIT
S: 221 Goodbye.

ligne 2 : connexion anonyme, que proposaient les serveurs publics de téléchargement ;
ligne 8 : le client demande au serveur d'ouvrir un port pour la connexion de données. Le serveur répond (ligne 9) qu'il attend cette connexion sur son port 40312 ;
ligne 10 : le client demande le fichier [lisezmoi.txt]. Le fichier arrive sur la connexion de données, et la connexion de contrôle reçoit les réponses 150 (début du transfert) et 226 (fin du transfert).

On peut observer ces commandes dans le journal d'un client FTP comme FileZilla. Mais FTP est en voie de disparition : il transmet les mots de passe en clair, s'accommode mal des pare-feu à cause de sa seconde connexion, et les navigateurs ne le prennent plus en charge depuis 2021 (Chrome 88, Firefox 90). On lui préfère SFTP, le transfert de fichiers par SSH, et le simple téléchargement par HTTPS.

12.5. Les classes Java de la programmation Internet

12.5.1. Choisir la classe adaptée

Java offre différentes classes pour travailler avec le réseau :

la classe [Socket] (paquetage [java.net]) représente l'extrémité d'une connexion TCP. Le terme anglais socket désigne une prise de courant ; il a été étendu pour désigner une prise de réseau logicielle. Dans une communication TCP/IP entre deux machines A et B, ce sont deux sockets qui communiquent entre eux. Un client crée un [Socket] pour se connecter à un serveur ; un serveur crée un [ServerSocket], qui attend les demandes de connexion et fournit, pour chaque client accepté, un [Socket] relié à ce client. Une fois la connexion établie, un [Socket] offre deux flux d'octets, un en lecture et un en écriture, que l'on utilise comme les flux de fichiers. C'est le cas de l'application A ci-dessus ;
la classe [DatagramSocket] permet d'envoyer et de recevoir des datagrammes UDP. Nous ne l'utiliserons pas dans ce cours ;
les classes [SSLSocket] et [SSLServerSocket] (paquetage [javax.net.ssl]) ajoutent au [Socket] le chiffrement TLS : une fois la négociation TLS faite, on les utilise exactement comme des sockets ordinaires (application B ci-dessus) ;
Java offre aussi une classe spécialisée dans un protocole : [HttpClient] (paquetage [java.net.http], Java 11), qui gère le protocole HTTP dans ses versions 1.1 et 2, y compris le chiffrement TLS de HTTPS (application C ci-dessus). Elle remplace la classe [HttpURLConnection] de Java 1.1, nous y reviendrons dans la seconde partie de ce chapitre. Le JDK n'a pas de classe pour le courrier électronique : on utilise pour cela la bibliothèque Jakarta Mail.

Les classes [Socket] et [ServerSocket] existent depuis Java 1.0. Leurs opérations sont bloquantes : [accept] immobilise le thread appelant jusqu'à l'arrivée d'un client, une lecture l'immobilise jusqu'à l'arrivée des données. Java 1.4 a ajouté le paquetage [java.nio.channels] ([SocketChannel], [ServerSocketChannel], [Selector]), qui permet des opérations non bloquantes, et Java 7 des canaux asynchrones ([AsynchronousSocketChannel]). Nous en reparlerons à la fin de ce chapitre, avant l'application exemple : depuis l'arrivée des threads virtuels (Java 21), les classes [Socket] et [ServerSocket], plus simples, suffisent dans la plupart des cas. Ce sont elles que nous utiliserons.

12.5.2. La classe Socket

La classe [Socket] est la classe qui convient dans la plupart des cas pour créer le client d'un service TCP. Elle a, parmi ses constructeurs C et méthodes M, les suivants :

Membre	Type	Rôle
Socket(String machine, int port)	C	établit une connexion TCP avec le service opérant sur le port [port] de la machine [machine]. Par exemple [new Socket("localhost", 27100)]. Lance une [UnknownHostException] si la machine est inconnue, une [ConnectException] si la connexion est refusée (ce sont deux [IOException])
Socket(), void connect(SocketAddress adresse, int delai)	C, M	crée un socket non connecté, puis le connecte en attendant au plus [delai] millisecondes : sans délai, la connexion à une machine qui ne répond pas peut attendre plusieurs dizaines de secondes
InputStream getInputStream(), OutputStream getOutputStream()	M	les flux d'octets de lecture et d'écriture de la connexion. Ce sont eux qui permettent les échanges client-serveur
SocketAddress getLocalSocketAddress(), getRemoteSocketAddress()	M	les deux extrémités de la connexion (adresse et port)
void setSoTimeout(int delai)	M	délai maximal d'attente d'une lecture, en millisecondes : au-delà, la lecture lance une [SocketTimeoutException] (0, valeur par défaut, signifie « pas de délai »)
void shutdownOutput()	M	ferme le seul flux d'écriture : le partenaire voit la fin du flux, mais on peut encore lire sa réponse
void close(), boolean isClosed()	M	ferme la connexion et ses deux flux ; [Socket] implémente [AutoCloseable] et s'utilise donc dans un [try] avec ressources. Une lecture en cours dans un autre thread se termine alors par une [SocketException]

Les flux de [getInputStream] et [getOutputStream] lisent et écrivent des octets. Beaucoup d'applications client-serveur échangent des lignes de texte. Aussi est-il intéressant de les envelopper dans des objets [BufferedReader] et [PrintWriter], rencontrés au chapitre 5, pour lire et écrire ces lignes. Voici comment le client d'écho que nous écrirons plus loin ([Internet05.java]) se connecte et crée ses flux :

    // connexion au service, puis flux de lecture et d'écriture sur la connexion
    try (var client = new Socket(serveur, port);
         var lecteur = new BufferedReader(new InputStreamReader(client.getInputStream(), UTF_8));
         // autoFlush : chaque ligne écrite par println part immédiatement sur le réseau
         var ecrivain = new PrintWriter(client.getOutputStream(), true, UTF_8)) {

ligne 2 : la connexion au serveur. Le [try] avec ressources fermera la connexion et les flux à la sortie du bloc, quoi qu'il arrive ;
ligne 3 : le flux réseau est transformé en flux de caractères ([InputStreamReader]), lui-même enveloppé dans un [BufferedReader], qui sait lire une ligne. Le jeu de caractères est toujours indiqué : les deux partenaires doivent être d'accord sur l'encodage des caractères qu'ils échangent. Depuis Java 18, UTF-8 est le jeu de caractères par défaut, mais l'indiquer explicitement rend le programme indépendant de la configuration de la machine ;
ligne 5 : le second paramètre ([true]) du constructeur de [PrintWriter] active le vidage automatique (« autoFlush ») : chaque appel à [println] transmet immédiatement la ligne au réseau, sans attendre que le tampon interne soit plein. Ce point est important. En général, lorsqu'un client envoie une ligne de texte à son partenaire, il en attend une réponse. Celle-ci ne viendra jamais si la ligne est restée dans le tampon de la machine émettrice sans avoir été envoyée. Sans autoFlush, il faut appeler explicitement [flush] après avoir écrit une demande complète.

Pour envoyer une ligne de texte au serveur, on écrit alors [ecrivain.println("un texte");] et, pour lire la réponse du serveur, [String reponse = lecteur.readLine();]. [readLine] rend [null] lorsque le partenaire a fermé la connexion et que tout ce qu'il a envoyé a été lu : c'est la fin du flux.

Trois points méritent attention :

la fin de ligne. [println] termine la ligne par le séparateur de lignes du système ([System.lineSeparator()]), c'est-à-dire \r\n sous Windows mais \n seul sous Linux et macOS. Les protocoles de l'Internet (HTTP, SMTP, POP, FTP) exigent \r\n. Certains serveurs tolèrent un \n seul, d'autres non ; un programme portable qui parle l'un de ces protocoles doit donc écrire lui-même les fins de ligne : [ecrivain.write(ligne + "\r\n")]. En lecture, [readLine] accepte indifféremment \r\n, \n et \r ;
les erreurs d'écriture. Les méthodes de [PrintWriter] ne lancent jamais d'[IOException] : une erreur est seulement mémorisée, et la méthode [checkError] indique s'il y en a eu une. Pour un dialogue « une demande, une réponse », ce n'est pas gênant : une connexion coupée sera détectée à la lecture de la réponse. Lorsque les erreurs d'écriture doivent être signalées, on utilise un [BufferedWriter] ou un [OutputStreamWriter], dont les méthodes [write] et [flush] lancent une [IOException] ;
les opérations bloquantes. [new Socket(...)], [readLine] et [println] immobilisent le thread qui les exécute jusqu'à la fin de l'opération. Pour un client qui n'a rien d'autre à faire qu'attendre la réponse du serveur, c'est exactement ce qu'il faut. Lorsqu'il doit faire deux choses à la fois (lire le clavier et le réseau, par exemple), on confie l'une d'elles à un autre thread, comme nous le ferons dans le client TCP générique.

L'architecture de base d'un client TCP ayant le protocole de communication basique suivant avec le serveur :

le client envoie une demande contenue dans une unique ligne ;
le serveur envoie une réponse contenue dans une unique ligne,

est donc la suivante : ouvrir dans un [try] avec ressources le socket et ses deux flux, puis répéter « envoi d'une demande par [println], lecture de la réponse par [readLine] » jusqu'à la fin du dialogue, en interceptant les [IOException] : une [UnknownHostException] ou une [ConnectException] signale une connexion impossible (machine inconnue, aucun service sur le port demandé…), une autre [IOException] une erreur pendant les échanges (connexion coupée…). C'est la structure du client d'écho que nous écrirons au paragraphe [Un client pour le serveur d'écho].

12.5.3. La classe ServerSocket

La classe [ServerSocket] est la classe qui convient dans la plupart des cas pour créer un service TCP. Elle a, parmi ses constructeurs C et méthodes M, les suivants :

Membre	Type	Rôle
ServerSocket(int port)	C	crée un service TCP qui attend (listen) les demandes des clients sur le port [port], appelé port d'écoute, de toutes les adresses de la machine (IPv4 et IPv6). Lance une [BindException] si le port est déjà utilisé
ServerSocket(int port, int fileAttente, InetAddress adresse)	C	idem, en n'écoutant que sur l'adresse [adresse] (par exemple l'adresse de bouclage, pour n'accepter que les clients de la machine locale). [fileAttente] est le nombre maximal de demandes de connexion en attente d'acceptation (50 par défaut)
Socket accept()	M	attend la demande d'un client et l'accepte. Rend comme résultat le [Socket] associé, côté serveur, à la connexion de service ouverte avec ce client
void close()	M	arrête d'écouter les demandes des clients ; un [accept] en cours dans un autre thread se termine par une [SocketException]
SocketAddress getLocalSocketAddress()	M	l'adresse et le port d'écoute

Voici, extraite du serveur d'écho que nous écrirons plus loin ([Internet04.java]), la structure de base d'un serveur TCP :

    // le service d'écoute, sur toutes les interfaces réseau de la machine
    try (var ecoute = new ServerSocket(port);
         // un thread virtuel par client ; close() attend la fin de tous les services
         var services = Executors.newVirtualThreadPerTaskExecutor()) {
        // Ctrl-C : le serveur s'arrête proprement
        arreterSurCtrlC(ecoute);
        IO.println("Serveur d'écho lancé sur " + ecoute.getLocalSocketAddress());
        try {
            // boucle d'attente des clients - arrêtée par Ctrl-C
            for (int numClient = 0; ; numClient++) {
                // attente (bloquante) d'un client
                Socket client = ecoute.accept();
                connexions.add(client);
                // le client est servi par un thread virtuel ; on retourne aussitôt attendre le suivant
                int numero = numClient;
                services.submit(() -> servir(client, numero));
            }

ligne 2 : le service d'écoute est créé pour un port donné. Une machine a au moins deux adresses IP : l'adresse de bouclage 127.0.0.1 et l'adresse qu'elle a sur le réseau auquel elle est connectée. Elle peut en avoir d'autres si elle est connectée à plusieurs réseaux. Sans adresse précisée, le service écoute sur toutes ces adresses. Dès sa création, le service écoute, c'est-à-dire attend les demandes de connexion des clients ;
ligne 4 : un [ExecutorService] (chapitre 8) qui crée un thread virtuel pour chaque tâche qu'on lui soumet. Il est lui aussi déclaré dans le [try] avec ressources : sa méthode [close] attend la fin de toutes les tâches soumises ;
lignes 10-17 : la boucle attente d'un client / lancement de son service, répétée pour chaque nouveau client ;
ligne 12 : la demande d'un client est acceptée. [accept] rend un [Socket] dit de service :
- le client a fait sa demande avec son propre [Socket], que nous appellerons [SocketDemande] ;
- le serveur accepte cette demande avec [accept], qui crée un [Socket] côté serveur, que nous appellerons [SocketService]. On a alors une connexion TCP ouverte avec, aux deux bouts, les sockets [SocketDemande] ↔ [SocketService] ;
- la communication client / serveur qui prend place ensuite se fait sur cette connexion. Le service d'écoute n'intervient plus ;
ligne 16 : afin que le serveur puisse traiter plusieurs clients à la fois, le service est assuré par un thread virtuel. Le serveur ne l'attend pas : il retourne immédiatement attendre le client suivant. La lambda passée à [submit] ne peut utiliser que des variables locales qui ne changent plus de valeur (« effectivement finales ») : la variable de boucle [numClient] est donc recopiée dans la variable [numero] (ligne 15).

La méthode [servir], exécutée par le thread virtuel, reçoit le [Socket] déjà connecté au client qui doit être servi. On y retrouve un code similaire à celui du client TCP : création des flux, puis boucle « lecture d'une demande par [readLine], écriture de la réponse par [println] », jusqu'à ce que [readLine] rende [null], c'est-à-dire jusqu'à ce que le client ferme la connexion. Les exceptions doivent être interceptées dans cette méthode : personne n'attend le résultat du thread de service, et une exception non interceptée y passerait inaperçue (elle serait seulement affichée sur la sortie d'erreur).

12.5.4. Un thread par client : threads de plate-forme ou threads virtuels ?

Avant Java 21, un serveur confiait chaque client à un thread de plate-forme, c'est-à-dire à un thread du système d'exploitation, ou à un thread d'un pool de taille fixe ([Executors.newFixedThreadPool]). Ce thread exécutait des lectures et des écritures bloquantes : pendant tout le temps où le client réfléchissait, son thread restait immobilisé dans [readLine]. Chaque thread de plate-forme coûte de la mémoire (une pile d'environ 1 Mo réservée) et du temps processeur au système, qui doit passer de l'un à l'autre. Avec quelques dizaines de clients, cela ne pose aucun problème ; avec des milliers de connexions simultanées, situation courante pour un serveur réel, le serveur s'effondre. Avec un pool limité à 10 threads, le onzième client doit attendre qu'un des dix premiers se déconnecte.

Pour échapper à cette limite, on a longtemps dû renoncer aux opérations bloquantes : les canaux non bloquants de [java.nio] et leur [Selector], qui permet à un seul thread de surveiller de nombreuses connexions, ou les canaux asynchrones de Java 7, qui appellent une méthode de rappel à la fin de chaque opération. Ces techniques sont efficaces mais difficiles à programmer : la logique du dialogue est éclatée entre plusieurs méthodes. Elles sont à la base de bibliothèques comme Netty, utilisées par de nombreux serveurs.

Les threads virtuels (Java 21, chapitre 8) ont changé la donne. Un thread virtuel est géré par la machine virtuelle Java et non par le système. Lorsqu'il exécute une opération réseau bloquante, il est « démonté » de son thread porteur (« carrier thread »), qui peut alors exécuter un autre thread virtuel ; il est remonté sur un thread porteur lorsque les données arrivent. Quelques threads porteurs, autant que de cœurs du processeur, suffisent ainsi à servir des milliers de clients, et un client qui n'envoie rien ne consomme presque rien : quelques centaines d'octets de pile. Le code, lui, reste celui, simple et séquentiel, du modèle « un thread par client ». C'est ce modèle que nous utiliserons dans tous les serveurs de ce chapitre : [ServerSocket.accept] dans le thread principal, un thread virtuel par client.

12.6. Exemples de clients / serveurs TCP

Les programmes de cette partie sont des fichiers source compacts du dossier [12-internet], exécutés par le lanceur de code source ([java Internet04.java ...]). Les serveurs et les clients sont lancés dans des fenêtres de commandes différentes, sur la même machine ; les ports utilisés sont de la forme 271xx.

12.6.1. Un serveur d'écho

Nous nous proposons d'écrire un serveur d'écho, qui sera lancé depuis une fenêtre de commandes par :

1	`java Internet04.java port`

Le serveur officie sur le port passé en paramètre. Il se contente de renvoyer au client chaque ligne que celui-ci lui envoie, entourée de crochets. Le programme [Internet04.java] est le suivant :

import static java.nio.charset.StandardCharsets.UTF_8;

// serveur d'écho : renvoie à chaque client les lignes que celui-ci lui envoie
// chaque client est servi par un thread virtuel
// appel : java Internet04.java port ; arrêt par Ctrl-C

final String SYNTAXE = "Syntaxe : java Internet04.java port";

// les connexions de service en cours, fermées à l'arrêt du serveur
final Set<Socket> connexions = ConcurrentHashMap.newKeySet();
// l'arrêt du serveur a-t-il été demandé ?
volatile boolean arret = false;

void main(String[] args) {
    // il faut un argument : un port entre 1 et 65535
    int port = args.length == 1 ? entier(args[0]) : -1;
    if (port < 1 || port > 65535) {
        IO.println(SYNTAXE);
        return;
    }
    // le service d'écoute, sur toutes les interfaces réseau de la machine
    try (var ecoute = new ServerSocket(port);
         // un thread virtuel par client ; close() attend la fin de tous les services
         var services = Executors.newVirtualThreadPerTaskExecutor()) {
        // Ctrl-C : le serveur s'arrête proprement
        arreterSurCtrlC(ecoute);
        IO.println("Serveur d'écho lancé sur " + ecoute.getLocalSocketAddress());
        try {
            // boucle d'attente des clients - arrêtée par Ctrl-C
            for (int numClient = 0; ; numClient++) {
                // attente (bloquante) d'un client
                Socket client = ecoute.accept();
                connexions.add(client);
                // le client est servi par un thread virtuel ; on retourne aussitôt attendre le suivant
                int numero = numClient;
                services.submit(() -> servir(client, numero));
            }
        } catch (SocketException e) {
            // accept échoue lorsque Ctrl-C ferme le service d'écoute
            if (!arret) {
                throw e;
            }
            IO.println("Arrêt du serveur demandé");
            // on ferme les connexions en cours : les services s'arrêtent
            for (Socket connexion : connexions) {
                connexion.close();
            }
        }
    } catch (IOException e) {
        IO.println("L'erreur suivante s'est produite sur le serveur : " + e.getMessage());
    }
}

// Ctrl-C : fermeture du service d'écoute, puis attente de la fin du programme principal
void arreterSurCtrlC(ServerSocket ecoute) {
    Thread principal = Thread.currentThread();
    Runtime.getRuntime().addShutdownHook(new Thread(() -> {
        arret = true;
        try {
            ecoute.close();
            // la machine virtuelle s'arrête à la fin de ce thread : on attend la fin du thread principal
            principal.join();
        } catch (IOException | InterruptedException e) {
            // on s'arrête de toute façon
        }
    }));
}

// le service rendu à un client
void servir(Socket client, int numClient) {
    IO.println("Début du service au client " + numClient + " (" + client.getRemoteSocketAddress() + ")");
    // la connexion et ses flux sont fermés à la sortie du try
    try (client;
         var lecteur = new BufferedReader(new InputStreamReader(client.getInputStream(), UTF_8));
         var ecrivain = new PrintWriter(client.getOutputStream(), true, UTF_8)) {
        // boucle lecture demande / écriture réponse
        // readLine rend null lorsque le client ferme la connexion
        String demande;
        while ((demande = lecteur.readLine()) != null) {
            IO.println("<--- client " + numClient + " : " + demande);
            // écho de la demande vers le client, entre crochets
            ecrivain.println("[" + demande + "]");
            IO.println("---> client " + numClient + " : [" + demande + "]");
        }
    } catch (IOException e) {
        if (arret) {
            IO.println("Service au client " + numClient + " interrompu par l'arrêt du serveur");
        } else {
            IO.println("L'erreur suivante s'est produite lors du service au client " + numClient + " : "
                    + e.getMessage());
        }
    } finally {
        connexions.remove(client);
        IO.println("Fin du service au client " + numClient);
    }
}

// un entier, ou -1 si la chaîne n'en est pas un
int entier(String chaine) {
    try {
        return Integer.parseInt(chaine);
    } catch (NumberFormatException e) {
        return -1;
    }
}

La structure du serveur d'écho est conforme à l'architecture de base des serveurs TCP exposée précédemment, avec quelques compléments :

lignes 10 et 12 : deux champs de la classe implicite du fichier source compact. L'ensemble [connexions] contient les connexions de service en cours ; plusieurs threads y ajoutent et y retirent des éléments en même temps, c'est donc un ensemble prévu pour l'accès concurrent, obtenu par [ConcurrentHashMap.newKeySet()] (chapitre 8). Le booléen [arret] indique si l'arrêt du serveur a été demandé ; il est déclaré [volatile] parce qu'il est modifié par un thread et lu par d'autres ;
lignes 16-20 : le port doit être un entier compris entre 1 et 65 535. La méthode [entier] (lignes 99-105) rend -1 si l'argument n'est pas un entier ;
lignes 22-24 : le service d'écoute et l'[ExecutorService] qui crée un thread virtuel par client ;
ligne 26 : l'arrêt du serveur. Ctrl-C ne permet pas d'exécuter une méthode choisie par le programme, comme le ferait un gestionnaire d'événement : il arrête la machine virtuelle. Mais, avant de s'arrêter, celle-ci exécute les « crochets d'arrêt » (« shutdown hooks ») qui ont été enregistrés par [Runtime.getRuntime().addShutdownHook]. Notre crochet (lignes 55-67) est un thread qui note que l'arrêt est demandé (ligne 58), ferme le service d'écoute (ligne 60), puis attend la fin du thread principal (ligne 62) : la machine virtuelle s'arrête en effet dès que les crochets sont terminés ;
ligne 32 : la fermeture du service d'écoute fait échouer l'attente d'un client, qui lance une [SocketException], interceptée ligne 38. Si l'arrêt n'a pas été demandé, c'est une véritable erreur : on la relance (ligne 41), pour qu'elle soit traitée par le [catch] de la ligne 49 ;
lignes 43-47 : on ferme toutes les connexions de service en cours : les threads de service, bloqués dans une lecture, reçoivent une [SocketException] et se terminent. À la sortie du [try] avec ressources, la méthode [close] de l'[ExecutorService] attend la fin de tous les services avant que la méthode [main] se termine.

La partie « service au client » :

ligne 71 : l'adresse et le port du client ;
lignes 73-75 : le socket du client, déclaré en tête du [try] avec ressources (Java 9 accepte une variable déjà déclarée), et les flux de lecture et d'écriture sur la connexion ;
ligne 79 : la demande du client est lue. [readLine] rend [null] lorsque le client ferme la connexion : la boucle et le service s'arrêtent alors ;
ligne 82 : la demande est renvoyée au client, entourée de crochets ;
lignes 85-91 : une [IOException] signale soit l'arrêt du serveur, qui a fermé la connexion pendant la lecture, soit une connexion coupée par le client ;
lignes 92-95 : le [finally] retire la connexion de l'ensemble des connexions en cours et signale la fin du service, quelle qu'en soit la cause.

Pour voir le serveur fonctionner, il nous faut un client. Nous l'écrivons au paragraphe suivant et présenterons les résultats après lui.

12.6.2. Un client pour le serveur d'écho

Nous écrivons maintenant un client pour le serveur précédent. Il sera appelé de la façon suivante :

1	`java Internet05.java machine port`

Il se connecte à la machine [machine] sur le port [port], puis envoie au serveur les lignes de texte tapées au clavier, que celui-ci lui renvoie en écho. Le programme [Internet05.java] est le suivant :

import static java.nio.charset.StandardCharsets.UTF_8;

// client d'écho : envoie au serveur les lignes tapées au clavier
// et affiche les réponses du serveur
// appel : java Internet05.java machine port

final String SYNTAXE = "Syntaxe : java Internet05.java machine port";

void main(String[] args) {
    int port = args.length == 2 ? entier(args[1]) : -1;
    if (port < 1 || port > 65535) {
        IO.println(SYNTAXE);
        return;
    }
    String serveur = args[0];

    // connexion au service, puis flux de lecture et d'écriture sur la connexion
    try (var client = new Socket(serveur, port);
         var lecteur = new BufferedReader(new InputStreamReader(client.getInputStream(), UTF_8));
         // autoFlush : chaque ligne écrite par println part immédiatement sur le réseau
         var ecrivain = new PrintWriter(client.getOutputStream(), true, UTF_8)) {
        IO.println("Connecté au serveur " + client.getRemoteSocketAddress() + " depuis "
                + client.getLocalSocketAddress());
        // boucle demande - réponse
        while (true) {
            // la demande vient du clavier
            String demande = IO.readln("Demande (bye pour arrêter) : ");
            // fini ?
            if (demande == null || demande.strip().equalsIgnoreCase("bye")) {
                break;
            }
            // on envoie la demande au serveur
            ecrivain.println(demande);
            // on attend sa réponse
            String reponse = lecteur.readLine();
            if (reponse == null) {
                IO.println("Le serveur a fermé la connexion");
                break;
            }
            IO.println("Réponse : " + reponse);
        }
    } catch (IOException e) {
        IO.println("L'erreur suivante s'est produite : " + e.getClass().getSimpleName()
                + " (" + e.getMessage() + ")");
    }
}

// un entier, ou -1 si la chaîne n'en est pas un
int entier(String chaine) {
    try {
        return Integer.parseInt(chaine);
    } catch (NumberFormatException e) {
        return -1;
    }
}

La structure de ce client est conforme à l'architecture de base proposée pour les clients TCP :

lignes 18-21 : connexion au serveur et création des flux, déjà commentées ;
lignes 22-23 : on affiche les deux extrémités de la connexion : [getRemoteSocketAddress] (le serveur) et [getLocalSocketAddress] (le client). Le port du client a été choisi par le système ;
ligne 27 : la demande est tapée au clavier. [IO.readln] rend [null] si l'entrée standard est fermée (Ctrl-D sous Linux, Ctrl-Z puis Entrée sous Windows) ;
ligne 29 : la comparaison avec [bye] ignore la casse ;
ligne 33 : la demande est envoyée au serveur ;
lignes 35-39 : on attend la réponse ; [null] signale que le serveur a fermé la connexion ;
lignes 42-45 : les erreurs de connexion et d'échange.

Voici les résultats obtenus dans la configuration suivante :

le serveur est lancé sur le port 27100 dans une fenêtre de commandes ;
sur la même machine, deux clients A et B sont lancés dans deux autres fenêtres, B ayant démarré pendant que A dialoguait encore avec le serveur.

Dans la fenêtre du client A :

> java Internet05.java localhost 27100
Connecté au serveur localhost/127.0.0.1:27100 depuis /127.0.0.1:47902
Demande (bye pour arrêter) : ligne1A
Réponse : [ligne1A]
Demande (bye pour arrêter) : ligne2A
Réponse : [ligne2A]
Demande (bye pour arrêter) : ligne3A
Réponse : [ligne3A]
Demande (bye pour arrêter) : bye

Le client A a envoyé trois lignes, reçues en écho, puis a tapé [bye] : il a fermé la connexion sans rien envoyer au serveur.

Dans la fenêtre du client B :

> java Internet05.java localhost 27100
Connecté au serveur localhost/127.0.0.1:27100 depuis /127.0.0.1:45096
Demande (bye pour arrêter) : ligne1B
Réponse : [ligne1B]
Demande (bye pour arrêter) : ligne2B
Réponse : [ligne2B]
Demande (bye pour arrêter) : ligne3B
Le serveur a fermé la connexion

Le client B a envoyé deux lignes puis, avant qu'il ne tape la troisième, le serveur a été arrêté par Ctrl-C. La ligne [ligne3B] a été envoyée sur une connexion déjà fermée par le serveur : la lecture de la réponse (ligne 8 des résultats) a rendu [null].

Dans la fenêtre du serveur :

> java Internet04.java 27100
Serveur d'écho lancé sur 0.0.0.0/0.0.0.0:27100
Début du service au client 0 (/127.0.0.1:47902)
<--- client 0 : ligne1A
---> client 0 : [ligne1A]
Début du service au client 1 (/127.0.0.1:45096)
<--- client 0 : ligne2A
---> client 0 : [ligne2A]
<--- client 1 : ligne1B
---> client 1 : [ligne1B]
<--- client 0 : ligne3A
---> client 0 : [ligne3A]
<--- client 1 : ligne2B
---> client 1 : [ligne2B]
Fin du service au client 0
Arrêt du serveur demandé
Service au client 1 interrompu par l'arrêt du serveur
Fin du service au client 1

ligne 2 : le serveur écoute sur le port 27100 de toutes les adresses de la machine, représentées par l'adresse joker 0.0.0.0 ;
lignes 3 et 6 : les deux clients sont arrivés depuis la même machine (127.0.0.1) avec des ports différents, choisis par le système. Ce sont eux qui distinguent les deux connexions, qui aboutissent toutes deux au port 27100 du serveur ;
ligne 6 : le client 1 (B) est servi alors que le client 0 (A) l'est encore, et les lignes 7-14 montrent que leurs demandes sont traitées au fur et à mesure de leur arrivée : le serveur sert bien plusieurs clients simultanément ;
ligne 15 : le serveur a constaté la fermeture de la connexion par le client A ;
lignes 16-18 : Ctrl-C a été tapé dans la fenêtre du serveur. L'attente d'un nouveau client a échoué, puis le service au client 1, qui attendait une ligne, a été interrompu par la fermeture de sa connexion. Le serveur s'est arrêté proprement.

Voici ce qui se passe lorsqu'on tente de se connecter à un port sur lequel aucun service n'écoute :

1 2	`> java Internet05.java localhost 27199 L'erreur suivante s'est produite : ConnectException (Connection refused)`

Le constructeur de [Socket] a lancé une [ConnectException] : la machine a répondu, mais aucun programme n'écoute sur le port 27199. Le message vient du système d'exploitation ; il est différent sous Windows.

Enfin, si l'on lance le serveur sur un port déjà utilisé, par exemple dans une seconde fenêtre alors que le premier serveur fonctionne encore, la création du [ServerSocket] échoue :

1 2	`> java Internet04.java 27100 L'erreur suivante s'est produite sur le serveur : Address already in use`

12.6.3. Un client TCP générique

Nous allons écrire un client TCP générique, qui sera lancé de la façon suivante :

1	`java Internet06.java machine port`

Il aura un fonctionnement analogue à celui des clients [telnet] et PuTTY : il permettra de dialoguer avec n'importe quel serveur TCP à lignes de texte.

Dans l'application précédente, le protocole du dialogue était connu : le client envoyait une seule ligne et le serveur répondait par une seule ligne. Chaque service a son protocole particulier, et on rencontre également les situations suivantes :

le client doit envoyer plusieurs lignes de texte avant d'avoir une réponse (une requête HTTP) ;
la réponse d'un serveur peut comporter plusieurs lignes de texte (la réponse [EHLO] d'un serveur SMTP, un document HTML) ;
le serveur peut parler le premier (le message d'accueil des serveurs SMTP et POP).

Le cycle « envoi d'une unique ligne au serveur / réception d'une unique ligne envoyée par le serveur » ne convient donc pas toujours. Pour gérer des protocoles plus complexes que celui de l'écho, le client TCP générique mène deux activités en parallèle, dans deux threads :

un thread virtuel lit les lignes de texte tapées au clavier et les envoie au serveur ;
le thread principal lit les lignes de texte envoyées par le serveur. Dès qu'il en reçoit une, il l'affiche sur la console. Il ne s'arrête que lorsque la connexion est fermée.

Le programme [Internet06.java] est le suivant :

import static java.nio.charset.StandardCharsets.UTF_8;

// client TCP générique
// - se connecte au service (machine, port)
// - un thread virtuel envoie au serveur chaque ligne tapée au clavier
// - le thread principal affiche en continu les lignes envoyées par le serveur
// appel : java Internet06.java machine port

final String SYNTAXE = "Syntaxe : java Internet06.java machine port";
// fin demandée au clavier (bye) ?
volatile boolean fin = false;

void main(String[] args) {
    int port = args.length == 2 ? entier(args[1]) : -1;
    if (port < 1 || port > 65535) {
        IO.println(SYNTAXE);
        return;
    }
    String serveur = args[0];

    // connexion au service
    Socket client;
    try {
        client = new Socket(serveur, port);
    } catch (IOException e) {
        IO.println("Impossible de se connecter au service (" + serveur + ", " + port + ") : "
                + e.getMessage());
        return;
    }
    try (client;
         var lecteur = new BufferedReader(new InputStreamReader(client.getInputStream(), UTF_8));
         var ecrivain = new OutputStreamWriter(client.getOutputStream(), UTF_8)) {
        IO.println("Tapez vos commandes (bye pour arrêter) :");
        // la lecture des commandes clavier est confiée à un thread virtuel
        Thread.ofVirtual().start(() -> saisir(client, ecrivain));
        // le thread principal affiche les lignes du serveur jusqu'à la fermeture de la connexion
        String reponse;
        while ((reponse = lecteur.readLine()) != null) {
            IO.println("<-- " + reponse);
        }
        IO.println("[le serveur a fermé la connexion]");
    } catch (IOException e) {
        // une connexion fermée par le thread de saisie (bye) n'est pas une erreur
        if (!fin) {
            IO.println("L'erreur suivante s'est produite à la lecture : " + e.getMessage());
        }
    }
    // fin du thread principal : le thread virtuel de saisie, s'il attend encore le clavier, est abandonné
}

// envoie au serveur les lignes tapées au clavier, jusqu'à bye
void saisir(Socket client, Writer ecrivain) {
    try {
        while (true) {
            String commande = IO.readln();
            // fini ?
            if (commande == null || commande.strip().equalsIgnoreCase("bye")) {
                break;
            }
            // les lignes envoyées se terminent par \r\n, comme l'exigent HTTP, SMTP, POP, FTP...
            ecrivain.write(commande + "\r\n");
            ecrivain.flush();
        }
    } catch (IOException e) {
        IO.println("L'erreur suivante s'est produite à l'écriture : " + e.getMessage());
    } finally {
        // on ferme la connexion : la lecture en cours dans le thread principal se termine
        fin = true;
        try {
            client.close();
        } catch (IOException e) {
            // rien à faire
        }
    }
}

// un entier, ou -1 si la chaîne n'en est pas un
int entier(String chaine) {
    try {
        return Integer.parseInt(chaine);
    } catch (NumberFormatException e) {
        return -1;
    }
}

lignes 23-29 : le client se connecte au serveur ;
lignes 30-32 : le socket et ses flux, fermés à la sortie du [try]. Le flux d'écriture est un simple [OutputStreamWriter], dont les méthodes lancent une [IOException] en cas d'erreur ;
ligne 35 : la lecture du clavier est confiée à un thread virtuel, créé et démarré par [Thread.ofVirtual().start] (Java 21), qui exécute la méthode [saisir] (lignes 52-75) ;
lignes 37-41 : pendant ce temps, le thread principal affiche, précédée de [<--], chaque ligne envoyée par le serveur, jusqu'à la fin du flux (ligne 41) ;
lignes 42-47 : lorsque l'utilisateur tape [bye], le thread de saisie ferme la connexion (ligne 70) ; la lecture en cours dans le thread principal se termine alors par une [SocketException]. Ce n'est pas une erreur : le champ [fin], positionné par le thread de saisie (ligne 68), permet de le savoir ;
ligne 48 : lorsque le serveur ferme la connexion, le thread principal se termine, alors que le thread de saisie attend peut-être encore une ligne au clavier. Ce n'est pas gênant : un thread virtuel est toujours un thread « démon » (« daemon thread »), et la machine virtuelle s'arrête lorsque tous les threads qui ne sont pas des démons sont terminés, ici le seul thread principal. Il est inutile, contrairement à ce qu'il faudrait faire avec un thread ordinaire, d'arrêter le thread de saisie ;
lignes 55-63 : le thread de saisie lit les lignes tapées au clavier et les envoie au serveur. Les lignes envoyées se terminent par \r\n, comme l'exigent les protocoles que nous voulons explorer, et sont immédiatement transmises au réseau par [flush].

Nous pouvons maintenant faire « à la main » une requête HTTP à notre serveur web de test ([Internet03.java]), lancé dans une autre fenêtre. Les lignes précédées de [<--] sont celles envoyées par le serveur ; les autres ont été tapées au clavier :

> java Internet06.java localhost 27110
Tapez vos commandes (bye pour arrêter) :
GET /bonjour?nom=Serge HTTP/1.1
Host: localhost:27110
Connection: close

<-- HTTP/1.1 200 OK
<-- Date: Sat, 03 Oct 2026 17:40:20 GMT
<-- Transfer-encoding: chunked
<-- Content-type: text/plain; charset=utf-8
<-- 
<-- f
<-- Bonjour Serge !
<-- 0
<-- 
[le serveur a fermé la connexion]

lignes 3-5 : la requête, tapée au clavier : on demande le document [/bonjour?nom=Serge]. L'entête [Connection: close] demande au serveur de fermer la connexion une fois sa réponse envoyée ;
ligne 6 : la ligne vide termine la requête. C'est elle qui déclenche la réponse du serveur ;
ligne 7 : le document a été trouvé ;
ligne 9 : le serveur n'a pas annoncé la taille du document ([Content-length]) ; il l'envoie par morceaux (chunks), chacun précédé de sa taille en hexadécimal ;
ligne 10 : cette fois, le document est un texte brut ;
lignes 12-14 : un seul morceau de 0x0f = 15 octets, le texte [Bonjour Serge !], suivi d'un morceau de taille 0 qui marque la fin du document ;
ligne 16 : comme demandé, le serveur a fermé la connexion. Le client l'a constaté et s'est arrêté de lui-même, sans attendre que l'utilisateur tape [bye].

Recommençons sans l'entête [Connection: close], en demandant la racine du site :

> java Internet06.java localhost 27110
Tapez vos commandes (bye pour arrêter) :
GET / HTTP/1.1
Host: localhost:27110

<-- HTTP/1.1 200 OK
<-- Date: Sat, 03 Oct 2026 17:40:23 GMT
<-- Content-type: text/html; charset=utf-8
<-- Content-length: 176
<-- 
<-- <!DOCTYPE html>
<-- <html lang="fr">
<-- <head><meta charset="utf-8"><title>Serveur de test</title></head>
<-- <body><h1>Bienvenue sur le serveur de test du cours Java</h1></body>
<-- </html>
bye

ligne 9 : le document est annoncé avec sa taille, 176 octets. Le client sait ainsi où il se termine ;
lignes 15-16 : le document a été entièrement reçu, mais le serveur n'a pas fermé la connexion : en HTTP/1.1, elle reste ouverte par défaut pour d'autres requêtes. Le serveur attend une nouvelle requête ; l'utilisateur tape alors [bye] pour fermer la connexion.

Lorsque le serveur est absent, la connexion échoue :

1 2	`> java Internet06.java localhost 27199 Impossible de se connecter au service (localhost, 27199) : Connection refused`

Le lecteur pourra utiliser ce client TCP générique avec le serveur d'écho, ou, s'il dispose d'un serveur SMTP ou POP3 acceptant les connexions en clair (un serveur de test installé localement, par exemple), pour reproduire les dialogues types présentés plus haut.

12.6.4. Un serveur TCP générique

Nous nous intéressons maintenant à un serveur :

qui affiche à l'écran les lignes envoyées par ses clients ;
qui leur envoie comme réponses les lignes de texte tapées au clavier par un utilisateur. C'est donc ce dernier qui fait office de serveur.

Le programme est lancé dans une fenêtre de commandes par [java Internet07.java port], où [port] est le port sur lequel les clients doivent se connecter. Les clients sont servis l'un après l'autre et non en parallèle : la console ne peut être utilisée pour deux clients simultanément. Les clients qui se présentent pendant ce temps voient leur connexion établie par le système, mais attendent que le programme les accepte. Trois activités se déroulent en parallèle :

un thread virtuel lit les lignes tapées au clavier, pendant toute la durée du programme ;
pour chaque client, un thread virtuel lit les lignes envoyées par le client et les affiche ;
le thread principal accepte les clients et envoie au client courant les lignes tapées au clavier. L'utilisateur signale par la commande [bye] qu'il clôt la connexion avec le client.

Le thread principal doit donc attendre deux sortes d'événements : une ligne tapée au clavier, ou le départ du client. Les deux autres threads les lui signalent en les plaçant dans une file d'attente bloquante ([BlockingQueue], chapitre 8), dans laquelle il les prend un par un. Le serveur ne s'arrête que par un Ctrl-C tapé au clavier par l'utilisateur, ou lorsque l'entrée standard est fermée. Le programme [Internet07.java] est le suivant :

import static java.nio.charset.StandardCharsets.UTF_8;

// serveur TCP générique
// - affiche les lignes envoyées par le client
// - lui envoie comme réponses les lignes tapées au clavier par l'utilisateur
// les clients sont servis l'un après l'autre (une seule console)
// appel : java Internet07.java port ; arrêt par Ctrl-C

final String SYNTAXE = "Syntaxe : java Internet07.java port";

// les événements attendus par le programme principal
sealed interface Evenement permits Saisie, FinSaisie, DepartClient {
}

// une ligne tapée au clavier
record Saisie(String ligne) implements Evenement {
}

// fin de l'entrée standard (Ctrl-D, Ctrl-Z)
record FinSaisie() implements Evenement {
}

// le client n° [numClient] a fermé la connexion
record DepartClient(int numClient) implements Evenement {
}

// la file des événements, alimentée par deux threads virtuels : le clavier et la lecture du client
final BlockingQueue<Evenement> evenements = new LinkedBlockingQueue<>();

void main(String[] args) throws InterruptedException {
    int port = args.length == 1 ? entier(args[0]) : -1;
    if (port < 1 || port > 65535) {
        IO.println(SYNTAXE);
        return;
    }
    // le service d'écoute
    try (var ecoute = new ServerSocket(port)) {
        IO.println("Serveur générique lancé sur " + ecoute.getLocalSocketAddress());
        // un thread virtuel lit le clavier pendant toute la durée du programme
        Thread.ofVirtual().start(this::lireClavier);
        // boucle de service - le serveur est arrêté par Ctrl-C
        for (int numClient = 0; ; numClient++) {
            // attente d'un client
            IO.println("Attente du client suivant...");
            Socket client = ecoute.accept();
            IO.println("Client " + client.getRemoteSocketAddress());
            // un thread virtuel affiche les lignes envoyées par le client
            int numero = numClient;
            Thread reception = Thread.ofVirtual().start(() -> recevoir(client, numero));
            IO.println("Tapez vos réponses (bye pour fermer la connexion avec le client) :");
            boolean continuer = true;
            // la connexion avec le client est fermée à la sortie du try
            try (client; var ecrivain = new OutputStreamWriter(client.getOutputStream(), UTF_8)) {
                // on traite les événements jusqu'à la fin de la connexion avec ce client
                continuer = servir(ecrivain, numClient);
            } catch (IOException e) {
                IO.println("L'erreur suivante s'est produite à l'écriture : " + e.getMessage());
            }
            // on attend la fin du thread de réception
            reception.join();
            // fin de l'entrée standard : arrêt du serveur
            if (!continuer) {
                return;
            }
        }
    } catch (IOException e) {
        IO.println("L'erreur suivante s'est produite sur le serveur : " + e.getMessage());
    }
}

// le dialogue avec le client n° [numClient] ; rend false si l'entrée standard a été fermée
boolean servir(Writer ecrivain, int numClient) throws IOException, InterruptedException {
    while (true) {
        // on attend soit une ligne tapée au clavier, soit le départ du client
        switch (evenements.take()) {
            case DepartClient(int numero) when numero == numClient -> {
                IO.println("[le client a fermé la connexion]");
                return true;
            }
            case DepartClient _ -> {
                // départ d'un client précédent, déjà traité : on l'ignore
            }
            case FinSaisie _ -> {
                return false;
            }
            case Saisie(String reponse) when reponse.strip().equalsIgnoreCase("bye") -> {
                IO.println("[connexion fermée par le serveur]");
                return true;
            }
            case Saisie(String reponse) -> {
                // on envoie la réponse au client
                ecrivain.write(reponse + "\r\n");
                ecrivain.flush();
            }
        }
    }
}

// lit le clavier et place chaque ligne tapée dans la file des événements
void lireClavier() {
    String ligne;
    while ((ligne = IO.readln()) != null) {
        evenements.add(new Saisie(ligne));
    }
    evenements.add(new FinSaisie());
}

// affiche les lignes envoyées par le client jusqu'à la fermeture de la connexion
void recevoir(Socket client, int numClient) {
    try {
        var lecteur = new BufferedReader(new InputStreamReader(client.getInputStream(), UTF_8));
        String demande;
        while ((demande = lecteur.readLine()) != null) {
            IO.println("<-- " + demande);
        }
    } catch (IOException e) {
        // la connexion a été fermée par le serveur pendant la lecture
    }
    // on signale le départ du client au programme principal
    evenements.add(new DepartClient(numClient));
}

// un entier, ou -1 si la chaîne n'en est pas un
int entier(String chaine) {
    try {
        return Integer.parseInt(chaine);
    } catch (NumberFormatException e) {
        return -1;
    }
}

lignes 12-25 : les trois sortes d'événements, des enregistrements qui implémentent une interface scellée ([sealed], Java 17) : la clause [permits] donne la liste exhaustive de ses implémentations. Dans un fichier source compact, ces types sont des membres de la classe implicite ;
ligne 28 : la file des événements. [LinkedBlockingQueue] peut être utilisée sans précaution par plusieurs threads à la fois ;
ligne 37 : le service d'écoute, sur toutes les interfaces réseau de la machine ;
ligne 40 : le thread virtuel de lecture du clavier, qui exécute la méthode [lireClavier] (lignes 100-106). Il place chaque ligne lue dans la file, puis un événement [FinSaisie] lorsque l'entrée standard est fermée. Il est lancé une seule fois : lorsqu'un client ferme la connexion, la lecture du clavier en cours servira au client suivant. Lancer une nouvelle lecture pour chaque client ferait se disputer deux lectures pour les mêmes touches ;
ligne 42 : boucle infinie d'attente des clients. L'utilisateur arrêtera le serveur par Ctrl-C ;
ligne 45 : attente d'un client. Lorsqu'il arrive, le [Socket] rendu par [accept] représente le côté serveur de la connexion ouverte avec lui ;
ligne 49 : la lecture des lignes envoyées par le client est confiée à un thread virtuel, qui exécute la méthode [recevoir] (lignes 109-121). Lorsque la connexion est fermée, celle-ci place dans la file un événement [DepartClient] portant le numéro du client ;
lignes 53-58 : le dialogue avec le client, confié à la méthode [servir]. La connexion est fermée à la sortie du [try] avec ressources ;
ligne 60 : on attend la fin du thread de réception avec [join] ;
lignes 62-64 : si l'entrée standard a été fermée, le serveur s'arrête ;
lignes 72-97 : la méthode [servir] prend les événements dans la file (ligne 75) et les traite avec un [switch] sur des motifs d'enregistrements (Java 21). L'interface étant scellée, le compilateur vérifie que tous les cas sont traités :
- ligne 76 : le motif [DepartClient(int numero)] déconstruit l'enregistrement et place son champ dans la variable [numero] ; la garde [when] vérifie qu'il s'agit du client courant ;
- ligne 80 : un événement [DepartClient] pour un autre client vient d'une connexion fermée par le serveur lui-même (commande [bye]) : il est ignoré. Le motif anonyme [_] (Java 22) indique que l'on n'a pas besoin de l'objet ;
- lignes 83-85 : fin de l'entrée standard ;
- lignes 86-89 : la commande [bye] ferme la connexion avec le client courant ;
- lignes 90-94 : toute autre ligne tapée est envoyée au client, terminée par \r\n.

Utilisons ce serveur pour simuler un serveur web interrogé par un client HTTP, ici [curl]. Le serveur générique est lancé sur le port 27101. Dans une autre fenêtre, on demande à [curl] l'URL [http://localhost:27101/exemple.html]. [curl] se connecte alors au port 27101 de la machine [localhost] et demande le document [/exemple.html]. Voici la fenêtre du serveur :

> java Internet07.java 27101
Serveur générique lancé sur 0.0.0.0/0.0.0.0:27101
Attente du client suivant...
Client /127.0.0.1:60386
Tapez vos réponses (bye pour fermer la connexion avec le client) :
<-- GET /exemple.html HTTP/1.1
<-- Host: localhost:27101
<-- User-Agent: curl/8.5.0
<-- Accept: */*
<-- 
HTTP/1.1 200 OK
Server: serveur tcp generique
Connection: close
Content-Type: text/html; charset=utf-8

<html><head><title>Serveur générique</title></head>
<body><h1>Réponse du serveur générique</h1></body></html>
bye
[connexion fermée par le serveur]
Attente du client suivant...

ligne 4 : un client est arrivé ;
lignes 6-10 : on découvre la requête HTTP envoyée par [curl], terminée par une ligne vide. Un navigateur enverrait bien plus d'entêtes (langues et formats acceptés, compression, cookies…) : le lecteur peut faire l'essai en demandant la même URL à son navigateur ;
lignes 11-17 : l'utilisateur au clavier est ici le véritable serveur, et il élabore la réponse à la main. Il s'en tient au strict minimum : une ligne de statut, trois entêtes, une ligne vide et le document HTML. Il ne donne pas la taille du document ([Content-Length]) mais annonce qu'il fermera la connexion après l'avoir envoyé ([Connection: close]). C'est suffisant : en voyant la connexion fermée, le client saura que la réponse est terminée ;
lignes 18-19 : l'utilisateur a tapé [bye] : le serveur ferme la connexion avec le client ;
ligne 20 : le serveur attend un nouveau client. On l'arrête par Ctrl-C.

Et voici ce qu'a affiché [curl] :

> curl -sv http://localhost:27101/exemple.html
* Host localhost:27101 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
*   Trying 127.0.0.1:27101...
* Connected to localhost (127.0.0.1) port 27101
> GET /exemple.html HTTP/1.1
> Host: localhost:27101
> User-Agent: curl/8.5.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Server: serveur tcp generique
< Connection: close
< Content-Type: text/html; charset=utf-8
< 
{ [55 bytes data]
* Closing connection
<html><head><title>Serveur générique</title></head>
<body><h1>Réponse du serveur générique</h1></body></html>

[curl] a reçu exactement ce qui a été tapé dans la fenêtre du serveur (lignes 12-16 et 19-20) et a constaté la fermeture de la connexion (ligne 18). Un navigateur aurait affiché la page HTML reçue, avec son titre [Serveur générique] dans l'onglet.

12.6.5. Un client web

Nous avons vu dans l'exemple précédent les entêtes HTTP qu'envoie [curl]. Nous allons écrire un client web auquel on passe en paramètre une URL, et qui affiche à l'écran tout ce que lui envoie le serveur. Nous supposons que celui-ci comprend le protocole HTTP/1.1. Notre client enverra la requête suivante :

GET /document HTTP/1.1
Host: machine:port
User-Agent: client-web-cours-java
Connection: close

la première ligne indique le document désiré ;
l'entête [Host], le serveur interrogé ;
l'entête [User-Agent], l'identité de notre client ;
l'entête [Connection], que nous souhaitons que le serveur ferme la connexion après nous avoir répondu : nous lirons sa réponse jusqu'à la fin du flux ;
la ligne vide termine la requête.

Si, dans la première ligne, nous remplaçons [GET] par [HEAD], le serveur ne nous enverra que les entêtes HTTP de sa réponse, et pas le document.

Notre client web sera appelé de la façon suivante : [java Internet08.java URL commande], où [URL] est l'URL désirée et [commande] l'un des deux mots clés [GET] ou [HEAD]. Le programme [Internet08.java] est le suivant :

import static java.nio.charset.StandardCharsets.UTF_8;

// client web : demande une URL avec une requête HTTP/1.1 écrite « à la main »
// et affiche tout ce que renvoie le serveur (entêtes HTTP et document)
// appel : java Internet08.java URL GET|HEAD

final String SYNTAXE = "Syntaxe : java Internet08.java http://machine[:port][/document] GET|HEAD";

void main(String[] args) {
    if (args.length != 2) {
        IO.println(SYNTAXE);
        return;
    }
    // vérification de l'URL : elle doit être absolue et utiliser le schéma http
    URI uri = analyser(args[0]);
    if (uri == null) {
        IO.println("URL incorrecte [" + args[0] + "]. " + SYNTAXE);
        return;
    }
    // vérification de la commande
    String commande = args[1].toUpperCase();
    if (!commande.equals("GET") && !commande.equals("HEAD")) {
        IO.println("Le second paramètre doit être GET ou HEAD. " + SYNTAXE);
        return;
    }

    // connexion au serveur web : le port 80 est le port par défaut de HTTP
    int port = uri.getPort() == -1 ? 80 : uri.getPort();
    try (var client = new Socket(uri.getHost(), port);
         var lecteur = new BufferedReader(new InputStreamReader(client.getInputStream(), UTF_8));
         var ecrivain = new BufferedWriter(new OutputStreamWriter(client.getOutputStream(), UTF_8))) {
        // la requête : ligne de commande, entêtes HTTP, ligne vide ; HTTP impose la fin de ligne \r\n
        ecrivain.write(commande + " " + cheminEtRequete(uri) + " HTTP/1.1\r\n");
        ecrivain.write("Host: " + uri.getRawAuthority() + "\r\n");
        ecrivain.write("User-Agent: client-web-cours-java\r\n");
        ecrivain.write("Connection: close\r\n");
        ecrivain.write("\r\n");
        // la requête part en une fois sur le réseau
        ecrivain.flush();
        // la réponse est lue jusqu'à ce que le serveur ferme la connexion
        String ligne;
        while ((ligne = lecteur.readLine()) != null) {
            IO.println(ligne);
        }
    } catch (IOException e) {
        IO.println("L'erreur suivante s'est produite : " + e.getClass().getSimpleName()
                + " (" + e.getMessage() + ")");
    }
}

// une URL absolue http correcte, ou null
URI analyser(String url) {
    try {
        URI uri = new URI(url);
        return uri.isAbsolute() && uri.getScheme().equals("http") && uri.getHost() != null ? uri : null;
    } catch (URISyntaxException e) {
        return null;
    }
}

// le chemin du document et les paramètres éventuels, par exemple /bonjour?nom=Serge
String cheminEtRequete(URI uri) {
    String chemin = uri.getRawPath().isEmpty() ? "/" : uri.getRawPath();
    return uri.getRawQuery() == null ? chemin : chemin + "?" + uri.getRawQuery();
}

La nouveauté de ce programme est l'utilisation de la classe [URI] (paquetage [java.net]). Le programme reçoit une URL (Uniform Resource Locator), forme particulière d'URI (Uniform Resource Identifier), de la forme [http://serveur:port/chemin?param1=val1&param2=val2]. La classe [URI] permet de décomposer cette chaîne en ses différents éléments :

lignes 52-59 : le constructeur [URI(String)] analyse la chaîne et lance une [URISyntaxException] (une exception contrôlée) si elle n'est pas une URI valide ; la méthode statique [URI.create] fait la même chose en lançant une [IllegalArgumentException]. On vérifie ensuite que l'URI est absolue (elle commence par un schéma), que le schéma est [http] (notre client ne sait pas faire la négociation TLS de [https]) et qu'elle désigne une machine. Une fois l'objet [URI] construit, on a accès aux différents éléments de l'URI. Ainsi, si l'objet [uri] a été construit à partir de la chaîne [http://localhost:27110/bonjour?nom=Serge], on a :
- [uri.getScheme()] : http ;
- [uri.getHost()] : localhost ;
- [uri.getPort()] : 27110 (-1 si le port n'est pas indiqué dans l'URL : c'est alors le port par défaut du schéma, 80 pour http, 443 pour https) ;
- [uri.getRawAuthority()] : localhost:27110 ;
- [uri.getRawPath()] : /bonjour ;
- [uri.getRawQuery()] : nom=Serge ;
- les méthodes [getPath], [getQuery]… rendent les mêmes éléments, mais décodés (nous verrons plus loin ce qu'est l'encodage d'une URL) : pour construire une requête, il faut utiliser les versions « brutes » ([getRawXxx]) ;
lignes 62-65 : le chemin et les paramètres, tels qu'ils doivent figurer dans la requête ; un chemin vide désigne la racine [/] du site ;
ligne 21 : la commande doit être [GET] ou [HEAD] ;
lignes 28-29 : connexion au serveur désigné par l'URL, sur le port 80 si l'URL n'en indique pas ;
ligne 31 : le flux d'écriture est un [BufferedWriter] sans vidage automatique ;
lignes 33-37 : la requête HTTP. HTTP exige des fins de ligne \r\n, écrites explicitement ;
ligne 39 : la requête est envoyée en une seule fois, après avoir été entièrement écrite ;
lignes 41-44 : la réponse est affichée jusqu'à ce que le serveur ferme la connexion.

Demandons les seuls entêtes de la racine de notre serveur de test :

> java Internet08.java http://localhost:27110/ HEAD
HTTP/1.1 200 OK
Date: Sat, 03 Oct 2026 17:40:36 GMT
Content-type: text/html; charset=utf-8
Content-length: 176

On obtient la ligne de statut et les entêtes, terminés par une ligne vide, mais pas le document. L'entête [Content-length] donne la taille qu'aurait eue le document avec la commande [GET]. Avec la commande [GET] et un document envoyé par morceaux :

> java Internet08.java "http://localhost:27110/bonjour?nom=Serge" GET
HTTP/1.1 200 OK
Date: Sat, 03 Oct 2026 17:40:36 GMT
Transfer-encoding: chunked
Content-type: text/plain; charset=utf-8

f
Bonjour Serge !
0

On remarquera les guillemets autour de l'URL dans la commande : sans eux, certains interpréteurs de commandes donneraient un sens particulier au caractère [?]. Le document ([Bonjour Serge !]) est encadré par les tailles de ses morceaux, comme nous l'avons déjà vu. Notre client affiche la réponse brute ; un vrai client HTTP doit, lui, reconstituer le document à partir des morceaux.

Un document inexistant :

> java Internet08.java http://localhost:27110/inconnu GET
HTTP/1.1 404 Not Found
Date: Sat, 03 Oct 2026 17:40:36 GMT
Content-length: 0

Une URL qui fait l'objet d'une redirection :

> java Internet08.java http://localhost:27110/ancienne GET
HTTP/1.1 302 Temporary Redirect
Date: Sat, 03 Oct 2026 17:40:36 GMT
Content-length: 0
Location: /bonjour?nom=visiteur

ligne 2 : le code 302 indique une redirection : le document demandé se trouve, temporairement, à une autre adresse. Le message qui suit le code est libre : le serveur du JDK écrit [Temporary Redirect], d'autres serveurs [Found] (le message de la RFC) ou [Moved Temporarily] ;
ligne 5 : cette adresse est donnée par l'entête [Location]. Elle est ici relative : l'adresse complète est [http://localhost:27110/bonjour?nom=visiteur].

Notre client s'est arrêté là. Un navigateur, lui, aurait demandé automatiquement la nouvelle adresse. C'est ce que fera notre prochain client.

Enfin, une URL [https] est refusée :

1 2	`> java Internet08.java https://www.oracle.com/java/ GET URL incorrecte [https://www.oracle.com/java/]. Syntaxe : java Internet08.java http://machine[:port][/document] GET\|HEAD`

12.6.6. Un client web gérant les redirections

Le client web précédent ne gère pas une éventuelle redirection de l'URL qu'il a demandée. Les codes de statut de redirection sont les suivants :

Code	Signification
301 Moved Permanently	le document a définitivement changé d'adresse ; un navigateur pourra mémoriser la nouvelle adresse
302 Found	le document se trouve temporairement à une autre adresse
303 See Other	la réponse doit être demandée à une autre adresse, avec la méthode [GET] (utilisé après l'envoi d'un formulaire)
307 Temporary Redirect, 308 Permanent Redirect	comme 302 et 301, mais le client doit refaire la requête avec la même méthode ([POST] reste [POST])

Dans tous les cas, la nouvelle adresse est donnée par l'entête [Location], sous forme absolue ou relative. Détecter une redirection à la présence d'un mot comme [moved] dans la ligne de statut serait fragile : le message qui suit le code est libre, et nous venons de voir que le serveur du JDK répond [302 Temporary Redirect]. Nous nous fondons sur le code de statut lui-même.

Le programme [Internet09.java] est le suivant :

import static java.nio.charset.StandardCharsets.UTF_8;

// client web qui suit les redirections (codes 301, 302, 303, 307, 308)
// appel : java Internet09.java URL GET|HEAD

final String SYNTAXE = "Syntaxe : java Internet09.java http://machine[:port][/document] GET|HEAD";
// les codes de statut HTTP qui signalent une redirection
final Set<Integer> CODES_REDIRECTION = Set.of(301, 302, 303, 307, 308);
// nombre maximal de redirections suivies
final int NB_REDIRECTIONS_MAX = 3;

void main(String[] args) {
    if (args.length != 2) {
        IO.println(SYNTAXE);
        return;
    }
    URI uri = analyser(args[0]);
    if (uri == null) {
        IO.println("URL incorrecte [" + args[0] + "]. " + SYNTAXE);
        return;
    }
    String commande = args[1].toUpperCase();
    if (!commande.equals("GET") && !commande.equals("HEAD")) {
        IO.println("Le second paramètre doit être GET ou HEAD. " + SYNTAXE);
        return;
    }

    try {
        // une itération par URL demandée
        for (int nbRedirections = 0; ; nbRedirections++) {
            // on demande l'URL et on récupère l'éventuelle adresse de redirection
            Optional<String> location = demander(uri, commande);
            // pas de redirection : c'est fini
            if (location.isEmpty()) {
                break;
            }
            // trop de redirections : on abandonne
            if (nbRedirections == NB_REDIRECTIONS_MAX) {
                IO.println("<-- Abandon : plus de " + NB_REDIRECTIONS_MAX + " redirections -->");
                break;
            }
            // la nouvelle URL : l'adresse de redirection peut être absolue ou relative à l'URL courante
            uri = uri.resolve(location.get());
            IO.println("<-- Redirection vers " + uri + " -->\n");
        }
    } catch (IOException | IllegalArgumentException e) {
        IO.println("L'erreur suivante s'est produite : " + e.getClass().getSimpleName()
                + " (" + e.getMessage() + ")");
    }
}

// demande l'URL [uri], affiche la réponse du serveur
// rend l'adresse de redirection, ou un Optional vide s'il n'y a pas de redirection
Optional<String> demander(URI uri, String commande) throws IOException {
    int port = uri.getPort() == -1 ? 80 : uri.getPort();
    try (var client = new Socket(uri.getHost(), port);
         var lecteur = new BufferedReader(new InputStreamReader(client.getInputStream(), UTF_8));
         var ecrivain = new BufferedWriter(new OutputStreamWriter(client.getOutputStream(), UTF_8))) {
        // la requête HTTP
        ecrivain.write(commande + " " + cheminEtRequete(uri) + " HTTP/1.1\r\n");
        ecrivain.write("Host: " + uri.getRawAuthority() + "\r\n");
        ecrivain.write("User-Agent: client-web-cours-java\r\n");
        ecrivain.write("Connection: close\r\n");
        ecrivain.write("\r\n");
        ecrivain.flush();

        // la ligne de statut, par exemple : HTTP/1.1 302 Found
        String ligneStatut = Objects.requireNonNullElse(lecteur.readLine(), "");
        IO.println(ligneStatut);
        String[] champs = ligneStatut.split(" ");
        boolean redirection = champs.length >= 2 && CODES_REDIRECTION.contains(entier(champs[1]));

        // les entêtes HTTP, jusqu'à la ligne vide
        String location = null;
        String entete;
        while ((entete = lecteur.readLine()) != null && !entete.isEmpty()) {
            IO.println(entete);
            // le nom d'un entête HTTP est insensible à la casse
            if (redirection && entete.regionMatches(true, 0, "Location:", 0, "Location:".length())) {
                location = entete.substring("Location:".length()).strip();
            }
        }
        IO.println();
        // le document éventuel
        String ligne;
        while ((ligne = lecteur.readLine()) != null) {
            IO.println(ligne);
        }
        return Optional.ofNullable(location);
    }
}

// une URL absolue http correcte, ou null
URI analyser(String url) {
    try {
        URI uri = new URI(url);
        return uri.isAbsolute() && uri.getScheme().equals("http") && uri.getHost() != null ? uri : null;
    } catch (URISyntaxException e) {
        return null;
    }
}

// le chemin du document et les paramètres éventuels, par exemple /bonjour?nom=Serge
String cheminEtRequete(URI uri) {
    String chemin = uri.getRawPath().isEmpty() ? "/" : uri.getRawPath();
    return uri.getRawQuery() == null ? chemin : chemin + "?" + uri.getRawQuery();
}

// un entier, ou -1 si la chaîne n'en est pas un
int entier(String chaine) {
    try {
        return Integer.parseInt(chaine);
    } catch (NumberFormatException e) {
        return -1;
    }
}

Par rapport à la version précédente, les changements sont les suivants :

ligne 8 : les codes de statut qui signalent une redirection, dans un ensemble non modifiable créé par [Set.of] (chapitre 5) ;
ligne 10 : le nombre maximal de redirections suivies. Sans limite, un serveur mal configuré pourrait entraîner notre client dans une boucle infinie (les navigateurs abandonnent après une vingtaine de redirections) ;
ligne 30 : le code qui était exécuté précédemment pour une unique URL peut l'être maintenant successivement pour plusieurs URL ;
ligne 32 : la méthode [demander] demande l'URL courante, affiche la réponse et rend l'adresse de redirection, sous la forme d'un [Optional<String>] (chapitre 3), vide s'il n'y a pas de redirection ;
lignes 38-41 : on abandonne si le nombre maximal de redirections est atteint ;
ligne 43 : la méthode [resolve] de la classe [URI] calcule la nouvelle URL. Si [location] est une adresse absolue, elle est utilisée telle quelle ; si elle est relative, elle est complétée à partir de l'URL courante [uri]. [resolve] lance une [IllegalArgumentException] si l'adresse est incorrecte : elle est interceptée ligne 46 ;
lignes 54-91 : la demande d'une URL :
- ligne 68 : on lit la ligne de statut, par exemple [HTTP/1.1 302 Temporary Redirect]. [Objects.requireNonNullElse] remplace [null] (connexion fermée par le serveur avant toute réponse) par une chaîne vide ;
- lignes 70-71 : on en extrait le code, deuxième champ de la ligne, et on regarde s'il fait partie des codes de redirection ;
- lignes 76-82 : on lit les entêtes jusqu'à la ligne vide. S'il y a redirection, on cherche l'entête [Location], sans tenir compte de la casse puisque les noms d'entêtes HTTP y sont insensibles : [regionMatches(true, ...)] compare le début de l'entête à [Location:] en ignorant la casse ;
- lignes 85-89 : le reste de la réponse est affiché, puis on rend l'adresse de redirection trouvée.

Reprenons l'URL [/ancienne] :

> java Internet09.java http://localhost:27110/ancienne GET
HTTP/1.1 302 Temporary Redirect
Date: Sat, 03 Oct 2026 17:40:36 GMT
Content-length: 0
Location: /bonjour?nom=visiteur

<-- Redirection vers http://localhost:27110/bonjour?nom=visiteur -->

HTTP/1.1 200 OK
Date: Sat, 03 Oct 2026 17:40:36 GMT
Transfer-encoding: chunked
Content-type: text/plain; charset=utf-8

12
Bonjour visiteur !
0

lignes 2-6 : la redirection temporaire vers une adresse relative ;
ligne 7 : la nouvelle URL, complétée par [uri.resolve(location)] ;
lignes 9-17 : la réponse à la nouvelle URL. Le document, de 0x12 = 18 octets, a été envoyé par morceaux.

L'URL [/deplacee] fait l'objet d'une redirection permanente vers une adresse absolue :

> java Internet09.java http://localhost:27110/deplacee GET
HTTP/1.1 301 Moved Permanently
Date: Sat, 03 Oct 2026 17:40:36 GMT
Content-length: 0
Location: http://localhost:27110/

<-- Redirection vers http://localhost:27110/ -->

HTTP/1.1 200 OK
Date: Sat, 03 Oct 2026 17:40:36 GMT
Content-type: text/html; charset=utf-8
Content-length: 176

<!DOCTYPE html>
<html lang="fr">
<head><meta charset="utf-8"><title>Serveur de test</title></head>
<body><h1>Bienvenue sur le serveur de test du cours Java</h1></body>
</html>

L'URL [/boucle] redirige vers elle-même :

> java Internet09.java http://localhost:27110/boucle HEAD
HTTP/1.1 302 Temporary Redirect
Date: Sat, 03 Oct 2026 17:40:37 GMT
Location: /boucle

<-- Redirection vers http://localhost:27110/boucle -->

HTTP/1.1 302 Temporary Redirect
Date: Sat, 03 Oct 2026 17:40:37 GMT
Location: /boucle

<-- Redirection vers http://localhost:27110/boucle -->

HTTP/1.1 302 Temporary Redirect
Date: Sat, 03 Oct 2026 17:40:37 GMT
Location: /boucle

<-- Redirection vers http://localhost:27110/boucle -->

HTTP/1.1 302 Temporary Redirect
Date: Sat, 03 Oct 2026 17:40:37 GMT
Location: /boucle

<-- Abandon : plus de 3 redirections -->

Notre client a suivi trois redirections, puis a abandonné (ligne 24). Avec la commande [HEAD], aucun document n'a été envoyé.

La fenêtre du serveur web a enregistré toutes les requêtes des paragraphes [Un client web] et [Un client web gérant les redirections] :

> java Internet03.java
Serveur web lancé sur http://localhost:27110
HEAD / HTTP/1.1 -> 200
GET /bonjour?nom=Serge HTTP/1.1 -> 200
GET /inconnu HTTP/1.1 -> 404
GET /ancienne HTTP/1.1 -> 302
GET /ancienne HTTP/1.1 -> 302
GET /bonjour?nom=visiteur HTTP/1.1 -> 200
GET /deplacee HTTP/1.1 -> 301
GET / HTTP/1.1 -> 200
HEAD /boucle HTTP/1.1 -> 302
HEAD /boucle HTTP/1.1 -> 302
HEAD /boucle HTTP/1.1 -> 302
HEAD /boucle HTTP/1.1 -> 302

On y retrouve, pour chaque redirection, la requête qui l'a provoquée puis la requête vers la nouvelle adresse (lignes 7-8 et 9-10), et les quatre requêtes de la boucle interrompue (lignes 11-14).

Écrire un client HTTP sur TCP permet de comprendre le protocole, mais un client réel doit gérer bien d'autres choses : le chiffrement TLS, l'envoi par morceaux, la compression, les connexions persistantes, HTTP/2… La seconde partie de ce chapitre présente la classe [HttpClient] de Java, qui fait tout cela pour nous.

12.7. Les classes Java spécialisées dans un protocole

Dans les exemples précédents, le protocole HTTP était géré avec un client TCP : il nous fallait construire nous-mêmes les requêtes, analyser les lignes de statut et les entêtes, suivre les redirections. Nous aurions pu construire de la même façon un client SMTP ou POP. Il existe des classes spécialisées dans ces protocoles : elles connaissent le protocole de communication entre le client et le serveur et évitent au développeur d'avoir à le gérer. Pour HTTP, le JDK fournit la classe [HttpClient] ; pour le courrier électronique, on utilise la bibliothèque Jakarta Mail. Nous les présentons maintenant.

Les programmes de cette seconde partie sont, comme ceux de la première, des fichiers source compacts du dossier [12-internet], numérotés à la suite ([Internet10] à [Internet19]). Ceux qui ont besoin d'une bibliothèque (Jackson pour le JSON, Jakarta Mail pour le courrier) sont des projets Maven, rangés dans un dossier du même nom ([Internet10/], [Internet14/], [Internet19/]). L'application exemple de la fin du chapitre forme un projet Maven à part, [ImpotsV8]. Les ports utilisés sont de la forme 272xx.

12.7.1. Les classes URL et HttpURLConnection, aujourd'hui dépassées

Avant Java 11, un programme Java qui voulait parler HTTP disposait de deux classes, présentes depuis les premières versions de Java :

la classe [URL], dont la méthode [openStream] donnait en une instruction un flux de lecture du document désigné par l'URL ;
la classe [HttpURLConnection], obtenue par la méthode [openConnection] de [URL], plus souple : elle permettait de choisir la méthode HTTP ([GET], [HEAD], [POST]), d'ajouter des entêtes, de lire le code de statut et les entêtes de la réponse.

Ces classes existent toujours dans Java 25, mais elles ont mal vieilli : [HttpURLConnection] est entièrement synchrone, ne connaît que HTTP/1.1, s'utilise au moyen d'une suite d'appels dont l'ordre est imposé (fixer les entêtes avant d'écrire le document, lire le code de statut avant le document…) et signale les codes d'erreur par des exceptions. Quant aux constructeurs de la classe [URL], qui n'analysaient pas correctement toutes les URL, ils sont déclarés obsolètes depuis Java 20 : on construit maintenant un objet [URI], puis on le convertit si nécessaire par sa méthode [toURL]. Un petit programme [Ancien.java] contenant l'instruction [var url = new URL("http://localhost:27210/");] donne à la compilation l'avertissement suivant :

> javac -Xlint:all Ancien.java
Ancien.java:2: warning: [deprecation] URL(String) in URL has been deprecated
    var url = new URL("http://localhost:27210/");
              ^
1 warning

Java 11 a apporté la classe [HttpClient] (paquetage [java.net.http]), conçue d'emblée pour HTTP/1.1 et HTTP/2, pour les requêtes synchrones et asynchrones, et capable de réutiliser ses connexions et d'être utilisée par plusieurs threads à la fois. C'est elle qu'il faut utiliser aujourd'hui. Nous ne présenterons pas davantage [URL] et [HttpURLConnection], que le lecteur rencontrera encore dans du code ancien.

12.7.2. La classe HttpClient

12.7.2.1. Un serveur web de test

Pour illustrer les possibilités de [HttpClient], il nous faut un serveur web plus riche que celui de la première partie ([Internet03.java]) : il doit accepter des formulaires, échanger du JSON, et savoir se faire attendre. Nous écrivons donc un second serveur de test, [Internet10], fondé lui aussi sur le serveur HTTP du JDK. Pour échanger du JSON, il utilise la bibliothèque Jackson (chapitre 5) : c'est donc un projet Maven. Là encore, il n'est pas nécessaire de comprendre ce programme en détail : il suffit de savoir ce que répond chaque URL. Le projet a l'arborescence Maven habituelle :

12-internet/Internet10/
  pom.xml
  src/main/java/internet/
    Internet10.java      le serveur
    Personne.java        une personne, échangée au format JSON

Le fichier [pom.xml] est le suivant :

<?xml version="1.0" encoding="UTF-8"?>
<!-- un serveur web local de test pour les clients java.net.http.HttpClient -->
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>exemples.internet</groupId>
    <artifactId>internet10</artifactId>
    <version>1.0</version>

    <properties>
        <maven.compiler.release>25</maven.compiler.release>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    </properties>

    <dependencies>
        <!-- Jackson 3 pour les échanges au format JSON -->
        <dependency>
            <groupId>tools.jackson.core</groupId>
            <artifactId>jackson-databind</artifactId>
            <version>3.1.5</version>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.15.0</version>
                <configuration>
                    <parameters>true</parameters>
                    <compilerArgs>
                        <arg>-Xlint:all</arg>
                    </compilerArgs>
                </configuration>
            </plugin>
            <!-- mvn exec:java exécute la classe principale -->
            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>exec-maven-plugin</artifactId>
                <version>3.5.1</version>
                <configuration>
                    <mainClass>internet.Internet10</mainClass>
                </configuration>
            </plugin>
        </plugins>
    </build>
</project>

lignes 8-10 : l'identité du projet ;
lignes 12-15 : la version de Java et l'encodage des fichiers source ;
lignes 19-23 : la seule dépendance, Jackson 3 ;
lignes 28-38 : le compilateur, avec tous les avertissements ([-Xlint:all]) ;
lignes 40-47 : le plugin qui exécute la classe principale par la commande [mvn exec:java].

Le type [Personne] est un enregistrement :

package internet;

// une personne, échangée au format JSON
public record Personne(int id, String nom, int age) {
}

La classe [Internet10] est la suivante :

package internet;

import com.sun.net.httpserver.HttpExchange;
import com.sun.net.httpserver.HttpServer;
import java.io.IOException;
import java.net.InetAddress;
import java.net.InetSocketAddress;
import java.net.URLDecoder;
import java.nio.charset.StandardCharsets;
import java.util.ArrayList;
import java.util.LinkedHashMap;
import java.util.List;
import java.util.Map;
import java.util.TreeMap;
import java.util.concurrent.Executors;
import java.util.regex.Matcher;
import java.util.regex.Pattern;
import java.util.stream.Collectors;
import tools.jackson.databind.json.JsonMapper;

// un serveur web local qui servira de cible aux clients java.net.http.HttpClient
// appel : mvn exec:java [-Dexec.args="port"]   (port 27210 par défaut) ; arrêt par Ctrl-C
public class Internet10 {

    // la page d'accueil : un document HTML
    private static final String ACCUEIL = """
            <!DOCTYPE html>
            <html lang="fr">
            <head><meta charset="utf-8"><title>Serveur de test</title></head>
            <body><h1>Bienvenue sur le serveur de test HttpClient</h1></body>
            </html>
            """;
    // les types des documents envoyés
    private static final String TEXTE = "text/plain; charset=utf-8";
    private static final String JSON = "application/json";
    // GET /api/personnes/n : une personne désignée par son numéro
    private static final Pattern PERSONNE = Pattern.compile("GET /api/personnes/(\\d+)");

    // une petite « base » de personnes, échangée au format JSON, et son verrou
    private final List<Personne> personnes = new ArrayList<>(List.of(
            new Personne(1, "Dupont", 42), new Personne(2, "Durand", 35)));
    private final Object verrou = new Object();
    // le convertisseur objets <-> JSON
    private final JsonMapper mapper = JsonMapper.builder().build();

    public static void main(String[] args) throws IOException {
        int port = args.length == 1 ? Integer.parseInt(args[0]) : 27210;
        var adresse = new InetSocketAddress(InetAddress.getLoopbackAddress(), port);
        HttpServer serveur = HttpServer.create(adresse, 0);
        serveur.createContext("/", new Internet10()::traiter);
        // chaque requête est traitée par un thread virtuel : une requête lente ne bloque pas les autres
        serveur.setExecutor(Executors.newVirtualThreadPerTaskExecutor());
        serveur.start();
        IO.println("Serveur web lancé sur http://localhost:" + port);
    }

    // traitement d'une requête, puis suivi console : la requête, le port du client et le code de statut
    private void traiter(HttpExchange echange) {
        String debut = "%s %s %s (port client %d)".formatted(echange.getRequestMethod(),
                echange.getRequestURI(), echange.getProtocol(), echange.getRemoteAddress().getPort());
        try (echange) {
            repondre(echange);
            IO.println(debut + " -> " + echange.getResponseCode());
        } catch (IOException e) {
            // la connexion a été coupée pendant l'échange
            IO.println(debut + " -> erreur : " + e.getMessage());
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
    }

    // la réponse selon la méthode et le chemin de l'URL
    private void repondre(HttpExchange echange) throws IOException, InterruptedException {
        String route = echange.getRequestMethod() + " " + echange.getRequestURI().getPath();
        // les paramètres de l'URL
        Map<String, String> parametresUrl = parametres(echange.getRequestURI().getRawQuery());
        switch (route) {
            // la page d'accueil : un document HTML
            case "GET /", "HEAD /" -> envoyer(echange, 200, ACCUEIL, "text/html; charset=utf-8");
            // un document texte construit à partir d'un paramètre de l'URL
            case "GET /bonjour", "HEAD /bonjour" -> envoyer(echange, 200,
                    "Bonjour " + parametresUrl.getOrDefault("nom", "inconnu") + " !", TEXTE);
            // les entêtes HTTP reçus par le serveur (ordre alphabétique), renvoyés sous forme de texte
            case "GET /entetes", "HEAD /entetes" -> envoyer(echange, 200,
                    new TreeMap<>(echange.getRequestHeaders()).entrySet().stream()
                            .map(entete -> entete.getKey() + ": " + String.join(", ", entete.getValue()))
                            .collect(Collectors.joining("\n")),
                    TEXTE);
            // redirection temporaire (302) vers une adresse relative
            case "GET /ancienne", "HEAD /ancienne" -> rediriger(echange, "/bonjour?nom=visiteur");
            // une redirection qui boucle sur elle-même
            case "GET /boucle", "HEAD /boucle" -> rediriger(echange, "/boucle");
            // une erreur du serveur (500 Internal Server Error)
            case "GET /erreur", "HEAD /erreur" -> echange.sendResponseHeaders(500, -1);
            // une réponse qui se fait attendre : le thread virtuel est suspendu pendant l'attente
            case "GET /lent" -> {
                int secondes = Integer.parseInt(parametresUrl.get("secondes"));
                Thread.sleep(secondes * 1000L);
                envoyer(echange, 200, "Réponse obtenue après " + secondes + " s", TEXTE);
            }
            // un formulaire envoyé par POST : on décrit ce qui a été reçu
            case "POST /formulaire" -> {
                Map<String, String> champs = parametres(lireDocument(echange));
                String type = echange.getRequestHeaders().getFirst("Content-Type");
                String description = champs.entrySet().stream()
                        .map(champ -> champ.getKey() + "=[" + champ.getValue() + "]")
                        .collect(Collectors.joining(", "));
                envoyer(echange, 200, "Content-Type reçu : " + type + "\nChamps reçus : " + description,
                        TEXTE);
            }
            // un texte quelconque envoyé par POST : on le renvoie en majuscules
            case "POST /texte" -> envoyer(echange, 200,
                    "Content-Type reçu : " + echange.getRequestHeaders().getFirst("Content-Type")
                            + "\nTexte reçu en majuscules : " + lireDocument(echange).toUpperCase(),
                    TEXTE);
            // la liste des personnes
            case "GET /api/personnes" -> {
                synchronized (verrou) {
                    envoyer(echange, 200, mapper.writeValueAsString(personnes), JSON);
                }
            }
            // ajout d'une personne : le serveur lui attribue un numéro et répond 201 Created
            case "POST /api/personnes" -> {
                Personne nouvelle = mapper.readValue(lireDocument(echange), Personne.class);
                synchronized (verrou) {
                    int id = personnes.stream().mapToInt(Personne::id).max().orElse(0) + 1;
                    Personne creee = new Personne(id, nouvelle.nom(), nouvelle.age());
                    personnes.add(creee);
                    echange.getResponseHeaders().set("Location", "/api/personnes/" + id);
                    envoyer(echange, 201, mapper.writeValueAsString(creee), JSON);
                }
            }
            default -> {
                // une personne désignée par son numéro, ou 404 si elle n'existe pas
                Matcher matcher = PERSONNE.matcher(route);
                if (matcher.matches()) {
                    int id = Integer.parseInt(matcher.group(1));
                    synchronized (verrou) {
                        var personne = personnes.stream().filter(p -> p.id() == id).findFirst();
                        if (personne.isPresent()) {
                            envoyer(echange, 200, mapper.writeValueAsString(personne.get()), JSON);
                            return;
                        }
                    }
                }
                // toute autre URL donne la réponse 404 Not Found
                echange.sendResponseHeaders(404, -1);
            }
        }
    }

    // envoi d'un document texte avec son code de statut et son type ; pas de document pour HEAD
    private void envoyer(HttpExchange echange, int code, String texte, String type) throws IOException {
        byte[] octets = texte.getBytes(StandardCharsets.UTF_8);
        echange.getResponseHeaders().set("Content-Type", type);
        if (echange.getRequestMethod().equals("HEAD")) {
            echange.sendResponseHeaders(code, -1);
        } else {
            echange.sendResponseHeaders(code, octets.length);
            echange.getResponseBody().write(octets);
        }
    }

    // redirection temporaire (302) : entête Location, sans document
    private void rediriger(HttpExchange echange, String adresse) throws IOException {
        echange.getResponseHeaders().set("Location", adresse);
        echange.sendResponseHeaders(302, -1);
    }

    // le document envoyé par le client, décodé en UTF-8
    private String lireDocument(HttpExchange echange) throws IOException {
        return new String(echange.getRequestBody().readAllBytes(), StandardCharsets.UTF_8);
    }

    // les paramètres nom1=valeur1&nom2=valeur2 d'une URL ou d'un formulaire, décodés
    private Map<String, String> parametres(String chaine) {
        Map<String, String> resultat = new LinkedHashMap<>();
        if (chaine != null && !chaine.isEmpty()) {
            for (String paire : chaine.split("&")) {
                String[] champs = paire.split("=", 2);
                resultat.put(URLDecoder.decode(champs[0], StandardCharsets.UTF_8),
                        champs.length == 2 ? URLDecoder.decode(champs[1], StandardCharsets.UTF_8) : "");
            }
        }
        return resultat;
    }
}

Commentaires :

ligne 23 : dans un projet Maven, nous écrivons des classes ordinaires, avec leur paquetage ([internet]) et leurs importations, plutôt que des fichiers source compacts ;
lignes 40-44 : les données du serveur : une petite « base » de personnes, le verrou qui la protège et l'objet [JsonMapper] de Jackson qui transforme les objets en JSON et inversement ;
lignes 50-52 : toutes les URL sont confiées à la méthode [traiter] d'une instance de [Internet10]. Par défaut, le serveur du JDK traite toutes les requêtes dans un seul thread : une requête lente bloquerait toutes les autres. La méthode [setExecutor] lui fournit un [ExecutorService] qui exécute chaque requête dans un thread virtuel ;
lignes 58-70 : chaque requête est affichée sur la console avec le port du client et le code de statut de la réponse. Le port du client nous permettra de savoir si deux requêtes ont emprunté la même connexion TCP ;
ligne 74 : la « route » de la requête, formée de sa méthode et du chemin de l'URL ([GET /bonjour], [POST /formulaire]…), sur laquelle se fait le [switch] de la ligne 77 ;
ligne 79 : l'URL [/] rend un petit document HTML ;
ligne 81 : l'URL [/bonjour?nom=xx] rend le texte [Bonjour xx !] ;
ligne 84 : l'URL [/entetes] renvoie au client, sous forme de texte, les entêtes HTTP de sa requête, par ordre alphabétique grâce à une [TreeMap]. Elle va nous permettre de voir ce qu'envoie [HttpClient] ;
lignes 90-92 : une redirection temporaire vers [/bonjour?nom=visiteur] et une redirection qui boucle sur elle-même, comme dans le serveur de la première partie ;
ligne 94 : une réponse 500 (erreur interne du serveur) ;
lignes 96-100 : l'URL [/lent?secondes=n] ne répond qu'au bout de n secondes. Le thread virtuel qui traite la requête est suspendu pendant ce temps, sans immobiliser de thread du système ;
lignes 102-110 : l'URL [/formulaire] reçoit un formulaire envoyé par la méthode [POST] et décrit ce qu'elle a reçu ;
lignes 112-115 : l'URL [/texte] reçoit un texte quelconque par [POST] et le renvoie en majuscules ;
lignes 117-148 : la « base » de personnes, échangée au format JSON. [GET /api/personnes] rend la liste des personnes, [GET /api/personnes/n] la personne n° n (ou une réponse 404), [POST /api/personnes] ajoute la personne envoyée par le client, lui attribue un numéro et répond avec le code 201 (Created) et un entête [Location] donnant l'URL de la nouvelle personne. Plusieurs requêtes pouvant être traitées en même temps par des threads différents, la liste est protégée par un verrou ([synchronized], chapitre 8). [writeValueAsString] transforme un objet en document JSON, [readValue] fait l'inverse ;
ligne 147 : toute autre URL donne la réponse 404.

Le serveur est lancé dans une fenêtre de commandes, depuis le dossier [Internet10], par [mvn compile exec:java], et y reste pendant tous les essais de cette section. Les requêtes qu'il a reçues seront présentées à la fin de la section.

12.7.2.2. Télécharger un document : send et BodyHandlers

L'utilisation de [HttpClient] met en jeu trois types :

[HttpClient] : le client lui-même, créé par [HttpClient.newHttpClient()] ou, pour le configurer, par [HttpClient.newBuilder()...build()] ;
[HttpRequest] : une requête, construite elle aussi par un « constructeur » ([builder]) : [HttpRequest.newBuilder(uri)...build()]. Sans autre précision, c'est une requête [GET] ;
[HttpResponse<T>] : la réponse, rendue par la méthode [send(requete, gestionnaire)] du client. Le second paramètre, un [BodyHandler<T>], indique ce qu'il faut faire du document reçu ; la classe [BodyHandlers] fournit les gestionnaires courants :

Gestionnaire	Le document est rendu sous forme de
BodyHandlers.ofString()	chaîne de caractères ([HttpResponse<String>]), décodée selon le jeu de caractères indiqué par l'entête [Content-Type]
BodyHandlers.ofByteArray()	tableau d'octets (une image, par exemple)
BodyHandlers.ofInputStream(), ofLines()	flux d'octets, ou flux ([Stream<String>]) de lignes, à lire au fur et à mesure de l'arrivée du document (un gros fichier, par exemple)
BodyHandlers.ofFile(Path)	fichier dans lequel le document est enregistré
BodyHandlers.discarding()	rien : le document est ignoré

La méthode [send] est synchrone : elle rend la réponse lorsque ses entêtes et, sauf pour les flux, son document sont arrivés. Elle lance une [IOException] en cas de problème de communication, mais pas pour un code de statut d'erreur : une réponse 404 est une réponse comme une autre. Nous verrons plus loin sa version asynchrone, [sendAsync].

Le programme [Internet11.java] est le suivant :

import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;
import java.net.http.HttpResponse.BodyHandlers;

// premiers pas avec java.net.http.HttpClient : télécharger un document
// le serveur de test [Internet10] doit être lancé sur le port 27210

// l'adresse de base des URL relatives que l'on demandera
final URI BASE = URI.create("http://localhost:27210/");

void main() throws IOException, InterruptedException {
    // un client HTTP, fermé à la sortie du try (HttpClient est AutoCloseable depuis Java 21)
    try (HttpClient client = HttpClient.newHttpClient()) {
        // 1 - un document texte : requête GET, document reçu sous forme de chaîne
        HttpRequest requete = HttpRequest.newBuilder(BASE.resolve("bonjour?nom=Serge")).build();
        HttpResponse<String> reponse = client.send(requete, BodyHandlers.ofString());
        IO.println("Document reçu : " + reponse.body());

        // 2 - les entêtes HTTP envoyés par HttpClient, tels que le serveur les a reçus
        IO.println("--- entêtes envoyés par défaut");
        requete = HttpRequest.newBuilder(BASE.resolve("entetes")).build();
        IO.println(client.send(requete, BodyHandlers.ofString()).body());

        // 3 - une requête HTTP/1.1, avec des entêtes ajoutés
        requete = HttpRequest.newBuilder(BASE.resolve("entetes"))
                .version(HttpClient.Version.HTTP_1_1)
                .header("User-Agent", "client-cours-java/1.0")
                .header("Accept-Language", "fr-FR")
                .build();
        IO.println("--- entêtes d'une requête HTTP/1.1 avec User-Agent et Accept-Language");
        IO.println(client.send(requete, BodyHandlers.ofString()).body());

        // 4 - un document de type HTML, sous forme de tableau d'octets
        requete = HttpRequest.newBuilder(BASE.resolve("/")).build();
        byte[] octets = client.send(requete, BodyHandlers.ofByteArray()).body();
        IO.println("--- la page d'accueil fait " + octets.length + " octets");

        // 5 - un document qui n'existe pas : pas d'exception, c'est au programme de tester le code de statut
        requete = HttpRequest.newBuilder(BASE.resolve("inconnu")).build();
        reponse = client.send(requete, BodyHandlers.ofString());
        IO.println("--- code de statut : " + reponse.statusCode() + ", document : [" + reponse.body() + "]");
    }
}

Résultats (le serveur [Internet10] ayant été lancé dans une autre fenêtre) :

> java Internet11.java
Document reçu : Bonjour Serge !
--- entêtes envoyés par défaut
Connection: Upgrade, HTTP2-Settings
Host: localhost:27210
Http2-settings: AAEAAEAAAAIAAAAAAAMAAAAAAAQBAAAAAAUAAEAAAAYABgAA
Upgrade: h2c
User-agent: Java-http-client/25.0.4.1
--- entêtes d'une requête HTTP/1.1 avec User-Agent et Accept-Language
Accept-language: fr-FR
Host: localhost:27210
User-agent: client-cours-java/1.0
--- la page d'accueil fait 173 octets
--- code de statut : 404, document : []

Commentaires :

ligne 10 : [HttpClient] n'a pas d'adresse de base pour les URL relatives : nous utilisons la méthode [resolve] de la classe [URI], rencontrée dans le client web de la première partie, qui complète une URL relative ([bonjour?nom=Serge]) à partir de l'URI de base pour obtenir [http://localhost:27210/bonjour?nom=Serge]. La barre oblique finale de l'adresse de base est importante : sans elle, le dernier segment du chemin serait remplacé par l'URL relative ;
ligne 14 : création du client. Depuis Java 21, [HttpClient] implémente [AutoCloseable] : sa méthode [close] attend la fin des requêtes en cours puis libère ses ressources (connexions, threads) ;
lignes 16-18 : trois instructions suffisent pour obtenir le document : construire la requête, l'envoyer, lire le document de la réponse ([body]). [HttpClient] a construit la requête HTTP, s'est connecté, a analysé la réponse et a décodé le document ;
lignes 22-23 : lignes 4-8 des résultats, on découvre ce qu'envoie [HttpClient] par défaut : l'entête [Host], obligatoire, et un entête [User-Agent] donnant la version de Java. Les entêtes [Connection: Upgrade, HTTP2-Settings], [Upgrade: h2c] et [HTTP2-Settings] sont plus surprenants : par défaut, [HttpClient] préfère HTTP/2, et propose au serveur de passer à HTTP/2 sur la connexion en clair ([h2c]). Notre serveur, qui ne connaît que HTTP/1.1, a ignoré la proposition et répondu en HTTP/1.1. Avec une URL [https], la version de HTTP est négociée pendant l'établissement de la connexion TLS. On remarque aussi que le serveur du JDK présente les noms d'entêtes reçus avec une seule majuscule ([User-agent]) ;
lignes 26-30 : une requête construite avec plus de précision : la version de HTTP (1.1, ce qui supprime les entêtes de passage à HTTP/2) et deux entêtes propres à cette requête. [HttpClient] n'a pas d'entêtes communs à toutes les requêtes : quand on en a besoin, on écrit une méthode qui construit les requêtes. Les lignes 10-12 des résultats montrent que les entêtes ont bien été reçus par le serveur ;
lignes 35-36 : le document est obtenu sous forme d'octets. Notons l'URL [/] : une URL relative commençant par une barre oblique désigne la racine du site de l'adresse de base ;
lignes 40-42 : un document inexistant. Aucune exception n'est lancée : la réponse a le code de statut 404 ([statusCode]) et un document vide. C'est au programme de tester le code de statut.

12.7.2.3. Requête et réponse : HttpRequest et HttpResponse

Examinons plus en détail la configuration du client et de la requête, et le contenu de la réponse :

Membre	Rôle
HttpClient.newBuilder() .followRedirects(Redirect r) .connectTimeout(Duration d) .version(Version v) .executor(Executor e) .proxy(ProxySelector p) .build()	la configuration du client : suivi des redirections ([Redirect.NEVER] par défaut, [Redirect.NORMAL] pour les suivre, sauf de [https] vers [http], [Redirect.ALWAYS]), délai maximal d'établissement d'une connexion, version de HTTP préférée, threads utilisés pour les opérations asynchrones, proxy…
HttpRequest.newBuilder(URI uri) .GET() .POST(BodyPublisher p) .method(String methode, BodyPublisher p) .header(String nom, String valeur) .timeout(Duration d) .version(Version v) .build()	la requête : méthode et document envoyé (pour [POST] et [PUT]), entêtes, délai maximal d'obtention de la réponse ([HttpTimeoutException] au-delà), version de HTTP
HttpResponse.statusCode(), version()	le code de statut et la version de HTTP de la réponse. Il n'y a pas de méthode pour le message qui suit le code (il n'existe plus en HTTP/2)
HttpResponse.headers()	les entêtes de la réponse, un objet [HttpHeaders] : [firstValue(nom)] rend la première valeur d'un entête (un [Optional<String>]), [map()] l'ensemble des entêtes sous la forme d'un dictionnaire nom → liste de valeurs
HttpResponse.body()	le document, sous la forme choisie par le [BodyHandler]
HttpResponse.uri(), request(), previousResponse()	l'URI de la réponse et la requête correspondante : en cas de redirection, c'est la dernière requête émise ; [previousResponse] donne la réponse précédente (la redirection)

Nous reprenons avec ces classes le client web de la première partie ([Internet08.java], [Internet09.java]), qui était appelé avec une URL et la méthode [GET] ou [HEAD]. Le programme [Internet12.java] est le suivant :

import java.net.http.HttpClient;
import java.net.http.HttpConnectTimeoutException;
import java.net.http.HttpHeaders;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;
import java.net.http.HttpResponse.BodyHandlers;
import java.net.http.HttpTimeoutException;

// client web fondé sur HttpClient : affiche le statut, les entêtes et le document reçus
// appel : java Internet12.java URL GET|HEAD

final String SYNTAXE = "Syntaxe : java Internet12.java URL GET|HEAD";

void main(String[] args) throws InterruptedException {
    if (args.length != 2) {
        IO.println(SYNTAXE);
        return;
    }
    // l'URL doit être une URL absolue http ou https
    URI uri = analyser(args[0]);
    if (uri == null) {
        IO.println("URL [" + args[0] + "] incorrecte : indiquez une URL de la forme "
                + "http://machine[:port]/document");
        return;
    }
    // la méthode HTTP
    String commande = args[1].toUpperCase();
    if (!commande.equals("GET") && !commande.equals("HEAD")) {
        IO.println(SYNTAXE);
        return;
    }

    // au plus 4 requêtes par URL demandée, donc 3 redirections suivies (5 requêtes par défaut)
    // cette propriété est lue lors de la première utilisation de HttpClient
    System.setProperty("jdk.httpclient.redirects.retrylimit", "4");
    // le client HTTP : il suit les redirections, sauf de https vers http ; 5 s au plus pour se connecter
    try (HttpClient client = HttpClient.newBuilder()
            .followRedirects(HttpClient.Redirect.NORMAL)
            .connectTimeout(Duration.ofSeconds(5))
            .build()) {
        // la requête : méthode, URL, entêtes, délai d'attente de la réponse
        HttpRequest requete = HttpRequest.newBuilder(uri)
                .method(commande, HttpRequest.BodyPublishers.noBody())
                .header("User-Agent", "client-cours-java/1.0")
                .timeout(Duration.ofSeconds(10))
                .build();
        // on l'envoie et on attend la réponse
        HttpResponse<String> reponse = client.send(requete, BodyHandlers.ofString());
        // la ligne de statut : URL de la dernière requête, version de HTTP, code
        IO.println("Le serveur " + reponse.uri() + " a répondu : " + reponse.version() + " "
                + reponse.statusCode());
        // les entêtes de la réponse
        IO.println("--- entêtes");
        afficherEntetes(reponse.headers());
        // le document, si le code de statut indique un succès (200-299)
        if (reponse.statusCode() / 100 == 2) {
            IO.println("--- document");
            IO.println(reponse.body());
        }
    } catch (HttpConnectTimeoutException e) {
        IO.println("La connexion n'a pas pu être établie dans le délai imparti");
    } catch (HttpTimeoutException e) {
        IO.println("Le serveur n'a pas répondu dans le délai imparti");
    } catch (ConnectException e) {
        IO.println("Connexion impossible au serveur " + uri.getAuthority());
    } catch (IOException e) {
        IO.println(e.getClass().getSimpleName() + " : " + e.getMessage());
    }
}

// une URL absolue http ou https correcte, ou null
URI analyser(String url) {
    try {
        URI uri = new URI(url);
        return uri.isAbsolute() && uri.getHost() != null
                && (uri.getScheme().equals("http") || uri.getScheme().equals("https")) ? uri : null;
    } catch (URISyntaxException e) {
        return null;
    }
}

// affiche une collection d'entêtes : un nom peut avoir plusieurs valeurs
void afficherEntetes(HttpHeaders entetes) {
    entetes.map().forEach((nom, valeurs) -> IO.println(nom + ": " + String.join(", ", valeurs)));
}

Commentaires :

ligne 20 : comme dans [Internet08.java], on vérifie que l'URL est valide (lignes 72-80). Le schéma [https] est cette fois accepté : [HttpClient] sait faire la négociation TLS ;
ligne 35 : le nombre de redirections suivies n'est pas une propriété du client mais une propriété système de Java, [jdk.httpclient.redirects.retrylimit], qui limite le nombre total de requêtes émises pour une URL demandée (5 par défaut). Elle est lue une fois pour toutes, à la première utilisation de [HttpClient] : on la fixe ici par programme avant de créer le client, mais on pourrait aussi la donner sur la ligne de commande ([java -Djdk.httpclient.redirects.retrylimit=4 ...]) ;
lignes 37-40 : le client suit les redirections (mais pas celles qui feraient passer de [https] à [http], ce qui ferait perdre le chiffrement) et attend au plus 5 secondes l'établissement d'une connexion ;
lignes 42-46 : la requête, avec la méthode demandée (sans document à envoyer : [noBody()]), un entête [User-Agent] et un délai maximal d'obtention de la réponse de 10 secondes ;
ligne 48 : la requête est envoyée ; la réponse est disponible lorsque ses entêtes et son document ont été reçus ;
lignes 50-51 : la ligne de statut. [reponse.uri()] est l'URL de la dernière requête : en cas de redirection, elle diffère de l'URL demandée. [version()] rend une constante de l'énumération [HttpClient.Version] ;
ligne 54 : les entêtes de la réponse, affichés par la méthode [afficherEntetes] (lignes 83-85). Un nom d'entête peut avoir plusieurs valeurs : [map()] associe à chaque nom la liste de ses valeurs ;
lignes 56-59 : le document n'est affiché que si le code de statut indique un succès (famille 2xx) ;
lignes 60-68 : les erreurs. [HttpConnectTimeoutException] (connexion non établie dans le délai) est une sorte de [HttpTimeoutException] (réponse non obtenue dans le délai), elle-même une sorte d'[IOException] : le [catch] de la classe la plus spécialisée doit venir en premier. Une connexion refusée donne une [ConnectException].

Demandons la racine du site :

> java Internet12.java http://localhost:27210/ GET
Le serveur http://localhost:27210/ a répondu : HTTP_1_1 200
--- entêtes
content-length: 173
content-type: text/html; charset=utf-8
date: Sat, 03 Oct 2026 17:42:17 GMT
--- document
<!DOCTYPE html>
<html lang="fr">
<head><meta charset="utf-8"><title>Serveur de test</title></head>
<body><h1>Bienvenue sur le serveur de test HttpClient</h1></body>
</html>

On retrouve les informations que nous avions obtenues en analysant nous-mêmes la réponse avec le client TCP : la ligne de statut, les entêtes [Content-Length], [Content-Type] et [Date] de la réponse, puis le document. [HttpClient] présente les noms d'entêtes en minuscules : c'est la forme imposée par HTTP/2, et [HttpHeaders] fait de toute façon des recherches insensibles à la casse.

Une URL qui fait l'objet d'une redirection :

> java Internet12.java http://localhost:27210/ancienne GET
Le serveur http://localhost:27210/bonjour?nom=visiteur a répondu : HTTP_1_1 200
--- entêtes
content-length: 18
content-type: text/plain; charset=utf-8
date: Sat, 03 Oct 2026 17:42:18 GMT
--- document
Bonjour visiteur !

La redirection a été suivie automatiquement : la réponse obtenue est celle de l'URL [/bonjour?nom=visiteur] (ligne 2). Comparons avec la première partie : le client [Internet09.java] devait lire la ligne de statut, en extraire le code, chercher l'entête [Location], calculer la nouvelle URL et recommencer, dans une boucle limitée à trois redirections. Ici, tout cela est fait par [HttpClient]. Pour traiter soi-même les redirections, il suffit de ne pas appeler [followRedirects] : la réponse 302 est alors rendue telle quelle.

Un document inexistant :

> java Internet12.java http://localhost:27210/inconnu GET
Le serveur http://localhost:27210/inconnu a répondu : HTTP_1_1 404
--- entêtes
content-length: 0
date: Sat, 03 Oct 2026 17:42:18 GMT

Le code 404 est disponible dans la réponse, avec ses entêtes ; le document n'est pas affiché. Il n'y a pas eu d'exception : c'est au programme de décider ce qu'il fait d'une réponse d'erreur.

L'URL [/boucle], qui redirige vers elle-même :

> java Internet12.java http://localhost:27210/boucle HEAD
Le serveur http://localhost:27210/boucle a répondu : HTTP_1_1 302
--- entêtes
date: Sat, 03 Oct 2026 17:42:19 GMT
location: /boucle

Après quatre requêtes, donc trois redirections, [HttpClient] renonce et rend la dernière réponse reçue, une réponse 302.

Une erreur du serveur :

> java Internet12.java http://localhost:27210/erreur HEAD
Le serveur http://localhost:27210/erreur a répondu : HTTP_1_1 500
--- entêtes
date: Sat, 03 Oct 2026 17:42:19 GMT

Un port où aucun serveur n'écoute :

1 2	`> java Internet12.java http://localhost:27299/ GET Connexion impossible au serveur localhost:27299`

La connexion a été refusée ([ConnectException]). Enfin, une URL [https] adressée à notre serveur, qui ne parle que HTTP en clair :

1 2	`> java Internet12.java https://localhost:27210/ GET La connexion n'a pas pu être établie dans le délai imparti`

Le client a envoyé le premier message de la négociation TLS ; notre serveur, qui attend une ligne de requête HTTP, n'y a rien compris et n'a pas répondu. Au bout de 5 secondes, la connexion sécurisée n'étant pas établie, le délai de connexion a expiré. Sur une machine reliée à l'Internet, une URL comme [https://dev.java/] serait servie normalement, en HTTP/2 si le serveur le permet.

Une dernière remarque sur les proxys, ces machines par lesquelles les postes d'un réseau d'entreprise doivent souvent passer pour accéder au Web. Par défaut, [HttpClient] utilise le proxy indiqué par les propriétés système [http.proxyHost], [http.proxyPort], [https.proxyHost] et [https.proxyPort] de la machine virtuelle (et aucun si elles ne sont pas définies). On peut en imposer un autre avec la méthode [proxy] du constructeur du client : [HttpClient.newBuilder().proxy(ProxySelector.of(new InetSocketAddress("proxy.example.org", 3128)))].

12.7.2.4. Envoyer des données au serveur : GET et POST

Un client peut transmettre des informations au serveur de deux façons :

avec la méthode [GET], les informations font partie de l'URL : [/document?param1=valeur1&param2=valeur2] ;
avec la méthode [POST], elles forment le document joint à la requête, après la ligne vide qui termine les entêtes. L'entête [Content-Type] en indique le format. Pour un formulaire HTML, le document a le même format que la partie paramètres d'une URL : [param1=valeur1&param2=valeur2], avec le type [application/x-www-form-urlencoded].

Dans les deux cas, les valeurs doivent être encodées : certains caractères (l'espace, [&], [=], [?], les lettres accentuées…) ne peuvent figurer tels quels dans une URL ou dans un formulaire. On utilise pour cela la méthode statique [URLEncoder.encode(valeur, jeuDeCaractères)], qui produit le format des formulaires ; [URLDecoder.decode], utilisée par nos serveurs de test, fait l'opération inverse.

Le document à envoyer est fourni à la requête par un [BodyPublisher], la classe [BodyPublishers] fournissant les plus courants :

Méthode	Document envoyé
BodyPublishers.ofString(String texte[, Charset jeu])	un texte, encodé en UTF-8 par défaut. Le type du document est indiqué par un entête [Content-Type] ajouté à la requête : [text/plain], [application/json], [application/x-www-form-urlencoded]…
BodyPublishers.ofByteArray(byte[] octets), ofFile(Path chemin), ofInputStream(...)	des octets quelconques, un fichier, un flux
BodyPublishers.noBody()	pas de document

Il n'y a pas, dans le JDK, de classe qui construise un formulaire : on construit soi-même la chaîne [nom=valeur&...]. Le programme [Internet13.java] est le suivant :

import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpRequest.BodyPublishers;
import java.net.http.HttpResponse;
import java.net.http.HttpResponse.BodyHandlers;

import static java.nio.charset.StandardCharsets.UTF_8;

// envoyer des données au serveur : paramètres d'URL (GET), formulaire et texte (POST)
// le serveur de test [Internet10] doit être lancé sur le port 27210

final URI BASE = URI.create("http://localhost:27210/");

void main() throws IOException, InterruptedException {
    try (HttpClient client = HttpClient.newBuilder().version(HttpClient.Version.HTTP_1_1).build()) {
        // 1 - GET : les paramètres font partie de l'URL ; ils doivent y être encodés
        String nom = "Jean & Marie";
        String url = "bonjour?nom=" + URLEncoder.encode(nom, UTF_8);
        IO.println("--- GET " + url);
        HttpRequest requete = HttpRequest.newBuilder(BASE.resolve(url)).build();
        IO.println(client.send(requete, BodyHandlers.ofString()).body());

        // 2 - POST d'un formulaire : les paramètres forment le document envoyé au serveur
        List<Map.Entry<String, String>> champs = List.of(
                Map.entry("nom", "Jean & Marie"),
                Map.entry("age", "42"),
                Map.entry("ville", "Angers"));
        // le document : nom=valeur&nom=valeur..., noms et valeurs encodés
        String formulaire = champs.stream()
                .map(champ -> URLEncoder.encode(champ.getKey(), UTF_8) + "="
                        + URLEncoder.encode(champ.getValue(), UTF_8))
                .collect(Collectors.joining("&"));
        IO.println("--- POST formulaire, document envoyé : " + formulaire);
        requete = HttpRequest.newBuilder(BASE.resolve("formulaire"))
                .header("Content-Type", "application/x-www-form-urlencoded")
                .POST(BodyPublishers.ofString(formulaire))
                .build();
        HttpResponse<String> reponse = client.send(requete, BodyHandlers.ofString());
        IO.println(reponse.statusCode() + " : " + reponse.body());

        // 3 - POST d'un texte quelconque, avec son type et son encodage
        IO.println("--- POST texte");
        requete = HttpRequest.newBuilder(BASE.resolve("texte"))
                .header("Content-Type", "text/plain; charset=utf-8")
                .POST(BodyPublishers.ofString("été comme hiver", UTF_8))
                .build();
        reponse = client.send(requete, BodyHandlers.ofString());
        IO.println(reponse.statusCode() + " : " + reponse.body());
    }
}

Résultats :

> java Internet13.java
--- GET bonjour?nom=Jean+%26+Marie
Bonjour Jean & Marie !
--- POST formulaire, document envoyé : nom=Jean+%26+Marie&age=42&ville=Angers
200 : Content-Type reçu : application/x-www-form-urlencoded
Champs reçus : nom=[Jean & Marie], age=[42], ville=[Angers]
--- POST texte
200 : Content-Type reçu : text/plain; charset=utf-8
Texte reçu en majuscules : ÉTÉ COMME HIVER

Commentaires :

lignes 17-18 : la valeur [Jean & Marie] est placée dans l'URL. Sans encodage, le caractère [&] serait pris pour le séparateur de deux paramètres et le serveur recevrait le paramètre [nom] avec la valeur [Jean]. Ligne 2 des résultats, on voit que l'espace est devenu [+] et le caractère [&] [%26] : c'est le code hexadécimal du caractère, précédé de [%]. [URLEncoder] produit le format des formulaires, où l'espace est codé par [+] ; dans le chemin d'une URL, il faudrait [%20], mais dans la partie paramètres, les serveurs acceptent les deux ;
lignes 24-27 : les champs du formulaire, sous la forme d'une liste de paires (nom, valeur) créées par [Map.entry]. Une liste conserve l'ordre des champs, ce que ne ferait pas un dictionnaire [Map.of] ;
lignes 29-32 : le document est construit par l'API Stream : chaque paire devient [nom=valeur], noms et valeurs encodés, et les paires sont jointes par [&]. Ligne 4 des résultats, on retrouve le format [nom=valeur&nom=valeur] ;
lignes 34-37 : le formulaire est envoyé par la méthode [POST] à l'URL [/formulaire], avec son type. Le serveur indique (lignes 5-6 des résultats) qu'il a reçu un document de type [application/x-www-form-urlencoded] et qu'il en a extrait, décodés, les trois champs ;
lignes 43-46 : un texte, codé en UTF-8, de type [text/plain]. Le serveur le renvoie en majuscules (ligne 9 des résultats) : les caractères accentués ont fait correctement l'aller et retour.

Rappelons la différence entre [GET] et [POST] : un navigateur affiche dans sa barre d'adresse les paramètres d'une requête [GET], pas ceux d'une requête [POST] ; de plus, une requête [GET] ne doit servir qu'à consulter des informations, une requête [POST] servant à en envoyer ou à modifier l'état du serveur.

12.7.2.5. Échanger des objets au format JSON

Les applications échangent aujourd'hui la plupart de leurs données au format JSON, présenté au chapitre 5. Le JDK n'a pas de bibliothèque JSON : [HttpClient] transporte des documents JSON comme des chaînes de caractères, et l'on utilise Jackson pour la conversion entre objets et JSON :

côté envoi, [mapper.writeValueAsString(objet)] produit le document JSON, que [BodyPublishers.ofString] envoie avec l'entête [Content-Type: application/json] ;
côté réception, [mapper.readValue(json, Type.class)] transforme le document JSON reçu en objet. Pour un type générique comme [List<Personne>], on utilise une [TypeReference], qui conserve le paramètre de type que Java efface à la compilation.

Le programme [Internet14] est un projet Maven, dont le [pom.xml] ne diffère de celui du serveur [Internet10] que par le nom du projet ([internet14]) et la classe principale ([internet.Internet14]). Il contient le même enregistrement [Personne] que le serveur. La classe [Internet14] est la suivante :

package internet;

import java.io.IOException;
import java.net.URI;
import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;
import java.net.http.HttpResponse.BodyHandlers;
import java.util.List;
import tools.jackson.core.type.TypeReference;
import tools.jackson.databind.json.JsonMapper;

// échanger des objets au format JSON avec un serveur web
// le serveur de test [Internet10] doit être lancé sur le port 27210
public class Internet14 {

    private static final URI BASE = URI.create("http://localhost:27210/");
    // le convertisseur objets <-> JSON de Jackson
    private static final JsonMapper MAPPER = JsonMapper.builder().build();

    public static void main(String[] args) throws IOException, InterruptedException {
        try (HttpClient client = HttpClient.newBuilder().version(HttpClient.Version.HTTP_1_1).build()) {
            // 1 - la liste des personnes : le document JSON est transformé en liste d'objets
            List<Personne> personnes = lireJson(client, "api/personnes", new TypeReference<List<Personne>>() {
            });
            IO.println("--- liste des personnes");
            personnes.forEach(IO::println);

            // 2 - une personne
            Personne durand = lireJson(client, "api/personnes/2", new TypeReference<Personne>() {
            });
            IO.println("--- personne n° 2 : " + durand);

            // 3 - ajout d'une personne : l'objet est envoyé au format JSON
            var martin = new Personne(0, "Martin", 25);
            HttpRequest requete = HttpRequest.newBuilder(BASE.resolve("api/personnes"))
                    .header("Content-Type", "application/json")
                    .POST(HttpRequest.BodyPublishers.ofString(MAPPER.writeValueAsString(martin)))
                    .build();
            HttpResponse<String> reponse = client.send(requete, BodyHandlers.ofString());
            IO.println("--- ajout de " + martin);
            IO.println("Statut : " + reponse.statusCode() + ", Location : "
                    + reponse.headers().firstValue("Location").orElse("?"));
            // le document JSON reçu, brut puis sous forme d'objet
            IO.println("JSON reçu : " + reponse.body());
            Personne creee = MAPPER.readValue(reponse.body(), Personne.class);
            IO.println("Personne créée : " + creee);

            // 4 - une personne qui n'existe pas
            try {
                lireJson(client, "api/personnes/99", new TypeReference<Personne>() {
                });
            } catch (IOException e) {
                IO.println("--- personne n° 99 : " + e.getClass().getSimpleName() + " : " + e.getMessage());
            }
        }
    }

    // GET [chemin] et transformation du document JSON reçu en objet de type T
    // lance une IOException si le code de statut n'indique pas un succès
    private static <T> T lireJson(HttpClient client, String chemin, TypeReference<T> type)
            throws IOException, InterruptedException {
        HttpRequest requete = HttpRequest.newBuilder(BASE.resolve(chemin))
                .header("Accept", "application/json")
                .build();
        HttpResponse<String> reponse = client.send(requete, BodyHandlers.ofString());
        if (reponse.statusCode() / 100 != 2) {
            throw new IOException("GET " + reponse.uri() + " : code de statut " + reponse.statusCode());
        }
        return MAPPER.readValue(reponse.body(), type);
    }
}

Résultats (depuis le dossier [Internet14]) :

> mvn compile exec:java
--- liste des personnes
Personne[id=1, nom=Dupont, age=42]
Personne[id=2, nom=Durand, age=35]
--- personne n° 2 : Personne[id=2, nom=Durand, age=35]
--- ajout de Personne[id=0, nom=Martin, age=25]
Statut : 201, Location : /api/personnes/3
JSON reçu : {"id":3,"nom":"Martin","age":25}
Personne créée : Personne[id=3, nom=Martin, age=25]
--- personne n° 99 : IOException : GET http://localhost:27210/api/personnes/99 : code de statut 404

Commentaires :

ligne 19 : le [JsonMapper] de Jackson, créé une fois pour toutes : il peut être utilisé par plusieurs threads à la fois ;
lignes 61-71 : la méthode générique [lireJson] fait l'équivalent d'une méthode « demander une URL et transformer le document JSON reçu en objet » : elle envoie la requête [GET] avec l'entête [Accept: application/json], vérifie le code de statut (ligne 67) et transforme le document en objet du type demandé (ligne 70) ;
lignes 24-25 : la liste des personnes. Le document JSON [[{"id":1,"nom":"Dupont","age":42},...]] envoyé par le serveur est directement transformé en liste d'objets [Personne]. L'expression [new TypeReference<List<Personne>>() {}] crée une instance d'une classe anonyme dérivée de [TypeReference] : c'est l'astuce qui permet à Jackson de connaître, à l'exécution, le type [List<Personne>] ;
ligne 27 : chaque personne est affichée par la méthode [toString] générée pour l'enregistrement ;
lignes 30-31 : une seule personne ;
lignes 35-40 : l'objet [martin] est transformé en JSON et envoyé au serveur par [POST]. Le serveur répond avec le code 201 (Created) et l'entête [Location], qui donne l'URL de la nouvelle ressource (ligne 7 des résultats) ;
lignes 45-46 : le document JSON reçu, brut puis transformé en objet. Les noms des propriétés sont ceux des composants de l'enregistrement ([id], [nom], [age]), en « camelCase », la convention du Web ;
lignes 50-55 : une personne inexistante : [lireJson] lance une [IOException] pour la réponse 404.

Nous retrouverons ces techniques au chapitre suivant, où le serveur de calcul de l'impôt deviendra un service web JSON.

12.7.2.6. Délai d'attente, annulation et réutilisation du client

Le programme [Internet15.java] illustre quatre points importants pour l'utilisation de [HttpClient] dans une vraie application : la réutilisation du client, les délais d'attente, l'annulation d'une requête et les requêtes asynchrones. La méthode [sendAsync] de [HttpClient] est la version asynchrone de [send] : elle envoie la requête et rend immédiatement un [CompletableFuture<HttpResponse<T>>] (chapitre 9), qui sera complété lorsque la réponse sera arrivée. Le programme est le suivant :

import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;
import java.net.http.HttpResponse.BodyHandlers;
import java.net.http.HttpTimeoutException;

// délai d'attente, annulation et réutilisation d'un HttpClient ; requêtes asynchrones (sendAsync)
// le serveur de test [Internet10] doit être lancé sur le port 27210

final URI BASE = URI.create("http://localhost:27210/");

void main() throws IOException, InterruptedException {
    // 1 - une seule instance de HttpClient pour toute l'application
    try (HttpClient client = HttpClient.newBuilder().version(HttpClient.Version.HTTP_1_1).build()) {

        // 2 - des requêtes successives : la même connexion TCP est réutilisée
        IO.println("--- trois requêtes successives");
        for (int i = 1; i <= 3; i++) {
            IO.println(client.send(requete("bonjour?nom=essai" + i), BodyHandlers.ofString()).body());
        }

        // 3 - une réponse obtenue dans le délai de 2 s, puis une réponse trop lente
        for (int secondes : List.of(1, 3)) {
            IO.println("--- réponse en " + secondes + " s attendue");
            try {
                IO.println(client.send(requete("lent?secondes=" + secondes), BodyHandlers.ofString()).body());
            } catch (HttpTimeoutException e) {
                IO.println(e.getClass().getSimpleName() + " : " + e.getMessage());
            }
        }

        // 4 - une requête asynchrone annulée par le programme au bout d'une demi-seconde
        IO.println("--- annulation au bout de 0,5 s");
        CompletableFuture<HttpResponse<String>> future =
                client.sendAsync(requete("lent?secondes=1"), BodyHandlers.ofString());
        CompletableFuture.delayedExecutor(500, TimeUnit.MILLISECONDS).execute(() -> future.cancel(true));
        try {
            IO.println(future.join().body());
        } catch (CancellationException e) {
            IO.println("Requête annulée (" + e.getClass().getSimpleName() + ")");
        }

        // 5 - quatre requêtes asynchrones simultanées avec le même client
        IO.println("--- quatre requêtes simultanées d'une seconde chacune");
        long debut = System.nanoTime();
        List<CompletableFuture<String>> reponses = IntStream.rangeClosed(1, 4)
                .mapToObj(_ -> client.sendAsync(requete("lent?secondes=1"), BodyHandlers.ofString())
                        .thenApply(HttpResponse::body))
                .toList();
        // on attend la fin des quatre requêtes
        CompletableFuture.allOf(reponses.toArray(CompletableFuture[]::new)).join();
        reponses.forEach(reponse -> IO.println(reponse.join()));
        IO.println("Durée totale : %.1f s".formatted((System.nanoTime() - debut) / 1e9));
    }
}

// une requête GET vers une URL relative à BASE : 2 secondes au plus pour obtenir la réponse
HttpRequest requete(String url) {
    return HttpRequest.newBuilder(BASE.resolve(url)).timeout(Duration.ofSeconds(2)).build();
}

Résultats :

> java Internet15.java
--- trois requêtes successives
Bonjour essai1 !
Bonjour essai2 !
Bonjour essai3 !
--- réponse en 1 s attendue
Réponse obtenue après 1 s
--- réponse en 3 s attendue
HttpTimeoutException : request timed out
--- annulation au bout de 0,5 s
Requête annulée (CancellationException)
--- quatre requêtes simultanées d'une seconde chacune
Réponse obtenue après 1 s
Réponse obtenue après 1 s
Réponse obtenue après 1 s
Réponse obtenue après 1 s
Durée totale : 1,0 s

Commentaires :

ligne 14 : une seule instance de [HttpClient] est utilisée par tout le programme. C'est la règle : un objet [HttpClient] gère un ensemble (« pool ») de connexions et les réutilise d'une requête à l'autre ; il est prévu pour durer et peut être utilisé par plusieurs threads simultanément. Créer un [HttpClient] pour chaque requête est une erreur classique : chaque instance ouvre ses propres connexions, que le système garde ensuite quelque temps en réserve après leur fermeture (état TIME_WAIT de TCP) ; un programme qui fait beaucoup de requêtes finit par épuiser les ports disponibles. Nous avons créé un client dans chacun des programmes précédents parce qu'ils ne faisaient que quelques requêtes avant de se terminer ;
lignes 58-60 : chaque requête doit obtenir sa réponse en 2 secondes au plus ;
lignes 18-20 : trois requêtes successives. Nous verrons dans le journal du serveur qu'elles ont emprunté la même connexion TCP ;
lignes 23-30 : une réponse qui arrive en 1 seconde, puis une réponse qui en demanderait 3 : au bout de 2 secondes, la requête est abandonnée et une [HttpTimeoutException] est lancée (ligne 9 des résultats) ;
lignes 34-41 : une annulation décidée par le programme. La requête est lancée de façon asynchrone par [sendAsync], qui rend aussitôt un [CompletableFuture]. On demande à un exécuteur différé ([CompletableFuture.delayedExecutor]) d'appeler sa méthode [cancel] au bout d'une demi-seconde ; dans une application interactive, ce serait l'effet d'un bouton [Annuler]. Depuis Java 16, l'annulation d'un [CompletableFuture] rendu par [sendAsync] interrompt réellement l'échange avec le serveur. [join] attend le résultat ; pour une requête annulée, il lance une [CancellationException] ;
lignes 46-49 : quatre requêtes lancées simultanément sur le même client : chaque [sendAsync] rend immédiatement son [CompletableFuture], transformé par [thenApply] en [CompletableFuture<String>] qui donnera le document. Le motif anonyme [_] (Java 22) remplace le paramètre de la lambda, dont on n'a pas besoin ;
ligne 51 : [CompletableFuture.allOf] (chapitre 9) rend un [CompletableFuture] complété lorsque les quatre le sont ; on l'attend par [join]. Chacune des requêtes demande une seconde au serveur ; l'ensemble a pris une seconde (ligne 17 des résultats) : les requêtes ont été traitées en parallèle, par le client comme par le serveur.

Avec les threads virtuels, on peut aussi obtenir le même parallélisme sans [sendAsync] : il suffit d'exécuter quatre appels à la méthode synchrone [send] dans quatre threads virtuels. Les deux styles sont légitimes ; [sendAsync] est commode lorsque les réponses doivent être enchaînées à d'autres traitements asynchrones.

Le journal du serveur [Internet10] montre toutes les requêtes reçues depuis le début de cette section :

> mvn compile exec:java
Serveur web lancé sur http://localhost:27210
GET /bonjour?nom=Serge HTTP/1.1 (port client 47338) -> 200
GET /entetes HTTP/1.1 (port client 47338) -> 200
GET /entetes HTTP/1.1 (port client 47338) -> 200
GET / HTTP/1.1 (port client 47338) -> 200
GET /inconnu HTTP/1.1 (port client 47338) -> 404
GET / HTTP/1.1 (port client 47352) -> 200
GET /ancienne HTTP/1.1 (port client 41552) -> 302
GET /bonjour?nom=visiteur HTTP/1.1 (port client 41552) -> 200
GET /inconnu HTTP/1.1 (port client 41560) -> 404
HEAD /boucle HTTP/1.1 (port client 41576) -> 302
HEAD /boucle HTTP/1.1 (port client 41592) -> 302
HEAD /boucle HTTP/1.1 (port client 41596) -> 302
HEAD /boucle HTTP/1.1 (port client 41610) -> 302
HEAD /erreur HTTP/1.1 (port client 41622) -> 500
GET /bonjour?nom=Jean+%26+Marie HTTP/1.1 (port client 41634) -> 200
POST /formulaire HTTP/1.1 (port client 41634) -> 200
POST /texte HTTP/1.1 (port client 41634) -> 200
GET /api/personnes HTTP/1.1 (port client 41638) -> 200
GET /api/personnes/2 HTTP/1.1 (port client 41638) -> 200
POST /api/personnes HTTP/1.1 (port client 41638) -> 201
GET /api/personnes/99 HTTP/1.1 (port client 41638) -> 404
GET /bonjour?nom=essai1 HTTP/1.1 (port client 41654) -> 200
GET /bonjour?nom=essai2 HTTP/1.1 (port client 41654) -> 200
GET /bonjour?nom=essai3 HTTP/1.1 (port client 41654) -> 200
GET /lent?secondes=1 HTTP/1.1 (port client 41654) -> 200
GET /lent?secondes=3 HTTP/1.1 (port client 41654) -> 200
GET /lent?secondes=1 HTTP/1.1 (port client 40736) -> 200
GET /lent?secondes=1 HTTP/1.1 (port client 40744) -> 200
GET /lent?secondes=1 HTTP/1.1 (port client 40758) -> 200
GET /lent?secondes=1 HTTP/1.1 (port client 40748) -> 200
GET /lent?secondes=1 HTTP/1.1 (port client 40760) -> 200

lignes 3-7 : les cinq requêtes de [Internet11.java] sont arrivées par la même connexion (même port client) : le client l'a gardée ouverte entre deux requêtes ;
lignes 9-10 : la requête redirigée de [Internet12.java] et la requête vers la nouvelle adresse, faite automatiquement sur la même connexion ;
lignes 12-15 : la requête initiale vers [/boucle] et les trois redirections suivies avant abandon ;
lignes 17-19 : les requêtes de [Internet13.java], sur une même connexion ;
lignes 20-23 : celles de [Internet14] ;
lignes 24-28 : les requêtes successives de [Internet15.java] ont toutes utilisé la même connexion. La requête trop lente (ligne 28) a été abandonnée par le client au bout de 2 secondes : [HttpClient] a alors fermé la connexion. Le serveur ne s'en est pas aperçu : au bout de 3 secondes, il a écrit sa réponse dans une connexion que le client avait déjà fermée, et le système ne signale pas d'erreur pour une telle écriture. C'est pourquoi le journal indique le code 200 ;
ligne 29 : la requête annulée par le programme a dû ouvrir une nouvelle connexion, la précédente ayant été fermée. Là encore, le serveur a répondu sans savoir que la réponse ne serait pas lue ;
les quatre dernières lignes : les quatre requêtes simultanées ont utilisé quatre connexions différentes, ouvertes pour l'occasion. En HTTP/1.1, une connexion ne transporte qu'une requête à la fois ; HTTP/2 permettrait de les faire passer toutes par une seule connexion.

Un programme qui reste longtemps en service (un serveur, un service système) doit tenir compte d'un dernier point : un [HttpClient] garde ses connexions inactives pendant un certain temps (30 secondes par défaut, réglable par la propriété système [jdk.httpclient.keepalive.timeout]) avant de les fermer. Dans les applications Spring, on peut aussi utiliser le client HTTP du framework, [RestClient] (construit sur [HttpClient] ou une autre bibliothèque), qui ajoute la conversion automatique des objets en JSON ; les clients du chapitre suivant, eux, utiliseront simplement [HttpClient] et Jackson, comme [Internet14].

12.7.3. Application : un client proxy d'un service web de traduction

Nous montrons maintenant comment [HttpClient] permet d'exploiter les ressources du Web, même lorsque celles-ci n'ont pas été prévues pour être utilisées par un programme.

12.7.3.1. L'application

Dans les années 2000, il existait sur le Web des sites de traduction gratuits. L'utilisateur y tapait un texte, choisissait un sens de traduction (« Français vers Anglais »…) dans une liste déroulante, cliquait sur un bouton et obtenait une page HTML contenant la traduction. On peut écrire une classe [ServiceTraduction] qui fait la même chose par programme : elle construit l'URL de la requête, interroge le site, et retrouve la traduction dans la page HTML reçue au moyen d'une expression régulière. Une interface graphique ou un autre programme peut alors s'appuyer sur cette classe ; on parle de client « proxy » (mandataire) : la classe [ServiceTraduction] se substitue au site et le cache à son utilisateur.

Notre machine de test n'ayant pas accès à l'Internet, nous remplaçons le site par un petit site local qui imite ceux de l'époque : il a le même formulaire (une zone de texte, une liste déroulante des sens de traduction écrite à l'ancienne) et rend la traduction au même endroit de sa page. Ses « traductions » sont faites mot à mot avec de petits dictionnaires : c'est la technique du client qui nous intéresse, pas la qualité de la traduction. Le client est utilisé par un programme de test console. L'architecture est la suivante :

12.7.3.2. Le site de traduction

Le programme [Internet16.java] est le suivant :

import com.sun.net.httpserver.HttpExchange;
import com.sun.net.httpserver.HttpServer;

import static java.nio.charset.StandardCharsets.UTF_8;

// un petit site web de « traduction » mot à mot, qui imite un site de traduction des années 2000
// appel : java Internet16.java [port]   (port 27220 par défaut) ; arrêt par Ctrl-C

// un sens de traduction : son libellé et son dictionnaire
record Traducteur(String libelle, Map<String, String> mots) {
}

// les sens de traduction : code -> traducteur (LinkedHashMap : l'ordre d'insertion est conservé)
final Map<String, Traducteur> sensTraduction = new LinkedHashMap<>();
// un mot, suivi éventuellement d'une apostrophe
final Pattern MOT = Pattern.compile("\\p{L}+'?");

void main(String[] args) throws IOException {
    int port = args.length == 1 ? Integer.parseInt(args[0]) : 27220;
    sensTraduction.put("fe", new Traducteur("Fran&ccedil;ais vers Anglais", Map.of(
            "ce", "this", "chien", "dog", "est", "is", "perdu", "lost", "malade", "sick",
            "l'", "the ", "été", "summer", "sera", "will be", "chaud", "hot")));
    sensTraduction.put("ef", new Traducteur("Anglais vers Fran&ccedil;ais", Map.of(
            "my", "mon", "tailor", "tailleur", "is", "est", "rich", "riche",
            "this", "ce", "dog", "chien", "lost", "perdu")));
    sensTraduction.put("fs", new Traducteur("Fran&ccedil;ais vers Espagnol", Map.of(
            "ce", "este", "chien", "perro", "est", "está", "perdu", "perdido",
            "l'", "el ", "été", "verano", "sera", "será", "chaud", "caliente")));

    HttpServer serveur = HttpServer.create(new InetSocketAddress(InetAddress.getLoopbackAddress(), port), 0);
    serveur.createContext("/traduction", this::traduire);
    serveur.start();
    IO.println("Service de traduction lancé sur http://localhost:" + port + "/traduction");
}

// la page de traduction : le formulaire, suivi de la traduction si un texte a été fourni
void traduire(HttpExchange echange) throws IOException {
    try (echange) {
        Map<String, String> parametres = parametres(echange.getRequestURI().getRawQuery());
        String sens = parametres.get("sens");
        String texte = parametres.getOrDefault("texte", "");
        var page = new StringBuilder("""
                <!DOCTYPE html>
                <html lang="fr">
                <head><meta charset="utf-8"><title>Traducteur du cours Java</title></head>
                <body>
                <h1>Traduction de textes</h1>
                <form action="/traduction" method="get">
                <textarea name="texte" rows="4" cols="60"></textarea>
                <select name="sens">
                """);
        // la liste des sens de traduction, écrite à l'ancienne : balises <option> non fermées
        sensTraduction.forEach((code, traducteur) -> page.append("    <option value='").append(code)
                .append("'>").append(traducteur.libelle()).append('\n'));
        page.append("""
                </select>
                <input type="submit" value="Traduire">
                </form>
                """);
        // la traduction, s'il y a un texte à traduire
        if (!texte.isBlank()) {
            Traducteur traducteur = sens == null ? null : sensTraduction.get(sens);
            if (traducteur != null) {
                // traduction mot à mot ; un mot inconnu est laissé tel quel
                String traduction = MOT.matcher(texte.strip().toLowerCase())
                        .replaceAll(mot -> Matcher.quoteReplacement(
                                traducteur.mots().getOrDefault(mot.group(), mot.group())));
                page.append("<strong>Texte traduit : </strong><div class=\"txtTrad\">")
                        .append(encoderHtml(traduction)).append("</div>\n");
            } else {
                page.append("<p>Sens de traduction inconnu</p>\n");
            }
        }
        page.append("</body>\n</html>\n");
        byte[] octets = page.toString().getBytes(UTF_8);
        echange.getResponseHeaders().set("Content-Type", "text/html; charset=utf-8");
        echange.sendResponseHeaders(200, octets.length);
        echange.getResponseBody().write(octets);
        // suivi console des requêtes
        IO.println("%s %s -> %d".formatted(echange.getRequestMethod(), echange.getRequestURI(),
                echange.getResponseCode()));
    }
}

// encodage HTML : les caractères spéciaux et les caractères non ASCII deviennent des entités &#nnn;
String encoderHtml(String texte) {
    var resultat = new StringBuilder();
    texte.codePoints().forEach(c -> {
        if (c > 127 || c == '<' || c == '>' || c == '&' || c == '"' || c == '\'') {
            resultat.append("&#").append(c).append(';');
        } else {
            resultat.appendCodePoint(c);
        }
    });
    return resultat.toString();
}

// les paramètres nom1=valeur1&nom2=valeur2 de l'URL, décodés
Map<String, String> parametres(String requete) {
    Map<String, String> resultat = new HashMap<>();
    if (requete != null) {
        for (String paire : requete.split("&")) {
            String[] champs = paire.split("=", 2);
            resultat.put(champs[0], champs.length == 2 ? URLDecoder.decode(champs[1], UTF_8) : "");
        }
    }
    return resultat;
}

Commentaires :

lignes 10-11 : un sens de traduction est un enregistrement formé d'un libellé et d'un dictionnaire ;
lignes 20-28 : les trois sens de traduction proposés, avec leur code ([fe] pour français → anglais, [ef] pour anglais → français, [fs] pour français → espagnol), leur libellé et leur dictionnaire. Les libellés contiennent une entité HTML ([ç] pour [ç]), comme sur les sites de l'époque. [Map.of] accepte au plus dix paires (nom, valeur) ; au-delà, on utilise [Map.ofEntries] ;
ligne 31 : l'unique page du site, [/traduction], reçoit éventuellement deux paramètres : le sens de traduction [sens] et le texte [texte] (lignes 39-41) ;
lignes 53-54 : la liste déroulante. Comme sur les sites de l'époque, les balises [<option>] ne sont pas fermées : le HTML des sites réels n'est pas toujours très propre, et notre client devra s'en accommoder ;
lignes 65-67 : la traduction mot à mot. L'expression régulière [\p{L}+'?] (ligne 16) désigne un mot, c'est-à-dire une suite de lettres ([\p{L}]), suivie éventuellement d'une apostrophe ([l'], [d']). Nous n'avons pas utilisé [\w] : en Java, [\w] ne désigne par défaut que les lettres non accentuées, les chiffres et le caractère [_], et [été] n'aurait pas été reconnu comme un mot. La méthode [replaceAll] de [Matcher] (Java 9) remplace chaque mot par le résultat d'une fonction : sa traduction, ou le mot lui-même s'il est inconnu. [Matcher.quoteReplacement] protège les caractères [$] et [\], qui ont un sens particulier dans un texte de remplacement ;
lignes 68-69 : la traduction est placée dans une balise [<div class="txtTrad">], comme sur les sites de l'époque. Elle est encodée par la méthode [encoderHtml] (lignes 86-96) : les caractères qui ont un sens en HTML ([<], [&]…) et les caractères non ASCII sont remplacés par des entités numériques [&#nnn;]. Le JDK n'a pas de méthode d'encodage HTML : les applications web utilisent celles de leur framework ;
ligne 71 : un sens de traduction inconnu donne une page sans traduction.

Voici la page obtenue avec [curl] pour la traduction de [l'été sera chaud] en espagnol ; on remarquera l'encodage du texte dans l'URL :

> curl -s "http://localhost:27220/traduction?sens=fs&texte=l%27%C3%A9t%C3%A9%20sera%20chaud"
<!DOCTYPE html>
<html lang="fr">
<head><meta charset="utf-8"><title>Traducteur du cours Java</title></head>
<body>
<h1>Traduction de textes</h1>
<form action="/traduction" method="get">
<textarea name="texte" rows="4" cols="60"></textarea>
<select name="sens">
    <option value='fe'>Fran&ccedil;ais vers Anglais
    <option value='ef'>Anglais vers Fran&ccedil;ais
    <option value='fs'>Fran&ccedil;ais vers Espagnol
</select>
<input type="submit" value="Traduire">
</form>
<strong>Texte traduit : </strong><div class="txtTrad">el verano ser&#225; caliente</div>
</body>
</html>

Pour écrire le client, il nous faut :

savoir ce qu'attend le site : une requête [GET /traduction?sens=code&texte=texte encodé]. Sur un site réel, on le découvre en regardant l'URL affichée par le navigateur après une traduction, ou l'attribut [action] du formulaire ;
savoir où se trouvent, dans les pages reçues, les informations qui nous intéressent : les sens de traduction sont dans les balises [<option value='code'>libellé] de la liste déroulante (lignes 10-12 de la page ci-dessus), et la traduction dans la balise [<div class="txtTrad">] (ligne 16). On le découvre en affichant le code source de la page dans le navigateur.

Deux expressions régulières (chapitre 5) permettent d'extraire ces informations :

[<option[^>]*value='(\w+)'>([^<\r\n]+)] : une balise [<option], suivie de caractères autres que [>], de [value='], du code (premier groupe), de [>], puis du libellé, c'est-à-dire des caractères qui suivent jusqu'au prochain [<] ou à la fin de la ligne (second groupe) ;
[<div class="txtTrad">(.*?)</div>] : la traduction est le texte (premier groupe) compris entre la balise ouvrante et la première balise [</div>] qui suit. Le quantificateur [*?] est « paresseux » : il prend le moins de caractères possible.

12.7.3.3. Le client ServiceTraduction

Pour rester bref, nous réunissons dans un seul fichier source compact l'interface [IServiceTraduction], son implémentation [ServiceTraduction], l'exception [TraductionException] et le programme de test ; dans une vraie application, l'interface et son implémentation formeraient une bibliothèque à part. Le programme [Internet17.java] est le suivant :

import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;
import java.net.http.HttpResponse.BodyHandlers;

import static java.nio.charset.StandardCharsets.UTF_8;

// client « proxy » d'un service web de traduction : la classe ServiceTraduction
// cache au programme le dialogue HTTP et l'analyse des pages HTML du site de traduction
// appel : java Internet17.java [urlDuSite]   (par défaut http://localhost:27220/)

// un essai de traduction
record Essai(String texte, String sens) {
}

void main(String[] args) {
    URI urlSite = URI.create(args.length == 1 ? args[0] : "http://localhost:27220/");
    try (HttpClient client = HttpClient.newBuilder().connectTimeout(Duration.ofSeconds(10)).build()) {
        // création du service de traduction : il interroge le site pour connaître les langues traduites
        IServiceTraduction service = ServiceTraduction.creer(client, urlSite);
        IO.println("Sens de traduction proposés par le site :");
        service.languesTraduites().forEach((code, libelle) -> IO.println("  " + code + " : " + libelle));
        // quelques traductions
        List<Essai> essais = List.of(
                new Essai("ce chien est perdu", "fe"),
                new Essai("l'été sera chaud", "fs"),
                new Essai("my tailor is rich", "ef"),
                new Essai("xx", "ef"),
                new Essai("", "fe"),
                new Essai("bonjour", "fx"));
        for (Essai essai : essais) {
            try {
                String traduction = service.traduire(essai.texte(), essai.sens());
                IO.println("Traduction [%s] de [%s] : [%s]".formatted(
                        service.languesTraduites().get(essai.sens()), essai.texte(), traduction));
            } catch (TraductionException e) {
                IO.println("L'erreur suivante de code " + e.getCode() + " s'est produite : "
                        + e.getMessage());
            }
        }
    } catch (TraductionException e) {
        IO.println("L'erreur suivante de code " + e.getCode() + " s'est produite : " + e.getMessage());
        // la cause éventuelle : toString donne sa classe, suivie de son message s'il y en a un
        if (e.getCause() != null) {
            IO.println("Cause : " + e.getCause());
        }
    }
}

// --------------------------------------------------------------------
// l'interface présentée au programme
interface IServiceTraduction {

    // les sens de traduction : code -> libellé, par exemple fe -> Français vers Anglais
    Map<String, String> languesTraduites();

    // traduction d'un texte dans le sens indiqué par son code
    String traduire(String texte, String sens);
}

// l'exception propre au service de traduction (non contrôlée), avec un code d'erreur
// static : dans un fichier source compact, une classe sans static serait une classe interne
static class TraductionException extends RuntimeException {

    @Serial
    private static final long serialVersionUID = 1L;

    private final int code;

    TraductionException(String message, int code) {
        this(message, null, code);
    }

    TraductionException(String message, Throwable cause, int code) {
        super(message, cause);
        this.code = code;
    }

    int getCode() {
        return code;
    }
}

// l'implémentation : un client HTTP du site de traduction
static class ServiceTraduction implements IServiceTraduction {

    // les options <option value='fe'>Fran&ccedil;ais vers Anglais du formulaire
    private static final Pattern OPTION = Pattern.compile("<option[^>]*value='(\\w+)'>([^<\\r\\n]+)");
    // la traduction : <div class="txtTrad">...</div>
    private static final Pattern TRADUCTION = Pattern.compile("<div class=\"txtTrad\">(.*?)</div>");
    // une entité HTML : &#225; ou &ccedil;
    private static final Pattern ENTITE = Pattern.compile("&(#\\d+|\\w+);");
    // les quelques entités nommées que l'on sait décoder
    private static final Map<String, String> ENTITES = Map.of(
            "amp", "&", "lt", "<", "gt", ">", "quot", "\"", "apos", "'", "ccedil", "ç", "eacute", "é");

    // le client HTTP et l'adresse du site, fournis par le programme
    private final HttpClient client;
    private final URI urlSite;
    private final Map<String, String> languesTraduites;

    // constructeur privé : on passe par la méthode de fabrication creer
    private ServiceTraduction(HttpClient client, URI urlSite, Map<String, String> langues) {
        this.client = client;
        this.urlSite = urlSite;
        this.languesTraduites = langues;
    }

    @Override
    public Map<String, String> languesTraduites() {
        return languesTraduites;
    }

    // création du service : les sens de traduction sont lus dans le formulaire du site
    static ServiceTraduction creer(HttpClient client, URI urlSite) {
        String page;
        try {
            HttpRequest requete = HttpRequest.newBuilder(urlSite.resolve("traduction"))
                    .timeout(Duration.ofSeconds(10)).build();
            page = client.send(requete, BodyHandlers.ofString()).body();
        } catch (IOException | InterruptedException e) {
            throw new TraductionException("Le site de traduction est inaccessible", e, 11);
        }
        Map<String, String> langues = new LinkedHashMap<>();
        Matcher option = OPTION.matcher(page);
        while (option.find()) {
            // les entités HTML (&ccedil;...) sont décodées
            langues.put(option.group(1), decoderHtml(option.group(2).strip()));
        }
        if (langues.isEmpty()) {
            throw new TraductionException("Le site n'indique aucun sens de traduction", 13);
        }
        return new ServiceTraduction(client, urlSite, Collections.unmodifiableMap(langues));
    }

    // traduction
    @Override
    public String traduire(String texte, String sens) {
        // la traduction demandée est-elle possible ?
        if (!languesTraduites.containsKey(sens)) {
            throw new TraductionException("Le sens de traduction [" + sens + "] n'est pas reconnu", 10);
        }
        // l'URL à demander : le texte doit être encodé
        URI url = urlSite.resolve("traduction?sens=" + sens + "&texte=" + URLEncoder.encode(texte, UTF_8));
        HttpRequest requete = HttpRequest.newBuilder(url).timeout(Duration.ofSeconds(10)).build();
        Optional<String> traduction;
        try {
            // le document est rendu sous forme d'un flux de lignes, lues au fur et à mesure de leur arrivée
            HttpResponse<Stream<String>> reponse = client.send(requete, BodyHandlers.ofLines());
            if (reponse.statusCode() != 200) {
                throw new TraductionException("Le site a répondu avec le code " + reponse.statusCode(), 11);
            }
            // on cherche la traduction ligne après ligne, et on s'arrête dès qu'on l'a trouvée
            try (Stream<String> lignes = reponse.body()) {
                traduction = lignes.map(TRADUCTION::matcher)
                        .filter(Matcher::find)
                        .map(resultat -> decoderHtml(resultat.group(1).strip()))
                        .findFirst();
            }
        } catch (IOException | UncheckedIOException | InterruptedException e) {
            throw new TraductionException("Erreur rencontrée lors de la traduction", e, 11);
        }
        // la page ne contenait pas de traduction
        return traduction.orElseThrow(
                () -> new TraductionException("Le serveur n'a pas renvoyé de traduction", 12));
    }

    // décodage des entités HTML d'un texte
    private static String decoderHtml(String texte) {
        return ENTITE.matcher(texte).replaceAll(entite -> {
            String nom = entite.group(1);
            String caractere = nom.startsWith("#")
                    ? Character.toString(Integer.parseInt(nom.substring(1)))
                    : ENTITES.getOrDefault(nom, entite.group());
            return Matcher.quoteReplacement(caractere);
        });
    }
}

Commençons par l'interface et l'exception :

lignes 52-59 : l'interface présentée au programme. La méthode [languesTraduites] rend le dictionnaire des sens de traduction acceptés par le site, d'entrées de la forme [fe] → [Français vers Anglais] ; la méthode [traduire] traduit le texte [texte] dans le sens dont le code est [sens]. Elle est synchrone : un programme qui veut lancer plusieurs traductions en parallèle les exécutera dans des threads virtuels ;
lignes 63-82 : l'exception propre au service, non contrôlée, avec un code d'erreur, sur le modèle de [ImpotException] (chapitre 6). Dans un fichier source compact, toutes les déclarations sont des membres de la classe implicite : une classe déclarée sans le mot clé [static] y serait une classe interne, dont les instances ne peuvent être créées que depuis une instance de la classe implicite. Les interfaces et les enregistrements, eux, sont toujours implicitement statiques ;
lignes 65-66 : une exception est sérialisable ; [-Xlint:all] demande alors un numéro de version, annoté [@Serial] (Java 14).

La classe [ServiceTraduction] :

lignes 88-95 : les expressions régulières présentées plus haut, compilées une fois pour toutes, et une troisième pour les entités HTML, numériques ([á]) ou nommées ([ç]) ;
ligne 98 : le service ne crée pas son [HttpClient] : il le reçoit du programme, qui décide de sa configuration et de sa durée de vie ;
ligne 103 : le constructeur est privé. Le service ne peut être créé qu'après avoir interrogé le site ; plutôt que de faire cette opération réseau dans un constructeur, on passe par une méthode de fabrication statique, [creer] ;
lignes 115-134 : la création du service. La liste des sens de traduction est lue sur le site lui-même, ce qui nous assure qu'elle est à jour :
- lignes 118-120 : on demande la page du formulaire, sans paramètres ;
- lignes 121-123 : une erreur de communication est encapsulée dans une [TraductionException] de code 11 ;
- lignes 125-129 : chaque balise [<option>] trouvée par l'expression régulière fournit un code (groupe 1) et un libellé (groupe 2). La méthode [decoderHtml] (lignes 169-177) remplace les entités HTML par les caractères qu'elles désignent : [Français] devient [Français] ;
- ligne 133 : le dictionnaire est rendu non modifiable par [Collections.unmodifiableMap], qui conserve l'ordre de la [LinkedHashMap] ;
lignes 138-166 : la traduction :
- lignes 140-142 : on vérifie que le sens de traduction demandé existe ;
- ligne 144 : l'URL à demander, le texte étant encodé ;
- ligne 149 : le gestionnaire [BodyHandlers.ofLines()] rend la réponse dès que ses entêtes sont arrivés ; son document est un flux ([Stream<String>]) de lignes, lues au fur et à mesure de leur arrivée ;
- lignes 154-159 : on cherche la traduction ligne après ligne, et l'on s'arrête à la première trouvée : [findFirst] interrompt le parcours du flux, et le reste de la page n'est jamais lu. Le flux est fermé à la sortie du [try] avec ressources, ce qui libère la connexion. Le résultat est un [Optional<String>], vide si aucune ligne ne contient de traduction ;
- lignes 160-162 : une erreur de communication donne une exception de code 11. Une erreur pendant la lecture du flux de lignes est signalée par une [UncheckedIOException], les méthodes de [Stream] ne pouvant pas lancer d'exception contrôlée ;
- lignes 164-165 : si la page a été lue entièrement sans qu'on y trouve de traduction, on lance une exception de code 12.

Le programme de test :

ligne 17 : l'adresse du site peut être passée en argument ;
ligne 18 : le client HTTP de l'application ;
ligne 20 : la création du service. Le programme ne manipule ensuite le service qu'au travers de son interface [IServiceTraduction] ;
lignes 24-30 : quelques essais, dont deux cas d'erreur : un texte vide et un sens de traduction inconnu. Chaque essai est un enregistrement [Essai] (lignes 13-14).

Résultats, le site [Internet16.java] ayant été lancé dans une autre fenêtre :

> java Internet17.java
Sens de traduction proposés par le site :
  fe : Français vers Anglais
  ef : Anglais vers Français
  fs : Français vers Espagnol
Traduction [Français vers Anglais] de [ce chien est perdu] : [this dog is lost]
Traduction [Français vers Espagnol] de [l'été sera chaud] : [el verano será caliente]
Traduction [Anglais vers Français] de [my tailor is rich] : [mon tailleur est riche]
Traduction [Anglais vers Français] de [xx] : [xx]
L'erreur suivante de code 12 s'est produite : Le serveur n'a pas renvoyé de traduction
L'erreur suivante de code 10 s'est produite : Le sens de traduction [fx] n'est pas reconnu

lignes 3-5 : les sens de traduction ont été lus dans le formulaire du site, et les entités HTML décodées ;
ligne 9 : un mot inconnu est rendu tel quel ;
ligne 10 : pour un texte vide, le site a renvoyé son formulaire sans traduction ;
ligne 11 : le sens [fx] a été refusé par le service sans interroger le site.

Si le site est absent :

1
2
3

> java Internet17.java http://localhost:27299/
L'erreur suivante de code 11 s'est produite : Le site de traduction est inaccessible
Cause : java.net.ConnectException

Côté site, on retrouve la requête de [curl] vue plus haut, puis celles envoyées par le client : la première pour le formulaire, les suivantes pour les traductions (le sens [fx], refusé par le service, n'a donné lieu à aucune requête). [URLEncoder] a encodé les espaces par [+], alors que l'URL donnée à [curl] les encodait par [%20] :

> java Internet16.java
Service de traduction lancé sur http://localhost:27220/traduction
GET /traduction?sens=fs&texte=l%27%C3%A9t%C3%A9%20sera%20chaud -> 200
GET /traduction -> 200
GET /traduction?sens=fe&texte=ce+chien+est+perdu -> 200
GET /traduction?sens=fs&texte=l%27%C3%A9t%C3%A9+sera+chaud -> 200
GET /traduction?sens=ef&texte=my+tailor+is+rich -> 200
GET /traduction?sens=ef&texte=xx -> 200
GET /traduction?sens=fe&texte= -> 200

12.7.3.4. Conclusion

Cette application a montré que [HttpClient] nous permet d'exploiter les ressources du Web. La technique est à chaque fois la même :

déterminer l'URL à interroger. Elle est la plupart du temps paramétrée ;
l'interroger ;
trouver dans la réponse du serveur ce qu'on cherche, grâce à des expressions régulières.

Cette technique, que l'on appelle aujourd'hui le « web scraping » (moissonnage du Web), est fragile : au fil du temps, l'URL interrogée ou la structure de la page peuvent changer, et l'expression régulière qui permettait de trouver le résultat ne fonctionne plus. On a intérêt à placer ces informations dans un fichier de configuration, mais cela ne suffit pas toujours ; de plus, les conditions d'utilisation de nombreux sites l'interdisent. Une analyse robuste d'une page HTML se ferait d'ailleurs plutôt avec une bibliothèque spécialisée, comme jsoup, qu'avec des expressions régulières. Nous verrons au chapitre suivant qu'il existe sur le Web des ressources plus stables, conçues pour être utilisées par des programmes : les services web. Les services de traduction actuels, par exemple, offrent tous une interface de ce type, qui reçoit et rend du JSON.

12.7.4. Un client SMTP avec Jakarta Mail

Un client SMTP est un client d'un serveur SMTP, serveur d'envoi de courrier, dont nous avons présenté le protocole dans la première partie. Le JDK n'a pas de classe pour le courrier électronique. La bibliothèque standard de fait est Jakarta Mail (autrefois JavaMail), dont l'implémentation de référence s'appelle aujourd'hui Eclipse Angus Mail. Elle encapsule les besoins d'un client de messagerie : le développeur n'a pas à connaître les détails du protocole SMTP, ni ceux du format MIME des messages. Ses principales classes sont [Session] (la configuration), [MimeMessage] (un message), [InternetAddress] (une adresse électronique), [MimeMultipart] et [MimeBodyPart] (un message en plusieurs parties, par exemple un texte et des pièces jointes) et [Transport], qui envoie le message. Elle sait aussi lire le courrier en POP3 et IMAP, et gère l'authentification et le chiffrement TLS qu'exigent les vrais serveurs.

Nous ne pouvons pas envoyer de courrier à un vrai serveur SMTP : notre machine de test n'a pas accès à l'Internet, et, comme nous l'avons dit, les fournisseurs d'accès bloquent le port 25. Le courrier sera envoyé à un petit serveur SMTP de test, écrit en Java et exécuté sur la machine locale, qui affichera tout ce qu'il reçoit et n'acheminera rien. Pour un usage réel, il existe des serveurs de test complets, comme Mailpit ou GreenMail (écrit en Java), qui offrent en plus une interface pour consulter les messages reçus.

12.7.4.1. Un serveur SMTP de test

Notre serveur SMTP reprend la structure du serveur d'écho de la première partie : une boucle d'attente des clients, un thread virtuel par client, un arrêt propre par Ctrl-C. Le service rendu à chaque client est le dialogue SMTP minimal présenté dans la première partie. Le programme [Internet18.java] est le suivant :

import static java.nio.charset.StandardCharsets.UTF_8;

// serveur SMTP de test : il joue le dialogue SMTP minimal et affiche les messages reçus,
// sans jamais les acheminer à leurs destinataires
// appel : java Internet18.java [port]   (port 27225 par défaut) ; arrêt par Ctrl-C

final Set<Socket> connexions = ConcurrentHashMap.newKeySet();
volatile boolean arret = false;

void main(String[] args) {
    int port = args.length == 1 ? Integer.parseInt(args[0]) : 27225;
    // le serveur n'accepte que les clients de la machine locale (adresse de bouclage)
    try (var ecoute = new ServerSocket(port, 50, InetAddress.getLoopbackAddress());
         var services = Executors.newVirtualThreadPerTaskExecutor()) {
        arreterSurCtrlC(ecoute);
        IO.println("Serveur SMTP de test lancé sur " + ecoute.getLocalSocketAddress());
        try {
            for (int numClient = 0; ; numClient++) {
                Socket client = ecoute.accept();
                connexions.add(client);
                int numero = numClient;
                services.submit(() -> servir(client, numero));
            }
        } catch (SocketException e) {
            if (!arret) {
                throw e;
            }
            IO.println("Arrêt du serveur demandé");
            for (Socket connexion : connexions) {
                connexion.close();
            }
        }
    } catch (IOException e) {
        IO.println("L'erreur suivante s'est produite sur le serveur : " + e.getMessage());
    }
}

// Ctrl-C : fermeture du service d'écoute, puis attente de la fin du programme principal
void arreterSurCtrlC(ServerSocket ecoute) {
    Thread principal = Thread.currentThread();
    Runtime.getRuntime().addShutdownHook(new Thread(() -> {
        arret = true;
        try {
            ecoute.close();
            principal.join();
        } catch (IOException | InterruptedException e) {
            // on s'arrête de toute façon
        }
    }));
}

// le dialogue SMTP avec un client : C: lignes reçues du client, S: lignes envoyées par le serveur
void servir(Socket client, int numClient) {
    IO.println("--- début du dialogue avec le client " + numClient + " ("
            + client.getRemoteSocketAddress() + ")");
    try (client;
         var lecteur = new BufferedReader(new InputStreamReader(client.getInputStream(), UTF_8));
         var ecrivain = new OutputStreamWriter(client.getOutputStream(), UTF_8)) {
        // envoi d'une ligne de réponse, affichée aussi sur la console ; SMTP exige des fins de ligne \r\n
        Repondeur repondre = reponse -> {
            IO.println("S: " + reponse);
            ecrivain.write(reponse + "\r\n");
            ecrivain.flush();
        };
        // l'enveloppe du message en cours : expéditeur et destinataires
        String expediteur = null;
        List<String> destinataires = new ArrayList<>();
        // message d'accueil
        repondre.envoyer("220 smtp.test ESMTP serveur de test du cours Java");
        String commande;
        while ((commande = lecteur.readLine()) != null) {
            IO.println("C: " + commande);
            // le verbe : les quatre premiers caractères, sans tenir compte de la casse
            String verbe = commande.length() >= 4 ? commande.substring(0, 4) : commande;
            verbe = verbe.toUpperCase(Locale.ROOT);
            // ce qui suit le caractère « : » dans MAIL FROM:<adresse> et RCPT TO:<adresse>
            String adresse = commande.substring(commande.indexOf(':') + 1).strip();
            switch (verbe) {
                case "EHLO" -> {
                    // réponse sur plusieurs lignes : 250-... puis 250 ...
                    repondre.envoyer("250-smtp.test bonjour");
                    repondre.envoyer("250-SIZE 10485760");
                    repondre.envoyer("250 8BITMIME");
                }
                case "HELO" -> repondre.envoyer("250 smtp.test bonjour");
                case "MAIL" -> {
                    expediteur = adresse;
                    destinataires.clear();
                    repondre.envoyer("250 2.1.0 Ok");
                }
                case "RCPT" -> {
                    destinataires.add(adresse);
                    repondre.envoyer("250 2.1.5 Ok");
                }
                case "DATA" -> {
                    // il faut d'abord l'expéditeur et les destinataires
                    if (expediteur == null || destinataires.isEmpty()) {
                        repondre.envoyer("503 5.5.1 Indiquez d'abord l'expéditeur et les destinataires");
                        continue;
                    }
                    repondre.envoyer("354 End data with <CR><LF>.<CR><LF>");
                    // le message : toutes les lignes jusqu'à une ligne réduite à un point
                    int nbLignes = 0;
                    String ligne;
                    while ((ligne = lecteur.readLine()) != null && !ligne.equals(".")) {
                        IO.println("C: " + ligne);
                        nbLignes++;
                    }
                    // le client a fermé la connexion avant la fin du message
                    if (ligne == null) {
                        IO.println("[message incomplet : connexion fermée par le client]");
                        return;
                    }
                    IO.println("C: .");
                    IO.println("[message de %s pour %s : %d lignes]".formatted(expediteur,
                            String.join(", ", destinataires), nbLignes));
                    repondre.envoyer("250 2.0.0 Ok: message accepté");
                    expediteur = null;
                    destinataires.clear();
                }
                case "RSET" -> {
                    expediteur = null;
                    destinataires.clear();
                    repondre.envoyer("250 2.0.0 Ok");
                }
                case "NOOP" -> repondre.envoyer("250 2.0.0 Ok");
                case "QUIT" -> {
                    repondre.envoyer("221 2.0.0 Au revoir");
                    return;
                }
                default -> repondre.envoyer("502 5.5.2 Commande non reconnue");
            }
        }
    } catch (IOException e) {
        if (arret) {
            IO.println("Dialogue avec le client " + numClient + " interrompu par l'arrêt du serveur");
        } else {
            IO.println("L'erreur suivante s'est produite avec le client " + numClient + " : "
                    + e.getMessage());
        }
    } finally {
        connexions.remove(client);
        IO.println("--- fin du dialogue avec le client " + numClient);
    }
}

// envoi d'une ligne de réponse : une interface fonctionnelle dont la méthode peut lancer une IOException
interface Repondeur {
    void envoyer(String reponse) throws IOException;
}

Ne commentons que ce qui est nouveau par rapport au serveur d'écho :

ligne 13 : le serveur n'écoute que sur l'adresse de bouclage : seuls des programmes de la même machine peuvent s'y connecter. Le deuxième paramètre (50) est la taille de la file d'attente des connexions ;
lignes 60-64 : une lambda qui envoie une ligne de réponse au client, terminée par \r\n comme l'exige SMTP, et l'affiche sur la console, précédée de [S:]. Les lignes reçues du client sont affichées précédées de [C:], comme dans les dialogues types de la première partie. Les interfaces fonctionnelles du JDK ([Consumer<String>]…) n'autorisent pas les exceptions contrôlées : nous déclarons donc notre propre interface fonctionnelle, [Repondeur] (lignes 148-150), dont la méthode peut lancer une [IOException] ;
lignes 66-67 : l'enveloppe du message en cours : l'expéditeur annoncé par [MAIL FROM] et les destinataires annoncés par [RCPT TO] ;
ligne 69 : le message d'accueil : en SMTP, c'est le serveur qui parle le premier ;
lignes 74-75 : le verbe de la commande est formé de ses quatre premiers caractères ([EHLO], [MAIL], [RCPT]…), mis en majuscules. [Locale.ROOT] rend la conversion indépendante de la langue de la machine (en turc, la majuscule de [i] n'est pas [I]) ;
lignes 79-84 : la réponse à [EHLO] est faite de plusieurs lignes. Le serveur y annonce ses extensions : la taille maximale d'un message ([SIZE]) et l'acceptation des caractères codés sur 8 bits ([8BITMIME]) ;
lignes 97-100 : la commande [DATA] est refusée si l'expéditeur ou les destinataires n'ont pas été indiqués ; [continue] passe à la commande suivante ;
lignes 101-119 : le message lui-même. Le serveur invite le client à l'envoyer (code 354), puis lit et affiche toutes les lignes jusqu'à une ligne réduite à un point, et confirme la réception (code 250). Si le client ferme la connexion avant la fin du message, celui-ci est abandonné (lignes 110-113) ;
lignes 127-130 : le client a terminé : le serveur répond et ferme la connexion, en sortant de la méthode (le [try] avec ressources ferme le socket) ;
ligne 131 : toute autre commande est refusée.

Ce serveur ne vérifie pas grand-chose et ne gère pas les extensions [STARTTLS] et [AUTH] : il suffit pour observer ce qu'envoie Jakarta Mail.

12.7.4.2. Le client SMTP

Le programme [Internet19] demande au clavier les éléments du courrier (expéditeur, destinataires, sujet, pièces jointes, texte), puis l'envoie au serveur SMTP indiqué en argument. C'est un projet Maven, dont le [pom.xml] déclare la dépendance suivante :

    <dependencies>
        <!-- Jakarta Mail : l'API jakarta.mail et son implémentation Eclipse Angus -->
        <dependency>
            <groupId>org.eclipse.angus</groupId>
            <artifactId>angus-mail</artifactId>
            <version>2.0.3</version>
        </dependency>
    </dependencies>

La dépendance [angus-mail] apporte l'implémentation et, par dépendance transitive, l'API [jakarta.mail] et la bibliothèque [jakarta.activation] qu'elle utilise. Le code n'utilise que l'API, dans les paquetages [jakarta.mail] et [jakarta.mail.internet]. La classe [Internet19] est la suivante :

package internet;

import jakarta.mail.Message.RecipientType;
import jakarta.mail.MessagingException;
import jakarta.mail.Session;
import jakarta.mail.Transport;
import jakarta.mail.internet.AddressException;
import jakarta.mail.internet.InternetAddress;
import jakarta.mail.internet.MimeBodyPart;
import jakarta.mail.internet.MimeMessage;
import jakarta.mail.internet.MimeMultipart;
import java.io.File;
import java.io.IOException;
import java.util.ArrayList;
import java.util.List;
import java.util.Properties;

// envoi d'un courrier électronique avec Jakarta Mail
// appel : mvn exec:java -Dexec.args="serveurSmtp port"
// les pièces jointes sont cherchées dans le dossier courant
public class Internet19 {

    private static final String SYNTAXE = "Syntaxe : mvn exec:java -Dexec.args=\"serveurSmtp port\"";

    public static void main(String[] args) {
        if (args.length != 2 || !args[1].matches("\\d{1,5}")) {
            IO.println(SYNTAXE);
            return;
        }
        String serveur = args[0];
        String port = args[1];

        // saisie des éléments du courrier
        String expediteur = saisir("Expéditeur");
        String destinataires = saisir("Destinataires (séparés par des virgules)");
        String copies = saisir("Copie à (Cc)");
        String copiesCachees = saisir("Copie cachée à (Bcc)");
        String sujet = saisir("Sujet");
        String piecesJointes = saisir("Pièces jointes (séparées par des virgules)");
        // le texte : plusieurs lignes, terminées par une ligne vide
        IO.println("Texte du message (terminé par une ligne vide) :");
        var texte = new StringBuilder();
        String ligne;
        while ((ligne = IO.readln()) != null && !ligne.isEmpty()) {
            texte.append(ligne).append('\n');
        }

        try {
            // la session de messagerie : elle contient la configuration du client SMTP
            var proprietes = new Properties();
            proprietes.put("mail.smtp.host", serveur);
            proprietes.put("mail.smtp.port", port);
            Session session = Session.getInstance(proprietes);

            // le message
            var message = new MimeMessage(session);
            var de = new InternetAddress(expediteur, true);
            de.validate();
            message.setFrom(de);
            message.setRecipients(RecipientType.TO, adresses(destinataires));
            message.setRecipients(RecipientType.CC, adresses(copies));
            message.setRecipients(RecipientType.BCC, adresses(copiesCachees));
            message.setSubject(sujet, "UTF-8");
            // un message en plusieurs parties : d'abord le texte, en UTF-8 transporté tel quel (8 bits)
            var partieTexte = new MimeBodyPart();
            partieTexte.setText(texte.toString(), "UTF-8");
            partieTexte.setHeader("Content-Transfer-Encoding", "8bit");
            var contenu = new MimeMultipart(partieTexte);
            // puis les pièces jointes, désignées par leur chemin
            List<String> noms = new ArrayList<>();
            for (String fichier : piecesJointes.split(",")) {
                if (!fichier.isBlank()) {
                    var piece = new MimeBodyPart();
                    piece.attachFile(new File(fichier.strip()));
                    contenu.addBodyPart(piece);
                    noms.add(piece.getFileName());
                }
            }
            message.setContent(contenu);

            // l'envoi : Transport connaît le protocole SMTP ; le message connaît le format MIME
            Transport.send(message);

            // résumé de l'envoi
            IO.println("Envoi réussi...");
            IO.println("Sujet : " + message.getSubject());
            IO.println("Destinataires : " + liste(message, RecipientType.TO));
            IO.println("Cc : " + liste(message, RecipientType.CC));
            IO.println("Bcc : " + liste(message, RecipientType.BCC));
            IO.println("Pièces jointes : " + String.join(", ", noms));
        } catch (MessagingException | IOException e) {
            IO.println("L'erreur suivante s'est produite : " + e.getClass().getSimpleName() + " : "
                    + e.getMessage());
            if (e.getCause() != null) {
                IO.println("Cause : " + e.getCause());
            }
        }
    }

    // une liste d'adresses séparées par des virgules ; chaque adresse est vérifiée
    private static InternetAddress[] adresses(String liste) throws AddressException {
        InternetAddress[] adresses = InternetAddress.parse(liste, true);
        for (InternetAddress adresse : adresses) {
            adresse.validate();
        }
        return adresses;
    }

    // les adresses d'une catégorie de destinataires, séparées par des virgules
    private static String liste(MimeMessage message, RecipientType type) throws MessagingException {
        return InternetAddress.toString(message.getRecipients(type));
    }

    // saisie d'une ligne au clavier
    private static String saisir(String libelle) {
        String ligne = IO.readln(libelle + " : ");
        return ligne == null ? "" : ligne.strip();
    }
}

Commentaires :

lignes 34-46 : la saisie des éléments du courrier, avec la méthode [saisir] (lignes 115-118). Le texte du message est formé de plusieurs lignes, terminées par une ligne vide ;
lignes 50-53 : la session de messagerie. Sa configuration est un objet [Properties] : ici, la machine et le port du serveur SMTP. Pour un vrai serveur, on ajouterait [mail.smtp.auth=true], [mail.smtp.starttls.enable=true] (chiffrement par [STARTTLS]) et l'on fournirait l'identifiant et le mot de passe à [Transport.send] ;
lignes 56-63 : le message :
- lignes 57-59 : l'expéditeur, un objet [InternetAddress]. Le second paramètre du constructeur ([true]) demande une analyse stricte de l'adresse, et [validate] vérifie en plus qu'elle a la forme [nom@domaine] ; une adresse incorrecte provoque une [AddressException] ;
- lignes 60-62 : les destinataires, ceux en copie (Cc, Carbon Copy) et ceux en copie cachée (Bcc, Blind Carbon Copy). Les destinataires en copie cachée reçoivent le message, mais les autres destinataires ne le savent pas. La méthode [adresses] (lignes 101-107) analyse une liste d'adresses séparées par des virgules avec [InternetAddress.parse], et vérifie chacune d'elles ;
- ligne 63 : le sujet, avec son jeu de caractères ;
lignes 65-68 : le message est formé de plusieurs parties ([MimeMultipart]). La première est le texte, en UTF-8. L'entête [Content-Transfer-Encoding: 8bit] demande qu'il soit transmis tel quel, sur 8 bits (le serveur a annoncé qu'il l'acceptait) ; sans lui, Jakarta Mail choisirait lui-même un codage (quoted-printable ou base64) qui rendrait le texte difficile à lire dans l'affichage du serveur ;
lignes 71-78 : les pièces jointes, désignées par le chemin de leur fichier. Un chemin relatif est relatif au dossier courant ; dans nos essais, le fichier [piece-jointe.txt] est placé dans le dossier [Internet19], d'où l'on lance le programme. [attachFile] crée une partie dont le contenu sera lu dans le fichier au moment de l'envoi ;
ligne 82 : l'envoi du message par la méthode statique [Transport.send], qui se connecte au serveur indiqué par la session, mène le dialogue SMTP et transmet le message au format MIME ;
lignes 85-90 : le résumé de l'envoi. [InternetAddress.toString] (ligne 111) réunit une liste d'adresses en une chaîne ;
lignes 91-97 : une adresse mal formée provoque une [AddressException], un problème d'envoi une autre [MessagingException], dont la cause est affichée. Une pièce jointe introuvable n'est détectée qu'au moment de l'envoi : elle provoque une [MessagingException] dont la cause est une [FileNotFoundException].

Le serveur SMTP de test est lancé dans une fenêtre de commandes, sur le port 27225. Dans une autre fenêtre, depuis le dossier [Internet19], on envoie un message à deux destinataires, avec un destinataire en copie, un en copie cachée et une pièce jointe :

> mvn compile exec:java -Dexec.args="localhost 27225"
Expéditeur : alice@example.org
Destinataires (séparés par des virgules) : bob@example.com, carole@example.com
Copie à (Cc) : david@example.com
Copie cachée à (Bcc) : eve@example.com
Sujet : Compte rendu de réunion
Pièces jointes (séparées par des virgules) : piece-jointe.txt
Texte du message (terminé par une ligne vide) :
Bonjour,
voici le compte rendu de la réunion d'été.
Cordialement,
Alice

Envoi réussi...
Sujet : Compte rendu de réunion
Destinataires : bob@example.com, carole@example.com
Cc : david@example.com
Bcc : eve@example.com
Pièces jointes : piece-jointe.txt

Le fichier [piece-jointe.txt] contient deux lignes de texte. Voici ce qu'a affiché le serveur :

> java Internet18.java
Serveur SMTP de test lancé sur localhost/127.0.0.1:27225
--- début du dialogue avec le client 0 (/127.0.0.1:47628)
S: 220 smtp.test ESMTP serveur de test du cours Java
C: EHLO localhost
S: 250-smtp.test bonjour
S: 250-SIZE 10485760
S: 250 8BITMIME
C: MAIL FROM:<alice@example.org>
S: 250 2.1.0 Ok
C: RCPT TO:<bob@example.com>
S: 250 2.1.5 Ok
C: RCPT TO:<carole@example.com>
S: 250 2.1.5 Ok
C: RCPT TO:<david@example.com>
S: 250 2.1.5 Ok
C: RCPT TO:<eve@example.com>
S: 250 2.1.5 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: Date: Sat, 3 Oct 2026 19:41:44 +0200 (CEST)
C: From: alice@example.org
C: To: bob@example.com, carole@example.com
C: Cc: david@example.com
C: Message-ID: <1094834071.1.1791049304833@localhost>
C: Subject: =?UTF-8?Q?Compte_rendu_de_r=C3=A9union?=
C: MIME-Version: 1.0
C: Content-Type: multipart/mixed; 
C:     boundary="----=_Part_0_1213415012.1791049304796"
C: 
C: ------=_Part_0_1213415012.1791049304796
C: Content-Type: text/plain; charset=UTF-8
C: Content-Transfer-Encoding: 8bit
C: 
C: Bonjour,
C: voici le compte rendu de la réunion d'été.
C: Cordialement,
C: Alice
C: 
C: ------=_Part_0_1213415012.1791049304796
C: Content-Type: text/plain; charset=UTF-8; name=piece-jointe.txt
C: Content-Transfer-Encoding: quoted-printable
C: Content-Disposition: attachment; filename=piece-jointe.txt
C: 
C: Ceci est la pi=C3=A8ce jointe du courrier d'essai.
C: Elle contient deux lignes.
C: 
C: ------=_Part_0_1213415012.1791049304796--
C: .
[message de <alice@example.org> pour <bob@example.com>, <carole@example.com>, <david@example.com>, <eve@example.com> : 28 lignes]
S: 250 2.0.0 Ok: message accepté
C: QUIT
S: 221 2.0.0 Au revoir
--- fin du dialogue avec le client 0
Arrêt du serveur demandé

Commentaires :

ligne 5 : Jakarta Mail se présente avec le nom de la machine locale, ici [localhost] ;
lignes 9-18 : l'enveloppe du message : l'expéditeur, puis tous les destinataires, y compris celui en copie cachée ([eve@example.com]). C'est l'enveloppe qui détermine à qui le message est remis ;
lignes 21-29 : les entêtes du message, qui forment ce que verront les destinataires : la date, l'expéditeur, les destinataires [To] et [Cc], un identifiant unique du message ([Message-ID]), le sujet… On n'y trouve pas le destinataire en copie cachée : c'est ainsi que celle-ci reste cachée. Le sujet contient un caractère accentué ; les entêtes ne pouvant contenir que des caractères ASCII, il a été codé selon la RFC 2047 : [=?UTF-8?Q?...?=] signifie « texte UTF-8 codé en quoted-printable », chaque octet non ASCII étant écrit [=XX] en hexadécimal ([=C3=A9] pour les deux octets de [é]) et chaque espace par [_] ;
lignes 28-29 : le message est au format MIME (Multipurpose Internet Mail Extensions, RFC 2045 et suivantes) : il est formé de plusieurs parties ([multipart/mixed]), séparées par une ligne frontière ([boundary]) choisie au hasard par Jakarta Mail. Un entête trop long peut être replié sur la ligne suivante, à condition que celle-ci commence par un espace ou une tabulation ;
lignes 31-39 : la première partie, le texte du message, en UTF-8 sur 8 bits : il est lisible tel quel ;
lignes 40-47 : la seconde partie, la pièce jointe. Jakarta Mail a reconnu un fichier texte ([text/plain]) et l'a codé en quoted-printable : ce codage laisse lisibles les caractères ASCII et code les autres, comme le [è] de [pièce] ([=C3=A8]). Un fichier binaire (une image…) aurait été codé en base64, qui représente des octets quelconques avec 64 caractères ASCII. L'entête [Content-Disposition: attachment] indique qu'il s'agit d'une pièce jointe et donne son nom ;
lignes 48-49 : la frontière finale, suivie de deux tirets, puis la ligne réduite à un point qui termine le message ;
ligne 50 : notre serveur a reçu un message pour quatre destinataires ;
lignes 52-53 : Jakarta Mail termine le dialogue ;
ligne 55 : le serveur a été arrêté par Ctrl-C après les essais.

Une adresse mal formée est refusée avant tout envoi :

> mvn compile exec:java -Dexec.args="localhost 27225"
Expéditeur : alice@example.org
Destinataires (séparés par des virgules) : bob.example.com
Copie à (Cc) : 
Copie cachée à (Bcc) : 
Sujet : essai
Pièces jointes (séparées par des virgules) : 
Texte du message (terminé par une ligne vide) :
texte

L'erreur suivante s'est produite : AddressException : Missing final '@domain'

Si le serveur SMTP est absent, c'est une [MailConnectException], sorte de [MessagingException], qui est lancée ; sa cause est la [ConnectException] du socket :

> mvn compile exec:java -Dexec.args="localhost 27299"
Expéditeur : alice@example.org
Destinataires (séparés par des virgules) : bob@example.com
Copie à (Cc) : 
Copie cachée à (Bcc) : 
Sujet : essai
Pièces jointes (séparées par des virgules) : 
Texte du message (terminé par une ligne vide) :
texte

L'erreur suivante s'est produite : MailConnectException : Couldn't connect to host, port: localhost, 27299; timeout -1
Cause : java.net.ConnectException: Connection refused

12.8. Programmation réseau asynchrone : des canaux NIO aux threads virtuels

À l'exception des requêtes [sendAsync] de [HttpClient], les programmes de ce chapitre utilisent des opérations réseau bloquantes, exécutées par des threads (virtuels pour les serveurs). Ce n'est pas la seule façon de faire, et le lecteur rencontrera dans du code existant les deux autres modèles que Java a proposés avant Java 21.

Le premier, introduit par Java 1.4, est celui des entrées-sorties non bloquantes du paquetage [java.nio.channels]. Un [SocketChannel] placé en mode non bloquant ([canal.configureBlocking(false)]) rend la main immédiatement, qu'il y ait des données à lire ou non ; un objet [Selector] permet à un seul thread de surveiller un grand nombre de canaux et d'être réveillé lorsque l'un d'eux est prêt (nouvelle connexion à accepter, données à lire, place pour écrire). Le programme tourne alors dans une boucle unique qui, à chaque réveil, traite les canaux prêts. Les données y sont lues par blocs dans des tampons d'octets ([ByteBuffer]) : c'est au programme de reconstituer les lignes, une ligne pouvant être coupée entre deux blocs, et de mémoriser, pour chaque client, où en est son dialogue.

Le second, introduit par Java 7 (NIO.2), est celui des canaux asynchrones : [AsynchronousSocketChannel] et [AsynchronousServerSocketChannel]. Chaque opération est lancée avec un objet de rappel ([CompletionHandler]), dont la méthode [completed] est exécutée par un thread d'un pool à la fin de l'opération. La connexion d'un client s'écrit ainsi [canal.connect(adresse, null, gestionnaire)], et la méthode [completed] du gestionnaire doit lancer la lecture suivante, dont la méthode [completed] lancera la suivante, et ainsi de suite. Le code est long, et la logique du dialogue est dispersée entre plusieurs méthodes de rappel.

Ces deux modèles sont efficaces : ils permettent à quelques threads de servir des milliers de connexions. Mais ils sont difficiles à programmer et à mettre au point ; on les utilise surtout au travers de bibliothèques comme Netty, sur lesquelles reposent de nombreux serveurs. Les threads virtuels de Java 21 ont rendu ces techniques inutiles pour la plupart des applications : un thread virtuel bloqué sur une opération réseau ne bloque aucun thread du système, et le code se lit dans l'ordre où il s'exécute, comme un code synchrone. Le client TCP générique de la première partie ([Internet06.java]) en est un exemple : un thread virtuel lit le clavier pendant que le thread principal lit le réseau, avec de simples appels à [readLine].

Retenons que l'asynchronisme apporte peu à un client qui n'a qu'une connexion : son thread n'a rien d'autre à faire qu'attendre la réponse. Il est en revanche essentiel pour un serveur : un serveur qui sert ses clients avec des threads de plate-forme bloqués immobilise un thread du système par client ; avec des threads virtuels, ou avec les canaux non bloquants, quelques threads du système suffisent à servir un grand nombre de clients. C'est ce que fait le serveur de l'application exemple qui suit.

12.9. Application exemple, version 8 : serveur de calcul de l'impôt

12.9.1. L'architecture de la nouvelle version

Nous reprenons l'application de calcul de l'impôt. Dans sa version 5 (chapitre 6), elle était formée de trois couches, chacune dans son module Maven : [dao] (les tranches d'impôt), [metier] (le calcul) et [ui] (le dialogue console), assemblées par le conteneur d'injection de dépendances de Spring ; les versions 6 et 7 ont remplacé la couche [dao] par un accès à une base de données. Nous partons de la version 5, plus simple à exécuter : la nouvelle version fonctionnerait de la même façon avec la couche [dao] des versions 6 et 7.

Nous allons distribuer cette architecture sur deux machines :

une machine [serveur] héberge les couches [metier] et [dao] de la version 5. Une couche [serveur] est construite pour permettre à des clients du réseau d'interroger le service de calcul de l'impôt, avec un protocole TCP à lignes de texte ;
une machine [client] héberge la couche [ui] de la version 5. Une nouvelle couche [metier], cliente TCP du serveur, lui permet d'interroger le service de calcul de l'impôt.

L'architecture change profondément : la version 5 était une application monoposte ; la version 8 devient une application client / serveur, et le serveur pourra servir plusieurs clients simultanément. Pourtant, nous n'écrirons que deux classes nouvelles, [ServeurImpot] et [ImpotMetierTcp], un enregistrement d'options et deux programmes principaux : tout le reste est réutilisé sans modification.

Le projet [ImpotsV8] est un projet Maven multi-modules, formé de deux modules, qui utilisent les modules de la version 5. Ceux-ci doivent avoir été installés dans le dépôt Maven local par la commande [mvn install], exécutée dans le dossier [ImpotsV5] (chapitre 6) :

12-internet/ImpotsV8/
  pom.xml                         projet parent : modules, versions, configuration commune
  impots-serveur/
    pom.xml                       dépendances : impots-dao et impots-metier (V5), Spring
    serveur.properties            configuration de la couche [dao] et du serveur
    DataImpot.txt                 les tranches d'impôt
    src/main/java/impots/serveur/
      Main.java                   intégration des couches, lancement du serveur
      OptionsServeur.java         les options du serveur
      ServeurImpot.java           la couche [serveur]
  impots-client/
    pom.xml                       dépendances : impots-metier et impots-ui (V5), Spring
    src/main/java/impots/client/
      ImpotMetierTcp.java         la couche [metier] du client : un client TCP
      Main.java                   intégration des couches, dialogue

Le projet parent est le suivant :

<?xml version="1.0" encoding="UTF-8"?>
<!-- projet parent de l'application [Impots], version 8 : un serveur TCP et son client -->
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>exemples.impots</groupId>
    <artifactId>impots-v8</artifactId>
    <version>8.0</version>
    <packaging>pom</packaging>

    <modules>
        <module>impots-serveur</module>
        <module>impots-client</module>
    </modules>

    <properties>
        <maven.compiler.release>25</maven.compiler.release>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
    </properties>

    <!-- les couches de la version 5 (installées par mvn install dans ImpotsV5) et Spring -->
    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>exemples.impots</groupId>
                <artifactId>impots-dao</artifactId>
                <version>5.0</version>
            </dependency>
            <dependency>
                <groupId>exemples.impots</groupId>
                <artifactId>impots-metier</artifactId>
                <version>5.0</version>
            </dependency>
            <dependency>
                <groupId>exemples.impots</groupId>
                <artifactId>impots-ui</artifactId>
                <version>5.0</version>
            </dependency>
            <dependency>
                <groupId>org.springframework</groupId>
                <artifactId>spring-context</artifactId>
                <version>7.0.9</version>
            </dependency>
        </dependencies>
    </dependencyManagement>

    <build>
        <pluginManagement>
            <plugins>
                <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-compiler-plugin</artifactId>
                    <version>3.15.0</version>
                    <configuration>
                        <parameters>true</parameters>
                        <compilerArgs>
                            <arg>-Xlint:all</arg>
                        </compilerArgs>
                    </configuration>
                </plugin>
                <plugin>
                    <groupId>org.codehaus.mojo</groupId>
                    <artifactId>exec-maven-plugin</artifactId>
                    <version>3.5.1</version>
                </plugin>
            </plugins>
        </pluginManagement>
    </build>
</project>

lignes 8-11 : le projet parent, d'empaquetage [pom], a la version 8.0 de l'application ;
lignes 13-16 : ses deux modules ;
lignes 24-47 : les versions des dépendances utilisées par les modules : les trois modules de la version 5 et le conteneur Spring ;
lignes 49-70 : la configuration commune du compilateur et du plugin d'exécution.

12.9.2. Le protocole de dialogue

Une fois le client connecté, le serveur lui envoie un message de bienvenue, puis accepte les commandes suivantes, une par ligne, sans tenir compte de la casse :

Commande	Réponse du serveur
aide	la liste des commandes acceptées, sur quatre lignes
impot marié nbEnfants salaireAnnuel	l'impôt d'une personne mariée (marié vaut [o]) ou non ([n]) ayant [nbEnfants] enfants et un salaire annuel de [salaireAnnuel] euros, par exemple [4282] en réponse à [impot o 2 60000] ; ou un message d'erreur, sur une ligne
aurevoir	le message [Au revoir...] ; le serveur ferme ensuite la connexion

Toute autre commande reçoit la réponse [Commande non reconnue. Utilisez la commande aide.]

12.9.3. Le serveur de calcul de l'impôt

12.9.3.1. Le module

Le fichier [pom.xml] du module [impots-serveur] est le suivant :

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <parent>
        <groupId>exemples.impots</groupId>
        <artifactId>impots-v8</artifactId>
        <version>8.0</version>
    </parent>

    <artifactId>impots-serveur</artifactId>

    <dependencies>
        <!-- les couches [dao] et [metier] de la version 5, réutilisées telles quelles -->
        <dependency>
            <groupId>exemples.impots</groupId>
            <artifactId>impots-dao</artifactId>
        </dependency>
        <dependency>
            <groupId>exemples.impots</groupId>
            <artifactId>impots-metier</artifactId>
        </dependency>
        <!-- le conteneur d'injection de dépendances de Spring -->
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-context</artifactId>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <!-- mvn exec:java exécute la classe principale, dans le dossier du module -->
            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>exec-maven-plugin</artifactId>
                <configuration>
                    <mainClass>impots.serveur.Main</mainClass>
                </configuration>
            </plugin>
        </plugins>
    </build>
</project>

lignes 7-11 : le module hérite du projet parent ;
lignes 17-24 : les couches [dao] et [metier] de la version 5 sont des dépendances, sans version : celle-ci est donnée par le projet parent ;
lignes 26-29 : le conteneur d'injection de dépendances de Spring ;
lignes 35-41 : la classe principale exécutée par [mvn exec:java]. Comme dans la version 5, le programme lit sa configuration et le fichier des tranches d'impôt dans le dossier courant, c'est-à-dire dans le dossier du module, où se trouvent les fichiers [serveur.properties] et [DataImpot.txt].

Le fichier de configuration [serveur.properties] :

# configuration du serveur de calcul de l'impôt
# la couche [dao] : comme dans la version 5
dao.implementation=FileImpot
dao.fichier=DataImpot.txt
# le port d'écoute et l'écho du dialogue avec les clients dans le journal
serveur.port=27200
serveur.echo=true

lignes 3-4 : la configuration de la couche [dao], identique à celle de la version 5 : les tranches d'impôt sont lues dans le fichier texte [DataImpot.txt] ;
lignes 6-7 : le port d'écoute du serveur et l'écho du dialogue avec les clients dans le journal du serveur. Plutôt qu'une console d'administration (avec des commandes [start], [stop], [echo]…), nous avons préféré un fichier de configuration et l'arrêt par Ctrl-C, plus simples et plus proches de ce que font les serveurs actuels.

12.9.3.2. Le programme principal

Les options du serveur forment un enregistrement :

package impots.serveur;

// les options du serveur : port d'écoute et écho du dialogue dans le journal
public record OptionsServeur(int port, boolean echo) {
}

La classe [Main] du serveur est la suivante :

package impots.serveur;

import impots.dao.FileImpot;
import impots.dao.HardwiredImpot;
import impots.dao.IImpotDao;
import impots.dao.JsonImpot;
import impots.entites.ImpotException;
import impots.metier.ImpotMetier;
import java.io.IOException;
import java.io.Reader;
import java.nio.file.Files;
import java.nio.file.Path;
import java.util.Properties;
import org.springframework.context.support.GenericApplicationContext;

// le serveur TCP de calcul de l'impôt : configuration, intégration des couches, exécution
// appel : mvn exec:java (dans le dossier impots-serveur) ; arrêt par Ctrl-C
public class Main {

    public static void main(String[] args) {
        ServeurImpot serveur;
        try {
            // lecture de la configuration, dans le dossier courant
            Properties config = new Properties();
            try (Reader reader = Files.newBufferedReader(Path.of("serveur.properties"))) {
                config.load(reader);
            }
            String implementation = config.getProperty("dao.implementation", "HardwiredImpot");
            String fichier = config.getProperty("dao.fichier", "");
            int port = Integer.parseInt(config.getProperty("serveur.port", "27200"));
            boolean echo = Boolean.parseBoolean(config.getProperty("serveur.echo", "false"));

            // enregistrement des couches dans le conteneur Spring
            GenericApplicationContext contexte = new GenericApplicationContext();
            // la couche [dao] : l'implémentation est choisie par la configuration (comme dans la version 5)
            contexte.registerBean(IImpotDao.class, () -> switch (implementation) {
                case "HardwiredImpot" -> new HardwiredImpot();
                case "FileImpot" -> new FileImpot(fichier);
                case "JsonImpot" -> new JsonImpot(fichier);
                default -> throw new ImpotException(
                        "Implémentation [" + implementation + "] de la couche [dao] inconnue");
            });
            // la couche [metier] de la version 5
            contexte.registerBean(ImpotMetier.class);
            // la couche [serveur] : le conteneur passera à son constructeur la couche [metier]
            // et les options du serveur
            contexte.registerBean(OptionsServeur.class, () -> new OptionsServeur(port, echo));
            contexte.registerBean(ServeurImpot.class);

            // démarrage du conteneur : création des couches [dao], [metier] et [serveur]
            contexte.refresh();
            serveur = contexte.getBean(ServeurImpot.class);
        } catch (IOException | RuntimeException e) {
            // affichage de la chaîne des exceptions et arrêt
            IO.println("L'erreur suivante s'est produite à l'initialisation du serveur :");
            for (Throwable cause = e; cause != null; cause = cause.getCause()) {
                IO.println(cause.getClass().getSimpleName() + " : " + cause.getMessage());
            }
            System.exit(1);
            return;
        }

        // Ctrl-C : on demande l'arrêt du serveur, puis on attend la fin du thread principal
        Thread principal = Thread.currentThread();
        Runtime.getRuntime().addShutdownHook(new Thread(() -> {
            serveur.arreter();
            try {
                principal.join();
            } catch (InterruptedException e) {
                // on s'arrête de toute façon
            }
        }));
        // exécution du serveur jusqu'à l'arrêt demandé
        serveur.executer();
    }
}

On reconnaît le programme principal de la version 5 :

lignes 24-31 : la lecture de la configuration. Les valeurs sont des chaînes de caractères : le port et l'écho sont convertis, des valeurs par défaut étant prévues ;
lignes 34-44 : les couches [dao] et [metier] sont enregistrées dans le conteneur exactement comme dans la version 5 ;
lignes 47-48 : la nouveauté. Les options du serveur (port, écho) sont enregistrées sous la forme d'une fonction qui les construit, puis la couche [serveur] elle-même. Le constructeur de [ServeurImpot] attend un [IImpotMetier] et un [OptionsServeur] : le conteneur les lui fournira ;
ligne 51 : le démarrage du conteneur crée le serveur, ce qui entraîne la création de la couche [metier], qui entraîne celle de la couche [dao] ; c'est à ce moment que le fichier [DataImpot.txt] est lu. Une erreur (fichier absent, mal formé) est affichée et le programme s'arrête (lignes 53-61) ;
lignes 64-72 : Ctrl-C déclenche un crochet d'arrêt qui demande l'arrêt du serveur, puis attend la fin du thread principal, comme dans le serveur d'écho ;
ligne 74 : le serveur s'exécute jusqu'à ce que son arrêt soit demandé.

12.9.3.3. La couche [serveur]

La classe [ServeurImpot] est la suivante :

package impots.serveur;

import impots.metier.IImpotMetier;
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.io.PrintWriter;
import java.net.ServerSocket;
import java.net.Socket;
import java.net.SocketException;
import java.time.LocalTime;
import java.time.format.DateTimeFormatter;
import java.util.Set;
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.Executors;
import java.util.function.Consumer;

import static java.nio.charset.StandardCharsets.UTF_8;

// la couche [serveur] : elle rend accessible la couche [metier] par un protocole TCP à lignes de texte
public class ServeurImpot {

    // les réponses fixes du protocole
    private static final String BIENVENUE = "Bienvenue sur le serveur de calcul de l'impôt";
    private static final String AIDE = """
            Commandes acceptées
            1-aide
            2-impot marié(O/N) nbEnfants salaireAnnuel
            3-aurevoir""";
    private static final String AU_REVOIR = "Au revoir...";
    private static final String COMMANDE_INCORRECTE = "Commande non reconnue. Utilisez la commande aide.";
    private static final String CALCUL_INCORRECT = "Commande calcul incorrecte. Utilisez la commande aide.";
    private static final DateTimeFormatter HEURE = DateTimeFormatter.ofPattern("HH:mm:ss");

    // la couche [metier] et les options, reçues par le constructeur
    private final IImpotMetier metier;
    private final OptionsServeur options;
    // le service d'écoute et les connexions de service en cours
    private volatile ServerSocket ecoute;
    private final Set<Socket> connexions = ConcurrentHashMap.newKeySet();
    private volatile boolean arret = false;

    public ServeurImpot(IImpotMetier metier, OptionsServeur options) {
        this.metier = metier;
        this.options = options;
    }

    // exécution du serveur jusqu'à l'appel de [arreter]
    public void executer() {
        // un thread virtuel par client ; close() attend la fin de tous les services
        try (var ecoute = new ServerSocket(options.port());
             var services = Executors.newVirtualThreadPerTaskExecutor()) {
            this.ecoute = ecoute;
            journal("Serveur de calcul d'impôt lancé sur le port " + options.port());
            try {
                for (int numClient = 0; ; numClient++) {
                    // attente d'un client
                    Socket client = ecoute.accept();
                    connexions.add(client);
                    // il est servi par un thread virtuel : on retourne aussitôt attendre le client suivant
                    int numero = numClient;
                    services.submit(() -> servir(client, numero));
                }
            } catch (SocketException e) {
                // accept échoue lorsque [arreter] ferme le service d'écoute
                if (!arret) {
                    throw e;
                }
                journal("Arrêt du serveur demandé");
                // on ferme les connexions en cours : les services s'arrêtent
                for (Socket connexion : connexions) {
                    connexion.close();
                }
            }
        } catch (IOException e) {
            journal("L'erreur suivante s'est produite sur le serveur : " + e.getMessage());
        }
        journal("Serveur arrêté");
    }

    // demande d'arrêt du serveur (appelée par un autre thread)
    public void arreter() {
        arret = true;
        try {
            if (ecoute != null) {
                ecoute.close();
            }
        } catch (IOException e) {
            // le service d'écoute est fermé de toute façon
        }
    }

    // le service rendu à un client
    private void servir(Socket client, int numClient) {
        journal("Début du service au client " + numClient + " (" + client.getRemoteSocketAddress() + ")");
        try (client;
             var lecteur = new BufferedReader(new InputStreamReader(client.getInputStream(), UTF_8));
             var ecrivain = new PrintWriter(client.getOutputStream(), true, UTF_8)) {
            // envoi d'une réponse au client, avec écho éventuel dans le journal
            Consumer<String> ecrire = reponse -> {
                if (options.echo()) {
                    journal("---> client " + numClient + " : " + reponse);
                }
                ecrivain.println(reponse);
            };
            // message de bienvenue
            ecrire.accept(BIENVENUE);
            // boucle lecture demande / écriture réponse, jusqu'à la commande aurevoir
            String demande;
            while ((demande = lecteur.readLine()) != null) {
                if (options.echo()) {
                    journal("<--- client " + numClient + " : " + demande);
                }
                // la demande décomposée en champs
                String[] champs = demande.strip().toLowerCase().split("\\s+");
                if (champs.length == 1 && champs[0].equals("aurevoir")) {
                    ecrire.accept(AU_REVOIR);
                    break;
                }
                // la réponse selon la commande
                String reponse = switch (champs[0]) {
                    case "aide" -> champs.length == 1 ? AIDE : COMMANDE_INCORRECTE;
                    case "impot" -> calculerImpot(champs);
                    default -> COMMANDE_INCORRECTE;
                };
                ecrire.accept(reponse);
            }
        } catch (IOException e) {
            if (arret) {
                journal("Service au client " + numClient + " interrompu par l'arrêt du serveur");
            } else {
                journal("L'erreur suivante s'est produite lors du service au client " + numClient + " : "
                        + e.getMessage());
            }
        } finally {
            connexions.remove(client);
            journal("Fin du service au client " + numClient);
        }
    }

    // la commande impot marié nbEnfants salaireAnnuel : rend l'impôt ou un message d'erreur
    private String calculerImpot(String[] champs) {
        // il faut 4 champs : impot, o ou n, deux entiers
        if (champs.length != 4 || !champs[1].matches("[on]")
                || !champs[2].matches("-?\\d{1,9}") || !champs[3].matches("-?\\d{1,9}")) {
            return CALCUL_INCORRECT;
        }
        try {
            // le calcul est confié à la couche [metier]
            int impot = metier.calculerImpot(champs[1].equals("o"), Integer.parseInt(champs[2]),
                    Integer.parseInt(champs[3]));
            return String.valueOf(impot);
        } catch (RuntimeException e) {
            // le message de l'exception, sur une seule ligne : le protocole est à lignes de texte
            return e.getMessage().replaceAll("\\R", " ");
        }
    }

    // le journal du serveur : chaque ligne est horodatée
    private static void journal(String message) {
        IO.println(LocalTime.now().format(HEURE) + " " + message);
    }
}

lignes 24-32 : les réponses fixes du protocole. La réponse à la commande [aide], écrite dans un bloc de texte, contient des fins de ligne : elle sera reçue par le client sous la forme de quatre lignes ;
lignes 43-46 : la classe reçoit la couche [metier] et ses options par son constructeur. Elle ne connaît de la couche [metier] que son interface [IImpotMetier] et ignore tout de la couche [dao] ;
lignes 49-79 : la boucle d'attente des clients. C'est celle du serveur d'écho de la première partie : chaque client est servi par un thread virtuel que l'on n'attend pas (ligne 62), la fermeture du service d'écoute termine l'attente d'un client (ligne 64), on ferme alors les connexions en cours (lignes 71-73) et l'on attend la fin des services avant de s'arrêter (fermeture de l'[ExecutorService] à la sortie du [try]). Aucun thread du système n'est immobilisé par un client qui réfléchit ;
ligne 53 : le service d'écoute est mémorisé dans un champ, pour que la méthode [arreter] puisse le fermer ;
lignes 82-91 : la méthode [arreter], appelée par le crochet d'arrêt dans un autre thread : c'est pourquoi les champs [ecoute] et [arret] sont déclarés [volatile] (lignes 39 et 41) ;
lignes 94-139 : le service rendu à un client :
- lignes 100-105 : une lambda, implémentant l'interface fonctionnelle [Consumer<String>], qui envoie une réponse au client, et l'écrit aussi dans le journal si l'écho est activé ;
- ligne 107 : une fois le client connecté, le serveur lui envoie le message de bienvenue ;
- ligne 110 : la boucle de lecture des commandes, qui s'arrête si le client ferme la connexion ou si le serveur est arrêté ;
- ligne 115 : la commande, mise en minuscules, est décomposée en champs. L'expression régulière [\s+] (un ou plusieurs espaces) évite les champs vides dus à plusieurs espaces consécutifs ;
- lignes 116-119 : la commande est formée du seul mot [aurevoir]. Le serveur répond et sort de la boucle : la connexion est fermée à la sortie du [try] avec ressources ;
- lignes 121-125 : une expression [switch] choisit la réponse selon le premier champ : [aide] seul, une commande commençant par [impot], ou toute autre commande. Une ligne vide reçoit la réponse [Commande non reconnue] ;
lignes 142-157 : le calcul de l'impôt :
- lignes 144-147 : la commande doit avoir quatre champs, le deuxième valant [o] ou [n] et les deux derniers étant des entiers (de un à neuf chiffres, éventuellement précédés d'un signe moins : [parseInt] ne pourra pas échouer) ;
- lignes 150-152 : le calcul est demandé à la couche [metier]. Une même instance de [ImpotMetier] sert tous les clients, éventuellement en même temps, depuis des threads différents : c'est possible parce que cette classe ne modifie aucune donnée après sa construction (sa liste de tranches n'est que lue) ;
- lignes 153-156 : si la couche [metier] lance une exception (par exemple pour un nombre d'enfants négatif), son message est renvoyé au client. Ce message pourrait contenir des fins de ligne : on les remplace par des espaces ([\R] désigne toute fin de ligne), car le protocole impose une réponse sur une ligne ;
lignes 160-162 : le journal du serveur, sur la console : chaque ligne est précédée de l'heure, ce qui permettra de voir le déroulement des services simultanés. [IO.println] peut être appelée sans précaution depuis plusieurs threads : ses écritures ne se mélangent pas.

12.9.4. Le client du serveur de calcul de l'impôt

Le client reprend l'interface console de la version 5, la classe [impots.ui.Dialogue], sans la modifier.

12.9.4.1. La couche [metier] du client

La couche [ui] dialogue avec une couche [metier] dont elle ne connaît que l'interface [IImpotMetier] de la version 5, réduite à une méthode : [int calculerImpot(boolean marie, int nbEnfants, int salaire)].

Il suffit donc de lui fournir une autre implémentation de cette interface, qui, au lieu de calculer l'impôt, le demande au serveur. C'est la classe [ImpotMetierTcp] :

package impots.client;

import impots.entites.ImpotException;
import impots.metier.IImpotMetier;
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.io.PrintWriter;
import java.net.Socket;

import static java.nio.charset.StandardCharsets.UTF_8;

// la couche [metier] du client : elle implémente IImpotMetier en déléguant le calcul au serveur TCP
public class ImpotMetierTcp implements IImpotMetier, AutoCloseable {

    // la connexion au serveur, ouverte pour toute la durée de vie de l'objet
    private final Socket client;
    private final BufferedReader lecteur;
    private final PrintWriter ecrivain;

    // connexion au serveur (machine, port)
    public ImpotMetierTcp(String machine, int port) {
        try {
            client = new Socket(machine, port);
            lecteur = new BufferedReader(new InputStreamReader(client.getInputStream(), UTF_8));
            ecrivain = new PrintWriter(client.getOutputStream(), true, UTF_8);
            // le serveur parle le premier : on lit (et on ignore) son message de bienvenue
            lireReponse();
        } catch (IOException e) {
            throw new ImpotException("Impossible de se connecter au serveur (" + machine + ", " + port + ")",
                    e, 21);
        }
    }

    // calcul de l'impôt : une demande, une réponse
    @Override
    public int calculerImpot(boolean marie, int nbEnfants, int salaire) {
        String reponse;
        try {
            ecrivain.println("impot " + (marie ? "o" : "n") + " " + nbEnfants + " " + salaire);
            reponse = lireReponse();
        } catch (IOException e) {
            throw new ImpotException("Erreur de communication avec le serveur", e, 22);
        }
        // le serveur rend l'impôt, ou un message d'erreur
        try {
            return Integer.parseInt(reponse);
        } catch (NumberFormatException e) {
            throw new ImpotException("Le serveur a répondu : " + reponse, 23);
        }
    }

    // lecture d'une ligne de réponse ; null signifie que le serveur a fermé la connexion
    private String lireReponse() throws IOException {
        String reponse = lecteur.readLine();
        if (reponse == null) {
            throw new ImpotException("Le serveur a fermé la connexion", 24);
        }
        return reponse;
    }

    // fin de la connexion : on prend congé du serveur, s'il est encore là
    @Override
    public void close() {
        try (client) {
            ecrivain.println("aurevoir");
            lecteur.readLine();
        } catch (IOException e) {
            // la connexion est déjà coupée : il n'y a plus rien à faire
        }
    }
}

ligne 14 : la classe implémente [IImpotMetier]. Elle implémente aussi [AutoCloseable] : elle détient une connexion réseau, qu'il faudra fermer ;
lignes 17-19 : la connexion au serveur et ses flux de lecture et d'écriture. Nous ouvrons une seule connexion, utilisée pour tous les calculs d'une session, plutôt qu'une connexion par calcul : c'est plus économe, et le serveur voit un client par session de l'utilisateur ;
lignes 22-33 : le constructeur se connecte au serveur et lit son message de bienvenue (ligne 28). Une erreur de connexion est encapsulée dans une [ImpotException], l'exception de l'application, avec le code 21 ;
lignes 37-51 : le calcul de l'impôt. La commande [impot o 2 60000] est envoyée au serveur (ligne 40) et sa réponse lue. Si celle-ci est un entier, c'est l'impôt ; sinon c'est un message d'erreur du serveur, qui est transmis dans une [ImpotException] (ligne 49) : convertir directement la réponse en entier provoquerait, pour un message d'erreur, une exception de conversion qui masquerait la vraie cause de l'erreur ;
lignes 54-60 : [readLine] rend [null] lorsque le serveur a fermé la connexion : on lance alors une [ImpotException] ;
lignes 64-71 : la fin de la connexion. Le client prend congé du serveur avec la commande [aurevoir], lit sa réponse, puis ferme la connexion ([try (client)]). Si le serveur a déjà coupé la connexion, l'[IOException] qui en résulte est ignorée.

Cette classe utilise les méthodes bloquantes de [Socket], comme tous les clients de ce chapitre : l'interface [IImpotMetier] de la version 5 est synchrone ([calculerImpot] rend un [int], pas un [CompletableFuture<Integer>]), et, pour un programme console qui ne sert qu'un utilisateur, c'est parfaitement adapté : le thread principal n'a rien d'autre à faire qu'attendre la réponse. Si plusieurs calculs devaient être menés en parallèle, on appellerait [calculerImpot] depuis plusieurs threads virtuels (avec une connexion par thread, car [ImpotMetierTcp] n'est pas prévue pour être utilisée par plusieurs threads à la fois).

12.9.4.2. Le programme principal du client

Le module [impots-client] dépend de la couche [metier] et de la couche [ui] de la version 5 :

    <dependencies>
        <!-- l'interface de la couche [metier] et la couche [ui] de la version 5 -->
        <dependency>
            <groupId>exemples.impots</groupId>
            <artifactId>impots-metier</artifactId>
        </dependency>
        <dependency>
            <groupId>exemples.impots</groupId>
            <artifactId>impots-ui</artifactId>
        </dependency>
        <!-- le conteneur d'injection de dépendances de Spring -->
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-context</artifactId>
        </dependency>
    </dependencies>

Le module [impots-ui] de la version 5 contient une application (sa classe [Main]) ; on peut néanmoins l'utiliser comme une bibliothèque, pour sa classe publique [impots.ui.Dialogue]. La classe [Main] du client est la suivante :

package impots.client;

import impots.metier.IImpotMetier;
import impots.ui.Dialogue;
import org.springframework.context.support.GenericApplicationContext;

// le client console du serveur de calcul de l'impôt
// appel : mvn exec:java [-Dexec.args="machine port"]   (par défaut : localhost 27200)
public class Main {

    public static void main(String[] args) {
        String machine = args.length > 0 ? args[0] : "localhost";
        int port = args.length > 1 ? Integer.parseInt(args[1]) : 27200;

        // le conteneur Spring est fermé à la sortie du try : il ferme alors les objets AutoCloseable
        // qu'il a créés
        try (var contexte = new GenericApplicationContext()) {
            // la couche [metier] est désormais un client TCP du serveur de calcul de l'impôt
            contexte.registerBean(IImpotMetier.class, () -> new ImpotMetierTcp(machine, port));
            // démarrage du conteneur : création de la couche [metier], donc connexion au serveur
            contexte.refresh();
            IImpotMetier metier = contexte.getBean(IImpotMetier.class);
            IO.println("Connecté au serveur de calcul de l'impôt (" + machine + ", " + port + ")");
            // la couche [ui] de la version 5, inchangée
            Dialogue.run(metier);
        } catch (RuntimeException e) {
            // erreur de connexion ou de communication : affichage de la chaîne des exceptions
            Dialogue.afficherErreur(e);
        }
    }
}

lignes 12-13 : la machine et le port du serveur, passés en arguments, avec des valeurs par défaut ;
ligne 17 : le conteneur Spring est déclaré dans un [try] avec ressources. Lorsqu'il est fermé, à la fin du programme, il appelle la méthode [close] des objets [AutoCloseable] qu'il a créés : la connexion de [ImpotMetierTcp] sera fermée proprement ;
ligne 19 : la couche [metier] enregistrée dans le conteneur est maintenant [ImpotMetierTcp]. Son constructeur attendant deux paramètres que le conteneur ne connaît pas, on lui fournit une fonction de fabrication ;
ligne 21 : le démarrage du conteneur crée la couche [metier], donc se connecte au serveur ;
ligne 25 : le dialogue de la version 5, inchangé. La couche [ui] ignore que l'impôt est calculé par un serveur distant ;
lignes 26-29 : une erreur de connexion ou de communication est affichée par la méthode [afficherErreur] de la version 5.

12.9.5. Exécutions

Le serveur est lancé dans une fenêtre de commandes, depuis le dossier [impots-serveur], par [mvn compile exec:java], les modules de la version 5 ayant été installés comme indiqué plus haut. Dans une autre fenêtre, le client est lancé depuis le dossier [impots-client] :

> mvn compile exec:java
Connecté au serveur de calcul de l'impôt (localhost, 27200)
Paramètres du calcul de l'impôt au format : Marié (o/n) NbEnfants Salaire ou rien pour arrêter : o 2 60000
Impôt=4282 euros
Paramètres du calcul de l'impôt au format : Marié (o/n) NbEnfants Salaire ou rien pour arrêter : o 3 60000
Impôt=2959 euros
Paramètres du calcul de l'impôt au format : Marié (o/n) NbEnfants Salaire ou rien pour arrêter : n 0 60000
Impôt=11519 euros
Paramètres du calcul de l'impôt au format : Marié (o/n) NbEnfants Salaire ou rien pour arrêter : x 2 60000
syntaxe : Marié NbEnfants Salaire
Marié : o pour marié, n pour non marié
NbEnfants : nombre d'enfants
Salaire : salaire annuel en euros
Argument Marié incorrect : tapez o ou n
Paramètres du calcul de l'impôt au format : Marié (o/n) NbEnfants Salaire ou rien pour arrêter : o deux 60000
syntaxe : Marié NbEnfants Salaire
Marié : o pour marié, n pour non marié
NbEnfants : nombre d'enfants
Salaire : salaire annuel en euros
Argument NbEnfants incorrect : tapez un entier positif ou nul
Paramètres du calcul de l'impôt au format : Marié (o/n) NbEnfants Salaire ou rien pour arrêter : o 2
syntaxe : Marié NbEnfants Salaire
Marié : o pour marié, n pour non marié
NbEnfants : nombre d'enfants
Salaire : salaire annuel en euros
Paramètres du calcul de l'impôt au format : Marié (o/n) NbEnfants Salaire ou rien pour arrêter :

Le dialogue est exactement celui de la version 5 : on retrouve les valeurs de contrôle (4282 et 2959 pour une personne mariée ayant 2 ou 3 enfants et un salaire de 60 000 euros, 11519 pour une personne non mariée sans enfant), et les mêmes messages pour les saisies incorrectes. Ces derniers sont produits par la couche [ui] du client, qui vérifie les saisies avant de demander le calcul : les saisies incorrectes n'atteignent jamais le serveur.

Lançons maintenant deux clients A et B dans deux fenêtres, B démarrant pendant que A est encore connecté. Chacun fait deux calculs. Dans la fenêtre du client A :

> mvn compile exec:java
Connecté au serveur de calcul de l'impôt (localhost, 27200)
Paramètres du calcul de l'impôt au format : Marié (o/n) NbEnfants Salaire ou rien pour arrêter : o 2 60000
Impôt=4282 euros
Paramètres du calcul de l'impôt au format : Marié (o/n) NbEnfants Salaire ou rien pour arrêter : n 2 40000
Impôt=2854 euros
Paramètres du calcul de l'impôt au format : Marié (o/n) NbEnfants Salaire ou rien pour arrêter :

Dans la fenêtre du client B :

> mvn compile exec:java
Connecté au serveur de calcul de l'impôt (localhost, 27200)
Paramètres du calcul de l'impôt au format : Marié (o/n) NbEnfants Salaire ou rien pour arrêter : o 3 60000
Impôt=2959 euros
Paramètres du calcul de l'impôt au format : Marié (o/n) NbEnfants Salaire ou rien pour arrêter : n 0 60000
Impôt=11519 euros
Paramètres du calcul de l'impôt au format : Marié (o/n) NbEnfants Salaire ou rien pour arrêter :

Pour voir les réponses du serveur à des commandes incorrectes, il faut un client qui envoie les commandes telles qu'elles sont tapées : le client TCP générique de la première partie convient parfaitement. Le serveur parle le premier, ce que ce client sait gérer :

> java Internet06.java localhost 27200
Tapez vos commandes (bye pour arrêter) :
<-- Bienvenue sur le serveur de calcul de l'impôt
aide
<-- Commandes acceptées
<-- 1-aide
<-- 2-impot marié(O/N) nbEnfants salaireAnnuel
<-- 3-aurevoir
impot o 2 60000
<-- 4282
IMPOT N 0 60000
<-- 11519
impot x 2 60000
<-- Commande calcul incorrecte. Utilisez la commande aide.
impot o 2
<-- Commande calcul incorrecte. Utilisez la commande aide.
impot o -2 60000
<-- nbEnfants (-2) doit être positif ou nul
calcul
<-- Commande non reconnue. Utilisez la commande aide.
aurevoir
<-- Au revoir...
[le serveur a fermé la connexion]

ligne 3 : le message de bienvenue, arrivé dès la connexion ;
lignes 5-8 : la réponse à la commande [aide], sur quatre lignes ;
lignes 11-12 : la casse de la commande est ignorée ;
lignes 13-16 : deux commandes de calcul mal formées ;
lignes 17-18 : la commande est bien formée, mais la couche [metier] refuse un nombre d'enfants négatif ; le message de son exception a été renvoyé ;
lignes 19-20 : une commande inconnue ;
lignes 21-23 : après la commande [aurevoir], le serveur a fermé la connexion, et le client s'est arrêté de lui-même.

Le serveur est ensuite arrêté par Ctrl-C, pendant qu'un dernier client est connecté. Celui-ci a fait un premier calcul avant l'arrêt et tape sa seconde demande après :

> mvn compile exec:java
Connecté au serveur de calcul de l'impôt (localhost, 27200)
Paramètres du calcul de l'impôt au format : Marié (o/n) NbEnfants Salaire ou rien pour arrêter : o 2 60000
Impôt=4282 euros
Paramètres du calcul de l'impôt au format : Marié (o/n) NbEnfants Salaire ou rien pour arrêter : o 3 60000
Chaîne des exceptions :
----------------------------------------
impots.entites.ImpotException: Le serveur a fermé la connexion
----------------------------------------

La lecture de la réponse a rendu [null] : la couche [metier] a lancé une [ImpotException], que le programme principal a affichée. Une fois le serveur arrêté, un nouveau client ne peut plus se connecter :

> mvn compile exec:java
oct. 03, 2026 7:43:33 PM org.springframework.context.support.GenericApplicationContext refresh
AVERTISSEMENT: Exception encountered during context initialization - cancelling refresh attempt: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'impots.metier.IImpotMetier': Instantiation of supplied bean failed
Chaîne des exceptions :
----------------------------------------
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'impots.metier.IImpotMetier': Instantiation of supplied bean failed
----------------------------------------
impots.entites.ImpotException: Impossible de se connecter au serveur (localhost, 27200)
----------------------------------------
java.net.ConnectException: Connection refused
----------------------------------------

Le constructeur de [ImpotMetierTcp] a lancé une [ImpotException], dont la cause est la [ConnectException] du socket. Comme il a été appelé par le conteneur Spring pendant son démarrage, celui-ci l'a encapsulée dans une [BeanCreationException], en tête de la chaîne des exceptions. Les deux premières lignes sont un avertissement écrit par Spring dans son journal (sur la sortie d'erreur, au format du journal standard de Java, en français puisque la machine est configurée en français) : le démarrage du conteneur a échoué.

Voici enfin le journal du serveur pour l'ensemble de ces essais :

> mvn compile exec:java
19:42:50 Serveur de calcul d'impôt lancé sur le port 27200
19:42:52 Début du service au client 0 (/127.0.0.1:44044)
19:42:52 ---> client 0 : Bienvenue sur le serveur de calcul de l'impôt
19:42:54 <--- client 0 : impot o 2 60000
19:42:54 ---> client 0 : 4282
19:42:55 <--- client 0 : impot o 3 60000
19:42:55 ---> client 0 : 2959
19:42:56 <--- client 0 : impot n 0 60000
19:42:56 ---> client 0 : 11519
19:42:58 <--- client 0 : aurevoir
19:42:58 ---> client 0 : Au revoir...
19:42:58 Fin du service au client 0
19:43:00 Début du service au client 1 (/127.0.0.1:54654)
19:43:00 ---> client 1 : Bienvenue sur le serveur de calcul de l'impôt
19:43:02 <--- client 1 : impot o 2 60000
19:43:02 ---> client 1 : 4282
19:43:03 Début du service au client 2 (/127.0.0.1:54662)
19:43:03 ---> client 2 : Bienvenue sur le serveur de calcul de l'impôt
19:43:05 <--- client 2 : impot o 3 60000
19:43:05 ---> client 2 : 2959
19:43:05 <--- client 1 : impot n 2 40000
19:43:05 ---> client 1 : 2854
19:43:08 <--- client 2 : impot n 0 60000
19:43:08 ---> client 2 : 11519
19:43:08 <--- client 1 : aurevoir
19:43:08 ---> client 1 : Au revoir...
19:43:08 Fin du service au client 1
19:43:11 <--- client 2 : aurevoir
19:43:11 ---> client 2 : Au revoir...
19:43:11 Fin du service au client 2
19:43:13 Début du service au client 3 (/127.0.0.1:45664)
19:43:13 ---> client 3 : Bienvenue sur le serveur de calcul de l'impôt
19:43:14 <--- client 3 : aide
19:43:14 ---> client 3 : Commandes acceptées
1-aide
2-impot marié(O/N) nbEnfants salaireAnnuel
3-aurevoir
19:43:15 <--- client 3 : impot o 2 60000
19:43:15 ---> client 3 : 4282
19:43:16 <--- client 3 : IMPOT N 0 60000
19:43:16 ---> client 3 : 11519
19:43:17 <--- client 3 : impot x 2 60000
19:43:17 ---> client 3 : Commande calcul incorrecte. Utilisez la commande aide.
19:43:18 <--- client 3 : impot o 2
19:43:18 ---> client 3 : Commande calcul incorrecte. Utilisez la commande aide.
19:43:19 <--- client 3 : impot o -2 60000
19:43:19 ---> client 3 : nbEnfants (-2) doit être positif ou nul
19:43:20 <--- client 3 : calcul
19:43:20 ---> client 3 : Commande non reconnue. Utilisez la commande aide.
19:43:21 <--- client 3 : aurevoir
19:43:21 ---> client 3 : Au revoir...
19:43:21 Fin du service au client 3
19:43:25 Début du service au client 4 (/127.0.0.1:43690)
19:43:25 ---> client 4 : Bienvenue sur le serveur de calcul de l'impôt
19:43:27 <--- client 4 : impot o 2 60000
19:43:27 ---> client 4 : 4282
19:43:30 Arrêt du serveur demandé
19:43:30 Service au client 4 interrompu par l'arrêt du serveur
19:43:30 Fin du service au client 4
19:43:30 Serveur arrêté

lignes 3-13 : le client de la première exécution. Avec l'écho, on voit toutes les commandes reçues et toutes les réponses envoyées. On remarque la commande [aurevoir] (ligne 11), envoyée par la méthode [close] de [ImpotMetierTcp] lorsque le conteneur Spring a été fermé : le dialogue a été clos proprement ;
lignes 14-31 : les clients A (client 1) et B (client 2). Le client 2 est arrivé (ligne 18) alors que le client 1 était encore servi, et leurs demandes ont été traitées en alternance, au fur et à mesure de leur arrivée : le serveur sert bien plusieurs clients simultanément ;
lignes 32-53 : la session du client TCP générique ;
lignes 54-61 : le dernier client, servi au moment de l'arrêt. Ctrl-C a fermé le service d'écoute, ce qui a terminé l'attente d'un nouveau client ; le serveur a fermé la connexion du client 4, dont le thread de service, qui attendait une commande, s'est terminé, puis le serveur s'est arrêté.

12.9.6. Conclusion

De nouveau, nous avons pu réutiliser du code existant sans le modifier : les couches [dao] et [metier] de la version 5 côté serveur, la couche [ui] côté client, utilisées comme des bibliothèques Maven. Cela a été rendu possible par l'utilisation systématique d'interfaces et par l'injection de dépendances : pour distribuer l'application sur deux machines, il a suffi d'ajouter une couche [serveur] au-dessus de la couche [metier] et de fournir à la couche [ui] une autre implémentation de [IImpotMetier]. Si la version 1 avait mêlé le calcul de l'impôt et le dialogue avec l'utilisateur dans le même programme, rien de tout cela n'aurait été réutilisable. On notera que la couche [ui] n'a aucune connaissance du fait que c'est un serveur distant qui calcule le montant de l'impôt.

Notre protocole maison a cependant ses limites : il faut écrire le serveur, gérer les connexions, analyser les commandes, convertir les réponses, et un client écrit dans un autre langage devrait connaître ce protocole particulier. La version 9, au chapitre suivant, remplacera le serveur TCP par un service web : le protocole sera HTTP, les données seront échangées en JSON, et le client utilisera [HttpClient].

12.10. Conclusion

Ce chapitre a présenté la programmation Internet en Java, en partant des fondations pour arriver aux classes de haut niveau :

la première partie a rappelé le fonctionnement des protocoles de l'Internet (IP, TCP, UDP, DNS) et des protocoles d'application à lignes de texte (HTTP, SMTP, POP, FTP), puis présenté les classes [InetAddress] et [NetworkInterface], et les classes [Socket] et [ServerSocket]. Avec elles, et avec un thread virtuel par client, nous avons écrit des serveurs qui servent plusieurs clients simultanément, des clients TCP génériques, et un client web qui parlait HTTP « à la main » ;
la seconde partie a présenté les classes spécialisées dans un protocole. Pour HTTP, la classe [HttpClient] de Java 11 remplace [URL] et [HttpURLConnection] : elle fait en quelques instructions ce que notre client TCP faisait en cinquante lignes, gère les redirections, les formulaires, les délais, l'annulation et les requêtes asynchrones, et doit être réutilisée d'une requête à l'autre ; associée à Jackson, elle échange des objets au format JSON. Pour SMTP, la bibliothèque Jakarta Mail construit les messages MIME et mène le dialogue avec le serveur ;
l'application exemple est devenue une application client / serveur, sans modification de ses couches existantes.

Les threads virtuels, vus au chapitre 8, ont trouvé ici leur principal champ d'application : un serveur sert un grand nombre de clients avec quelques threads du système, tout en gardant le code simple d'un thread par client. Écrire un serveur TCP et inventer son protocole reste toutefois l'exception : la plupart des applications réparties communiquent aujourd'hui par HTTP, au moyen de services web qui échangent des données JSON. C'est l'objet du chapitre suivant.