“This article has participated in the call for good writing activities, click to view: the back end, the big front end double track submission, 20,000 yuan prize pool waiting for you to challenge!”

TCP is like an old driver, in addition to buying tickets to get on the bus (three handshakes), and load (sliding window), this car in the world of the Internet repeated transport, when too many passengers, the car will certainly not fit, and inform the passengers next time I have a seat you come up. The same is true of TCP on the Internet. When the network transmission traffic is too large, it is easy to cause the receiving party to fail to process it, and the request backlog is easy to result. Then how does TCP solve the problem? Today we will discuss TCP flow control means sliding window.

I’m going to use an example here to make it easier to understand.

Let’s say A sends data to B. When the connection is established, B tells A: “My receive window RWND = 400” (where RWND stands for Receiver window). This means that the sending window of sender A cannot exceed the value of the receiving window given by receiver B, that is, 400 bytes. Note here that TCP Windows are in bytes, not segments. Let each packet segment be 100 bytes long and the initial sequence number of the data packet segment be set to 1 (see seq = 1 above the first arrow in the figure). In this article, A represents the sender and B represents the message receiver.

Host B of the receiver performs three flow controls. The first time the window is reduced to RWND =300, the second time to RWND = 100, and finally to RWND = 0, that is, the sender is no longer allowed to send data. Note that ACK = 1 is set for all three segments sent from B to A. The ACK number field is meaningful only when ACK = 1.

To sum up, the sender can only send the packet size specified by the receiver. If the packet size exceeds the size specified by the receiver, the sender stops sending messages.

We’re done with the sliding window process, but we’re not done with the problem.

1. If the packet sent by the sender is lost, for example, seQ =201 in the figure above, what can I do?

2. After B sends 0 window (RWND =0) to A, B’s receive cache has some storage space, and B sends A packet segment with RWND = 400 to A, but the request is lost. Does A still think that B is 0 window and waits for B?

Let’s go over the questions again

When user A sends A message to user B, the message of user A is lost, but the subsequent message is not affected. As long as USER A reconnects to user B, the message is sent again. Note, however, that a resend request cannot send new data.

When B send A side window value is missing, the continuous counter of TCP is played A role, when A client receives the notification window 0, continuous counter will start, if continue to counter set timeout has arrived, will send A 0 to B A window detection message, at this point B can confirmation window value, if the window still is zero, The party receiving the segment resets the duration timer. If the window is not zero, the deadlock can be broken.

In the second part, sliding window controls the size of transmission flow by window value; Using the retransmission mechanism to solve the sending end message loss; Continuous counter and probe message are used to solve the infinite waiting situation caused by the loss of window value sent by the receiver.

Let’s use a common example to further understand: my car load is only 200 (TCP window value), every time it is full, passengers are forbidden to get on the bus (sending end is blocked), when some people get off (TCP receive cache has some space), passengers can continue to get on the bus.

Read here, is not another small knowledge point with the interviewer brag. Brave Niuniu forward!!