The master will show you the basic TCP sliding window (1)

The master will show you the basic TCP sliding window (1)

What distinguishes TCP from UDP is the quality of data transmission. TCP tracks sent data. This data management protocol requires the following two key functions:

Reliability: ensures that the data reaches the destination. If it does not arrive, it can be found and re-transmitted.

Data Flow Control: manages the data transmission rate so that the receiving device is not overloaded.

To complete these tasks, the entire Protocol operation is performed around the Sliding Window validation mechanism. Therefore, we understand sliding windows, that is, TCP.

TCP stream-oriented Sliding Window validation mechanism:

TCP processes independent byte data as a stream. It is obviously not feasible to send one byte at a time and receive one confirmation. Even if overlapping transmission (that is, sending the next data without waiting for confirmation), the speed is still very slow.

As shown in the TCP Message validation mechanism, each message has an identification number, and each message can be independently identified. Therefore, multiple messages can be sent at the same time. Device B periodically sends A limit parameter to device A, which limits the maximum number of messages that device A can send at A time. Device B can adjust this parameter to control the data flow of device.

To increase the speed, TCP does not send data streams by byte but divides the data streams into segments. All the bytes in the clip are sent and received together, so they are also confirmed together. The validation mechanism does not use the message ID field, but uses the sequence number of the last byte in the fragment. Therefore, different bytes can be processed at a time, which is the sequence number in the segment.

Classification of TCP Data Streams

Assume that A new TCP connection is established between A and B. Device A needs to transmit A long string of data streams, but Device B cannot receive all data at A time. Therefore, it limits the number of bytes that device A sends to each segment until the number of bytes that have been sent in the segment is confirmed. Then, device A can send more bytes. Each device tracks sending, receiving, and confirming data.

If we create a "snapshot" for this process at any time point, we can divide the data in TCP buffer into the following four types and regard them as a timeline:

1. The earliest bytes in the confirmed data stream have been sent and confirmed. The data is from the perspective of the sending device. As shown in, 31 bytes have been sent and confirmed.

2. Bytes Sent but not confirmed. The sender does not consider the data to have been processed before confirmation. The 14 bytes shown in the figure are 2nd categories.

3. the receiver has not sent the data but the Ready device has not sent the data. However, the receiver confirms that it has sufficient space based on the last message about how many bytes the sender will send. The sender immediately tries to send the message ., The 3rd class has 6 bytes.

4. The receiver Not Ready is not allowed to send this part of data because the receiver is Not ready.

The recipient uses a similar mechanism to distinguish between received and confirmed data that has not been accepted but is ready for receiving and data that has not yet been received and is not yet ready for receiving. In fact, the sending and receiving sides maintain a set of independent variables to monitor the types of data streams sent and received.

Sequence Number settings and synchronization:

The sender and receiver must agree on the sequence number they will specify for the bytes in the data stream. This process is called synchronization and completed when a TCP connection is established. To simplify the assumption that the first byte sequence number is 1, the four types of bytes are as follows:

1. Confirmed bytes 1 to 31 have been sent.

2. Sent but unconfirmed bytes 32 to 45.

3. the receiver has not been sent, and the receiver has Ready bytes 46 to 51.

4. the receiver is Not Ready, and the bytes are 52 to 95.