Windows size value что это

mirk » 19.05.2017 15:21:04

Re: Пояснение по TCP Window size

Pavia » 19.05.2017 19:46:23

TCP это потоковый протокол.
TCP Window — это часть этого потока. Вернее TCP двунаправленный протокол поэтому у него два потока.
TCP Window Size это размер окна для текущего пакета TCP.

Когда идёт трёх этапное рукопожатие. Приемная и передающая сторона сообщают размер своих накопителей(буферов). Сообщают они это в поле TCP.WindowSize.
Если передающая сторона будет передавать больше чем размер накопителя у приемника то накопитель просто не сможет запомнить все данные что-бы отдать их приложению.
Поэтому выбирается общий наименьший размер буфера. Так как протокол двунаправленный то тут два передатчика и два приемника и у каждого свои размеры накопителей.
А далее текущий размер окна может быть ещё снижен.

Такого ограничения на подтверждение нет. Приемная сторона сообщает желаемый порядковый номер(Sequence Number) на который она пошлёт подтверждение.
Передатчик должен всё отослать и жать 2*MSL секунд подтверждения. Если подтверждения не было, то он начинает повторно отправлять данные.

Добавлено спустя 15 минут 18 секунд:
А да забыл. Ограничения на размер подтверждение нет но есть нестрогая рекомендуется выбирать не более размера MTU.
И есть требование, что если размер окна нулевой, то обязательно отправлять подтверждение.

Re: Пояснение по TCP Window size

vitaly_l » 19.05.2017 20:20:04

Re: Пояснение по TCP Window size

mirk » 19.05.2017 22:44:11

Буферы чего именно?

Выборочное подтверждение? Слабо верится в такое. Это ведь получается не гарантированная доставка, а вероятностная.

Re: Пояснение по TCP Window size

serbod » 20.05.2017 01:13:46

Re: Пояснение по TCP Window size

Pavia » 20.05.2017 09:50:58

Буферы данных, потока данных TCP. Я уже написал принимающей и передающей стороны. Размер определяет приложения которое должно обрабатывать данные.
Это буферы сокета. К примеру в компоненте инди:

Нет, не вероятностное. Подтверждение закрывает всю последовательность байт(seqance byts) до предыдущего подтверждённого номера. Если нет подтверждения, то вся последовательность отправляется заново. Было у вас в последовательности 10 TCP пакетов вот все их вы должны повторно отправить. Причём с теми же номерами что и до этого.
Да подтверждение выборочное, но это не баг это фича: большой номер подтверждения(Acknowledgment Number) позволяет принимающей стороне работать в тихом скрытном режиме.
Но с другой стороны из-за скрытности может произойти обрыв связи. Маршрутизатор стоящий по середине может посчитать что маршрут не работающий и перестать пропускать пакеты.

MTU это не размер пакета. Что означает буква M? Во-вторых я уже сказал что это нестрогая рекомендация.

Короче говоря частоту подтверждения надо выбирать из разумных соображений.

Re: Пояснение по TCP Window size

mirk » 21.05.2017 00:17:29

Смотрю трафик и вижу — в пакетах и стоит TCP Window Size=65536, а подтверждения сыпятся на каждый пакет.
ОС MS Windows 2008 Server.

Re: Пояснение по TCP Window size

Pavia » 21.05.2017 01:08:18

int recv(
_In_ SOCKET s,
_Out_ char *buf,
_In_ int len,
_In_ int flags
);

В len вы говорите сколько хотите получить. Это и есть через сколько байт вы отправите ACK. Делите на Windows Size получаете через сколько пакетов.

Просто никто мегабайты не указывает вот оно и сыпется на каждый пакет. Типично указывают килобайт ну не больше 64 кб.
Если указать мегабайт то есть вероятность нарваться на ошибку передачи. А вероятность ошибки высокая для примера 10 раз в секунду.
У меня интернет 15 мбит/с тобишь 2 мб в секунду. Я гарантированно словлю 5 ошибок на мегабайт. А значит принимающая сторона не пошлёт подтверждение, а отправляющая будет крутиться в бесконечном цикле снова и снова пытаясь отправить данные. Но статистика вещь упрямая.
Вот какой размер передачи следует выбрать? Ясно что лучше в 5 раз меньше и того имеем 204 кб. А если мы сидим на DSL модеме? Помниться у меня тогда 1 ошибка на 32 кбита была.
Там надо ещё меньше указывать. Типичным значением является MTU 1400 байт.
А почему сразу не выбрать маленький размер принимаемых данных? Это скажется на производительности Пока Ie7 тянул со скоростью 7-9 мБайт/с Опера9 тянула 11-12 мБайт.

Посмотрите исходники любой качалке как они динамически меняют размер принимаемых данных.

Тоже мне Фома-неверующий. Вам надо вы и проверяйте, а я макрософту верю. Читайте про SO_RCVBUF socket option

Да драйвер динамически меняет WindowsSize но приделы задаёт ваше приложение. Но вообще этот параметр лучше не трогать, а играться с параметром len в recv().
Кстати о птичках: Unix, Linux, embbeddet и прочие. Не все ОС поддерживают опцию SO_RCVBUF, но большинство всё же её поддерживают.

Добавлено спустя 59 минут 17 секунд:

WM_SIZE message

Sent to a window after its size has changed.

A window receives this message through its WindowProc function.

Parameters

The type of resizing requested. This parameter can be one of the following values.

Value	Meaning
SIZE_MAXHIDE 4	Message is sent to all pop-up windows when some other window is maximized.
SIZE_MAXIMIZED 2	The window has been maximized.
SIZE_MAXSHOW 3	Message is sent to all pop-up windows when some other window has been restored to its former size.
SIZE_MINIMIZED 1	The window has been minimized.
SIZE_RESTORED 0	The window has been resized, but neither the SIZE_MINIMIZED nor SIZE_MAXIMIZED value applies.

The low-order word of lParam specifies the new width of the client area.

The high-order word of lParam specifies the new height of the client area.

Return value

Type: LRESULT

If an application processes this message, it should return zero.

Example

Remarks

If the SetScrollPos or MoveWindow function is called for a child window as a result of the WM_SIZE message, the bRedraw or bRepaint parameter should be nonzero to cause the window to be repainted.

Although the width and height of a window are 32-bit values, the lParam parameter contains only the low-order 16 bits of each.

The DefWindowProc function sends the WM_SIZE and WM_MOVE messages when it processes the WM_WINDOWPOSCHANGED message. The WM_SIZE and WM_MOVE messages are not sent if an application handles the WM_WINDOWPOSCHANGED message without calling DefWindowProc.

IT Blogtorials

Where blogs and tutorials intersect >>>

Pages

Sunday, February 17, 2013

Understanding TCP Window Size / Window Scaling

The easiest way to understand TCP Window size is to observe two people having a conversation. Every so often, the talker will wait for the listener to acknowledge that they have heard everything up to that point. Once the listener acknowledges then the talker begins to talk again. The amount of words spoken before waiting for an acknowledgement from the listener is much like the TCP window size. The official definition of the window size is «the amount of octets that can be transmitted without receiving an acknowledgement from the other side».

Let’s assume that the receiver window size is 16,384 bytes which means that the sender can send up to 16,384 bytes before stopping to wait for an acknowledgement. Let’s also assume that the maximum segment size is 1024. This means that the sender can send 1024 bytes 16 times before it will stop sending and wait for an acknowledgement. For the sake of simplicity, I will not discuss TCP slow start (Rapid Increase/Multiplicative Decrease), congestion avoidance, congestion window and congestion control etc. As a side note keep in mind that the sender rate is controlled by the min(congestion window, receive window).

So what is the optimum window size that two hosts should agree on? Well there are different school of thoughts, but let’s look at one example where the window size is 2 x BDP. What the heck is BDP you ask? BDP is short for bandwidth-delay product. Here is how to calculate BDP. Bandwidth times one-way latency.

For example take two hosts connected with 20 Mbps of bandwidth and using PING/ICMP we conclude that the one-way latency is 20 ms. First let’s convert 20 Mbps into bytes which turns out to be 2,621,440 bytes. Take 2,621,440 x .02 equals to approximately 52,428. So 2 x 52,428 = 104,856 bytes, therefore the optimum window size for 2 hosts with 20 Mbps of bandwidth with a 20 ms one-way latency is 104,856 bytes. That is the sender can send 104,856 bytes of data before the sender must wait for an acknowledgement from the receiver. The reason we are doing 2 x the BDP is because the sender does not have to wait the time it takes for the ACK from the receiver (that he got the first 52428 bytes of data) to come back to the sender. Instead of the sender sitting IDLE for the ACK to come back, the sender can use the ACK travel time (20 ms) to actually send another 52,428 bytes of data.

One problem, the TCP RFC states that the window size is a 16 bit field which means that the largest window size that can be advertised is 65,536 or 2 ^ 16 or 1111 1111 1111 1111 (16 bits). And as we saw earlier, it is optimum to use 104,856 for the window size. So how do we accomplish this? This is where window scaling comes into play. It is a TCP option that is sent with the initial TCP 3 way handshake and both sides MUST agree to use this option or else window scaling will not be used. Window scaling basically bitwise shifts the window size. So let’s take a look at a wireshark packet capture to further explain this. Note that window scale option/shift count will be only be sent/negotiated in the initial 3 way handshake (SYN, SYN-ACK,ACK).

Flags 0x002 (SYN) — Initial SYN Packet sent by the sender.
Window size value: 8192 or 0010 0000 0000 0000 (16 bits).
Window scale Shift count: 8 — bit-wise shift window size by 8 to the left.
Window multiplier: 256 or 2 ^ shift count which is 2 ^ 8 in this case.

Flags 0x012 (SYN,ACK) — SYN, ACK packet sent by the receiver acknowledging the initial SYN packet.
Window size value: 5840 or 0001 0110 1101 0000 (16 bits).
Window scale Shift count: 7 — bit-wise shift window size by 7 to the left.
Window multiplier: 128 or 2 ^ shift count which is 2 ^ 7 in this case.

Now we are inspecting a packet farther down the conversation. This is a packet sent by 192.168.1.78 who notified the other end to use a shift count of 8.

Window size value: 64 or 0000 0000 0100 0000 (16 bits)
Window size scaling factor: 256 or 2 ^ 8 (as advertised by the 1st packet)
Although the window size states 64, the actual window size is 16,384 (64 * 256) meaning that the other side can send 16,384 bytes of data before stopping to wait for an acknowledgement.

As the conversation between the two hosts continue, the window size can be narrowed or widen using the widow size by specifying the window size value in the 16 bit field however the window size scaling factor must/will remains the same. For example if the sender wants to make the window size 104,856 the window size would be set as 410 in the 16 bit option field.

410 or 0000 0001 1001 1010 (16 bits) and since it will be shifted 8 to the left, the actual window size will be 104,960 or 0000 0000 0000 0001 1001 1010 0000 0000 (32 bits).

The maximum number of the shift count is 14 per RFC 1323 which means that the maximum window size can be 1 gigabyte. That is ONE BIG window size!!

Many more articles to come so stay tuned.

Please subscribe/comment/+1 if you like my posts as it keeps me motivated to write more and spread the knowledge.

Какие параметры влияют на производительность приложений? Часть 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 и определяет оптимальный размер окна для каждого сеанса. В очень эффективных сетях размеры окна могут стать очень большими, потому что данные не теряются. В сетях, где сетевая инфраструктура перегружена, размер окна, вероятно, останется маленьким.