Communication des données dans les systèmes de trading algorithmique : un panorama technologique

Dans le trading algorithmique, la différence entre gain et perte peut se mesurer en microsecondes. L'architecture de transmission des données est l'un des facteurs clés déterminant l'efficacité d'un système de trading. Dans cet article, nous décortiquons les technologies de communication à tous les niveaux : de l'interaction avec l'exchange à la communication interne entre services, en passant par le stockage et la distribution des données.

L'article est organisé par niveaux — de l'« externe » (protocoles d'exchange) à l'« interne » (IPC, brokers de messages, stockage) — reflétant l'architecture réelle d'une plateforme de trading algorithmique.

1. Interaction avec l'exchange : REST, WebSocket, FIX

1.1 API REST

REST est la manière la plus simple et la plus courante d'interagir avec l'API d'un exchange. Chaque requête est une connexion HTTP distincte : handshake TCP → handshake TLS → envoi de la requête → réception de la réponse → fermeture de la connexion.

Problèmes de REST pour le trading :

Chaque requête entraîne un surcoût lié à l'établissement de la connexion. Même avec le keep-alive HTTP, le modèle « requête-réponse » signifie qu'on ne peut pas recevoir de données plus vite qu'on n'envoie de requêtes. Cela mène au polling — un cycle sans fin de requêtes du type « y a-t-il de nouvelles données ? » qui génèrent, selon les développeurs d'exchanges crypto, jusqu'à 80 % de la charge sur les serveurs de l'exchange. Les exchanges instaurent des limites de débit (typiquement 10 à 1200 requêtes par minute), ce qui rend REST inadapté aux stratégies à haute fréquence.

Quand REST est approprié : récupération de données historiques (chandeliers, OHLCV), gestion de compte (solde, positions), opérations non temps réel (bots DCA, rééquilibrage horaire).

1.2 WebSocket

WebSocket établit une connexion TCP persistante unique par laquelle les données circulent de manière bidirectionnelle. Elle démarre comme une requête HTTP classique avec un en-tête Upgrade, puis bascule vers un protocole de framing bidirectionnel (la charge utile peut être du JSON texte ou du binaire).

Avantages pour le trading :

Le principal avantage est l'absence de surcoût par requête. Une fois établie, les données sont poussées instantanément par le serveur. La latence de livraison des données de marché via WebSocket est généralement inférieure à 50 ms entre la passerelle de l'exchange et le client. On peut s'abonner à 50 symboles ou plus simultanément sur une seule connexion.

Un point critique : les ordres via WebSocket. Beaucoup de traders ignorent que certains exchanges (Binance, HitBTC, Deribit, Bybit, etc.) permettent d'envoyer des ordres via WebSocket, et pas seulement de recevoir des données. C'est fondamentalement plus rapide que REST car :

• Pas de handshake TCP/TLS pour chaque ordre (la connexion est déjà « chaude »)
• Pas de surcoût HTTP (en-têtes, cookies, etc.)
• Modèle asynchrone : on envoie un ordre et on reçoit la confirmation via le même WebSocket sans bloquer le thread.

Selon Deribit, WebSocket et FIX ont souvent la même vitesse d'exécution. REST est légèrement plus lent en raison du prétraitement au niveau de la connexion. Les ordres WebSocket rejoignent la file d'attente du moteur d'appariement tout comme les ordres FIX.

Le problème du mélange de contextes. Si l'on envoie des ordres via REST mais que l'on reçoit les notifications d'exécution via WebSocket, une condition de course survient : la notification WebSocket peut arriver avant que la requête REST ne soit terminée. Cela entraîne une incohérence d'état. La solution consiste à envoyer les ordres via le même WebSocket, en passant entièrement à un modèle asynchrone.

1.3 Protocole FIX (Financial Information eXchange)

FIX est la norme industrielle du trading électronique, existant depuis 1992 (créée par Fidelity Investments et Salomon Brothers). C'est un protocole binaire sur TCP spécifiquement conçu pour le trading.

Architecture de FIX :

• Couche session — gère la connexion, les heartbeats, la numérotation de séquence, la récupération des lacunes. Garantit la livraison et l'ordre des messages.
• Couche application — logique métier : types d'ordres, rapports d'exécution, demandes de données de marché.

Les messages FIX se composent de paires « tag=value » séparées par un caractère SOH. Par exemple, un ordre d'achat de 100 actions AAPL à 150 $ ressemble à ceci :

8=FIX.4.2|35=D|49=BUYER|56=SELLER|11=ORD1001|38=100|40=2|54=1|55=AAPL|44=150.00

Pourquoi FIX est plus rapide que WebSocket : FIX est un protocole TCP natif sans couches HTTP. AWS, dans son guide d'optimisation tick-to-trade pour les exchanges crypto, recommande explicitement FIX plutôt que REST et WebSocket pour minimiser la latence induite par le protocole. FIX fonctionne au niveau de la microseconde, tandis que WebSocket se situe généralement en millisecondes.

Où FIX domine : DMA (Direct Market Access) vers le moteur d'appariement de l'exchange, trading algorithmique et HFT dans les milieux institutionnels, agrégation de liquidité (prime brokers se connectant à des dizaines de banques via FIX).

Limitations de FIX : complexité d'intégration, format de message dépassé (les paires texte tag-value sont moins efficaces que les formats binaires), barrière d'entrée élevée. Dans l'industrie crypto, FIX n'est pris en charge que par un nombre limité d'exchanges.

1.4 SBE (Simple Binary Encoding) — L'évolution de FIX

SBE est un format de sérialisation binaire créé par le High Performance Working Group au sein de la FIX Trading Community. Sa mission est de remplacer le format texte de FIX par une représentation binaire compacte pour le trading à très faible latence.

Principes clés de SBE :

• Modèle flyweight zero-copy — les encodeurs et décodeurs agissent comme des « modèles » sur un buffer. Les valeurs sont écrites directement sans copies intermédiaires (contrairement à Protobuf, qui en nécessite plusieurs).
• Format sur le fil = format en mémoire — les données sur le fil ressemblent exactement à celles en mémoire, ce qui minimise le surcoût de transformation.
• Champs fixes d'abord, champs variables ensuite — une contrainte de conception qui offre un ordre de grandeur de performance en plus par rapport à Protocol Buffers.

SBE + Aeron est la combinaison standard pour les systèmes de trading haute performance. Aeron est un système de messagerie open source de Real Logic (créé par Martin Thompson, ancien CTO de LMAX Exchange, et Todd Montgomery, ancien CTO de 29West/Ultra Messaging). C'est essentiellement une couche de transport spécialisée pour les systèmes financiers, fonctionnant sur UDP et mémoire partagée avec des latences à un chiffre de microsecondes. SBE se charge de la sérialisation, tandis qu'Aeron gère la livraison avec des délais de l'ordre de la microseconde. Plus de détails sur Aeron à la section 3.1.

1.5 Tableau comparatif des protocoles d'exchange

2. Communication interne entre microservices

Une fois que les données entrent dans le système depuis l'exchange, le traitement interne commence : parsing → stratégie → décision → envoi de l'ordre. À chaque étape, il y a communication entre services.

2.1 Streaming bidirectionnel gRPC (TCP)

gRPC est un framework de Google basé sur HTTP/2 utilisant Protocol Buffers pour la sérialisation. Pour le trading algorithmique, le streaming bidirectionnel est particulièrement important — lorsque client et serveur envoient simultanément des flux de messages sur une même connexion.

Pourquoi gRPC convient aux systèmes de trading :

• Protobuf est compact (3 à 10 fois plus petit que JSON)
• Multiplexage HTTP/2 — plusieurs flux sur une seule connexion TCP
• Typage strict via des schémas .proto détectant les erreurs à la compilation
• Génération de code pour Python, Rust, Go, C++, Java, etc.
• Le streaming bidirectionnel permet le motif « données de marché en descente, ordres en montée » via un seul canal.

Selon SmartDev, 70 % des institutions financières déployant du HFT piloté par l'IA utilisent gRPC ou du TCP brut pour des temps de réponse de l'ordre de la microseconde.

Exemple d'architecture : Market Data Collector (Rust) → flux gRPC → Strategy Engine (Python/Rust) → appel gRPC → Order Router (Rust) → WebSocket/FIX → Exchange.

2.2 gRPC via Unix Domain Socket (UDS)

Si les services s'exécutent sur la même machine (typique en co-location), TCP est un surcoût inutile. Unix Domain Socket (UDS) contourne toute la pile réseau : pas de handshake TCP, pas de routage, pas de calcul de checksum.

Les benchmarks montrent une différence significative :

• gRPC via UDS : ~102 μs/requête (100 000 requêtes)
• gRPC via TCP : ~127 μs/requête (100 000 requêtes)
• Gain UDS : ~20 % sur les petits messages, jusqu'à 50 % sur les gros (100 Ko+).

Selon F. Werner (MPI Heidelberg), comparant gRPC UDS avec des E/S bloquantes brutes via UDS, gRPC ajoute environ 10 fois plus de surcoût — médiane ~130 μs contre ~13 μs pour l'UDS brut. C'est le coût de l'abstraction (framing HTTP/2, sérialisation protobuf).

Quand utiliser gRPC+UDS : communication inter-processus sur un seul serveur, lorsque le confort du développeur (schéma, génération de code) est privilégié par rapport à la latence absolument minimale. UDS offre aussi des avantages en matière de sécurité via les permissions de fichiers Unix.

Quand NE PAS l'utiliser : si une latence <10 μs est nécessaire, la mémoire partagée ou l'UDS brut sans gRPC sont préférables. Pour référence : médiane de l'UDS brut ~13 μs, médiane du gRPC UDS ~130 μs. La mémoire partagée (Aeron IPC) est sous 1 μs, l'anneau tampon LMAX Disruptor tourne autour de 50 à 100 ns. Ainsi, gRPC+UDS est environ 10 fois plus lent que l'UDS brut et 100 à 1000 fois plus lent que la mémoire partagée. Mais chaque palier de latence gagné se paie en complexité de code accrue.

Reproduisez-le vous-même : tous les chiffres de latence IPC de cette section sont reproductibles avec le benchmark compagnon open source suenot/trading-ipc-bench — des implémentations Python d'aller-retours sur TCP, UDS, ZeroMQ IPC/TCP, WebSocket, Redis Pub/Sub, mémoire partagée et Named Pipe, mesurant la latence p50/p95/p99/p99,9 et le débit sur votre propre matériel.

UDS brut sans gRPC — si le surcoût de gRPC est excessif, retirez-le et gardez uniquement le socket. Options par performance décroissante :

• Sockets AF_UNIX + sérialisation personnalisée (SBE, FlatBuffers, MessagePack) — médiane ~13 μs, contrôle maximal, complexité maximale
• ZeroMQ IPC (ipc://) — ~50–100 μs, motifs prêts à l'emploi (PUB/SUB, REQ/REP) sans code répétitif, utilise l'UDS en interne
• IPC nanomsg/NNG — similaire à ZeroMQ, latence légèrement meilleure sur les petits messages (<64 Ko)
• RPC Cap'n Proto sur UDS — sérialisation zero-copy + abstraction RPC, plus rapide que gRPC, avec schéma

2.3 IPC par mémoire partagée

Pour une latence ultra-faible sur le même hôte, on utilise la mémoire partagée. Deux processus mappent le même segment de RAM, et les données transitent sans appels système (sauf lors de la configuration initiale).

Le motif LMAX Disruptor (anneau tampon en mémoire partagée) traite environ 6 millions d'événements par seconde sur un seul thread. Cette approche est au cœur de LMAX Exchange et de nombreux systèmes HFT.

Implémentations : Aeron IPC (Java/C++), Chronicle Queue (Java), solutions personnalisées basées sur mmap (Rust/C++). IronSBE (implémentation SBE en Rust) prend en charge l'IPC par mémoire partagée avec une latence d'environ 20 ns au niveau du canal SPSC.

3. Systèmes de transport : brokers de messages et bibliothèques

3.1 Aeron — L'étalon-or

Aeron est un système de transport de messages open source haute performance développé par Real Logic. Ses créateurs sont Martin Thompson (ancien CTO de LMAX) et Todd Montgomery (ancien CTO de 29West). Il a débuté en 2014 pour un grand exchange américain et compte désormais plus de 70 contributeurs et plus de 5000 abonnés GitHub.

En pratique : Aeron n'est ni un broker (comme Kafka) ni une bibliothèque de sockets (comme ZeroMQ). C'est une couche de transport conçue pour une latence faible et prévisible. Elle fonctionne sur UDP (réseau) et mémoire partagée (IPC), offrant une livraison fiable, un ordonnancement et un contrôle de flux — des éléments absents de l'UDP brut. On peut voir Aeron comme un « TCP avec la latence d'UDP ».

Caractéristiques d'Aeron :

• Latence : <100 μs dans le cloud, <18 μs sur bare metal.
• Débit : >1 million de messages/s à latence microseconde.
• Pointe à 20 millions+ de messages/s.
• Sans broker (brokerless) — pas de point unique de défaillance.
• Prend en charge l'unicast, le multicast et l'IPC.
• Contrôle de flux et détection de perte intégrés.

Aeron Cluster — réplication d'une machine à états tolérante aux pannes (consensus Raft) pour une logique de trading cohérente avec une latence additionnelle minimale.

Aeron Archive — persistance des messages à la pleine vitesse du flux, avec capacité de rejeu.

Aeron Sequencer — le composant le plus récent de l'écosystème, conçu pour coordonner plusieurs projets au sein de grandes organisations. Construit sur Aeron Transport et Aeron Cluster. Caractéristiques clés :

• Journal distribué — une longue séquence de messages répliquée sur plusieurs machines pour la tolérance aux pannes
• Lecteurs multiples — plusieurs applications lisent simultanément le même journal à des fins différentes
• Équipes découplées — les équipes restent indépendantes tout en opérant au sein d'un système coordonné unique
• Cas d'usage cibles : traitement de données de marché, plateformes de brokers, moteurs d'exchange

Comparaison avec Kafka : les deux utilisent un journal distribué, mais Aeron vise la latence microseconde, tandis que Kafka vise la durabilité et le débit en millisecondes. Aeron existe pour la logique temps réel ; Kafka pour les pipelines de données et l'analytique.

3.2 Apache Kafka

Apache Kafka est la norme de facto pour le streaming d'événements à grande échelle. Il n'est pas fait pour le chemin critique du trading (délais en millisecondes), mais il est indispensable pour :

• Agrégation de données de marché : collecter des flux de plus de 100 exchanges dans un seul pipeline.
• Event sourcing : enregistrer chaque action du système comme un topic d'événements.
• CDC (Change Data Capture) : diffuser les changements de la base de données de trading vers l'analytique.
• Intégration QuestDB : Kafka → QuestDB pour l'analytique de ticks en temps réel.

La latence est de 2 à 15 ms de bout en bout. Inacceptable pour le HFT, mais correcte pour des stratégies avec un horizon supérieur à 1 seconde.

3.3 Redis Pub/Sub et Streams

Redis est un stockage en mémoire qui fonctionne aussi comme un broker léger.

Redis Pub/Sub — fire-and-forget ; latence sous la milliseconde. Idéal pour les notifications en temps réel : mises à jour de prix, signaux de stratégie, alertes.

Redis Streams — ajoute la persistance et les groupes de consommateurs (mini-Kafka). Prend en charge la lecture de l'historique et les ACK.

Redis est plus rapide que Kafka pour les petits messages (sous la milliseconde), mais lui manque la réplication et la durabilité robustes de Kafka.

3.4 NATS

NATS est un système ultra-léger écrit en Go. Latence sous la milliseconde, pub/sub intégré, request/reply. NATS JetStream ajoute la persistance et la livraison exactement une fois.

3.5 ZeroMQ et nanomsg

Des bibliothèques sans broker offrant des abstractions de sockets pour la communication de pair à pair. ZeroMQ traite plus de 5 millions de messages/s et est éprouvé en production depuis 2007. nanomsg (et NNG) en est le « successeur », avec une meilleure latence sur les petits messages (<64 Ko).

4. PUB/SUB temps réel pour les clients : Centrifugo

Centrifugo est un serveur PUB/SUB auto-hébergé écrit en Go, optimisé pour la diffusion à des milliers ou millions de clients via WebSocket, SSE ou gRPC.

Pourquoi Centrifugo pour l'algo trading :

• Gère 1 million de connexions WebSocket et 30 millions de messages/min sur un seul serveur.
• Prend en charge le streaming à 60 Hz.
• Compression delta (algorithme Fossil) pour minimiser le trafic.
• Parfait pour le « dernier kilomètre » vers les tableaux de bord web ou les applications mobiles.

5. Bases de données à accès temps réel

5.1 QuestDB — Séries temporelles pour le trading

QuestDB est une base de données de séries temporelles open source écrite en Java (zero-GC), C++ et Rust.

• Requêtes : exécution vectorisée sous la milliseconde via SIMD.
• SAMPLE BY/ASOF JOIN : extensions SQL natives conviviales pour les traders.
• WAL : ajout à très faible latence.
• Utilisé par B3 (la bourse du Brésil).

5.2 Redis comme couche de données

Généralement une couche intermédiaire :

• Cache chaud pour un accès aux prix en O(1).
• Sorted sets pour les carnets d'ordres.
• Scripts Lua pour les opérations atomiques.

5.3 Solutions spécialisées : RayforceDB, AXL DB

Bases de données vectorielles minimalistes en C (binaires <1 Mo) sans dépendances et avec accélération SIMD. Axées sur la latence déterministe pour le HFT.

6. Sérialisation : Protobuf vs SBE vs JSON

7. Architectures de référence

7.1 Arbitrage crypto (fréquence moyenne)

Exchanges → Collector (Rust) → Redis (Hot) → Stratégie (Python) → gRPC → Router (Rust) → Exchange.

7.2 Market making HFT (co-location)

Flux de l'exchange → NIC en kernel bypass → Aeron IPC → Stratégie (C++) → SBE → Aeron → Exchange.

8. Conseils pratiques

• <10 μs (HFT) : FPGA, mémoire partagée, SBE, Aeron IPC.
• 10–100 μs : Aeron (UDP), gRPC+UDS, ZeroMQ.
• 100 μs – 1 ms : gRPC (TCP), WebSocket, Protobuf.
• 1–10 ms (fréquence moyenne) : WebSocket, Kafka, Redis.
• >10 ms (basse fréquence / swing) : l'API REST suffit. DCA, rééquilibrage, gestion de portefeuille.

N'optimisez pas ce qui n'est pas un goulot d'étranglement. Si votre stratégie prend 50 ms pour décider, les 100 μs économisées par Aeron n'auront pas d'importance. Les architectures hybrides sont la norme : utilisez REST pour la configuration, gRPC comme cœur et WS pour la livraison.

Dépôt de benchmarks

Les chiffres de latence cités tout au long de cet article peuvent être reproduits avec suenot/trading-ipc-bench — une suite de benchmarks Python open source couvrant tous les principaux transports IPC abordés ici : TCP, UDS, Named Pipe, ZeroMQ IPC/TCP, WebSocket, Redis Pub/Sub et mémoire partagée.

git clone https://github.com/suenot/trading-ipc-bench
cd trading-ipc-bench
pip install -r requirements.txt
python run_all.py   # runs all 8 transports, saves results to results/
python report.py    # prints a summary table + ASCII latency chart

Exécutez-le sur votre propre matériel — les résultats différeront des chiffres de cet article selon votre CPU, votre système d'exploitation, votre version de noyau et vos réglages. C'est précisément le but.

Conclusion

Il n'existe pas de technologie de communication « parfaite ». Chaque niveau a des exigences uniques : externe (compatibilité), interne (latence), pipeline (fiabilité) et client (flexibilité). L'architecture consiste à choisir le bon outil pour la tâche spécifique.