Разное

Tcp window: на что он влияет и как его правильно рассчитать?

14.09.1999

Содержание

на что он влияет и как его правильно рассчитать?

Самый простой способ понять значение термина размер 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 — Windows Server

  • Статья
  • Чтение занимает 12 мин
  • Участники: 2

Были ли сведения на этой странице полезными?

Да Нет

Хотите оставить дополнительный отзыв?

Отзывы будут отправляться в корпорацию Майкрософт. Нажав кнопку «Отправить», вы разрешаете использовать свой отзыв для улучшения продуктов и служб Майкрософт. Политика конфиденциальности.

Отправить

В этой статье

В этой статье описываются функции TCP в Windows.

Применяется к:   Windows 10 — все выпуски, Windows Server 2012 R2
Исходный номер КБ:   224829

Сводка

В этой статье описываются следующие функции TCP в Windows:

  • Размер окна TCP
  • Параметры TCP теперь поддерживаются
  • Windows масштабирования — RFC 1323
  • Timestamp — RFC 1323
  • Защита от завернутой последовательности номеров (PAWS)
  • Селективные подтверждения (SACKS) — RFC 2018
  • Поведение ретрансмиссии TCP и быстрая перетрансмиссия

Функции TCP можно изменить, изменив записи в реестре.

Важно!

В следующих разделах, методах или задачах содержатся действия, которые содержат информацию о том, как изменить реестр. Однако неправильное изменение параметров реестра может привести к возникновению серьезных проблем. Поэтому следует в точности выполнять приведенные инструкции. Для дополнительной защиты создайте резервную копию реестра, прежде чем редактировать его. Так вы сможете восстановить реестр, если возникнет проблема. Дополнительные сведения о том, как создать и восстановить реестр, щелкните следующий номер статьи, чтобы просмотреть статью в базе знаний Майкрософт:

322756 Создание резервной копии и восстановление реестра Windows

Размер окна TCP

Размер окна получения TCP — это объем получаемой информации (в bytes), который можно буферить во время подключения. Отправитель может отправлять только такой объем данных, прежде чем ждать подтверждения и обновления окна от принимающего хоста. Стек Windows TCP/IP предназначен для самонастройки в большинстве сред и использует более крупные размеры окон по умолчанию, чем предыдущие версии.

Вместо использования жестко закодируемого по умолчанию размера окна TCP настраивается даже на приращения максимального размера сегмента (MSS). MsS обсуждается во время установки подключения. Настройка окна получения даже с увеличением msS увеличивает процент полноразмысных сегментов TCP, используемых при массовой передаче данных.

Размер окна получения определяется следующим образом:

  1. Первый запрос на подключение, отправленный удаленному хосту, рекламирует размер окна получения 16K (16 384 bytes).
  2. Когда подключение установлено, размер окна получения округление до даже приращения MSS.
  3. Размер окна регулируется в четыре раза больше, чем msS, до максимального размера 64 K, если не используется параметр масштабирования окна (RFC 1323).

Примечание

См. раздел «Windows масштабирование».

Для подключений Ethernet размер окна обычно устанавливается до 17 520 bytes (16K округляется до двенадцати сегментов 1460-byte). Размер окна может уменьшаться при подключении к компьютеру, поддерживаюшем расширенные параметры головы TCP, например селективные подтверждения (SACKS) и Timestamps. Эти два параметра увеличивают размер заготавлика TCP более чем до 20 bytes, что приводит к меньшему объему данных.

В предыдущих версиях Windows NT размер окна для подключения Ethernet был 8760 bytes, или шесть сегментов 1460-byte.

Чтобы установить размер окна получения к определенному значению, добавьте значение TcpWindowSize в подзарядку реестра, определенную вашей версии Windows. Для этого выполните указанные ниже действия.

  1. Выберите >

    запуск, Regedit введите, а затем выберите ОК.

  2. Развяжите подкайку реестра, специфическая для вашей версии Windows:

    • В Windows 2000 г. развяжите следующую подкайку:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces

    • Для Windows Server 2003 развяжите следующую подкайку:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

  3. В меню Редактирование указать значение New, а затем выберите значение DWORD.

  4. Введите TcpWindowSize поле «Новое значение» и нажмите кнопку Ввод

  5. Выберите Изменение в меню Изменить.

  6. Введите нужный размер окна в поле данных Value.

    Примечание

    Допустимый диапазон для размера окна — 0-0x3FFFC000 hexadecimal.

Это значение по умолчанию не присутствует. При добавлении значения TcpWindowSize оно переопределяет алгоритм размера окна по умолчанию, рассмотренный выше.

Примечание

TcpWindowSize также можно добавить в ключ Параметры, чтобы глобально установить размер окна для всех интерфейсов.

Параметры TCP теперь поддерживаются

Ранее параметры TCP использовались в основном для ведения переговоров о максимальных размерах сегмента. В Windows параметры TCP используются для масштабирования окон, штампа времени и выборочного ACK.

Существует два типа параметров TCP:

  1. Один параметр TCP octet, который используется для указать определенный вид параметра.
  2. Параметр TCP с несколькими октетами, состоящий из вида параметра, длины параметра и ряда октетов параметра.

В следующем списке показаны вид, длина, имя и описание каждого варианта TCP.

Вид: 0
Длина: 1
Вариант: Конец списка опций
Описание. Используется при заполнении последнего параметра TCP.

Вид: 1
Длина: 1
Параметр: Без операции
Описание. Используется при необходимости заполнения, и в одном пакете следуют дополнительные параметры TCP.

Вид: 2
Длина: 4
Параметр: Максимальный размер сегмента
Описание. Указывает максимальный размер сегмента TCP, который можно отправить по сети.

Вид: 3
Длина: 3
Параметр: Параметр масштабирования окна
Описание. Определяет фактор масштабирования, который будет использоваться при использовании размеров окна больше 64k.

Вид: 8
Длина: 10
Параметр: Параметр «Печать времени»
Описание. Используется для вычисления времени круговой поездки (RTT) передаваемых пакетов.

Вид: 4
Длина: 2
Вариант: разрешенО TCP SACK
Описание. Информирует других хостов о том, что разрешены выборочные Acks.

Вид: 5
Длина: изменяется
Вариант: параметр TCP SACK
Описание. Используется хостами для определения того, были ли получены неупорядоченные пакеты.

Windows масштабирование

Для более эффективного использования сетей с высокой пропускной способностью можно использовать больший размер окна TCP. Поле размеров окна TCP управляет потоком данных и ограничено 2-ми bytes или размером окна 65 535 bytes.

Так как поле размеров не может быть расширено, используется фактор масштабирования. Шкала окна TCP — это параметр, используемый для увеличения максимального размера окна с 65 535 бет до 1 гигабайта.

Параметр масштабирования окна используется только при трехшаговом рукопожатии TCP. Значение масштабирования окна представляет количество битов для переноса влево 16-битного поля размера окна. Значение масштабирования окна можно установить с 0 (без переноса) до 14.3

Истинный размер окна = 524280

Следующий след сетевого монитора показывает, как используется параметр масштабирования окна:

TCP: ....S., len:0, seq:725163-725163, ack:0, win:65535, src:1217 dst:139(NBT Session)  
TCP: Source Port = 0x04C1  
TCP: Destination Port = NETBIOS Session Service  
TCP: Sequence Number = 725163 (0xB10AB)  
TCP: Acknowledgement Number = 0 (0x0)  
TCP: Data Offset = 44 (0x2C)  
TCP: Reserved = 0 (0x0000)  
+ TCP: Flags = 0x02 : ....S.  
TCP: Window = 65535 (0xFFFF)  
TCP: Checksum = 0x8565  
TCP: Urgent Pointer = 0 (0x0)  
TCP: Options  
+ TCP: Maximum Segment Size Option  
TCP: Option Nop = 1 (0x1)  
TCP: Window Scale Option  
TCP: Option Type = Window Scale  
TCP: Option Length = 3 (0x3)  
TCP: Window Scale = 3 (0x3)  
TCP: Option Nop = 1 (0x1)  
TCP: Option Nop = 1 (0x1)  
+ TCP: Timestamps Option  
TCP: Option Nop = 1 (0x1)  
TCP: Option Nop = 1 (0x1)  
+ TCP: SACK Permitted Option  

Размер окна, используемый в фактическом трехшаговом рукопожатии, не является масштабным размером окна в разделе 2.2 RFC 1323:

«Поле Окно в syn (например, сегмент [SYN] или [SYN,ACK]) никогда не масштабируется».

Это означает, что первый пакет данных, отправленный после трехнаправного рукопожатия, является фактическим размером окна. Если есть фактор масштабирования, всегда используется начальный размер окна в 65 535 bytes. Затем размер окна умножается на коэффициент масштабирования, идентифицированный в трехшаговом рукопожатии. В таблице ниже представлены границы коэффициента масштабирования для различных размеров окна.

Фактор масштабирования Масштабное значение Начальное окно Масштабировать окно
0 1 65535 или менее 65535 или менее
1 2 65535 131,070
2 4 65535 262,140
3 8 65535 524,280
4 16 65535 1,048,560
5 32 65535 2,097,120
6 64 65535 4,194,240
7 128 65535 8,388,480
8 256 65535 16,776,960
9 512 65535 33,553,920
10 1024 65535 67,107,840
11 2048 65535 134,215,680
12 4096 65535 268,431,360
13 8192 65535 536,862,720
14 16384 65535 1,073,725,440

Например:

Если размер окна в реестре вошел как 2690000000 (269M) в десятичной, то коэффициент масштабирования при трехстолевом рукопожатии составляет 13.13
True window size = 536,862,720

Когда значение для размера окна добавляется в реестр и его размер превышает значение по умолчанию, Windows использовать значение масштабирования, которое вмещает новый размер окна.

Значение Tcp1323Opts в следующем ключе реестра можно добавить для управления масштабированием окон и временем:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters

  1. На панели инструментов выберите Запуск запуска и введите для > Regedit запуска редактора реестра.

  2. В редакторе реестра выберите Изменить, указать на Новое, а затем выбрать значение DWORD.

  3. В поле «Новое значение» введите кнопку ВВОД, а затем в Tcp1323Opts меню Изменить выберите Изменение.

    Примечание

    Допустимый диапазон: 0, 1, 2 или 3, где:
    0 (отключить параметры RFC 1323)
    1 (только включена шкала окна)
    2 (только включено время)
    3 (включено оба варианта)

Эта запись реестра управляет 1323 разами RFC и параметрами масштабирования окон. Время и масштабирование окна включены по умолчанию, но ими можно управлять с помощью битов флага. Bit 0 управляет масштабированием окон. Bit 1 управляет временем.

Timestamps

Ранее в Стеке TCP/IP использовался один пример на окно данных, отправленных для вычисления времени в пути (RTT). При отправлении пакета был задат timer (retransmit timer) до тех пор, пока не будет получено подтверждение. Например, если размер окна в сети Ethernet составляет 64 240 bytes (44 полных сегмента), для пересчета времени в обратном пути использовался только один из 44 пакетов. С максимальным размером окна 65 535 bytes, этого коэффициента выборки было достаточно. С помощью масштабирования окна и максимального размера окна в 1 гигабайт этот показатель выборки RTT является недостаточным.

Теперь параметр TCP Timestamp можно использовать в сегментах (данные и ACK), которые считаются подходящими для стека, для операций, таких как:

  • Вычисление RTT
  • Проверка PAWS

С помощью этих данных RTT можно точно рассчитать с помощью больших размеров окна. RTT используется для вычисления интервалов ретрансмиссии. Для оптимальной пропускной способности необходимы точные перерывы в RTT и ретрансмиссии.

Когда в сеансе TCP используется штамп времени TCP, отправитель сеанса отправляет параметр в своем первом пакете трехсторонней рукопожатия TCP (пакет SYN). Затем любая сторона может использовать параметр TCP во время сеанса.

TCP Timestamps Option (TSopt):

Вид = 8 Длина = 10 TS Value (Tsval) TS Echo Reply (Tsecr)
1 байт 1 байт 4 байта 4 байта

Поле параметра timestamp можно просмотреть в следе сетевого монитора, расширив поле параметров TCP, как показано ниже:

TCP: Timestamps Option  
TCP: Option Type = Timestamps  
TCP: Option Length = 10 (0xA)  
TCP: Timestamp = 2525186 (0x268802)  
TCP: Reply Timestamp = 1823192 (0x1BD1D8)

Защита от завернутой последовательности номеров (PAWS)

Поле номеров последовательности TCP ограничено 32 битами, что ограничивает количество доступных номеров последовательности. С высокой пропускной способностью сетей и большой передачи данных, можно обернуть номера последовательности, прежде чем пакет проходит по сети. Если отправлять данные по одной сети Giga-byte в секунду (Gbps), номера последовательности могут обертывание всего за 34 секунды. Если пакет задерживается, потенциально может существовать другой пакет с одинаковым номером последовательности. Чтобы избежать путаницы с дублирующими номерами последовательности, timestamp TCP используется в качестве расширения к номеру последовательности. Пакеты имеют текущие и прогрессивные отметки времени. Старый пакет имеет более старый штамп времени и удаляется.

Селективные подтверждения (SACKs)

Windows представляет поддержку функции производительности, известной как Селективное подтверждение или SACK. SACK особенно важен для подключений с большими размерами окна TCP. Перед SACK приемник мог подтвердить только последний номер последовательности полученного потока данных или «левый край» окна получения. С включенной поддержкой SACK приемник продолжает использовать номер ACK для подтверждения левого края окна получения, но он также может признавать другие блоки полученных данных по отдельности. SACK использует параметры загона TCP, как показано ниже.

SACK использует два типа TCP Options.

Параметр TCP Sack-Permitted используется только в пакете SYN (во время создания подключения TCP), чтобы указать, что он может делать выборочный ACK.

Второй параметр TCP — TCP Sack Option — содержит подтверждение для одного или нескольких блоков данных. Блоки данных идентифицированы с помощью номера последовательности в начале и в конце этого блока данных. Он также известен как левый и правый край блока данных.

Kind 4 — это параметр TCP Sack-Permitted. Вид 5 — это параметр TCP Sack. Длина — это длина в bytes этого параметра TCP.

Tcp SACK разрешено:

Вид = 4 Длина = 2
1 байт 1 байт

Параметр Tcp SACK:

Вид = 5 Длина = переменная
1 байт Левый край первого блока до правого края первого блока

Левый край блока Nth к правому краю блока Nth

С включенной поддержкой SACK (по умолчанию) пакет или серия пакетов могут быть отброшены. Приемник сообщает отправителю, какие данные получены и где могут быть «дыры» в данных. Затем отправитель может выборочно перенаправить недостающие данные без повторной передачи уже успешно полученных блоков данных. SACK контролируется параметром реестра SackOpts.

Значение SackOpts в следующем ключе реестра можно изменить, чтобы контролировать использование селективных подтверждений:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

  1. На панели инструментов выберите Запуск запуска и введите для > Regedit запуска редактора реестра.
  2. Найдите и выберите вышеуказанный ключ в редакторе реестра, а затем выберите Изменение в меню Редактирование.
  3. Введите нужное значение в поле данных Value.

Примечание

Допустимо двоичное значение — 0 или 1, по умолчанию — 1. Этот параметр контролирует, включена ли поддержка селективного ACK (SACK — RFC 2018).

Следующий след сетевого монитора показывает, как хост подтверждает все данные до номера последовательности 54857341, а также данные из последовательности номер 54858789-54861685. Отсутствующие данные от 54857341 до 54858788.

TCP: .A...., len:0, seq:925104-925104, ack:54857341, win:32722, src:1242 dst:139  
TCP: Source Port = 0x04DA  
TCP: Destination Port = NETBIOS Session Service  
TCP: Sequence Number = 925104 (0xE1DB0)  
TCP: Acknowledgement Number = 54857341 (0x3450E7D)  
TCP: Data Offset = 44 (0x2C)  
TCP: Reserved = 0 (0x0000)  
+ TCP: Flags = 0x10 : .A....  
TCP: Window = 32722 (0x7FD2)  
TCP: Checksum = 0x4A72  
TCP: Urgent Pointer = 0 (0x0)  
TCP: Options  
TCP: Option Nop = 1 (0x1)  
TCP: Option Nop = 1 (0x1)  
+ TCP: Timestamps Option  
TCP: Option Nop = 1 (0x1)  
TCP: Option Nop = 1 (0x1)  
TCP: SACK Option  
TCP: Option Type = 0x05  
TCP: Option Length = 10 (0xA)  
TCP: Left Edge of Block = 54858789 (0x3451425)  
TCP: Right Edge of Block = 54861685 (0x3451F75)

Поведение ретрансмиссии TCP и быстрая перетрансмиссия

Ретрансмиссия TCP

В качестве обзора нормального поведения ретрансмиссии TCP запускает ретрансмиссию, когда каждый исходящие сегменты передаются в Протокол Интернета (IP). Если подтверждения данных в данном сегменте до истечения срока действия времени не получено, сегмент повторно передается.

Время перерасчета (RTO) непрерывно корректируется в соответствие с характеристиками подключения с помощью расчетов Сглаженное время в пути (SRTT), как описано в RFC 793. После каждой повторной передачи этого сегмента время от времени для данного сегмента удваивается. С помощью этого алгоритма TCP настраивает себя на нормальную задержку подключения.

Быстрый перетрансмит

TCP повторно передает данные до истечения срока действия времени ретрансмиссии при некоторых обстоятельствах. Наиболее распространенной причиной является функция, известная как быстрая перенаторка. Когда приемник, который поддерживает быстрый перетрансмит, получает данные с номером последовательности, превысят текущий ожидаемый, некоторые данные, скорее всего, будут отброшены. Чтобы сообщить отправительу об этом событии, приемник немедленно отправляет ACK с номером ACK на ожидаемом номере последовательности. Он будет продолжать делать это для каждого дополнительного сегмента TCP, который приходит. Когда отправитель начинает получать поток acKs с одним и тем же номером последовательности, сегмент может быть отброшен. Отправитель немедленно повторно отправляет сегмент, который ожидает приемник, не дожидаясь истечения срока действия времени ретрансмиссии. Эта оптимизация значительно повышает производительность при частом сбросе пакетов.

По умолчанию Windows в следующих условиях:

  • Он получает три acKs для одного номера последовательности: один ACK и два дубликата.
  • Номер последовательности отстает от текущего.

Это поведение можно контролировать с помощью TcpMaxDupAcks параметра реестра.

Значение TcpMaxDupAcks в следующем ключе реестра можно изменить, чтобы контролировать количество acKs, необходимых для запуска быстрых переадтрансмитов:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

  1. На панели инструментов выберите Запуск запуска и введите для > Regedit запуска редактора реестра.
  2. Найдите и выберите вышеуказанный ключ в редакторе реестра, а затем выберите Изменение в меню Редактирование.
  3. Введите нужное значение в поле данных Value.

Примечание

Допустимый диапазон 1-3, значение по умолчанию — 2.

Этот параметр определяет количество дубликатов acKs, которые должны быть получены для того же количества отправленных данных последовательности, прежде чем запускается для повторного повторного запуска сегмента, который был отброшен fast retransmit в пути.

В поисках утерянного гигабита или немного про окна в TCP / Хабр

Поводом для написания этой статьи послужила лень, которая, как известно, двигатель прогресса и свидетель появления на свет невероятно облегчающих жизнь вещей.

В моём случае это была лень объяснять в тысячный раз клиенту, почему он арендовал канал точка-точка и в договоре чёрным по белому написано Ethernet 1Гбит/с, а он как ни измеряет, но чуть-чуть да меньше получается.

Где остальное? Почему недобор? Куда девался интернет из провода? А может его и вовсе страшно обманули?

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


Важно

Если вы сетевой инженер, то не читайте эту статью. Она оскорбит все ваши чувства т.к. написана максимально простым и доступным языком с множеством упущений.


История про окна. Мир до окон

Итак, чтобы понять, где скорость, нам придётся разобраться в том, как работает TCP в плане обеспечения надежности соединения.

Как нам всем известно, у ТСР есть финт последней надежды, когда все ухищрения доставить кадр до получателя не сработали, он просто заново отправляет испорченный или утерянный кадр.

Как это выглядит в простейшем случае:


  • Кадр отправляется передатчиком. На передатчике включается таймер, в течении которого от получателя должно быть получено подтверждение АСК об успешном получении кадра или явное указание, что кадр был испорчен/утерян в пути — NACK
  • Если по истечении таймера АСК не получен, пакет отправляется ещё раз
  • Если приходит NACK, источник повторяет отправку кадра
  • А если АСК получен, источник отправляет следующий кадр

Графически этот алгоритм легко представляется на временной шкале:

Называется этот алгоритм методом простоя источника, что сразу даёт нам понять его главный минус: катастрофически неэффективное использование канала связи. Технически, ничего не мешает передатчику сразу после отправки первого кадра отправлять второй, но мы принуждаем его ждать прихода ACK/NACK или истечения таймера.

Поэтому важно понимать, что процессы отправки и получения ACKов могут идти независимо друг от друга. На этой идее и был рождён метод скользящего окна.


Окно первое. Скользящее. Теоретическое.

После осознания минусов предыдущего метода, в голову приходит идея разрешить источнику передавать пакеты в максимально возможном для него темпе, без ожидания подтверждения от приёмника. Но не бесконечное их количество, а ограниченное неким буфером, который называется окном, а его размер указывает на количество кадров которое разрешено передать без ожидания подтверждений.

Вернёмся к картинкам:

Для наглядности рассмотрим окно размером К кадров, в котором находятся пакеты (1…N) в некий момент времени, т.е. у нас была отправлена пачка кадров, каждый кадр по мере своей возможности достиг получателя, тот их обработал и отправил подтверждение для каждого.

Теперь усложняем ситуацию, включив время.

В момент прихода АСК на первый кадр, последний ещё не был даже отправлен, но поскольку мы знаем об успешности доставки, в окно можно добавить следующий по порядку кадр, т.е. окно сдвигается и теперь включает в себя кадры 2…N+1. Когда приходит ACK на 2-й кадр, окно снова сдвигается: 3…N+2. И так далее. Получается, что окно как-бы «скользит» по потоку пакетов. Или пакеты через него, тут кому как удобней представлять.

Таким образом, все кадры глобально делятся на три вида:


  • Прошлое.Были отправлены, были получены подтверждения
  • Суровое настоящее. Состоит из отправленных кадров, но без полученных подтверждений и тех, кто уже в окне, но стоит в очереди на отправку
  • Светлое будущее. Кадры в очереди на попадание в окно.

И как это влияет на скорость связи? – спросите вы.

Как мы видим из графика, необходимым условием для максимальной утилизации канала связи является регулярное поступление подтверждений в рамках действия окна. АСК не обязаны приходить в чётком порядке, главное чтобы АСК на первый кадр в окне пришёл раньше, чем будет отправлен последний кадр, иначе сработает таймер неответа, кадр будет отправлен заново, а движение окна прекратится.

Также, стоит отметить, что в большинстве реализаций алгоритма скользящего окна, подтверждения приходят не на каждый пакет, а сразу на всю принятую пачку (называется Selective Ack). Это позволяет ещё больше увеличить эффективную утилизацию канала за счёт снижения объёма служебной информации.

Итак, что же мы имеем в сухом остатке? Какие параметры имеют существенное влияние на эффективность передачи данных между двумя точками?

Их два:


  • Размер окна, который выбирается меньшим из двух: окно, объявленное получателем (размер его буфера) или CWND — размер, определяемый отправителем на основе RTT
  • Само RTT: время приёма-передачи, равное времени, затраченному на отправку сигнала, плюс время необходимое для подтверждения о приёме.

И мы не должны передать больше, чем готов принять получатель или пропустить сеть.

Давайте представим, что у нас супер надёжная сеть, где пакеты практически никогда не теряются и не бьются. В такой сети нам выгодно иметь окно максимально возможного размера, что позволит нам минимизировать паузы между отправкой кадров.

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

И как нам всем известно, реальность — это смесь двух крайних случаев, поэтому в реальной сети размер окна величина переменная. Причём он может быть изменён, как в одностороннем порядке на любой стороне, так и по согласованию.

Промежуточное резюме. Как мы видим, даже без привязки к конкретным протоколам, чисто технически крайне сложно утилизировать канал на все 100%, т.к. хотим мы того или нет, но даже в лабораторных условиях между кадрами будут минимальные, но задержки, которые и не дадут нам достичь заветных 100% утилизации полосы пропускания.

А что уж говорить про реальные сети? Вот во второй части мы и рассмотрим одну из реализаций на примере TCP.


Окно второе. Реализация в TCP

Чем замечателен ТСР? На основе ненадёжных дейтаграмм IP, он позволяет обеспечить надежную доставку сообщений.

При установлении логического соединения модули ТСР обмениваются между собой следующими параметрами:


  • Размер буфера получателя — это верхнее ограничение размера окна
  • Начальный порядковый номер байта, с которого начнётся отсчёт потока данных в рамках этой сессии

Сразу запоминаем важную особенность — в ТСР окно оперирует не количеством кадров, а количеством байт. Это значит, что окно представляет из себя множество нумерованных байт неструктурированного потока данных от верхних протоколов. Звучит громоздко, но проще написать не получается.

Итак, ТСР протокол дуплексный, а значит каждая сторона в любой момент времени выступает и как отправитель, и как получатель. Следовательно с каждой стороны должен быть буфер для приёма сегментов и буфер для ещё не отправленных сегментов. Но кроме того, должен быть ещё и буфер для копий уже отправленных сегментов, на которые ещё не получили подтверждения о приёме.

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

В такой ситуации пляска ведётся от возможностей получателя. При установлении соединения, обе стороны высылают друг другу окна приёма. Получатель запоминает его размер и понимает сколько байт можно отправить, не дожидаясь АСК.

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

Пара слов про буфер копий на отправителе. У всех сегментов, лежащих в этом буфере, работает таймер. Если за время таймера приходит соответствующий АСК, сегмент удаляется. Если нет — отправляется заново. Возможна такая ситуация, что по таймеру сегмент будет отправлен ещё раз до того, как придёт АСК, но в этом случае повторный сегмент просто будет отброшен получателем.

И вот от этого тайм-аута на ожидание и зависит производительность ТСР. Будет слишком короткий — появятся избыточные переотправки пакетов. Слишком длинный — получим простои из-за ожидания несуществующих АСК.

На самом деле ТСР определяет размер тайм-аута по сложному адаптивному алгоритму, где учитываются скорость, надежность, протяжённость линии и множество других факторов. Но в общих чертах он таков:


  • При отправке каждого сегмента замеряется время до прихода АСК.
  • Получаемые значения усредняются с весовыми коэффициентами, возрастающими от прошлого к будущему. Это позволяет более новым данным оказывать большее влияние на итоговый результат.
  • Затем считается среднее значение от усреднений на предыдущем шаге и получается величина таймаута.Но если разброс величин очень велик, то учитывается ещё и дисперсия.

Но что-то мы всё больше про окно отправки, хотя окно приёма представляет из себя более интересную сущность. На разных концах соединения окна, обычно, имеют разный размер. В мире победивших клиент-серверных технологий, не приходится ожидать, что клиент будет готов оперировать окном того же размера, который может обрабатывать сервер.

Точно так же размер его может меняться динамически, в зависимости от состояния сети, но здесь неправильный выбор подразумевает уже “двойную” ответственность. В случае получения данных бОльших, чем может обработать ТСР модуль, они будут отброшены, на источнике сработает таймер, он переотправит данные, они опять не попадут в размер окна и т.д.

С другой стороны, установка слишком маленького окна приведёт к использованию канала на скорости равной скорости передачи одного сегмента.Поэтому разработчики ТСР предложили схему, в которой при установлении соединения размер окна устанавливается относительно большим и в случае проблем начинает сокращаться в два раза за шаг. Это действительно выглядит странно, поэтому были созданы реализации ТСР повторяющие привычную нам логику: начать с малого окна и, если сеть справляется, то начать его увеличивать.

Но на размер окна приёма может влиять не только принимающая сторона, но и отправитель данных. Если мы видим, что АСК регулярно приходят позже таймеров, что приходится часто переотправлять сегменты, то источник может выставить своё значение окна приёма и будет действовать правило наименьшего — будет принято самое маленькое значение, кто бы его ни назначил.

Остаётся рассмотреть ещё один вариант развития событий, а именно перегрузку ТСР-соединения. Это состояние сети характеризуется тем, что на на промежуточных и оконечных узлах возникают очереди пакетов. В данном случае у приёмника есть два варианта:


  • Уменьшить размер окна.
  • Совсем отказаться от приёма, установив размер окна, равный нулю.

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


Итого

Капитан подсказывает — если одна TCP сессия в принципе не может обеспечивать 100% утилизацию канала, то используй две. Если мы говорим про клиента, который взял в аренду канал точка-точка и поднял в нём GRE туннель, то пусть поднимет второй. Дабы они не дрались за полосу, заворачиваем в первый важный трафик, во второй — всякую ерунду и страшно зарезаем ему скорость. Этого как раз хватит на то, чтобы выбрать остатки полосы, которую первая сессия не может взять чисто технически.

TCP размер окна (для чего?)

Продолжаю тему про протокол TCP, на мой взгляд есть весьма интересная информация об этом протоколе – размер окна. Наверняка много раз слышали или встречали это понятие, но как понять что же это такое? Попробую объяснить доступно.

Для начала советую ещё раз ознакомиться со статьей про установку TCP соединения.

Так вот, когда соединение уже установлено, клиент должен послать подтверждение о приёмке. В противном случае будет считаться, что пакет не получен и требуется переотправка. А теперь представим ситуацию, что передать нужно большой файл, который не влезет целиком в MTU. Файл будет отправляться “кусками”, которые будут собираться на клиенте в один файл. Внимание. А подтверждения нужно посылать после каждого куска? Оказывается, можно посылать подтверждения сразу за несколько пакетов, что здорово экономит обратный трафик и ускоряет передачу (не нужно ждать каждый раз ответа), тут каждый раз учитывается время прохождения пакета в сети (дважды, причём).

Этот параметр и называется размер окна. Количество сегментов(байт), которые могут быть приняты без подтверждения. Подтверждение же, при переполнении окна, высылается сразу за все предыдущие пакеты.

В примере ниже размер окна = 3. То есть подтверждение приёма посылается после каждого 3-го пакета. Полученное подтверждение означает, что все пакеты до этого номера были получены.

TCP Window

Перед началом обмена получатель и отправитель договариваются о размере своих окон.

Кроме того, размер окна может динамически меняться, что может быть вызвано проблемами с каналом (высокая загрузка сети), вплоть до установки размера в 0, что прекращает дальнейший приём до тех пор, пока не будет послано другое значение размера окна.

Вот пример:

Плавающий размер окна

После того, как были отправлены 3 сегмента, получатель отправил пакет с ACK 3, (а не 4, как в предыдущем примере), то есть повторная передача сегмента 3 потребовалась, в то же время был отправлен размер окна 2. Отправитель получив ACK 3 будет отправлять сегменты начиная с 3-го, в количестве 2 штук (размер окна получателя).

Из-за чего мог возникнуть подобный сбой? Да что угодно, лавинный флуд канала, отчего пакет не пришел в установленный временной интервал. В случае таких сбоев предусмотрено так называемое Congestion Window Size (размер окна перегрузки), который обычно равен размеру окна получателя, но в случае обнаружения подобных проблем с доставкой, уменьшается вдвое, регулируя таким образом оптимальный объем передачи.

Прикольный процесс, не так ли? Но бывает ситуация, когда такая синхронизация размеров окон перегрузки начинает образовывать волны перегрузок. Все клиенты в сети, встретив “затык”, уменьшают своё окно и пропускная способность канала возрастает. Они, видя это, вновь увеличивают окна (одновременно), и вновь образуется “пробка”. Вот такие скачкообразные колебания трафика в сети и называются глобальной синхронизацией TCP – есть негативный процесс.

 

Нулевое окно в TCP — Русские Блоги

	Zero Window is something to investigate.
	
	TCP Zero Window is when the Window size in a machine remains at zero for a specified 
amount of time.

	This means that a client is not able to receive further information at the moment, and the 
TCP transmission is halted until it can process the information in its receive buffer.
	TCP Window size is the amount of information that a machine can receive during a TCP 
session and still be able to process the data. Think of it like a TCP receive buffer. When a 
machine initiates a TCP connection to a server, it will let the server know how much data it 
can receive by the Window Size.

	In many Windows machines, this value is around 64512 bytes. As the TCP session is 
initiated and the server begins sending data, the client will decrement it's Window Size as 
this buffer fills. At the same time, the client is processing the data in the buffer, and is 
emptying it, making room for more data. Through TCP ACK frames, the client informs the 
server of how much room is in this buffer. If the TCP Window Size goes down to 0, the 
client will not be able to receive any more data until it processes and opens the buffer up 
again. In this case, Protocol Expert will alert a "Zero Window" in Expert View.

	Troubleshooting a Zero Window For one reason or another, the machine alerting the Zero 
Window will not receive any more data from the host. It could be that the machine is running 
too many processes at that moment, and its processor is maxed. Or it could be that there is 
an error in the TCP receiver, like a Windows registry misconfiguration. Try to determine 
what the client was doing when the TCP Zero Window happened.

Перевод:

	Нулевое окно заслуживает изучения. 
	 Нулевое окно TCP относится к времени, в течение которого размер окна в машине остается нулевым в течение определенного времени.
	 Это означает, что клиент не может получить больше информации в это время, и передача TCP будет приостановлена ​​до тех пор, пока он не сможет обработать задержку приема.
 Информация в зоне стирки.
	 Размер окна TCP - это объем информации, который компьютер может получить во время сеанса TCP и по-прежнему иметь возможность обрабатывать данные. Жестяная банка
 Думайте об этом как о буфере приема TCP. Когда машина инициирует TCP-соединение с сервером, она сообщает серверу об этом.
 Сколько данных можно получить по размеру окна.
	 На многих компьютерах с Windows это значение составляет примерно 64512 байт. Когда запускается сеанс TCP и сервер начинает отправлять данные
 Когда этот буфер заполнен, клиент уменьшит размер своего окна. В то же время клиент обрабатывает данные в буфере,
 И очистите его, чтобы освободить место для дополнительных данных. Через кадр TCP ACK клиент сообщает серверу, сколько в этом буфере
 пространство. Если размер окна TCP упадет до 0, клиент не сможет получать больше данных, пока они не будут обработаны и снова открыты.
 Буфер. В этом случае Protocol Expert будет напоминать «нулевое окно» в экспертном обзоре.
	 Устранение неполадок с нулевым окном. По той или иной причине машина, запрашивающая нулевое окно, больше не будет получать никаких данных от хоста.
 в соответствии с. Возможно, в то время машина выполняла слишком много процессов, а ее процессор был самым большим. Или может TCP получить
 Ошибка устройства, например ошибка конфигурации в реестре Windows. Попытайтесь определить, когда возникает нулевое окно TCP, когда клиент
 что делать.

Приемник ограничивает размер окна TCP до 64,512

Факты (пожалуйста, укажите любые ложные утверждения):

  1. У меня есть соединение 100 Мбит / с между двумя сайтами, которые находятся на расстоянии 80 мс

  2. Это длинное толстое соединение, которое может выиграть от большого размера окна TCP, возможно, до 100 Мбит / с * 0,08 сек = 1 000 000 байт

  3. Обе машины работают под управлением Windows Server 2012. «Уровень автоматической настройки окна приема» является нормальным для обеих систем. «Эвристика масштабирования окна» отключена на обоих.

  4. Я запустил «iperf -s» с одной стороны и «iperf -c» с другой. Передача произошла со скоростью 5 Мбит / с. Я получаю тот же результат в другом направлении.

  5. Обе стороны объявили о поддержке раздвижных окон TCP в своих SYN.

  6. Получатель запросил размер окна TCP 64,512 байт (0xFC00) в течение всего цикла со значением масштаба окна TCP «без сдвига» (0x000).

  7. Сеть смогла обработать окно большего размера (см. Схемы последовательности ниже)

  8. Приемник держал окно меньше, чем поддерживает сеть

  9. Это соединение происходит в IPSEC VPN. MTU интерфейса туннеля уменьшается до 1400 байтов в обоих направлениях.

Вопрос

  • Почему приемник держит окно маленьким?

Non-ответы

  • Сеть сломана

    Машины Linux, работающие в одной сети, открывают окно TCP до 1,5 мегабайт и передают данные с 6-кратной пропускной способностью

  • Эвристика масштабирования окна включена

    Эвристика масштабирования окна отключена (см. Вывод «эвристики netsh interface tcp show» ниже)

  • Уровень автоматической настройки окна получения не является нормальным

    Уровень автонастройки окна получения является нормальным (см. Вывод «netsh interface tcp show global» ниже)

  • Это просто не работает на виртуальной машине в ESXi

    Я получаю в 6 раз лучшую производительность на виртуальной машине Linux, работающей на том же хосте.


Обновление от 1 июня 12, 2015, 16:30 PDT

Я изменил тест, поместив linux на одну сторону соединения. Конечно, когда linux отправляет данные в Windows Server 2012, Windows предлагает слишком маленькое окно приема TCP (64 512 байт).

Когда я отправляю данные из Windows в Linux, Linux предлагает достаточно большое окно приема TCP (1 365 120 байтов). Тем не менее, Windows ограничивает отправку до ~ 60000 байт в полете.


Обновление 2 июня 13, 2015 15:00 PDT

На шаг ближе к основной причине. В моей настройке ни SO_SNDBUF, ни SO_RCVBUF не установлены (по iperf). Это буферы отправки и получения, которые эффективно ограничивают окно приема. Если эти значения не указаны, Windows Server 2012 предоставляет значение по умолчанию 64 КБ. Итак, вопрос сейчас:

Вопрос

  • Если один из них не указан, почему Windows Server 2012 не динамически увеличивает SO_SNDBUF / SO_RCVBUF для размещения длинных толстых каналов, как описано в MSDN ?

Non-ответы


Обновление 3 августа 24, 2015 16:00 PDT

netsh, видимо, был заменен на Set-NetTCPSetting и семейство. Get-NetTCPSetting в сочетании с Get-NetTCPConnection показывает, что я работаю в режиме «Интернет», который предлагает мне следующие настройки:

SettingName                   : Internet
MinRto(ms)                    : 300
InitialCongestionWindow(MSS)  : 4
CongestionProvider            : CTCP
CwndRestart                   : False
DelayedAckTimeout(ms)         : 50
MemoryPressureProtection      : Enabled
AutoTuningLevelLocal          : Normal
AutoTuningLevelGroupPolicy    : NotConfigured
AutoTuningLevelEffective      : Local
EcnCapability                 : Enabled
Timestamps                    : Disabled
InitialRto(ms)                : 3000
ScalingHeuristics             : Disabled
DynamicPortRangeStartPort     : 49152
DynamicPortRangeNumberOfPorts : 16384

Настройки TCP отправителя

PS C:\Users\acs> 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                      : enabled
RFC 1323 Timestamps                 : disabled
Initial RTO                         : 3000
Receive Segment Coalescing State    : enabled

PS C:\Users\acs> netsh interface tcp show heuristics
TCP Window Scaling heuristics Parameters
----------------------------------------------
Window Scaling heuristics         : disabled
Qualifying Destination Threshold  : 3
Profile type unknown              : normal
Profile type public               : normal
Profile type private              : normal
Profile type domain               : normal

PS C:\Users\acs> Get-NetTCPSetting

SettingName                   : Automatic
MinRto(ms)                    : 
InitialCongestionWindow(MSS)  : 
CongestionProvider            : 
CwndRestart                   : 
DelayedAckTimeout(ms)         : 
MemoryPressureProtection      : 
AutoTuningLevelLocal          : 
AutoTuningLevelGroupPolicy    : 
AutoTuningLevelEffective      : 
EcnCapability                 : 
Timestamps                    : 
InitialRto(ms)                : 
ScalingHeuristics             : 
DynamicPortRangeStartPort     : 
DynamicPortRangeNumberOfPorts : 

SettingName                   : Custom
MinRto(ms)                    : 20
InitialCongestionWindow(MSS)  : 4
CongestionProvider            : DCTCP
CwndRestart                   : True
DelayedAckTimeout(ms)         : 10
MemoryPressureProtection      : Enabled
AutoTuningLevelLocal          : Normal
AutoTuningLevelGroupPolicy    : NotConfigured
AutoTuningLevelEffective      : Local
EcnCapability                 : Enabled
Timestamps                    : Disabled
InitialRto(ms)                : 3000
ScalingHeuristics             : Disabled
DynamicPortRangeStartPort     : 49152
DynamicPortRangeNumberOfPorts : 16384

SettingName                   : Compat
MinRto(ms)                    : 300
InitialCongestionWindow(MSS)  : 2
CongestionProvider            : Default
CwndRestart                   : False
DelayedAckTimeout(ms)         : 200
MemoryPressureProtection      : Enabled
AutoTuningLevelLocal          : Normal
AutoTuningLevelGroupPolicy    : NotConfigured
AutoTuningLevelEffective      : Local
EcnCapability                 : Enabled
Timestamps                    : Disabled
InitialRto(ms)                : 3000
ScalingHeuristics             : Disabled
DynamicPortRangeStartPort     : 49152
DynamicPortRangeNumberOfPorts : 16384

SettingName                   : Datacenter
MinRto(ms)                    : 20
InitialCongestionWindow(MSS)  : 4
CongestionProvider            : DCTCP
CwndRestart                   : True
DelayedAckTimeout(ms)         : 10
MemoryPressureProtection      : Enabled
AutoTuningLevelLocal          : Normal
AutoTuningLevelGroupPolicy    : NotConfigured
AutoTuningLevelEffective      : Local
EcnCapability                 : Enabled
Timestamps                    : Disabled
InitialRto(ms)                : 3000
ScalingHeuristics             : Disabled
DynamicPortRangeStartPort     : 49152
DynamicPortRangeNumberOfPorts : 16384

SettingName                   : Internet
MinRto(ms)                    : 300
InitialCongestionWindow(MSS)  : 4
CongestionProvider            : CTCP
CwndRestart                   : False
DelayedAckTimeout(ms)         : 50
MemoryPressureProtection      : Enabled
AutoTuningLevelLocal          : Normal
AutoTuningLevelGroupPolicy    : NotConfigured
AutoTuningLevelEffective      : Local
EcnCapability                 : Enabled
Timestamps                    : Disabled
InitialRto(ms)                : 3000
ScalingHeuristics             : Disabled
DynamicPortRangeStartPort     : 49152
DynamicPortRangeNumberOfPorts : 16384

Отправитель SYN

No.     Time           Source                Destination           Protocol Length Delta      Sequence number Acknowledgment number Bytes in flight Calculated window size Info
    814 5.036577000    10.10.0.21            10.11.0.1             TCP      66     0.000000000 0               0                                     64512                  49758→5001 [SYN, ECN, CWR] Seq=0 Win=64512 Len=0 MSS=1460 WS=1 SACK_PERM=1

Frame 814: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) on interface 0
Ethernet II, Src: 00:11:22:33:44:55, Dst: aa:bb:cc:dd:ee:ff
Internet Protocol Version 4, Src: 10.10.0.21 (10.10.0.21), Dst: 10.11.0.1 (10.11.0.1)
Transmission Control Protocol, Src Port: 49758 (49758), Dst Port: 5001 (5001), Seq: 0, Len: 0
    Source Port: 49758 (49758)
    Destination Port: 5001 (5001)
    [Stream index: 73]
    [TCP Segment Len: 0]
    Sequence number: 0    (relative sequence number)
    Acknowledgment number: 0
    Header Length: 32 bytes
    .... 0000 1100 0010 = Flags: 0x0c2 (SYN, ECN, CWR)
    Window size value: 64512
    [Calculated window size: 64512]
    Checksum: 0x1451 [validation disabled]
    Urgent pointer: 0
    Options: (12 bytes), Maximum segment size, No-Operation (NOP), Window scale, No-Operation (NOP), No-Operation (NOP), SACK permitted
        Maximum segment size: 1460 bytes
        No-Operation (NOP)
        Window scale: 0 (multiply by 1)
            Kind: Window Scale (3)
            Length: 3
            Shift count: 0
            [Multiplier: 1]
        No-Operation (NOP)
        No-Operation (NOP)
        TCP SACK Permitted Option: True

Перспектива отправителя графа последовательности

Настройки TCP получателя

PS C:\Users\acs> 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                      : enabled
RFC 1323 Timestamps                 : disabled
Initial RTO                         : 3000
Receive Segment Coalescing State    : enabled

PS C:\Users\acs> netsh interface tcp show heuristics
TCP Window Scaling heuristics Parameters
----------------------------------------------
Window Scaling heuristics         : disabled
Qualifying Destination Threshold  : 3
Profile type unknown              : normal
Profile type public               : normal
Profile type private              : normal
Profile type domain               : normal

PS C:\Users\acs> Get-NetTCPSetting

SettingName                   : Automatic
MinRto(ms)                    : 
InitialCongestionWindow(MSS)  : 
CongestionProvider            : 
CwndRestart                   : 
DelayedAckTimeout(ms)         : 
MemoryPressureProtection      : 
AutoTuningLevelLocal          : 
AutoTuningLevelGroupPolicy    : 
AutoTuningLevelEffective      : 
EcnCapability                 : 
Timestamps                    : 
InitialRto(ms)                : 
ScalingHeuristics             : 
DynamicPortRangeStartPort     : 
DynamicPortRangeNumberOfPorts : 

SettingName                   : Custom
MinRto(ms)                    : 20
InitialCongestionWindow(MSS)  : 4
CongestionProvider            : DCTCP
CwndRestart                   : True
DelayedAckTimeout(ms)         : 10
MemoryPressureProtection      : Enabled
AutoTuningLevelLocal          : Normal
AutoTuningLevelGroupPolicy    : NotConfigured
AutoTuningLevelEffective      : Local
EcnCapability                 : Enabled
Timestamps                    : Disabled
InitialRto(ms)                : 3000
ScalingHeuristics             : Disabled
DynamicPortRangeStartPort     : 49152
DynamicPortRangeNumberOfPorts : 16384

SettingName                   : Compat
MinRto(ms)                    : 300
InitialCongestionWindow(MSS)  : 2
CongestionProvider            : Default
CwndRestart                   : False
DelayedAckTimeout(ms)         : 200
MemoryPressureProtection      : Enabled
AutoTuningLevelLocal          : Normal
AutoTuningLevelGroupPolicy    : NotConfigured
AutoTuningLevelEffective      : Local
EcnCapability                 : Enabled
Timestamps                    : Disabled
InitialRto(ms)                : 3000
ScalingHeuristics             : Disabled
DynamicPortRangeStartPort     : 49152
DynamicPortRangeNumberOfPorts : 16384

SettingName                   : Datacenter
MinRto(ms)                    : 20
InitialCongestionWindow(MSS)  : 4
CongestionProvider            : DCTCP
CwndRestart                   : True
DelayedAckTimeout(ms)         : 10
MemoryPressureProtection      : Enabled
AutoTuningLevelLocal          : Normal
AutoTuningLevelGroupPolicy    : NotConfigured
AutoTuningLevelEffective      : Local
EcnCapability                 : Enabled
Timestamps                    : Disabled
InitialRto(ms)                : 3000
ScalingHeuristics             : Disabled
DynamicPortRangeStartPort     : 49152
DynamicPortRangeNumberOfPorts : 16384

SettingName                   : Internet
MinRto(ms)                    : 300
InitialCongestionWindow(MSS)  : 4
CongestionProvider            : CTCP
CwndRestart                   : False
DelayedAckTimeout(ms)         : 50
MemoryPressureProtection      : Enabled
AutoTuningLevelLocal          : Normal
AutoTuningLevelGroupPolicy    : NotConfigured
AutoTuningLevelEffective      : Local
EcnCapability                 : Enabled
Timestamps                    : Disabled
InitialRto(ms)                : 3000
ScalingHeuristics             : Disabled
DynamicPortRangeStartPort     : 49152
DynamicPortRangeNumberOfPorts : 16384

Приемник SYN

No.     Time           Source                Destination           Protocol Length Delta      Sequence number Acknowledgment number Bytes in flight Calculated window size Info
    817 5.110501000    10.11.0.1             10.10.0.21            TCP      70     0.073924000 0               1                                     64512                  5001→49758 [SYN, ACK, ECN] Seq=0 Ack=1 Win=64512 Len=0 MSS=1460 WS=1 SACK_PERM=1 [ETHERNET FRAME CHECK SEQUENCE INCORRECT]

Frame 817: 70 bytes on wire (560 bits), 70 bytes captured (560 bits) on interface 0
Ethernet II, Src: aa:bb:cc:dd:ee:ff, Dst: 00:11:22:33:44:55
Internet Protocol Version 4, Src: 10.11.0.1 (10.11.0.1), Dst: 10.10.0.21 (10.10.0.21)
Transmission Control Protocol, Src Port: 5001 (5001), Dst Port: 49758 (49758), Seq: 0, Ack: 1, Len: 0
    Source Port: 5001 (5001)
    Destination Port: 49758 (49758)
    [Stream index: 73]
    [TCP Segment Len: 0]
    Sequence number: 0    (relative sequence number)
    Acknowledgment number: 1    (relative ack number)
    Header Length: 32 bytes
    .... 0000 0101 0010 = Flags: 0x052 (SYN, ACK, ECN)
    Window size value: 64512
    [Calculated window size: 64512]
    Checksum: 0xb5bb [validation disabled]
    Urgent pointer: 0
    Options: (12 bytes), Maximum segment size, No-Operation (NOP), Window scale, No-Operation (NOP), No-Operation (NOP), SACK permitted
        Maximum segment size: 1460 bytes
        No-Operation (NOP)
        Window scale: 0 (multiply by 1)
            Kind: Window Scale (3)
            Length: 3
            Shift count: 0
            [Multiplier: 1]
        No-Operation (NOP)
        No-Operation (NOP)
        TCP SACK Permitted Option: True
    [SEQ/ACK analysis]

Перспектива приемника графика последовательности

Окно TCP

Описание функций Windows TCP — Windows Server

  • Статья
  • 14 минут на чтение
  • 6 участников

Полезна ли эта страница?

да Нет

Любая дополнительная обратная связь?

Отзыв будет отправлен в Microsoft: при нажатии кнопки отправки ваш отзыв будет использован для улучшения продуктов и услуг Microsoft.Политика конфиденциальности.

Представлять на рассмотрение

В этой статье

В этой статье описываются функции TCP в Windows.

Применимо к:   Windows 10 – все выпуски, Windows Server 2012 R2
Исходный номер базы знаний:   224829

Резюме

В этой статье описываются следующие функции TCP в Windows:

  • Размер окна TCP
  • Опции TCP теперь поддерживаются
  • Масштабирование Windows — RFC 1323
  • Отметка времени — RFC 1323
  • Защита от переноса порядковых номеров (PAWS)
  • Выборочные подтверждения (SACKS) — RFC 2018
  • Поведение повторной передачи TCP и быстрая повторная передача

Функции TCP можно изменить, изменив записи в реестре.

Важно

Следующие разделы, методы или задачи содержат инструкции по изменению реестра. Однако при неправильном изменении реестра могут возникнуть серьезные проблемы. Поэтому убедитесь, что вы внимательно выполните следующие действия. Для дополнительной защиты создайте резервную копию реестра перед его изменением. Затем вы можете восстановить реестр, если возникнет проблема. Для получения дополнительных сведений о резервном копировании и восстановлении реестра щелкните следующий номер статьи базы знаний Майкрософт:
322756 Как выполнить резервное копирование и восстановление реестра в Windows

Размер окна TCP

Размер окна приема TCP — это объем принимаемых данных (в байтах), который может быть буферизован во время соединения.Хост-отправитель может отправить только такое количество данных, после чего ему придется ждать подтверждения и обновления окна от хоста-получателя. Стек Windows TCP/IP предназначен для самонастройки в большинстве сред и использует более крупные размеры окна по умолчанию, чем в более ранних версиях.

Вместо использования жестко запрограммированного размера окна приема по умолчанию TCP подстраивается под четные приращения максимального размера сегмента (MSS). MSS согласовывается во время установки соединения. Настройка окна приема на равные приращения MSS увеличивает процент полноразмерных TCP-сегментов, используемых при массовой передаче данных.

Размер окна приема определяется следующим образом:

  1. Первый запрос на подключение, отправленный на удаленный узел, сообщает о размере окна приема 16 КБ (16 384 байта).
  2. Когда соединение установлено, размер окна приема округляется до четного приращения MSS.
  3. Размер окна регулируется в четыре раза больше MSS, до максимального размера 64 КБ, если не используется параметр масштабирования окна (RFC 1323).

Примечание

См. раздел «Масштабирование Windows».

Для соединений Ethernet размер окна обычно устанавливается равным 17 520 байт (16 КБ округляется до двенадцати сегментов по 1460 байт). Размер окна может уменьшиться при установке соединения с компьютером, который поддерживает расширенные параметры заголовка TCP, такие как выборочные подтверждения (SACKS) и временные метки. Эти два параметра увеличивают размер заголовка TCP до более чем 20 байтов, что приводит к меньшему количеству места для данных.

В предыдущих версиях Windows NT размер окна для соединения Ethernet составлял 8760 байт или шесть сегментов по 1460 байт.

Чтобы задать для размера окна получения определенное значение, добавьте значение TcpWindowSize в раздел реестра, относящийся к вашей версии Windows. Для этого выполните следующие действия:

  1. Выберите Пуск > Выполнить , введите Regedit , а затем выберите OK .

  2. Разверните подраздел реестра, относящийся к вашей версии Windows:

    • Для Windows 2000 разверните следующий подраздел: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces

    • Для Windows Server 2003 разверните следующий подраздел: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

  3. В меню Edit укажите New , а затем выберите DWORD Value .

  4. Введите TcpWindowSize в поле Новое значение и нажмите Enter

    .
  5. Выберите Изменить в меню Редактировать .

  6. Введите желаемый размер окна в поле Value data .

    Примечание

    Допустимый диапазон размера окна: 0–0x3FFFC000 в шестнадцатеричном формате.

Это значение отсутствует по умолчанию. Когда вы добавляете значение TcpWindowSize, оно переопределяет алгоритм размера окна по умолчанию, описанный выше.

Примечание

TcpWindowSize также можно добавить к ключу Parameters, чтобы установить размер окна глобально для всех интерфейсов.

Опции TCP теперь поддерживаются

Ранее параметры TCP использовались главным образом для согласования максимальных размеров сегментов. В Windows параметры TCP используются для масштабирования окна, отметки времени и выборочного подтверждения.

Существует два типа опций TCP:

  1. Опция TCP, состоящая из одного октета, которая используется для указания конкретного типа опции.
  2. Опция TCP, состоящая из нескольких октетов, состоящая из типа опции, длины опции и последовательности октетов опции.

В следующем списке показаны тип, длина, имя и описание каждой опции TCP.

Вид: 0
Длина: 1
Опция: Конец списка опций
Описание: Используется, когда требуется дополнение для последней опции TCP.

Вид: 1
Длина: 1
Опция: Нет операции
Описание: Используется, когда требуется дополнение и в одном пакете следуют дополнительные параметры TCP.

Тип: 2
Длина: 4
Параметр: Максимальный размер сегмента
Описание: Указывает максимальный размер TCP-сегмента, который можно отправить по сети.

Вид: 3
Длина: 3
Опция: Масштаб окна Опция
Описание: Определяет коэффициент масштабирования, используемый при использовании окон размером более 64 КБ.

Вид: 8
Длина: 10
Опция: Отметка времени Опция
Описание: Используется для расчета времени приема-передачи (RTT) передаваемых пакетов.

Тип: 4
Длина: 2
Опция: TCP SACK разрешен
Описание: Информирует другие хосты о том, что выборочные подтверждения разрешены.

Тип: 5
Длина: Варьируется.
Опция: TCP SACK Опция
Описание: Используется хостами для определения того, были ли получены неправильные пакеты.

Масштабирование Windows

Для более эффективного использования сетей с высокой пропускной способностью можно использовать больший размер окна TCP. Поле размера окна TCP управляет потоком данных и ограничено 2 байтами или размером окна 65 535 байт.

Поскольку поле размера не может быть расширено, используется коэффициент масштабирования. Масштаб окна TCP — это параметр, используемый для увеличения максимального размера окна с 65 535 байт до 1 гигабайта.

Опция масштабирования окна используется только во время трехэтапного установления связи TCP.S, где S — значение масштаба.3

Истинный размер окна = 524280

Следующая трассировка сетевого монитора показывает, как используется параметр масштабирования окна:

  TCP: ....S., len:0, seq:725163-725163, ack:0, win:65535, src:1217 dst:139(сеанс NBT)
TCP: Исходный порт = 0x04C1
TCP: порт назначения = служба сеансов NETBIOS
TCP: порядковый номер = 725163 (0xB10AB)
TCP: номер подтверждения = 0 (0x0)
TCP: смещение данных = 44 (0x2C)
TCP: зарезервировано = 0 (0x0000)
+ TCP: Флаги = 0x02 : ....S.
TCP: Окно = 65535 (0xFFFF)
TCP: контрольная сумма = 0x8565
TCP: срочный указатель = 0 (0x0)
ПТС: параметры
+ TCP: опция максимального размера сегмента
TCP: Опция Nop = 1 (0x1)
TCP: опция масштабирования окна
TCP: Тип опции = Масштаб окна
TCP: длина параметра = 3 (0x3)
TCP: масштаб окна = 3 (0x3)
TCP: Опция Nop = 1 (0x1)
TCP: Опция Nop = 1 (0x1)
+ TCP: опция временных меток
TCP: Опция Nop = 1 (0x1)
TCP: Опция Nop = 1 (0x1)
+ TCP: Разрешенная опция SACK
  

Размер окна, используемый в фактическом трехстороннем рукопожатии, не соответствует размеру окна, масштабируемому в соответствии с разделом 2 RFC 1323.2:

«Поле окна в сегменте SYN (например, [SYN] или [SYN,ACK]) само по себе никогда не масштабируется».

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

Масштабный коэффициент Значение шкалы Начальное окно Масштаб окна
0 1 65535 или менее 65535 или менее
1 2 65535 131 070
2 4 65535 262 140
3 8 65535 524 280
4 16 65535 1 048 560
5 32 65535 2 097 120
6 64 65535 4 194 240
7 128 65535 8 388 480
8 256 65535 16 776 960
9 512 65535 33 553 920
10 1024 65535 67 107 840
11 2048 65535 134 215 680
12 4096 65535 268 431 360
13 8192 65535 536 862 720
14 16384 65535 1 073 725 440

Например:

Если размер окна в реестре указан как 26

00 (269M) в десятичном формате, коэффициент масштабирования при трехстороннем рукопожатии равен 13.13


Истинный размер окна = 536 862 720

Когда значение размера окна добавляется в реестр и его размер превышает значение по умолчанию, Windows пытается использовать значение масштаба, соответствующее новому размеру окна.

Значение Tcp1323Opts в следующем разделе реестра можно добавить для управления масштабированием окон и отметкой времени:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters

  1. На панели инструментов выберите Пуск > Выполнить , а затем введите Regedit , чтобы запустить редактор реестра.

  2. В редакторе реестра выберите Изменить , укажите Новый , а затем выберите Параметр DWORD .

  3. В поле Новое значение введите Tcp1323Opts , нажмите клавишу ВВОД, а затем в меню Редактировать выберите Изменить .

    Примечание

    Допустимый диапазон: 0, 1, 2 или 3, где:
    0 (отключить параметры RFC 1323)
    1 (включен только масштаб окна)
    2 (включены только временные метки)
    3 (включены оба параметра)

Эта запись реестра управляет временными метками RFC 1323 и параметрами масштабирования окна.Временные метки и масштабирование окна включены по умолчанию, но ими можно управлять с помощью флаговых битов. Бит 0 управляет масштабированием окна. Бит 1 управляет отметками времени.

Временные метки

Ранее стек TCP/IP использовал одну выборку на окно данных, отправляемых для расчета времени приема-передачи (RTT). Таймер (таймер повторной передачи) был установлен при отправке пакета до получения подтверждения. Например, если размер окна составлял 64 240 байт (44 полных сегмента) в сети Ethernet, только один из каждых 44 пакетов использовался для пересчета времени приема-передачи.При максимальном размере окна 65 535 байт такой частоты дискретизации было достаточно. Используя масштабирование окна и максимальный размер окна 1 гигабайт, этой частоты дискретизации RTT недостаточно.

Параметр TCP Timestamp теперь можно использовать для сегментов (данных и ACK), которые стек считает подходящими, для выполнения таких операций, как:

  • Расчет RTT
  • Лап чек

Используя эти данные, можно точно рассчитать RTT для больших размеров окна. RTT используется для расчета интервалов повторной передачи.Для оптимальной пропускной способности необходимы точные тайм-ауты RTT и повторной передачи.

Когда в сеансе TCP используется метка времени TCP, инициатор сеанса отправляет параметр в своем первом пакете трехэтапного установления связи TCP (пакет SYN). После этого любая из сторон может использовать параметр TCP во время сеанса.

Опция временных меток TCP (TSopt):

Вид = 8 Длина = 10 Значение ТС (Цвал) Эхо-ответ TS (Tsecr)
1 байт 1 байт 4 байта 4 байта

Поле параметров метки времени можно просмотреть в трассировке сетевого монитора, развернув поле параметров TCP, как показано ниже:

  TCP: параметр временных меток
TCP: тип параметра = метки времени
TCP: длина опции = 10 (0xA)
TCP: Отметка времени = 2525186 (0x268802)
TCP: Отметка времени ответа = 1823192 (0x1BD1D8)
  

Защита от упакованных порядковых номеров (PAWS)

Поле порядкового номера TCP ограничено 32 битами, что ограничивает количество доступных порядковых номеров.В сетях с высокой пропускной способностью и при передаче больших объемов данных можно использовать перенос порядковых номеров до того, как пакет пройдет по сети. При отправке данных по сети со скоростью один гигабайт в секунду (Гбит/с) порядковые номера могут переноситься всего за 34 секунды. Если пакет задерживается, потенциально может существовать другой пакет с тем же порядковым номером. Чтобы избежать путаницы с повторяющимися порядковыми номерами, метка времени TCP используется как расширение порядкового номера. Пакеты имеют текущие и текущие метки времени.Старый пакет имеет более старую метку времени и отбрасывается.

Выборочные подтверждения (SACK)

В Windows появилась поддержка функции повышения производительности, известной как выборочное подтверждение или SACK. SACK особенно важен для соединений, которые используют большие размеры окна TCP. До SACK получатель мог подтвердить только последний порядковый номер непрерывного потока данных, который был получен, или «левый край» окна приема. При включенном SACK приемник продолжает использовать номер ACK для подтверждения левого края окна приема, но он также может отдельно подтверждать другие блоки полученных данных.SACK использует параметры заголовка TCP, как показано ниже.

SACK использует два типа параметров TCP.

Параметр TCP Sack-Permitted используется только в пакете SYN (во время установления соединения TCP), чтобы указать, что он может выполнять выборочный ACK.

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

Тип 4 является опцией, разрешенной для TCP Sack. Тип 5 — это опция TCP Sack. Длина — это длина в байтах этой опции TCP.

TCP SACK Разрешено:

Вид = 4 Длина = 2
1 байт 1 байт

Параметр TCP SACK:

Вид = 5 Длина = Переменная
1 байт Левый край первого блока на правый край первого блока

От левого края N-го блока до правого края N-го блока

При включенном SACK (по умолчанию) пакет или серия пакетов могут быть отброшены. Получатель сообщает отправителю, какие данные были получены и где в данных могут быть «дыры». Затем отправитель может выборочно повторно передать недостающие данные без повторной передачи блоков данных, которые уже были успешно получены. SACK управляется параметром реестра SackOpts.

Значение SackOpts в следующем разделе реестра можно изменить, чтобы управлять использованием выборочных подтверждений:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

  1. На панели инструментов выберите Пуск > Выполнить и введите Regedit , чтобы запустить редактор реестра.
  2. Найдите и выберите указанный выше ключ в редакторе реестра, а затем выберите Изменить в меню Изменить .
  3. Введите нужное значение в поле Value data .

Примечание

Допустимое двоичное значение — 0 или 1, значение по умолчанию — 1. Этот параметр определяет, включена ли поддержка выборочного подтверждения (SACK — RFC 2018).

Следующая трассировка сетевого монитора показывает, что узел подтверждает все данные до порядкового номера 54857341, а также данные с порядкового номера 54858789-54861685.Отсутствуют данные с 54857341 по 54858788.

  TCP: .A...., len:0, seq:925104-925104, ack:54857341, win:32722, src:1242 dst:139
TCP: Исходный порт = 0x04DA
TCP: порт назначения = служба сеансов NETBIOS
TCP: порядковый номер = 925104 (0xE1DB0)
TCP: номер подтверждения = 54857341 (0x3450E7D)
TCP: смещение данных = 44 (0x2C)
TCP: зарезервировано = 0 (0x0000)
+ TCP: Флаги = 0x10: .A....
TCP: Окно = 32722 (0x7FD2)
TCP: контрольная сумма = 0x4A72
TCP: срочный указатель = 0 (0x0)
ПТС: параметры
TCP: Опция Nop = 1 (0x1)
TCP: Опция Nop = 1 (0x1)
+ TCP: опция временных меток
TCP: Опция Nop = 1 (0x1)
TCP: Опция Nop = 1 (0x1)
TCP: опция SACK
TCP: Тип опции = 0x05
TCP: длина опции = 10 (0xA)
TCP: левый край блока = 54858789 (0x3451425)
TCP: правый край блока = 54861685 (0x3451F75)
  

Поведение повторной передачи TCP и быстрая повторная передача

Повторная передача TCP

В качестве проверки нормального поведения повторной передачи TCP запускает таймер повторной передачи, когда каждый исходящий сегмент передается в Интернет-протокол (IP).Если подтверждение для данных в данном сегменте не получено до истечения таймера, то сегмент передается повторно.

Тайм-аут повторной передачи (RTO) постоянно корректируется в соответствии с характеристиками соединения с использованием расчетов сглаженного времени приема-передачи (SRTT), как описано в RFC 793. Таймер для данного сегмента удваивается после каждой повторной передачи этого сегмента. Используя этот алгоритм, TCP настраивается на обычную задержку соединения.

Быстрая повторная передача

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

По умолчанию Windows повторно отправляет сегмент при следующих условиях:

  • Он получает три ACK для одного и того же порядкового номера: один ACK и два дубликата.
  • Порядковый номер отстает от текущего.

Это поведение можно контролировать с помощью параметра реестра TcpMaxDupAks .

Значение TcpMaxDupAcks в следующем разделе реестра можно изменить, чтобы контролировать количество подтверждений, необходимых для запуска быстрой повторной передачи:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

  1. На панели инструментов выберите Пуск > Выполнить и введите Regedit , чтобы запустить редактор реестра.
  2. Найдите и выберите указанный выше ключ в редакторе реестра, а затем выберите Изменить в меню Изменить .
  3. Введите нужное значение в поле Value data .

Примечание

Допустимый диапазон: 1–3, значение по умолчанию — 2.

Этот параметр определяет количество дубликатов ACK, которые должны быть получены для одного и того же порядкового номера отправленных данных, прежде чем инициируется быстрая повторная передача для повторной отправки сегмента, который был отброшен при передаче.

Окно приема TCP и все, что нужно о нем знать

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

После рассмотрения того, как работает механизм повторной передачи TCP, мы теперь рассмотрим окна приема TCP и то, как они могут повлиять на производительность.

Почему вы должны заботиться об окнах TCP? Потому что это влияет на скорость передачи данных и, следовательно, на удобство доступа ваших пользователей к приложениям, как описано в этих двух других статьях:

.

Что такое окно приема TCP?

Проще говоря, это приемный буфер TCP для входящих данных, которые еще не были обработаны приложением.

Размер окна приема TCP передается партнеру по соединению с использованием поля значения размера окна заголовка TCP. Это поле сообщает партнеру по соединению, сколько данных может быть отправлено по сети, прежде чем будет получено подтверждение. Если получатель не может обрабатывать данные так же быстро, как они приходят, постепенно буфер приема будет заполняться, и окно TCP будет уменьшаться в пакетах подтверждения. Это предупредит отправителя о том, что ему необходимо уменьшить объем отправляемых данных или дать получателю время на очистку буфера.

TCP Receive Window

На приведенной выше диаграмме клиент и сервер объявляют свои значения размера окна при обмене данными. Каждый заголовок TCP будет отображать самое последнее значение окна, которое может увеличиваться или уменьшаться по мере установления соединения. В этом примере окно приема TCP у клиента составляет 65 535 байт, а у сервера — 5 840. Для многих приложений, поскольку клиенты, как правило, получают данные, а не отправляют их, клиенты часто имеют больший размер выделенного окна. После рукопожатия клиент отправляет на сервер HTTP-запрос GET, который быстро обрабатывается.Два ответных пакета от сервера приходят к клиенту, который отправляет подтверждение вместе с обновленным размером окна. Клиент мог обрабатывать пакеты данных из буфера TCP так же быстро, как они поступали, поэтому размер окна не уменьшался. Клиенту еще доступно полное окно для приема данных — 65 535 байт.

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

Окно приема TCP и буфер TCP

Подтверждения от клиента указывают, что окно уменьшается . Пока значение окна не упадет до нуля, это поведение останется незамеченным для конечного пользователя. Хотя число немного уменьшилось, в буфере все еще достаточно места для продолжения передачи данных. Во многих случаях клиент может догнать и обработать данные из буфера, очищая окно и увеличивая значение окна.

Масштаб окна TCP

Значение заголовка TCP, выделенное для размера окна, имеет длину два байта. Это означает, что максимально возможное числовое значение для окна приема составляет 65 535 байт. В современных сетях этого размера окна недостаточно для обеспечения оптимального потока трафика, особенно в длинных и толстых сетях (каналы с высокой пропускной способностью и высокой задержкой). В своем исходном состоянии TCP не может использовать преимущества этих высокопроизводительных каналов связи, поскольку за один раз он может отправлять не более 65 535 байтов.

По этой причине в RFC 1323 были введены параметры TCP, которые позволяют экспоненциально увеличивать окно приема TCP. Конкретная функция называется TCP Window Scaling , которая объявляется в процессе установления связи. Объявляя свое окно, клиент или сервер также объявляет коэффициент масштабирования (множитель), который будет использоваться в течение срока действия соединения.

Информация о размере окна TCP отображается в Wireshark

На изображении выше отправитель этого пакета объявляет окно TCP размером 63 792 байта и использует коэффициент масштабирования, равный четырем.Это означает, что истинный размер окна составляет 63 792 x 4 (255 168 байт). Использование масштабирования окон позволяет конечным точкам объявлять размер окна более 1 ГБ . Чтобы использовать масштабирование окна, обе стороны соединения должны объявить об этой возможности в процессе рукопожатия. Если одна или другая сторона не поддерживает масштабирование, то ни одна из них не будет использовать эту функцию. Масштабный коэффициент или множитель будет отправляться только в пакетах SYN во время рукопожатия и будет использоваться в течение всего срока действия соединения.Это одна из причин, почему так важно фиксировать процесс рукопожатия при выполнении анализа TCP.

Что такое нулевое окно?

Когда клиент (или сервер, но обычно это клиент) объявляет нулевое значение размера своего окна, это указывает на то, что буфер приема TCP заполнен и он не может больше принимать данные. У него может быть зависший процессор или он занят какой-то другой задачей, что может привести к заполнению приемного буфера TCP. Нулевые окна также могут быть вызваны проблемой в приложении, когда буфер TCP не извлекается.

Пример нулевого окна TCP

Нулевое окно TCP от клиента останавливает передачу данных со стороны сервера, позволяя проблемной станции очистить свой буфер. Когда клиент начинает переваривать данные, он сообщает серверу о возобновлении потока данных, отправляя пакет TCP Window Update. Это будет рекламировать увеличенный размер окна, и поток возобновится.

Как мы можем обнаружить нулевое окно TCP?

Проблемы с окном обычно наблюдаются в приложениях, которые перемещают много данных, таких как резервные копии, передача файлов и большие загрузки.Если проблема с производительностью препятствует передаче данных, ищите проблемы с окном на приемнике.

Skylight может отслеживать условия нулевого окна и отображать статистику о том, какие соединения пострадали и когда. Если эти проблемы наблюдаются в Skylight, сосредоточьтесь на станции, рекламирующей значение Zero Window. Помните, что это указывает на то, что буфер приема TCP исчерпан, и поток данных остановится до тех пор, пока буфер не будет очищен. Обычно это вызвано зависшими процессами на клиенте, ПК с недостаточными ресурсами или приложением, которое не настроено на получение данных с высокой скоростью.

В качестве примера, если мы рассмотрим приложение, в котором мы можем наблюдать многочисленные события 0-Windows, генерируемые клиентами 223.

Вы можете легко перейти к клиентам, вовлеченным в явление, и подтвердить влияние на передачу данных и время отклика конечного пользователя:

Лучшие клиенты по количеству событий нулевого окна

Вы также можете просмотреть эволюцию во времени, чтобы понять, является ли это постоянной или прерывистой проблемой:

Нулевой тренд событий Windows во времени

При таком уровне детализации TCP Skylight может быстро помочь выявить основную причину зависания TCP-соединения. Получите бесплатную пробную версию сегодня!

Еще из этой серии

Сетевой анализ: размер окна TCP

Размер окна TCP

— один из самых популярных параметров для устранения неполадок в сети или выполнения базовых показателей приложения. Я читал много статей и книг, которые могут сделать этот вариант довольно громоздким, но на самом деле он довольно прост.

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

В некоторых операционных системах для расчета максимального размера окна TCP используется значение, кратное их максимальному размеру сегмента (MSS). Например, в Microsoft Windows 2000 в сетях Ethernet значение по умолчанию составляет 17 520 байт или 12 сегментов MSS по 1 460 байт каждый. Я предлагаю вам задокументировать настройки вашей системы по умолчанию, так как они могут измениться при установке приложения.

Обратите особое внимание, если операционная система использует параметр масштабирования TCP, так как он увеличивает общий размер окна TCP, предоставляя значение множителя.Проверьте свой анализатор сетевых протоколов и выясните, можете ли вы указать значение масштабирования TCP вручную, если у вас нет пакетов SYN. В видео ниже я рассказываю, как это сделать с помощью Wireshark 2.0:

.

На снимке экрана ниже этот пакет имеет масштабное значение, равное восьми, которое преобразуется в 256. Математика довольно проста: два в множителе (или степени) восьми, что равно 256.

 

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

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

 

Ищите пакеты TCP ZeroWindowProbe (снимок экрана ниже), так как они помогают доказать, что отправитель распознает, что получатель указал, что его размер окна TCP равен нулю, но пытается возобновить поток.Существование пакетов TCP ZeroWindowProbeAck также указывает на то, что сеть доставляет пакеты и устройства не отключены.

 

При попытке решить проблемы с размером окна TCP стоит попробовать общие исправления, такие как увеличение оперативной памяти или более быстрый процессор. Также стоит увеличить размер окна TCP на устройстве, сообщающем о нулевом окне TCP.

Если вы хотите рассчитать, каким должен быть размер окна TCP, существует множество веб-сайтов и приложений, которые могут помочь рассчитать, какими должны быть эти значения.Мне нравятся анализатор TCP/IP и оптимизатор TCP от Speedguide.net.

TCP Windows и масштабирование окон

Я помню разговор с коллегой, когда работал сетевым администратором в Ираке. Он хотел знать, будет ли достаточно нашего скудного (и очень дорогого) спутникового интернет-соединения со скоростью 2 Мбит/с, чтобы играть в XBox Live. Я ответил, что не имеет значения, если бы у нас было соединение со скоростью 1 Гбит/с. Почему? Потому что ему по-прежнему мешала односторонняя задержка около 250 мс, не считая задержки от восходящего спутникового концентратора в Великобритании до серверов в США.С такой задержкой в ​​оба конца вам снесет голову в Call of Duty, прежде чем вы даже поймете, что игра началась.

«Длинные, толстые сети», такие как наша, называемые так из-за их относительно высокой задержки и высокой пропускной способности, представляли собой интересную проблему для ранних реализаций TCP. Чтобы разобраться в этом вопросе, сначала мы должны ознакомиться с работой окон TCP.

TCP-окна

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

Предположим, у нас есть два хоста, A и B, которые образуют TCP-соединение. В начале соединения оба хоста выделяют 32 КБ буферного пространства для входящих данных, поэтому начальный размер окна для каждого равен 32 768.

Узлу A необходимо отправить данные узлу B. По объявленному узлом B размеру окна он может определить, что он может передать до 32 768 байт данных (с интервалами максимального размера сегмента, или MSS), прежде чем он должен будет приостановиться и ожидать подтверждение. Предполагая, что MSS составляет 1460 байт, хост A может передать 22 сегмента, прежде чем исчерпается окно приема хоста B.

При подтверждении получения данных, отправленных хостом A, хост B может настроить размер своего окна. Например, если приложение верхнего уровня обработало только половину буфера, узел B уменьшит размер своего окна до 16 КБ.Если бы буфер все еще был полностью заполнен, узел B установил бы размер своего окна равным нулю, указывая на то, что он еще не может принимать больше данных.

В локальной сети с высокой пропускной способностью и чрезвычайно низкой задержкой окна редко испытывают нагрузку, поскольку обычно между двумя конечными точками в любой момент времени проходит очень мало сегментов. Однако в сети с высокой пропускной способностью и высокой задержкой происходит интересное явление: можно максимально увеличить окно приема хоста-получателя до получения подтверждения.

В качестве примера предположим, что TCP-соединение установлено между двумя хостами, соединенными выделенным путем 10 Мбит/с с односторонней задержкой 80 мс. Оба хоста объявляют максимальный размер окна 65 535 байт (максимальное значение 16-битного целого числа без знака). Мы можем рассчитать потенциальный объем данных, передаваемых в одном направлении в один момент времени, как пропускная способность * задержка : 10 000 000 бит/с, разделенные на 8 бит на байт, умноженные на 0,08 секунды, равно 100 000 байт. Другими словами, если хост A начнет непрерывно передавать хосту B, он отправит 100 000 байтов до того, как хост B получит первый переданный байт.Однако, поскольку наше максимальное окно приема составляет всего 65 535 байт, узел A должен прекратить передачу после достижения этого числа и дождаться подтверждения от узла B. (Ради простоты расчеты в нашем примере не учитывают накладные расходы TCP и заголовки нижнего уровня.) Эта задержка приводит к потере потенциальной пропускной способности, излишне увеличивая время, необходимое для надежной передачи данных по сети. Масштабирование окна TCP было создано для решения этой проблемы.

Масштабирование окна

Масштабирование окна было введено в RFC 1072 и усовершенствовано в RFC 1323.По сути, масштабирование окна просто увеличивает длину 16-битного поля окна до 32 бит. Конечно, инженеры не могли просто вставить в заголовок TCP дополнительные 16 бит, что сделало бы его полностью несовместимым с существующими реализациями. Решение состояло в том, чтобы определить параметр TCP, чтобы указать количество, на которое поле заголовка TCP должно быть побитовым сдвигом для получения большего значения.

Счетчик, равный единице, сдвигает двоичное значение поля на один бит влево, удваивая его.При счете до двух значение смещается на два разряда влево, увеличиваясь в четыре раза. При счете семь (как показано в приведенном выше примере) значение умножается на 128. Таким образом, мы можем умножить 16-битное поле заголовка по экспоненциальной шкале, чтобы получить более чем достаточно высокие значения. Конечно, это приводит к потере степени детализации при масштабировании (мы можем увеличивать или уменьшать размер окна только с интервалами 2 n , где _n_ — наш масштаб), но это не имеет большого значения при работе с такими большими окнами. окна.

Параметр масштабирования окна может быть отправлен только один раз во время соединения каждым хостом в его пакете SYN. Размер окна можно динамически настроить, изменив значение поля окна в заголовке TCP, но множитель масштаба остается постоянным на время соединения TCP. Масштабирование действует только в том случае, если оба конца включают опцию; если только один конец соединения поддерживает масштабирование окна, оно не будет включено ни в одном направлении. Максимальное допустимое значение шкалы равно 14 (раздел 2.3 RFC 1323 содержит некоторые сведения об этом предостережении для тех, кто заинтересован).

Возвращаясь к нашему предыдущему примеру, мы можем наблюдать, как масштабирование окна позволяет нам гораздо более эффективно использовать длинные толстые сети. Чтобы вычислить наше идеальное окно, мы удваиваем сквозную задержку, чтобы найти время приема-передачи, и умножаем ее на доступную пропускную способность: 2 * 0,08 секунды * 10 000 000 бит/с / 8 = 200 000 байт. Для поддержки окна такого размера хост B может установить размер окна равным 3125 со значением масштаба 6 (3125, сдвинутое влево на 6, равно 200 000).К счастью, все эти вычисления выполняются автоматически современными реализациями стека TCP/IP.

Как настроить для повышения производительности сети| Аувик

Вы наблюдаете низкую производительность сети, но при этом коэффициент использования канала значительно ниже 100 %? Возможно, у вас проблема с размером окна TCP. Вот как и почему это можно исправить.

Протокол TCP/IP

Протокол TCP/IP иногда показывает свой возраст.

Он был изобретен в эпоху, когда сети были очень медленными, а потери пакетов были высокими.Таким образом, одним из основных соображений при разработке раннего протокола была надежность.

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

Эти функции были изобретены, когда пропускная способность глобальной сети составляла 56 Кбит/с, а коэффициент отбрасывания пакетов в 1 % не был чем-то необычным.

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

Что такое окно TCP?

Ключевой функцией надежности TCP является пакет подтверждения (ACK). Устройство A отправляет пакет данных на устройство B. Затем устройство B проверяет все контрольные суммы на уровне пакетов и отправляет пакет ACK, в котором говорится, что все было получено правильно.

Если не все получено, часть или все данные необходимо передать повторно.Каждое устройство поддерживает буфер всех данных на тот случай, если ему нужно отправить их снова. Получение пакета ACK означает, что устройство может сбросить эти старые данные из буфера.

Окно TCP — это максимальное количество байтов, которые можно отправить, прежде чем должен быть получен ACK.

Если сеть ненадежна, лучше оставить окно маленьким. Таким образом, вам не придется повторно передавать столько данных, если возникнет проблема. Но если сеть надежная, то окно может быть довольно большим.

Одной из самых умных функций TCP является концепция скользящего окна . Устройства могут динамически изменять размер окна, делая его меньше, когда есть заторы, и больше, когда все чисто.

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

Где происходит сбой TCP-окна

Управление окнами TCP — очень умный механизм.Но подумайте, что происходит в сети с очень высокой задержкой и высокой пропускной способностью.

Вы можете легко передать данные всего окна еще до того, как первый пакет будет получен на другом конце. Затем отправитель останавливается и ждет подтверждения. В конце концов получатель получает последний пакет в пакете и отправляет подтверждение — одиночный пакет, который должен пересечь сеть — снова за то же время.

Каждое устройство может отправлять пакеты только этими относительно короткими пакетами.Затем он должен дождаться подтверждения с другого конца.

Средний объем данных, проходящих через сеть, составляет небольшую долю от общей пропускной способности. В современных сетях частота отбрасывания настолько мала, что такая медленная скорость передачи не оправдана. Все, что он делает, это снижает производительность сети

.

Как исправить окна TCP

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

Но, как я упоминал ранее, механизм TCP был разработан для пропускной способности сети, которая на несколько порядков меньше, чем у нас сегодня. Таким образом, в некоторых реализациях по-прежнему применяется максимальный размер окна 64 КБ. Вы можете обойти это, включив масштабирование окон TCP , что позволяет использовать окна размером до 1 ГБ.

Масштабирование Windows было введено в RFC 1323 для решения проблемы управления окнами TCP в быстрых и надежных сетях. Он доступен в качестве опции в любой современной реализации TCP.Вопрос только в том, правильно ли он включен.

Во всех последних реализациях Microsoft Windows масштабирование окон включено по умолчанию. В Интернете вы найдете места, где вам предлагается изменить значения реестра, чтобы увеличить размер окна, но в зависимости от используемой версии Windows эти изменения не будут иметь никакого эффекта. Значения могут больше не существовать. Суть в том, что вам не нужно исправлять окна TCP в Windows, ни на клиентах, ни на серверах.

В системах Linux вы можете проверить, включено ли полное масштабирование окна TCP, просмотрев значение в /proc/sys/net/ipv4/tcp_window_scaling.

На устройствах Cisco размер окна можно настроить с помощью команды глобальной конфигурации «ip tcp window-size». Эта команда влияет только на сеансы самого устройства Cisco. Сетевые устройства обычно не изменяют параметры сеансов, которые просто проходят через них.

Масштабирование размера окна TCP

TCP (протокол управления передачей) — это протокол, ориентированный на соединение, что означает, что мы отслеживаем, сколько данных было передано.Отправитель будет передавать некоторые данные, и получатель должен подтвердить это. Если мы не получим подтверждение вовремя, отправитель повторно передаст данные.

TCP использует «оконный режим», что означает, что отправитель отправит один или несколько сегментов данных, а получатель подтвердит один или все сегменты. Когда мы запускаем TCP-соединение, хосты будут использовать приемный буфер, где мы временно сохраняем данные, прежде чем приложение сможет их обработать.

Когда получатель отправляет подтверждение, он сообщает отправителю, сколько данных он может передать, прежде чем получатель отправит подтверждение.Мы называем это размером окна . По сути, размер окна указывает размер приемного буфера.

Обычно TCP-соединение начинается с небольшого размера окна, и каждый раз при успешном подтверждении размер окна увеличивается. Вот пример:

Выше у нас есть два хоста, хост с левой стороны отправит один сегмент, а хост с правой стороны отправит в ответ подтверждение. Поскольку подтверждение прошло успешно, размер окна увеличится:

Хост с левой стороны теперь отправляет два сегмента, а хост с правой стороны возвращает одно подтверждение.Все работает нормально, поэтому размер окна увеличится еще больше:

Теперь хост отправляет четыре сегмента, а хост справа отвечает одним подтверждением.

В приведенном выше примере размер окна продолжает увеличиваться до тех пор, пока получатель отправляет подтверждения для всех наших сегментов или когда размер окна достигает определенного максимального предела. Когда получатель не отправляет подтверждение в течение определенного периода времени (так называемого времени приема-передачи), размер окна будет уменьшен.

Если интерфейс перегружен, IP-пакеты могут быть отброшены. Чтобы справиться с этим, TCP имеет ряд алгоритмов, которые имеют дело с контролем перегрузки. Один из них называется медленный старт .

Перегрузка возникает, когда интерфейсу приходится передавать больше данных, чем он может обработать. Его очередь(и) достигнет предела, и пакеты будут отброшены.

При медленном запуске TCP размер окна сначала будет расти экспоненциально (размер окна удваивается), но после того, как пакет будет отброшен, размер окна уменьшится до одного сегмента.Затем он снова будет расти в геометрической прогрессии до тех пор, пока размер окна не станет вдвое меньше, чем в момент возникновения перегрузки. В этот момент размер окна будет расти линейно, а не экспоненциально.

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

Оранжевая, синяя и зеленая линии — это три разных соединения TCP.Эти TCP-подключения начинаются в разное время, и через некоторое время интерфейс перегружается, а пакеты всех TCP-подключений отбрасываются. Что произойдет, так это то, что размер окна всех этих TCP-соединений упадет до единицы, и как только перегрузка интерфейса исчезнет, ​​все размеры их окон снова увеличатся.

Затем интерфейс снова перегружается, размер окна снова уменьшается до единицы, и история повторяется. В результате мы не используем всю доступную полосу пропускания, которую может предложить наш интерфейс.Если вы посмотрите на пунктирную линию, то увидите, что среднее использование интерфейса не очень велико.

Чтобы предотвратить глобальную синхронизацию, мы можем использовать КРАСНЫЙ (случайное раннее обнаружение). это функция, которая отбрасывает «случайные» пакеты из потоков TCP на основе количества пакетов в очереди и маркировки TOS (типа службы) пакетов. Когда пакеты отбрасываются до заполнения очереди, мы можем избежать глобальной синхронизации.

Конечный результат будет выглядеть примерно так:

Когда мы используем RED, наше среднее использование интерфейса улучшится.

Теперь у вас есть представление о размере окна TCP, давайте посмотрим на реальный пример того, как используется размер окна. Для этого мы можем использовать wireshark.

Wireshark захватывает

Чтобы проверить размер окна TCP, я буду использовать два устройства:

Устройство слева — современный компьютер с гигабитным интерфейсом. С правой стороны у нас есть небольшой raspberry pi с интерфейсом FastEthernet. Raspberry Pi — отличное маленькое устройство, но его процессор/память/интерфейс Ethernet ограничены.Чтобы получить интересный результат, я скопирую большой файл через SSH со своего компьютера на Raspberry Pi, который будет легко перегружен.

Вот что получилось, взгляните на эту картинку:

На графике выше вы можете увидеть размер окна, который использовался во время этого подключения. Передача файла началась примерно через 6 секунд, и вы можете видеть, что размер окна быстро увеличивается. Он немного поднимался и опускался, но примерно через 30 секунд полностью рухнул. Через несколько секунд он снова увеличился, и я смог завершить передачу файла.Давайте подробнее рассмотрим эту передачу файлов, которая начинается с трехэтапного рукопожатия:

.

Мой быстрый компьютер использует 10.56.100.1, а raspberry pi использует 10.56.100.164. Выше вы можете видеть, что в сообщении SYN,ACK о том, что Raspberry Pi хочет использовать размер окна 29200. Мой компьютер хочет использовать размер окна 8388480 (win=65535 * ws=128), что сейчас не имеет значения, так как мы отправка данных на raspberry pi.

После нескольких пакетов размер окна Raspberry Pi выглядит так:

Выше видно, что размер окна увеличился до 132480.Первоначально размер окна представляет собой 16-битное значение, поэтому наибольший размер окна будет равен 65535. В настоящее время мы используем коэффициент масштабирования, чтобы мы могли использовать окна большего размера.

Примерно на 10-й секунде размер окна уменьшился. Вот что получилось:

Похоже, Raspberry Pi не справляется, и его приемный буфер, вероятно, заполнен. Он сообщает компьютеру, что с этого момента следует использовать размер окна 26752. Компьютер отправляет 18 сегментов по 1460 байт и один сегмент по 472 байта (всего 26752 байта).Последний пакет показывает нам сообщение «TCP Window Full». Это то, что нам сообщает Wireshark, наш компьютер полностью заполнил приемный буфер raspberry pi.

Как только Raspberry Pi немного догоняет и приближается к 30-секундной отметке, происходит что-то плохое. Взгляните на захват wireshark ниже:

Выше вы можете видеть, что raspberry pi отправляет ACK на компьютер с размером окна 0 . Это означает, что размер окна останется равным 0 в течение определенного периода времени, raspberry pi больше не сможет получать данные в этот момент, и передача TCP будет приостановлена ​​на некоторое время, пока обрабатывается приемный буфер.

Вот собственно пакет:

Выше вы можете видеть, что размер окна теперь равен 0. После обработки буфера приема Raspberry Pi отправит ACK с новым размером окна:

Размер окна сейчас составляет всего 25600 байт, но снова будет увеличиваться. Остальная часть передачи прошла без сбоев, и передача файла завершилась.

Заключение

Теперь вы видели, как TCP использует размер окна, чтобы сообщить отправителю, сколько данных нужно передать, прежде чем он получит подтверждение.Я также показал вам пример того, как размер окна используется, когда получатель не может вовремя обработать свой приемный буфер.

UDP, в отличие от TCP, является протоколом без установления соединения и будет просто продолжать отправлять трафик. Размер окна не задан, по этой причине вы можете захотеть ограничить свой UDP-трафик, или вы можете столкнуться с голоданием вашего TCP-трафика при перегрузке.

Надеюсь, вам понравился этот урок. Если у вас есть еще вопросы, не стесняйтесь оставлять комментарии на нашем форуме.

Работа с окнами TCP: объяснение | Экстрахоп

Что такое окно TCP?

«Окно TCP» — это то, как мы называем это, когда протокол управления передачей (TCP) использует протокол скользящего окна для смягчения проблем с клиентами и серверами, пытающимися совместно использовать сегменты данных, которые слишком велики или малы и поэтому не могут эффективно передавать.

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

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

Протокол скользящего окна является одним из способов, с помощью которых TCP решает некоторые из этих проблем (и работа с окнами использовалась для смягчения атак DDoS). Давайте посмотрим на управление окнами TCP с точки зрения сервера как получателя и клиента как отправителя.

Протокол скользящего окна: приемник

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

В качестве простого примера предположим, что у нас есть сервер с пустым буфером приема, способным хранить 100 байтов (1).После установления соединения клиент передает 40 байт. Сервер получает их все (2), обрабатывает 30 байт (3) и возвращает отправителю номер подтверждения 41 и размер окна 90.

Далее клиент отправляет 90 байт. Сервер их получает (4) и обрабатывает еще 30 байт из своего буфера (5). Сервер возвращает номер подтверждения 131 и размер окна 30.

Протокол скользящего окна: отправитель

Как и следовало ожидать, клиент имеет окно отправки, соответствующее окну получения сервера.Размер окна отправки — это общее количество байтов, которые клиент может иметь неподтвержденными за раз. Как правило, окно отправки ограничено минимальным размером буфера отправки и размером окна приема сервера, но на него также влияет перегрузка сети и количество отправленных, но неподтвержденных байтов. У отправителя также есть полезное окно, которое является подмножеством окна отправки для неотправленных байтов, для которых еще есть место в буфере получателя. Другими словами, используемое окно — это окно отправки за вычетом всех отправленных байтов, которые еще не были подтверждены.Пример диаграммы окна отправки.

«Скользящий» аспект протокола легче увидеть, взглянув на упрощенный визуальный пример операции отправителя:

Приложение на клиенте имеет 500 байт, которые необходимо отправить на сервер (1). Сервер уже имеет 50 байтов в своем 150-байтовом буфере приема, поэтому он устанавливает размер окна приема равным 100. После установления соединения клиент отправляет 30 байтов из 100-байтового окна отправки. Поскольку 30 байтов еще не были подтверждены, у клиента остается доступное для использования окно размером 70 байтов (2).

Допустим, клиент отправляет следующие 70 байт, прежде чем ждать подтверждения (3). При этом используется текущее используемое окно, поскольку клиент отправил всю сумму, которую может обработать получатель.

Далее сервер подтверждает первые 30 байт. Отправитель сдвигает свое окно отправки вправо на 30 и обновляет используемое окно, чтобы учесть подтвержденные байты (4). Если сервер затем обработает все в своем буфере, он подтвердит следующие 70 байт и обновит свое окно приема до 150 байт.Клиент увеличивает свое окно отправки и используемое окно, чтобы они совпадали, и сдвигает их вправо. Затем клиент передает еще 100 байт (5).

Этот процесс продолжается до тех пор, пока не будут переданы все байты отправителя.

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

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

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

Больше хорошего содержания TCP:

.

Добавить комментарий

Ваш адрес email не будет опубликован.