Un tour d'horizon neutre, avec sources citées, des bibliothèques WebSocket disponibles pour les développeurs .NET en 2026 : sgcWebSockets .NET, System.Net.WebSockets, ASP.NET Core SignalR, WebSocket-Sharp, Fleck et Watson WebSocket. Chaque affirmation sur une fonctionnalité renvoie à la documentation officielle du projet.
Un résumé d'un paragraphe pour chaque bibliothèque, avec un lien vers la documentation officielle ou le dépôt.
eSeGeCe · Commercial
Suite de composants C# qui reflète le produit Delphi. Mêmes noms de classes Tsgc*, même couverture de protocoles : client et serveur WebSocket (TCP et HTTP.SYS), MQTT, AMQP, STOMP, WAMP, HTTP/2, OAuth2, JWT, clients IA/LLM (OpenAI, Anthropic, Gemini, DeepSeek, Grok, Ollama, Mistral, MCP), serveurs WebRTC, plus les 30+ intégrations d'API d'échanges crypto et SaaS. Cible .NET Framework 2.0–4.8.1, .NET Core 1.0–3.1, .NET 5/6/7/8/9 et .NET Standard 1.6/2.0.
Microsoft · MIT (partie de .NET)
L'API WebSocket de bas niveau intégrée directement dans .NET. Elle fournit ClientWebSocket pour les clients et une classe serveur abstraite WebSocket consommée par ASP.NET Core, Kestrel et HttpListener. Le framing RFC 6455 et per-message-deflate (WebSocketDeflateOptions) sont gérés nativement.
Microsoft · MIT (partie d'ASP.NET Core)
Le framework temps réel de haut niveau de Microsoft. Construit par-dessus WebSocket, Server-Sent Events et Long Polling (dans cet ordre de repli) ; expose une API RPC de type hub plutôt que des trames brutes. Protocoles de hub JSON ou MessagePack ; passe à l'échelle via Azure SignalR Service ou un backplane Redis.
sta.blockhead · MIT
Client et serveur WebSocket C# open source ancien. Cible .NET Framework 3.5 et ultérieur (ainsi que Mono), implémente RFC 6455 avec per-message-deflate (sans context takeover). Le dépôt GitHub n'a pas de releases taguées — les utilisateurs prennent généralement le dernier master ou figent un commit hash.
Jason Staten / communauté · MIT
Bibliothèque WebSocket C# côté serveur uniquement, qui ne dépend ni de HttpListener ni de HTTP.SYS — elle écoute sur un socket brut. Pas de côté client, pas de serveur HTTP, et pas de terminaison TLS intégrée en dehors du chemin de certificat X509. La dernière release taguée est 0.14.0 datant d'octobre 2016.
Joel Christner · MIT
Client et serveur WebSocket C# asynchrones avec une API basée sur les événements. Cible .NET Framework 4.8 et .NET 7.0. Le dépôt a été archivé en mai 2024 avec une note indiquant qu'il a été intégré à Watson Webserver.
Un point () signifie que le projet documente un support natif. Un tiret (—) signifie que le projet ne le fournit pas nativement. Un tilde (~) signifie partiel / via un add-on / non explicitement documenté — consulte la section Sources pour ce que nous avons pu vérifier.
| Fonctionnalité | sgcWebSockets .NET | System.Net.WebSockets | ASP.NET Core SignalR | WebSocket-Sharp | Fleck | Watson WebSocket |
|---|---|---|---|---|---|---|
| Client WebSocket Client RFC 6455 | — | |||||
| Serveur WebSocket Serveur RFC 6455 | ||||||
| TLS 1.3 TLS 1.3 pris en charge par le transport fourni | ~ | ~ | ||||
| Client HTTP/2 Client HTTP/2 natif (RFC 7540 / 9113) | ~ | — | — | — | — | |
| MQTT Client MQTT 3.1.1 / 5.0 intégré | — | — | — | — | — | |
| AMQP Client AMQP 0.9.1 / 1.0 intégré | — | — | — | — | — | |
| STOMP Client STOMP 1.0 / 1.2 intégré | — | — | — | — | — | |
| WAMP Client WAMP v1 / v2 intégré | — | — | — | — | — | |
| Push serveur / streaming Connexion push ou streaming longue durée | ||||||
| Reconnexion automatique Reconnexion automatique / watchdog client intégrés | — | — | — | — | ||
| per-message-deflate (RFC 7692) Extension de compression WebSocket | ~ | — | ~ | |||
| Multiplateforme Win / macOS / Linux / iOS / Android | ~ | |||||
| Usage commercial autorisé La licence autorise un usage commercial à code source fermé | ||||||
| Code source disponible Le code source de la bibliothèque est visible pour le développeur | ||||||
| Maintenance active Release ou activité taguée au cours des 12 à 18 derniers mois | ~ | — | — | |||
| Modèle de licence Type de licence | Commercial | MIT (partie de .NET) | MIT (partie d'ASP.NET Core) | MIT | MIT | MIT |
Chaque bibliothèque ici a un public réel. Le bon choix dépend des runtimes que tu cibles, de l'éventail de protocoles dont tu as besoin, et de savoir si tu veux une API de hub style RPC ou des trames WebSocket brutes.
Choisis sgcWebSockets .NET quand tu as besoin de WebSocket aux côtés de MQTT, AMQP, STOMP, WAMP, HTTP/2 et de clients IA/LLM dans un seul package ; quand tu cibles un runtime plus ancien (.NET Framework 2.0+, .NET Core 1.0) que les bibliothèques plus récentes ont abandonné ; quand tu veux la même surface d'API dans tes projets Delphi et .NET ; ou quand tu as spécifiquement besoin des composants serveur WebRTC (signalisation, ICE, TURN) sur .NET.
Choisis System.Net.WebSockets quand tu utilises déjà ASP.NET Core / Kestrel pour l'hébergement et que tu veux zéro dépendance supplémentaire ; quand tu veux une API de bas niveau que tu contrôles de bout en bout ; quand WebSocket est le seul protocole dont tu as besoin ; ou quand tu construis ton propre protocole par-dessus les trames brutes.
Choisis SignalR quand ton serveur et tes clients sont tous deux en .NET (ou que tu utilises les clients SignalR JavaScript / Java / Python), quand tu préfères un modèle de programmation RPC (hubs et méthodes) plutôt que les trames WebSocket brutes, quand tu as besoin d'un repli automatique du transport vers SSE / Long Polling pour les réseaux restreints, ou quand tu prévois de passer à l'échelle sur Azure SignalR Service.
Choisis WebSocket-Sharp quand tu as besoin d'un client et serveur WebSocket sous licence permissive (MIT) qui tourne sur les cibles .NET Framework 3.5 / Mono, et que figer un commit hash et incorporer le code source dans ta build ne te dérange pas.
Choisis Fleck quand tu as besoin d'un petit serveur WebSocket sous licence MIT, qui ne nécessite pas HTTP.SYS, qui tourne sur des serveurs Windows hérités (7 / 2008), et où tu fournis ton propre certificat TLS. Adapté aux scénarios embarqués et aux petits services.
Choisis Watson WebSocket quand tu utilises déjà la famille Watson Webserver / Watson TCP de Joel Christner et que tu veux garder le style d'API harmonisé. Les nouveaux projets devraient considérer Watson Webserver (le successeur actif) ou l'une des autres bibliothèques de cette page.
Notes courtes sur les différences d'API et de fonctionnalités si tu passes depuis une des bibliothèques ci-dessus. Pas d'esprit antagoniste — juste un mappage pratique.
System.Net.WebSockets te donne le protocole sur le fil ; sgcWebSockets .NET ajoute par-dessus les sous-protocoles MQTT / AMQP / STOMP / WAMP, HTTP/2, la reconnexion automatique, le watchdog, les clients IA/LLM et d'API d'échanges, et les composants serveur WebRTC. Si tu as écrit une fine couche autour de ClientWebSocket, la migration consiste essentiellement à renommer et à porter les gestionnaires d'événements.
SignalR parle son propre protocole de framing par-dessus WebSocket. sgcWebSockets implémente le protocole client SignalR sur le fil (TsgcWSAPI_SignalR et TsgcWSAPI_SignalRCore), donc un client Delphi ou .NET construit avec sgcWebSockets peut dialoguer avec un serveur ASP.NET Core SignalR existant. Si tu migres un back-end SignalR complet vers du WebSocket brut, attends-toi à redéfinir la dispatch des méthodes de hub sous forme de ton propre enveloppe de message.
Le client WebSocket et le WebSocketServer de WebSocket-Sharp correspondent étroitement à TsgcWebSocketClient et TsgcWebSocketServer de sgcWebSockets. Les noms d'événements diffèrent (OnMessage existe dans les deux ; OnError et OnClose ont des signatures similaires). Les sous-protocoles (MQTT / AMQP / STOMP / WAMP) sont propres à sgcWebSockets.
Fleck est côté serveur uniquement. Si ton application a à la fois un serveur Fleck et une bibliothèque client séparée, sgcWebSockets .NET unifie les deux. L'API basée sur des handlers de Fleck (WebSocketServer.Start(socket => ...)) correspond au TsgcWebSocketServer basé sur les événements de sgcWebSockets avec les gestionnaires OnMessage / OnConnect.
La surface d'événements client/serveur de Watson (MessageReceived, ClientConnected, ClientDisconnected) correspond proprement à OnMessage / OnConnect / OnDisconnect de sgcWebSockets. Les sous-protocoles et les clients d'API IA/LLM sont propres à sgcWebSockets.
Chaque cellule de la matrice ci-dessus renvoie à l'une de ces pages de documentation officielles, dépôts ou notes de version. Toutes les URL ont été vérifiées par HEAD au moment de la rédaction.