TCP nul finster fia in proxy: werk de ûntfanger

In pakkettspoar seit TCP ZeroWindow. Foardat jo in kernelynstelling feroarje, moatte jo it einpunt werke dat de nul oankundiget.

Dat einpunt beskriuwt syn ûntfangstkapasiteit op dy TCP-ferbining. It kundiget net oan hoefolle bânbreedte de hiele proxy hat. In nul-finsterproef lit de stjoerder ûntdekke oft dy oankundige kapasiteit feroare is; proeven allinnich bewize gjin pakketferlies of in stikken proxy.

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

Dit binne aparte TCP-petearen. Stel dat de browser ophâldt mei it lêzen fan in grut antwurd en nul oankundiget op A. De proxy kin úteinlik ophâlde B te leegjen wylst syn eigen buffers folje. In letter nul finster op B kin in gefolch wêze fan 'e stadige kliïnt, net it oarspronklike probleem.

De omkearde situaasje is mooglik by in upload. As de bestimmingstapassing ophâldt mei it konsumearjen fan gegevens, kin syn finster op B tichtgean. De druk kin dan werom reizgje nei de kliïnt fia de buffers fan 'e proxy.

Set de waarnimmings yn oarder

1. Skriuw de einpunten fan 'e ferbining en de rjochting fan 'e troffen gegevensferfier op.
2. Wurkje út hokker einpunt earst in krimpjend of nul ûntfangstfinster oankundige.
3. Kontrolearje oft syn tapassing lies, stilstie by in oare bewurking of beheind wie troch middels.
4. Fergelykje de timing op 'e oare ferbining fan 'e proxy foardat jo de oarspronklike oarsaak tawize.

De finsteranalyzelabels fan Wireshark binne nuttige ynterpretaasjes fan 'e opname, gjin opdracht om elke ûntfangstbuffer te fergrutsjen. Finsterskalering moat ek ynterpretearre wurde mei de ûnderhanneling fan 'e ferbining yn it each.

In oar einpunt besykje út in proxylist en sjen dat de oerdracht weromkomt is nuttich bewiis dat it paad feroare. It bewizet op himsels net dat de TCP-ymplemintaasje fan in bestjoeringssysteem defekt wie. Hâld de ferklearring bûn oan it ûntfangende proses en de ferbining wêr't it wachtsjen begûn.