This is the 15th day of my participation in Gwen Challenge
TCP window
If you are an industrious Courier, you need to send 100 parcels to a company, how to deliver scientifically?
The easiest way is to deliver one at a time for 100 trips. Of course, this is also the slowest way, because the more round trips you make, the longer it takes. Except for couriers who need to lose weight, this is not an option for most people.
The quickest way would be to deliver 100 at a time, so you only have to make one trip. Unfortunately, the reality is not so beautiful, there are often various constraints: the company’s small front desk only has room for 20 packages, they have to wait for the completion of the delivery; To add to the frustration, the electric car can only hold 10 packages. Combining these two factors, it is not difficult to conclude that the capacity of the battery car is the bottleneck of efficiency, while the space of the front desk does not constitute an impact.
The strategy of Courier delivery is very simple and almost everyone can understand it, while TCP’s strategy of transferring large chunks of data is less well understood. In fact, the principle is similar.
TCP obviously doesn’t use a battery car to deliver packets, but it does have the need for “round trips.” After sending the packet, we do not know whether the other party can receive it or not, so we have to wait until the packet arrives, which takes a round trip time. If each packet is stopped for confirmation, only one packet can be sent per round trip, which is inefficient. The quickest way would be to send out all the bags at one go and confirm them together. However, there are some practical limitations: ** The receiver’s cache (receive window) ** may not be able to accept that much data at once; The network bandwidth may not be large enough. Sending too many packets at a time may cause packet loss.
Therefore, the sender needs to know which of the two constraints – the receiving window or the network – is more stringent, and then sends as many packets as possible within its limits. This amount of data that can be sent in one go is known as the TCP**** send window.
How much does the send window affect performance?
A picture is worth a thousand words, and the following figure shows the difference between one MSS (the maximum amount of data that can be carried per TCP packet) and two MSS in the sending window. In the same round trip time, there is twice as much data on the right as on the left. In the real world, the send window can often reach tens of ****MSS
If the receiver can’t process the data fast enough to receive it, the cache is full, resulting in a receive window of ****0.
What does the send window have to do with MSS?
The send window determines how many bytes can be sent at a time, and the MSS determines how many packets these bytes should be sent.
For example, in the case of a 16000-byte send window, if the MSS is 1000 bytes, 16000/1000****=****16 packets need to be sent; If MSS is 8000, the number of packets to be sent is **16000/8000****=**2.
If the sender sends n packets in one window, does it receive n acknowledgement packets?
Not necessarily. The confirmation package is usually less. Because TCP can accumulate acknowledgements, when multiple packets are received, only the last one needs to be acknowledged.
I often hear the term “TCP Window Scale”. How does it relate to the receive Window?
When TCP was first invented, the world’s network bandwidth was small, so the maximum receive window was defined as 65535 bytes. With the hardware revolution, 65,535 bytes has become a performance bottleneck, how to scale? The TCP header only leaves 16 bits for the receive window value, which is definitely not able to break 65535.
RFC 1323 in 1992 proposed a solution, which is to inform the other party of their Window Scale information during the three handshakes. Since the Window Scale is placed in Options outside the TCP header, there is no need to change the design of the TCP header. The Window Scale declares a Shift count, which we use as an exponent of 2, multiplied by the receive Window defined in the TCP header to get the actual TCP receive Window.
The following attribute represents the received Window =Window X Winsow size scaling factor (304X128=38912), which wireshark has helped us calculate
TCP retransmission
The sender’s send window is influenced by the receiver’s receive window and the network, where more restrictive factors play a decisive role. The effect of the receive window is as simple as notifying the sender with “Win**=**” in the packet. And the way the network affects is very complex.
The network is able to limit the sending window because it becomes congested when it receives too much data at once. The result of congestion is packet loss, which the sender fears the most. The amount of data that causes network congestion is called the congestion point, and the sender of course wants to keep the sending window below the congestion point to avoid congestion. The problem is that even network devices do not know their congestion points, and even if they do, they cannot notify the sender. How can the sender avoid touching the congestion point in this case?
Can the maximum amount of traffic obtained be defined as the congestion point of the connection by increasing the amount of traffic one by one until the network becomes congested?
It’s a good idea, but it’s not that simple. The Internet is like a road: sometimes it’s congested, other times it’s empty (except in Beijing). Therefore, the congestion point is a dynamic value that changes at any time, and the current congestion point tested cannot represent the future.
Isn’t there a perfect solution? Unfortunately, not really. In the decades since the web was born, there have been countless brilliant engineers, but none of them have been able to solve this problem. Fortunately, it has taken generations to come up with a strategy that works best. The strategy is to maintain a virtual congestion window at the sender and use various algorithms to make it as close to the real congestion point as possible. The limitation of sending window in network is realized by blocking window. Let’s take a look at how to maintain the congestion window.
1. When the connection is established, the sender knows nothing about the network status. Congestion can occur if you send too much data at once, so the sender sets the initial value of the congestion window to be very small. The RFC recommends 2****, 3****, or 4 MSS, depending on the size of the MSS.
2. If the sent packets are confirmed, the congestion point has not been reached, and the congestion window can be enlarged. Since the probability of congestion is low at this stage, growth should be faster. The RFC suggested algorithm is to increase the congestion window by N MSs for every n acknowledgements received. For example, after sending two packets and receiving two confirmations, the congestion window increases to 2+2=4, followed by 4+4=8, 8+8=16… This process grows quickly, but is called a slow start because of its low base and slow transmission speed.
3. After the slow start process lasts for a period of time, the congestion window reaches a large value. At this time, the transmission speed is relatively fast, and the probability of touching the congestion point is also large, so we can not continue to double the slow start algorithm, but a little slower. The RFC suggested algorithm is to add 1 MSS per round trip time. For example, after 16 MSS are sent and all confirmed, the congestion window is increased to **16+1****=17 MSS, and then 17+1****=**18,
This process is called congestion avoidance. The critical window value for transitioning from slow start to congestion avoidance is tricky. If congestion has occurred before, use that congestion point as a reference point. A relatively large value can be taken if there is never congestion, such as equal to the maximum receive window. The whole process can be graphically represented.
In both slow start and congestion avoidance phases, the congestion window is gradually increasing and the congestion point will theoretically be reached after a certain period of time. So why don’t we feel congestion on a regular basis? There are many reasons, as follows.
- The maximum setting of the receive window in the operating system has not changed for many years. For example, in Windows, the maximum receive window is only 64KB without the “TCP Window Scale option” enabled. In recent years, the network has made great progress, and the congestion point in many environments is far above 64KB****. That means the send window is limited to 64KB and never hits the congestion point.
- Many applications are interactive and small data, such as network chat, so there is no potential for congestion.
- If the data is transferred synchronously, the window may be very small. For example, in a synchronous NFS write operation, each write request is stopped and waits for a reply, and a write request may be only 4KB
- Even if congestion does occur occasionally, it is not long enough to be felt unless network packets are captured for data analysis and comparison.
What happens after congestion? For the sender, it means that the packet sent is not confirmed as usual. However, the failure to receive confirmation could also be due to network latency, so the sender decided to wait a short time before judging. If the packet is not received, it is assumed that the packet has been lost and can only be retransmitted. This process is called timeout retransmission. As shown in the figure, the time between sending the original packet and retransmitting it is called RTO
The following figure shows how the congestion window changes when timeout retransmission occurs.
As you can easily imagine, timeout retransmission has a serious impact on transport performance. One reason is that data cannot be transmitted during the RTO phase, which is equivalent to wasting a period of time. The second reason is the sharp reduction of the congestion window, which is equivalent to much slower transmission. In my experience, even 1/10,000 timed retransmissions have a significant impact on performance. How do we check for retransmissions in Wireshark? Click Analysis ****-> Expert Information. Retransmission in the Note is one.
Then you can filter out the original and retransmitted packets based on Sequence
Sometimes congestion is minimal, with only a small number of packets missing. There are also occasional factors, such as incorrect checksum codes, which may result in single packet loss. These two symptoms of packet loss are different from those of severe congestion because packets can arrive normally afterwards. When subsequent packets arrive at the receiver, the receiver will find that the Seq number is larger than expected, so it will Ack the expected Seq number every time it receives a packet to remind the sender of retransmission. When the sender receives three or more duplicate acknowledgements (dupacks), it realizes that the corresponding packet has been lost and immediately retransmits it. This process is called fast retransmission. It is fast because it does not wait for a period of time like timeout retransmission.
Here are some summary conclusions
- When there is no congestion, the larger the send window, the better the performance. Therefore, if bandwidth is not limited, the receiver window should be enlarged as much as possible, such as enabling Scale Option (refer to KB 224829 on Windows).
- If congestion occurs frequently, limiting the send window can actually improve performance, since even 1 in 10,000 retransmissions can have a significant impact on performance. On many operating systems, you can reduce the send window by limiting the receive window. On Windows, you can also refer to KB 224829
- Timed retransmission has the greatest performance impact because it does not transfer any data for a period of time (RTO), and the congestion window is set to 1 MSS, so try to avoid timed retransmission.
- Fast retransmission has less of a performance impact because it has no wait time and the congestion window does not decrease as much.
- SACK and NewReno improve retransmission efficiency and transmission performance.
- Packet loss affects very small files more severely than large files. Because the number of packets required to read and write a small file is very small, the number of Dup Acks is usually less than three when the packet is lost, and you have to wait for retransmission due to timeout. Large files are more likely to trigger fast retransmission.
Article compiled from Wireshark Network Analysis As Simple as that