TCP/IP Learning Notes (11) – TCP Interactive and Block Data Streams

Currently, there are many network protocols built on the TCP protocol, such as telnet, ssh, ftp, http, etc. These protocols can be roughly divided into two categories based on data throughput:

(1) Interactive data types, such as telnet and ssh. These types of protocols usually only do small-scale data exchanges, such as pressing a key on the keyboard and echoing some text.

(2) Block data types, such as ftp. These types of protocols require TCP to carry data as much as possible, maximizing data throughput and improving efficiency. For these two situations, TCP provides two different strategies for data transmission.

TCP Interactive Data Stream

For applications with high interactivity requirements, TCP provides two strategies to improve sending efficiency and reduce network burden: (1) Piggybacked ACK. (2) Nagle’s algorithm (send as much data as possible at once). Typically, in cases of fast network speeds, such as using the lo interface for telnet communication, when a letter key is pressed and an echo is requested, the client and server will experience the process of sending key data -> server sends ACK for key data -> server sends echo data -> client sends ACK for echo data, where the data flow will be 40bit + 41bit + 41bit + 40bit = 162bit. If on a wide-area network, such small packet TCP traffic can cause a significant network burden.

Piggybacked ACK Sending Method

This strategy states that when a host receives a TCP datagram from a remote host, it typically does not immediately send an ACK datagram but waits for a short time. If during this time the host also has TCP datagrams to send to the remote host, it will “piggyback” this ACK datagram and send it together, integrating the originally two TCP datagrams into one. Generally, this time is 200ms. It can be clearly seen that this strategy can greatly improve the utilization of TCP datagrams.

Nagle’s Algorithm

Those who have used BBS should have felt that when posting in a slow network, sometimes after typing a string, after a while, the client suddenly echoes a lot of content, as if the data has suddenly come over. This is the effect of Nagle’s algorithm.

Nagle’s algorithm states that when host A sends a TCP datagram to host B and enters the state of waiting for host B’s ACK datagram, there can only be one TCP datagram in TCP’s output buffer, and this datagram continuously collects subsequent data, integrating it into a larger datagram. Once the ACK packet from host B arrives, it sends all this data out at once. Although this description is somewhat inaccurate, it is still vivid and easy to understand, and we can also appreciate the benefits of this strategy in reducing network burden.

When writing interface programs, you can close this algorithm using TCP_NODELAY. Additionally, this algorithm should be used based on the situation; for example, in the case of the TCP-based X Window protocol, if this algorithm is still used when processing mouse events, the “delay” can be very large.

TCP Block Data Stream

For protocols like FTP that have high requirements for data throughput, it will always hope to send as much data as possible to the other host each time, even if there is a bit of “delay”. TCP also provides a complete set of strategies to support such needs. In the TCP protocol, there are 16 bits representing the size of the “window”, which is the core of these strategies.

ACK Issues During Data Transmission

Before explaining the sliding window, we need to look at the ACK response strategy. Generally speaking, when the sender sends a TCP datagram, the receiver should send an ACK datagram in response. However, this is not the case; the sender will continuously send data to fill the receiver’s buffer, while the receiver only needs to send one ACK message to respond to all this data. This is the cumulative property of ACK, which greatly reduces the burden on both the sender and the receiver.

Sliding Window

The sliding window essentially describes the size of the receiver’s TCP datagram buffer, and the sender calculates how much data it can send based on this data. If the sender receives a TCP datagram from the receiver indicating that the window size is 0, the sender will stop sending data and wait until the receiver sends a datagram with a non-zero window size.

Regarding the sliding window protocol, three terms are introduced:

1. Window Contraction: This phenomenon occurs when the window moves from left to right, which happens when data is sent and confirmed.

2. Window Expansion: This phenomenon occurs when the right edge of the window moves to the right, which happens when the receiving end processes the data.

3. Window Shrinkage: This phenomenon occurs when the right edge of the window moves to the left, which is not common.

TCP uses this window to slowly move from the left side of the data to the right, sending out the data within the window range (but not all, only the data within the window can be sent). This is the significance of the window. The size of the window can be defined through the socket, and 4096 is not the ideal window size, while 16384 can greatly increase throughput.

Data Congestion

The strategies above work for transmission within a local area network, but may cause problems in a wide area network, with the biggest issue being the large amount of data congestion caused when there is a bottleneck during transmission (for example, having to pass through a slip low-speed link). To solve this problem, the TCP sender needs to confirm what the maximum throughput of the connection between the two parties is. This is known as the congestion window.

The principle of the congestion window is simple: the TCP sender first sends a datagram and then waits for a response from the other party. After receiving the response, it doubles the size of this window, then continuously sends two datagrams, and after receiving a response from the other party, it doubles the window again (initially it grows exponentially, and after a certain point, it shifts to linear growth, known as slow start), sending more datagrams until a timeout error occurs. In this way, the sender learns about the carrying capacity of the communication line between the two parties and determines the size of the congestion window, using this size to send data. It is very easy to observe this phenomenon; we usually see that the speed of downloading data gradually “picks up”.

The above is the general process of TCP data transmission. Although not very detailed, it is sufficient to describe the working principle of TCP, focusing on the principles of TCP flow control, sliding window, congestion window, and cumulative ACK confirmation.