push to the web - websocket et signalr

Push to the Web - Le protocole WebSocketet la librairie SignalR

Dominic Marchand

9 février 2015

À propos de moi

• Développeur web depuis 1996• Réseautique / DevOps• Agences et médias• Stack Microsoft• Aujourd’hui : backend électoral

pour Radio-Canada

@domimarch

Aujourd’hui – Push to the web

• Scénarios typiques

• D’où on part

• WebSocket

• SignalR• Les bases• Connexions• Groupes• Sécurité• Performance / Scaling

• Conclusion

Scénarios typiques

• HTTP = OK pour énormément de cas d’utilisation, mais pas toujours…

• Discussions et messagerie en ligne (webchat)

• Informations financières et boursières (stock tickers)

• Enchères

• Jeux

• Résultats sportifs et électoraux

• Consoles de monitoring et autres dashboards dynamiques

• Capteurs (sensors)

WebSocket

• Protocole/API issu du standard HTML5 offrant un canal de communication full-duplex sur une connexion TCP

• Seul lien avec HTTP : le handshake se fait au moyen d'une requête HTTP/S de type UPGRADE

• Communication se fait en TCP sur le port 80/443, donc firewall-friendly

WebSocket – Support

CLIENT

• Firefox 6

• Safari 6

• Chrome 14

• Opera 12.10

• IE 10

• Inclut les versions mobiles de ces navigateurs

SERVEUR

• IIS 8

donc Windows 8 ouWindows Server 2012

WebSocketDEMO : JabbR

SignalR

• Librairie ASP.NET pour applications real-time, 2-way

• Développement et support par Microsoft

• .NET Framework 4

• Open Source

• Event-driven

• Asynchronous

• Scalable

• Multiple transports

• Librairies client pour javascript (browser) et .NET (server as client, WPF, WinForms, WinRT, WinPhone, Console, etc.) via Nuget

SignalRDEMO : Setup + Hubs

SignalR – Transports

• Support pour 4 différents types de transport; tout est géré de façon transparente par SignalR (aucune configuration)

• Niveaux disponibles (dans cet ordre)• WebSocket

[ requiert IIS 8 sur le serveur et .NET 4.5 pour le runtime ]

• Server Sent Events / EventSource[ sans cross domain; IE ne supporte pas ]

• Forever Frame[ utilisation d’un <iframe />, IE seulement ]

• Ajax Long Polling

SignalRDEMO : Transports

SignalR – Cycle de vie d’une connexion

• 3 niveaux d’abstraction de connexions• SignalR (lien logique entre un client et un URL, y’a un ConnectionId unique

pour chaque connexion client/serveur)

• Transport (lien logique qui est lié au type de transport utilisé)

• Physique (câble réseau, lien wifi, routeurs, etc.)

• Une perte de connexion du réseau PHYSIQUE n’implique PAS NÉCESSAIREMENT une perte de la connexion TRANSPORT


• Start – déclenche le processus de handshake entre le client et le serveur, c’est là que la sélection du type de transport optimal s’effectue

• ConnectionSlow – mécanisme de keepalive et disconnectTimeout – 10 secondes par défaut

• Reconnecting – handshake est essayé à nouveau – la connexion logique n’est pas encore « perdue »

• OnReconnected – indique à la connexion logique (sur le serveur) que le client a réussi à se rebrancher

• OnDisconnected (serveur) / Closed (client) – la connexion physique a été perdue et le transport est fermé

• Stop – la connexion logique SignalR est complètement terminée (volontaire ou non)


• Les valeurs par défaut de KeepAlive (10 sec.), DisconnectTimeout(30 sec.) et ConnectionTimeout (110 sec., utilisé pour le long polling) peuvent être modifiées

• Les événements ConnectionSlow, Reconnecting et Disconnected peuvent être utilisés pour informer le client de ce qui se passe

• On peut automatiquement ré-appeler Start() dans le handlerDisconnected pour continuellement reconnecter un client

• Depuis SignalR 2.1, on peut aussi savoir si la fin d’une connexion était voulue ou pas (stopCalled sur serveur, lastError sur client)

• Une option de debugging avancé est disponible pour voir plus de détails

SignalRDEMO : Cycle de vie d’une connexion

SignalR - Groupes

• Un groupe représente un sous-ensemble d’utilisateurs à qui envoyer certains messages, donc qu’on ne veut pas broadcaster à tous (une chat room, un item spécifique dans une plate-forme d’enchères, une circonscription dans le cadre d’une élection, une partie spécifique pour un service de résultats sportifs, etc.)

• Les groupes sont créés et supprimés automatiquement par SignalR et il n’y a pas d’API de gestion des groupes

• Aucune persistence d’un « abonnement » à un groupe au-delà de la connexion logique SignalR, mais supporté lors d’un OnReconnected

• Ce n’est PAS un mécanisme de sécurité

SignalRDEMO : Groupes

SignalR - Sécurité

• Y’a aucune mécanique d’authentification des utilisateurs dans SignalR; tout doit se faire en amont, dans l’application web qui « host » la couche SignalR

• On peut cependant appliquer l’attribut Authorize sur un Hub ou sur une méthode spécifique d’un Hub

• Si de l’information sensible est échangée par SignalR, il est fortement recommandé d’utiliser le protocole HTTPS/SSL/TLS qui fera aussi en sorte que les échanges WebSocket seront sécurisés (wss:// au lieu de ws://)

• Les requêtes cross domain sont refusées par défaut; dans la mesure du possible, laisser tel quel mais c’est possible de les autoriser

• Si on ne veut pas exposer tous les noms de méthodes disponibles sur un Hub, on peut désactiver la génération dynamique de proxy pour javascript

• Ne pas retourner les exceptions aux clients; utilisez plutôt la méthode DisplayError dans vos catch()

SignalRDEMO : Sécurité

SignalR - Performance

• Fréquence élevée (plusieurs messages par seconde) ? Batch

• Réduire la taille des messages

• Paramètres de performance sur le serveur• SignalR : DefaultMessageBufferSize

• IIS : appConcurrentRequestLimit

• ApplicationPool : queueLength et maxConcurrentRequestsPerCPU

• Utiliser WebSocket (IIS 8 + .NET 4.5) si possibleCompteurs de performance disponibles (Microsoft.AspNet.SignalR.Utils)

• Outils de load testing : Crank

http://www.asp.net/signalr/overview/getting-started/tutorial-high-frequency-realtime-with-signalr

https://www.asp.net/signalr/overview/performance/signalr-connection-density-testing-with-crank

SignalR - Scaling

• Si un serveur ne suffit plus, Scaleout !

• Trois backplanes disponibles (via Nuget) :• Azure Service Bus

• Redis

• SQL Server

• Une seule ligne de configuration !GlobalHost.DependencyResolver.UseServiceBus(connString, "MyApp");

• Attention : backplane peut devenir un bottleneck

SignalR - Conclusion

• Idéal pour les scénarios évoqués au début de la session

• Même si WebSocket n’est pas disponible (IIS < 8 et .NET < 4.5), allez-y quand même

• Facile à implémenter, autant du côté serveur que client

• Pour des scénarios à petit ou moyen volume, c’est plug-and-play

• Pour des scénarios à grand volume, il faudra assurément fine tuner les serveurs

• Pour des scénarios à grande fréquence, il faudra probablement ajuster le code

• Bien documenté et communauté active d’utilisateurs

Merci :-)http://asp.net/signalr

http://asp.net/signalr

push to the web - websocket et signalr

Technology