Squid గుండా వెళ్ళిన తర్వాత HTTP ప్రతిస్పందన అనేక క్యాప్చర్ చేసిన TCP విభాగాలలో కనిపిస్తుందని అనుకుందాం. అది సాధారణ TCP ప్రవర్తన కావచ్చు, ప్రతిస్పందన తప్పుగా విభజించబడిందనడానికి రుజువు కాదు.

ఫార్వర్డ్ ప్రాక్సీకి సాధారణంగా రెండు కనెక్షన్లు ఉంటాయి:

client ⇄ TCP connection A ⇄ proxy ⇄ TCP connection B ⇄ origin

ప్రతి కనెక్షన్‌కు దాని స్వంత TCP స్థితి, క్రమ సంఖ్యలు మరియు ప్యాకెటీకరణ ఉంటాయి. ప్రాక్సీ ఒక కనెక్షన్ నుండి డేటాను చదివి మరొకదానికి రాయగలదు, అసలు విభాగ పరిమాణాలను కాపాడకుండా. బఫరింగ్, పంపే సమయం, రద్దీ మరియు మార్గం పరిమాణ పరిమితులు మరో సమూహాన్ని సృష్టించవచ్చు.

వేరుగా ఉంచవలసిన మూడు సరిహద్దులు

సరిహద్దుదాన్ని ఏది నిర్ణయిస్తుంది
TCP విభాగంరవాణా మరియు నెట్‌వర్క్ మార్గం
సాకెట్ పఠన ఫలితంఅందుబాటులో ఉన్న స్ట్రీమ్ బైట్‌లు మరియు పిలుచువారి బఫర్
HTTP సందేశం లేదా ఫ్రేమ్HTTP ప్రోటోకాల్ ఫ్రేమింగ్ నియమాలు

ఒక పఠనంలో హెడర్‌లోని కొంత భాగం, పూర్తి హెడర్‌తో పాటు బాడీ బైట్‌లు, లేదా ఒకటి కంటే ఎక్కువ అప్లికేషన్-స్థాయి సరిహద్దులను దాటే డేటా ఉండవచ్చు. TCP “HTTP ప్రతిస్పందన ముగింపు”ను విజయవంతమైన పఠనం ముగింపుకు కలపదు.

అందువల్ల HTTP/1.1 పార్సర్ హెడర్‌లను సేకరించి వర్తించే బాడీ-ఫ్రేమింగ్ నియమాలను ఉపయోగిస్తుంది, వాటిలో పొడవు, బదిలీ కోడింగ్ లేదా అనుమతించిన కనెక్షన్ మూసివేత ఉంటాయి. HTTP/2 ఫ్రేమ్ అనేది TCP విభాగాలను తానే దాటగల ప్రోటోకాల్ నిర్మాణం; అది నెట్‌వర్క్ ప్యాకెట్‌కు మరో పేరు కాదు.

విజయవంతమైన CONNECT సొరంగం సొరంగంలోని బైట్ ప్రవాహాన్ని కాపాడుతుంది, అయినా రెండు TCP కాళ్ళను ఉపయోగిస్తుంది. ప్రాక్సీ సొరంగం లోపలి బైట్‌లను మార్చకపోయినా దాని విభాగ సరిహద్దులు భిన్నంగా ఉండవచ్చు.

పాడైన సమస్యను దర్యాప్తు చేసేటప్పుడు తిరిగి కలిపిన అప్లికేషన్ డేటాను పోల్చండి. ప్యాకెట్ల సంఖ్యను పోల్చడం లేదా రెండు వైపులా ఒకే ప్యాకెట్ పొడవును ఆశించడం TCP అందించని సరిహద్దు హామీని అడగడమే.

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