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 പോർട്ട് പരിശോധനയോ ചെറിയ ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു.