Paketni posnetek pravi TCP ZeroWindow. Preden spremenite nastavitev jedra, prepoznajte končno točko, ki naznani ničlo.

Ta končna točka opisuje svojo zmogljivost sprejemanja na tej TCP povezavi. Ne naznani, koliko pasovne širine ima celoten proxy. Sonda ničelnega okna omogoči pošiljatelju, da ugotovi, ali se je naznanjena zmogljivost spremenila; sonde same po sebi ne dokazujejo izgube paketov ali pokvarjenega proxyja.

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

To sta ločena TCP pogovora. Recimo, da brskalnik preneha brati velik odgovor in naznani ničlo na A. Proxy lahko sčasoma preneha prazniti B, ko se njegovi medpomnilniki napolnijo. Kasnejše ničelno okno na B je lahko posledica počasnega odjemalca, ne prvotna težava.

Obratna situacija je mogoča med pošiljanjem. Če ciljna aplikacija preneha porabljati podatke, se njeno okno na B lahko zapre. Pritisk lahko nato potuje nazaj proti odjemalcu skozi medpomnilnike proxyja.

Uredite opažanja po vrsti

  1. Zapišite končni točki povezave in smer prizadetega prenosa podatkov.
  2. Ugotovite, katera končna točka je prva naznanila krčeče se ali ničelno sprejemno okno.
  3. Preverite, ali je njena aplikacija brala, se ustavila pri drugi operaciji ali bila omejena z viri.
  4. Primerjajte čas na drugi povezavi proxyja, preden določite prvotni vzrok.

Oznake analize oken v Wiresharku so koristne razlage posnetka, ne navodilo, naj povečate vsak sprejemni medpomnilnik. Tudi skaliranje okna je treba razlagati ob upoštevanju pogajanj povezave.

Preizkus druge končne točke s seznama proxyjev in videnje, da si prenos opomore, je koristen dokaz, da se je pot spremenila. Samo po sebi pa ne dokazuje, da je bila izvedba TCP katerega operacijskega sistema pomanjkljiva. Razlago držite povezano s sprejemnim procesom in povezavo, kjer se je čakanje začelo.

Sorodni članki