20 سال سے زیادہ عرصے سے ہم HTTP پروٹوکول کا استعمال کرتے ہوئے ویب صفحات دیکھ رہے ہیں۔ زیادہ تر صارفین یہ نہیں سوچتے کہ یہ کیا ہے اور یہ کیسے کام کرتا ہے۔ دوسرے جانتے ہیں کہ HTTP کے تحت کہیں TLS ہے، اور اس کے نیچے TCP ہے، جس کے تحت IP ہے، وغیرہ۔ اور پھر بھی دوسرے - بدعتی - یقین رکھتے ہیں کہ TCP ماضی کی چیز ہے؛ وہ کچھ تیز، زیادہ قابل اعتماد اور محفوظ چاہتے ہیں۔ لیکن ایک نیا مثالی پروٹوکول ایجاد کرنے کی کوششوں میں، وہ 80 کی دہائی کی ٹیکنالوجی کی طرف لوٹ آئے ہیں اور اس پر اپنی بہادر نئی دنیا بنانے کی کوشش کر رہے ہیں۔
ایک چھوٹی سی تاریخ: HTTP/1.1
1997 میں، ٹیکسٹ انفارمیشن ایکسچینج پروٹوکول HTTP ورژن 1.1 نے اپنا RFC حاصل کیا۔ اس وقت، پروٹوکول براؤزرز کے ذریعے کئی سالوں سے استعمال کیا جا رہا تھا، اور نیا معیار مزید پندرہ تک جاری رہا۔ پروٹوکول صرف درخواست کے جواب کے اصول پر کام کرتا تھا اور اس کا مقصد بنیادی طور پر متن کی معلومات کی ترسیل کے لیے تھا۔
HTTP کو TCP پروٹوکول کے اوپر چلنے کے لیے ڈیزائن کیا گیا تھا، اس بات کو یقینی بناتے ہوئے کہ پیکٹ قابل اعتماد طریقے سے ان کی منزل تک پہنچائے جائیں۔ TCP اینڈ پوائنٹ کے درمیان ایک قابل اعتماد کنکشن قائم کرنے اور برقرار رکھنے اور ٹریفک کو حصوں میں تقسیم کرکے کام کرتا ہے۔ سیگمنٹس کا اپنا سیریل نمبر اور چیکسم ہوتا ہے۔ اگر اچانک سیگمنٹ میں سے ایک نہیں آتا یا غلط چیکسم کے ساتھ آتا ہے، تو ٹرانسمیشن اس وقت تک رک جائے گی جب تک کہ گم شدہ سیگمنٹ بحال نہ ہو جائے۔
HTTP/1.0 میں، ہر درخواست کے بعد TCP کنکشن بند کر دیا گیا تھا۔ یہ انتہائی فضول تھا، کیونکہ... TCP کنکشن (3-Way-handshake) قائم کرنا ایک سست عمل ہے۔ HTTP/1.1 نے زندہ رکھنے کا طریقہ کار متعارف کرایا، جو آپ کو متعدد درخواستوں کے لیے ایک کنکشن کو دوبارہ استعمال کرنے کی اجازت دیتا ہے۔ تاہم، چونکہ یہ آسانی سے رکاوٹ بن سکتا ہے، لہذا HTTP/1.1 کے مختلف نفاذ سے متعدد TCP کنکشن ایک ہی میزبان کے لیے کھولے جا سکتے ہیں۔ مثال کے طور پر، کروم اور فائر فاکس کے حالیہ ورژن چھ کنکشن کی اجازت دیتے ہیں۔
انکرپشن کو بھی دوسرے پروٹوکول پر چھوڑ دیا جانا تھا، اور اس کے لیے TCP پر TLS پروٹوکول استعمال کیا گیا، جس نے ڈیٹا کو قابل اعتماد طریقے سے محفوظ کیا، لیکن کنکشن قائم کرنے کے لیے درکار وقت میں مزید اضافہ کیا۔ نتیجے کے طور پر، مصافحہ کا عمل اس طرح نظر آنے لگا:
Cloudflare کی مثال
اس طرح HTTP/1.1 میں کئی مسائل تھے:
- سست کنکشن سیٹ اپ۔
- ڈیٹا کو ٹیکسٹ کی شکل میں منتقل کیا جاتا ہے، جس کا مطلب ہے کہ تصاویر، ویڈیوز اور دیگر غیر متنی معلومات کی ترسیل غیر موثر ہے۔
- ایک درخواست کے لیے ایک TCP کنکشن استعمال کیا جاتا ہے، جس کا مطلب ہے کہ دوسری درخواستوں کو یا تو دوسرا کنکشن تلاش کرنا چاہیے یا موجودہ درخواست کے جاری ہونے تک انتظار کرنا چاہیے۔
- صرف پل ماڈل سپورٹ ہے۔ سرور پش کے بارے میں معیار میں کچھ نہیں ہے۔
- عنوانات متن میں منتقل کیے جاتے ہیں۔
اگر سرور پش کو کم از کم WebSocket پروٹوکول کا استعمال کرتے ہوئے لاگو کیا جاتا ہے، تو باقی مسائل کو زیادہ بنیادی طور پر نمٹنا ہوگا۔
تھوڑی سی جدیدیت: HTTP/2
2012 میں، گوگل نے SPDY (تلفظ "تیز") پروٹوکول پر کام کرنا شروع کیا۔ پروٹوکول کو HTTP/1.1 کے اہم مسائل کو حل کرنے کے لیے ڈیزائن کیا گیا تھا اور ساتھ ہی اسے پسماندہ مطابقت کو برقرار رکھنا تھا۔ 2015 میں، IETF ورکنگ گروپ نے SPDY پروٹوکول کی بنیاد پر HTTP/2 تفصیلات متعارف کروائیں۔ HTTP/2 میں یہ اختلافات ہیں:
- بائنری سیریلائزیشن۔
- متعدد HTTP درخواستوں کو ایک TCP کنکشن میں ملٹی پلیکس کرنا۔
- سرور پش آؤٹ آف باکس (ویب ساکٹ کے بغیر)۔
پروٹوکول ایک بہت بڑا قدم تھا۔ اس نے سختی سے اور متعدد TCP کنکشن بنانے کی ضرورت نہیں ہے: ایک میزبان کی تمام درخواستیں ایک میں ملٹی پلیکس کی جاتی ہیں۔ یعنی، ایک سلسلے میں کئی نام نہاد سلسلے ہیں، جن میں سے ہر ایک کی اپنی شناخت ہے۔ بونس ایک باکسڈ سرور پش ہے۔
تاہم، ملٹی پلیکسنگ ایک اور اہم مسئلہ کی طرف جاتا ہے. تصور کریں کہ ہم ایک سرور سے 5 درخواستوں کو متضاد طور پر انجام دے رہے ہیں۔ HTTP/2 کا استعمال کرتے وقت، یہ تمام درخواستیں ایک ہی TCP کنکشن کے اندر کی جائیں گی، جس کا مطلب ہے کہ اگر کسی بھی درخواست کے سیگمنٹ میں سے کوئی ایک گم ہو جاتا ہے یا غلط طریقے سے موصول ہوتا ہے، تو تمام درخواستوں اور جوابات کی ترسیل اس وقت تک بند ہو جائے گی جب تک کہ گم شدہ سیگمنٹ نہیں ہو جاتا۔ بحال ظاہر ہے، کنکشن کا معیار جتنا خراب ہوگا، HTTP/2 کام اتنا ہی کم ہوگا۔ ، ایسے حالات میں جہاں کھوئے ہوئے پیکٹ تمام پیکٹوں کا 2% ہوتے ہیں، براؤزر میں HTTP/1.1 HTTP/2 سے بہتر کارکردگی کا مظاہرہ کرتا ہے کیونکہ یہ ایک کے بجائے 6 کنکشن کھولتا ہے۔
اس مسئلے کو "ہیڈ آف لائن بلاکنگ" کہا جاتا ہے اور بدقسمتی سے، TCP استعمال کرتے وقت اسے حل کرنا ممکن نہیں ہے۔
ڈینیل سٹینبرگ کی طرف سے مثال
نتیجے کے طور پر، HTTP/2 معیار کے ڈویلپرز نے بہت اچھا کام کیا اور تقریباً ہر وہ کام کیا جو OSI ماڈل کی ایپلیکیشن لیئر پر کیا جا سکتا تھا۔ یہ ٹرانسپورٹ کی تہہ پر جانے اور ایک نیا ٹرانسپورٹ پروٹوکول ایجاد کرنے کا وقت ہے۔
ہمیں ایک نئے پروٹوکول کی ضرورت ہے: UDP بمقابلہ TCP
بہت جلد یہ واضح ہو گیا کہ بالکل نئے ٹرانسپورٹ لیئر پروٹوکول کو نافذ کرنا آج کی حقیقتوں میں ایک ناممکن کام ہے۔ حقیقت یہ ہے کہ ہارڈ ویئر یا مڈل باکسز (راؤٹرز، فائر والز، NAT سرورز...) ٹرانسپورٹ کی تہہ کے بارے میں جانتے ہیں، اور انہیں کچھ نیا سکھانا ایک انتہائی مشکل کام ہے۔ اس کے علاوہ، آپریٹنگ سسٹم کے کرنل میں ٹرانسپورٹ پروٹوکول کے لیے سپورٹ بنایا گیا ہے، اور دانا بھی تبدیل کرنے کے لیے بہت زیادہ تیار نہیں ہیں۔
اور یہاں کوئی ہاتھ اٹھا کر کہہ سکتا ہے کہ "یقینا ہم ترجیحات اور درباریوں کے ساتھ ایک نیا HTTP/3 ایجاد کریں گے، لیکن اس پر عمل درآمد ہونے میں 10-15 سال لگیں گے (اس وقت کے بعد زیادہ تر ہارڈویئر تبدیل کیا گیا ہے)"، لیکن ایک اور نہیں ہے، واضح آپشن UDP پروٹوکول استعمال کرنا ہے۔ ہاں، ہاں، وہی پروٹوکول جو ہم نوے کی دہائی کے آخر اور XNUMX کی دہائی کے اوائل میں LAN پر فائلیں پھینکتے تھے۔ آج کے تقریباً تمام ہارڈ ویئر اس کے ساتھ کام کر سکتے ہیں۔
TCP پر UDP کے کیا فائدے ہیں؟ سب سے پہلے، ہمارے پاس ٹرانسپورٹ لیئر سیشن نہیں ہے جس کے بارے میں ہارڈ ویئر جانتا ہے۔ یہ ہمیں اختتامی نکات پر سیشن کا تعین کرنے اور وہاں تنازعات کو حل کرنے کی اجازت دیتا ہے۔ یعنی، ہم ایک یا کئی سیشنز تک محدود نہیں ہیں (جیسا کہ TCP میں ہے)، بلکہ ان میں سے زیادہ سے زیادہ سیشن بنا سکتے ہیں جتنی ہمیں ضرورت ہے۔ دوم، UDP کے ذریعے ڈیٹا کی ترسیل TCP کے مقابلے میں تیز ہے۔ اس طرح، نظریہ میں، ہم HTTP/2 میں حاصل کردہ موجودہ رفتار کی حد کو توڑ سکتے ہیں۔
تاہم، UDP قابل اعتماد ڈیٹا ٹرانسمیشن کی ضمانت نہیں دیتا۔ درحقیقت، ہم صرف پیکٹ بھیج رہے ہیں، اس امید پر کہ دوسرے سرے سے انہیں موصول ہو جائے گا۔ حاصل نہیں کیا؟ ٹھیک ہے، کوئی قسمت نہیں... یہ بالغوں کے لیے ویڈیوز منتقل کرنے کے لیے کافی تھا، لیکن زیادہ سنجیدہ چیزوں کے لیے آپ کو قابل اعتماد کی ضرورت ہے، جس کا مطلب ہے کہ آپ کو UDP کے اوپر کچھ اور لپیٹنا ہوگا۔
جیسا کہ HTTP/2 کے ساتھ، گوگل پر 2012 میں ایک نیا پروٹوکول بنانے کا کام شروع ہوا، یعنی تقریباً اسی وقت جب SPDY پر کام شروع ہوا۔ 2013 میں، جم Roskind عام لوگوں کو پیش کیا ، اور پہلے ہی 2015 میں IETF میں معیاری کاری کے لیے انٹرنیٹ ڈرافٹ متعارف کرایا گیا تھا۔ پہلے سے ہی اس وقت، Google میں Roskind کی طرف سے تیار کردہ پروٹوکول معیار سے بہت مختلف تھا، لہذا گوگل ورژن کو gQUIC کہا جانے لگا۔
QUIC کیا ہے؟
سب سے پہلے، جیسا کہ پہلے ہی ذکر کیا گیا ہے، یہ UDP پر ایک ریپر ہے۔ ایک QUIC کنکشن UDP کے اوپر اٹھتا ہے، جس میں HTTP/2 کے ساتھ مشابہت کے ساتھ، کئی سلسلے موجود ہو سکتے ہیں۔ یہ سلسلے صرف اختتامی مقامات پر موجود ہیں اور آزادانہ طور پر پیش کیے جاتے ہیں۔ اگر ایک سٹریم میں پیکٹ کا نقصان ہوتا ہے، تو یہ دوسروں کو متاثر نہیں کرے گا.
ڈینیل سٹینبرگ کی طرف سے مثال
دوم، خفیہ کاری کو اب علیحدہ سطح پر لاگو نہیں کیا جاتا، بلکہ پروٹوکول میں شامل کیا جاتا ہے۔ یہ آپ کو کنکشن قائم کرنے اور ایک ہی ہینڈ شیک میں عوامی کلیدوں کا تبادلہ کرنے کی اجازت دیتا ہے، اور آپ کو ہوشیار 0-RTT ہینڈ شیک میکانزم کو استعمال کرنے اور مصافحہ میں تاخیر سے مکمل طور پر بچنے کی اجازت دیتا ہے۔ اس کے علاوہ، اب انفرادی ڈیٹا پیکٹ کو خفیہ کرنا ممکن ہے۔ یہ آپ کو سٹریم سے ڈیٹا وصول کرنے کے مکمل ہونے کا انتظار نہیں کرنے دیتا، بلکہ موصول شدہ پیکٹوں کو آزادانہ طور پر ڈکرپٹ کرنے کی اجازت دیتا ہے۔ آپریشن کا یہ طریقہ عام طور پر TCP میں ناممکن تھا، کیونکہ TLS اور TCP ایک دوسرے سے آزادانہ طور پر کام کرتے ہیں، اور TLS یہ نہیں جان سکتا تھا کہ TCP ڈیٹا کو کن ٹکڑوں میں کاٹا جائے گا۔ اور اس وجہ سے، وہ اپنے سیگمنٹس تیار نہیں کر سکا تاکہ وہ TCP سیگمنٹس میں ایک سے ایک ہو جائیں اور آزادانہ طور پر ڈکرپٹ ہو سکیں۔ یہ تمام اصلاحات QUIC کو TCP کے مقابلے میں تاخیر کو کم کرنے کی اجازت دیتی ہیں۔
تیسرا، لائٹ سٹریمنگ کا تصور آپ کو کلائنٹ کے آئی پی ایڈریس سے کنکشن کو دوگنا کرنے کی اجازت دیتا ہے۔ یہ اہم ہے، مثال کے طور پر، جب ایک کلائنٹ ایک Wi-Fi رسائی پوائنٹ سے دوسرے میں سوئچ کرتا ہے، اپنا IP تبدیل کرتا ہے۔ اس صورت میں، TCP استعمال کرتے وقت، ایک لمبا عمل ہوتا ہے جس کے دوران موجودہ TCP کنکشن کا وقت ختم ہو جاتا ہے اور نئے کنکشن ایک نئے IP سے بنائے جاتے ہیں۔ QUIC کے معاملے میں، کلائنٹ پرانے اسٹریم ID کے ساتھ نئے IP سے سرور کو پیکٹ بھیجنا جاری رکھتا ہے۔ کیونکہ اسٹریم ID اب منفرد ہے اور اسے دوبارہ استعمال نہیں کیا جاتا ہے؛ سرور سمجھتا ہے کہ کلائنٹ نے IP تبدیل کر دیا ہے، کھوئے ہوئے پیکٹ دوبارہ بھیجے اور نئے پتے پر مواصلت جاری رکھے۔
چوتھا، QUIC ایپلی کیشن کی سطح پر لاگو کیا جاتا ہے، آپریٹنگ سسٹم کی سطح پر نہیں۔ یہ، ایک طرف، آپ کو پروٹوکول میں تیزی سے تبدیلیاں کرنے کی اجازت دیتا ہے، کیونکہ اپ ڈیٹ حاصل کرنے کے لیے، آپ کو نئے OS ورژن کا انتظار کرنے کے بجائے صرف لائبریری کو اپ ڈیٹ کرنے کی ضرورت ہے۔ دوسری طرف، یہ پروسیسر کی کھپت میں مضبوط اضافہ کی طرف جاتا ہے.
اور آخر میں، سرخیاں. ہیڈر کمپریشن ان چیزوں میں سے ایک ہے جو QUIC اور gQUIC کے درمیان مختلف ہے۔ مجھے اس کے لیے زیادہ وقت دینے کا کوئی فائدہ نظر نہیں آتا، میں صرف اتنا کہوں گا کہ معیاری کاری کے لیے پیش کیے گئے ورژن میں، ہیڈر کمپریشن کو HTTP/2 میں ہیڈر کمپریشن کی طرح ممکن بنایا گیا تھا۔ آپ مزید پڑھ سکتے ہیں۔ .
یہ کتنا تیز ہے؟
یہ ایک مشکل سوال ہے۔ حقیقت یہ ہے کہ جب تک ہمارے پاس کوئی معیار نہیں ہے، اس وقت تک پیمائش کے لیے کچھ خاص نہیں ہے۔ شاید ہمارے پاس صرف اعداد و شمار گوگل کے اعدادوشمار ہیں، جو 2013 سے اور 2016 میں gQUIC استعمال کر رہا ہے۔ کہ کروم براؤزر سے ان کے سرورز پر جانے والی تقریباً 90% ٹریفک اب QUIC استعمال کرتی ہے۔ اسی پریزنٹیشن میں، وہ رپورٹ کرتے ہیں کہ صفحات gQUIC کے ذریعے تقریباً 5% تیزی سے لوڈ ہوتے ہیں اور TCP کے مقابلے ویڈیو اسٹریمنگ میں 30% کم ہنگامہ آرائی ہوتی ہے۔
2017 میں، آرش مولوی کاکھکی کی قیادت میں محققین کے ایک گروپ نے شائع کیا۔ TCP کے مقابلے gQUIC کی کارکردگی کا مطالعہ کرنے کے لیے۔
مطالعہ نے gQUIC کی کئی کمزوریوں کا انکشاف کیا، جیسے نیٹ ورک پیکٹ کے اختلاط میں عدم استحکام، چینل بینڈوڈتھ میں لالچ (غیر منصفانہ) اور چھوٹی (10 kb تک) اشیاء کی سست منتقلی۔ تاہم، مؤخر الذکر کی تلافی 0-RTT استعمال کرکے کی جاسکتی ہے۔ دیگر تمام معاملات میں جن کا مطالعہ کیا گیا، gQUIC نے TCP کے مقابلے رفتار میں اضافہ دکھایا۔ یہاں مخصوص نمبروں کے بارے میں بات کرنا مشکل ہے۔ پڑھنا بہتر ہے۔ یا .
یہاں یہ کہنا ضروری ہے کہ یہ ڈیٹا خاص طور پر gQUIC کے بارے میں ہے، اور یہ تیار کیے جانے والے معیار سے متعلق نہیں ہے۔ QUIC کے لیے کیا ہوگا: یہ اب بھی ایک راز ہے، لیکن امید ہے کہ gQUIC میں جن کمزوریوں کی نشاندہی کی گئی ہے ان کو مدنظر رکھا جائے گا اور ان کو درست کیا جائے گا۔
تھوڑا سا مستقبل: HTTP/3 کا کیا ہوگا؟
لیکن یہاں سب کچھ واضح ہے: API کسی بھی طرح سے تبدیل نہیں ہوگا۔ سب کچھ بالکل ویسا ہی رہے گا جیسا کہ HTTP/2 میں تھا۔ ٹھیک ہے، اگر API وہی رہتا ہے تو، HTTP/3 میں منتقلی کو بیک اینڈ پر لائبریری کے تازہ ورژن کا استعمال کرکے حل کرنا ہوگا جو QUIC ٹرانسپورٹ کو سپورٹ کرتا ہے۔ سچ ہے، آپ کو HTTP کے پرانے ورژنز پر فال بیک کچھ عرصے کے لیے رکھنا پڑے گا، کیونکہ انٹرنیٹ فی الحال UDP میں مکمل منتقلی کے لیے تیار نہیں ہے۔
جو پہلے ہی سپورٹ کرتا ہے۔
یہاں موجودہ QUIC نفاذات۔ معیار کی کمی کے باوجود، فہرست بری نہیں ہے۔
فی الحال کوئی براؤزر پروڈکشن ریلیز میں QUIC کو سپورٹ نہیں کرتا ہے۔ حال ہی میں ایسی معلومات تھی کہ HTTP/3 کی حمایت کروم میں شامل تھی، لیکن اب تک صرف کینری میں۔
بیک اینڈز میں سے، HTTP/3 صرف سپورٹ کرتا ہے۔ и ، لیکن پھر بھی تجرباتی۔ NGINX موسم بہار 2019 کے آخر میں ، کہ انہوں نے HTTP/3 سپورٹ پر کام کرنا شروع کیا، لیکن ابھی تک اسے ختم نہیں کیا ہے۔
مسائل کیا ہیں؟
آپ اور میں حقیقی دنیا میں رہتے ہیں، جہاں کوئی بھی بڑی ٹیکنالوجی مزاحمت کو پورا کیے بغیر عوام تک نہیں پہنچ سکتی، اور QUIC بھی اس سے مستثنیٰ نہیں ہے۔
سب سے اہم بات یہ ہے کہ آپ کو کسی نہ کسی طرح براؤزر کو سمجھانے کی ضرورت ہے کہ "https://" اب یہ حقیقت نہیں ہے کہ یہ TCP پورٹ 443 کی طرف لے جاتا ہے۔ ہو سکتا ہے کہ TCP بالکل نہ ہو۔ اس کے لیے Alt-Svc ہیڈر استعمال کیا جاتا ہے۔ یہ آپ کو براؤزر کو بتانے کی اجازت دیتا ہے کہ یہ ویب سائٹ فلاں اور فلاں ایڈریس پر فلاں پروٹوکول پر بھی دستیاب ہے۔ نظریہ میں، یہ ایک دلکش کی طرح کام کرنا چاہیے، لیکن عملی طور پر ہم اس حقیقت کو دیکھیں گے کہ UDP، مثال کے طور پر، DDoS حملوں سے بچنے کے لیے فائر وال پر ممنوع ہو سکتا ہے۔
لیکن یہاں تک کہ اگر UDP ممنوع نہیں ہے، کلائنٹ ایک NAT روٹر کے پیچھے ہو سکتا ہے جو IP ایڈریس کے ذریعہ TCP سیشن منعقد کرنے کے لئے ترتیب دیا گیا ہے، اور چونکہ ہم UDP استعمال کرتے ہیں، جس کا کوئی ہارڈ ویئر سیشن نہیں ہے، NAT کنکشن نہیں رکھے گا، اور ایک QUIC سیشن .
یہ تمام مسائل اس حقیقت کی وجہ سے ہیں کہ UDP پہلے انٹرنیٹ مواد کی ترسیل کے لیے استعمال نہیں کیا گیا تھا، اور ہارڈویئر مینوفیکچررز اس بات کا اندازہ نہیں لگا سکتے تھے کہ ایسا کبھی ہوگا۔ اسی طرح، منتظمین ابھی تک یہ نہیں سمجھتے ہیں کہ QUIC کے کام کرنے کے لیے اپنے نیٹ ورکس کو صحیح طریقے سے ترتیب دینے کا طریقہ۔ یہ صورتحال بتدریج بدلے گی، اور، کسی بھی صورت میں، اس طرح کی تبدیلیوں میں نئے ٹرانسپورٹ لیئر پروٹوکول کے نفاذ سے کم وقت لگے گا۔
مزید برآں، جیسا کہ پہلے بیان کیا گیا ہے، QUIC CPU کے استعمال کو بہت زیادہ بڑھاتا ہے۔ ڈینیئل سٹینبرگ تین گنا تک پروسیسر کی ترقی.
HTTP/3 کب آئے گا؟
سٹینڈرڈ مئی 2020 تک، لیکن یہ دیکھتے ہوئے کہ جولائی 2019 کے لیے طے شدہ دستاویزات اس وقت نامکمل ہیں، ہم کہہ سکتے ہیں کہ تاریخ کو زیادہ تر ممکنہ طور پر پیچھے دھکیل دیا جائے گا۔
ٹھیک ہے، گوگل 2013 سے اپنے gQUIC نفاذ کا استعمال کر رہا ہے۔ اگر آپ HTTP درخواست کو دیکھتے ہیں جو گوگل سرچ انجن کو بھیجی جاتی ہے، تو آپ کو یہ نظر آئے گا:
نتائج
QUIC اب ایک خام، لیکن بہت امید افزا ٹیکنالوجی کی طرح لگتا ہے۔ اس بات پر غور کرتے ہوئے کہ پچھلے 20 سالوں میں، ٹرانسپورٹ لیئر پروٹوکولز کی تمام اصلاحیں بنیادی طور پر TCP، QUIC، جس کی زیادہ تر صورتوں میں بہترین کارکردگی ہے، پہلے سے ہی بہت اچھی لگتی ہے۔
تاہم، ابھی بھی حل طلب مسائل موجود ہیں جن سے اگلے چند سالوں میں نمٹنا پڑے گا۔ اس عمل میں اس حقیقت کی وجہ سے تاخیر ہو سکتی ہے کہ اس میں ہارڈ ویئر شامل ہے، جسے کوئی بھی اپ ڈیٹ کرنا پسند نہیں کرتا، لیکن اس کے باوجود، تمام مسائل کافی حد تک حل کیے جا سکتے ہیں، اور جلد یا بدیر ہم سب کے پاس HTTP/3 ہو گا۔
مستقبل قریب ہی ہے!
ماخذ: www.habr.com