Масштабирование окна TCP и анализ пропускной способности PCAP: окно приема, нулевое окно, полное окно и отладка медленной передачи

---

Медленная пропускная способность TCP не всегда означает потерю пакетов. Это может быть давление на окно приема, отсутствие масштабирования окна, небольшие буферы сокетов, задержка чтения приложения, буферизация прокси-сервера, ограничения VPN или несоответствие продукта задержки полосы пропускания. Пользователи ищут «масштабирование окна TCP pcap», «нулевое окно TCP», «окно TCP заполнено», «захват пакетов медленной загрузки», «пропускная способность, ограничивающая окно приема» и «анализ TCP продукта задержки полосы пропускания», когда тесты скорости плохие, но повторные передачи не объясняют замедление.

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

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

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

Это особенно важно, когда задержка значительна:

• WAN-передачи.
• VPN-ссылки.
• Спутниковые или сотовые сети.
• Межрегиональный облачный трафик.
• Репликация резервных копий на большие расстояния.
• Удаленное копирование файлов.
• Большие HTTP-загрузки.

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

Продукт задержки полосы пропускания

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

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

Доказательства захвата пакетов:

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

Это узкое место на стороне приема или управления потоком, а не классическая потеря.

Нулевое окно

TCP Zero Window означает, что получатель объявил об отсутствии доступного буфера приема. Отправитель не может продолжать отправку данных приложения до тех пор, пока не придет обновление окна.

Распространенные причины:

• Принимающее приложение читается недостаточно быстро.
• Сервер перегружен.
• Клиент приостановлен или заблокирован на диске.
• Буферы прокси заполнены.
• Стек TLS находится под давлением.
• Клиент базы данных или приемник файлов работает медленно.
• Захват пакетов производится рядом с получателем и показывает локальное давление.

«Нулевое окно» не является автоматически неисправностью сети. Это часто указывает на нехватку ресурсов приложения или хоста.

Окно полное

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

Искать:

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

Этот шаблон особенно важен для случаев поддержки «медленной загрузки» и «медленной загрузки».

Отсутствует опция масштабирования

Масштабирование окна должно быть согласовано во время рукопожатия. Если одна сторона не включает опцию масштабирования окна в SYN или SYN-ACK, соединение не сможет использовать масштабирование позже.

Доказательство:

• Опции SYN.
• Опции SYN-ACK.
• Значение масштаба окна.
• Начальное окно приема.
• Эффективное масштабируемое окно.
• Поведение промежуточного блока, которое лишает вариантов.

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

Местоположение съемки имеет значение

Анализ окна зависит от того, где был сделан захват. Захват возле отправителя может показывать другое время, чем захват возле получателя. NAT, VPN, прокси-серверы и балансировщики нагрузки также могут разделять соединения.

Вопросы:

• Был ли PCAP зафиксирован на клиенте, сервере, брандмауэре или прокси-сервере?
• Это одно сквозное TCP-соединение или два соединения на стороне прокси?
• Переводятся ли порядковые номера?
• Задерживаются ли ACK получателем или сетью?
• Объявляет ли прокси-сервер другое окно, чем конечная конечная точка?

PCAP Surgery помогает обрезать и сравнивать разговоры, не теряя вариантов рукопожатия.

Избегайте ложных выводов о потере пакетов

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

Признаки того, что потеря не является основной причиной:

• Мало повторных передач.
• Никакого дублирующего шторма ACK.
• Регулярные циклы обновления окон.
• Отправитель делает паузу точно в рекламируемом окне.
• Реакция уровня приложения медленно потребляет данные.

Статья должна быть нацелена на такие поисковые запросы, как «медленный TCP без потери пакетов», поскольку этим пользователям нужен другой путь диагностики.

Контрольный список отладки

Используйте этот рабочий процесс:

1. Сохраните пакеты SYN и SYN-ACK.
2. Параметры масштабирования окна записи.
3. Рассчитайте эффективное окно приема.
4. Определите пакеты нулевого окна и обновления окна.
5. Определите периоды полного окна.
6. Измерьте RTT.
7. Сравните байты в полете с произведением задержки полосы пропускания.
8. Проверьте скорость ретрансляции отдельно.
9. Обратите внимание на место захвата.
10. Сохраняйте медленный интервал и рукопожатие вместе.

Окончательный диагноз

Масштабирование окна TCP и проблемы с окном приема приводят к медленной передаче без очевидной потери пакетов. Доказательствами являются параметры установления связи, объявленные окна приема, события с нулевым окном, обновления окон, RTT и поведение паузы отправителя.

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