Een packet trace zegt TCP ZeroWindow. Voordat u een kernelinstelling wijzigt, identificeert u het eindpunt dat de nul aankondigt.

Dat eindpunt beschrijft zijn ontvangstcapaciteit op die TCP-verbinding. Het kondigt niet aan hoeveel bandbreedte de hele proxy heeft. Een nulvensterprobe laat de afzender ontdekken of die aangekondigde capaciteit is veranderd; probes alleen bewijzen geen pakketverlies of een kapotte proxy.

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

Dit zijn afzonderlijke TCP-gesprekken. Stel dat de browser stopt met het lezen van een groot antwoord en nul aankondigt op A. De proxy kan uiteindelijk stoppen met het leeghalen van B naarmate zijn eigen buffers vollopen. Een later nulvenster op B kan een gevolg zijn van de trage client, niet het oorspronkelijke probleem.

De omgekeerde situatie is mogelijk tijdens een upload. Als de bestemmingstoepassing stopt met het verbruiken van gegevens, kan zijn venster op B sluiten. De druk kan dan via de buffers van de proxy terug naar de client reizen.

Zet de waarnemingen in volgorde

  1. Noteer de eindpunten van de verbinding en de richting van de getroffen gegevensoverdracht.
  2. Identificeer welk eindpunt als eerste een krimpend of nul ontvangstvenster aankondigde.
  3. Controleer of de toepassing las, bij een andere bewerking pauzeerde of door middelen beperkt was.
  4. Vergelijk de timing op de andere verbinding van de proxy voordat u de oorspronkelijke oorzaak toewijst.

De vensteranalyselabels van Wireshark zijn nuttige interpretaties van de opname, geen opdracht om elke ontvangstbuffer te vergroten. Ook vensterschaling moet worden geïnterpreteerd met de onderhandeling van de verbinding in het oog.

Een ander eindpunt proberen uit een proxylijst en zien dat de overdracht herstelt, is nuttig bewijs dat het pad is veranderd. Het bewijst op zichzelf niet dat de TCP-implementatie van een besturingssysteem defect was. Houd de verklaring gekoppeld aan het ontvangende proces en de verbinding waar het wachten begon.

Gerelateerde artikelen