একটি 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 পোর্ট পরীক্ষা ছোট প্রশ্নের উত্তর দেয়।