એક પ્રોક્સી પોર્ટ કેવી રીતે HTTP અને SOCKS બંને સ્વીકારી શકે

મિશ્ર પ્રોક્સી લિસનર એક TCP પોર્ટ પર HTTP અને SOCKS સ્વીકારી શકે છે કારણ કે સર્વર પ્રારંભિક પ્રોટોકોલ બાઇટ્સની તપાસ કરે છે. પોર્ટ નંબર એ ઓળખ કરતો નથી.

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 પ્રોટોકોલ પસંદગી અને પછીથી ડેટાગ્રામ રિલે અલગ ક્ષમતાઓ છે.