Java Reference
In-Depth Information
An overview of WebSockets
A WebSocket session between the client and server is built upon a standard TCP connec-
tion. Although the WebSocket protocol has its own control frames (mainly to create and
sustain the connection) coded by the Internet Engineering Task Force in the RFC 6455 (
ht-
tp://tools.ietf.org/html/rfc6455
), the peers are not obliged to use any specific format to ex-
change application data. You may use plaintext, XML, JSON, or anything else to transmit
your data. As you probably remember, this is quite different from SOAP-based WebSer-
vices, which had bloated specifications of the exchange protocol. The same goes for REST-
ful architectures; we no longer have the predefined verb methods from HTTP (GET, PUT,
POST, and DELETE), status codes, and the whole semantics of an HTTP request.
This liberty means that WebSockets are pretty low level compared to the technologies that
we have used up to this point, but thanks to this, the communication overhead is minimal.
The protocol is less verbose than SOAP or RESTful HTTP, which allows us to achieve
higher performance. This, however, comes with a price. We usually like to use the features
of higher-level protocols (such as horizontal scaling and rich URL semantics), and with
WebSockets, we would need to write them by hand. For standard CRUD-like operations, it
would be easier to use a REST endpoint than create everything from scratch.
What do we get from WebSockets compared to the standard HTTP communication? First
of all, a direct connection between two peers. Normally, when you connect to a web server
(which can, for instance, handle a REST endpoint), every subsequent call is a new TCP
connection, and your machine is treated like it is a different one every time you make a re-
quest. You can, of course, simulate a stateful behavior (so that the server will recognize
your machine between different requests) using cookies and increase the performance by
reusing the same connection in a short period of time for a specific client, but basically, it is
a workaround to overcome the limitations of the HTTP protocol.
Once you establish a WebSocket connection between a server and client, you can use the
same session (and underlying TCP connection) during the whole communication. Both
sides are aware of it and can send data independently in a full-duplex manner (both sides
can send and receive data simultaneously). Using plain HTTP, there is no way for the serv-
er to spontaneously start sending data to the client without any request from its side. What's
more, the server is aware of all of its connected WebSocket clients, and can even send data
between them!
