Understanding how TCP sliding Windows work is crucial to understanding the rest of TCP.
Compared to UDP, a simpler transport-layer protocol, TCP provides quality assurance over transmitted data.
In terms of reliability, TCP ensures that transmitted data is not lost, repeated, or out of order.
In addition, TCP provides traffic control to control the data transmission speed and prevent the buffer overflow of the fast host from the slow host.
Starting with unreliable protocols, let’s look at how TCP’s flow-oriented sliding window mechanism evolved.
Unreliable agreements
For unreliable protocols (such as IP and UDP), data may reach its destination or be lost after being sent.
If there is no mechanism to provide message feedback, the sender will not know whether the data has been successfully delivered to the destination, and therefore will not be able to retransmit the lost data.
There is no message feedback mechanism, which is one of the main reasons for unreliable transmission and no flow control.
Supports the confirmation mechanism for retransmission
In order to carry out reliable data transmission on the basis of an unreliable protocol, the message feedback mechanism is introduced.
Message feedback
The sender sends a message, and when the receiver receives the data, it returns a successful message to the sender.
The simple implementation process is as follows:
- Host A sends A message to host B.
- After receiving the message, host B sends an acknowledgement message to inform host A that the message has been successfully received.
- After receiving an acknowledgement message from HOST B, host A knows that the message is successfully sent.
But there are two problems with this simple mechanism:
- Since the IP protocol is unreliable, messages may not actually reach their destination. In this case, host A will be waiting for the message to be acknowledged and may never receive it.
- On the other hand, host B may return an acknowledgement message after receiving the message from HOST A, but the message is accidentally lost.
In both cases, host A may be waiting for A confirmation message, but it never arrives.
Timeout retransmission
To solve this problem, when host A sends A message, A timer can be started simultaneously. The timer should be long enough for the message to reach host B and for the confirmation message to be returned to Host A.
If the timer times out before the acknowledgement message reaches host A. Host A then assumes that it encountered A problem in sending the message (perhaps it was lost, or the packet was delayed due to network congestion) and retransmits the message.
This Acknowledgment mechanism is called PAR, Positive Acknowledgment with Retransmission because it includes both Acknowledgment Acknowledgment that the message has been received and Retransmission of the message after a timeout has occurred.
The PAR-based mechanism provides basic reliability for data transmission.
One disadvantage of the PAR mechanism, however, is that only one message can be unacknowledged at any time. This makes the system very slow because subsequent messages have to wait for the previous message to be confirmed.
Message identification and sending restrictions
The PAR mechanism is best suited for protocols that transfer a small amount of data or interact infrequently. Because PAR transport is inefficient, it is also not suitable for protocols such as TCP.
In order to solve the problem of low transmission efficiency, message identification is introduced.
The message identifier
When a sender sends a message, add a unique identifier to the message. After receiving a message, the recipient returns an acknowledgement message with the message identifier.
This allows the sender to use different identifiers for different messages. The sender can send multiple messages at the same time. After receiving an acknowledgement message, the sender only needs to confirm the corresponding message based on the message identifier.
The above, only from the sender’s point of view, solves the problem of the sender’s sending rate (only one message can be unacknowledged at any time).
Sending limit
Another way to look at it is to send a message, the recipient processes it, returns a confirmation message, and waits for the next message. This process, for the recipient, is no problem.
With the introduction of message identification, senders can send multiple messages at the same time. But if you send it too fast, the recipient may be overwhelmed.
Therefore, for the receiver, it is necessary to ensure that it can normally receive and process data, through a mechanism to inform the sender not to send too fast, send data as far as possible according to its own processing capacity.
It is easy to think of passing the sender’s send restriction information along when the receiver returns an acknowledgement message.
After receiving the send limit field in the confirmation message, the sender can control its own send rate according to the requirements of the receiver.
With this sending limit, the receiver can adjust the sending rate and optimize the sending performance by dynamic feedback according to its actual load.
With the addition of message identification and send restrictions, you can think of it as an enhanced version of the PAR mechanism.
For data transfer, reliability, efficiency, and basic data flow control can now be provided.
TCP flow oriented sliding window validation
With the addition of message identification and send restrictions, the entire message sending and confirmation process has been improved.
But from the point of view of “data” being transferred, everything we’ve talked about is really message oriented. That is, both send and acknowledge are on a message basis.
In fact, TCP is byte stream oriented and has no concept of message itself. The data transmitted by TCP is usually called a packet segment. How to identify and assemble a complete message is the job of the application layer.
Because of this, TCP processes data streams in bytes. If you want to identify TCP transmission data, you need one byte for an identity.
As a result, TCP can only send one byte of data at a time, and then only acknowledge one byte of data at a time, which is obviously unreasonable. It wastes bandwidth and reduces transmission efficiency.
TCP’s designers didn’t do that. Instead, they divided the data into segments that could be sent one at a time.
For each piece of data, use a serial number to identify it. Each time you validate data, you validate a piece of data, not a byte.
In fact, the serial number is the offset of the data byte in the packet segment, indicating the position of the data byte.
TCP buffer
Imagine A scenario where host A and host B establish A new connection:
- Host A has A large byte stream that needs to be transmitted, but host B cannot receive it all.
- Therefore, host B limits the number of bytes that can be transmitted by host A until the sent bytes are acknowledged.
- Host B allows host A to send more bytes.
So, each host needs to keep track of which bytes have been sent, which bytes have not been sent, and which bytes have been confirmed. This process is very similar to the message-per-send restriction mechanism above.
To this end, TCP introduces the concept of a buffer, which divides the sender’s buffer into four parts.
Sender’s buffer
As shown in the figure, the sender’s buffer is divided into four sections, as described below.
Part 1: bytes sent and acknowledged
(Bytes Sent And Acknowledged)
Corresponding to the Category #1 section of the figure, bytes 1 through 31 total.
Part 2: bytes sent but not acknowledged
(Bytes Sent But Not Yet Acknowledged)
Corresponding to the Category #2 section in the figure, bytes 32 through 45 are 14 bytes.
Part three: bytes that have not been sent but can be sent immediately
(Bytes Not Yet Sent For Which Recipient Is Ready)
Corresponding to the Category #3 section in the figure, bytes 46 through 51 are 6 bytes.
This represents the number of bytes that the sender can send and the number of bytes that the receiver can receive.
Part 4: Bytes that have not been sent and cannot be sent
(Bytes Not Yet Sent For Which Recipient Is Not Ready)
Corresponding to the Category #4 section in the figure, bytes 52 through 95 are 44 bytes.
This part of the byte, has exceeded the maximum window size that the receiver can receive, so cannot send.
Send Window
The black box represents a Send Window, often referred to simply as a Window.
The send window consists of two parts, corresponding to the second part of the send buffer (Category #2, in the gray box) and the third part (Category #3, in the red box).
As shown in the figure, the size of the send window is 20 bytes, the second and third parts are 14 bytes and 6 bytes respectively.
The left edge of the window is the first byte of the window (byte 32), and the right edge is the last byte of the window (byte 51).
The position of the window’s left edge determines the position of the window’s right edge. The left edge is the boundary between parts 1 and 2, and the right edge is the boundary between parts 3 and 4.
The size of the sending window determines the number of bytes a sender can send at the same time, that is, the number of bytes not acknowledged by the receiver.
Usable Window
Usable Window, which corresponds to the third part of the buffer (Category #3), which is the number of bytes that the sender can still send.
Changes to the window after sending the message
If some data is sent within the available window, the position of the send window and the size of the sections will change.
In the example above, the window available to the sender is 6 bytes. If the sender sends six bytes of data, the six bytes will become unacknowledged and be merged into the second part.
The second part has a range of 20 bytes from 32nd to 51st.
The available window, the third part of the window, becomes 0. This is often called a Zero Window.
The sender needs to wait until a new acknowledgment packet arrives before there is a window available to continue sending data.
Window changes after confirmation message
After the receiver successfully receives the data, a confirmation packet is returned to the sender. The acknowledgement packet contains an acknowledgement sequence number that notifies the sender that any data prior to this sequence number has been successfully received. The main function of confirming serial number is to solve the problem of not losing packets. Notifies the receiver of what data has been received.
Suppose that the sent unacknowledged portion (bytes 32 through 45) is transmitted by four TCP segments. The ranges of each packet segment are as follows:
- The first segment is 32 to 34 bytes.
- The second segment is 35 to 36 bytes.
- The third segment is 37 to 41 bytes.
- The fourth segment is 42 to 45 bytes.
Assume that the first, second, and fourth paragraphs have all been successfully sent to the receiver. However, the third paragraph had not yet arrived.
Then, the receiver will only be able to confirm that the first and second segments, bytes 32 through 36, have been received successfully. As for paragraph 4, it cannot be confirmed.
This is because TCP uses a cumulative acknowledgement mechanism, and the acknowledgement number indicates that all data up to this number (minus 1) has been successfully received.
Since the third paragraph has not been received by the recipient, it is not possible to go beyond this to confirm the fourth paragraph. Otherwise, the sender will assume that the third segment has been successfully received.
(In fact, TCP now supports the SACK mechanism, which, if enabled, allows acknowledgment of discontinuous blocks.)
After the sender receives the confirmation packet, the window moves 5 bytes to the right (confirmation 32 through 36 total 5 bytes). Bytes 32 to 36, however, will be merged into the first part and become sent and acknowledged.
As the 5 bytes are confirmed, a new 5 byte window (bytes 52 through 56) is created after the window is moved right.
This happens each time the sender receives an acknowledgement packet, and the window moves accordingly to resize the various parts of the buffer. (Sliding window is very vivid)
With the sliding window mechanism, a single confirmation number can be used to confirm an entire piece of data. This provides reliability support for TCP byte stream oriented services without the time-consuming validation of each sequence number.
Missing window changes after confirmation
After sending bytes 52 to 56, the sender stops sending data. Bytes in this range are still not returned because they are stuck on bytes 37 through 41.
Of course, like the PAR mechanism, TCP also supports timeout detection and retransmission of packets.
Therefore, after the timer expires, the sender resends the lost message segment and hopes to reach its destination this time.
Unfortunately, one drawback of TCP’s cumulative acknowledgment mechanism is that it does not independently acknowledge each segment of a message.
This means that TCP may repeat segments that have actually been received successfully by the recipient.
In our example, the fourth segment (bytes 42 through 45) has been received successfully. However, as long as the third paragraph is not confirmed, the fourth paragraph will also be retransmitted when the timeout expires.
(after)
Illustration: pixabay.com
reference
www.tcpipguide.com/free/t_TCPS…
TCP/IP Details Volume 1: Protocols
Interesting Talk Network Protocol
Personal public account
For more articles, please pay attention to the public number: binary road
