Um levantamento neutro, com fontes citadas, das bibliotecas WebSocket disponíveis para desenvolvedores .NET em 2026: sgcWebSockets .NET, System.Net.WebSockets, ASP.NET Core SignalR, WebSocket-Sharp, Fleck e Watson WebSocket. Cada afirmação sobre recursos liga à própria documentação do projeto.
Um resumo de um parágrafo sobre cada biblioteca, com um link para a documentação ou repositório oficial.
eSeGeCe · Comercial
Suíte de componentes C# que espelha o produto Delphi. Os mesmos nomes de classe Tsgc*, a mesma cobertura de protocolos: cliente e servidor WebSocket (TCP e HTTP.SYS), MQTT, AMQP, STOMP, WAMP, HTTP/2, OAuth2, JWT, clientes de IA/LLM (OpenAI, Anthropic, Gemini, DeepSeek, Grok, Ollama, Mistral, MCP), servidores WebRTC, além de mais de 30 integrações com exchanges de cripto e APIs SaaS. Tem como alvo .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 do .NET)
A API WebSocket de baixo nível embutida no próprio .NET. Fornece ClientWebSocket para clientes e uma classe abstrata WebSocket de servidor consumida por ASP.NET Core, Kestrel e HttpListener. O framing do RFC 6455 e o per-message-deflate (WebSocketDeflateOptions) são de primeira classe.
Microsoft · MIT (parte do ASP.NET Core)
O framework de tempo real de alto nível da Microsoft. Construído sobre WebSocket, Server-Sent Events e Long Polling (nessa ordem de fallback); expõe uma API RPC de hub em vez de frames brutos. Protocolos de hub em JSON ou MessagePack; escala via Azure SignalR Service ou um backplane Redis.
sta.blockhead · MIT
Cliente e servidor WebSocket em C# open source de longa data. Tem como alvo .NET Framework 3.5 e posteriores (e Mono), implementa o RFC 6455 com per-message-deflate (sem context takeover). O repositório no GitHub não tem releases marcadas — usuários geralmente pegam o master mais recente ou fixam em um commit hash.
Jason Staten / comunidade · MIT
Biblioteca WebSocket em C# apenas de servidor que não depende de HttpListener ou HTTP.SYS — escuta em um socket bruto. Não tem lado cliente, nem servidor HTTP, nem terminação TLS integrada fora do caminho do certificado X509. A release marcada mais recente é a 0.14.0, de outubro de 2016.
Joel Christner · MIT
Cliente e servidor WebSocket assíncrono em C# com uma API orientada a eventos. Tem como alvo .NET Framework 4.8 e .NET 7.0. O repositório foi arquivado em maio de 2024 com uma nota informando que foi integrado ao Watson Webserver.
Um check () significa que o projeto documenta suporte nativo. Um traço (—) significa que o projeto não oferece o recurso nativamente. Um til (~) significa parcial / via add-on / não documentado explicitamente — veja a seção Fontes para o que foi possível verificar.
| Recurso | sgcWebSockets .NET | System.Net.WebSockets | ASP.NET Core SignalR | WebSocket-Sharp | Fleck | Watson WebSocket |
|---|---|---|---|---|---|---|
| Cliente WebSocket Cliente RFC 6455 | — | |||||
| Servidor WebSocket Servidor RFC 6455 | ||||||
| TLS 1.3 TLS 1.3 suportado pelo transporte fornecido | ~ | ~ | ||||
| Cliente HTTP/2 Cliente HTTP/2 nativo (RFC 7540 / 9113) | ~ | — | — | — | — | |
| MQTT Cliente MQTT 3.1.1 / 5.0 integrado | — | — | — | — | — | |
| AMQP Cliente AMQP 0.9.1 / 1.0 integrado | — | — | — | — | — | |
| STOMP Cliente STOMP 1.0 / 1.2 integrado | — | — | — | — | — | |
| WAMP Cliente WAMP v1 / v2 integrado | — | — | — | — | — | |
| Push de servidor / streaming Conexão push ou streaming de longa duração | ||||||
| Reconexão automática Reconexão automática / watchdog integrado no cliente | — | — | — | — | ||
| per-message-deflate (RFC 7692) Extensão de compressão do WebSocket | ~ | — | ~ | |||
| Multiplataforma Win / macOS / Linux / iOS / Android | ~ | |||||
| Uso comercial permitido Licença permite uso comercial com código fechado | ||||||
| Código-fonte disponível Código-fonte da biblioteca é visível ao desenvolvedor | ||||||
| Manutenção ativa Release ou atividade marcada nos últimos 12–18 meses | ~ | — | — | |||
| Modelo de licença Tipo de licença | Comercial | MIT (parte do .NET) | MIT (parte do ASP.NET Core) | MIT | MIT | MIT |
Toda biblioteca aqui tem um público real. A escolha certa depende dos seus runtimes-alvo, da amplitude de protocolos que você precisa e se você quer uma API de hub no estilo RPC ou frames WebSocket brutos.
Escolha sgcWebSockets .NET quando você precisar de WebSocket junto com MQTT, AMQP, STOMP, WAMP, HTTP/2 e clientes de IA/LLM num único pacote; quando tiver como alvo um runtime mais antigo (.NET Framework 2.0+, .NET Core 1.0) que bibliotecas mais novas deixaram de suportar; quando quiser a mesma superfície de API tanto em projetos Delphi quanto em .NET; ou quando você especificamente precisar de peças de servidor WebRTC (signalling, ICE, TURN) em .NET.
Escolha System.Net.WebSockets quando você já usar ASP.NET Core / Kestrel para hospedagem e quiser zero dependências extras; quando quiser uma API de baixo nível que você controle de ponta a ponta; quando WebSocket for o único protocolo de que você precisa; ou quando você estiver construindo o seu próprio protocolo sobre os frames brutos.
Escolha SignalR quando tanto o seu servidor quanto os seus clientes forem .NET (ou se você usar os clientes SignalR em JavaScript / Java / Python), quando preferir um modelo de programação RPC (hubs e métodos) em vez de frames WebSocket brutos, quando precisar de fallback automático de transporte para SSE / Long Polling em redes restritas, ou quando planejar escalar no Azure SignalR Service.
Escolha WebSocket-Sharp quando você precisar de um cliente e servidor WebSocket com licença permissiva (MIT) que rode em .NET Framework 3.5 / Mono, e estiver feliz em fixar em um commit hash e incorporar o código-fonte ao seu build.
Escolha Fleck quando você precisar de um servidor WebSocket minúsculo, com licença MIT, que não exija HTTP.SYS, que rode em servidores Windows legados (7 / 2008), e em que você forneça o seu próprio certificado TLS. Adequado para cenários embarcados e pequenos serviços.
Escolha Watson WebSocket quando você já usar a família Watson Webserver / Watson TCP de Joel Christner e quiser manter o estilo de API consistente. Projetos novos deveriam considerar Watson Webserver (o sucessor ativo) ou uma das outras bibliotecas desta página.
Notas curtas sobre as diferenças de API e de recursos caso você esteja migrando de uma das bibliotecas acima. Sem adversidade — apenas o mapeamento prático.
O System.Net.WebSockets te dá o protocolo de fio; o sgcWebSockets .NET adiciona sub-protocolos MQTT / AMQP / STOMP / WAMP, HTTP/2, reconexão automática, watchdog, os clientes de IA/LLM e APIs de exchange e as peças de servidor WebRTC por cima. Se você escreveu um wrapper fino em torno de ClientWebSocket, a migração é principalmente um rename mais o porting dos event handlers.
O SignalR fala o seu próprio protocolo de framing sobre WebSocket. O sgcWebSockets implementa o protocolo de fio do cliente SignalR (TsgcWSAPI_SignalR e TsgcWSAPI_SignalRCore), então um cliente Delphi ou .NET feito com sgcWebSockets pode conversar com um servidor ASP.NET Core SignalR já existente. Se você está migrando um back-end SignalR completo para WebSocket bruto, espere redesenhar o despacho de métodos de hub como o seu próprio envelope de mensagem.
O cliente WebSocket e o WebSocketServer do WebSocket-Sharp se mapeiam diretamente para TsgcWebSocketClient e TsgcWebSocketServer do sgcWebSockets. Os nomes dos eventos diferem (OnMessage existe em ambos; OnError e OnClose têm assinaturas similares). Sub-protocolos (MQTT / AMQP / STOMP / WAMP) só existem no sgcWebSockets.
O Fleck é apenas de servidor. Se a sua aplicação tem tanto um servidor Fleck quanto uma biblioteca cliente separada, o sgcWebSockets .NET unifica ambos. A API baseada em handler do Fleck (WebSocketServer.Start(socket => ...)) se mapeia para o TsgcWebSocketServer baseado em eventos do sgcWebSockets com handlers OnMessage / OnConnect.
A superfície de eventos do cliente/servidor Watson (MessageReceived, ClientConnected, ClientDisconnected) se mapeia de forma limpa para OnMessage / OnConnect / OnDisconnect do sgcWebSockets. Sub-protocolos e os clientes de API de IA/LLM só existem no sgcWebSockets.
Cada célula da matriz acima remete a uma destas páginas oficiais de documentação, repositórios ou notas de release. Todas as URLs passaram por HEAD-check no momento da escrita.