The TCP/IP technology, considered one of the great inventions of the Internet era, has profoundly impacted today’s world. After nearly a month of study and exploration, I have a basic understanding of TCP/IP. Since TCP/IP operates in kernel mode within the OS, many details are not perceptible to users, leading to some confusion about TCP/IP. I have organized and refined my understanding of several points after consulting various books and blogs.
Confusion 1 — About Congestion
Confusion 1: Whether in the slow start or congestion avoidance phase, the congestion window is always increasing. Theoretically, it must eventually hit a congestion point; why is it that we usually do not feel congestion?
After reviewing many books and literature, here are some possible answers:
-
1. The maximum setting for the receive window in the OS has remained unchanged for many years. For example, in Windows, without enabling the “TCP Window Option,” the maximum receive window is only 64KB. However, with advancements in networking, many environments have congestion points far above 64KB, meaning the sending window may never hit the congestion point.
-
2. Many application scenarios involve interactive small data exchanges, such as chatting, which do not have the potential for congestion.
-
3. Some applications use synchronous methods for data transmission, which may require a very small window (for example, NFS write operations using synchronous methods wait for a reply after sending each write request, and a write request may only be 4KB).
-
4. Even if congestion occurs occasionally, the duration is often too short to be noticeable unless packet capture is performed to observe packet exchange details.
Confusion 2 — About Timeout Retransmission
Confusion 2: There is controversy regarding the ssthresh setting after a timeout retransmission.
-
1. Richard Stevens in “TCP/IP Illustrated” defines the critical window value as half of the sending window at the time of the last congestion.
-
2. RFC5681 suggests it should be half of the amount of unacknowledged data at the time of congestion (also known as Flight Size), and not less than 2MSS.
-
3. The Westwood/Westwood+ algorithm believes that it first calculates how many packets have been delivered to the receiver (this can be estimated based on the ACKs received), thus accurately estimating the bandwidth at the time of congestion, and then confirming the new congestion window based on the bandwidth.
-
4. The Vegas algorithm introduces a completely new concept, discarding the previous practice of adjusting the congestion window only after packet loss. It adjusts the sending rate by monitoring network conditions to achieve “true congestion avoidance.” When the network is good, RTT is stable, and the congestion window can be increased; when the network is busy, RTT increases, and the congestion window should be decreased.
-
5. The Compound algorithm maintains two congestion windows simultaneously, one similar to Vegas and the other similar to RFC5681, with the effective window being the sum of both (defaulted off in Win7).
-
6. The BIC and CUBIC algorithms are adopted in Linux 2.6.18 and 2.6.19 respectively and are still under research.
Key Summaries about TCP/IP:
-
(1) When there is no congestion, the larger the sending window, the better the performance. Therefore, in the absence of bandwidth limitations, the receive window should be increased as much as possible, such as enabling the Scale Option.
-
(2) If congestion occurs frequently, limiting the sending window can actually improve performance, as even a one-in-ten-thousand retransmission can significantly impact performance. Many OSs can reduce the sending window by limiting the receive window.
-
(3) Timeout retransmissions have the greatest impact on performance, as no data is transmitted during the RTO period, and Cwnd is set to 1 MSS; thus, it should be avoided as much as possible.
-
(4) Fast retransmissions have a smaller impact on performance since there is no waiting time, and Cwnd reduction is not significant.
-
(5) SACK and New Reno are beneficial in increasing retransmission efficiency and enhancing transmission performance.
-
(6) Packet loss has a more severe impact on small files than on large files. The underlying reason is that reading and writing a small file requires very few packets; thus, during packet loss, it often does not accumulate three Dup ACKs and must wait for a timeout retransmission, while large files have a greater chance of triggering fast retransmissions.
Author: hansonwang99 Link: https://www.jianshu.com/p/c35d50747ee2
Previous Highlights
A Look at the Evolution of Medium and Large Website Architecture from an Operations Perspective
Insights: How to Build an Operations Automation Platform
34 Essential Technical Knowledge Maps No IT Architect Should Miss
The “36 Strategies of Operations”: A Must-Have Guide for Operations Survival [Collector’s Edition]
The Upgrade Path for Senior Operations Engineers
Linux Non-Interactive Login to Remote Server and Execute Commands
A Brief Discussion on MySQL Database Optimization from an Operations Perspective
14 Mind Maps for Learning Python
Turning 30! Still confused, what should we do?
