ఒకే ప్రాక్సీ పోర్ట్ HTTP మరియు SOCKS రెండింటినీ ఎలా అంగీకరించగలదు
ఉద్దేశపూర్వకంగా మిశ్రమ లిజనర్ HTTP మరియు SOCKS మధ్య ఎలా భేదం చూపగలదో, సాధారణ ఒకే-ప్రోటోకాల్ లిజనర్ అలా చేయలేదో వివరిస్తుంది.
మిశ్రమ ప్రాక్సీ లిజనర్ ఒకే TCP పోర్ట్పై HTTP మరియు SOCKS అంగీకరించగలదు ఎందుకంటే సర్వర్ ప్రారంభ ప్రోటోకాల్ బైట్లను పరిశీలిస్తుంది. పోర్ట్ నంబర్ ఆ గుర్తింపును చేయదు.
HTTP ప్రాక్సీ అభ్యర్థన GET లేదా CONNECT వంటి HTTP పద్ధతితో ప్రారంభమవుతుంది. SOCKS అభివాదన బైనరీ ప్రోటోకాల్ ఫీల్డ్లతో ప్రారంభమవుతుంది. ఈ ఇన్పుట్ల కోసం రూపొందించిన సాఫ్ట్వేర్ కనెక్షన్ను సరైన హ్యాండ్లర్కు పంపగలదు.
ఇది స్పష్టమైన అమలు లక్షణం. సాధారణ Squid HTTP లిజనర్ తన పోర్ట్ను 1080కి మార్చినందున మిశ్రమం కాదు, మరియు SOCKS మాత్రమే ఉన్న లిజనర్ బ్రౌజర్ సెట్టింగ్ నుండి HTTP నేర్చుకోదు.
TLS మరో సరిహద్దును జోడిస్తుంది: గూఢీకృత ప్రాక్సీ కనెక్షన్ కనిపించే HTTP పద్ధతితో కాక TLS తో ప్రారంభమవుతుంది. అదే ఎండ్పాయింట్పై దాన్ని మద్దతు చేయడానికి అదనపు ఉద్దేశపూర్వక నిర్వహణ అవసరం; సాదా HTTP మరియు SOCKS గుర్తించడం ఆ సామర్థ్యాన్ని నిరూపించదు.
ఎండ్పాయింట్ కోసం డాక్యుమెంట్ చేసిన క్లయింట్ ప్రోటోకాల్ ఉపయోగించండి. రెండూ పనిచేస్తే, అది ఆ సర్వర్ మిశ్రమ లిజనర్ గురించిన సాక్ష్యం, ప్రతి క్లయింట్లో ప్రోటోకాల్ను నిర్దిష్టం చేయకుండా వదలడానికి కారణం కాదు.
Glider మిశ్రమ లిజనర్ ఒక నిర్దిష్ట ఉదాహరణ ఇస్తుంది: అది ఒక బైట్ను వినియోగించకుండా దానిపై కన్నేస్తుంది, 0x05 ను తన SOCKS5 హ్యాండ్లర్కు పంపుతుంది, లేకపోతే తన HTTP పార్సర్ను పిలుస్తుంది. ఆ పార్సర్ ఇప్పటికీ వచ్చే అభ్యర్థనను ధృవీకరిస్తుంది; పంపే ఎంపిక ఏకపక్ష ఇన్పుట్ను చెల్లుబాటు అయ్యే HTTP గా మార్చదు.
TCP లిజనర్ను పంచుకోవడం దానంతటదే SOCKS5 UDP అనుబంధాన్ని అందించదు. Glider తన UDP లిజనర్ను విడిగా ప్రారంభిస్తుంది. TCP ప్రోటోకాల్ ఎంపిక మరియు తరువాతి డేటాగ్రామ్ రిలే వేర్వేరు సామర్థ్యాలు.