Снимката на пакети покажува TCP ZeroWindow. Пред да промените поставка на јадрото, препознајте ја крајната точка што ја објавува нулата.

Таа крајна точка го опишува својот капацитет за прием на таа TCP врска. Не објавува колку пропусен опсег има целото прокси. Сондата за нулти прозорец му овозможува на испраќачот да открие дали објавениот капацитет се променил; самите сонди не докажуваат загуба на пакети или расипано прокси.

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

Ова се одделни TCP разговори. Претпоставете дека прелистувачот престанал да чита голем одговор и објавува нула на A. Проксито на крајот може да престане да го празни B како што се полнат неговите бафери. Подоцнежен нулти прозорец на B може да е последица од бавниот клиент, а не од првобитниот проблем.

Обратната ситуација е возможна при поставување. Ако целната апликација престане да троши податоци, нејзиниот прозорец на B може да се затвори. Притисокот потоа може да патува назад кон клиентот низ баферите на проксито.

Ставете ги набљудувањата во ред

  1. Забележете ги крајните точки на врската и насоката на погодениот пренос на податоци.
  2. Препознајте која крајна точка прва објавила прозорец за прием што се намалува или е нула.
  3. Проверете дали нејзината апликација читала, застанала на друга операција или била ограничена со ресурси.
  4. Споредете го времето на другата врска на проксито пред да ја одредите првобитната причина.

Ознаките за анализа на прозорци во Wireshark се корисни толкувања на снимката, а не упатство да го зголемите секој бафер за прием. И скалирањето на прозорецот треба да се толкува со оглед на преговорите на врската.

Пробата на друга крајна точка од список со проксија и гледањето дека преносот закрепнува е корисен доказ дека патеката се променила. Сепак, само по себе тоа не докажува дека TCP-имплементацијата на некој оперативен систем била дефектна. Држете го објаснувањето врзано за процесот што прима и за врската каде што започнало чекањето.

Поврзани статии