Push to the web - Websocket et SignalR
-
Upload
msdevmtl -
Category
Technology
-
view
724 -
download
1
Transcript of Push to the web - Websocket et SignalR
À 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)
D’où on part
• HTTP = stateless
• Serveur ne peut pas « initier » un échange
• Solutions inélégantes, workaroundsComet | HTTP server push | Pushlet | Long polling | Flash XMLSocket relays
• Autres protocolesIRC | BitTorrent | Push Access Protocol
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
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
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
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
SignalR – Cycle de vie d’une connexion
• 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)
SignalR – Cycle de vie d’une connexion
• 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
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é
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()
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
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