TCP Zero Window через проксі: визначте отримувача

Трасування пакетів показує TCP ZeroWindow. Перш ніж змінювати параметр ядра, визначте, яка кінцева точка оголошує нуль.

Ця кінцева точка описує свою здатність приймати дані в цьому TCP-з'єднанні. Вона не повідомляє, скільки пропускної здатності має весь проксі. Проба zero-window дає змогу відправникові дізнатися, чи змінилася оголошена здатність; сама проба не доводить ні втрату пакетів, ні несправність проксі.

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

Це два окремі TCP-сеанси. Припустімо, браузер перестав читати велику відповідь і оголосив нуль на A. Проксі зрештою може перестати вичитувати з B, коли його власні буфери заповняться. Пізніший zero window на B може бути наслідком повільного клієнта, а не початковою проблемою.

Зворотна ситуація можлива під час вивантаження. Якщо цільовий застосунок перестає споживати дані, його вікно на B може закритися. Тиск тоді може піти назад до клієнта крізь буфери проксі.

Упорядкуйте спостереження

1. Запишіть кінцеві точки з'єднання та напрямок ураженого передавання даних.
2. Визначте, яка кінцева точка першою оголосила вікно приймання, що зменшується або дорівнює нулю.
3. Перевірте, чи її застосунок читав дані, чи зупинився на іншій операції, чи був обмежений ресурсами.
4. Порівняйте час на іншому з'єднанні проксі, перш ніж призначати першопричину.

Мітки аналізу вікон у Wireshark — це корисні інтерпретації захоплення, а не вказівка збільшувати кожен буфер приймання. Window scaling також треба тлумачити з огляду на узгодження в з'єднанні.

Спробувати іншу кінцеву точку зі списку проксі й побачити, що передавання відновилося, — корисний доказ того, що шлях змінився. Сам по собі він не доводить, що реалізація TCP якоїсь операційної системи була дефектною. Тримайте пояснення прив'язаним до процесу-отримувача та з'єднання, де почалося очікування.