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

Тази крайна точка описва капацитета си за приемане по тази TCP връзка. Тя не обявява колко честотна лента има цялото прокси. Пробата за нулев прозорец позволява на подателя да разбере дали обявеният капацитет се е променил; пробите сами по себе си не доказват загуба на пакети или повредено прокси.

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

Това са отделни TCP разговори. Да предположим, че браузърът спре да чете голям отговор и обяви нула на A. Проксито в крайна сметка може да спре да източва B, докато собствените му буфери се запълват. По-късен нулев прозорец на B може да е следствие от бавния клиент, а не първоначалният проблем.

Обратната ситуация е възможна при качване. Ако приложението получател спре да консумира данни, неговият прозорец на B може да се затвори. Тогава натискът може да се върне към клиента през буферите на проксито.

Подредете наблюденията

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

Етикетите за анализ на прозорци в Wireshark са полезни интерпретации на записа, а не указание да увеличите всеки буфер за приемане. Мащабирането на прозореца също трябва да се тълкува с оглед на договарянето на връзката.

Изпробването на друга крайна точка от списък с проксита и виждането, че трансферът се възстановява, е полезно доказателство, че пътят се е променил. Само по себе си то не доказва, че TCP реализацията на дадена операционна система е била дефектна. Дръжте обяснението свързано с приемащия процес и връзката, в която е започнало изчакването.

Подобни статии