'n Pakketspoorsnit sê TCP ZeroWindow. Voordat jy 'n kerninstelling verander, bepaal watter eindpunt die nul adverteer.

Daardie eindpunt beskryf sy ontvangsvermoë op daardie TCP-verbinding. Dit kondig nie aan hoeveel bandwydte die hele proxy beskikbaar het nie. 'n Nulvenster-probe laat die sender ontdek of daardie geadverteerde vermoë verander het; probe alleen bewys nie pakkieverlies of 'n stukkende proxy nie.

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

Dit is afsonderlike TCP-gesprekke. Veronderstel die blaaier hou op om 'n groot antwoord te lees en adverteer nul op A. Die proxy kan uiteindelik ophou om B te dreineer namate sy eie buffers vol raak. 'n Latere nulvenster op B kan 'n gevolg van die stadige kliënt wees, eerder as die oorspronklike probleem.

Die omgekeerde situasie is tydens 'n oplaai moontlik. As die bestemmingsprogram ophou om data te verbruik, kan sy venster op B sluit. Druk kan dan terug na die kliënt beweeg deur die proxy se buffers.

Plaas die waarnemings in orde

  1. Noteer die verbinding se eindpunte en die rigting van die betrokke data-oordrag.
  2. Bepaal watter eindpunt eerste 'n krimpende of nul ontvangsvenster geadverteer het.
  3. Kontroleer of sy program gelees het, op 'n ander bewerking gewag het, of deur hulpbronne beperk is.
  4. Vergelyk die tydsberekening op die proxy se ander verbinding voordat jy die oorspronklike oorsaak toeken.

Wireshark se vensteranalise-etikette is nuttige interpretasies van die opname, nie 'n opdrag om elke ontvangsbuffer te vergroot nie. Vensterskaal moet ook met die verbinding se onderhandeling in gedagte geïnterpreteer word.

Om 'n ander eindpunt uit 'n proxylys te probeer en te sien dat die oordrag herstel, is nuttige bewyse dat die pad verander het. Dit bewys op sigself nie dat een bedryfstelsel se TCP-implementering foutief was nie. Hou die verklaring gekoppel aan die ontvangende proses en die verbinding waar die wag begin het.

Verwante artikels