Think about the key

  • How does TCP confirm that the peer receives a message?
  • Header message changes in message sending and receiving?
  • Close the connection operation?

Core knowledge

Packet sending and receiving

When the connection is completed using connect(), the control flow is returned to the application and we can use write() to send messages and read() to read messages. The write() operation, however, allows the application to determine how much data to write. This data is stored in the buffer allocated by the operating system through the protocol stack, and the TCP module determines how much data to publish at a time. Similarly, a read() operation fetches a message to a specific buffer allocated by the operating system

Due to TCP’s emphasis on reliability and connection-oriented communication, both parties need to respond to the sender with an ACK to indicate that they have received the packet. In addition, assuming that TCP does segment data from an application, the sender must use the sequence number function to tell the receiver exactly where the packet occupies the entire data in order to prevent messages from missing

Drop application layer data

Although call write () operation will specify in length, but the protocol stack will first will specify the length of the data in the buffer, send the packet will not be completely in accordance with the specified length, and each operating system to release the packet length limit are not the same, but they consistent aim is to avoid too frequently send short data length, and is too long the congestion of data length and time delay

To achieve greater efficiency, the protocol stack also allows the application to set a flag to tell the protocol stack how to handle buffer messages when performing send operations. For example, allow the buffer to publish messages when it is not full

Buffers have extra configuration timers to prevent problems that have not been published for too long


Shown above a send packet set of functions, by creating a special set of packet length of buffer, it will be in the unit time or in the operating system will go into the buffer to the length of a data packet buffer into a group, to reach the specified length, the assembled packets will send out after (here is based on three packets examples), This feature is mostly used on devices with limited network connectivity

TCP segmentation function

Generally speaking, the data length of the application does not exceed MSS(maximum packet length), so the application data does not involve data shredding, also known as segmentation. However, some applications, such as submitting a form or Posting a very long string of data, may be beyond the scope of MSS, so TCP will need to process these packets, cutting them up into smaller pieces


The segmented function of TCP is just like cutting a freshly baked cake into good equal parts, packaging the segmented cake and selling it to consumers with a brand name. After all, will anyone really buy the whole cake at one time? I’m afraid not

TCP also cuts application data that exceeds MSS into equal pieces, with special attention to the inclusion of application layer protocol headers


So the question comes, how do the transmission parties decide the length of the cut? In fact, in the three-way handshake between the communication parties, the two parties will fill in their allowed MSS length in the option part of the TCP header, and select the smallest one as the cutting size of TCP segment after comparison. In the future data transmission, if the data length exceeds MSS(suppose 500 on the way), the data will be divided by 500


Function of ACK and serial number

Why use TCP? One of the goals is to make communication between two parties reliable, so of course, a message packet cannot be sent and ignored. TCP requires the receiver to respond whether the message was received correctly to determine whether to initiate a retransmission mechanism. In addition, if the data is segmented, the receiver should use the received serial number message to determine whether packets are missing and how to assemble them after receiving them

ACK is like in the chat “uh, oh, vp”, it tells the other I received your message, do you remember when I was in the use of network video, if a delay in the conversation, the dialogue will become very strange, when I said a word, the other will have a period of time have no reaction, then just think I should to say it again? Did the other person not understand me? However, it usually takes a second or two for the other person to respond. It seems that I have a much higher standard of time delay than computers.

ACK and serial number


The receiver can calculate the bytes to start from next time by subtracting the data offset of the TCP header from the total length of data. This mechanism can avoid packet loss. For example, the next time a packet with the serial number 501 is received but the packet with the serial number 1000 is lost during transmission. In addition, the operating system is configured with a Timer to determine whether a response has been received within a specified period of time, and therefore whether to start retransmission

For the sender, the serial number is when he tells the receiver where and how long the data I want to send starts. For the receiver, I reply to the sender that I received successfully. What bytes should the next packet start from

The figure above embodies the serial number communication between the two parties and the handling method of packet loss

  • If the sender’s data packet has been successfully received, the receiver calculates the length of the data received so far. If the packet has not been received in its entirety, the received data range +1 is written to the TCP header
  • If the receiver does not receive a packet, or the response is lost in the network, the sender determines that the packet failed to be sent after the waiting time has elapsed. It does not investigate the cause and sends the same packet again
  • In another case, if the sender’s packet is lost in the network for unknown reasons, or the packet format is wrong and cannot be parsed by the receiver, the packet will be resend after a certain waiting time

Acknowledgment Number: Displays the starting position of the data packet to be received next time. This Number -1 is the total length of the control bit ACK(Acknowledgment Flag) that is currently received: Bolin value, set to 1 during TCP three-way handshake and packet reception means I received your data

About the starting serial number In general packet number won’t be the start of the 1, but borrow when the connection is established by the client and the server sends the sequence number of a common random number, the aim is to prevent the network attacker to predict the packet sequence number, improve security, but the subsequent confirmation still is + 1

Timed retransmission mechanism

When a packet sent by a client does not receive an acknowledgement message within a specified period of time, the retransmission mechanism is started.

In fact, TCP dynamically monitors the sending and receiving status of packets, calculates the sending time of each packet and estimates the elapsed time. The elapsed time varies according to the operating system (for example, UNIX and Windows use 0.5 seconds as a unit). However, the default timeout time is set to 6 seconds at the beginning because you do not know the connection status of the packet

Not overweight transfer mechanism is not without any restrictions, often operating system will set a retransmission limit retry limit, when more than all the operating system will be more than when the time is adjusted for 2, 4 times index, but if the client pass too many times to retry the quota of draining it will trigger disconnect socket connection or to establish a connection


TCP’s requirement for time-out is not to trigger time-out easily, send more packets, and take the minimum value of 0.5 second multiples of the average value (for example, UNIX). Sometimes, however, the fluctuation range is too steep, such as in the second figure above. This is usually due to conditions such as congestion in the network core, in which the operating system sets a higher upper limit for the elapsed time than normal

Do you feel a bit of trade off from some TCP operations? After all, in reality, it is difficult to have your cake and eat it. Efficiency, reliability and speed will be adjusted according to the actual application scenarios, and there is no absolute superiority or inferiority

Disconnect the attachment

Disconnection occurs after data transfer is complete, or for certain operations. If the browser disconnects the connection after requesting the end of the connection from the server, the communication ends. Another situation may be that the server determines that the data packet sent by the client does not meet the format and disconnects the connection. Therefore, the disconnection operation can be initiated by both the client and the server, depending on the current communication status

Disconnecting operation

For example, the client disconnects after all requests are sent. Because both sender and receiver need to send two FIN packets and two ACK packets, disconnection is also called four-way handshake


  1. The client writes the control bit message FIN = 1 to the TCP header and sends it to the server
    • Client AccessFIN_WAIT_1Wait for the server to respond with ACK
    • The server writes the ACK to the TCP header
  2. The server sends an ACK message back to the client
    • The client knows that the server is disconnecting and changes the state toFIN_WAIT_2Wait for the server to return the final FIN message
    • The server stack communicates the disconnection message to the specified application, and the server is inCLOSE_WAITState wait result
  3. After processing the disconnection message, the application calls the Socket API and delegates the protocol stack to return the message containing FIN = 1 to the client
    • After receiving the FIN = 1 message, the client sends back an ACK and entersTIME_WAITCountdown state
    • The server is inLAST_ACKStatus, waiting for the client to return an ACK message to it
  4. The server successfully received the ACK message. Procedure
    • The client will count down and enter the CLOSE state automatically after 2MSL
    • The server enters the CLOSE state as soon as it receives the ACK response

Enter CLOSE after 2MSL

The first thing to note is that only the party that initiated the break request in the first place enters the TIME_WAIT phase. We assume that the client receives the first server sends FIN news immediately enter the stage of the CLOSE, but good dead deathless, unstable network conditions or any communication delay caused more than more than client ACK response time, when the server will be FIN retransmission, if so just again, client just created another socket port number of the same application, In this case, the returned FIN message packet may incorrectly close the connection. The MSL is the Maximum Segment Lifetime, which can be interpreted as the processing time of a set of FIN messages. Linux default is 60 seconds. The client will delete the corresponding socket after 2MSL of time if it is confirmed that the handshake is successful

#define TCP_TIMEWAIT_LEN (60*HZ) /* how long to wait to destroy TIME-WAIT state, about 60 seconds */
Copy the code