This article compares SignalR and WebSocket, two of the most commonly used technologies for building realtime features and experiences for end-users, such as chat, live multiplayer games, multi-user collaboration apps, or live location tracking. We’ll cover the following:
A WebSocket connection starts as an HTTP request/response handshake between the client and the server. The client always initiates the handshake; it sends a
GET request to the server, indicating that it wants to upgrade the connection from HTTP to WebSockets. The server must return an
HTTP 101 Switching Protocols response code for the WebSocket connection to be established.
Once the connection upgrade is successful and switches from HTTP to WebSocket, the client and server can freely exchange low-latency messages over the connection as and when needed. After the WebSocket connection has served its purpose, it can be terminated via a closing handshake (both the client and server can initiate it).
The standardized WebSocket API, which is supported by the vast majority of browsers, extends the WebSocket protocol to web clients. The WebSocket API allows you to perform actions like creating the WebSocket object, managing the WebSocket connection, sending and receiving messages, and listening for events triggered by the WebSocket server.
Before WebSocket, HTTP techniques like AJAX long polling and Comet were the standard for building realtime apps. Compared to the HTTP protocol, WebSocket eliminates the need for a new connection with every request, drastically reducing the size of each message (no HTTP headers). This helps save bandwidth, improves latency, and makes WebSockets less taxing on the server side compared to HTTP.
Flexibility is ingrained into the design of the WebSocket technology, which allows for the implementation of application-level protocols and extensions for additional functionality (such as pub/sub messaging).
As an event-driven technology, WebSocket allows data to be transferred without the client requesting it. This characteristic is desirable in scenarios where the client needs to react quickly (instantly) to an event, as soon as it occurs.
WebSocket is a mature and widely adopted technology: most programming languages support WebSockets, and there are numerous libraries and frameworks implementing the WebSocket protocol. Additionally, almost all modern browsers natively support the WebSocket API.
The WebSocket protocol is stateful. This can be tricky to handle, especially at scale, because it requires the server layer to keep track of each individual WebSocket connection and maintain state information.
WebSockets don’t automatically recover when connections are terminated – this is something you need to implement yourself, and is part of the reason why there are many WebSocket client-side libraries in existence.
Even though WebSockets generally benefit from widespread support, certain environments (such as corporate networks with proxy servers) will block WebSocket connections.
SignalR is a technology that enables you to add realtime web functionality to apps. SignalR comes in several different flavors:
ASP .NET SignalR - a library for ASP. NET developers. Note that this version is largely outdated (only critical bugs are being fixed, but no new features are being added).
ASP .NET Core SignalR - an open-source SignalR library; unlike ASP. NET SignalR, this version is actively maintained.
Azure SignalR Service - the fully managed cloud version.
SignalR uses WebSocket as the main underlying transport, while providing additional features, such as:
Fallback to other transports.
An API for creating server-to-client remote procedure calls (RPC).
The ability to send messages to all connected clients simultaneously, or to specific (groups of) clients.
SignalR uses hubs to communicate between clients and servers. A SignalR hub is a high-level pipeline that enables connected servers and clients to invoke methods on each other. There are two built-in hub protocols: a JSON-based text protocol, and a binary protocol inspired by MessagePack.
Multiple backplane options to choose from when scaling out: Redis, SQL Server, or Azure Service Bus (note that there’s no need to configure and manage a backplane when using the fully managed version, Azure SignalR Service).
Part of the ASP. NET Framework, which makes it easy to use SignalR in combination with other ASP. NET features like authentication, authorization, and dependency injection.
SignalR uses WebSockets wherever possible, but it also supports two fallback transports: Server-Sent Events, and HTTP long polling, for environments where the WebSocket transport is blocked/unsupported.
SignalR offers rather weak messaging QoS; ordering and delivery are not guaranteed. You’d have to develop your own mechanism to ensure robust messaging (e.g., adding sequencing information to messages themselves).
SignalR is designed to be a single-region solution, which can negatively impact its performance, reliability, and availability.
Scaling SignalR (or any other WebSocket-based implementation) yourself is likely to be difficult, expensive, and time-consuming. Read about the challenges of scaling SignalR. You can abstract away the pain of managing SignalR yourself by using the managed version, Azure SignalR Service. However, SignalR Service also has its limitations; for example, it only provides a maximum 99.95% uptime guarantee (for premium accounts), which amounts to almost 4.5 hours of allowed downtime / unavailability per year. This SLA might not be reliable enough for critical use cases, like healthcare apps that must be available 24/7. The situation is worse for non-premium accounts, where the SLA provided is 99.9% (almost 9 hours of annual downtime).
We can broadly group WebSocket use cases into two distinct categories:
Realtime updates, where the communication is unidirectional, and the server is streaming low-latency (and often frequent) updates to the client. Think of live score updates, GPS location tracking, live dashboards, or realtime alerts and notifications, to name just a few use cases.
Bidirectional communication, where both the client and the server send and receive messages. Examples include chat, virtual events, and virtual classrooms (the last two usually involve features like live polls, quizzes, and Q&As). WebSockets can also be used to underpin multi-user synchronized collaboration functionality, such as multiple people editing the same document simultaneously (think of Figma).
As SignalR is a WebSocket implementation, you can use it to engineer the same types of realtime features you’d build with raw WebSockets. Examples include:
Collaborative apps (e.g., whiteboards).
Realtime location updates.
High-frequency updates (for use cases like realtime multiplayer gaming and streaming live score updates).
WebSocket is an event-driven protocol that enables bidirectional, full-duplex communication between client and server. In contrast, SignalR is a solution that provides an abstraction layer on top of WebSockets, making it easier and faster to add realtime web functionality to apps.
SignalR provides features such as automatic reconnections, fallback transports, or the ability to broadcast messages to all connected clients, or only to specific groups of clients. With vanilla WebSockets, you don’t benefit from such features out of the box; you have to build all these capabilities yourself if they're relevant to your use case.
Finally, a word on performance. As SignalR is a more complex (and demanding) solution than raw WebSockets, it’s safe to expect some performance-related differences. For example, it takes less time to establish a raw WebSocket connection than a SignalR connection. SignalR almost certainly has higher memory and CPU requirements than vanilla WebSockets.
Whether you should use SignalR or WebSocket depends on a couple of factors. Firstly, the specifics of your use case. For example, raw WebSocket is suitable for PoCs and simplistic scenarios, such as pushing data to browsers. On the other hand, for more complex use cases, such as a production-ready chat app, SignalR is a superior alternative, as it allows you to move faster than plain WebSockets, and provides features like automatic reconnections and the ability to broadcast messages to multiple clients (useful for multi-user chat).
Another aspect to bear in mind is the degree of flexibility you need for your use case. Raw WebSockets provide more flexibility - you can design your own architecture and your own protocol on top, using essentially any programming language you want - although this is incredibly difficult and time-consuming. In comparison, SignalR is available as a fully managed service (in addition to the open-source version), which removes the need to provision and manage infrastructure in-house. However, SignalR has a pre-designed architecture and limited platform support, which may become restrictive at some point.
We hope this article has helped you gain a good understanding of the advantages, disadvantages, and differences between SignalR and WebSocket. Of course, SignalR and WebSocket are far from the only technologies you can use to build realtime features. Here are some:
If you want to avoid the headache and high costs of managing WebSocket infrastructure in-house, and you’re looking for a more robust alternative to SignalR, we invite you to explore the Ably platform. See how SignalR compares to Ably.
Ably provides globally-distributed edge infrastructure and hosted WebSocket APIs to build and deliver realtime features like multiplayer games, chat, and location tracking at internet scale.
Our platform offers robust capabilities and guarantees, including 25+ client SDKs targeting every major platform and programming language, feature-rich pub/sub messaging, guaranteed message ordering and delivery, and a 99.999% uptime SLA.
To find out more about what Ably can do for you, get started with a free account.
Scaling SignalR: available options and key challenges
Learn how to scale ASP.NET Core SignalR and Azure SignalR Service, and discover the challenges you’ll face along the way.
5 solutions you can use instead of SignalR to develop live and collaborative features like chat, multi-user whiteboards, and live dashboards.
WebSocket alternatives for realtime features
Discover 5 alternatives to WebSocket for engineering realtime functionality for end-users: SSE, long polling, MQTT, WebRTC, and WebTransport.