ଏକ ପ୍ରକ୍ସି ପୋର୍ଟ କିପରି HTTP ଏବଂ SOCKS ଉଭୟକୁ ଗ୍ରହଣ କରିପାରେ
ଜାଣିଶୁଣି ମିଶ୍ରିତ ଲିସନର 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 ପ୍ରୋଟୋକଲ ଚୟନ ଏବଂ ପରବର୍ତ୍ତୀ ଡାଟାଗ୍ରାମ ରିଲେ ଅଲଗା କ୍ଷମତା।