اطلاعیه

بستن
No announcement yet.

What is TCP Window Scaling?

بستن
این موضوع بسته شده است.
X
X
 
  • فیلتر کردن
  • زمان
  • نمایش
Clear All
پست های جدید

  • What is TCP Window Scaling?

    The original TCP specification included a window size no larger than 64 KB. This limitation was introduced by the 16 bit header that specified window size. To achieve the recommended 1 MB window size, RFC 1323 TCP extensions must be enabled. The rest of this post is a somewhat detailed elaboration of how the RFC 1323 TCP window scaling option works.
    The TCP window scaling option in RFC 1323 allows for a maximum window size of 1 GB. This particular limitation is derived from the original design of TCP that requires a data segment's sequence number to be within the first 231 bytes (2 GB) of the window. If the sequence number does not appear in that area, the data segment is considered old and discarded. To guarantee the sequence number is always withing the first 231 bytes, RFC 1323 requires the maximum window size to be less than 230 bytes.
    The TCP window scaling option works by including a scale factor in a SYNpacket. This scale factor informs the receiver that the sender is willing to do window scaling and offers a scale factor for the communication. The scale factor is used to shift the window field before the data segment is sent. The scale factor is limited to 14 to guarantee the window is less than the 231maximum. Thus, 214 * (216 - 1) < 231 (or (216 - 1) << 14 < 231, if you prefer).
    All of this is just a highly involved way of saying that in order to increase window size beyond the 64 KB limit, RFC 1323 window scaling options must be enabled. Most operating systems support this option, but not all of them have it enabled by default. When in doubt, make sure and enable it.

    کد:
    http://slaptijack.com/system-administration/what-is-tcp-window-scaling/

  • #2
    Windows TCP Performance Tuning

    As discussed previously, we're going to enable RFC 1323 Window Scaling and increase the default TCP receive and send windows to 1 MB. By default Windows 2000 and XP do not offer window scaling options, but will accept them if offered by the other side. To make our changes, we'll need to modify the following registry keys underHKLM\SYSTEM\CurrentControlSet\Services\Tcpip\ Parameters and reboot the system.
    Tcp1323Opts = 3
    TcpWindowSize = 1048576
    GlobalMaxTcpWindowSize = 16777216

    You can edit the Windows registry with Registry Editor. To start Registry Editor issue regedit at the command prompt or in the Run box. In this image, you can see the various options being set. Remember to select the radio option for Decimal, otherwise your values won't mean what they should.

    کامنت


    • #3
      Linux TCP Performance Tuning

      If you have been following our TCP Performance Tuning series, you'll know that we want to enable RFC 1323 Window Scaling and increase the TCP window size to 1 MB. To do this, we'll add the following lines to /etc/sysctl.conf and issue sudo sysctl -p to apply the changes immediately.
      net.core.rmem_max = 16777216
      net.core.wmem_max = 16777216
      net.core.rmem_default = 1048576
      net.core.wmem_default = 1048576
      net.ipv4.tcp_rmem = 4096 1048576 16777216
      net.ipv4.tcp_wmem = 4096 1048576 16777216
      net.ipv4.tcp_congestion_control = bic
      net.ipv4.tcp_window_scaling = 1
      net.ipv4.tcp_timestamps = 1

      As before, we're setting the maximum buffer size large and the default window size to 1 MB. RFC 1323 is enabled via net.ipv4.tcp_window_scaling andnet.ipv4.tcp_timestamps. These options are probably on by default, but it never hurts to force them via /etc/sysctl.conf. Finally, we are choosing BIC as our TCP Congestion Control Algorithm. Again, that value is most likely the default on your system (especially any kernel version after 2.6.12).

      کامنت


      • #4
        TCP Receive Window Size Calculation and Window Scaling

        The TCP receive window size is the amount of receive data (in bytes) that can be buffered at one time on a connection. The sending host can send only that amount of data before waiting for an acknowledgment and window update from the receiving host. The Windows Embedded CE TCP/IP stack was designed to tune itself in most environments, and uses larger default window sizes than earlier versions. Instead of using a hard-coded default receive window size, TCP adjusts to even increments of the maximum segment size (MSS) negotiated during connection setup. Matching the receive window to even increments of the MSS increases the percentage of full-sized TCP segments used during bulk data transmission.
        The receive window size defaults to a value calculated as follows:
        1. The starting value of the receive window size is determined from the registry settings for GlobalMaxTcpWindowSize, the global TcpWindowSize, and the adapter specific TcpWindowSize, according to the following logic:
          TcpWindowSize is set to HKLM\Comm\<AdapterName>\Parms\Tcpip\TcpWindowSize if the registry key value exists.
        2. Upon establishing the connection, the receive window size is rounded up to an increment of the maximum TCP segment size (MSS) which was negotiated during connection setup.
        3. If that is not at least four times the value of MSS, then it is adjusted to four times the value of MSS, with a maximum size of 64 KB, unless a window scaling option (RFC 1323) is in effect.

        You can set the receive window size to a specific value by setting the TcpWindowSizeregistry entry described in TCP/IPv4 Configurable Registry Settings.
        To improve performance on high-bandwidth, high-delay networks, RFC 1323 is supported. This RFC details a method for supporting scalable windows by allowing TCP to negotiate a scaling factor for the window size at connection establishment. This allows for an actual receive window of up to 1 gigabyte (GB). RFC 1323 Section 2.2 provides the following description of window scaling:
        2.2 Window Scale Option
        The three-byte Window Scale option may be sent in a SYN segment by a TCP. It has two purposes: (1) indicate that the TCP is prepared to do both send and receive window scaling, and (2) communicate a scale factor to be applied to its receive window. Thus, a TCP that is prepared to scale windows should send the option, even if its own scale factor is 1. The scale factor is limited to a power of two and encoded logarithmically, so it may be implemented by binary shift operations.
        TCP Window Scale Option (WSopt):
        Kind: 3 Length: 3 bytes



        +---------+---------+---------+
        | Kind=3 |Length=3 |shift.cnt|
        +---------+---------+---------+




        This option is an offer, not a promise; both sides must send Window Scale options in their SYN segments to enable window scaling in either direction. If window scaling is enabled, then the TCP that sent this option will right-shift its true receive-window values by Shift.cnt bits for transmission in SEG.WND. The value Shift.cnt can be zero (offering to scale, while applying a scale factor of 1 to the receive window).
        This option may be sent in an initial <SYN> segment (for example, a segment with the SYN bit on and the ACK bit off). It may also be sent in a <SYN,ACK> segment, but only if a Window Scale option was received in the initial <SYN> segment. A Window Scale option in a segment without a SYN bit should be ignored.
        The Window field in a SYN (for example, a <SYN> or <SYN,ACK>) segment itself is never scaled.
        When you read network traces of a connection that was established by two computers that support scalable windows, keep in mind that the window sizes advertised in the trace must be scaled by the negotiated scale factor. The scale factor can be observed in the connection establishment (3-way handshake) packets.
        Windows Embedded CE uses window scaling automatically if the TcpWindowSize registry entry is set to a value greater than 64 KB. Window scaling can be disabled with the Tcp1323Opts registry entry.

        http://msdn.microsoft.com/en-us/library/aa924893.aspx

        کامنت


        • #5
          TCP Windows and Window Scaling

          TCP Windowing

          As we know, TCP is a connection-oriented protocol; both ends of a connection keep strict track of all data transmitted, so that any lost or jumbled segments can be retransmitted or reordered as necessary to maintain reliable transport. To compensate for limited buffer space (where received data is temporarily stored until the appropriate application can process it), TCP hosts agree to limit the amount of unacknowledged data that can be in transit at any given time. This is referred to as the window size, and is communicated via a 16-bit field in the TCP header.Suppose we have two hosts, A and B, that form a TCP connection. At the start of the connection, both hosts allocate 32 KB of buffer space for incoming data, so the initial window size for each is 32,768.Host A needs to send data to host B. It can tell from host B's advertised window size that it can transmit up to 32,768 bytes of data (in intervals of the maximum segment size, or MSS) before it must pause and wait for an acknowledgment. Assuming an MSS of 1460 bytes, host A can transmit 22 segments before exhausting host B's receive window.When acknowledging receipt of the data sent by host A, host B can adjust its window size. For example, if the upper-layer application has only processed half of the buffer, host B would lower its window size to 16 KB. If the buffer was still entirely full, host B would set its window size to zero, indicating that it cannot yet accept more data.On a LAN with high bandwidth and extremely low delay, windows are rarely stressed as there are typically very few segments in transit between two endpoints at any given time. On a high-bandwidth, high-delay network, however, an interesting phenomenon occurs: it is possible to max out the receive window of the destination host before receiving an acknowledgment.As an example, let's assume a TCP connection is established between two hosts connected by a dedicated 10 Mbps path with a one-way delay of 80ms. Both hosts advertise the maximum window size of 65,535 bytes (the maximum value of a 16-bit unsigned integer). We can calculate the potential amount of data in transit in one direction at one point in time as bandwidth * delay: 10,000,000 bps divided by 8 bits per byte, multiplied by 0.08 seconds equals 100,000 bytes. In other words, if host A begins transmitting to host B continuously, it will have sent 100,000 bytes before host B receives the first byte transmitted. However, because our maximum receive window is only 65,535 bytes, host A must stop transmitting once this number has been reached and wait for an acknowledgment from host B. (For the sake of simplicity, our example calculations do not factor in overhead from TCP and lower-layer headers.) This delay wastes potential throughput, unnecessarily inflating the time it takes to reliably transfer data across the network. TCP window scaling was created to address this problem.Window Scaling

          Window scaling was introduced in RFC 1072 and refined in RFC 1323. Essentially, window scaling simply extends the 16-bit window field to 32 bits in length. Of course, the engineers could not simply insert an extra 16 bits into the TCP header, which would have rendered it completely incompatible with existing implementations. The solution was to define a TCP option to specify a count by which the TCP header field should be bitwise shifted to produce a larger value.A count of one shifts the binary value of the field to left by one bit, doubling it. A count of two shifts the value two places to the left, quadrupling it. A count of seven (as shown in the example above) multiplies the value by 128. In this manner, we can multiply the 16-bit header field along an exponential scale to achieve more than sufficiently high values. Of course, this causes us to lose granularity as we scale (we can only increase or decrease the window size in intervals of 2nwhere _n_ is our scale), but that isn't much of a concern when dealing with such large windows.The window scaling option may be sent only once during a connection by each host, in its SYN packet. The window size can be dynamically adjusted by modifying the value of the window field in the TCP header, but the scale multiplier remains static for the duration of the TCP connection. Scaling is only in effect if both ends include the option; if only one end of the connection supports window scaling, it will not be enabled in either direction. The maximum valid scale value is 14 (section 2.3 of RFC 1323 provides some background on this caveat for those interested).Revisiting our earlier example, we can observe how window scaling allows us to make much more efficient use of long fat networks. To calculate our ideal window, we double the end-to-end delay to find the round trip time, and multiple it by the available bandwidth: 2 * 0.08 seconds * 10,000,000 bps / 8 = 200,000 bytes. To support a window of this size, host B could set its window size to 3,125 with a scale value of 6 (3,125 left shifted by 6 equals 200,000). Fortunately, these calculations are all handled automatically by modern TCP/IP stack implementations.
          http://packetlife.net/blog/2010/aug/...indow-scaling/

          کامنت

          در حال انجام ...
          X