Streaming HTTP : savoir communiquer via des flux

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

View Slide

Streaming - 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
@mickaelbaron
mickael-baron.fr

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
Java, Apache Kafka
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/HTML ‘5’
WebSocket
SSE
Technologies basées sur Publish-subscribe
AMQP via Apache Kafka

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/HTML
Comet, WebHooks, WebSocket* et Server Sent Event (SSE)*
Basées sur le patron Publish/Subscribe
PubSubHubbub, AMQP* (Apache Kafka) * Etudiées dans la suite

View Slide

SOA – Streaming
Technologies HTML5 avec WebSocket et SSE

View Slide

15
Plan du cours
Comprendre WebSocket et SSE
Support des navigateurs
Performances
À l’heure du choix ?
Implémentations disponibles
Technologies basées sur Publish-Subscribe

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/recentchange
emojitracker.com : utilisation des Emojis sur Twitter
emojitrack-gostreamer.herokuapp.com/subscribe/eps
À compléter …

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

WebSocket et Server-Sent Event : performances
27
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

28
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

29
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

30
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
31
Caractéristiques Web Socket Server-Sent Event
Année de création 2008 2006
Nature du contenu Texte + Binaire Texte
Protocole 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
32
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

SOA – Streaming
Publish-Subscribe

View Slide

34
Plan du cours
WebSocket
SSE
Technologies basées sur Publish-subscribe
AMQP
Apache Kafka

View Slide

35

View Slide

36
• https://blog.zwindler.fr/2019/04/16/suivez-le-lapin-orange-intro-et-bonnes-pratiques-dinfra-rabbitmq/
• AMQP
• DDS
• MQTT
• https://zeromq.org/
• RabbitMQ

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