One, foreword

★, this article contains 100 front-end interview questions, carefully read all the questions, a feeling in the body several knife can not breathe, leaving no technical tears, had to remolding ~

What is your understanding of TCP three-way handshake and four-way wave? This is a particularly common topic for front-end interviews, so let’s look at TCP’s three-way handshake and four-way wave

Why is there TCP/IP

Computer users realized that computers alone would not do much good. Only when they are combined will the computer reach its full potential. So people tried to wire computers together. But simply connecting is not enough. You need to define something common to communicate, and TCP/IP was born for that. With these, the computer can communicate freely with other computer terminals, just like learning a foreign language.

Introduction to TCP

The TCP Transport Control Protocol (TCP) is a connection-oriented, reliable, byte stream based Transport layer communication Protocol. It is specially designed to provide reliable end-to-end byte stream over unreliable Internet networks.

Remember the keywords “connection-oriented”, “reliable”, and “byte stream”, which are the keys to mastering TCP:

  • Connection-oriented: A connection needs to be established before the client and server exchange data
  • Reliability: Ensures the accurate delivery of packets over an unreliable network through a specific mechanism
  • Byte stream: The smallest unit of data in bytes. The meaning of what is stored in bytes is determined by the application layer


4. TCP packet format

The fields are described as follows:

⒈ Source Port: 16 bits, indicating which process data comes from.

⒉ Destination Port (Destination Port) : a 16-bit Port that indicates the process to which data is sent.

⒊ Sequence Number: 32-bit, the part of the DATA in the TCP packet segment, in which each byte has its Sequence Number (increasing). Sequence Number indicates different meanings according to whether the SYN in the control flag is 1 or not:

  • SYN = 1: The connection is being established, and the ISN is the initial sequence number. When data transfer begins, the ISN + 1 is the sequence number of the first byte of data
  • SYN = 0: indicates the sequence number of the first byte in the data part of the current packet segment.

This Acknowledgment Number: 32 bits. When the ACK of the control flag is 1, it indicates the Sequence Number of the next packet segment that the sender expects to receive. Once a connection is established, the ACK value is always 1.

5. Data Offset (a) : 4-bit, the header length of the TCP packet segment, in Word (4 bytes). It is the offset from the start of a TCP packet segment to the start of a TCP packet segment. The largest number that can be represented in 4 bytes is 15, so the largest header is 60 bytes.

Pictures of Reserved: 6 bits, Reserved for future use, must be 0.

7. Control Bits: There are six Control Bits, including SYN/ACK and FIN/ACK for connection establishment and disconnection.

  • URG: When set to 1, it indicates that the Urgent Pointer field is valid.
  • ACK: Confirm that the serial Number field is valid;
  • PSH: The receiver immediately sends the packet segment to the application layer.
  • RST: reestablishes the connection.
  • SYN: indicates the synchronization sequence number, which is used to establish a connection.
  • FIN: The sender stops sending data.

8. Window Size: 16 bits, allowing the amount of data to be sent. Control the speed at which the other person can send data by telling them how many bytes they can hold in their buffer.

Its advantages are Checksum and Checksum: 16 bits. The sender carries out CRC operation on the TCP head and data. After receiving the data, the receiving end performs CRC operations on the header and data of the received TCP packet segment and compares them with the verification in the TCP header to ensure that the data is not damaged during transmission.

The Urgent Pointer is of 16 bits. It takes effect only when URG=1. Its value is an offset, which is added to the value in the serial number field to get the serial number of the last byte of the emergency data.


5. Connect vs. disconnect

TCP is a connection-oriented unicast protocol. Before sending data, communication parties must establish a connection. The so-called “connection” is actually a piece of information about each other, such as IP address and port number, stored in the memory of the client and server.

TCP provides a reliable, connection-oriented, byte stream, transport layer service that establishes a connection using a three-way handshake. Use four waves to close a connection.

Establish a connection – three handshakes

Both the client and server are initially CLOSED. The client actively opens the connection, while the server passively opens the connection.

The TCP server process creates the TCB and is ready to accept the connection request from the client process. At this time, the server enters the LISTEN state.

The TCP client process first created a TCB and then SENT a connection request packet to the server. SYN=1 was selected in the header of the packet. Seq = X was selected as the initial sequence number. According to TCP, the SYN segment (SYN=1) cannot carry data, but must consume a sequence number.

The TCP server receives the request packet and sends a confirmation packet if it agrees to the connection. In the acknowledgement packet, ACK=1, SYN=1, ACK= X +1, and seq= Y are initialized. Then, the TCP server process enters the SYN-RCVD state. This message also does not carry data, but again consumes a serial number.

After receiving the confirmation, the TCP client process needs to confirm the confirmation to the server. Confirm the ACK=1, ACK= y+1, and seq= X +1 of the packet. In this case, the TCP connection is ESTABLISHED and the client enters the ESTABLISHED state. According to TCP, AN ACK packet segment can carry data, but does not consume serial numbers if it does not.

When a CLIENT acknowledges a SCHEME, the server also enters the ESTABLISHED state. After that, the two parties can communicate.

Disconnect – Wave four times

After data transfer is complete, both parties can release the connection. Initially, both the client and the server are in an ESTABLISHED state, and then the client is actively shut down and the server is passively shut down.

The client process sends a connection release packet and stops sending data. Release the header of the data packet, FIN=1, whose sequence number is SEq = U (equal to the sequence number of the last byte of the previously transmitted data plus 1). At this point, the client enters the fin-WaIT-1 state. According to TCP, FIN packets consume a sequence number even if they do not carry data.

The server sent an ACK=1 (ACK= U +1) with its own serial number (SEq = V). Then the server entered the close-wait state. The TCP server notifies the higher-level application process that the client is released from the direction of the server. This state is half-closed, that is, the client has no data to send, but if the server sends data, the client still accepts it. This state also lasts for a period of time, i.e. the duration of the close-wait state.

After receiving the confirmation request from the server, the client enters the fin-WaIT-2 state and waits for the server to send the connection release packet. The client also needs to receive the final data from the server.

After sending the LAST data, the server sends a connection release packet (FIN=1, ACK = U +1) to the client. Because the server is in the half-closed state, the server probably sends some more data. Assume that the serial number is SEq = W.

When a CLIENT receives a CONNECTION release message from the server, it must send an acknowledgement (ACK=1, ACK= w+1) with its own sequence number (SEq =u+1). Then the client enters the time-wait state. Note that the TCP connection is not released at this time, and the client can enter the CLOSED state only after 2∗ *∗MSL (maximum packet segment life) and the corresponding TCB is revoked.

The server shall enter the CLOSED state immediately after receiving the confirmation sent by the client. Similarly, revoking the TCB terminates the TCP connection. As you can see, the server ends the TCP connection earlier than the client.

Packet capture and parse the TCP life cycle

The following shows the screenshot for capturing packets in the Wireshark: 1 establishing a connection, 2 Transferring data, and 3 disconnecting a connection

[1] Establish a connection

① Client – > server: [SYN] Seq=0; The initial Seq value of the client and server is not 0. The value shown in the screenshot is a relative value, which is converted by wireshark to facilitate packet capture and analysis.

Server – > client: [SYN, ACK] Seq=0, ACK =1;

③ Client – > server: [ACK] Seq=1, ACK =1

[2] Send data

The data exchange is two-way, and the HTTP response on the server is used as an example. The response contains a large number of TCP packets. The whole data sending process is that the server sends data to the client, and the client sends confirmation to the server.

① Server – > client: Seq=1, TCP data length 273. In other words, the serial number of the first data byte in the packet segment sent by the server is 1. The sequence number of the first data byte in the next TCP packet segment should be 274 (1 + 273).

② Server – > client: Seq=274, TCP data length 1400. In other words, the serial number of the first data byte in the packet segment sent by the server is 274. The sequence number of the first data byte in the next TCP packet segment should be 1674 (274 + 1400).

③ Client – > server: Ack=274. Indicates that the client has received all bytes before the serial number 274. That is, if the server continues to send TCP packets to the client, it should send data with serial number 274 or later.

④ The following analysis process is the same as above

[3] Disconnect

When the server receives the disconnection request (FIN=1) from the client, the server sends the FIN and ACK in the same response packet, reducing the number of packets.

Nine, often meet test questions

[1] To create a connection, why does the TCP client send an acknowledgement at the end?

In short, the main purpose is to prevent invalid connection request packets suddenly sent to the server, resulting in errors.

If you are using two handshake connection is established, suppose there is such a scenario, the client sends the first request connection and not lost, just because in the network node in the retention time is too long, as a result of the TCP client has not received the confirmation message, thought the server did not receive, at this time to send this message to the server, The client and server then complete the connection with two handshakes, transfer data, and close the connection. This message should be invalid. However, the two-handshake mechanism will allow the client and server to establish a connection again, which will lead to unnecessary errors and waste of resources.

If the three-way handshake is used, even if the invalid packet is sent, the server receives the invalid packet and replies with an acknowledgement message, but the client does not send an acknowledgement again. Since the server does not receive an acknowledgement, it knows that the client has not requested a connection.

[2] Can data be carried during the three-way handshake?

The first and second handshakes can’t carry data, and one simple reason is that it makes the server more vulnerable. For the third time, the client is already in ESTABLISHED state. As far as the client is concerned, it has already established the connection and already knows that the server’s receiving and sending capabilities are normal, so there is no problem with carrying data.

[3] What is a SYN attack?

In a SYN attack, the Client forges a large number of nonexistent IP addresses and sends SYN packets to the Server. The Server replies with an acknowledgement packet and waits for the Client to confirm the attack. Because the source IP address does not exist, the Server resends the packets until the attack times out. These forged SYN packets occupy unconnected queues for a long time. As a result, normal SYN requests are discarded because the queues are full, causing network congestion or even system breakdown. SYN attack is a typical DoS/DDoS attack.

[4] Why does the client end up waiting for 2MSL?

Maximum Segment Lifetime (MSL) indicates the Maximum Segment Lifetime of a packet. After the Maximum Segment Lifetime, the packet is discarded. TCP allows different implementations to set different MSL values.

First, ensure that the client sends the final ACK packet to reach the server, because the ACK packet may be lost, standing in the server’s perspective, I have already sent the FIN + ACK message request disconnect, the client also did not give me response, should be I send the request of the disconnect message it did not receive, then the server will send a again, The client receives the retransmitted message within the 2MSL period, responds with a message, and restarts the 2MSL timer.

Second, prevent “invalid connection request message segment” as mentioned in “three-way handshake” from appearing in this connection. After the client sends the last acknowledgement message, in this 2MSL time, all the message segments generated during the duration of the connection can be removed from the network. In this way, the new connection does not contain the request packets of the old connection.

[5] Why is there a three-way handshake to establish a connection and a four-way wave to close it?

During connection establishment, the server receives a SYN packet in LISTEN state and sends the ACK and SYN packets to the client. And close connection, the server receives the other side of the FIN message, just said to each other can no longer send data but also receives the data, and the oneself also is not necessarily all data are sent to each other, so their can immediately shut down, also can send some data to each other, then send the FIN message now agreed to close the connection to the other side, therefore, The ACK and FIN are usually sent separately, resulting in an extra ACK.

[6] What if the connection has been established, but the client suddenly fails?

TCP also has a keepalive timer, so obviously if the client fails, the server can’t wait forever and waste resources. The server resets this timer every time it receives a request from the client, usually for two hours. If it does not receive any data from the client within two hours, the server sends a probe segment, which is then sent every 75 seconds. If there is no response after 10 probe packets are sent, the server assumes that the client is faulty and closes the connection.