የHTTP/3 ጥያቄ 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 ያሉ ስታንዳርዶች UDPን በHTTP ፕሮክሲ ስርዓት ለማጓጓዝ ሌላ መንገድ ይገልጻሉ። በሁለቱም ወገን ድጋፍ ይፈልጋሉ እና ከባህላዊ CONNECT ጋር መምታታት የለባቸውም።

የHTTP ደንበኛው በTCP ላይ ወደ HTTP/2 ወይም HTTP/1.1 ከተመለሰ፣ ጥያቄው በተራ ፕሮክሲ ሊሳካ ይችላል፣ HTTP/3 ግንዛቤ ግን አልተጠቀመም። ይህ ልዩነት አስፈላጊ ሲሆን የተደራደረውን ፕሮቶኮል ይመዝግቡ።

ስለዚህ ጠቃሚው የተኳኋኝነት ጥያቄ ልዩ ነው፦ ይህ ደንበኛ የQUIC ዳታግራሞቹን በዚህ ፕሮክሲ በዚህ የተደገፈ ዘዴ ማሳለፍ ይችላል? የሚሰራ የአሳሽ ገጽ ወይም የTCP ወደብ ፍተሻ ትንሽ ጥያቄን ይመልሳል።