TCP Nagle и анализ отложенного ACK PCAP: небольшая задержка пакетов, задержки в 40 мс и медленные приложения с запросами/ответами

---

Некоторые TCP-приложения работают медленно даже при отсутствии потери пакетов, низкой загрузке ЦП и хорошей пропускной способности. Причиной может быть взаимодействие алгоритма Нэгла и поведения задержки ACK. Пользователи ищут «TCP Nagle задержанный ACK pcap», «Задержка TCP 40 мс», «малая задержка пакета», «захват пакета TCP_NODELAY», «медленный ответ на запрос TCP» и «почему TCP ждет перед отправкой небольших пакетов», когда интерактивный протокол останавливается при крошечных операциях записи.

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

Что делает Нэгл

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

Типичный образец:

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

Эта задержка может выглядеть как загадочная пауза приложения.

Что делает отложенный ACK

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

Проблема появляется, когда:

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

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

Общие симптомы

Поисковики часто описывают:

• «TCP не теряет пакетов, но приложение работает медленно».
• «Каждый запрос имеет задержку 40 мс».
• «Небольшие записи выполняются медленно».
• «Отключение фиксированной задержки TCP_NODELAY».
• «Протокол базы данных медленный через VPN».
• «Удаленный пользовательский интерфейс работает медленно и содержит множество крошечных пакетов».
• «Вызовы RPC имеют странные пробелы».
• «Задержка возникает только в Linux и Windows».

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

Пакетное доказательство

Искать:

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

Это отличает Nagle/задержку ACK от потери, перегрузки, задержки DNS, согласования TLS и времени обработки сервера.

Протоколы запросов/ответов

Интерактивные протоколы особенно чувствительны:

• Запросы к базе данных.
• Оформление РПК.
• Telnet-подобные протоколы.
• Пользовательские протоколы промышленного контроля.
• Каналы управления удаленным рабочим столом.
• Финансовые торговые шлюзы.
• Болтливые клиентские библиотеки HTTP.
• Линейно-ориентированные командные протоколы.

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

TCP_NODELAY и пакетная обработка приложений

Отключение Nagle с помощью TCP_NODELAY может уменьшить задержку для некоторых интерактивных приложений. Но это не всегда лучшее решение.

Опции включают в себя:

• Включите TCP_NODELAY для небольших сообщений, чувствительных к задержке.
• Пакетная запись небольших объемов данных в одно приложение.
• Сбрасывать только полные кадры протокола.
• Избегайте шаблонов записи-записи-чтения с крошечными сегментами.
• Настройте поведение отложенного подтверждения, если платформа это позволяет.
• Оставьте Nagle включенным для массовых передач.

PCAP должен определять решение.

Ложные диагнозы

Эту проблему часто ошибочно диагностируют как:

• Потеря пакетов.
• Медленный процессор сервера.
• Накладные расходы TLS.
• Задержка Wi-Fi.
• Перегрузка VPN.
• Задержка DNS.
• Проблема с МТУ.

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

Требования к захвату

Для полезного анализа сохраните:

• TCP-рукопожатие.
• Первый медленный запрос.
• Размеры полезной нагрузки.
• Временные метки пакетов с высоким разрешением.
• Пакеты только для ACK.
• Направление каждого сегмента.
• Временные метки журнала приложения, если они доступны.
• Знание вариантов разъемов, если таковые имеются.

Не удаляйте небольшие холостые зазоры. Они являются доказательствами.

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

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

1. Выявите повторяющиеся пробелы в задержке.
2. Измерьте продолжительность перерыва.
3. Проверьте, мала ли полезная нагрузка.
4. Проверьте, есть ли у отправителя неподтвержденные данные.
5. Проверьте время подтверждения.
6. Подтверждение отсутствия повторной передачи объясняет пробел.
7. Сравните с РТТ.
8. Пакетная запись тестового приложения.
9. Если необходимо, проверьте TCP_NODELAY.
10. Сохраните до/после pcaps.

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

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

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