Neutralne, oparte na źródłach zestawienie bibliotek WebSocket dostępnych dla programistów .NET w 2026 r.: sgcWebSockets .NET, System.Net.WebSockets, ASP.NET Core SignalR, WebSocket-Sharp, Fleck i Watson WebSocket. Każde twierdzenie dotyczące funkcji odsyła do własnej dokumentacji projektu.
Jednoparagrafowe podsumowanie każdej biblioteki z odnośnikiem do oficjalnej dokumentacji lub repozytorium.
eSeGeCe · Commercial
Zestaw komponentów C# odzwierciedlający produkt Delphi. Te same nazwy klas Tsgc*, ta sama obsługa protokołów: klient i serwer WebSocket (TCP i HTTP.SYS), MQTT, AMQP, STOMP, WAMP, HTTP/2, OAuth2, JWT, klienty AI/LLM (OpenAI, Anthropic, Gemini, DeepSeek, Grok, Ollama, Mistral, MCP), serwery WebRTC oraz ponad 30 integracji API giełd kryptowalut i SaaS. Obsługuje .NET Framework 2.0–4.8.1, .NET Core 1.0–3.1, .NET 5/6/7/8/9 i .NET Standard 1.6/2.0.
Microsoft · MIT (part of .NET)
Niskopoziomowe API WebSocket wbudowane bezpośrednio w .NET. Zapewnia ClientWebSocket dla klientów oraz abstrakcyjną klasę serwera WebSocket używaną przez ASP.NET Core, Kestrel i HttpListener. Ramkowanie RFC 6455 i per-message-deflate (WebSocketDeflateOptions) są obsługiwane natywnie.
Microsoft · MIT (part of ASP.NET Core)
Wysokopoziomowy framework czasu rzeczywistego firmy Microsoft. Zbudowany na WebSocket, Server-Sent Events i Long Polling (w tej kolejności awaryjnej); udostępnia RPC API w stylu hub zamiast surowych ramek. Protokoły hub JSON lub MessagePack; skaluje się przez Azure SignalR Service lub Redis backplane.
sta.blockhead · MIT
Długo rozwijany open-source'owy klient i serwer WebSocket dla C#. Obsługuje .NET Framework 3.5 i nowsze (oraz Mono), implementuje RFC 6455 z per-message-deflate (bez przejęcia kontekstu). Repozytorium GitHub nie ma oznaczonych wydań — użytkownicy zazwyczaj pobierają najnowszy master lub pinują do hasha commita.
Jason Staten / community · MIT
Biblioteka WebSocket C# tylko dla serwera, niezależna od HttpListener ani HTTP.SYS — nasłuchuje na gołym gnieździe. Nie ma strony klienckiej, serwera HTTP ani wbudowanego TLS poza ścieżką certyfikatu X509. Ostatnie oznaczone wydanie to 0.14.0 z października 2016 r.
Joel Christner · MIT
Asynchroniczny klient i serwer WebSocket C# z API opartym na zdarzeniach. Obsługuje .NET Framework 4.8 i .NET 7.0. Repozytorium zostało zarchiwizowane w maju 2024 r. z adnotacją, że zostało zintegrowane z Watson Webserver.
A check () means the project documents native support. A dash (—) means the project does not provide it natively. A tilde (~) means partial / via add-on / not explicitly documented — see the Sources section for what we could verify.
| Feature | sgcWebSockets .NET | System.Net.WebSockets | ASP.NET Core SignalR | WebSocket-Sharp | Fleck | Watson WebSocket |
|---|---|---|---|---|---|---|
| Klient WebSocket Klient RFC 6455 | — | |||||
| Serwer WebSocket Serwer RFC 6455 | ||||||
| TLS 1.3 TLS 1.3 obsługiwany przez dostarczony transport | ~ | ~ | ||||
| Klient HTTP/2 Natywny klient HTTP/2 (RFC 7540 / 9113) | ~ | — | — | — | — | |
| MQTT Wbudowany klient MQTT 3.1.1 / 5.0 | — | — | — | — | — | |
| AMQP Wbudowany klient AMQP 0.9.1 / 1.0 | — | — | — | — | — | |
| STOMP Wbudowany klient STOMP 1.0 / 1.2 | — | — | — | — | — | |
| WAMP Wbudowany klient WAMP v1 / v2 | — | — | — | — | — | |
| Push / streaming serwera Długotrwałe połączenie push lub strumieniowe | ||||||
| Auto-reconnect Wbudowany auto-reconnect / watchdog klienta | — | — | — | — | ||
| per-message-deflate (RFC 7692) Rozszerzenie kompresji WebSocket | ~ | — | ~ | |||
| Wieloplatformowość Win / macOS / Linux / iOS / Android | ~ | |||||
| Dozwolone użycie komercyjne Licencja zezwala na komercyjne użycie w kodzie zamkniętym | ||||||
| Dostępny kod źródłowy Kod źródłowy biblioteki jest widoczny dla programisty | ||||||
| Aktywna konserwacja Wydanie lub aktywność tagów w ciągu ostatnich 12–18 miesięcy | ~ | — | — | |||
| Model licencji Typ licencji | Commercial | MIT (part of .NET) | MIT (part of ASP.NET Core) | MIT | MIT | MIT |
Każda biblioteka ma tu swoich odbiorców. Właściwy wybór zależy od docelowych środowisk uruchomieniowych, zakresu protokołów i tego, czy potrzebujesz RPC-style hub API, czy surowych ramek WebSocket.
Wybierz sgcWebSockets .NET, gdy potrzebujesz WebSocket razem z MQTT, AMQP, STOMP, WAMP, HTTP/2 i klientami AI/LLM w jednym pakiecie; gdy celujesz w starsze środowisko uruchomieniowe (.NET Framework 2.0+, .NET Core 1.0) porzucone przez nowsze biblioteki; gdy chcesz tej samej powierzchni API zarówno w projektach Delphi, jak i .NET; lub gdy konkretnie potrzebujesz elementów serwera WebRTC (sygnalizacja, ICE, TURN) w .NET.
Wybierz System.Net.WebSockets, gdy już używasz ASP.NET Core / Kestrel do hostingu i chcesz zerowych dodatkowych zależności; gdy potrzebujesz niskopoziomowego API kontrolowanego od początku do końca; gdy WebSocket jest jedynym potrzebnym protokołem; lub gdy budujesz własny protokół na surowych ramkach.
Wybierz SignalR, gdy zarówno serwer, jak i klienty są .NET (lub używasz klientów SignalR dla JavaScript / Java / Python), gdy wolisz model programowania RPC (huby i metody) od surowych ramek WebSocket, gdy potrzebujesz automatycznego awaryjnego przełączenia na SSE / Long Polling dla ograniczonych sieci, lub gdy planujesz skalowanie na Azure SignalR Service.
Wybierz WebSocket-Sharp, gdy potrzebujesz klienta i serwera WebSocket na licencji liberalnej (MIT) działającego na .NET Framework 3.5 / Mono, i nie masz nic przeciwko przypinaniu do hasha commita i dołączaniu źródła do swojego builda.
Wybierz Fleck, gdy potrzebujesz małego serwera WebSocket na licencji MIT niewymagającego HTTP.SYS, działającego na starszych serwerach Windows (7 / 2008), gdzie sam dostarczasz certyfikat TLS. Nadaje się do scenariuszy wbudowanych i małych usług.
Wybierz Watson WebSocket, gdy już używasz rodziny Watson Webserver / Watson TCP Joela Christnera i chcesz zachować dopasowany styl API. Nowe projekty powinny rozważyć Watson Webserver (aktywnego następcę) lub jedną z innych bibliotek na tej stronie.
Krótkie uwagi dotyczące różnic w API i funkcjach przy przechodzeniu z jednej z powyższych bibliotek. Bez rywalizacji — tylko praktyczne mapowanie.
System.Net.WebSockets daje protokół przewodowy; sgcWebSockets .NET dodaje na wierzch subprotokołu MQTT / AMQP / STOMP / WAMP, HTTP/2, auto-reconnect, watchdog, klientów AI/LLM i API giełd oraz elementy serwera WebRTC. Jeśli napisałeś cienką nakładkę na ClientWebSocket, migracja to głównie zmiana nazw i przenoszenie obsługi zdarzeń.
SignalR używa własnego protokołu ramkowania nad WebSocket. sgcWebSockets implementuje kliencki protokół przewodowy SignalR (TsgcWSAPI_SignalR i TsgcWSAPI_SignalRCore), więc klient Delphi lub .NET zbudowany z sgcWebSockets może rozmawiać z istniejącym serwerem ASP.NET Core SignalR. Migrując pełny back-end SignalR do czystego WebSocket, spodziewaj się przeprojektowania dyspozytora metod huba jako własnej koperty wiadomości.
Klient WebSocket i WebSocketServer z WebSocket-Sharp ściśle odpowiadają TsgcWebSocketClient i TsgcWebSocketServer z sgcWebSockets. Nazwy zdarzeń różnią się (OnMessage istnieje w obu; OnError i OnClose mają podobne sygnatury). Subprotokołu (MQTT / AMQP / STOMP / WAMP) są dostępne wyłącznie w sgcWebSockets.
Fleck jest tylko serwerowy. Jeśli aplikacja ma zarówno serwer Fleck, jak i oddzielną bibliotekę kliencką, sgcWebSockets .NET łączy obie. API oparte na handlerach Fleck (WebSocketServer.Start(socket => ...)) odpowiada opartemu na zdarzeniach TsgcWebSocketServer z sgcWebSockets z handlerami OnMessage / OnConnect.
Powierzchnia zdarzeń klienta/serwera Watson (MessageReceived, ClientConnected, ClientDisconnected) czysto mapuje się na OnMessage / OnConnect / OnDisconnect z sgcWebSockets. Subprotokołu i klienty API AI/LLM są dostępne wyłącznie w sgcWebSockets.
Każda komórka powyższej macierzy odnosi się do jednej z tych oficjalnych stron dokumentacji, repozytoriów lub informacji o wydaniu. Wszystkie adresy URL były sprawdzane metodą HEAD w momencie pisania.