አንድ የፕሮክሲ ፖርት እንዴት HTTP እና SOCKS ሁለቱንም ሊቀበል ይችላል

የተቀላቀለ የፕሮክሲ አድማጭ HTTP እና SOCKS ን በአንድ TCP ፖርት ላይ መቀበል ይችላል፣ ምክንያቱም አገልጋዩ የመጀመሪያዎቹን የፕሮቶኮል ባይቶች ይመረምራል። የፖርቱ ቁጥር ያንን መለያ አያደርግም።

የHTTP ፕሮክሲ ጥያቄ በHTTP ዘዴ ይጀምራል፣ እንደ GET ወይም CONNECT። የSOCKS ሰላምታ በሁለትዮሽ የፕሮቶኮል መስኮች ይጀምራል። ለእነዚህ ግብዓቶች የተነደፈ ሶፍትዌር ግንኙነቱን ወደ ተገቢው አስተናጋጅ ማስተላለፍ ይችላል።

ይህ ግልጽ የአተገባበር ባህሪ ነው። መደበኛ የ Squid HTTP አድማጭ ፖርቱ ወደ 1080 ስለተቀየረ የተቀላቀለ አይሆንም፣ እና SOCKS-ብቻ አድማጭ ከአሳሽ ቅንብር HTTP አይማርም።

TLS ሌላ ድንበር ይጨምራል፦ የተመሰጠረ የፕሮክሲ ግንኙነት በTLS ይጀምራል፣ በሚታየው የHTTP ዘዴ አይደለም። በተመሳሳይ መጨረሻ ነጥብ ላይ ይህን መደገፍ ተጨማሪ ሆን ተብሎ የተደረገ አያያዝ ይፈልጋል፤ ግልጽ HTTP እና SOCKS ን መለየት ያንን ችሎታ አያረጋግጥም።

ለመጨረሻ ነጥቡ የተመዘገበውን የደንበኛ ፕሮቶኮል ይጠቀሙ። ሁለቱም ከሰሩ፣ ያ ስለዚያ አገልጋይ የተቀላቀለ አድማጭ ማስረጃ ነው፣ ፕሮቶኮሉን በሁሉም ደንበኛ ውስጥ ሳይገለጽ ለመተው ምክንያት አይደለም።

የGlider የተቀላቀለ አድማጭ ተጨባጭ ምሳሌ ይሰጣል፦ ሳይበላው አንድ ባይት ይመለከታል፣ 0x05 ን ወደ SOCKS5 አስተናጋጁ ይልካል፣ አለበለዚያ የHTTP ተንታኙን ይጠራል። ያ ተንታኝ አሁንም የሚመጣውን ጥያቄ ያረጋግጣል፤ የመላክ ምርጫ የዘፈቀደ ግብዓትን ትክክለኛ HTTP አያደርግም።

የTCP አድማጭን መጋራት በራሱ SOCKS5 UDP ትስስር አያቀርብም። Glider የUDP አድማጩን ለየብቻ ይጀምራል። የTCP ፕሮቶኮል ምርጫ እና በኋላ ያለው የዳታግራም ማስተላለፍ የተለያዩ ችሎታዎች ናቸው።