Communications en temps réel dans le développement mobile : définition, protocoles et fonctionnement

Communications en temps réel : protocoles WebSocket, SSE et Long Polling

Les communications en temps réel sont des technologies permettant l'échange de données entre le client et le serveur avec une latence minimale. Les principaux protocoles : WebSocket, SSE (Server-Sent Events), Long Polling et Short Polling. Chacun a son créneau : WebSocket pour la communication bidirectionnelle, SSE pour les notifications, Long Polling comme solution de repli pour les anciens navigateurs. Le temps réel dans le développement mobile est particulièrement important : les utilisateurs s'attendent à une livraison instantanée des messages et notifications. Les communications dans le développement mobile sont construites précisément sur ces protocoles.

WebSocket vs SSE

WebSocket est un protocole full-duplex (client ↔ serveur). Après la poignée de main (HTTP Upgrade), la connexion reste ouverte. Les en-têtes sont minimes (2 octets contre en-têtes HTTP). Utilisé dans les chats (WhatsApp, Telegram), jeux, trading en temps réel. SSE est un protocole unidirectionnel (serveur → client). Le client s'abonne aux événements et les reçoit via une seule connexion HTTP. SSE est plus simple, plus facile à scaler (HTTP simple), idéal pour les flux Twitter, taux de change, notifications push.

Long Polling est une technique où le client fait une requête HTTP et la maintient ouverte jusqu'à ce que le serveur envoie des données ou qu'un timeout survienne (30–60 s). Après réception des données, le client ouvre immédiatement une nouvelle requête. Long Polling est une solution de repli pour WebSocket. Short Polling — le client interroge le serveur toutes les N secondes. Le plus simple mais inefficace (la plupart des requêtes retournent des réponses vides).

Serveur de signalisation

Avant d'établir une connexion P2P, les appareils ont besoin d'un serveur de signalisation — un serveur intermédiaire pour échanger les offres SDP et les candidats ICE entre les pairs. La signalisation peut être implémentée via WebSocket, SSE ou tout autre protocole. Après l'établissement de la connexion, la signalisation ne participe plus à la transmission du trafic multimédia.

WebRTC : communications en temps réel avec appels audio et vidéo

WebRTC (Web Real-Time Communication) est une technologie ouverte pour l'audio/vidéo/données P2P. Fonctionne dans les navigateurs et les applications natives (iOS, Android). WebRTC inclut : getUserMedia (accès caméra/micro), RTCPeerConnection (connexion P2P), RTCDataChannel (transfert de données). WebRTC permet les communications en temps réel dans les applications mobiles — les communications dans les apps mobiles fonctionnent sans plugins supplémentaires.

Flux WebRTC

Le pair A crée une RTCPeerConnection et une offre SDP. Étape 2 : L'offre est envoyée via le serveur de signalisation au pair B. Étape 3 : Le pair B reçoit l'offre, crée une réponse SDP et la renvoie. Étape 4 : Les deux pairs collectent les candidats ICE (adresses pour la connexion) et les échangent via la signalisation. Étape 5 : Le framework ICE sélectionne le meilleur chemin (P2P ou via TURN). Après la connexion — le trafic multimédia circule directement.

SDP (Session Description Protocol) est un protocole textuel décrivant les paramètres de connexion : codecs, adresses IP, ports. ICE Candidate est une proposition de STUN/TURN : « On peut me trouver à cette adresse ». Plus il y a de candidats, plus la probabilité de P2P est élevée.

Socket.IO est le leader pour les startups : vous contrôlez le serveur, sans limites. Pusher et Ably sont pour les produits où vous ne voulez pas gérer d'infrastructure. PubNub est pour l'IoT et les audiences mondiales. IT Sectr recommande Socket.IO pour les projets avec votre propre backend, Pusher pour les prototypes rapides, Ably pour les entreprises avec des exigences de fiabilité.

Plateformes : Socket.IO, Pusher, Ably, PubNub

Les plateformes temps réel fournissent une infrastructure serveur prête à l'emploi pour WebSocket et SSE. Elles éliminent le besoin d'écrire votre propre serveur temps réel, d'équilibrer les connexions WebSocket et de les scaler. Le choix de la plateforme dépend du budget, des exigences de fiabilité et de la volonté de gérer un serveur. Pour le temps réel dans le développement mobile, les plateformes offrent des SDK clients et une infrastructure prêts à l'emploi.

Socket.IO

Socket.IO est une bibliothèque pour Node.js et les clients (iOS, Android, web). Basée sur WebSocket, mais utilise le polling HTTP comme solution de repli. Prend en charge les salles, les espaces de noms, les confirmations ACK. Pour le développement — socket.io-client-java (Android) et socket.io-client-swift (iOS). Les communications dans les applications mobiles sur Socket.IO sont gérées de manière fiable grâce à la reconnexion automatique.

Pusher et Ably

Pusher est une plateforme SaaS temps réel. Intégration simple : créez un canal et abonnez-vous aux événements. Pusher Channels pour les notifications, Pusher Beams pour les notifications push. Ably est de niveau entreprise avec réplication globale dans 7 centres de données. Garantit une livraison exactly-once. Prend en charge SSE, WebSocket, MQTT pour l'IoT. Les deux plateformes résolvent les tâches de communication dans le développement mobile sans écrire de code serveur.

Infrastructure temps réel : STUN, TURN, Signalisation dans WebRTC

STUN (Session Traversal Utilities for NAT) est un serveur qui aide un appareil à découvrir son IP et son port externes derrière un NAT. L'appareil envoie une requête STUN, le serveur répond : « Vous êtes visible comme 203.0.113.5:45678 ». STUN est utilisé gratuitement (Google STUN : stun.l.google.com:19302). Dans le contexte de l'infrastructure temps réel, STUN est la première étape pour établir un canal P2P.

STUN vs TURN

TURN (Traversal Using Relays around NAT) est un serveur relais qui relaie le trafic multimédia si une connexion P2P est impossible (par exemple, les deux appareils derrière un NAT symétrique). TURN consomme de la bande passante serveur, donc coûteux. Dans WebRTC, le framework ICE essaie d'abord le P2P, puis TURN en dernier recours. Le temps réel dans le développement nécessite TURN pour les communications dans les applications mobiles lors de la connexion via des réseaux d'entreprise.

ICE (Interactive Connectivity Establishment) est un framework qui collecte tous les chemins de connexion possibles (IP locale, IP externe via STUN, relais TURN) et sélectionne le meilleur. ICE Candidate est chaque chemin possible. Plus il y a de candidats, plus la probabilité de P2P réussi est élevée.

Peer-to-Peer

P2P est une connexion directe entre deux appareils sans serveur intermédiaire pour le trafic multimédia. Le P2P réduit la latence (< 100 ms) et les coûts serveur. Inconvénients : faible protection contre le NAT, nécessité de STUN/TURN. WebRTC utilise le P2P par défaut.

P2P et ICE

Peer-to-Peer (P2P) est une architecture où les données sont transférées directement entre les appareils. Dans le contexte des communications en temps réel, le P2P est utilisé dans WebRTC pour minimiser la latence. ICE (Interactive Connectivity Establishment) est le mécanisme qui trouve le meilleur chemin pour une connexion P2P. Pour le développement, le P2P est la manière optimale d'organiser les communications dans les applications mobiles en temps réel.

Comment fonctionne ICE

ICE collecte ICE Candidate de trois types : 1) host (IP locale), 2) srflx (via STUN), 3) relay (via TURN). Tous les candidats sont triés, et ICE essaie de se connecter à chacun par ordre de priorité. La première connexion réussie est utilisée. Si le P2P est impossible, TURN est utilisé (mais c'est coûteux).