TCP sliding window and window zoom factor (Window Scaling)

I. Introduction

Said TCP sliding window protocol, I believe everyone is very familiar, but said that the WINDOW Scaling parameter may know and have been used, this article Let us talk about the origin of Window Scaling.

Second, TCP Sliding Window

It is well known that TCP is a connection-oriented reliable message transmission protocol; in order to ensure reliable, both ends of the connection remain stringent to all transferred data in order to retransmit or reorder them. In addition, in order to track the transmitted data in the transmitting end, there is a TCP transmission cache. If the receiving end is accepted, the sliding window is part of this cache, and the recipient accepts the data, the ACK and the current sliding window can be told to send the sender, The data sent by the sender cannot exceed the residual window size of the recipient, and if the data in the receiver window has not been received, the window is full, the sender will stop sending data until the receiving side slide window has space.

Suppose we have two hosts A and B, which has established a TCP connection. At the beginning of the connection (negotiate when holding hands), the two hosts assign 32 kb buffer space for incoming data, so the initial window size of each host is 32,768.

The host A needs to send data to the host B. When the host B tells the host a, you can send up to 32,768 bytes (at maximum segment size or MSS interval) before accepting yourself. Suppose the MSS is 1460 bytes, and host A can send 22 segments before the receiving window of the host B.

When confirming that the data sent by the host A is confirmed, host B can adjust its window size. For example, if the upper application processes only half buffers, the host B reduces its window size to 16 kb (this time the host A transmits up to 16KB data to B) before accepting B. If the buffer is still completely filled, host B will set its window size to zero, indicating that it is not accepting more data, at this time, host A stops sending data.

On the LAN with high bandwidth and very low delay, the sliding window is very small. However, on the high bandwidth and high delay network, an interesting phenomenon occurs: before the sender receives a confirmation of the receiver, it cannot maximize the bandwidth.

For example, it is assumed that a TCP connection is established between two hosts connected by a dedicated 10 Mbps path, and the one-way delay is 80ms. Both hosts agree that the maximum window size is 65,535 bytes (the maximum value of 16-bit unsigned integers). We can calculate the potential amount of data transmitted in one direction in one direction, with bandwidth * delay: 10,000,000 BPS divided by 8 bits per byte, multiplied by 0.08 seconds, equal to 100,000 bytes.

In other words, if the host A starts continuously send it to the host B, it will send 100,000 bytes before the host B receives the first byte of the transmitted. However, since only 65,535 bytes of the agreed maximum receiving window, the host A must stop sending 65,535 bytes, and waits for acknowledgment from the host B. (For simplicity, our example calculations do not consider TCP and low-level headers.) This delay isted to waste potential throughput, unnecessarily increased the time required to transmit data over the network. Create a TCP window to resolve this issue.

Third, window zoom factor

The window is scaled in RFC 1072 and improved in RFC 1323. In fact, the window scaling is just the extended 16-bit window field to 32-bit length. The solution is to define the TCP option to specify the count, through which the TCP header field should be displaced to generate a larger value.

The Window size is set to 5840 bytes as shown above, but the window zoom factor is 7 (Window Scale), that is, the maximum actual window is 5840 * 128. WINDOW Scale is 1 to shift a binary value of the field to the left and double it. The count is 2 to move the value to the left and double it. The count is 7 (as shown in the above) multiplied the value by 128.

Window Scaling Options You can send only once during the connection in the SYN packet at the TCP handshake. You can dynamically adjust the window size by modifying the value of the window field in the TCP header, but within the duration of the TCP connection, the scale multiplier is static. Scaling is only valid only when both ends contain options; if only one end support window is scaled, it will not be enabled in either direction. The maximum effective proportion value is 14 (RFC 1323 2.3) provides some background information as interested people).

Review our previous example, we can observe how window scaling allows us to make network transfers more effectively (maximize the use of network bandwidth).In order to calculate our ideal window, we double the end to the end to find round-trip times, multiply it by available bandwidth: 2 * 0.08 seconds * 10,000,000 BPS / 8 200,000 bytes.In order to support this size window, host B can set its window size to 3,125, and its Window Scaling factor is 6 (3, 125 left shift 6 multiplied by 200,000).Fortunately, these calculations are automatically processed by modern TCP / IP stacks without application level intervention.In the application actual combat, our file upload service is okay, but when I go upload big video, I found very slow, one 8M video upload takes 1 minute 30s, we increase TCPBuffer and open the zoom factor, 8mVideo only needs 20s

Fourth, reference

http://packetlife.net/blog/2010/aug/4/tcp-windows-and-window-scaling/