HTTP connections before WS

Before THE emergence of WS, HTTP was a client-initiated server response mode, relying on the active communication of the client, while the server was completely passive to wait for requests and reply data. If the server is required to actively push information to the client (such as application reminders on mobile phones), only the client active pulling or Long pulling uninterrupted request server can obtain data, and HTTP is stateless. Authentication information and TCP connection are required every time data is requested. Very resource-intensive.

For an introduction to pulling and long pulling, click to see the WebSocket protocol

Let’s start with a WS handshake request

GET / HTTP/1.1

Host: 127.0.0.1:8080

Connection: Upgrade

Upgrade: websocket

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36

Accept-Encoding: gzip, deflate, sdch

Accept-Language: zh-CN,zh; Q = 0.8

Sec-WebSocket-Version: 13

Sec-WebSocket-Key: VR+OReqwhymoQ21dBtoIMQ==

Sec-WebSocket-Protocol: chat, superchat

Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits

ShellCopy

Similar to HTTP, but with the Connection and Upgrade fields, tell the server I want to Upgrade to A WS Connection,

The domains are:

  • It must be a valid HTTP request format
  • The HTTP request Method must be GET and the protocol must be at least 1.1, for example, GET, HTTP, or 1.1
  • The Upgrade header field must be included and has a value of websocket
  • The Connection header field must be included and has a value of Upgrade
  • The sec-websocket-key header field, whose value is a random sequence of 16-byte characters encoded in Base64, must be included
  • If the request is coming from a browser client, the Origin header field must also be included. This header field is used to protect against unauthorized cross-domain scripting attacks, and the server can decide from Origin whether to accept the WebSocket connection
  • The sec-websocket-version header field must be included and the current value must be 13
  • This may include sec-websocket-protocol, which represents a list of protocols supported by the client, to which the server responds by selecting one or none of the acceptable protocols
  • This may include sec-websocket-extensions, protocol Extensions, which may support multiple Extensions for a protocol
  • May include any other fields, such as cookies

The server responds as follows:

HTTP/1.1 101 WebSocket Protocol Handshake Upgrade: WebSocket Connection: Upgrade SEC-websocket-accept: Y+Te7S7wQJC0FwXumEdGbv9/Mek=

ShellCopy

Description:

  • The Upgrade header field must be included and has a value of websocket
  • The Connection header field must be included and has a value of Upgrade
  • The sec-websocket-Accept header must be included, which concatenates the value of the request packet sec-websocket-key with the string 258eAFa5-E914-47DA-95CA-C5AB0DC85b11. The concatenated string is then sha-1 and base64 encoded, which is the value of sec-websocket-Accept
  • There is a space after the colon in the reply packet
  • Two blank lines are needed to end the reply packet

Then the communication is established, followed by ws two-way communication, not HTTP.

Reading 1 was released just now