Three handshakes and four waves.

I. Serial number and confirmation number

Establish a connection before sending an HTTP request (three-way handshake) :

When sending data, the sender does not need to send an acknowledgement signal every time the TCP segment is sent. In the figure above, each segment sends an acknowledgement signal just to give us a better understanding of the sending process.

The serial number is the sender so that the receiver knows which piece of data is being sent. The true serial number does not start at 1 (relative value), but is a large value (raw value), which wireshark has calculated to facilitate memorization and learning.

The serial number is determined when the connection is established.

The ACK number is the byte from which the receiver tells the sender to start the next data transmission.

Why can’t the original ordinal value start at 1 (simple value)?

For safety. When the serial number is very simple, you can know what the next packet to be sent is by capturing the packet, and then simulate the packet data for transmission.

Sequence number and confirmation number interaction flow

Only the first two SYN values are 1 (SYN=1), and the subsequent SYN values are 0 (SYN=0). After the connection is established (three-way handshake) the HTTP request is formally sent.

In the actual transmission process, the initial value of the serial number will not be 1, but a random number to prevent prediction and exploitation. Take a look at the ACK number and sequence number transmission process:

The server also sends data to the client. The client calculates the initial number and sends it along with the data to the server. The server computes the ACK number and sends it back. The server needs to calculate an initial number of its own and send it with the data to the client, which then returns an ACK to the server.

In this way, both sides tell each other their initial serial number and start transmitting data, as shown in the figure below:

The initial serial numbers of both the client and server are determined (randomly) when TCP establishes the connection, and each tells the other the serial number. Before sending and receiving data, the serial number of the client is Seq = Serial number of the last client (the first time is the initial value) + TCP segment byte number. The TCP segment byte number is the number of the TCP segment and is a relative value. The ACK number of the server is ACK = Seq + TCP segment length of the client. The server sends data to the client in the same way (using the initial serial number of the server).

For example, the initial serial number of the client is 123456, and that of the server is 56789. After the connection is established, the serial number of the first packet sent by the client is Seq = 123456 + 1 = 123457. Assume that the Length of the TCP packet is 100 bytes, and the ACK number of the server is ACK = Seq + Length = 123557.

The initial value of the sender’s serial number is used for both the sender’s serial number and the receiver’s confirmation number.

Remove s1 and S2 from the original values, and the remainder is the relative value.

Two, establish a connection (three handshake)

  • CLOSED: The client is closed.
  • LISTEN: The server is listening and waiting for the client to connect.
  • SYN-RCVD: Indicates that the server receives a SYN packet. After receiving an ACK packet from the client, the server enters the SYN packetESTABLISHEDState.
  • SYN-SEND: Indicates that the client sends a SYN packet and waits for the second handshake from the server.
  • ESTABLISHED: Indicates that the connection is established.

Features of the first 2 handshakes:

  • SYN is set to 1
  • The length of the data part is 0
  • The length of the TCP header is 32 bytes, the fixed part is 20 bytes, and the option part is 12 bytes

The two sides exchange confirmation information such as MSS, whether SACK is supported, Window scale (Window scaling factor), etc. This data is placed in the options section of the TCP header (12 bytes).

Why three handshakes when establishing a connection? Can’t you do it twice? The main purpose is to prevent the server from wasting resources by waiting all the time.

  • Only 2 handshakes are required if a connection is established. Suppose that the first connection request packet segment sent by the client does not reach the server until some time after the connection is released due to network latency.
  • This is an invalid connection request. However, after receiving the invalid request, the server mistakenly thinks it is a new connection request sent by the client. Therefore, the server sends an acknowledgement packet to the client, agreeing to establish a connection.
  • If the three-way handshake is not used, a new connection is established as soon as the server sends an acknowledgement.
  • Since the client does not really want to connect to the server, it ignores the server’s confirmation and does not send data to the server.
  • However, the server thinks that a new connection has been established and waits for data from the client, thus wasting a lot of resources.

The three-way handshake prevents this from happening. For example, if the client does not send an acknowledgement to the server, the server knows that the client does not request to establish a connection.

What happens if the third handshake fails?

  • The state of the server isSYN-RCVD, if the client cannot waitACK, the server will resendSYN+ACKThe package;
  • If the server resends multiple timesSYN+ACKI can’t even wait for the clientACK, will be sentRSTPackage to force the connection to close.

3. Release the connection (wave four times)

  • FIN-WAIT-1: indicates that you want to close the connection.
    • A FIN packet is sent to the peerFIN-WAIT-1State.
  • CLOSE-WAIT: Indicates that the system is waiting to close.
    • When the peer sends a FIN packet to the peer, the peer sends an ACK packet to the peerCLOSE-WAITState.
    • In this state, you need to check whether you still have data to send to the peer party. If no, you need to send FIN packets to the peer party.
  • FIN-WAIT-2: Once the other party sends an ACK, the active party will be inFIN-WAIT-2Status and waits for the FIN packet to be sent.
  • CLOSING: a rare exception.
    • After you send a FIN packet, you receive a FIN packet from the peer party instead of an ACK packet.
    • If the two parties prepare to close the connection at almost the same time, the two parties send FIN packets at the same timeCLOSINGState.
    • Indicates that both parties are closing the connection.
  • LAST-ACK: Passive close After a party sends a FIN packet, it waits for the ACK packet from the other party. After receiving an ACK packet, you can enter the deviceCLOSEDState.
  • TIME-WAIT: indicates that the FIN packet is received and an ACK packet is sent. The IP address can be accessed after 2MSLCLOSEDState.
    • ifFIN-WAIT-1If the peer receives a PACKET with both the FIN and ACK flags, the peer can directly enterTIME-WAITState without having to go throughFIN-WAIT-2State.
  • CLOSED: Closed.

Some states, such as SYN-rcvd and fin-wait, are difficult to see with netstat because they are ephemeral.

Why should a connection be released in time-wait state? Can you just release it? The TCP/IP stack is designed to allow either party to initiate a disconnect request first. Here is a demonstration of the client’s initiative to disconnect.

After sending ACK packets, the client needs to WAIT for a period of TIME before closing the connection. The Maximum Segment Lifetime is the Maximum Segment Lifetime. MSL is the maximum lifetime of TCP packets on the Internet. Each SPECIFIC TCP implementation must select a definite MSL value. RFC1122 recommends 2 minutes. This prevents the packets generated in this connection from being mistransmitted to the next connection (because the packets in this connection will disappear in 2MSL time).

If the CLIENT releases the ACK immediately and the server does not receive the ACK from the client due to network reasons, the server resends the FIN. Here’s what might happen:

  • If no response is received from the client, the server waits for the FIN to be sent repeatedly, wasting resources.
  • A new application assigned to the client with the same port number disconnects immediately after receiving the FIN. It may have wanted to establish a connection with the server.

In the time-wait state, a client waits to see whether the server sends a FIN packet (to prevent ACK packet loss).

Why do you wave four times to release the connection? The main reason is that TCP is in duplex mode.

  1. First wave: When host 1 sends a FIN packet
    • Indicates that host 1 tells host 2 that host 1 has no data to send, but host 1 can still receive data from host 2
  2. Second wave: When host 2 returns an ACK packet segment
    • Indicates that host 2 knows that host 1 has no data to send, but host 2 can send data to host 1
  3. Third wave: When host 2 also sends a FIN packet segment
    • Indicates that host 2 tells host 1 that host 2 has no data to send
  4. Fourth wave: When host 1 returns an ACK packet segment
    • Indicates that host 1 knows that no data is sent from host 2, and then officially disconnects the TCP connection

For more articles in this series, please pay attention to wechat official account [1024 Planet].