Трасса пакетов показывает TCP ZeroWindow. Прежде чем менять параметр ядра, определите конечную точку, которая объявляет ноль.

Эта конечная точка описывает свою способность принимать данные в этом TCP-соединении. Она не сообщает, сколько пропускной способности у всего прокси. Проверка нулевого окна позволяет отправителю узнать, изменилась ли объявленная способность; сами проверки не доказывают потерю пакетов или неисправный прокси.

browser  <-- TCP A -->  proxy  <-- TCP B -->  website

Это отдельные разговоры TCP. Предположим, браузер перестал читать большой ответ и объявил ноль на A. Прокси в конце концов может перестать откачивать B по мере заполнения собственных буферов. Более позднее нулевое окно на B может быть следствием медленного клиента, а не исходной проблемой.

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

Упорядочьте наблюдения

  1. Запишите концевые точки соединения и направление затронутой передачи данных.
  2. Определите, какая концевая точка первой объявила уменьшающееся или нулевое окно приёма.
  3. Проверьте, читало ли её приложение, стояло ли на другой операции или было ограничено ресурсами.
  4. Сравните время на другом соединении прокси, прежде чем назначать исходную причину.

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

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

Похожие статьи