Finally came to the TCP sliding window, originally calculated in section 2 on sliding Windows, but every time the plan can not catch up with the change, push and push, so came to section 5, but it is not too late, understand TCP/IP is still very useful.

5.1 delay ACK

Delayed ACK is a key aspect of TCP, but we’ll start with interactive communication.

5.1.1 Interactive communication

An “interactive “TCP connection is one that requires the transfer of user input information, such as keystrokes, short messages, joystick or mouse actions, between the client and the server. These packets are relatively small, and if each packet is not small enough to be transmitted as a single packet, then the transport protocol is expensive because each switching packet contains fewer payload bytes. Conversely, a larger packet segment does not cause a larger delay. Negative impact on delay-sensitive applications such as online games, collaboration tools, etc. So you need to find a middle ground,

Interactive communication is simple: the client takes user input and passes it to the server. The server parses the command and returns it to the client. It’s kind of like one request, one response.

But to my surprise, each interactive key usually generates a separate packet. That is, each keystroke is transmitted independently (one character at a time instead of one line at a time, which, to be honest, I didn’t read in the TCP detail, and I was also puzzled by the design).

When communicating with the server using SSH, the server needs to echo the input characters. So the process should look something like this:Would it be more efficient to combine data byte acknowledgement and data byte echo? This method is called delayed acknowledgement.

5.1.2 Delay confirmation

In many cases, TCP does not return an ACK for every incoming packet. This can be done using TCP’s cumulative ACK field. Cumulative acknowledgment allows TCP to delay sending ACK s for a period of time so that ACK s can be sent together with data that needs to be sent in the same direction. The TCP ACK delay must be less than 500ms. In practice, the maximum delay is 200ms.

The delayed ACK method can reduce the number of ACK transmission and reduce the network load to a certain extent.

Usage: TCP usually uses delayed ACK in some cases, but the delay is not very long. In the transmission of large data packets, congestion control and delay ACK are used. In small packet transmission, such as interactive applications, additional algorithms are required. (This is Nagle’s algorithm.)

5.1.3 Nagle algorithm

In SSH connections, a single keystroke usually causes data flows to be transmitted. These packets contain less data but need to carry the entire TCP/ IP header, resulting in high network transmission costs. So John proposed a simple and effective solution, which is now known as Nagle algorithm. Now let’s talk about what this algorithm means;

  • When a TCP connection has ongoing data (that is, sent but still acknowledged data), small segments (less than SMSS in length) cannot be sent until all retransmitted data has received an ACK
  • After receiving an ACK, TCP needs to collect the small data and send it into a packet segment.

Here’s an example:First observe the disabled Nagle algorithm: When Nagle is disabled, each character is sent separately, so we see three separate packets. When the server replies with ack, there is packet loss. If the client does not receive ACK2, the server retransmits an ACK2. The client responds with ack6, indicating that all packets before 6 have been received, as mentioned in the sliding window.

And then the second key is also three characters, so I don’t have to say it, it’s the same thing.

Through this example, we obviously feel that there are too many small packets, which is a waste of network resources, so we put forward the Nagle algorithm.

Let’s see what happens when Nagle’s algorithm is enabled: This is the process of starting Nagle algorithm, is there no packet in the middle of the existence of communication is also simple.

But this poses a problem: Have you noticed that every time after sending a request packet, the ACK length of reply is about 200ms? This is determined by delayed ACK. After receiving a request packet, the server will start a timer and wait for 200ms. But the client is using Nagle’s algorithm, and it waits for an ACK to send the request again. There is a deadlock, but the deadlock is not permanent, until the delayed ACK times out, the client sends an ACK, and the client can send the request again. This is also when you look at the graph and see that a request is always waiting about 200ms for a response.

Conclusion: As you can see from the previous examples, there are situations in which Nagle’s algorithm does not work.

These typically include applications that require as little delay as possible, such as remote control where mouse or key actions need to be delivered in time to get feedback on fast keys. There are also multiplayer online games where the character’s actions need to be delivered in time to ensure that they don’t interfere with the game’s progress.

Disabling Nagle is also easy. You can set the TCP_NODELAY option.

5.2 Sliding Windows

TCP is transmission control protocol, socket: streaming socket, sequential. Our application layer is to use socket to receive, then we receive the data how to ensure the sequence? We need to know that all kinds of situations may occur in network transmission. If the previous packet chooses a routing path, the later packet may choose another route, which may cause the later packet to be larger than the previous one.

So the TCP stack uses a sliding window mechanism to ensure that data is received sequentially.

5.2.1 Sending Window

Each end of the TCP connection sends and receives data. The amount of data sent and received by a connection is maintained through a set of window structures. Both ends of each TCP active connection maintain a send window structure and a receive window structure.

Let’s look at the structure of the send window:Send window has four parts, the first part has been sent and has confirmed that the receiver has to return to an ACK, the second part has been sent but unconfirmed, this part may be in transit, may also have been received, but since there is no time to delay ACK, so it has not been confirmed, the third part is about to send, will send the data, The second and third parts are notified by the receiver of the window called the offer window, is after receiving 3 bytes, reply ack, along with a 6 byte size window, in the previous TCP introduction of this article, has introduced the field of the window. (Because the window byte is 4 bytes, up to 65535, there is a window factor in the option byte, which extends the window size). The last part is not able to send, the receiver is relying on this window to control the rate of the sender, that is, to control how many bytes can be sent, the following cannot be sent, until the received but not determined data, and after the ACK, the sender window continues to move to the right. So this is called a sliding window.

Note: TCP does not support left-shifting of the window’s right boundary.

Each TCP packet segment contains the ACK number and window notification information. The TCP sender can adjust the window structure accordingly. The left edge of the window cannot be moved left because it controls the acknowledged ACK number, which is cumulative and cannot be returned. When the resulting ACK number increases while the window size remains the same (as is usually the case). Let’s say the window slides forward. If the window decreases with the increase of ACK number, the left and right boundary distance decreases. When the left and right boundaries are equal, it is called ** “zero window” **. The sending end cannot send new data. In this case, the TCP sender starts to probe the peer window to enlarge the providing window.

5.2.2 Receiving Window

The receiver also maintains a window structure, but it is simpler than the sender window.The receiving window consists of three parts, the first part is the received and confirmed data, and the second part is the data that will be saved after receiving. The window can ensure the correctness of the received data, especially to avoid storing duplicate received and confirmed data. You can also avoid storing data that should not be received (beyond the bounds of the sender’s right window). The third part is data that cannot be received.

Note: Due to TCP’s cumulative ACK structure, data is not discarded and the window slides forward only when the data sequence number is equal to the left boundary. With the SACK option, other segments within the window can also be received for confirmation, but the window can only move forward if serial number data equal to the left boundary is received.

5.2.3 Zero Windows with TCP persistence timers

As we saw earlier, TCP implements traffic control through the notification window at the receiving end. The notification window indicates the amount of data the receiver can receive. When the window value is 0, the sender is effectively prevented from sending until the window size returns to a non-zero value.

When the receiver retrieves free space, it sends a window update to the sender, telling the sender that it is ready to continue sending data, but such a window update is only a pure ACK and contains no data, so if there is a loss, no retransmission is sent. In this case, both the sending and receiving ends are in a wait state, resulting in a deadlock.

To prevent this deadlock, the sender uses a persistent timer to intermittently query the receiver to see if its window has grown. A persistent timer triggers the transmission of window probes, forcing the receiver to return an ACK containing window information, which is then sent at exponential intervals.

5.2.4 Confused window syndrome

Tcp-ip: Silly Window Syndrome

Here is a copy of the reason: this problem can be attributed to the packet problem, which is caused by the inconsistent processing between the sender and receiver, resulting in a lot of packets on the network. Measures to avoid excessive packets on the network have been introduced before, such as Nagle algorithm. With sliding Windows, this silly situation can also occur if the rates of the sender and receiver are very different: the sender sends data with a large header that carries very little data.

For the receiver, if the receiving slowly, receive a byte, or a few at a time, this time the receiver buffer are soon fill up, then the window notice to 0 bytes, the sender to stop sending this time, the application was taken up after 1 byte, issue a notice for 1 byte, window after the sender receives the notice, issued a byte of data, This cycle would be very inefficient.

At the same time, if the sender program sends one byte at a time, although the window is large enough, the transmission is still a byte by byte transmission, which is very inefficient

Solution: Receiver:

  • Small window values should not be advertised. (A window larger than the current window must not be advertised until the window has been expanded to a full-length MSS segment or one pass in the receiver’s cache space).
  • Delayed ACK, and cumulative ACK.

The sender:

  • Small packets should not be sent, and the Nagle algorithm controls when to send them.

To avoid SWS problems, the packet segment can be transmitted only when the following conditions are met.

  • Full-length (sending MSS bytes) packet segments can be sent
  • Data length ≥ half of the maximum window value advertised by the receiver can be sent
  • An ACK is not currently expected (needs to be reissued)
  • Disable the Nagle algorithm

The current TCP algorithm in the Linux kernel supports window automatic tuning, and will be analyzed later.