Shulou(Shulou.com)06/01 Report--

Time to dust this place off and write an article about TCP. Today's topic is TCP's sliding window. Before I start, I want to mention a few common misconceptions about TCP.

Mistake 1: The last two packets in the TCP three-way handshake are both [ACK] packets.

Explanation: This statement is not bad, but it is not rigorous. First, the first packet is [SYN], and the SYN bit is in the TCP header flag field, see TCP header structure above. The second packet should be more accurately called a [SYN,ACK] packet because the SYN bit is set in addition to the ACK bit. The third packet is a pure ACK packet because only the ACK bit is set. So the process of the three-way handshake is:

Client----[SYN]------------>> Server

client server

There is a very classic ** called SYN Flood***, which is a DDOS** method in which the client sends multiple SYN packet requests but does not reply to the third ACK packet to occupy the limited resources of the server.

Myth 2: During TCP data transmission, the unit of sequence number increase is the number of packets.

Explanation: This is the most common mistake beginners make, because most teachers in order to facilitate the understanding of students, the beginning of the example sequence number is +1 to increase. It's not true. The unit of sequence number increment is the number of bytes of packet application layer data (also called Payload).

Take a chestnut:

Suppose a packet sequence number is 1000 and the Payload length is 500. Then the serial number of the next packet is 1500.

Myth 3: Sequence numbers grow for both sides of a TCP connection.

Explanation: For most applications (HTTP, Telnet), both parties have data transmission, so the serial number of both parties will increase, while for applications such as FTP, only one party is transmitting data (uploading or downloading) in the data channel, so the other party is only playing a simple confirmation role, in this case, the serial number of the other party will not increase.

Having said that, let's start talking about TCP's window mechanism, which is a key point to understand TCP protocol.

1. We all know that the difference between TCP and UDP is that TCP is based on connection (three-way handshake), and TCP data transmission is reliable, the so-called reliability is relying on sequence number and acknowledgement number mechanism to make TCP transmission process even if packet loss will be retransmitted.

2. However, TCP's acknowledgement mechanism also slows down the data transmission speed of both sides of the TCP connection, that is, one party needs to wait for the other party's acknowledgement before continuing to send subsequent data. This reflects the role of the window mechanism, the so-called window, that is, to make full use of the bandwidth and buffer of both sides. For example, instead of waiting for an acknowledgement from the other party, the sender can send multiple packets in succession to the other party, and the other party can temporarily store these data in a buffer and give an acknowledgement to the other party. In this way, the speed of data transmission can be greatly increased.

3. The problem with this is that once the receiver's buffer is full or about to be full, it will be overloaded, so this requires a real-time update mechanism of TCP window. For example, the receiver window size is set to 50000, that is, the sender can send 50000 bytes of data at a time without waiting for confirmation. Once the receiver realizes the overload situation, it can send a window update notification to tell the sender. The window size is now 30000, please reduce the number of bytes of data sent at once. In some extreme cases, the receiver's Buffer is completely full, and a ZeroWindowSize notification is sent, causing the sender to temporarily stop data transmission and wait for the next acknowledgement.

Let's see how the window features are reflected in the capture package:

The above figure shows the header information of an ACK packet captured by the packet capture tool. It can be seen that the windowsize value is the maximum value, because the maximum value of the 16-bit field is 65535. The bottom line in the red box may be confusing. Why is there a Calculated window size? Let's look at a TCP Window Size Scaling option.

1. Since it is an option, there is no doubt that it needs to be reflected in the Options field of the TCP header in the above figure.

2. Next, let's take a look at a screenshot of the bag:

In this picture, we can see that the value of Windows Size is 114, but the value of Calculated Windows Size is 14592.

3. In the TCP three-way handshake process, you can open the TCP option Window Size Scaling through the SYN packet. This option is designed because today's bandwidth has been greatly increased, and gigabit to the desktop is also a common thing. Therefore, the window size of 65535 length has become a little small. In order to break through this limit, there is the Window Size Scaling option. See the SYN packet screenshot below:

You can see that the value of this field is 7, which means that the value of Window Size is shifted to the left by seven bits, that is, multiplied by 128. Therefore, in the above figure, we see that the window size value is 114, but the real value selected is 14592(114*128).

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.