Një gjurmë paketash thotë TCP ZeroWindow. Përpara se të ndryshosh një cilësim të kernelit, identifiko cili endpoint shpall zerën.

Ai endpoint përshkruan kapacitetin e tij marrës në atë lidhje TCP. Nuk po shpall sa bandwidth ka në dispozicion i gjithë proxy-i. Një probe zero-window lejon dërguesin të zbulojë nëse kapaciteti i shpallur ka ndryshuar; vetë provat nuk vërtetojnë humbje paketash apo një proxy të prishur.

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

Këto janë dy biseda TCP të ndara. Supozo se shfletuesi ndalon leximin e një përgjigjeje të madhe dhe shpall zero në A. Proxy-i mund të ndalojë përfundimisht tërheqjen nga B ndërsa buffer-at e tij mbushen. Një zero window i mëvonshëm në B mund të jetë pasojë e klientit të ngadaltë, jo problemi origjinal.

Situata e kundërt është e mundshme gjatë një ngarkimi. Nëse aplikacioni destinacion ndalon konsumimin e të dhënave, dritarja e tij në B mund të mbyllet. Presioni mund të udhëtojë pastaj mbrapsht drejt klientit përmes buffer-ave të proxy-t.

Vendosi vëzhgimet sipas radhës

  1. Regjistro endpoint-et e lidhjes dhe drejtimin e transferimit të prekur.
  2. Identifiko cili endpoint shpalli i pari një receive window në tkurrje ose zero.
  3. Kontrollo nëse aplikacioni i tij po lexonte, ishte ndalur në një operacion tjetër, apo i kufizuar nga burimet.
  4. Krahaso kohën në lidhjen tjetër të proxy-t përpara se të caktosh shkakun origjinal.

Etiketat e analizës së dritareve të Wireshark janë interpretime të dobishme të kapjes, jo një udhëzim për të rritur çdo receive buffer. Edhe window scaling duhet interpretuar duke pasur parasysh negocimin e lidhjes.

Të provosh një endpoint tjetër nga një listë proxy dhe të shohësh transferimin të rikuperohet është provë e dobishme se rruga ndryshoi. Nuk vërteton vetvetiu se zbatimi TCP i një sistemi operativ ishte me defekt. Mbaje shpjegimin të lidhur me procesin marrës dhe lidhjen ku filloi pritja.

Artikuj të ngjashëm