1. Introduction to WebSocket
WebSocket protocol is a new network protocol based on TCP. It implements full-duplex communication between the browser and the server - allowing the server to actively send information to the client.
The WebSocket Protocol enables two-way communication between a client running untrusted code in a controlled environment to a remote host that has opted-in to communications from that code. The security model used for this is the origin-based security model commonly used by web browsers. The protocol consists of an opening handshake followed by basic message framing, layered over TCP. The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections (e.g., using XMLHttpRequest or <iframe>s and long polling)
The WebSocket protocol supports full-duplex communication between a client (running untrusted code in a controlled environment) and a remote host (opting in to the code's communication). The security model used for this is the raw-based security model commonly used by web browsers. The protocol consists of an open handshake followed by message frames on the TCP layer. The goal of this technology is to provide a communication mechanism for browser-based applications that require two-way communication with the server (the server cannot rely on opening multiple HTTP connections (eg, using XMLHttpRequest or <iframe> and long polling)) .
2. WebSocket generation background
Simply put, before the WebSocket protocol, duplex communication was achieved through multiple http links, which led to inefficiency. WebSocket solves this problem. Below is an overview of the production background in standard RFC6455.
Historically, creating web applications that need bidirectional communication between a client and a server (e.g., instant messaging and gaming applications) has required an abuse of HTTP to poll the server for updates while sending upstream notifications as distinct HTTP calls.
This results in a variety of problems:
o The server is forced to use a number of different underlying TCP connections for each client: one for sending information to the client and a new one for each incoming message.
o The wire protocol has a high overhead, with each client-to-server message having an HTTP header. o The client-side script is forced to maintain a mapping from the outgoing connections to the incoming connection to track replies.
A simpler solution would be to use a single TCP connection for traffic in both directions. This is what the WebSocket Protocol provides. Combined with the WebSocket API , it provides an alternative to HTTP polling for two-way communication from a web page to a remote server.
The WebSocket Protocol is designed to supersede existing bidirectional communication technologies that use HTTP as a transport layer. Such technologies were implemented as trade-offs between efficiency and reliability because HTTP was not initially meant to be used for bidirectional communication (see [RFC6202] for further discussion).[1]
For a long time, creating web apps that implement duplex communication between the client and the client has resulted in the abuse of HTTP polling: the client keeps sending different HTTP calls to the host to ask for it.
This leads to a series of problems:
1. The server is forced to use many different underlying TCP connections for each client: one for sending information to the client and the other for receiving each incoming message.
2. The wire protocol has high overhead, and there are HTTP headers between every client and server.
3. Client scripts are forced to maintain a mapping from outgoing connections to incoming connections to track replies.
A simpler solution is to use a single TCP connection for bidirectional communication. This is what the WebSocket protocol provides. Combined with the WebSocket API, the WebSocket protocol provides an alternative to HTTP polling for bidirectional communication between web pages and remote hosts.
The WebSocket protocol was designed to replace the two-way communication technologies that use HTTP as the transport layer. These technologies can only sacrifice efficiency and reliance on one of the parties to improve the other, because the original purpose of HTTP was not for two-way communication. (For more discussion on this see RFC6202)
3. The background realization principle of WebSocket
In the process of implementing a websocket connection, a websocket connection request needs to be sent through the browser, and then the server sends a response. This process is usually called "handshake". In the WebSocket API, the browser and the server only need to do a handshake, and then a fast channel is formed between the browser and the server. Data can be transferred directly between the two. In this WebSocket protocol, there are two major benefits for us to achieve instant services:
1. Header
The headers that communicate with each other are very small - only about 2 Bytes
2. Server Push
For server push, the server no longer passively receives the browser's request before returning data, but actively pushes it to the browser when there is new data.
4. WebSockets handshake
Client-side and server-side TCP connections are established after the HTTP protocol handshake takes place. With HTTP traffic debugging, the handshake is easy to observe. As soon as the client creates a WebSocket instance, the following request and server-side response appear:
Note: We only entered the HTTP headers used by the WebSocket handshake.
ask:
GET /byteslounge/websocket HTTP/1.1
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Key: wVlUJ/tu9g6EBZEh51iDvQ==
response:
HTTP/1.1 101 Web Socket Protocol Handshake
Upgrade: websocket
Sec-WebSocket-Accept: 2TNh+0h5gTX019lci6mnvS66PSY=
Note: Connecting requires upgrading the protocol to a Websocket protocol that supports the websocket HTTP header via Upgrade and Upgrade. The server responds that the request is accepted and the protocol will switch to the WebSocket protocol (HTTP status code 101):
HTTP/1.1 101 Web Socket Protocol Handshake