Streaming HTTP : savoir communiquer via des flux

SOA – Streaming et Messages
Mickaël BARON – Février 2019 (Rév. Novembre 2023)
mailto:[email protected] ou mailto:[email protected]
mickael-baron.fr
mickaelbaron
Savoir communiquer via des flux et par messages

View Slide

Streaming et Messages - M. Baron - Page
mickael-baron.fr mickaelbaron
2
Creative Commons
Contrat Paternité
Partage des Conditions Initiales à l'Identique
2.0 France
creativecommons.org/licenses/by-sa/2.0/fr
Licence

View Slide

3
À propos de l’auteur …
Mickaël BARON
Ingénieur de Recherche au LIAS
https://www.lias-lab.fr
Equipe : Ingénierie des Données et des Modèles
Responsable des plateformes logicielles, « coach » technique
Ancien responsable Java de Developpez.com (2011-2021)
Communauté Francophone dédiée au développement informatique
https://java.developpez.com
4 millions de visiteurs uniques et 12 millions de pages vues par mois
750 00 membres, 2 000 forums et jusqu'à 5 000 messages par jour
mickael-baron.fr
mickaelbaron

View Slide

4
Déroulement du cours
Pédagogie du cours
Des bulles d’aide tout au long du cours
Survol des principaux concepts en évitant une présentation
exhaustive
Logiciels utilisés
Navigateur Web
Pré-requis
Service web REST
Protocole HTTP

View Slide

5
Ressources : liens sur le Web
Articles, rapports et billets de blog
www.diva-portal.se/smash/get/diva2:1133465/FULLTEXT01.pdf
nordsecmob.aalto.fi/en/publications/theses2013/thesis_estep
aquil.io/articles/a-comparison-between-websockets-server-sent-events-and-polling
www.baeldung.com/java-websockets
www.baeldung.com/rest-vs-websockets
codeburst.io/polling-vs-sse-vs-websocket-how-to-choose-the-right-one-1859e4e13bd9
golb.hplar.ch/2018/02/Access-Server-Sent-Events-from-Java.html
Github
github.com/KeKsBoTer/websocket-vs-sse
Conférences vidéos
www.youtube.com/watch?v=MmVRkkZ7qHk&t=357s
Présentations
fr.slideshare.net/aneveu/le-streaming-dapi-pourquoi-et-comment-transformer-vos-apis-
statiques-en-donnes-temps-rel
fr.slideshare.net/arungupta1/nuts-and-bolts-of-websocket-devoxx-2014

View Slide

6
Plan du cours
Problématique et contexte
Solutions existantes pour communiquer via des flux
Technologies Push via HTTP/1, HTTP/2 et HTML5
WebSocket
SSE
gRPC
Technologies basées sur l’envoi de messages
AMQP

View Slide

Problématique : retourner de la donnée en continue
7
Réception de messages via
les réseaux sociaux (Twitter)
Afficher les
informations des
capteurs d’un
drone : altimètre,
GPS, vidéo
(Mission Planner)
Dialoguer avec de
l’audio et de la vidéo
(Zoom, Teams,
Discord…)

View Slide

Problématique : pourquoi c’est important ?
8
Une application doit donner l’impression d’être vivante
sans quoi l’utilisateur peut penser qu’il y a un problème
Retourner l’information la plus « fraîche » du serveur pour
des applications critiques (capteurs, valeurs boursières, etc.)
Avec les dispositifs mobiles, l’ère de la notification à
outrance pour éviter le fameux « Fear of Missing Out »
Éviter de solliciter le serveur inutilement pour éviter une
consommation d’énergie inutile

View Slide

Contexte : se poser les bonnes questions ?
9
À quelle fréquence de rafraichissement ?
Dès que possible ? Une fois par heure ? Une fois l’an ?
Aucune idée ?
Est-ce important de consommer la donnée tout de suite ?
Est-ce pour de l’affichage immédiat (station sol pour un drone) ?
Est-ce pour l’intégrer dans une chaîne de traitement (workflow) ?
Qui est responsable de la mise à jour de la donnée ?
Le responsable de l’affichage (Polling) ?
Celui qui possède l’information (Push) ?
Quelle technologie choisir ?
Une technologie énergivore (CPU, réseau…) ?

View Slide

Contexte : actuellement pour mettre à jour ?
10
La technique dite de Polling (tirer l’information) est la plus
classique (celle utilisée par les services web)
Mise en œuvre
Appuyer sur le bouton « refresh » du navigateur (web)
Lancer un processus qui toutes les n sec. invoque un service web
Variante
Long Polling

View Slide

Contexte : Polling (XHR-Polling)
11
Client
Principe : client sollicite le serveur même s’il n’y pas de
nouvelles données
Serveur
Temps
Temps
Requête AJAX
Réponse (vide)
Réponse (vide)
Requête AJAX
Nouvelles
informations
Délai avant
prochaine
requête
(généralement fixé)
Réponse (non vide)
Requête AJAX
L’accès aux
nouvelles données
ne pourra se faire
qu’à la prochaine
itération
Requête AJAX
Inconvénients
Nombreuses requêtes inutiles
Le délai entre chaque requête
difficile à prévoir
Au minimum une requête
pour chaque nouvelle
information du serveur
Peu devenir lent s’il y a
beaucoup de clients

View Slide

Contexte : Long Polling
12
Principe : la requête est interrompue côté serveur jusqu’à
l’arrivée d’une nouvelle donnée puis, envoi de la réponse
Client Serveur
Temps
Temps
Requête AJAX
Réponse
Nouvelles
informations
Requête Longue durée
Réponse Longue durée (non vide)
Nouvelles
informations
Réponse Longue durée (non vide)
Requête Longue durée
Requête longue
durée suspendue
jusqu’à la présence
d’une nouvelle
donnée
La réponse longue
durée est retournée
uniquement s’il y a
un résultat
Inconvénients
Une fois la nouvelle donnée
reçue réitérer l’opération
Au minimum une requête
pour chaque nouvelle donnée
Comet ?
Collection de techniques
avant HTML5 pour faire du
Long Polling

View Slide

Solutions existantes pour faire du Streaming d’API
13
Utilisation de technologies basées sur une communication de
type « Push Serveur »
Le dialogue est lancé par le serveur et notifie les clients
Quelles sont les technologies disponibles ?
Basées sur HTTP/1 et HTML5
Comet, WebHooks, WebSocket* et Server Sent Event (SSE)*
Basée sur HTTP/2
gRPC*
Basées sur l’envoi de messages
AMQP*
* Etudiées dans la suite

View Slide

mickael-baron.fr
mickaelbaron
WebSocket, SSE et gRPC

View Slide

15
Plan du cours
Technologies Push via HTTP/HTML5 et HTTP/2
Comprendre WebSocket et SSE
Support des navigateurs
Performances
À l’heure du choix ?
Implémentations disponibles

View Slide

WebSocket : généralités
16
WebSocket est à la fois un protocole de communication
et une API (premiers travaux 2008)
Protocole de communication
Full-duplex (bidirectionnel) sur TCP
Standardisé par IETF en 2011 : tools.ietf.org/html/rfc6455
Interface de programmation (API)
Standardisé par W3C en 2012 : www.w3.org/TR/websockets
Client Serveur
Client Serveur
Ou
Half Duplex
Client Serveur
Full Duplex
Et

View Slide

WebSocket : en détail
17
Nature des messages
Texte ou binaire (pour texte possibilité d’utiliser le format JSON)
Protocole
HTTP (le plus courant pour les navigateurs)
Autres protocoles supportés
Terminologie
WebSocket client
qui se connecte à un unique WebSocket serveur (l’URL via le
schème ws:// ou wss://)
ne peut envoyer un message qu’à un seul WebSocket serveur
WebSocket serveur
qui reçoit plusieurs connexions de WebSocket client
qui peut envoyer un message à un ou plusieurs WebSocket client
(broadcast)

View Slide

18
Requête et réponse HTTP
Cycle de vie (client et serveur) définie dans le standard W3C
onOpen : quand la connexion avec un WebSocket est réalisée
onMessage : quand un message est envoyé d’un WebSocket
onError : quand une erreur est provoquée
onClose : quand la connexion est fermée (par le client ou serveur)
Ne peut se reconnecter automatiquement
GET ws://localhost:8026/chatwebsocket/chat HTTP/1.1
Host: localhost:8026
Connection: Upgrade
Upgrade: websocket
Origin: http://localhost:8026
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: 2BmJzxYsb/ZfR3/ZAITKjA==
Sec-WebSocket-Extensions: permessage-deflate;
client_max_window_bits
HTTP/1.1 101 Web Socket Protocol Handshake
Connection: Upgrade
Sec-WebSocket-Accept: wonfz9jNMdz7L2HK9RewAt+QFvk=
Upgrade: websocket
Requête HTTP Réponse HTTP

View Slide

19
Client Serveur
Temps
Temps
onOpen (serveur)
onOpen (client)
Nouvelles
informations
onMessage (client)
Nouvelles
informations
onMessage (serveur)
Nouvelles
informations
onMessage (serveur)
Nouvelles
informations
onMessage (serveur)
Nouvelles
informations
onMessage (client)
onClose (serveur)
onClose (client)
Ouverture d’une connexion
entre un WebSocket client et
un WebSocket serveur
Principe : dès l’ouverture de la connexion WebSocket
communication bidirectionnelle depuis le client et le serveur
Communication full-duplex.
Possibilité d’envoyer et
recevoir en même temps des
messages
Possibilité d’envoyer ou de
recevoir des messages de
manière exclusive
La fin d’une connexion (peut être décidée
par le WebSocket client ou serveur)

View Slide

20
Support des navigateurs web
Source : caniuse.com/#search=websocket
Les navigateurs mobiles
prennent également en
charge WebSocket excepté
Opera Mini
Les WebSockets sont pris en
compte par tous les navigateurs
« desktop »
Un client
WebSocket n’est
pas forcément un
navigateur web

View Slide

Server-Sent Event : généralités
21
Server-Sent Event (SSE) est une technologie unidirectionnelle
proposée initialement par WHATWG en 2006
WHATWG : Web Hypertext Application Technology Working Group
Collaboration non officielle des développeurs de navigateurs web
Protocole de communication
HTTP (pas de protocole spécifique)
Uniquement serveur vers le client (exemple : navigateur web)
Interface de programmation (API)
Standardisé au W3C en 2015 : www.w3.org/TR/eventsource

View Slide

Server-Sent Event : où trouver des accès SSE
22
stream.wikimedia.org : flux sur les données de Wikimedia
stream.wikimedia.org/v2/stream/{stream}
emojitracker.com : utilisation des Emojis sur Twitter
emojitrack-gostreamer.herokuapp.com/subscribe/eps
À compléter …
$ curl -H "Accept:text/event-stream" \
https://stream.wikimedia.org/v2/stream/mediawiki.page-create

View Slide

Server-Sent Event : en détail
23
Description d’un événement
event : le type d’événement (ex : add, remove…)
data : le contenu du message envoyé par le serveur (ex : « Hello »)
id : un identifiant (utile en cas de reprise déconnexion pour savoir quel
était le dernier événement envoyé)
retry : temps en millisecondes pour une reconnexion du client vers
le serveur (en cas de panne)
‘:’ : commentaire
Nature de l’attribut data
Texte (possibilité d’utiliser le format JSON pour faire du binding)
Peut se reconnecter automatiquement via l’option retry
retournée par le dernier événement

View Slide

24
Requête et réponse HTTP
Cycle de vie (client uniquement) défini par le standard W3C
onOpen : quand une connexion au serveur est réalisée
onMessage : quand un message (événement) est reçu
onError : quand une erreur est déclenchée
GET /api/sse HTTP/1.1
Host: localhost:9992
Accept: text/event-stream
HTTP/1.1 200 OK
Content-Type: text/event-stream
Transfer-Encoding: chunked
: This is a new HelloWorld message and continue the
communication.
event: add-message
id: 123
retry: 1000
data: HelloWorld
Requête HTTP Réponse HTTP

View Slide

25
Principe : dès l’ouverture de la connexion Server-Sent Event
communication unidirectionnelle vers le client
Client Serveur
Temps
Temps
Requête (Accept: text/eventStream)
Nouvelles
informations
onOpen (client) (ContentType: text/eventStream)
onMessage (client)
Nouvelles
informations
onMessage (client)
Nouvelles
informations
onMessage (client)
onClose (client)
Ouverture d’une connexion entre
le client et le serveur
Nécessite d’utiliser un MediaType
particulier : text/eventStream
Communication unidirectionnelle.
Envoi de messages uniquement du
serveur vers le client
La fin de la connexion peut être
décidé par le client ou le serveur

View Slide

26
Support des navigateurs web
Source : caniuse.com/#search=server%20sent%20event
Server-Sent Event sont presque
pris en compte par tous les
navigateurs exceptés ceux de
Microsoft IE et Edge
Les navigateurs mobiles
prennent également en charge
SSE excepté Opera Mini
Possibilité d’utiliser des Polyfills qui sont
des fonctions permettant de simuler des
fonctionnalités non prises en compte par
les anciens navigateurs web

View Slide

gRPC : généralités
27

View Slide

WebSocket et Server-Sent Event : performances
29
Fournir des métriques de performance pour choisir la
technologie la plus adaptée selon un contexte donné
Différentes études sur les performances WebSocket et SSE
www.diva-portal.se/smash/get/diva2:1133465/FULLTEXT01.pdf
nordsecmob.aalto.fi/en/publications/theses2013/thesis_estep
Expérimentations disponibles
blog.arungupta.me/rest-vs-websocket-comparison-benchmarks
matthiasnehlsen.com/blog/2013/05/01/server-sent-events-vs-
websockets
github.com/KeKsBoTer/websocket-vs-sse

View Slide

30
Métrique étudiée
Temps total pour envoyer les messages
Comparatif (ce qui est comparable)
WebSocket client et serveur VS service web REST
WebSocket serveur VS Server-Sent Event
Protocole d’expérimentation
Varier le nombre de requête par client ou serveur (push)
Varier la valeur pour le « payload »
Mise en place de l’expérimentation
Code source : « coming soon »
Codes clients développés HTML/JS (version Java en préparation)
Codes serveurs développés en Java

View Slide

31
0,00
1,00
2,00
3,00
4,00
5,00
6,00
7,00
8,00
9,00
10 100 500 1000 5000 10000
Temps (s)
Number of requests (Payload = 1024 bytes)
REST(Chrome) WebSocket (Chrome)
0,00
0,20
0,40
0,60
0,80
1,00
10 100 500 1000 5000 10000
Temps (s)
Payload en bytes (Number of requests = 1000)
REST(Chrome) WebSocket (Chrome)
REST Versus WebSocket (envoi et réception)

View Slide

32
0,00
0,05
0,10
0,15
0,20
10 100 500 1000 5000 10000
Temps (s)
Payload en bytes (Number of requests = 1000)
REST (Chrome) SSE (Chrome)
0,00
0,05
0,10
0,15
0,20
0,25
0,30
0,35
0,40
0,45
10 100 500 1000 5000 10000
Temps (s)
Number of requests (Payload = 1024 bytes)
WebSocket (Chrome) SSE (Chrome)
WebSocket Versus SSE (serveur vers client en mode PUSH)

View Slide

WebSocket et SSEvent : à l’heure du choix
33
Caractéristiques Web Socket Server-Sent Event
Année de création 2008 2006
Nature du contenu Texte + Binaire Texte
Protocole TCP/HTTP (navigateur)
Autres protocoles supportés
HTTP
Communication Bidirectionnelle
Serveur <=> Client
Unidirectionnelle
Serveur => Client
Reprise à la connexion Non Oui
Support des navigateurs web Complète Ne supporte pas IE et Edge
Usages Chat de discussions, Outils
collaboratifs
Flux réseaux sociaux, valeurs
boursières, notifications
Performance (à relativiser …) Plus performant que SSE Moins performant que
WebSocket
Spécification du standard www.w3.org/TR/websockets www.w3.org/TR/eventsource

View Slide

Implémentations
34
La grande majorité des plateformes de développements
fournissent le support de WebSocket et SSE
Plateforme .NET
Plateforme Java
Plateforme PHP
Les API permettent de
Développer la partie serveur (WebSocket et SSE)
Développer la partie cliente
Mapping Objet / Classe (Marshall, Unmarshall)
Accéder à la couche HTTP
Dans le cours suivant, nous utiliserons la plateforme Java
Outillée, gratuite, accessible, légère, respect des standards

View Slide

mickael-baron.fr
mickaelbaron
Envoi de messages : AMQP

View Slide

36
Plan du cours
Technologies Push via HTTP/HTML5 et HTTP/2
WebSocket
SSE
gRCP
AMQP

View Slide

Envoi de messages : pourquoi ?
37
Postulats sur les technologies étudiées (REST, WS, SSE, etc.)
Le composant appelé existe et est disponible
Le réseau fonctionne et n’échoue pas à envoyer les messages
Intérêt d’une technologie basée sur l’envoi de message ?
Transmettre un message de manière répétée jusqu’à la réussite
Le composant émetteur ne se soucie pas du récepteur (asynchrone)
Communication asynchrone entre composants
Architecture à faible couplage
Favorise la montée en charge horizontale Horizontale
Verticale

View Slide

Envoi de messages : principaux concepts
38
Producteur
Diffuseur
Éditeur
Consommateur
Destinataire
Abonné
Technologies basées sur
l’envoi de messages
« Broker » de Messages
Message Message
Publier Consommer
?
Stratégie de choix d’un consommateur « Routage » ?
Gestion de la file d’attente « Queue » ?

View Slide

Envoi de messages : standards et produits
39
Nombreux standards ou produits (définissent leur propre
protocole) pour définir un système d’envoi de messages
Standards existants (non exhaustif et en vrac)
AMQP : Advanced Message Queuing Protocol
JMS : Jarkarta Messaging API
STOMP : Streaming Text Oriented Messaging Protocol
XMPP : Extensible Messaging and Presence Protocol
MQTT : Message Queuing Telemetry Protocol

View Slide

Envoi de messages AMQP : généralités
40
AMQP est l’acronyme de Advanced Message Queuing Protocol
Standardisé à partir de 2003 au sein de l’organisme OASIS
Site web : www.amqp.org
Version courante : 1.0, mais la version la plus utilisée et
complète est la 0.9.1
Pourquoi AMQP ?
Le plus largement supporté par les outils
Le plus complet

View Slide

Envoi de messages AMQP : concept message
41
Un message est composé des informations suivantes
Des champs d’en-tête
La charge utile (payload)
Une clé de routage (Routing Key)
Les informations du message sont
importantes pour aider à
connaître le(s) consommateur(s) en fonction
de la stratégie employée

View Slide

Envoi de messages AMQP : concepts
42
Producteur Consommateur
Message Message
Publier Consommer
« Broker » de Messages
respectant le standard AMQP
Routeur de
message
« Echange »
File d’attente
« Queue »
File d’attente
« Queue »
File d’attente
« Queue »
Un producteur publie un message dans un Exchange
(routeur de messages)
En se basant sur des bindings (conditions de routage) le
message est routé vers une file d'attente
Un consommateur récupère un message d'une Queue (file
d’attente)
Router
Conditions de routage
« Bindings »

View Slide

Envoi de messages AMQP : comparaison avec les emails
43
Message ✉ AMQP
File d’attente (Queue)
Consommateur
Routeur de ✉ (Exchange)
Clé de routage
Message Email
Boite de messagerie
Client d’email (Thunderbird)
Mail Transfert Agent (MTA)
To, Cc, Bcc

View Slide

Envoi de messages AMQP : Exchanges en détail
44
Les messages sont publiés dans un Exchange (routeur
de messages)
La déclaration d’un Exchange se fait via une condition de
routage (Binding) et trois informations sont nécessaires
Nom de la file d’attente (Queue)
Type (Direct, Fanout, Topic ou Headers)
Condition qui peut être fonction de la clé de routage du message
Queue.Bind TO WHERE

View Slide

Queue.Bind Queue1
TO amq.direct
WHERE Routing-Key = value1
Envoi de messages AMQP : Type d’Exchanges (partie 1)
45
Direct : délivre le message si Routing-Key matche une valeur
« Echange »
Direct
« Queue »
Queue1
« Queue »
Queue2
Routing-Key = value1
« Queue »
Queue3
Queue.Bind Queue2
TO amq.direct
WHERE Routing-Key = value1
Fanout : délivre le message à toutes les queues « bindées »
« Echange »
Fanout
« Queue »
Queue1
« Queue »
Queue2
« Queue »
Queue3
Queue.Bind Queue1
TO amq.fanout
Queue.Bind Queue2
TO amq.fanout
Routing-Key si
présente non utilisée

View Slide

Envoi de messages AMQP : Type d’Exchanges (partie 2)
46
Topic : délivre le message si Routing-Key matche un pattern
Queue.Bind Queue1
TO amq.topic
WHERE Routing-Key = foo.*
« Echange »
Topic
« Queue »
Queue1
« Queue »
Queue2
Routing-Key = foo.bar
« Queue »
Queue3
Queue.Bind Queue2
TO amq.topic
WHERE Routing-Key = #
Headers : délivre le message si les en-têtes matchent un pattern
« Echange »
Headers
« Queue »
Queue1
« Queue »
Queue2
Headers : format=pdf
type=report
« Queue »
Queue3
Queue.Bind Queue2
TO amq.match
WHERE format=pdf
type=report
x-match=all

View Slide

Envoi de messages AMQP : consommateur
47
Un consommateur est une connexion à une file d’attente
Une application cliente peut créer plusieurs consommateurs
Un consommateur est relié à une seule file d’attente
Plusieurs consommateurs peuvent être reliés à une file
d'attente, mais un seul message est délivré
Si plusieurs messages à délivrer, c'est en mode « chacun
son tour » (round-robin)
Pour avoir plusieurs consommateurs qui reçoivent un
message en même temps il faut plusieurs files d’attente

View Slide

Envoi de messages AMQP : patron de conception
48
L’usage d’une technologie basée sur le standard AMQP à
amener à développer des patrons de conception
Ce sont des modèles de communication couramment utilisés
dans les architectures logicielles basées sur les services
Competing Consumers (File d’attente de travail)
Pub-Sub (Producteur-Consommateurs)
Topics
Request/Response

View Slide

Modèle de communication AMQP : Competing Consumers
49
Quand ? répartir une tâche sur plusieurs consommateurs
Favorise la montée en charge (« à plusieurs on travaille plus vite »)
Evite d’attendre la fin du traitement de la tâche
1
2
3
Une seule file d’attente
Une tâche décrite par
un ensemble de
messages
Exemple : compresser des vidéos
Producteur N consommateurs
(basé sur le même code
client)
Messages envoyés de
manière séquentielle
(round-robin)
« Echange »
Direct

View Slide

Modèle de communication AMQP : Pub/Sub
50
Quand ? Avertir en même temps plusieurs consommateurs
Favorise des traitements différents d’une même tâche
Autant de file d’attente
que de consommateurs
un ensemble de
messages
Producteur
N consommateurs
(basé sur des codes clients
différents)
1
1
Exemple : gestion de logs avec des adapters différents
« Echange »
Fanout

View Slide

Modèle de communication AMQP : Topics
51
Quand ? Avertir des consommateurs en fonction de sujets
Permet au producteur de cibler indirectement des consommateurs
Autant de file d’attente
que de consommateurs
un ensemble de
messages
Producteur
N consommateurs
(basé sur des codes clients
différents)
1
2
« Echange »
Topic
*.cuisine
Exemples
messagerie instantanée via un abonnement par sujet
Internet Of Thing (IOT)
*.bricolage

View Slide

Modèle de communication AMQP : Request/Reply
52
Quand ? Être averti qu’un consommateur à traiter la tâche
Permet au consommateur de communiquer avec le producteur
Deux files d’attente
Producteur et
Consommateur
« Echange »
Direct
« Echange »
Direct
Producteur et
Consommateur
Message consommé quand le
consommateur est disponible
(ne traite pas une réponse)
Exemples
gestion d’une transaction
dans une chaîne de traitement

View Slide

Envoi de messages : bilan
53
Standards (AMQP) qui définissent un cadre d’utilisation
Modèles de communication qui permettent de construire des
architectures en fonction des besoins applicatifs
Des produits qui ne s’appuient pas sur des standards
Kafka, Google Cloud Pub/Sub, Microsoft Azure Service Bus
Beaucoup de choses à traiter
Gestion des erreurs (que se passe-t-il si la file d’attente est saturée ?)
La mise en œuvre (voir cours suivant)

View Slide

Streaming HTTP : savoir communiquer via des flux

Streaming HTTP : savoir communiquer via des flux

Mickael BARON

More Decks by Mickael BARON

Other Decks in Programming

Featured

Transcript