“This is the 16th day of my participation in the Gwen Challenge in November. Check out the details: The Last Gwen Challenge in 2021.”

Hello, I’m looking at the mountains.

I’ve been hearing about HTTP long connections. I only know that long connections save more resources and are faster than short ones, but I don’t really know why. This state of affairs is dangerous for technology. So, still want to dig a principle, even if dig relatively shallow, also want to take this step.

HTTP is an application-layer protocol. TCP is used at the transport layer, and IP is used at the network layer.

The IP protocol mainly solves the problem of network routing and addressing, the TCP protocol mainly solves the problem of how to transmit data packets reliably on the IP layer, so that the other end of the network receives all the packets sent by the sender, and the order is consistent with the order of sending. The HTTP protocol is mainly based on the TCP protocol to complete data transmission.

Let’s start with TCP connections and disconnections.

The TCP life cycle is nicknamed the three-way handshake and four-way wave. Each handshake (wave) requires data exchange between the communication parties. Therefore, the transmission of data over the TCP connection is relatively resource-consuming, which is commonly referred to as high cost.

TCP’s three handshakes and four waves

However, the HTTP protocol is stateless and connection-oriented, meaning that the protocol itself has no memory and there is no connection between two different HTTP requests.

Before HTTP/1.1, when a web page loaded a resource, it needed to make an HTTP request, establish a connection, and disconnect after the request, and each connection (TCP connection) needed to consume resources (time resources, network resources, etc.).

Therefore, in HTTP/1.1, persistent connection was introduced. In other words, TCP connections are not closed by default and can be reused by multiple requests. There is no need to declare connection: keep-alive, also known as long connection.

The long connection mentioned here is actually a TCP long connection. For example, when an HTTP request is made, a TCP connection is created between the client and server. After receiving the response result, the TCP connection is kept for a period of time instead of the four TIMES of TCP wave. At this point, if there is another HTTP request to the same server, the same TCP connection will continue to be used. In this way, TCP connection consumption is saved.

Of course, for efficient utilization of resources, the client or server will disconnect the TCP connection when there is no activity for a period of time (timeout time, set in the keep-alive: timeout=10 in the request header). The recommended approach is to send Connection: close in the request header on the last request from the client, explicitly asking to close the TCP Connection.

Add TCP three handshake, four wave knowledge.

Three handshakes to establish a connection:

  1. First handshake: The client sends a SYN packet (seq= X) to the server and enters the SYN_SEND state for confirmation.
  2. Second handshake: After receiving a SYN packet, the server must acknowledge the client’s SYN (ACK= X +1) and send a SYN packet (SEq = Y). In this case, the server enters the SYN_RECV state.
  3. Third handshake: After receiving the SYN+ACK packet from the server, the client sends an ACK packet (ACK= Y +1) to the server. After the packet is sent, the client and the server enter the ESTABLISHED state to complete the three-way handshake.

The packet transmitted during the handshake does not contain data. After three handshakes, the client and server start data transmission. Ideally, once a TCP connection is established, it is maintained until either of the communicating parties voluntarily closes the connection.

Four waves to disconnect

  1. First wave: The active closing party sends a FIN to shut down the data transmission from the active to the passive closing party, that is, the active closing party tells the passive closing party: I will not send you any more data (of course, if the data sent before the FIN packet is not received, the active closing party will resend the data), but the active closing party can still accept the data at this time.
  2. Second wave: After receiving a FIN packet, the passive closing party sends an ACK with the received sequence number +1 (the same as SYN, one FIN occupies one sequence number).
  3. Third wave: The passive closing party sends a FIN to close the data transfer from the passive closing party to the active closing party, which tells the active closing party that MY data has also been sent and I will not send you any more data.
  4. Fourth wave: After the active closing party receives the FIN, it sends an ACK to the passive closing party and confirms that the serial number is +1. Thus, the four waves are completed.

Note: The interrupt end can be either Client or Server.

Detailed status description

  • SYN_SEND: The client attempts to connect to the server through the open method. After step 1 of the TCP three-way handshake, note the client state
  • SYN_RECEIVED: After the service accepts the SYN of the creation request, step 2 in the TCP three-way handshake, and before sending the ACK packet. Generally, the number of packets is about 15. If the number is large, SYN_FLOOD attacks are suspected
  • ESTABLISHED: Indicates the state after the client receives the ACK packet from the server. The server changes to ESTABLISHED after sending the ACK packet
  • FIN_WAIT1: The active closing party, after issuing the FIN request, is the first of four TCP waves
  • CLOSE_WAIT: The passive closed party, after receiving the client’s FIN, is the second step in TCP’s four waves
  • FIN_WAIT2: The active closing party, after receiving the ACK from the passive closing party, is the second step of TCP’s four waves. You can set the timeout period after the passive closing party returns the FIN to effectively reclaim links and prevent SYN-flood attacks.
  • LASK_ACK: A passive closed party initiates a FIN request some time after sending an ACK (ensuring that the client has received it). This is the third step of TCP’s four waves
  • TIME_WAIT: The active closing party sends an ACK upon receiving the passively closed FIN packet. This is the fourth step of TCP’s four waves

Hello, I’m looking at the mountains. Swim in the code, play to enjoy life. If this article is helpful to you, please like, bookmark, follow. Welcome to follow the public account “Mountain Hut”, discover a different world.