The layered model of TCP/IP has always been abstract, so I did not understand the SYN and ACK in TCP three-way handshake, disconnection, and various mechanisms to ensure THE stability and reliability of TCP interpenetrating in the transmission process, such as flow control mechanism – sliding window, congestion window; Retransmission mechanism -ARQ, SACK Therefore, this article focuses on opening the black box through a WireShark packet process and where we can optimize it.
Main reference: “UNIX network programming volume 1: Socket API”, Master Zhang’s gold digging booklet in-depth understanding of TCP protocol: from principle to practice, “Computer Network – Xie Xiren” Java uses Socket encapsulation of all the following details, can be compared with this article read: In – depth analysis of Java Socket principle blocking sockets
Visit Baidu:
Three handshakes to establish a connection:
TCP is a full-duplex, connection-oriented, and byte stream protocol. Therefore, to use TCP communication, a bidirectional connection must be established and packets must be captured using WireShark. The result is as follows:
Big picture of three handshakes
First of all, we need to clarify that the purpose of the three-way handshake is to establish a connection. The connection is to establish reliable communication between the two parties, and in reliable communication, the sender needs to know whether it can now send the packet from where (ACK NUM and SEQ(ISN) control) and how long (sliding window, congestion window and MSS control) to the receiver. The three-way handshake is essentially the exchange of information necessary for those communications.
What are ACK and SYN?
SETThese flag bits are used to identify the properties of the current TCP packet.
Serial number and confirmation number and sliding window
The sequence number of each TCP connection is a randomly initiated 32 digit number that increases with the number of bytes sent (i.e., up to 4G, after which the sequence number increases again from 0).
As shown in the figure below, when a large packet of the application layer is fragmented into six small packets according to the Max segment size (MSS) of the transport layer, MSS increases from 0(relative) to 5MSS, and these six TCP packets appear in the following four states in the network:
The size of the sliding send Window shown in the figure above is 4MSS. This value is obtained in the TCP header by calculating the window size * window factor. This value dynamically changes with the WIN in the recipient’s ACK packet – in extreme network conditions it may change to 0-TCP Zero window. In this case, the sender will not continue to send packets to the receiver; But this raises the question of how the sender should know when to continue if the network improves. Should the sender initiate the inquiry or the receiver give the warning? The zero-window detection mechanism is designed in TCP. The sender sends inquiry packets in turn according to the exponential retreat time, mainly to obtain the network status of the receiver – whether the receiving window allows to continue sending.
Why do I need to add the sequence number field in the TCP header? As shown above
- Through the serial number, we can ensure that the receiver can restore the application layer packet according to the sequence specified by the sender through the serial number size.
- Based on the combination of sequence numbers and ACK NUM, we can provide a retransmission mechanism:
ARQ(Auto Repeat Quest)
For example, in ARQ automatic retransmission protocol based on this combination, when the ACK NUM transmitted by the receiver is always MSS, it indicates that the maximum sequence number continuously received by the receiver is MSS. When the timeout period of the packet expires, if the sender still does not receive the ACK of 2MSS, the sender needs to retransmit the packet later than MSS. Until the ACK NUM transmitted by the receiver changes to 3MSS;
From the aspect of response time: we can solve the delay problem of ARQ through fast retransmission. When the sender receives the same ACK value of the receiver, it does not need to wait for timeout to directly retransmit, thus reducing the network delay.
From the perspective of reducing network overhead: We notice that in the figure above, the receiver has actually received the packet of 2MSSS: 3MS-1, but the sender does not know whether the receiver has received the packet, which leads to the sender may send the packet of 2MSSS: 3MS-1 repeatedly. Therefore, we need to provide an additional optimization mechanism to provide the sender with more specific information about the packet received by the corresponding receiver than the maximum serial number received -SACK mechanism.
Selective ACK mechanism (SACK)
In the three-way handshake, SACK_PERM field is used to mark whether SACK is supported by both parties in connection construction. However, according to the three-way handshake packet caught by WireShark before, it can be seen that both parties in connection construction permit SACK.
As shown in the figure above, the SACK mechanism provides an additional 2MSS:3MSS message to the sender in the header of the TCP packet sent by the receiver, so the sender will not send 2MSS: 3MS-1 packets again knowing that the receiver did not receive a packet between MSS: 2MS-1.
However, the SACK mechanism also brings a large byte overhead, because the SACK mechanism requires to reflect the discontinuous packet status in the receiving window. As shown in the figure above, three serial numbers are stored, one of which is 32 bits 4 bytes, and three of which are 12 bytes. So you need to put this information into the extended space of the TCP header (the extended space of the TCP header is up to 40 bytes, so there is a limit to how much you can store (no more than 4 bytes because the TCP extended fields require additional description bytes).
WireShark packet analysis
First, send a SYN packet from 192.168.0.100:53754 (that is, the TCP header with the SYN flag Set) to Request baidu’s address 180.101.49.12:80, and inform Baidu server of the current client connection sequence number Seq(RAW): 4151837647, Sliding window size (WIN) is 64240, maximum transmission length (MSS) is 1460(MTU(1500)-20-20).
After receiving the message, the baidu server needs to tell the client that I have received the request (ACK) and inform the server of the current serial number (Seq) and the sliding window, MSS and other information used in transmission.
Finally the client sends an ACK to the server:
In this case, the ACK packet does not occupy the sequence number, because the TCP packet that occupies the sequence number mainly needs to be acknowledged by the recipient. In this case, the ACK packet does not need to be acknowledged by the recipient. Therefore, the NEXT_SEQ is the same as the current SEQ.
In this case, the TCP state of the client is ESTABLISHED and the TCP connection is ESTABLISHED with the server. When the server receives an ACK packet for ACK + SYN from the client, the TCP state of the server changes from WAIT_REVE to ESTABLISHED.
HTTP Request interaction
HTTP request packets are sent after the connection is established
After the link is established, we send www.baidu.com an HTTP request with the request type of GET, the request address of /, and the HTTP version of 1.1 through CMD curl. The payload of the entire HTTP packet as a TCP packet is 77 bytes.
PS: We noticed that WIN value changed from 64240 at the beginning to 131584(514*256, window size in TCP header * expansion factor), which changed to 2.04 times of last time. The size of the sliding window in the sender’s message indicates the number of bytes that the sender can receive from the receiver, while the size of WIN expanded by 2 times in the early stage. This is a slow start strategy for congestion control to avoid network crash caused by direct large-byte network switching in poor network environment.
The ACK bit is set because: According to the TCP protocol, after a connection is established, the ACK bit in all sent TCP packets is set.
The receiver processes the HTTP request and returns a response packet
In this case, the HTTP response packet is long, and the recipient uses MSS(1452) fragments TCP packets at the transport layer.
Here we parse the HTTP packet body as an HTML document – baidu page.
Reply to an ACK acknowledgement packet
Under normal circumstances, after receiving the response packet, the sender returns the corresponding ACK to the receiver to complete the data exchange:
The heartbeat packets
15s.
Close the connection (four waves)
When the local host has been didn’t respond to a heartbeat packets, baidu server selection after the second heartbeat packets are not reply by four wave disconnected, but our local host did not reply ACK, baidu server then resend the 5 times after we still have not received our reply, then sent via active RST packet end off this connection.
Of course, the normal four-wave process is shown below:
Conclusion:
At this point, a complete interaction process between our local host and Baidu server has ended, including three handshakes, information exchange, heartbeat mechanism and disconnection, but many details are not described.