Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Streaming HTTP : savoir communiquer via des flux

Mickael BARON
November 19, 2020

Streaming HTTP : savoir communiquer via des flux

Ce support de cours est une introduction aux technologies HTTP pour savoir communiquer via des flux et réaliser des communications de type "Push Serveur". Après avoir dressé les besoins de ce type de technologies, une présentation détaillée est donnée sur WebSocket et Server-Sent Event.

Mickael BARON

November 19, 2020
Tweet

More Decks by Mickael BARON

Other Decks in Programming

Transcript

  1. 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

  2. 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. Streaming - M. Baron - Page
    mickael-baron.fr @mickaelbaron
    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. Streaming - M. Baron - Page
    mickael-baron.fr @mickaelbaron
    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. Streaming - M. Baron - Page
    mickael-baron.fr @mickaelbaron
    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. Streaming - M. Baron - Page
    mickael-baron.fr @mickaelbaron
    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

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

  8. Streaming - M. Baron - Page
    mickael-baron.fr @mickaelbaron
    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

  9. Streaming - M. Baron - Page
    mickael-baron.fr @mickaelbaron
    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

  10. Streaming - M. Baron - Page
    mickael-baron.fr @mickaelbaron
    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

  11. Streaming - M. Baron - Page
    mickael-baron.fr @mickaelbaron
    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

  12. Streaming - M. Baron - Page
    mickael-baron.fr @mickaelbaron
    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

  13. Streaming - M. Baron - Page
    mickael-baron.fr @mickaelbaron
    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

  14. SOA – Streaming
    Mickaël BARON – Février 2019 (Rév. Novembre 2020)
    mailto:[email protected] ou mailto:[email protected]
    @mickaelbaron mickael-baron.fr
    Technologies HTML5 avec WebSocket et SSE

    View Slide

  15. Streaming - M. Baron - Page
    mickael-baron.fr @mickaelbaron
    15
    Plan du cours
    † Problématique et contexte
    † Solutions existantes pour communiquer via des flux
    † Technologies Push via HTTP/HTML ‘5’
    † Comprendre WebSocket et SSE
    † Support des navigateurs
    † Performances
    † À l’heure du choix ?
    † Implémentations disponibles
    † Technologies basées sur Publish-Subscribe

    View Slide

  16. Streaming - M. Baron - Page
    mickael-baron.fr @mickaelbaron
    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

  17. Streaming - M. Baron - Page
    mickael-baron.fr @mickaelbaron
    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. Streaming - M. Baron - Page
    mickael-baron.fr @mickaelbaron
    WebSocket : en détail
    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. Streaming - M. Baron - Page
    mickael-baron.fr @mickaelbaron
    WebSocket : en détail
    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. Streaming - M. Baron - Page
    mickael-baron.fr @mickaelbaron
    WebSocket : en détail
    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

  21. Streaming - M. Baron - Page
    mickael-baron.fr @mickaelbaron
    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

  22. Streaming - M. Baron - Page
    mickael-baron.fr @mickaelbaron
    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

  23. Streaming - M. Baron - Page
    mickael-baron.fr @mickaelbaron
    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. Streaming - M. Baron - Page
    mickael-baron.fr @mickaelbaron
    Server-Sent Event : en détail
    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. Streaming - M. Baron - Page
    mickael-baron.fr @mickaelbaron
    Server-Sent Event : en détail
    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. Streaming - M. Baron - Page
    mickael-baron.fr @mickaelbaron
    Server-Sent Event : en détail
    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

  27. Streaming - M. Baron - Page
    mickael-baron.fr @mickaelbaron
    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. Streaming - M. Baron - Page
    mickael-baron.fr @mickaelbaron
    WebSocket et Server-Sent Event : performances
    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. Streaming - M. Baron - Page
    mickael-baron.fr @mickaelbaron
    WebSocket et Server-Sent Event : performances
    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. Streaming - M. Baron - Page
    mickael-baron.fr @mickaelbaron
    WebSocket et Server-Sent Event : performances
    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

  31. Streaming - M. Baron - Page
    mickael-baron.fr @mickaelbaron
    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

  32. Streaming - M. Baron - Page
    mickael-baron.fr @mickaelbaron
    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

  33. SOA – Streaming
    Mickaël BARON – Février 2019 (Rév. Novembre 2020)
    mailto:[email protected] ou mailto:[email protected]
    @mickaelbaron mickael-baron.fr
    Publish-Subscribe

    View Slide

  34. Streaming - M. Baron - Page
    mickael-baron.fr @mickaelbaron
    34
    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
    † Apache Kafka

    View Slide

  35. Streaming - M. Baron - Page
    mickael-baron.fr @mickaelbaron
    Technologies basées sur Publish-Subscribe
    35

    View Slide

  36. Streaming - M. Baron - Page
    mickael-baron.fr @mickaelbaron
    Technologies basées sur Publish-Subscribe
    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