ClientServer Websocket

1. PLASMA UNIVERSITY
COLLEGE OF ENGINEERING TECHNOLOGY
Lecturer Name: ENG Khadar Mohamed Khadar
Work : Presentation
Academic Year : 2022 – 2023
Student Name : Mohamed Amin Haji Ali
ID No: 10345 Faculty : BITS7
Shift : Part-Time Batch : SIX
PLASMA UNIVERSITY – SOMALIA -MOGADISHU
COMPUS : MAIN COMPUS

2. Client Server And Distribution System
Client Server Web Socket

3. OverView
Client Server web socket
How Do Web sockets Work ?
Why WebSocket ?
Why Is a Web Socket Needed and When Should it be avoided?
Differences between HTTP and WebSocket Connection ?
Protocol Overview
Web Socket protocols

4. Introduction
What is WebSocket?
As per the conventional definition, WebSocket is a duplex
protocol used mainly in the client-server communication channel.
It’s bidirectional in nature which means communication happens
to and fro between client-server .
The connection, developed using the WebSocket, lasts as long as
any of the participating parties lays it off. Once one party breaks
the connection, the second party won’t be able to communicate as
the connection breaks automatically at its front.

5. WebSocket need support from HTTP to initiate the connection.
Speaking of its utility, it’s the spine for modern web application
development when seamless streaming of data and assorted
unsynchronized traffic is concerned .

6. Why Is a Web Socket Needed and When Should it be
avoided?
WebSocket are an essential client-server communication tool and one needs
to be fully aware of its utility and avoid scenarios to
benefit from its utmost potential. It’s explained extensively in the next
section.
Use WebSocket When You Are:
1. Real-time web application:
Real-time web application uses a web socket to show the data at the client
end, which is continuously being sent by the backend server. In WebSocket,
data is continuously pushed/transmitted into the same connection which is
already open, that is why WebSocket is faster and improves the application
performance.

7. For e.g. in a trading website or bitcoin trading, for displaying the price
fluctuation and movement data is continuously pushed by the backend
server to the client end by using a WebSocket channel.
2. Gaming application:
In a Gaming application, you might focus on that, data is continuously
received by the server, and without refreshing the UI, it will take effect
on the screen, UI gets automatically refreshed without even
establishing the new connection, so it is very helpful in a Gaming
application

8. 3. Chat application:
Chat applications use WebSockets to establish the connection only once for
exchange, publishing, and broadcasting the message among the subscribers.
It reuses the same WebSocket connection, for sending and receiving the
message and for one-to-one message transfer.

9. When not to use WebSocket
WebSocket can be used if we want any real-time updated or continuous
streams of data that are being transmitted over the network. If we want to
fetch old data, or want to get the data only once to process it with an
application we should go with HTTP protocol, old data which is not
required very frequently or fetched only once can be queried by the simple
HTTP request, so in this scenario, it’s better not use WebSocket.
Note: RESTful web services are sufficient to get the data from the server if
we are loading the data only once .

10. Differences between HTTP and
WebSocket Connection
WebSocket Connection
WebSocket is a bidirectional communication protocol that can send the data
from the client to the server or from the server to the client by reusing the
established connection channel. The connection is kept alive until
terminated by either the client or the server.
Almost all the real-time applications like (trading, monitoring, notification)
services use WebSocket to receive the data on a single communication
channel.
All the frequently updated applications used WebSocket because it is faster
than HTTP Connection

11. Count…..
HTTP Connection
The HTTP protocol is a unidirectional protocol that works on top of TCP
protocol which is a connection-oriented transport layer protocol, we can
create the connection by using HTTP request methods after getting the
response HTTP connection get closed.
Simple RESTful application uses HTTP protocol which is stateless.
When we do not want to retain a connection for a particular amount of time
or reuse the connection for transmitting data; An HTTP connection is slower
than WebSockets.
Note: Depending on your project you have to choose where it will be
WebSocket or HTTP Connection.

12. How Do Websockets Work?
A WebSocket is a persistent connection between a client and server.
WebSockets provide a bidirectional, full-duplex communications channel
that operates over HTTP through a single TCP/IP socket connection. At its
core, the WebSocket protocol facilitates message passing between a client
and server. This article provides an introduction to the WebSocket protocol,
including what problem WebSockets solve, and an overview of how
WebSockets are described at the protocol level.

13. Why WebSocket?
The idea of WebSockets was borne out of the limitations of HTTP-based
technology. With HTTP, a client requests a resource, and the server
responds with the requested data.
HTTP is a strictly unidirectional protocol — any data sent from the server to
the client must be first requested by the client.
Long-polling has traditionally acted as a workaround for this limitation.
With long-polling, a client makes an HTTP request with a long timeout
period, and the server uses that long timeout to push data to the client.
Long-polling works, but comes with a drawback — resources on the server
are tied up throughout the length of the long-poll, even when no data is
available to send.

14. Count…….
WebSockets, on the other hand, allow for sending message-based data,
similar to UDP, but with the reliability of TCP.
WebSocket uses HTTP as the initial transport mechanism, but keeps the
TCP connection alive after the HTTP response is received so that it can be
used for sending messages between client and server.
WebSockets allow us to build “real-time” applications without the use of
long-polling

15. Protocol Overview
The protocol consists of an opening handshake followed by basic message framing,
layered over TCP .
RFC 6455 - The WebSocket Protocol
WebSockets begin life as a standard HTTP request and response.
Within that request response chain, the client asks to open a
WebSocket connection, and the server responds (if its able to).
If this initial handshake is successful, the client and server have agreed
to use the existing TCP/IP connection that was established for the
HTTP request as a WebSocket connection. Data can now flow over this
connection using a basic framed message protocol. Once both parties
acknowledge that the WebSocket connection should be closed, the TCP
connection is torn down

16. Establishing a WebSocket connection — The
WebSocket Open Handshake
WebSockets do not use the http:// or https:// scheme (because they do not follow the
HTTP protocol).
Rather, WebSocket URIs use a new scheme ws: (or wss: for a secure WebSocket).
The remainder of the URI is the same as an HTTP URI: a host, port, path and any
query parameters.

17. "ws:" "//" host [ ":" port ] path [ "?" query ]
"wss:" "//" host [ ":" port ] path [ "?" query ]
WebSocket connections can only be established to URIs that follow this
scheme. That is, if you see a URI with a scheme of ws:// (or wss://), then
both the client and the server
MUST follow the WebSocket connection protocol to follow the WebSocket
specification. WebSocket connections are established by upgrading an
HTTP request/response pair.
A client that supports WebSockets and wants to establish a connection will
send an HTTP request that includes a few required headers:

18. Connection : Upgrade
The Connection header generally controls whether or not the network
connection stays open after the current transaction finishes.
A common value for this header is keep-alive to make sure the connection is
persistent to allow for subsequent requests to the same server.
During the WebSocket opening handshake we set to header to Upgrade,
signaling that we want to keep the connection alive, and use it for non-HTTP
requests

19. Upgrade: websocket
The Upgrade header is used by clients to ask the server to switch to one of the
listed protocols, in descending preference order. We specify websocket here
to signal that the client wants to establish a WebSocket connection.

20. Sec-WebSocket-Key: q4xkcO32u266gldTuKaSOw==
The Sec-WebSocket-Key is a one-time random value (a nonce) generated by
the client. The value is a randomly selected 16-byte value that has been
base64-encoded
Sec-WebSocket-Version: 13
The only accepted version of the WebSocket protocol is 13. Any other version
listed in this header is invalid.
Together, these headers would result in an HTTP GET request from the client
to a ws:// URI like in the following example:

21. • GET ws://example.com:8181/ HTTP/1.1
• Host: localhost:8181
• Connection: Upgrade
• Pragma: no-cache
• Cache-Control: no-cache
• Upgrade: websocket
• Sec-WebSocket-Version: 13
• Sec-WebSocket-Key: q4xkcO32u266gldTuKaSOw==

22. Once a client sends the initial request to open a WebSocket connection, it
waits for the server’s reply. The reply must have an HTTP 101 Switching
Protocols response code. The HTTP 101 Switching Protocols response
indicates that the server is switching to the protocol that the client requested
in its Upgrade
request header. In addition, the server must include HTTP headers that
validate the connection was successfully upgraded
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: fA9dggdnMPU79lJgAE3W4TRnyDM=

23. •Connection: Upgrade
•Confirms that the connection has been upgraded.
•Upgrade: websocket
•Confirms that the connection has been upgraded.

24. Sec-WebSocket-Accept: fA9dggdnMPU79lJgAE3W4TRnyDM=`
Sec-WebSocket : Accept is base64 encoded, SHA-1 hashed value. You
generate this value by concatenating the clients Sec-WebSocket-Key nonce
and the static value 258EAFA5-E914-47DA-95CA-C5AB0DC85B11 defined
in RFC 6455.
Although the Sec-WebSocket-Key and Sec-WebSocket-Accept seem
complicated, they exist so that both the client and the server can know that
their counterpart supports WebSockets. Since the WebSocket re-uses the
HTTP connection, there are potential security concerns if either side
interprets WebSocket data as an HTTP request.
After the client receives the server response, the WebSocket connection is
open to start transmitting data.

25. The WebSocket Protocol
• WebSocket is a framed protocol, meaning that a chunk of data (a message)
is divided into a number of discrete chunks, with the size of the chunk
encoded in the frame. The frame includes a frame type, a payload length,
and a data portion. An overview of the frame is given in RFC 6455 and
reproduced here.

26. 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-------+-+-------------+-------------------------------+
|F|R|R|R| opcode|M| Payload len | Extended payload length |
|I|S|S|S| (4) |A| (7) | (16/64) |
|N|V|V|V| |S| | (if payload len==126/127) |
| |1|2|3| |K| | |
+-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
| Extended payload length continued, if payload len == 127 |
+ - - - - - - - - - - - - - - - +-------------------------------+
| |Masking-key, if MASK set to 1 |
+-------------------------------+-------------------------------+
| Masking-key (continued) | Payload Data |
+-------------------------------- - - - - - - - - - - - - - - - +
: Payload Data continued ... :
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Payload Data continued ... |
+---------------------------------------------------------------+

27. I won’t cover every piece of the frame protocol here. Refer to RFC 6455 for
full details. Rather, I will cover the most important bits so that we can gain
an understanding of the WebSocket protocol.
Fin Bit
The first bit of the WebSocket header is the Fin bit. This bit is set if this
frame is the last data to complete this message.
RSV1, RSV2, RSV3 Bits
These bits are reserved for future use.
Opcode
Every frame has an opcode that determines how to interpret this frame’s
payload data.

28. Opcode value Description
0x00
This frame continues the payload from the
previous frame.
0x01
Denotes a text frame. Text frames are UTF-8
decoded by the server.
0x02
Denotes a binary frame. Binary frames are
delivered unchanged by the server.

29. 0x03-0x07 Reserved for future use.
0x08 Denotes the client wishes to close the connection.
0x09
A ping frame. Serves as a heartbeat mechanism
ensuring the connection is still alive. The receiver must
respond with a pong.
0x0a
A pong frame. Serves as a heartbeat mechanism
ensuring the connection is still alive. The receiver must
respond with a ping frame.
0x0b-0x0f Reserved for future use.

30. Mask
Setting this bit to 1 enables masking. WebSockets require that all payload be
obfuscated using a random key (the mask) chosen by the client. The masking
key is combined with the payload data using an XOR operation before
sending data to the payload. This masking prevents caches from
misinterpreting WebSocket frames as cacheable data. Why should we
prevent caching of WebSocket data? Security

31. Count..
During development of the WebSocket protocol, it was shown that if a
compromised server is deployed, and clients connect to that server, it is
possible to have intermediate proxies or infrastructure cache the responses
of the compromised server so that future clients requesting that data receive
the incorrect response. This attack is called cache poisoning, and results
from the fact that we cannot control how misbehaving proxies behave in the
wild.
This is especially problematic when introducing a new protocol like
WebSocket that has to interact with the existing infrastructure of the
internet.

32. Payload len
The Payload len field and Extended payload length field are used to encode
the total length of the payload data for this frame. If the payload data is small
(under 126 bytes), the length is encoded in the Payload len field. As the
payload data grows, we use the additional fields to encode the length of the
payload.

33. Masking-key
As discussed with the MASK bit, all frames sent from the client to the server
are masked by a 32-bit value that is contained within the frame. This field is
present if the mask bit is set to 1 and is absent if the mask bit is set to 0.
Payload data
The Payload data includes arbitrary application data and any extension data
that has been negotiated between the client and the server. Extensions are
negotiated during the initial handshake and allow you to extend the
WebSocket protocol for additional uses.

34. Closing a WebSocket connection — The
WebSocket Close Handshake
To close a WebSocket connection, a closing frame is sent (opcode 0x08). In
addition to the opcode, the close frame may contain a body that indicates the
reason for closing. If either side of a connection receives a close frame, it
must send a close frame in response, and no more data should be sent over
the connection. Once the close frame has been received by both parties, the
TCP connection is torn down.
The server always initiates closing the TCP connection.

35. ENDED
More References
This article provides an introduction to the WebSocket protocol, and covers a lot of ground.
However, the full protocol has more detail than what I could fit in to this blog post. If you
want to learn more, there are several great resources to choose from:
• RFC 6544 - The WebSocket Protocol
• High Performance Browser Networking
• WebSocket