HTTP/3 ଅନୁରୋଧ ପାଇଁ UDP ସକ୍ଷମ ପ୍ରକ୍ସି ପଥ ଆବଶ୍ୟକ
HTTP/3 ର QUIC ପରିବହନକୁ ସାଧାରଣ HTTP CONNECT TCP ଟନେଲ ଏବଂ SOCKS5 ସେବାର ବୈକଳ୍ପିକ UDP ସମର୍ଥନଠାରୁ ଅଲଗା କରନ୍ତୁ।
TCP ପ୍ରକ୍ସି ମାଧ୍ୟମରେ HTTPS କୁ ସଫଳତାର ସହ ପହଞ୍ଚିଥିବା କ୍ଲାଏଣ୍ଟ HTTP/3 ପାଇଁ ପଥ ସ୍ଥାପନ କରିନାହିଁ। HTTP/3 QUIC ବ୍ୟବହାର କରେ, ଏବଂ QUIC UDP ବ୍ୟବହାର କରେ।
ସାଧାରଣ HTTP CONNECT ଟନେଲ ଏହାର ଲକ୍ଷ୍ୟସ୍ଥାନ ପର୍ଯ୍ୟନ୍ତ TCP ଷ୍ଟ୍ରିମ ଦିଏ। URL HTTPS ସହ ଆରମ୍ଭ ହେଲେ କିମ୍ବା ଲକ୍ଷ୍ୟସ୍ଥାନ 443 ପୋର୍ଟରେ ଶୁଣିଲେ ମଧ୍ୟ ଏହା UDP ରିଲେ ହୋଇଯାଏ ନାହିଁ।
SOCKS5 ମଧ୍ୟ UDP ପଥ ଆବଶ୍ୟକ କରେ
SOCKS5 UDP ସଂଯୋଗକୁ ସଂଜ୍ଞା ଦିଏ, କିନ୍ତୁ କ୍ଲାଏଣ୍ଟ ଏବଂ ସର୍ଭର ଉଭୟେ ଏହାକୁ ଲାଗୁ କରିବାକୁ ପଡ଼ିବ, ଏବଂ ରିଲେ ଏଣ୍ଡପଏଣ୍ଟ ପ୍ରାପ୍ୟ ହେବା ଆବଶ୍ୟକ। କେବଳ SOCKS TCP ଡାୟଲର ଦେଉଥିବା ଲାଇବ୍ରେରୀ କେବଳ ଏହାର ପ୍ରକାର ନାମ SOCKS5 ଥିବା କାରଣରୁ ଡେଟାଗ୍ରାମ ପରିବହନ ଦେଇପାରିବ ନାହିଁ।
ସେହିପରି, କୌଣସି ଟୁଲର proxy ନାମକ ଉପାଦାନ ସାଧାରଣ ଅପଷ୍ଟ୍ରିମ-ପ୍ରକ୍ସି କ୍ଲାଏଣ୍ଟ ନୁହେଁ, ବରଂ ବିକାଶ ପ୍ୟାକେଟ-କ୍ଷତି ସିମୁଲେଟର ହୋଇପାରେ। ଏହାର ପ୍ରକୃତ ଇଣ୍ଟରଫେସ ଏବଂ ସମର୍ଥିତ ପରିବହନ ଯାଞ୍ଚ କରନ୍ତୁ।
CONNECT-UDP ଭଳି ମାନକ HTTP ପ୍ରକ୍ସି ସିଷ୍ଟମ ମାଧ୍ୟମରେ UDP ବହନ କରିବାର ଅନ୍ୟ ଉପାୟ ସଂଜ୍ଞା ଦିଏ। ସେମାନେ ଉଭୟ ପ୍ରାନ୍ତରେ ସମର୍ଥନ ଆବଶ୍ୟକ କରନ୍ତି ଏବଂ ପାରମ୍ପରିକ CONNECT ସହ ମିଶ୍ରିତ କରାଯିବା ଉଚିତ ନୁହେଁ।
ଯଦି HTTP କ୍ଲାଏଣ୍ଟ TCP ଉପରେ HTTP/2 କିମ୍ବା HTTP/1.1 କୁ ଫେରିଯାଏ, ତେବେ HTTP/3 ସଂଯୋଗ ବ୍ୟବହାର ନ କରି ସାଧାରଣ ପ୍ରକ୍ସି ମାଧ୍ୟମରେ ଅନୁରୋଧ ସଫଳ ହୋଇପାରେ। ସେହି ପାର୍ଥକ୍ୟ ଗୁରୁତ୍ୱପୂର୍ଣ୍ଣ ହେଲେ ବୁଝାମଣା ପ୍ରୋଟୋକଲ ରେକର୍ଡ କରନ୍ତୁ।
ତେଣୁ ଉପଯୋଗୀ ସୁସଙ୍ଗତତା ପ୍ରଶ୍ନ ନିର୍ଦ୍ଦିଷ୍ଟ: ଏହି କ୍ଲାଏଣ୍ଟ ଏହି ସମର୍ଥିତ ଯନ୍ତ୍ରରେ ଏହି ପ୍ରକ୍ସି ମାଧ୍ୟମରେ ନିଜର QUIC ଡେଟାଗ୍ରାମ ବହନ କରିପାରିବ କି? କାର୍ଯ୍ୟକ୍ଷମ ବ୍ରାଉଜର ପୃଷ୍ଠା କିମ୍ବା TCP ପୋର୍ଟ ଯାଞ୍ଚ ଛୋଟ ପ୍ରଶ୍ନର ଉତ୍ତର ଦିଏ।