In Linux, The WEB100 patch is used to expand the window.

Some time ago, I was tracking the problem of an RDP application. After the RDP application is processed by a device transparent proxy, the speed of the application is much slower than that of the device transparent proxy, at least half. It is too troublesome to use RDP each time. Therefore, a simple TCP packet sending server and the packet receiving client are used to simulate the RDP data stream and speed up the test efficiency. The results showed that the simplest packet sending application would be slowed down by about 3 seconds after transparent proxy. At first, we thought this was the processing latency caused by proxy processing, this number is reached when the processing latency of each package is accumulated. After reading the packet capture, I found that it is incorrect. So I used Linux as the server for sending packets and Windows as the client. The packet capture during connection is as follows:

-Bash-2.05b # tcpdump-I eth0 port 8888-nn-c 20

Tcpdump: listening on eth0

15:24:16. 709831 192.168.0.148.60320> 192.168.3.121.8888: S 1286639064: 1286639064 (0) win 8192 <mss 1460, nop, nop, sack, nop, wscale 8> (DF)

15:24:16. 713211 192.168.3.121.8888> 192.168.0.148.60320: S 1778803221: 1778803221 (0) ack 1286639065 win 5840 <mss 1460, nop, nop, sackOK, nop, wscale 7>

15:24:16. 709831 192.168.0.148.60320> 192.168.3.121.8888:. ack 1 win256(DF)

15:24:19. 740047 192.168.3.121.8888> 192.168.0.148.60320: P (256) Ack 1 win 45

15:24:19. 929831 192.168.0.148.60320> 192.168.3.121.8888:. ack 257 win 255 (DF)

15:24:19. 936427 192.168.3.121.8888> 192.168.0.148.60320: P 257: 1461 (1204) ack 1 win 45

15:24:19. 936538 192.168.3.121.8888> 192.168.0.148.60320: P 1461: 1601 (140) ack 1 win 45

15:24:19. 929831 192.168.0.148.60320> 192.168.3.121.8888:. ack 1601 win 256 (DF)

15:24:19. 929831 192.168.0.148.60320> 192.168.3.121.8888: P (20) ack 1601 win 256 (DF)

15:24:19. 937526 192.168.3.121.8888> 192.168.0.148.60320:. ack 21 win 45

15:24:19. 929831 192.168.0.148.60320> 192.168.3.121.8888: P (20) ack 1601 win 256 (DF)

15:24:19. 937731 192.168.3.121.8888> 192.168.0.148.60320:. ack 41 win 45

15:24:19. 929831 192.168.0.148.60320> 192.168.3.121.8888: P 41: 61 (20) ack 1601 win 256 (DF)

15:24:19. 937927 192.168.3.121.8888> 192.168.0.148.60320:. ack 61 win 45

15:24:19. 966700 192.168.3.121.8888> 192.168.0.148.60320:. 1601: 3061 (1460) ack 61 win 45

15:24:19. 966830 192.168.3.121.8888> 192.168.0.148.60320: P 3061: 3201 (140) ack 61 win 45

 

The problem occurs on the third packet in the three-way handshake process and the first packet sent by the server. There is a 3 s interval in the middle. The upper-layer server sends data immediately after acceept, there is no latency. To determine where the latency occurs, add some debugging information to the upper layer, and register the hook function at the highest priority of LOCAL_OUT to print some debugging information, the result indicates that the latency may only occur in the TCP protocol stack.

At the same time, there is a strange phenomenon that the length of the packet sent at the upper layer is 1600 bytes. The packet sent by TCP according to the MSS package should be a combination of 1460 + 140, this can be seen from the following package, but the split method when the delayed package is sent is 256 + 1204 + 140, 256 is the window value carried by the third ACK packet in the three-way handshake. It seems that the window is limited. The kernel has been added with debugging logs to prove that the window is restricted. TCP considers that the receiving window of the other party is exceeded. As a result, no sending is successful when sending is called at the upper layer, and the second sending timeout occurs, the package is also sent out.

In the three-way handshake, we can see that the wscale option is 256 <8 = 65536, rather than 256. It seems that there is a problem in processing the window expansion option. Repeat the TCP establishment process in detail, mainly looking at the process of snd_wnd. In tcp_rcv_state_process (), we found that when we processed the third ACK packet of the three-way handshake, we were surprised to say:

Tp-> snd_wnd = ntohs (th-> window );

 

In this case, the window expansion option should be considered. I don't believe that Linux has this big BUG. I went to lxr to read the original Linux code and found that:

Tp-> snd_wnd = ntohs (th-> window) <tp-> snd_wscale; 

 

We finally found that we modified this sentence on the WEB100 patch. The patch code is as follows:

Code Tp-> snd_una = TCP_SKB_CB (skb)-> ack_seq;
-Tp-> snd_wnd = ntohs (th-> window) <tp-> snd_wscale;
+ WEB100_VAR_SET (tp, SndUna, tp-> snd_una );
+/* RFC1323: The window in SYN & SYN/ACK segments is
+ * Never scaled (PSC/CMU patch {rreddy, mathis} @ psc.edu ).
+ */
+
+ Tp-> snd_wnd = ntohs (th-> window );
+ WEB100_UPDATE_FUNC (tp, web100_update_rwin_rcvd (tp ));

 

Google found that this is the old Web100 patch code, and the new Code does not seem to have this code.

After modification, the latency of 3 S is eliminated. However, RDP is slower than half, and the elimination of latency of 3 S has little impact. The next article will continue.