Ufuatiliaji wa pakiti unaonyesha TCP ZeroWindow. Kabla ya kubadilisha mpangilio wa kernel, tambua mwisho unaotangaza sifuri.

Mwisho huo unaeleza uwezo wake wa kupokea kwenye muunganisho huo wa TCP. Hautangazi bandwidth inayopatikana kwa proxy yote. Uchunguzi wa zero-window humruhusu mtumaji kujua kama uwezo uliotangazwa umebadilika; uchunguzi wenyewe hauthibitishi upotevu wa pakiti au proxy mbovu.

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

Haya ni mazungumzo mawili tofauti ya TCP. Tuseme kivinjari kinaacha kusoma jibu kubwa na kutangaza sifuri kwenye A. Proxy inaweza hatimaye kuacha kuvuta kutoka B kadri buffer zake zinavyojazana. Zero window ya baadaye kwenye B inaweza kuwa matokeo ya mteja wa polepole, si tatizo la awali.

Hali ya kinyume inawezekana wakati wa kupakia. Ikiwa programu lengwa inaacha kutumia data, dirisha lake kwenye B linaweza kufungwa. Shinikizo linaweza kisha kusafiri kurudi kwa mteja kupitia buffer za proxy.

Panga uchunguzi kwa mpangilio

  1. Rekodi miisho ya muunganisho na mwelekeo wa uhamishaji data ulioathirika.
  2. Tambua ni mwisho gani uliotangaza kwanza dirisha la kupokea linalopungua au sifuri.
  3. Angalia kama programu yake ilikuwa inasoma, imesimama kwenye operesheni nyingine, au imezuiwa na rasilimali.
  4. Linganisha muda kwenye muunganisho mwingine wa proxy kabla ya kuamua sababu ya awali.

Lebo za uchambuzi wa dirisha za Wireshark ni tafsiri muhimu za nakala, si maagizo ya kuongeza kila buffer ya kupokea. Window scaling pia inapaswa kufasiriwa kwa kuzingatia majadiliano ya muunganisho.

Kujaribu mwisho mwingine kutoka orodha ya proxy na kuona uhamishaji unapona ni ushahidi muhimu kwamba njia ilibadilika. Hilo peke yake hakuthibitishi kwamba utekelezaji wa TCP wa mfumo mmoja wa uendeshaji ulikuwa na kasoro. Weka maelezo yakihusishwa na mchakato wa kupokea na muunganisho ambapo kusubiri kulianza.

Makala zinazohusiana