CH-J Server ManagerSSH کے ذریعے سرور کا انتظام
مینو
تمام رہنما اور مضامین ←

کیسے تصدیق کریں کہ HTTP/3 اور QUIC واقعی کام کر رہے ہیں

Alt-Svc ہیڈر ثبوت کیوں نہیں، NGINX اور فائر وال میں کیا جانچنا چاہیے، اور حقیقی QUIC منتقلی کی تصدیق کیسے کریں۔

اعلان کا مطلب کام کرنا نہیں

سرور جوابی ہیڈر Alt-Svc میں HTTP/3 کا اعلان کرتا ہے، جو کلائنٹ کو ان میں سے کسی پروٹوکول کے ذریعے ملتا ہے: HTTP/1.1 یا HTTP/2. یہ ہیڈر محض ایک وعدہ ہے۔ HTTP/3 UDP پر QUIC کے ذریعے چلتا ہے، اس لیے UDP مکمل طور پر بند ہونے کے باوجود صفحہ معمول کے مطابق لوڈ ہو سکتا ہے اور براؤزر خاموشی سے HTTP/2 ہی استعمال کرتا رہتا ہے۔

curl -sI https://server.example/ | grep -i alt-svc

حقیقی منتقلی کی تصدیق کریں

صرف QUIC کے ذریعے مکمل ہونے والی درخواست ہی اس پروٹوکول کے کام کرنے کی تصدیق کرتی ہے: HTTP/3. ایسا curl استعمال کریں جسے HTTP/3 کی معاونت کے ساتھ بنایا گیا ہو؛ بہت سے سسٹم پیکیجوں میں یہ معاونت نہیں ہوتی، اس صورت میں اختیار مسترد ہو جاتا ہے، جو سرور کے بارے میں کچھ ثابت نہیں کرتا۔ براؤزر میں ڈویلپر ٹولز کھولیں اور Protocol کالم دیکھیں، جو ایسی درخواست کے لیے h3 دکھاتا ہے۔ پہلی بار صفحہ کھولنے پر براؤزر HTTP/2 استعمال کر سکتا ہے، اس لیے صفحہ دوبارہ لوڈ کریں۔

curl -V | grep -i http3
curl -sS --http3-only -o /dev/null -w '%{http_version}\n' https://server.example/

NGINX کی ترتیب جانچیں

NGINX کو TCP لسنر کے ساتھ QUIC لسنر بھی درکار ہوتا ہے، اور اس کا ورژن اور بلڈ دونوں اس کی معاونت کرتے ہوں۔ TLS 1.3 ضروری ہے کیونکہ QUIC اسے براہ راست استعمال کرتا ہے۔ دوبارہ لوڈ کرنے سے پہلے ترتیب جانچیں۔ Alt-Svc میں ma کی قدر سیکنڈوں میں وہ مدت ہے جس تک کلائنٹ اس وعدے کو یاد رکھتے ہیں، اس لیے جانچ کے دوران مختصر مدت رکھیں۔

listen 443 ssl;
listen 443 quic reuseport;
http2 on;
add_header Alt-Svc 'h3=":443"; ma=300' always;

nginx -V 2>&1 | grep -o with-http_v3_module
sudo nginx -t

پورے راستے میں UDP 443 کھولیں

ناکامی کی سب سے عام وجہ ایسا فائر وال ہے جو TCP 443 کی اجازت دیتا ہے لیکن UDP 443 کی نہیں۔ سرور اور کسی بھی بیرونی فلٹر کو جانچیں۔ سرور پر تصدیق کی جا سکتی ہے کہ ساکٹ سن رہا ہے۔ بعض اداروں کے اور عوامی نیٹ ورک جان بوجھ کر QUIC کو روکتے ہیں، اس لیے ایک نیٹ ورک سے جانچ ناکام ہونے کا مطلب یہ نہیں کہ سرور میں خرابی ہے: اسے کسی دوسرے نیٹ ورک سے دہرائیں۔

sudo ss -lunp | grep ':443'
sudo ufw allow 443/udp
sudo tcpdump -ni any udp port 443

کیا نیا پروٹوکول زیادہ تیز ہے؟

HTTP/3 ان کنکشنز پر سب سے زیادہ مدد دیتا ہے جہاں پیکٹ ضائع ہوتے ہوں یا نیٹ ورک بدلتے ہوں، کیونکہ ایک پیکٹ ضائع ہونے سے دوسری اسٹریمز نہیں رکتیں۔ اچھے تار والے کنکشن پر فرق کم ہو سکتا ہے اور سرور پر CPU کا استعمال بڑھ سکتا ہے۔ فائدہ فرض کرنے کے بجائے اپنی صورت حال میں پیمائش کریں، اور ایسے کلائنٹس کے لیے HTTP/2 دستیاب رکھیں جو UDP استعمال نہیں کر سکتے۔

CH-J Server Manager میں HTTP/3 کی جانچ

Server Diagnostics کے ساتھ HTTP کلائنٹ شامل ہوتا ہے، اس لیے جانچ سسٹم کے curl پر منحصر نہیں ہوتی۔ یہ صرف مکمل QUIC منتقلی کے بعد HTTP/3 کو تصدیق شدہ بتاتا ہے اور Alt-Svc کو محض اعلان سمجھتا ہے۔ UDP کی مہلت ختم ہونے پر یہ بتاتا ہے کہ سرور کی معاونت کی تصدیق ابھی نہیں ہوئی، کیونکہ وجہ آپ اور سرور کے درمیان نیٹ ورک بھی ہو سکتا ہے، اور یہ دوسرے پروٹوکول پر منتقل ہونے کو کامیابی شمار نہیں کرتا۔

تفصیلی دستاویزات

RFC 9114: HTTP/3 ←

NGINX: QUIC and HTTP/3 ←

بایومیٹرک اَن لاک اور سیکیورٹی ←