TCP Zero Window кроз прокси: идентификујте примаоца

Утврдите да ли је контрола TCP протока на страни клијента или сервера проксија пре него што заглављено преузимање припишете window scaling-у или величини бафера.

Снимак пакета показује 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 имплементација неког оперативног система била неисправна. Држите објашњење везано за пријемни процес и везу на којој је чекање почело.

Повезани чланци