Homa divise par treize la latence des messages courts que TCP inflige au datacenter
Le 1er octobre 2026, John Ousterhout, professeur émérite de Stanford, défend Homa, un protocole de transport à messages dont la latence p99 sur les messages courts tombe à 92 microsecondes contre 1,2 milliseconde pour TCP sur un réseau à 100 Gbit/s. Évaluez-le sur les liaisons datacenter où chaque milliseconde immobilise un GPU, mais mesurez le coût d’adoption avant de remplacer quoi que ce soit.
1er octobre 2026. John Ousterhout, professeur émérite de Stanford et créateur de Tcl/Tk comme du consensus Raft, défend publiquement Homa, un protocole de transport pensé pour remplacer TCP dans les datacenters. 92 microsecondes. C’est la latence au 99e centile de Homa sur les messages courts, contre 1,2 milliseconde pour TCP. Mars 2026. Le protocole a été rétroporté sur Red Hat Enterprise Linux 8 et 9.5. Pourquoi c’est important : TCP transporte presque tout le Web, mais il a été conçu pour des flots de paquets, pas pour les rafales de messages courts qui font tourner l’IA — et dans un datacenter, une milliseconde perdue, c’est un GPU qui dort.
Ce que Homa change par rapport à TCP
TCP est un protocole à flot d’octets : les messages sont sérialisés dans un flux continu, sans différenciation ni priorité. Le récepteur ne distingue pas un message court d’un long, et le contrôle de congestion appartient à l’émetteur, qui doit deviner le bon débit à partir de l’arrivée des accusés de réception. Cette mécanique, conçue par Vint Cerf et ses pairs pour civiliser des réseaux hétérogènes, devient un goulot dès qu’on parle de latence.
Homa inverse les rôles. C’est un protocole à messages, proche d’un appel de procédure distante (RPC) : la longueur de chaque message est explicite. Le récepteur pilote le contrôle de congestion — le premier paquet reçu annonce la quantité de données à venir, et le récepteur planifie ensuite quand chaque paquet doit être émis. Cette inversion permet d’appliquer un algorithme de SRPT (shortest-remaining-processing-time) : les messages courts passent devant les longs, au lieu de faire la queue derrière eux dans un flux indistinct.
Le résultat se mesure sur les deux extrêmes. Sur un réseau à 100 Gbit/s chargé à 80 %, le p99 de Homa pour les messages courts tombe à 92 microsecondes, soit treize fois moins que les 1,2 milliseconde de TCP. Même sur les messages les plus longs, Homa reste deux fois plus rapide, selon Ousterhout.
Pourquoi maintenant : les GPU n’attendent pas
Le calendrier de ce plaidoyer n’a rien d’un hasard. Les laboratoires qui entraînent de grands modèles déplacent sur le réseau des gradients de poids, des poids de modèle, des entrées de cache KV et des checkpoints — de gros transferts qui doivent désormais partager la bande passante avec des rafales courtes venues des agents et des tâches de contrôle, comme la coordination de métadonnées ou les recherches de cache.
« Pour ces charges, ce qui compte vraiment, c’est la latence », explique Ousterhout. Même une milliseconde met un GPU coûteux en attente. C’est la phrase qui transforme un débat académique sur les protocoles en un problème de facture : quand une grappe de plusieurs milliers de GPU perd une fraction de seconde à chaque synchronisation, le coût se chiffre en argent, pas en abstractions.
Homa n’est pas le premier à contourner TCP pour ce motif. Le monde des bases de données utilise DPDK pour court-circuiter la pile réseau et accélérer les requêtes. Le stockage est passé à NVMe-oF sur RDMA ou Fibre Channel. Le Web, lui, a adopté QUIC, devenu la base d’HTTP/3, pour échapper au head-of-line blocking de TCP. AWS propose son Scalable Reliable Datagram (SRD). Homa s’inscrit dans cette lignée, mais avec une ambition plus large : remplacer TCP comme protocole de transport par défaut du datacenter.
Un déploiement volontairement progressif
L’argument le plus pragmatique d’Ousterhout tient en une phrase : Homa n’exige pas de tout casser. On compile le module depuis son dépôt GitHub, on l’installe dans le noyau Linux des clients et des serveurs, sans redémarrage. « Homa fonctionne côte à côte avec TCP, donc vous pouvez migrer vos applications progressivement », écrit-il — et il ajoute que faire tourner Homa accélère même les applications TCP restantes.
Le protocole n’est pas né la semaine dernière. Il trouve son origine dans la thèse de doctorat de Behnam Montazeri, publiée en 2019 et aujourd’hui ingénieur chez Google. Ousterhout, désormais à la retraite de l’enseignement, a fait de la diffusion de Homa sa « mission de vie ». Il rédige actuellement un document de standardisation IETF et travaille à l’intégration du protocole dans le noyau Linux ; le rétroportage vers RHEL 8 et 9.5 en mars 2026 montre que l’effort a dépassé le stade du laboratoire. Il accompagne aussi une grande société de services financiers dans un prototype.
Les sceptiques ont un point
Tout le monde ne partage pas l’enthousiasme. L’architecte réseau Ivan Pepelnjak a publié dès 2023 un papier au vitriol contre Homa, contestant la façon dont Ousterhout caractérise les performances de TCP et résumant Homa à « une solution qui cherche un problème ». Le débat n’est pas tranché, et il est sain qu’il ne le soit pas : remplacer un protocole éprouvé depuis quatre décennies exige une charge de la preuve élevée.
La réalité est plus nuancée que le plaidoyer. TCP reste le champion du Web et du cloud, et rien n’indique qu’il disparaîtra du périmètre Internet. Le vrai terrain de Homa, c’est le réseau interne du datacenter, là où l’opérateur maîtrise les deux bouts de la liaison et peut déployer un module noyau sans négocier avec des milliers de pairs. C’est précisément le périmètre que les équipes d’infrastructure contrôlent déjà.
Verdict
Si vous exploitez une grappe de GPU pour l’entraînement ou l’inférence d’IA, Homa mérite un banc d’essai sur vos liaisons internes : le gain de treize fois sur le p99 des messages courts se traduit directement en temps GPU récupéré, et le déploiement côte à côte avec TCP limite le risque d’adoption. Si votre datacenter est majoritairement du trafic Web ou de gros transferts, la priorité reste ailleurs — QUIC, DPDK ou NVMe-oF traitent déjà leurs goulots respectifs, et Homa ne changera pas grand-chose à vos métriques. Dans tous les cas, ne remplacez pas TCP sur la foi d’un graphique : mesurez la latence p99 de vos propres charges, sur votre propre topologie, avant de laisser un protocole expérimental porter du trafic de production. Le protocole a un argument solide — il lui reste à gagner le droit de le prouver chez vous.