Zero-Stack Loopback : Accélérer l'entrée réseau des microservices avec eBPF Sockmaps

Dans l’ère moderne de l’infrastructure cloud-native, l’architecture microservices est devenue la norme pour construire des applications évolutives. En décomposant des applications monolithiques en services plus petits et découplés, les équipes d’ingénierie ont déployé une agilité et une vitesse de déploiement sans précédent. Cependant, cette architecture distribuée introduit un nouveau défi redoutable : la latence réseau.

Lorsqu’une seule requête utilisateur nécessite la communication d’une demi-douzaine de microservices internes avant de renvoyer une réponse, la surcharge réseau cumulative peut gravement dégrader les performances de l’application. Pour y remédier, les systèmes d’orchestration comme Kubernetes programment fréquemment des pods très communicants sur le même hôte physique. Bien que la co-localisation des services élimine la latence des sauts physiques du réseau, elle expose un autre goulot d’étranglement caché — la pile réseau du noyau Linux elle-même.

Même lorsque les microservices résident sur la même machine, leurs communications ont historiquement dû traverser la pile TCP/IP complète de Linux. Cet article explore comment l’accélération eBPF sockmap utilise la redirection de paquets au niveau des sockets pour exécuter une déviation de la pile réseau Linux pour ce trafic local, réduisant la latence et récupérant des cycles CPU autrement consacrés à re-deriver des garanties que la mémoire locale fournit déjà.

---

L’illusion Loopback : la taxe cachée du réseau local

Pour comprendre l’impact de l’accélération des sockets eBPF, il est utile de suivre d’abord le parcours d’un paquet de données dans un environnement Linux traditionnel.

Lorsque Microservice A (le client) envoie des données à Microservice B (le serveur) s’exécutant sur le même nœud Kubernetes, l’application suppose qu’elle écrit dans un simple descripteur de socket. Cependant, sous cette abstraction, le noyau traite ce trafic local de manière remarquablement similaire au trafic destiné à un serveur de l’autre côté de la planète.

Lorsque Microservice A appelle sendmsg(), la séquence suivante se produit approximativement :

1. Transition utilisateur-espace vers espace noyau. L’application intercepte dans le noyau, entraînant un changement de contexte.
2. Allocation du buffer socket. Le noyau alloue un sk_buff pour contenir la charge utile.
3. Traitement de la couche TCP. La pile TCP applique des numéros de séquence, des sommes de contrôle, et la gestion de congestion — tout cela inutile pour un transfert qui ne quitte jamais la mémoire de l’hôte.
4. Traitement de la couche IP. Les en-têtes IP sont ajoutés et la table de routage locale est consultée.
5. Netfilter / iptables. Le paquet est évalué selon chaque hook Netfilter applicable et règle iptables.
6. Contrôle du trafic (qdisc). Le paquet passe par la couche de file d’attente.
7. Dispositif Loopback (lo). Le paquet atteint le pilote loopback virtuel.
8. Le voyage de retour. Le pilote renvoie le paquet dans la pile : décapsulation, second passage par Netfilter, et réassemblage TCP avant qu’il ne atterrisse dans le buffer de réception de Microservice B.
9. Transition espace noyau-espace utilisateur. Microservice B se réveille et lit les données via recvmsg().

Ce parcours implique plusieurs allocations mémoire, un traitement complet du protocole, et plusieurs changements de contexte. Pour le trafic traversant réellement un réseau, cette machinerie est indispensable. Pour deux conteneurs sur le même hôte, c’est une surcharge importante dépensée à re-deriver des garanties que la mémoire locale fournit déjà.

---

Entrée dans eBPF : Programmabilité au niveau du noyau

Extended Berkeley Packet Filter (eBPF) a changé la façon dont les ingénieurs interagissent avec le noyau Linux. Le BPF classique a été conçu au début des années 1990 comme un mécanisme simple de filtrage de paquets — la technologie qui sous-tend encore des outils comme tcpdump — mais le eBPF moderne, dont l’infrastructure noyau a commencé à apparaître avec Linux 3.18 fin 2014, est devenu une machine virtuelle sandboxée qui s’exécute directement dans le noyau.

eBPF permet aux développeurs d’écrire des programmes restreints, de type C, et de les attacher à des points d’accroche dans tout le système d’exploitation : pilotes réseau, appels système, points de trace, et plus encore. Avant que tout programme eBPF ne s’exécute, un vérificateur en noyau vérifie statiquement qu’il ne peut pas faire planter le noyau, boucler indéfiniment, ou toucher la mémoire qu’il ne doit pas.

eBPF utilise des structures de données spécialisées appelées cartes eBPF — tables de hachage, tableaux, buffers circulaires — pour stocker l’état et échanger des données avec l’espace utilisateur. Des frameworks comme XDP (eXpress Data Path) accélèrent l’entrée au niveau du pilote NIC, mais XDP se situe trop bas dans la pile pour aider avec le trafic loopback qui n’atteint jamais une NIC physique. Pour résoudre le problème de boucle locale des microservices, le point d’accroche utile est plus haut dans la pile : la couche socket elle-même.

---

Décodage de la redirection de paquets au niveau des sockets

La solution au goulot d’étranglement du loopback est ce qu’on appelle communément l’accélération sockmap eBPF : attacher des programmes eBPF directement à la couche socket pour qu’ils interceptent les données au moment où une application appelle sendmsg(), puis les copier directement dans le buffer de socket de l’application réceptrice — en contournant complètement la pile TCP/IP.

1. Les types de cartes sockmap et sockhash

Au centre de ce mécanisme se trouvent deux types de cartes eBPF conçues à cet effet. BPF_MAP_TYPE_SOCKMAP est une carte basée sur un tableau qui stocke des références à des sockets ouvertes, introduite dans kernel 4.14. BPF_MAP_TYPE_SOCKHASH est une variante basée sur une table de hachage qui supporte des clés plus flexibles — par exemple, un tuple complet 5-tuple — arrivée dans kernel 4.18, selon la documentation officielle du sockmap kernel. Les deux types de cartes ont été initialement développés par John Fastabend et font partie du sous-système BPF depuis.

Un sockmap est plus qu’une table de recherche — un programme parseur et un programme de verdict peuvent lui être attachés directement. Lorsqu’un agent en espace utilisateur (par exemple, un daemon CNI) insère un descripteur de socket dans la carte, le noyau échange en transparence les callbacks de la carte pour ce socket, transformant la carte en un registre actif de connexions accélérées.

2. Le type de programme SK_MSG

Avec les sockets suivis dans une carte, les développeurs attachent un programme eBPF de type BPF_PROG_TYPE_SK_MSG, qui intercepte le chemin sendmsg()/sendfile() pour tout socket appartenant à la carte, comme documenté dans la référence du type de programme eBPF. Le programme reçoit le buffer du message avant l’existence des en-têtes TCP ou IP, et retourne un verdict : SK_PASS pour laisser passer les données (optionnellement après redirection), ou SK_DROP pour les rejeter.

3. L’assistant de redirection : bpf_msg_redirect_map()

Dans un programme SK_MSG, la logique eBPF inspecte la destination des données. Si celle-ci n’est pas un socket reconnu par le programme, il retourne SK_PASS et le message suit le chemin normal vers la NIC. Mais si la destination correspond à un socket déjà enregistré dans le sockmap — ce qui signifie que le pair est sur le même hôte — le programme appelle bpf_msg_redirect_map() (ou son homologue basé sur une table de hachage, bpf_msg_redirect_hash()).

Cet assistant copie la charge utile directement du buffer du socket émetteur dans celui du socket récepteur. Le traitement TCP/IP, Netfilter, iptables, et le pilote loopback sont tous contournés. Ce n’est pas qu’une théorie : un tutoriel eBPF montre que le trafic redirigé disparaît réellement de tcpdump — capturer l’interface loopback lors d’un transfert accéléré par sockmap ne montre que la poignée de main TCP et la déconnexion, car la charge utile elle-même ne revient jamais dans la partie de la pile que tcpdump surveille.

Il est également utile de savoir que sockmap a commencé sa vie comme un mécanisme TCP-only. La prise en charge bidirectionnelle complète UDP, ainsi qu’un type de redirection BPF_SK_SKB_VERDICT inter-protocoles, est arrivée plus tard : la série de patches la mettant en œuvre a commencé à circuler dans la communauté kernel vers 2021, selon LWN, comblant un vide que les ingénieurs de Cloudflare avaient signalé comme une fonctionnalité future potentielle dans leurs expérimentations sockmap.

---

Mise en œuvre concrète : Accélération du Service Mesh

Les bénéfices théoriques de la redirection au niveau des sockets sont convaincants, mais la technologie trouve sa pleine valeur dans les déploiements de service mesh, où elle a été mise en œuvre par des projets comme Cilium, Calico, et Merbridge.

Le problème classique du sidecar

Dans l’architecture initiale d’Istio, le trafic entre microservices est intercepté par des proxies Envoy exécutés à côté de chaque conteneur d’application. Si Microservice A parle à Microservice B, le flux ressemble à ceci :

1. Microservice A écrit dans ce qu’il pense être un socket normal.
2. Une règle iptables redirige de façon transparente le paquet vers le sidecar Envoy dans le Pod A.
3. Envoy traite le trafic — mTLS, traçage, routage.
4. Envoy envoie le paquet au Pod B via le réseau.
5. Le paquet arrive au Pod B et est intercepté par iptables à nouveau.
6. Il est remis au sidecar Envoy dans le Pod B pour déchiffrement et inspection.
7. Envoy le transmet enfin à Microservice B.

Lorsque le Pod A et le Pod B partagent un hôte, ce flux force le passage des données à travers la pile TCP/IP Linux plusieurs fois pour ce qui est, physiquement, d’une seule machine qui se parle à elle-même. Des travaux de mesure récents donnent un chiffre précis : un article de février 2026 de l’Université de Pékin sur un système appelé XLB a trouvé que le trafic entrant et sortant dans ce modèle traverse la pile TCP/IP du noyau trois fois, et que ce traitement protocolaire en double — ainsi que les appels système nécessaires pour le splicing de connexion entre le sidecar et l’application — représentent plus de la moitié de la latence totale par saut. Seul un cinquième de ce temps est consacré à la logique d’équilibrage de charge, qui est en fait le but du proxy.

Il est à noter qu’Istio lui-même a depuis lancé une option sans sidecar, visant précisément ce problème. Le mode Ambient, basé sur un proxy Rust partagé par nœud appelé ztunnel, avec des proxies “waypoint” optionnels par namespace pour les services nécessitant des fonctionnalités de couche 7, est devenu disponible en général dans Istio 1.24 en novembre 2024. Ce mode élimine la surcharge du sidecar par pod pour le trafic L4 (mTLS, identité, autorisation de base), mais comme le notent les chercheurs de XLB, un mesh L4 sans sidecar comme celui-ci ne dispose pas encore de suffisamment de contexte pour faire des décisions de routage HTTP ou gRPC de couche 7 — cela reste du ressort des proxies “waypoint” optionnels, qui réintroduisent une étape de proxy pour tout service qui en a besoin.

Accélération sockmap de Cilium

Le datapath eBPF de Cilium utilise depuis des années l’application de règles sockmap pour accélérer les connexions locales — à la fois le trafic pod-à-pod sur le même nœud et le saut entre une application et l’instance Envoy intégrée de Cilium, utilisée pour la politique réseau de couche 7. La documentation de l’architecture de Cilium décrit un hook d’opérations socket qui surveille les connexions TCP vers un pair local (y compris un proxy local) et attache un chemin rapide basé sur sockmap dès qu’une connexion est détectée, permettant aux messages de contourner le reste des couches de politique et NAT de Cilium.

Exécuter Cilium sous Istio — plutôt que d’utiliser les capacités de mesh natives de Cilium — nécessite aujourd’hui une certaine prudence. La documentation d’intégration actuelle de Cilium avec Istio indique que l’équilibrage de charge basé sur socket de Cilium pour les Services Kubernetes (un mécanisme lié mais distinct, utilisé pour remplacer kube-proxy) peut interférer avec la redirection iptables d’Istio, sauf si configuré explicitement avec le paramètre socketLB.hostNamespaceOnly, et que le CNI est configuré comme cni-exclusive: false pour permettre la coexistence de Cilium et du plugin CNI d’Istio sur le même nœud.

Cilium n’est pas la seule CNI à adopter cette approche, et il est utile d’être honnête sur la façon dont cette comparaison se présente. Calico a lancé une fonctionnalité d’accélération côté sidecar comparable utilisant eBPF sockmap dès Calico 3.8 en 2019, avec un blog d’ingénierie de Tigera la décrivant à l’époque comme contournant une grande partie de la surcharge réseau de l’architecture sidecar. Fait notable, la documentation actuelle de Tigera indique que cette fonctionnalité est expérimentale et déconseillée en production, en raison de problèmes de fiabilité nécessitant des correctifs noyau en amont — un rappel utile que “basé sur eBPF” et “prêt pour la production” ne sont pas synonymes, même plusieurs années après la sortie d’une fonctionnalité. Merbridge, un projet open-source plus petit, adopte une approche similaire, en remplaçant la redirection iptables utilisée par Istio, Linkerd, et Kuma par une redirection sockmap.

---

Load balancing en noyau de nouvelle génération

La redirection sockmap résout la moitié Layer-4 du problème — déplacer des octets entre deux sockets locaux — mais elle n’a pas de concept de requêtes HTTP, flux gRPC, ou règles de routage. Comme le soulignent les chercheurs de XLB, les outils L4 comme sockmap sont des blocs de construction utiles mais ne disposent pas d’assez de contexte pour gérer la couche 7 ou les décisions de load-balancing ; cela a historiquement signifié remonter le message à un proxy utilisateur complet comme Envoy, peu importe la rapidité du saut socket.

XLB, développé par Yuejie Wang, Chenchen Shou, Jiaxu Qian, et Guyue Liu à l’Université de Pékin, publié en février 2026, pousse plus loin : plutôt que de rediriger les octets vers un processus proxy séparé, il déplace la logique de load-balancing de couche 7 elle-même dans le noyau. La conception étend l’abstraction socket avec deux nouveaux types — un “proxy socket” qui contient la logique de load-balancing pour une connexion client, et des “sockets d’instance” préétablis avec chaque backend — et utilise des cartes eBPF imbriquées pour représenter la configuration de routage de style Envoy (clusters, routes, écouteurs) comme structures de données en noyau, la rendant compatible avec les outils de contrôle d’Envoy et Istio sans nécessiter de modifications applicatives.

Les chiffres rapportés sont impressionnants. Mesurés par rapport à Istio et Cilium dans des déploiements de 50 microservices ou plus, l’article indique jusqu’à 1,5x plus de débit et une réduction de 60% de la latence moyenne de bout en bout. Lors d’un microbenchmark plus précis avec 128 connexions simultanées, XLB a délivré 2,18x et 1,83x le débit d’Istio et Cilium respectivement. Lors d’un test séparé avec un taux de requêtes fixé à 60 000 requêtes par seconde, XLB a utilisé environ 75% et 76% moins de CPU que Istio et Cilium à ce même débit — la majorité de cet écart étant attribuée à l’élimination des coûts de planification inter-processus, de changement de contexte, et de cohérence de cache liés à l’exécution du proxy en processus séparé de l’application, un coût qui persiste même lorsque le saut socket entre eux est accéléré par sockmap.

L’article décrit aussi une déploiement en production réelle : un client bancaire exécutant des microservices de traitement de paiements sur plus de 100 nœuds ARM (Kunpeng-920), où XLB aurait réduit la latence des transactions d’environ 41%, diminué la consommation CPU liée au proxy d’un ordre de grandeur, et permis d’exécuter environ 30% de services supplémentaires par nœud — une marge utile pour absorber les pics de transactions lors des périodes de forte affluence. Les auteurs le présentent comme le premier load balancer L7 basé sur eBPF connu à servir des clients externes dans un cloud public.

Il est important d’être précis sur ce qu’il en est : XLB est un système de recherche décrit dans un article académique récent avec une étude de cas en production, et non — selon ce qui a pu être confirmé — un projet open-source disponible en téléchargement aujourd’hui. C’est un signal fort de l’évolution du réseau résident dans le noyau, plutôt qu’un outil prêt à l’emploi pour un projet de week-end.

---

Impact sur la performance du Zero-Stack Networking

1. Latence réduite, avec réserves

Éliminer la surcharge de la discipline de file d’attente, de la table de routage, et de l’encapsulation protocolaire réduit mesurablement la latence inter-processus locale. Des benchmarks informels indépendants d’une charge d’écho redirigée par sockmap ont trouvé environ 30% de réduction de latence par rapport au chemin non accéléré — une victoire significative, même si plus modérée que ce que laissent penser des cadres “quasi-instantanés”.

Il est aussi utile de noter que cette technologie a connu un départ plus difficile que ce que sa maturité actuelle laisse penser. Quand les ingénieurs de Cloudflare ont benchmarké une implémentation précoce de TCP splicing basé sur sockmap en 2019, sur un noyau 4.14 alors tout récent, sockmap s’est avéré le plus lent de tous leurs tests, avec des stalls de plusieurs millisecondes dus à des bugs noyau de cette époque. Des comparaisons académiques plus récentes donnent un tableau plus positif mais nuancé : un article de 2023 sur l’architecture FlatProxy indique que la redirection sockmap simple n’a qu’un effet mineur sur la latence dans leur configuration de test, et que son avantage en débit par rapport à un proxy Envoy complet disparaît dès que le nombre de connexions TCP simultanées dépasse environ quatre — limitation attribuée à l’absence de gestion native des connexions par sockmap. En résumé : sockmap est une solution durable pour le transfert de bytes à haute connexion, mais pas une solution gratuite et universelle, ce qui pousse la recherche vers des systèmes L7 en noyau plus complets comme XLB.

2. Économies CPU concrètes

Les chiffres concrets sont plus faciles à établir. Au-delà du principe général que moins de changements de contexte et moins de traitement protocolaire signifient moins de cycles CPU gaspillés, les benchmarks XLB donnent une référence : environ 75% de CPU en moins à un débit de 60K req/s comparé à Istio, et 76% de moins par rapport à Cilium, avec une réduction d’un ordre de grandeur de CPU dans le déploiement bancaire en production. Sur des hôtes très denses en conteneurs, le CPU économisé sur le proxy est du CPU — ou de la densité d’instances — récupéré pour le traitement applicatif.

3. La sécurité est réelle, mais pas automatique

Une idée reçue est que contourner iptables signifie renoncer à la pare-feu et à l’application de politiques. En pratique, des systèmes basés sur eBPF comme Cilium réimplémentent la politique nativement : le datapath de Cilium mappe chaque paquet à une identité dérivée d’un label Kubernetes et applique la politique L3/L4 (et, via son proxy, L7) avant que le chemin rapide sockmap ne soit engagé, garantissant que les connexions accélérées ne soient pas non contrôlées.

Cela dit, “implémenté en eBPF” ne veut pas dire sans faille. Le code noyau de sockmap a connu plusieurs vulnérabilités de sécurité. En 2025, la sous-système BPF-TCP/sockmap a été patchée pour une faille use-after-free dans tcp_bpf_send_verdict() (CVE-2025-39913) pouvant être déclenchée par une allocation mémoire échouée lors du “corking” du message, pouvant entraîner un crash noyau ou une escalade de privilèges locale. Des correctifs séparés ont également été apportés pour une issue de null-pointer dans sockmap/vsock (CVE-2025-21854) et un panic d’interaction kTLS affectant sockmap (CVE-2025-38166). Rien de tout cela ne doit dissuader d’utiliser sockmap, mais il faut le traiter comme toute autre surface d’attaque noyau : suivre les CVE de votre distribution et appliquer les correctifs, plutôt que de considérer “c’est eBPF” comme une garantie de sécurité en soi.

---

Défis et perspectives

eBPF sockmap est vraiment utile, mais comporte des considérations opérationnelles.

Premièrement, les exigences en version noyau sont plus précises que “récemment suffisant”. BPF_MAP_TYPE_SOCKMAP nécessite au moins Linux 4.14 ; BPF_MAP_TYPE_SOCKHASH, qui est la majorité des déploiements réels pour sa flexibilité, nécessite Linux 4.18 ; et si votre charge inclut UDP, il faut un noyau récent pour la redirection inter-protocoles BPF_SK_SKB_VERDICT, arrivée vers 2021. Les organisations utilisant des noyaux enterprise LTS plus anciens doivent vérifier leur statut de backport plutôt que de supposer que “nous avons eBPF” suffit.

Deuxièmement, le dépannage requiert de nouveaux outils. Les captures classiques comme tcpdump s’interfacent avec les couches basses du pilote réseau et TCP, donc les payloads redirigés par sockmap n’apparaissent pas dans ces captures — seul la configuration de connexion et la déconnexion seront visibles sur une capture loopback. Les équipes doivent disposer d’observabilité native eBPF, comme Hubble de Cilium, pour voir ce qui arrive réellement au trafic local accéléré.

Troisièmement — et c’est facile à manquer dans le marketing des fournisseurs — la maturité varie considérablement selon l’implémentation. La accélération sockmap de Cilium est une partie documentée et stable de son architecture depuis des années. La fonctionnalité comparable de Calico, en revanche, porte un avertissement expérimental dans la documentation de Tigera depuis 2019. Avant d’adopter la sockmap via un CNI ou un service mesh, il est conseillé de vérifier le statut de production actuel de cette implémentation plutôt que de supposer que toutes les fonctionnalités sockmap eBPF sont équitablement éprouvées.

Conclusion

Le passage au microservices cloud-native a apporté une flexibilité architecturale réelle, mais a mis à rude épreuve la pile réseau Linux conçue pour l’internet ouvert, et pas pour des conteneurs adjacents partageant un seul hôte. À mesure que la densité de conteneurs augmente, faire transiter le trafic inter-processus local par une encapsulation TCP/IP complète devient une surcharge de plus en plus coûteuse.

L’accélération sockmap eBPF comble aujourd’hui une partie significative de cet écart, et est suffisamment mature — du moins dans des implémentations comme Cilium — pour être déployée en production. La tendance va plus loin : du simple redirection de bytes vers des systèmes comme XLB qui déplacent la logique de load-balancing de couche 7 dans le noyau, éliminant le sidecar plutôt que de simplement accélérer le saut vers lui. Quelle que soit la couche qui convient le mieux à une charge de travail donnée, la direction est claire — le réseautage résident dans le noyau, pas dans l’espace utilisateur, est la prochaine étape pour améliorer la performance des microservices.

---

Historique des modifications

Métadonnées supprimées - Suppression de la ligne SEO en gras / meta-description qui apparaissait sous le titre dans la version initiale.

Corrections - Exigence de version noyau pour sockmap : la version initiale indiquait que eBPF était présent depuis le noyau 4.4. ; la documentation officielle précise que BPF_MAP_TYPE_SOCKMAP nécessite Linux 4.14 et BPF_MAP_TYPE_SOCKHASH Linux 4.18. - La mention “trois à quatre fois” pour la traversée de la pile dans le cas des sauts sidecar est maintenant accompagnée d’une donnée précise (trois traversées) issue d’une étude académique de 2026, plutôt qu’une approximation non sourcée.

Vérifié comme précis, sans modification substantielle - La description du walkthrough du paquet loopback en 9 étapes, la mécanique sockmap/sockhash/SK_MSG/bpf_msg_redirect_map(), et la déclaration que tcpdump ne peut pas voir les payloads redirigés par sockmap — tout cela confirmé par la documentation du noyau, la documentation eBPF, et des tutoriels indépendants. - La performance revendiquée de XLB (“jusqu’à 1,5x de débit, 60% de latence en moins vs. Istio et Cilium”) était déjà correcte dans la version initiale. Elle est maintenant attribuée à la source réelle — un article récent (février 2026) de l’Université de Pékin — avec des détails vérifiés (architecture, décomposition des benchmarks, étude de cas en production).

Ajouté (nouvelles informations vérifiées) - Statut de disponibilité générale d’Istio Ambient Mode (Istio 1.24, novembre 2024) et sa relation avec le problème de couche 7 abordé dans cet article, tiré du blog d’Istio. - Détails opérationnels actuels pour faire fonctionner Cilium sous Istio, y compris les flags de configuration précis pour éviter les conflits, tirés de la documentation actuelle de Cilium. - La fonctionnalité d’accélération côté sidecar de Calico et son statut “expérimental, pas pour la production” selon la documentation de Tigera, avec une mention du projet Merbridge. - Contexte de performance équilibré (découvertes de Cloudflare en 2019, étude FlatProxy 2023, et un benchmark indépendant d’environ 30% de latence réelle), remplaçant une présentation non vérifiable “latence quasi-zéro / vitesse mémoire brute” par des chiffres vérifiables. - Un avertissement de sécurité couvrant trois CVE de 2025 affectant le sous-système BPF-TCP/sockmap, incluant une faille use-after-free pouvant entraîner un escalade de privilèges. - Support UDP historique de sockmap (TCP-only au lancement ; support UDP bidirectionnel complet via patches à partir de 2021). - Une note de clarification sur ce qu’est actuellement XLB (système de recherche avec déploiement en production documenté) versus ce qu’il n’est pas (un projet open-source disponible en téléchargement), pour éviter de surévaluer sa disponibilité.

Mise en forme - Réduction de la répétition de la mise en gras des mêmes phrases-clés SEO dans le corps du texte ; les termes techniques sont maintenant mis en évidence lors de leur première mention plutôt qu’à chaque occurrence.

Sources consultées

• Documentation du sockmap Linux
• Docs eBPF : BPF_PROG_TYPE_SK_MSG
• Tutoriel sockops eunomia.dev
• LWN : patches UDP sockmap / BPF_SK_SKB_VERDICT
• Cloudflare : “SOCKMAP – TCP splicing of the future” (2019)
• Cilium : guide d’intégration Istio actuel
• Tigera/Calico : docs d’accélération sidecar Istio
• Article XLB (arXiv, fév. 2026)
• Istio : “Ambient Mode Reaches General Availability in v1.24”
• Article FlatProxy (arXiv, 2023)
• eBPFChirp : benchmark de latence socket local
• CVE-2025-39913 approfondissement ; CVE-2025-21854