ఒక packet trace TCP ZeroWindow అని చూపుతుంది. kernel సెట్టింగ్ను మార్చే ముందు సున్నాను ప్రకటిస్తున్న endpoint ఏదో గుర్తించండి.

ఆ endpoint ఆ TCP కనెక్షన్పై తన స్వీకరణ సామర్థ్యాన్ని వివరిస్తోంది. మొత్తం ప్రాక్సీకి ఎంత bandwidth అందుబాటులో ఉందో అది ప్రకటించడం లేదు. zero-window probe ప్రకటించిన సామర్థ్యం మారిందో లేదో పంపినవాడు తెలుసుకోవడానికి సహాయపడుతుంది; probe మాత్రమే packet నష్టాన్ని లేదా పాడైన ప్రాక్సీని నిరూపించదు.

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

ఇవి వేర్వేరు TCP సంభాషణలు. browser పెద్ద response చదవడం ఆపి A పై సున్నాను ప్రకటిస్తుందని అనుకోండి. ప్రాక్సీ buffers నిండుతున్నప్పుడు అది B నుంచి లాగడం ఆపేయవచ్చు. తర్వాత B పై వచ్చే zero window నెమ్మదైన client వల్ల కలిగిన ఫలితం కావచ్చు, అసలు సమస్య కాదు.

అప్లోడ్ సమయంలో దీనికి విరుద్ధమైన స్థితి సంభవించవచ్చు. గమ్యస్థాన అప్లికేషన్ డేటాను వినియోగించడం ఆపితే, B పై దాని window మూసుకుపోవచ్చు. ఒత్తిడి తర్వాత ప్రాక్సీ buffers ద్వారా క్లయింట్ వైపు తిరిగి ప్రయాణించవచ్చు.

పరిశీలనలను క్రమంలో పెట్టండి

  1. కనెక్షన్ చివరలను, ప్రభావిత డేటా బదిలీ దిశను నమోదు చేయండి.
  2. తగ్గుతున్న లేదా సున్నా అయిన receive window మొదట ప్రకటించిన endpoint ఏదో గుర్తించండి.
  3. దాని అప్లికేషన్ చదువుతోందా, మరో ఆపరేషన్పై ఆగిందా, లేక వనరులతో పరిమితమైందా చూడండి.
  4. అసలు కారణాన్ని నిర్ణయించే ముందు ప్రాక్సీ మరో కనెక్షన్పై సమయాన్ని పోల్చండి.

Wireshark window విశ్లేషణ లేబుళ్లు captureకి ఉపయోగకరమైన వ్యాఖ్యానాలు, ప్రతి receive buffer ను పెంచమని చెప్పే ఆదేశం కాదు. window scaling ను కూడా కనెక్షన్ సంధానం దృష్ట్యా అర్థం చేసుకోవాలి.

ప్రాక్సీ జాబితా నుంచి మరో endpoint ప్రయత్నించి బదిలీ కోలుకోవడం చూడటం మార్గం మారిందనే ఉపయోగకరమైన ఆధారం. అది ఒక ఆపరేటింగ్ సిస్టమ్ TCP అమలు లోపభూయిష్టమని తనంతట తాను నిరూపించదు. వివరణను స్వీకరించే ప్రాసెస్, ఎదురుచూపు ప్రారంభమైన కనెక్షన్కు కట్టిపడేయండి.

సంబంధిత వ్యాసాలు