এটা TCP proxy ৰ জৰিয়তে HTTPS লৈ সফলভাৱে পোৱা client এ HTTP/3 ৰ বাবে পথ স্থাপন কৰা নাই। HTTP/3 এ QUIC ব্যৱহাৰ কৰে, আৰু QUIC এ UDP ব্যৱহাৰ কৰে।

সাধাৰণ HTTP CONNECT tunnel এ ইয়াৰ গন্তব্যস্থানলৈ TCP stream প্ৰদান কৰে। URL টো HTTPS ৰে আৰম্ভ হ'লে বা গন্তব্যই port 443 ত শুনিলে ই UDP relay লৈ পৰিণত নহয়।

SOCKS5 ৰো UDP পথ প্ৰয়োজন

SOCKS5 এ UDP association সংজ্ঞায়িত কৰে, কিন্তু client আৰু server দুয়োটেই ইয়াক ৰূপায়ণ কৰিব লাগে, আৰু relay endpoint টো উপলব্ধ হ'ব লাগে। কেৱল SOCKS TCP dialer আগবঢ়োৱা library এ ইয়াৰ type name টো SOCKS5 বুলি থকাৰ কাৰণে datagram transport যোগান ধৰিব নোৱাৰে।

একেদৰে, কোনো tool ৰ proxy নামৰ component এ সাধাৰণ upstream-proxy client নহয়, বিকাশকালীন packet-loss simulator হ'ব পাৰে। ইয়াৰ প্ৰকৃত interface আৰু সমৰ্থিত transport পৰীক্ষা কৰক।

CONNECT-UDP ৰ দৰে standard এ HTTP proxy ব্যৱস্থাৰ মাজেৰে UDP কঢ়িয়াবলৈ আন উপায় সংজ্ঞায়িত কৰে। ইয়াৰ বাবে দুয়োফালে সমৰ্থন প্ৰয়োজন আৰু ইয়াক পৰম্পৰাগত CONNECT ৰ সৈতে মিলাই নল'ব।

যদি HTTP client এ TCP ৰ ওপৰত HTTP/2 বা HTTP/1.1 লৈ ঘূৰি যায়, অনুৰোধটো সাধাৰণ proxy ৰ জৰিয়তে সফল হ'ব পাৰে যদিও কোনো HTTP/3 সংযোগ ব্যৱহাৰ হোৱা নাই। এই পাৰ্থক্য গুৰুত্বপূৰ্ণ হ'লে negotiated protocol লিপিবদ্ধ কৰক।

সেয়া হ'লে উপযোগী compatibility প্ৰশ্নটো নিৰ্দিষ্ট: এই client এ এই সমৰ্থিত ব্যৱস্থাৰে এই proxy ৰ মাজেৰে ইয়াৰ QUIC datagram কঢ়িয়াব পাৰিবনে? কাৰ্যক্ষম browser পৃষ্ঠা বা TCP port পৰীক্ষাই সৰু প্ৰশ্নৰ উত্তৰ দিয়ে।

সম্পৰ্কিত প্ৰবন্ধ