An instance of TCP traffic control: unable to send data!

Simulate the test program, send data from the client to the server, and manually control the server to receive data. When the client sends a portion of the data, it cannot be sent again. At this time, the server starts to charge 1 K each time.
According to common sense, after the server collects 1 kb of data, the client should be able to send data again. However, it is found that the client still cannot send data until the server collects a certain amount of data, the client can continue sending.

The tcp packet capture is as follows:

11:42:40.217984 IP localhost.6379 > localhost.28944: . ack 65665 win 0 <nop,nop,timestamp 1816613366 1816613366>0x0000: 4500 0034 5e08 4000 4006 deb9 7f00 0001 E..4^.@.@.......0x0010: 7f00 0001 18eb 7110 7c79 0efb 7c5f 2ff1 ......q.|y..|_/.0x0020: 8010 0000 3a7f 0000 0101 080a 6c47 51f6 ....:.......lGQ.0x0030: 6c47 51f6 lGQ.11:42:40.425034 IP localhost.28944 > localhost.6379: . ack 1 win 257 <nop,nop,timestamp 1816613573 1816613366>0x0000: 4500 0034 7f94 4000 4006 bd2d 7f00 0001 E..4..@.@..-....0x0010: 7f00 0001 7110 18eb 7c5f 2ff0 7c79 0efb ....q...|_/.|y..0x0020: 8010 0101 38b0 0000 0101 080a 6c47 52c5 ....8.......lGR.0x0030: 6c47 51f6 lGQ.11:42:40.425047 IP localhost.6379 > localhost.28944: . ack 65665 win 0 <nop,nop,timestamp 1816613573 1816613366>0x0000: 4500 0034 5e09 4000 4006 deb8 7f00 0001 E..4^.@.@.......0x0010: 7f00 0001 18eb 7110 7c79 0efb 7c5f 2ff1 ......q.|y..|_/.0x0020: 8010 0000 39b0 0000 0101 080a 6c47 52c5 ....9.......lGR.0x0030: 6c47 51f6 lGQ.11:42:40.838967 IP localhost.28944 > localhost.6379: . ack 1 win 257 <nop,nop,timestamp 1816613987 1816613573>0x0000: 4500 0034 7f95 4000 4006 bd2c 7f00 0001 E..4..@.@..,....0x0010: 7f00 0001 7110 18eb 7c5f 2ff0 7c79 0efb ....q...|_/.|y..0x0020: 8010 0101 3643 0000 0101 080a 6c47 5463 ....6C......lGTc0x0030: 6c47 52c5 lGR.11:42:40.838983 IP localhost.6379 > localhost.28944: . ack 65665 win 0 <nop,nop,timestamp 1816613987 1816613366>0x0000: 4500 0034 5e0a 4000 4006 deb7 7f00 0001 E..4^.@.@.......0x0010: 7f00 0001 18eb 7110 7c79 0efb 7c5f 2ff1 ......q.|y..|_/.0x0020: 8010 0000 3812 0000 0101 080a 6c47 5463 ....8.......lGTc0x0030: 6c47 51f6 lGQ.11:42:41.666922 IP localhost.28944 > localhost.6379: . ack 1 win 257 <nop,nop,timestamp 1816614815 1816613987>0x0000: 4500 0034 7f96 4000 4006 bd2b 7f00 0001 E..4..@.@..+....0x0010: 7f00 0001 7110 18eb 7c5f 2ff0 7c79 0efb ....q...|_/.|y..0x0020: 8010 0101 3169 0000 0101 080a 6c47 579f ....1i......lGW.0x0030: 6c47 5463 lGTc11:42:41.666939 IP localhost.6379 > localhost.28944: . ack 65665 win 0 <nop,nop,timestamp 1816614815 1816613366>0x0000: 4500 0034 5e0b 4000 4006 deb6 7f00 0001 E..4^.@.@.......0x0010: 7f00 0001 18eb 7110 7c79 0efb 7c5f 2ff1 ......q.|y..|_/.0x0020: 8010 0000 34d6 0000 0101 080a 6c47 579f ....4.......lGW.0x0030: 6c47 51f6 lGQ.11:42:43.322908 IP localhost.28944 > localhost.6379: . ack 1 win 257 <nop,nop,timestamp 1816616471 1816614815>0x0000: 4500 0034 7f97 4000 4006 bd2a 7f00 0001 E..4..@.@..*....0x0010: 7f00 0001 7110 18eb 7c5f 2ff0 7c79 0efb ....q...|_/.|y..0x0020: 8010 0101 27b5 0000 0101 080a 6c47 5e17 ....'.......lG^.0x0030: 6c47 579f lGW.11:42:43.322921 IP localhost.6379 > localhost.28944: . ack 65665 win 0 <nop,nop,timestamp 1816616471 1816613366>0x0000: 4500 0034 5e0c 4000 4006 deb5 7f00 0001 E..4^.@.@.......0x0010: 7f00 0001 18eb 7110 7c79 0efb 7c5f 2ff1 ......q.|y..|_/.0x0020: 8010 0000 2e5e 0000 0101 080a 6c47 5e17 .....^......lG^.0x0030: 6c47 51f6 lGQ.11:42:46.634889 IP localhost.28944 > localhost.6379: . ack 1 win 257 <nop,nop,timestamp 1816619783 1816616471>0x0000: 4500 0034 7f98 4000 4006 bd29 7f00 0001 E..4..@.@..)....0x0010: 7f00 0001 7110 18eb 7c5f 2ff0 7c79 0efb ....q...|_/.|y..0x0020: 8010 0101 144d 0000 0101 080a 6c47 6b07 .....M......lGk.0x0030: 6c47 5e17 lG^.

The server returns a large number of ack 65665 win 0 packets.

After reading the relevant information, we found that this problem is related to tcp traffic control. because too many content is involved, we will only summarize the key points here:
1) win 0 in ack 65665 win 0 indicates that the server tells the client that my tcp sliding window is full and there is no space. After receiving such a packet, the client stops sending data;
2) Why does tcp sliding windows fail to be full after the server collects a portion of the data and returns ack 65665 win 0?
This is what the tcp protocol stipulates. When the sliding window is full, in order to avoid being quickly filled up again, the client can continue sending messages only when the Sliding Window space reaches the buffer size or when the MSS size is large. That is, the win value in the ack packet is no longer 0. For details, see the following description:

To avoid SWS, we simply make the rule that the caller may not update its advertised receive window in such a way that this leaves too little usable window space on the part of the sender. In other
Words, we restrict the operator from moving the right edge of the window by too small an amount. the usual minimum that the edge may be moved is either the value of theMSS parameter, or one-half the buffer size, whichever is
Less.

Test and code verification confirm that Linux is equal to MSS.

The process involves a lot of tcp knowledge, such as MSS, SWS (Slide window system), SWS (Silly window syndrome), tcp cache, and ack mechanism, if you are interested, you can check it.

For a complete explanation, see the following link:
Http://www.tcpipguide.com/free/t_TCPWindowManagementIssues.htm