real-time applications avec la spécification java (jsr 356) et le protocole websocket (rfc 6455)

REAL-TIME APPLICATIONS

JSR-356Java API for WebSocket

Par : Ouadie LAHDIOUI

RFC-6455WebSocket Protocol

Le : 29/10/2015

CE QUE VOUS VERREZ PENDANT CETTE PRÉSENTATION

SOMMAIRE

1

+ Les limitations du protocole HTTP 101

+ Les techniques de push de données

+ WebSocket - Kézako ?

+ La spécification IETF RFC 6455 « The WebSocket Protocol »

+ Le standard W3C « WebSocket JavaScript API »

+ JSR 356 « Java API for WebSocket »

+ Performances : WebSocket vs REST

+ Implémentations des WebSockets

+ Backend as service : La suite de la guerre du temps réel

+ Challenges d’une Application temps réel

+ Démonstration

FireBase, PubNub, Pusher et RethinkDB

Polling, Long-polling, Streaming, Comet, SSE(Server-Sent Events)

benchmark

Talk is cheap show me the code

Grizzly, Tomcat, Netty, Atmosphere, GlassFish, Tyrus Project et Jetty

HTTP pipelining et Keep Alive

Real-Time applications avec la spécification Java (JSR 356) et le protocole WebSocket (RFC 6455)

1/4

LES LIMITATIONS DU PROTOCOLE HTTP 101

2

+ HTTP 101 = HTTP 1.0 et HTTP 1.1

+ Le HTTP 1.0 crée une connexion TCP pour chaque requête (page, image, etc …)

+ Le HTTP 1.1 des connexions persistantes pour obtenir les autres éléments de la page


connexion persistante (keepalive)

2/4


2

+ Pipelining HTTP : une technique qui consistant à combiner plusieurs requêtes HTTP dans une seule connexion TCP


3/4


3

+ HTTP est un protocole sans état (stateless protocol) qui fonctionne sur le modèle requête/réponse :

+ HTTP n’est pas optimisé pour les applications qui ont d’important besoins de communication temps réel bi-directionnelle (duplex)


HTTP est unidirectionnel : Le server ne peut pas initier un transfert de données

4/4

LES LIMITATIONS DU PROTOCOLE HTTP

4

+ Half duplex : Le client envoie une requête au serveur qui répond en lui renvoyant une réponse. Le client doit attendre la réponse. La transmission de données ne peut se faire que dans une direction en même temps.

+ Verbeux : Chaque requête et réponse HTTP doit avoir des en-têtes (headers). Ce qui augmente le trafic sur le réseau.

+ Il n'est pas possible d'utiliser un mode push de la part du serveur : Le serveur envoie à son initiative des données au client.

+ HTTP a été conçu pour obtenir des éléments du web. Il répond à de nombreux besoins mais il possède plusieurs inconvénients notamment pour une utilisation dans une application web interactive :


1/5

LES TECHNIQUES DE PUSH DE DONNÉES

5

+ Plusieurs techniques ont été développées pour contourner les limitations du protocole HTTP :

+ Polling : Le client effectue périodiquement des requêtes synchrones au serveur pour obtenir des données. Elle nécessite beaucoup de connexions selon la fréquence utilisée par le client. Cette technique peut être intéressante si les données sont périodiquement modifiées côté

serveur.

+ Ajax Polling

+ JSONP Polling

+ Piggyback

+ …


2/5


6

+ Long polling : Le client ouvre une connexion et envoie une requête HTTP au serveur qui ne renvoie la réponse

que si un événement force l'envoi de données au client ou après un certain timeout. Le nombre de requêtes/réponses peut ainsi être réduit sauf si le nombre d'événements est très

important.


3/5


7

+ Streaming : Le client envoie une requête au serveur qui maintient le flux de la réponse ouvert en y envoyant

des données au besoin. Cette technique repose sur l’utilisation de connexion http persistantes. Elle pose généralement des soucis avec certains éléments réseaux comme les firewalls ou les

proxys


4/5


9

+ Reverse Ajax ou bien Comet: Une technique combinant Ajax et long polling Un concept dont le but est de permettre à un serveur d'envoyer à son initiative des données à un

navigateur. Plusieurs techniques sont utilisées pour répondre au concept Comet :

+ Forever Iframes

+ Multi-part XMLHttpRequest

+ Hidden Iframes


5/5


8

+ Server Side Event : Un mécanisme de communication comparable à JMS : les clients s'inscrivent à un bus de

messages auprès du serveur, qui peut alors leur transmettre des données de manière asynchrone via HTTP (= unidirectionnelle)

L'API SSE est normalisée dans le cadre de HTML5 par le W3C.


1/1

WEBSOCKET - KÉZAKO ?

10

+ Une technologie permet d'ouvrir une connexion bi-directionnelle permanente entre un client et un serveur utilisant un canal en mode full duplex.

+ Permet le développement de véritables applications temps-réel performantes : application de suivi des cours boursiers, ou des applications multi-utilisateurs (chat, jeux en ligne...).


1/1

COMPATIBILITÉ NAVIGATEUR

11Real-Time applications avec la spécification Java (JSR 356) et le protocole WebSocket (RFC 6455)

+ http://caniuse.com

12Source des images : kaazing.com

1/4 THE WEBSOCKET PROTOCOL

LA SPÉCIFICATION IETF RFC 6455

13

+ Le protocole WS permet l'échange de données entre un client et un serveur de manière asynchrone, bidirectionnelle en mode full duplex utilisant une connections TCP

+ La spécification du protocole WebSocket est définie dans la RFC 6455, publiée en décembre 2011 par Internet Engineering Task Force (IETF)

+ WS est :

+ basé sur 1 unique connexion TCP entre 2 peers

+ bi-directionnel : le client peut envoyer un message au serveur et le serveur peut envoyer un message au client

+ full-duplex : le client peut envoyer plusieurs messages vers le serveur et le serveur vers le client sans attendre de réponse l’un de l’autre




14

+ Le protocole WebSocket fonctionne en 2 phases : handshake et data transfer

+ HTTP half-duplex

+ WebSocket full-duplex




15

+ Handshake : Unique échange requête/réponse HTTP entre l’initiateur de la connexion (peer client) et le peer serveur. Cet échange HTTP utilise le mécanisme HTTP Upgrade L’Upgrade HTTP permet au client de communiquer avec le serveur pour lui demander de changer de

protocole de communication

+ Requête HTTP Handshake

+ Réponse HTTP Handshake





+ Data transfer Une fois le handshake acceptée, une gestion de callback est activée pour initier la communication Les 2 peers s'échangent des messages dans une communication bi-directionnelle et full-duplex

WEBSOCKET JAVASCRIPT API

LE STANDARD W3C

18

+ Pour communiquer avec un serveur via le protocole WS, il est nécessaire d’utiliser une API cliente en Javascript.

+ L’interface WebSocket propose des gestionnaires d'évènements pour s’adapter aux méthodes du cycle de vie des WebSocket :

+ l’Event-Handler onopen est appelé lorsqu’une nouvelle connexion est initiée

+ l’Event-Handler onerror est appelé lorsqu’une erreur est reçue pendant la communication

+ l’Event-Handler onmessage est appelé lorsqu’un message est reçu


JAVA API FOR WEBSOCKET

JAVA SPECIFICATION REQUESTS 356

19

+ Le W3C définit comment utiliser WebSocket en Javascript, le Java Communitee Process (JCP) fait de même pour le monde Java via la JSR 356

+ La spécification JSR 356 définit une API Java pour WebSocket qui propose :

+ La création d’un WebSocket Endpoint

+ L’utilisation l’approche par annotation Java ou par programmation

+ La possibilité d’envoyer et de consommer des messages en synchrone ou en asynchrone

+ La configuration et la gestion des sessions WebSocket (timeout, cookies…)

+ Une intégration dans Java EE Web Profile


JAVA SPECIFICATION REQUESTS 356

20

JAVA API FOR WEBSOCKET


1/1

PERFORMANCES : WEBSOCKET VS REST

21

+ Benchmark publié par Arun Gupta sur GitHub


1/1

IMPLÉMENTATIONS DES WEBSOCKETS

22

+ Plusieurs implémentations des WebSockets sont disponibles :


1/1 BACKEND AS SERVICE

LA SUITE DE LA GUERRE DU TEMPS RÉEL

23

+ Certaines solutions proposent du temps réel et le stockage de fichiers décentralisé sur leur infrastructure :

+ Concept de « room » pour publier et retrouver les messages

+ BaaS : Backend as service

Real-Time applications avec la spécification Java pour les WebSockets (JSR 356) et le protocole WebSocket (RFC 6455)

PROXY, REVERS PROXY, FIREWALL, LOAD BALANCING…

CHALLENGES D’UNE APPLICATION TEMPS RÉEL


LIVRES

25

+ Java WebSocket Programming + The Definitive Guide to HTML5 WebSocket


MERCI POUR VOTRE ATTENTION

Real-Time applications avec la spécification Java pour les WebSockets (JSR 356) et le protocole WebSocket (RFC 6455) 26

Références :• Internet Engineering Task Force (IETF) RFC 6455: http://tools.ietf.org/html/rfc6455• W3C The WebSocket API : http://www.w3.org/TR/websockets/• Java Specification Requests 356 “Java API for WebSocket” : http://jcp.org/en/jsr/detail?id=356• HTML5 Web Sockets Specification: http://dev.w3.org/html5/websockets/• Server Sent Events : http://www.w3.org/TR/2011/WD-eventsource-20110208/

http://tools.ietf.org/html/rfc6455



http://www.w3.org/TR/websockets/

http://jcp.org/en/jsr/detail?id=356

http://jcp.org/en/jsr/detail?id=356

http://dev.w3.org/html5/websockets/

http://dev.w3.org/html5/websockets/

http://www.w3.org/TR/2011/WD-eventsource-20110208/

http://www.w3.org/TR/2011/WD-eventsource-20110208/