Nulové okno TCP cez proxy: určite príjemcu

Nájdite riadenie toku TCP na strane klienta alebo servera proxy skôr, než zaseknuté sťahovanie pripíšete škálovaniu okna alebo veľkosti buffera.

Trasovanie paketov hlási TCP ZeroWindow. Pred zmenou nastavenia jadra určite koncový bod, ktorý nulu oznamuje.

Tento koncový bod opisuje svoju prijímaciu kapacitu na tomto TCP spojení. Neoznamuje, koľko šírky pásma má celý proxy. Sonda nulového okna umožní odosielateľovi zistiť, či sa oznámená kapacita zmenila; samotné sondy nepreukazujú stratu paketov ani pokazený proxy.

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

Sú to oddelené TCP rozhovory. Predpokladajme, že prehliadač prestane čítať veľkú odpoveď a oznámi nulu na A. Proxy môže napokon prestať vyprázdňovať B, ako sa jeho vlastné buffery plnia. Neskoršie nulové okno na B môže byť následkom pomalého klienta, nie pôvodným problémom.

Opačná situácia je možná pri nahrávaní. Ak cieľová aplikácia prestane spotrebúvať dáta, jej okno na B sa môže zavrieť. Tlak sa potom môže šíriť späť ku klientovi cez buffery proxy.

Zoraďte pozorovania

  1. Zapíšte koncové body spojenia a smer postihnutého prenosu dát.
  2. Určite, ktorý koncový bod ako prvý oznámil zmenšujúce sa alebo nulové prijímacie okno.
  3. Overte, či jeho aplikácia čítala, bola pozastavená na inej operácii alebo obmedzená zdrojmi.
  4. Porovnajte časovanie na druhom spojení proxy, než priradíte pôvodnú príčinu.

Popisy analýzy okien vo Wiresharku sú užitočné interpretácie záznamu, nie pokyn zväčšiť každý prijímací buffer. Aj škálovanie okna treba vykladať s ohľadom na vyjednávanie spojenia.

Vyskúšať iný koncový bod zo zoznamu proxy a vidieť, že sa prenos obnoví, je užitočný dôkaz, že sa cesta zmenila. Sám o sebe však nepreukazuje, že implementácia TCP niektorého operačného systému bola chybná. Držte vysvetlenie spojené s prijímajúcim procesom a spojením, kde čakanie začalo.

Súvisiace články