Какие параметры влияют на производительность приложений? Часть 1. TCP Window Size

Самый простой способ понять значение термина размер TCP окна (TCP Window Size), это представить разговор двух человек. Один человек говорит, а второй кивает головой или говорит да, тем самым подтверждая, что он понял, а по сути, получил все слова, которые ему были сказаны. После этого разговор продолжается. Если мы встречаем особо говорливого человека, то наша голова быстро загружается, и мы начинаем терять нить разговора или переспрашивать нашего собеседника. Тоже самое происходит и в Матрице — в мире цифр и машин.

Размер TCP окна (TCP Window Size) – количество октетов (начиная с номера подтверждения), которое принимающая сторона готова принять в настоящий момент без подтверждения. На стадии установления соединения рабочая станция и сервер обмениваются значениями максимального размера TCP окна (TCP Window Size), которые присутствуют в пакете и эти значения можно легко увидеть, воспользовавшись захватом трафика.

Например, если размер окна получателя равен 16384 байта, то отправитель может отправить 16384 байта без остановки. Принимая во внимание, что максимальная длина сегмента (MSS) может быть 1460 байт, то отправитель сможет передать данный объем в 12 фреймах, и затем будет ждать подтверждение доставки от получателя и информации по обновлению размера окна. Если процесс прошел без ошибок, то размер окна может быть увеличен. Таким образом, реализуется размер скользящего окна в стеке протокола TCP.

В зависимости от состояния каналов связи, размер окна может быть больше или меньше. Каналы связи могут быть высокоскоростными (большая пропускная способность) и протяженными (большая задержка и возможно потери), поэтому при небольшом размере TCP окна мы будем вынуждены отправлять один или несколько фреймов и ждать подтверждения от получателя, затем процесс повторяется. Таким образом, наши приложения будут неэффективно использовать доступную полосу пропускания. Пакетов будет много, но реального полезного трафика будет передано не много. Чтобы получить максимальную пропускную способность, необходимо использовать оптимально установленный размер передающего и принимающего окна для канала, который вы используете.

Для расчёта максимального размера окна (т.е. максимальный объем данных, которые могут передаваться одним пользователем другому в канале связи) рассчитывается по формуле:

Полоса пропускания (бит/сек) * RTT (круговое время передачи по сети) = размер окна в битах

Таким образом, если ваши два офиса соединяет канал связи в 10 Мбит/сек и круговое время составляет 85 миллисекунд, то воспользовавшись данной формулой, мы получим значение окна равное:

10 000 000 * 0,085 / 8 = 106250 байт

Размер поля Window в заголовке TCP составляет 16 бит; это означает, что узел TCP может указать максимальный размер TCP окна 65535 байт. Таким образом, максимальная пропускная способность составляет:

65535 * 8 / 0,085 = 6,2 Мбит/сек

т.е. чуть больше 50% от реально доступной полосы пропускания канала.

В современных версиях операционных систем можно увеличить размер окна TCP Window Size и включить динамическое изменение окна в зависимости от состояния канала связи. В предложении RFC 1323 дано определение масштабирования окон, позволяющего получателю указывать размер окна больше 65535 байт, что позволит применять большие размеры окон и высокоскоростные каналы передачи. Параметр TCP Window Scale указывает коэффициент масштабирования окна, который в сочетании с 16-битным полем Window в заголовке TCP может увеличивать размер окна приема до максимального значения, составляющего примерно 1 ГБ. Параметр Window Scale отправляется только в сегментах синхронизации (SYN) при установке соединения. На нашем скриншоте из WireShark он составляет 256. Устройства, общающиеся друг с другом, могут указывать разные коэффициенты масштабирования для TCP окон.

Таким образом, активировав масштабирование окон TCP и уменьшив круговое время передачи по сети, мы сможем повысить эффективность использования доступной полосы пропускания и как следствие скорость работы приложений. А проверить это можно захватив пакеты, и посмотреть о каких значениях размера окна и коэффициенте масштабирования договорились устройства в момент установки соединения. Это динамическое увеличение и уменьшение размера окна является непрерывным процессом в TCP и определяет оптимальный размер окна для каждого сеанса. В очень эффективных сетях размеры окна могут стать очень большими, потому что данные не теряются. В сетях, где сетевая инфраструктура перегружена, размер окна, вероятно, останется маленьким.

Windows tcp receive window size

C:\windows\system32>netsh interface tcp show global

Querying active state.

TCP Global Parameters

Receive-Side Scaling State : enabled

Chimney Offload State : disabled

NetDMA State : disabled

Direct Cache Access (DCA) : disabled

Receive Window Auto-Tuning Level : normal

Add-On Congestion Control Provider : none

ECN Capability : disabled

RFC 1323 Timestamps : disabled

Initial RTO : 3000

Receive Segment Coalescing State : disabled

Hope this helps.

Jeremy Wu
TechNet Community Support

The value of autotuninglevel are:

• disabled : Fix the receive window at its default value.
• highlyrestricted : Allow the receive window to grow beyond its default value, but do so very conservatively.
• restricted : Allow the receive window to grow beyond its default value, but limit such growth in some scenarios.
• normal : Allow the receive window to grow to accommodate almost all scenarios.
• experimental : Allow the receive window to grow to accommodate extreme scenarios.

And, RTO refers to Retransmission timeout.

Windows tcp receive window size

Введение:
Термины:

MTU — Maximum Transmission Unit.
Это максимальный размер пакета данных, который может быть передан за один физический кадр по протоколу TCP/IP. Дело в том, что данные от компьютера к компьютеру в Интернете идут не сплошным потоком, а этими самыми кадрами — пакетами строго определенного размера.
При этом слишком большой пакет в пути, скорее всего, будет фрагментироваться и заполняться «воздухом», «балластом», что негативно скажется на эффективности связи. Так, если ваш провайдер имеет установки MTU=576, а у вас в Windows задано MTU=1500, то каждый ваш пакет будет им разбиваться на три по 576 байт: 576+576+576=1728 — то есть, 228 байт балласта будут добавляться к каждому вашему пакету. Но даже если провайдер тоже имеет MTU=1500, то при связи с удаленным сервером вполне может попасться маршрутизатор с меньшим значением MTU и пакеты опять-таки будут фрагментироваться, замедляя передачу данных.

MSS — Maximum Segment Size — это еще один параметр протокола TCP, определяющий самый большой сегмент данных TCP, которые могут быть переданы за один раз. То есть, MTU = MSS + заголовки TCP/IP. Для заголовка тоже имеется общепринятый размер — это 40 байт (20 байт IP и 20 байт TCP), следовательно, обычно MSS = MTU — 40. Этот параметр не устанавливается, а вычисляется:)

RWIN — Receive Window — окно приема, размер буфера, в котором накапливается содержимое области данных (MSS) нескольких полученных пакетов, прежде чем передается дальше, например, в браузер. При недостаточном размере этого буфера иногда происходит его переполнение, и поступающие пакеты отвергаются и теряются. Размер RWIN обязательно должен быть кратен MSS и обычно для лучшей эффективности модемного соединения рекомендуется его устанавливать равным 4 — 8 MSS. Однако, чрезмерно большой размер буфера также нежелателен, особенно на плохих линиях — при потере всего одного пакета в случае сбоя на линии будет повторно затребован не один потерянный пакет, а все пакеты из этого буфера, что займет некоторое время.

TTL — Time To Live — время жизни — количество хопов, то есть промежуточных серверов, через которые может пройти ваш пакет в поисках своего места назначения. Каждый такой сервер добавляет единицу к специальному счетчику в заголовке вашего пакета, и когда счетчик достигает максимально разрешенного значения, пакет считается заблудившимся и прекращает свое существование. По умолчанию TTL равен 32, что сегодня явно недостаточно для разросшегося Интернета — нередки случаи, когда удаленный сервер находится более чем в 32 переходах, поэтому TTL следует увеличить как минимум до 64.

——————————————————
Таким образом, логично считать, что большие пакеты в итоге все-таки предпочтительнее, и если ваш провайдер настроил свои серверы и маршрутизаторы на большие пакеты, то надо стремиться использовать это на всю катушку.

Итак, надо определить MTU провайдера (оператора). Определяем вручную: Только сначала надо установить MTU равным 1500б. это можно сделать и вручную в реестре, но лучше (чтобы и остальные параметры также править) использовать спец. проги, например
MTUspeed .
После этого мерием MTU прова.
В командной строке:
PING -f -l 1500 ххх.ххх.ххх.ххх, где «ххх.ххх.ххх.ххх» — IP-адрес тестируемого сервера, а «-I» — это буква L, а не единица. -l это размер буфера отправки(1500). -f это флаг запрещающий фрагментацию пакета.

Например, у меня получилось так:

PING -f -l 1472 mail.ru
Обмен пакетами с mail.ru [194.67.57.51] по 1472 байт:
Ответ от 194.67.57.51: число байт=1472 время=3617мс TTL=249
Ответ от 194.67.57.51: число байт=1472 время=3315мс TTL=249
Ответ от 194.67.57.51: число байт=1472 время=3271мс TTL=249

PING -f -l 1473 mail.ru
Обмен пакетами с mail.ru [194.67.57.51] по 1473 байт:
Требуется фрагментация пакета, но установлен запрещающий флаг.
Требуется фрагментация пакета, но установлен запрещающий флаг.
Требуется фрагментация пакета, но установлен запрещающий флаг.

Но это не значит, что MTU прова 1472б. Ping прибавляет к нашим данным заголовок — IP (20 Байтов) и ICMP (8 Байтов). Итак, MTU прова 1500б .

Несмотря на то, что программ, предназначенных якобы для двукратного улучшения связи одним кликом мыши — пруд пруди. И тут, как вы можете сами понять, совсем не факт, что MTU=576, которое везде рекомендуется западными программистами и экспертами, будет оптимальным и для нас в России. Наши провайдеры сплошь и рядом выбирают для себя MTU=1500, а при «пинговании» удаленных серверов мы обнаруживаем, что пакет такого размера, вопреки всем утверждениям, проходит чаще всего нефрагментированным.

Для остальных параметров не считаю нужным ничего писать:) потому что они не так спорны как MTU.

Читайте также

Подключаем ReadyBoost Один из самых простых и недорогих способов ускорить работу Vista…

используют разное ядро существуют разные драйвера, оптимизированные под каждую систему…

Похоже, что многостраничные инструкции на тему того, как создать загрузочную флешку и…

В этой статье хочу рассказать вам о бесспорно хорошей и необходимой функции Windows –…

работать с AIMP для windows 7 стало намного удобнее и приятнее. Если вы впервые слышите…

Подпишись на нашу группу в контакте и будь в курсе обновлений:

Lowest TCP receive window size

What is the lowest possible TCP receive window size can be announced by Linux kernel TCP/IP stack impl and how can i configure to make it announce such one? My goal is to achieve low latency and sacrificing throughput?

1 Answer 1

Right now my test client application reads about 128 bytes each second from buffer and TCP stack waits till there are free SO_RCVBUF/2 bytes space before notifying server about new window size. I’d like to make my client announce window size lower than SO_RCVBUF/2 if its possible.

I do not think that changing the receive window size will have any effect on latency.

However, since your messages are small (128 bytes), you may like to disable Nagle algorithm in the sender that makes the sender wait when sending TCP payload smaller than MSS:

Applications that expect real-time responses and low latency can react poorly with Nagle’s algorithm. Applications such as networked multiplayer video games or the movement of the mouse in a remotely controlled operating system, expect that actions are sent immediately, while the algorithm purposefully delays transmission, increasing bandwidth efficiency at the expense of latency. For this reason applications with low-bandwidth time-sensitive transmissions typically use TCP_NODELAY to bypass the Nagle delay.

On the receiver you may like to disable TCP delayed acknowledgements:

The additional wait time introduced by the delayed ACK can cause further delays when interacting with certain applications and configurations. If Nagle’s algorithm is being used by the sending party, data will be queued by the sender until an ACK is received. If the sender does not send enough data to fill the maximum segment size (for example, if it performs two small writes followed by a blocking read) then the transfer will pause up to the ACK delay timeout. Linux 2.4.4+ supports a TCP_QUICKACK socket option that disables delayed ACK.

The TCP Window, Latency, and the Bandwidth Delay product

This article is intended as a primer on some TCP/IP networking concepts and factors that determine an optimal TCP Receive Window.

The TCP Window is the amount of outstanding data (unacknowledged by the recepient) that can remain in the network. After sending that amount of data, the sender stops and waits for acknowledgement back from the receiver that it has gotten some of it. As such, this value is probably the single most important setting in tuning broadband internet connections. The TCP Window is negotiated at the beginning of every connection during the TCP «handshake» stage.

In the original DARPA TCP/IP standard, the TCP Receive Window (RWIN) was limited to 64K (65535), since there are only 16-bits in the TCP headers for the RWIN value, and 2^16=64K. This limitation needed to be addressed, and in 1992 RFC 1323 added a «TCP Options» header extension, which allowed for expanding the maximum TCP Window size by adding another byte to act as a «scale factor» to the RWIN value. The RFC1323 RWIN byte can contain any value between 0 and 14, as follows:

1. Start with the original 16-bit window size, let’s call it the «Unscaled RWIN».
2. Compute the «multiplier», which equals two, raised to the power of our RFC1323 «scale factor».
3. The requested TCP Window Size is then the «Unscaled RWIN» multiplied by the «multiplier».

For example, let’s assume an unscaled RWIN value of 64240, and a scale factor is 3. the actual RWIN value then would be: 64240 * 2^3 = 513920.

Note that the scale factor is limited to 14; 2^14=16384, and the maximum unscaled RWIN is 65535. 16384 * 65536 = 1,073,725,440 (a gigabyte). Thus, RFC1323 allows for a maximum TCP Receive Window of up to one gigabyte.

Notes:
When calculating an optimal RWIN value for broadband, one should try to use as high as possible unscaled RWIN values first (usually the highest MSS multiple under 65535) and a smaller scale factor. It is a much better method for maximizing compatability with older routers (that don’t work well with TCP Options), as well as some wireless networks, VPN endpoints, etc. that have problems coping with small unscaled RWIN values combined with high scale factors. Small initial/unscaled RWIN value is one of the shortcomings of Windows Vista’s TCP Window «auto-tuning» as well.

The speed of every data transfer, like TCP is of course largely determined by the line speed. In addition, however, let’s consider the delay, or RTT(round trip time) of each data packet.

Any time a client computer asks a server a question, there is a RTT delay until it receives a response. Data packets have to thravel through a number of high-traffic (sometimes congested) routers, and there is always the speed of light (or electricity for copper lines) as limitation, considering the huge distances of internet communication.

Let’s examine a client computer communicating with a server over a geosynchronous satellite link. The client’s request (every packet) has to travel 22,300 miles to the satellite, then 22,300 miles down to the server. Then, when the server sends its response, it has to travel the same distance back to the client, adding another 22,300 miles up + 22,300 miles down. Thus, that simple packet of data traveled at least 89,200 miles. Considering the speed of light (186,000 miles per second), we can conclude that there is a minimum round-trip delay on a satellite connection of about half a second (500ms).

The Bandwidth * Delay Product

The Bandwidth*Delay product, or BDP for short, determines the amount of data that can be in transit in the network (just as RWIN). It is the product of the available bandwidth and the latency (RTT). BDP is a very important concept in a window-based protocol such as TCP, as throughput is bound by the BDP ! The BDP states that:

What does it mean ? The BDP, and the TCP Receive Window limit our connection to the product of the latency and the bandwidth. A transmission can not exceed the RWIN / latency value.

When calculating an optimal RWIN value, one should try to use as high as possible unscaled RWIN values (usually the highest MSS multiple under 65535) and a smaller scale factor. It is a much better method accounting for older routers and some wireless networks that don’t work well with TCP Options (RFC1323), or large scale factors.

To determine the optimal TCP Receive Window, you can simply use one of the SG TCP Analyzer recommended values, or perform the following calculations:

1. Determine maximum segment size (MSS for short, packet size minus TCP/IP headers. Displayed by the SG TCP Analyzer), as well as the line’s maximum anticipated latency and advertised maximum bandwidth.
(for example, 1460 MSS, 300ms max latency, 6Mbit/s max bandwidth).

2. Find the unscaled RWIN value (largest even multiple of MSS less than 65535):
65535 / 1460 (MSS) = 44.9
round down to even number = 44
44 x 1460 = 64240 (this is the optimal unscaled RWIN value for broadband connections with 1500 MTU/1460 MSS)

3. Multiply the unscaled RWIN by 2 until it is close to, or larger than BDP
Our BDP for 6Mbps @ 300 latency is:
6000 kbps x 300ms = 1800000 / 8 = 225000
64240 (unscaled RWIN) x 2 x 2 . = 256960 (number larger than, or close to BDP, this is the optimal RWIN)

TCP Window in Vista / Windows 7 / 2008 Server

In Windows Vista and 2008 server, Microsoft introduced a new TCP/IP stack with a number of improvements. It also includes a concept called TCP Window «Auto-Tuning» that’s been used in Linux for years. The idea is, a small initial RWIN value is advertised, which is then adjusted on the fly depending on the current line speed and latency. This new implementation works much better by default, compared to previous Windows versions. In theory, the new automatic RWIN algorithm adjusts the TCP Window size based on three main factors:

Line speed: faster line speed leads to larger RWIN values
RTT delay: higher latency leads to larger RWIN values
Application delay: larter RWIN values for applications that are slow to empty the buffer

The algorithm has the ability to control the TCP Window value per connection. Also, by default, Vista/2008 will not allocate RWIN values larger than 16Mb.

There are still a couple of downsides to the new approach:

1. The initial assigned unscaled RWIN value is usually very small (

17520 bytes) when auto-tuning is enabled.
2. There are some routers, SPI firewalls, VPN endpoints, and wireless networks that do not work well with small RWIN values and large RWIN scale factors.
3. The ability for a user to control the Auto-tuning RWIN values is very limited; there is some limited control over the algorithm behavior, however one can not specify an initial or exact RWIN value for the stack to use.

For additional information on tunning TCP/IP under Vista, see our Windows Vista/2008 tweaks article.