This is the 10th day of my participation in the August More Text Challenge. For details, see:August is more challenging

Related articles:

  • Have you really figured out HTTP? (a)
  • Have you really figured out HTTP? (2)
  • Have you really figured out HTTP? (3)
  • Have you really figured out HTTP? (4)

Why does TCP need three handshakes and four waves?

1.1 Three handshakes

Three-way Handshake is when a TCP connection is established with a total of Three packets sent by the client and server

The main function is to confirm whether the receiving ability and sending ability of both sides are normal, and specify their own initialization sequence number for the reliability of later transmission preparation

The process is as follows:

  • First handshake: The client sends a SYN packet to the server with the ISN(c), and the client is in the SYN_SENT state
  • Second handshake: After receiving a SYN packet from the client, the server responds with its own SYN packet. To confirm the SYN from the client, the SERVER uses the ISN+1 as the ACK value. In this case, the server is in the SYN_RCVD state
  • Third handshake: After receiving the SYN packet, the client sends an ACK packet with the ISN+1 value of the server. The client is in the ESTABLISHED state. After receiving an ACK packet, the server is in the ESTABLISHED state. In this case, a connection has been ESTABLISHED between the server and the SERVER

Each of these handshakes does the following:

  • First handshake: The client sends a network packet and the server receives it so the server can conclude that the sending capability of the client and receiving capability of the server are normal.
  • Second handshake: the server sends the packet and the client receives it. The client can conclude that the server’s receiving and sending capabilities and the client’s receiving and sending capabilities are normal. However, the server is not able to confirm whether the client’s reception is normal
  • Third handshake: The client sends the packet and the server receives it. In this way, the server can conclude that the client’s receiving and sending capabilities are normal, and the server’s own sending and receiving capabilities are also normal

With three handshakes, it is possible to determine that the receiving and sending capabilities of both parties are normal. After that, you can communicate normally

Why not two handshakes?

If it is a two-time handshake, the sender can be sure that the other party can receive the message and the other party can receive the packet, but the receiver can only be sure that the other party can receive the packet but not the other party can receive the packet

In addition, if the two-time handshake is used, the client may send multiple request packets due to network congestion. The delayed request establishes a connection with the server and wastes many server resources

1.2 Four waves

TCP terminates a connection after four waves

The process is as follows:

  • First wave: The client sends a FIN packet. The packet contains a serial number. The client is in FIN_WAIT1 state, stops sending data, and waits for the acknowledgement from the server
  • Second wave: After receiving the FIN packet, the server sends an ACK packet and uses the client sn +1 as the SERIAL number of the ACK packet to indicate that it has received the packet from the client. In this case, the server is in CLOSE_WAIT state
  • Third wave: If the server also wants to disconnect the connection, the server sends a FIN packet with a serial number as the first wave on the client. The server is inLAST_ACKThe state of the
  • Fourth wave: After receiving the FIN packet, the client sends an ACK packet and uses the server sn +1 as the SN of the ACK packet. In this case, the client is in TIME_WAIT state. The server enters the CLOSED state after receiving ACK packets. After receiving ACK packets, the server closes the connection and is in the CLOSED state

Reasons for four waves

After receiving a Fin packet from the client, the server does not close the connection immediately. Instead, it sends an ACK packet to inform the client that it has received the request to close the connection. After all packets are sent, the server sends a Fin packet to disconnect the connection

1.3 summarize

A complete three-handshake and four-wave look like this:

What is your understanding of WebSocket? Application Scenario?

2.1 what is

WebSocket, a network transport protocol, is located in the OSI model of the application layer. Full-duplex communication can be carried out on a single TCP connection, which can better save server resources and bandwidth and achieve real-time communication

A handshake is all that is needed to create a persistent connection between the client and the server and two-way data transfer can take place

As you can see from the figure above, the WebSocket server and the client connect through a handshake. After the connection is successful, both of them can actively send or receive data to each other

Before WebSocket, real-time Web applications were developed by polling

It keeps sending HTTP requests to the server, asking for data, and when it does, the server responds with a response packet. If the polling frequency is high, then the “real-time communication” effect can be approximated

The disadvantages of polling are also obvious: repeatedly sending invalid query requests consumes a lot of bandwidth and CPU resources

2.2 the characteristics of

Full duplex

Communication allows data to be transmitted simultaneously in both directions and is equivalent in capability to a combination of two simplex communication modes

For example, when A goes to B and B goes to A, it’s instantaneous

Binary frame

Using binary frame structure, syntax and semantics are completely incompatible with HTTP, compared to HTTP/2, WebSocket is more focused on “real-time communication”, while HTTP/2 is more focused on improving transmission efficiency, so the frame structure of the two is also very different

Unlike HTTP/2, streams are not defined, and features such as multiplexing, priority, and so on do not exist

It is full-duplex and does not require server push

Agreement,

Ws and WSS are introduced to represent the plaintext and ciphertext WebSocket protocols, respectively, and the default port is 80 or 443, almost the same as HTTP

ws://www.chrono.com
ws://www.chrono.com:8080/srv
wss://www.chrono.com:445/im?user_id=xxx
Copy the code

Shake hands

WebSocket also requires a handshake process before it can formally send and receive data

The client sends data in the following format:

GET /chat HTTP/1.1
Host: server.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://example.com
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
Copy the code
  • Connection: Upgrade must be set, indicating that the client wants to connect to the Upgrade
  • Upgrade: Websocket must be set, indicating that you want to Upgrade to the Websocket protocol
  • Sec-websocket-key: a Base64-encoded ciphertext sent by the client and used as a simple authentication Key. The server must return an encrypted “sec-Websocket-Accept” response or the client will throw an error and close the connection
  • Sec-websocket-version: indicates the supported WebSocket Version

The format of the data returned by the server:

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=Sec-WebSocket-Protocol: chat
Copy the code
  • HTTP/1.1 101 Switching Protocols: Indicates that the server accepts the WebSocket client connection
  • Sec-websocket-accep: Authenticates client request packets, also to prevent false connections. To do this, add a dedicated UUID to the “sec-websocket-key” value in the request header, and then calculate the digest

advantages

  • Less control overhead: The packet header protocol is smaller, unlike HTTP, which requires a full header to be carried on each request
  • More real-time: Significantly less latency than HTTP requests that need to wait for a client to initiate a request before the server can respond
  • Maintain the connection state: After the communication is created, the status information can be omitted. Unlike HTTP, each request requires authentication
  • Better binary support: Binary frames are defined for better handling of binary content
  • Extension: Users can extend the WebSocket protocol and implement some customized sub-protocols
  • Better compression: Websockets, with appropriate extension support, can use the context of previous content, which can significantly improve compression when passing similar data

2.3 Application Scenarios

Based on the characteristics of webSocket factual communication, it exists in the following application scenarios:

  • barrage
  • Media chat
  • Collaborative editing
  • Location-based applications
  • Sports updates
  • Stock fund quotes are updated in real time