Un confronto neutrale e con fonti citate delle librerie WebSocket disponibili per gli sviluppatori .NET nel 2026: sgcWebSockets .NET, System.Net.WebSockets, ASP.NET Core SignalR, WebSocket-Sharp, Fleck e Watson WebSocket. Ogni affermazione su una funzionalità rimanda alla documentazione ufficiale del progetto.
Un riepilogo di un paragrafo per ogni libreria, con un link alla documentazione ufficiale o al repository.
eSeGeCe · Commerciale
Suite di componenti C# che rispecchia il prodotto Delphi. Stessi nomi di classe Tsgc*, stessa copertura di protocolli: client e server WebSocket (TCP e HTTP.SYS), MQTT, AMQP, STOMP, WAMP, HTTP/2, OAuth2, JWT, client AI/LLM (OpenAI, Anthropic, Gemini, DeepSeek, Grok, Ollama, Mistral, MCP), server WebRTC, oltre alle 30+ integrazioni con exchange di criptovalute e API SaaS. Target: .NET Framework 2.0–4.8.1, .NET Core 1.0–3.1, .NET 5/6/7/8/9 e .NET Standard 1.6/2.0.
Microsoft · MIT (parte di .NET)
L'API WebSocket di basso livello integrata in .NET stesso. Fornisce ClientWebSocket per i client e una classe astratta WebSocket lato server consumata da ASP.NET Core, Kestrel e HttpListener. Il framing RFC 6455 e per-message-deflate (WebSocketDeflateOptions) sono di prima classe.
Microsoft · MIT (parte di ASP.NET Core)
Il framework real-time di alto livello di Microsoft. Costruito sopra WebSocket, Server-Sent Events e Long Polling (in quest'ordine di fallback); espone un'API RPC basata su hub anziché frame grezzi. Protocolli hub JSON o MessagePack; scala tramite Azure SignalR Service o un backplane Redis.
sta.blockhead · MIT
Client e server WebSocket C# open-source di lunga data. Target: .NET Framework 3.5 e successivi (e Mono), implementa RFC 6455 con per-message-deflate (senza context takeover). Il repository GitHub non ha release con tag — gli utenti tipicamente prendono l'ultimo master o si ancorano a un hash di commit.
Jason Staten / comunità · MIT
Libreria WebSocket C# solo lato server che non dipende da HttpListener o HTTP.SYS — ascolta su un socket grezzo. Non ha un lato client, non ha server HTTP e non ha terminazione TLS integrata al di fuori del percorso del certificato X509. L'ultima release con tag è la 0.14.0 dell'ottobre 2016.
Joel Christner · MIT
Client e server WebSocket C# asincroni con API event-driven. Target: .NET Framework 4.8 e .NET 7.0. Il repository è stato archiviato a maggio 2024 con una nota che indica l'integrazione in Watson Webserver.
Un segno di spunta () significa che il progetto documenta il supporto nativo. Un trattino (—) significa che il progetto non lo fornisce nativamente. Una tilde (~) significa parziale / tramite add-on / non documentato esplicitamente — vedi la sezione Fonti per ciò che è stato possibile verificare.
| Funzionalità | sgcWebSockets .NET | System.Net.WebSockets | ASP.NET Core SignalR | WebSocket-Sharp | Fleck | Watson WebSocket |
|---|---|---|---|---|---|---|
| Client WebSocket Client RFC 6455 | — | |||||
| Server WebSocket Server RFC 6455 | ||||||
| TLS 1.3 TLS 1.3 supportato dal trasporto fornito | ~ | ~ | ||||
| Client HTTP/2 Client HTTP/2 nativo (RFC 7540 / 9113) | ~ | — | — | — | — | |
| MQTT Client MQTT 3.1.1 / 5.0 integrato | — | — | — | — | — | |
| AMQP Client AMQP 0.9.1 / 1.0 integrato | — | — | — | — | — | |
| STOMP Client STOMP 1.0 / 1.2 integrato | — | — | — | — | — | |
| WAMP Client WAMP v1 / v2 integrato | — | — | — | — | — | |
| Server push / streaming Connessione push o streaming a lunga durata | ||||||
| Riconnessione automatica Riconnessione automatica / watchdog del client integrati | — | — | — | — | ||
| per-message-deflate (RFC 7692) Estensione di compressione WebSocket | ~ | — | ~ | |||
| Multipiattaforma Win / macOS / Linux / iOS / Android | ~ | |||||
| Uso commerciale consentito La licenza consente uso commerciale closed-source | ||||||
| Codice sorgente disponibile Il sorgente della libreria è visibile allo sviluppatore | ||||||
| Manutenzione attiva Release o attività con tag negli ultimi 12–18 mesi | ~ | — | — | |||
| Modello di licenza Tipo di licenza | Commerciale | MIT (parte di .NET) | MIT (parte di ASP.NET Core) | MIT | MIT | MIT |
Ogni libreria qui presente ha un pubblico reale. La scelta giusta dipende dai runtime di destinazione, dall'ampiezza dei protocolli e dal fatto se vuoi un'API hub in stile RPC o frame WebSocket grezzi.
Scegli sgcWebSockets .NET quando ti serve WebSocket insieme a MQTT, AMQP, STOMP, WAMP, HTTP/2 e client AI/LLM in un unico pacchetto; quando il tuo target è un runtime più vecchio (.NET Framework 2.0+, .NET Core 1.0) abbandonato dalle librerie più recenti; quando vuoi la stessa superficie di API sia nei progetti Delphi sia in quelli .NET; oppure quando ti servono specificamente le componenti server WebRTC (signalling, ICE, TURN) su .NET.
Scegli System.Net.WebSockets quando usi già ASP.NET Core / Kestrel per l'hosting e vuoi zero dipendenze aggiuntive; quando vuoi un'API di basso livello che controlli end-to-end; quando WebSocket è l'unico protocollo che ti serve; oppure quando stai costruendo un tuo protocollo sopra i frame grezzi.
Scegli SignalR quando sia il server sia i client sono .NET (o usi i client SignalR JavaScript / Java / Python), quando preferisci un modello di programmazione RPC (hub e metodi) ai frame WebSocket grezzi, quando ti serve il fallback automatico del trasporto a SSE / Long Polling per reti restrittive, oppure quando hai intenzione di scalare su Azure SignalR Service.
Scegli WebSocket-Sharp quando ti serve un client e server WebSocket con licenza permissiva (MIT) che gira su target .NET Framework 3.5 / Mono e ti sta bene ancorarti a un hash di commit e includere il sorgente nella tua build.
Scegli Fleck quando ti serve un server WebSocket minuscolo, con licenza MIT, che non richieda HTTP.SYS, che giri su server Windows legacy (7 / 2008) e in cui fornisci tu stesso il certificato TLS. Adatto per scenari embedded e servizi piccoli.
Scegli Watson WebSocket quando usi già la famiglia Watson Webserver / Watson TCP di Joel Christner e vuoi mantenere lo stesso stile di API. I nuovi progetti dovrebbero considerare Watson Webserver (il successore attivo) o una delle altre librerie di questa pagina.
Brevi note sulle differenze di API e funzionalità se stai migrando da una delle librerie qui sopra. Non polemico — solo la mappatura pratica.
System.Net.WebSockets fornisce il protocollo di trasmissione; sgcWebSockets .NET aggiunge in più i sub-protocolli MQTT / AMQP / STOMP / WAMP, HTTP/2, riconnessione automatica, watchdog, i client AI/LLM e di API di exchange e le componenti server WebRTC. Se hai scritto un wrapper sottile attorno a ClientWebSocket, la migrazione si limita per lo più a una ridenominazione e al port dei gestori di eventi.
SignalR usa un proprio protocollo di framing sopra WebSocket. sgcWebSockets implementa il protocollo di trasmissione del client SignalR (TsgcWSAPI_SignalR e TsgcWSAPI_SignalRCore), quindi un client Delphi o .NET costruito con sgcWebSockets può parlare con un server ASP.NET Core SignalR esistente. Se stai migrando un intero back-end SignalR a WebSocket grezzo, aspettati di dover riprogettare il dispatch dei metodi hub come un tuo envelope di messaggi.
Il client WebSocket e il WebSocketServer di WebSocket-Sharp si mappano da vicino su TsgcWebSocketClient e TsgcWebSocketServer di sgcWebSockets. I nomi degli eventi differiscono (OnMessage esiste in entrambi; OnError e OnClose hanno signature simili). I sub-protocolli (MQTT / AMQP / STOMP / WAMP) sono esclusivi di sgcWebSockets.
Fleck è solo lato server. Se la tua applicazione ha sia un server Fleck sia una libreria client separata, sgcWebSockets .NET unifica entrambi. L'API basata su handler di Fleck (WebSocketServer.Start(socket => ...)) si mappa sul TsgcWebSocketServer event-based di sgcWebSockets con gli handler OnMessage / OnConnect.
La superficie di eventi client/server di Watson (MessageReceived, ClientConnected, ClientDisconnected) si mappa in modo pulito su OnMessage / OnConnect / OnDisconnect di sgcWebSockets. I sub-protocolli e i client di API AI/LLM sono esclusivi di sgcWebSockets.
Ogni cella della matrice qui sopra rimanda a una di queste pagine di documentazione ufficiale, repository o note di rilascio. Tutti gli URL sono stati controllati con HEAD al momento della stesura.