20 سالن کان وڌيڪ اسان ويب پيجز کي HTTP پروٽوڪول استعمال ڪندي ڏسي رهيا آهيون. گھڻا استعمال ڪندڙ اڃا به نه سوچيو ته اھو ڇا آھي ۽ اھو ڪيئن ڪم ڪري ٿو. ٻيا ڄاڻن ٿا ته HTTP جي ھيٺان ڪٿي آھي TLS، ۽ ان جي ھيٺان TCP آھي، جنھن جي ھيٺان IP آھي، وغيره. ۽ اڃا به ٻيا - مذھبي - مڃيندا آھن ته TCP ماضي جي شيء آھي؛ اھي ڪجھ تيز، وڌيڪ قابل اعتماد ۽ محفوظ چاھين ٿا. پر هڪ نئين مثالي پروٽوڪول کي ايجاد ڪرڻ جي ڪوشش ۾، اهي 80s جي ٽيڪنالاجي ڏانهن موٽيا آهن ۽ ان تي پنهنجي بهادر نئين دنيا ٺاهڻ جي ڪوشش ڪري رهيا آهن.
ٿوري تاريخ: HTTP/1.1
1997 ۾، ٽيڪسٽ انفارميشن ايڪسچينج پروٽوڪول HTTP ورزن 1.1 پنهنجي آر ايف سي حاصل ڪئي. ان وقت، پروٽوڪول ڪيترن ئي سالن تائين برائوزرن طرفان استعمال ڪيو ويو هو، ۽ نئين معيار ٻين پندرهن سالن تائين رهي. پروٽوڪول صرف درخواست جي جواب جي اصول تي ڪم ڪيو ۽ بنيادي طور تي متن جي معلومات جي منتقلي لاء ارادو ڪيو ويو.
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 ڪم ڪندڙ گروپ متعارف ڪرايو HTTP/2 وضاحتن جي بنياد تي SPDY پروٽوڪول. هتي HTTP/2 ۾ اختلاف آهن:
- بائنري سيريلائيزيشن.
- گهڻن HTTP درخواستن کي هڪ واحد TCP ڪنيڪشن ۾ ملائي.
- سرور-پش آئوٽ آف دي باڪس (بغير WebSocket).
پروٽوڪول هڪ وڏو قدم اڳتي هو. هن زور سان ۽ گھڻن 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 پروٽوڪول استعمال ڪرڻ. ها، ها، اهو ساڳيو پروٽوڪول جيڪو اسان LAN مٿان فائلون اڇلائڻ لاءِ استعمال ڪندا هئا XNUMX جي آخر ۾ ۽ XNUMX جي شروعات ۾. لڳ ڀڳ سڀ اڄ جي هارڊويئر ان سان ڪم ڪري سگهو ٿا.
TCP مٿان UDP جا فائدا ڇا آهن؟ سڀ کان پهريان، اسان وٽ ٽرانسپورٽ پرت سيشن نه آهي جنهن بابت هارڊويئر ڄاڻي ٿو. هي اسان کي اجازت ڏئي ٿو ته سيشن جو تعين ڪرڻ جي آخري نقطي تي پاڻ کي ۽ اتي تڪرار حل ڪرڻ. اھو آھي، اسان ھڪڙي يا گھڻن سيشنن تائين محدود نه آھيون (جيئن TCP ۾)، پر انھن مان گھڻا ٺاھي سگھون ٿا جيترو اسان کي ضرورت آھي. ٻيو، UDP ذريعي ڊيٽا جي منتقلي TCP جي ڀيٽ ۾ تيز آهي. اهڙيء طرح، نظريي ۾، اسان HTTP/2 ۾ حاصل ڪيل موجوده رفتار جي ڇت ذريعي ٽوڙي سگهون ٿا.
بهرحال، UDP قابل اعتماد ڊيٽا ٽرانسميشن جي ضمانت نٿو ڏئي. حقيقت ۾، اسان صرف پيڪٽ موڪلي رهيا آهيون، اميد آهي ته ٻيو آخر انهن کي وصول ڪندو. حاصل نه ڪيو آهي؟ خير، قسمت ناهي... اهو بالغن لاءِ وڊيوز منتقل ڪرڻ لاءِ ڪافي هو، پر وڌيڪ سنگين شين لاءِ توهان کي قابل اعتمادي جي ضرورت آهي، جنهن جو مطلب آهي ته توهان کي UDP جي مٿان ڪا ٻي شيءِ لپائڻي پوندي.
جيئن HTTP/2 سان، هڪ نئون پروٽوڪول ٺاهڻ تي ڪم گوگل تي 2012 ۾ شروع ٿيو، اهو آهي، ساڳئي وقت SPDY تي ڪم شروع ٿيو. 2013 ۾، جم Roskind عام عوام کي پيش ڪيو ، ۽ اڳ ۾ ئي 2015 ۾ انٽرنيٽ ڊرافٽ متعارف ڪرايو ويو IETF ۾ معياري ڪرڻ لاءِ. اڳ ۾ ئي ان وقت، گوگل تي Roskind پاران تيار ڪيل پروٽوڪول معيار کان بلڪل مختلف هئي، تنهنڪري گوگل ورزن کي gQUIC سڏيو وڃي ٿو.
QUIC ڇا آهي
پهرين، جيئن اڳ ۾ ئي ذڪر ڪيو ويو آهي، اهو يو ڊي پي تي هڪ ڍڪ آهي. هڪ QUIC ڪنيڪشن UDP جي چوٽي تي وڌي ٿو، جنهن ۾، HTTP/2 سان قياس سان، ڪيترائي اسٽريم موجود ٿي سگهن ٿا. اهي سلسلو صرف آخري پوائنٽن تي موجود آهن ۽ آزاد طور تي خدمت ڪري رهيا آهن. جيڪڏهن هڪ پيڪٽ نقصان هڪ وهڪرو ۾ ٿئي ٿي، اهو ٻين تي اثر انداز نه ٿيندو.
ڊينيل اسٽينبرگ پاران تصوير
ٻيو، انڪرپشن هاڻي هڪ الڳ سطح تي لاڳو ناهي، پر پروٽوڪول ۾ شامل آهي. هي توهان کي هڪ ڪنيڪشن قائم ڪرڻ جي اجازت ڏئي ٿو ۽ هڪ ئي هٿ ملائڻ ۾ عوامي چابيون مٽائي ٿو، ۽ پڻ توهان کي اجازت ڏئي ٿو ته هوشيار 0-RTT هينڊ شيڪ ميڪانيزم استعمال ڪري ۽ مڪمل طور تي هٿ ملائڻ جي دير کان پاسو ڪري. ان کان علاوه، اهو هاڻي ممڪن آهي انفرادي ڊيٽا پيڪٽس کي انڪرپٽ ڪرڻ. اهو توهان کي اجازت ڏئي ٿو ته وهڪرو مان ڊيٽا حاصل ڪرڻ جي مڪمل ٿيڻ جو انتظار نه ڪريو، پر حاصل ڪيل پيڪن کي آزاد طور تي ڊڪرپٽ ڪرڻ لاء. آپريشن جو هي طريقو عام طور تي TCP ۾ ناممڪن هو، ڇاڪاڻ ته TLS ۽ TCP هڪ ٻئي کان آزاديءَ سان ڪم ڪيو، ۽ TLS کي خبر نه ٿي سگهي ته TCP ڊيٽا ڪهڙن ٽڪرن ۾ ڪٽي ويندي. ۽ تنهن ڪري، هو پنهنجا حصا تيار نه ڪري سگهيو ته جيئن اهي TCP حصن ۾ هڪ کان هڪ ٿي سگهن ۽ آزاديءَ سان ڊيڪرپٽ ٿي سگهن. اهي سڀ سڌارا QUIC کي TCP جي مقابلي ۾ ويڪرائي گھٽائڻ جي اجازت ڏين ٿا.
ٽيون، روشني جي اسٽريمنگ جو تصور توهان کي ڪلائنٽ جي IP پتي کان ڪنيڪشن کي ڊبل ڪرڻ جي اجازت ڏئي ٿو. اهو ضروري آهي، مثال طور، جڏهن هڪ ڪلائنٽ هڪ وائي فائي رسائي پوائنٽ کان ٻئي ڏانهن سوئچ ڪري ٿو، ان جي IP کي تبديل ڪندي. انهي صورت ۾، جڏهن TCP استعمال ڪندي، هڪ ڊگهو عمل ٿئي ٿو جنهن دوران موجوده TCP ڪنيڪشن جو وقت ختم ٿي ويندو آهي ۽ نوان ڪنيڪشن هڪ نئين IP مان ٺاهيا ويندا آهن. QUIC جي صورت ۾، ڪلائنٽ بس جاري رکي ٿو سرور ڏانهن پيڪيٽس موڪلڻ لاءِ نئين IP کان پراڻي اسٽريم ID سان. ڇاڪاڻ ته وهڪرو ID هاڻي منفرد آهي ۽ ٻيهر استعمال نه ڪيو ويو آهي؛ سرور سمجهي ٿو ته ڪلائنٽ IP تبديل ڪيو آهي، گم ٿيل پيڪٽ ٻيهر موڪلي ٿو ۽ نئين ايڊريس تي ڪميونيڪيشن جاري رکي ٿو.
چوٿون، QUIC ايپليڪيشن جي سطح تي لاڳو ٿئي ٿو، نه آپريٽنگ سسٽم جي سطح تي. هي، هڪ پاسي، توهان کي جلدي پروٽوڪول ۾ تبديليون ڪرڻ جي اجازت ڏئي ٿي، ڇاڪاڻ ته اپڊيٽ حاصل ڪرڻ لاءِ، توهان کي صرف لائبريري کي اپڊيٽ ڪرڻ جي ضرورت آهي، بجاءِ نئين او ايس ورزن جو انتظار ڪرڻ جي. ٻئي طرف، هي پروسيسر جي استعمال ۾ مضبوط اضافو ٿي سگهي ٿو.
۽ آخر ۾، عنوان. هيڊر کمپريشن انهن شين مان هڪ آهي جيڪا QUIC ۽ gQUIC جي وچ ۾ مختلف آهي. مون کي اهو نقطو نظر نٿو اچي ته گهڻو وقت هن لاءِ وقف ڪيو وڃي، مان صرف ايترو چوندس ته معياري ڪرڻ لاءِ پيش ڪيل ورزن ۾، هيڊر ڪمپريشن کي HTTP/2 ۾ هيڊر ڪمپريشن جيترو ٿي سگهي ٺاهيو ويو. توهان وڌيڪ پڙهي سگهو ٿا .
اهو ڪيترو تيز آهي؟
اهو هڪ ڏکيو سوال آهي. حقيقت اها آهي ته جيستائين اسان وٽ معيار آهي، ماپڻ لاءِ ڪا خاص ڳالهه ناهي. شايد صرف انگ اکر اسان وٽ آهن گوگل جا انگ اکر، جيڪي 2013 کان وٺي 2016 ۾ استعمال ڪري رهيا آهن gQUIC ته اٽڪل 90% ٽرئفڪ انهن جي سرورز ڏانهن وڃي ٿي Chrome برائوزر کان هاڻي QUIC استعمال ڪري ٿي. ساڳئي پريزنٽيشن ۾، اهي رپورٽ ڪن ٿا ته صفحا تقريباً 5 سيڪڙو تيزيءَ سان لوڊ ٿين ٿا gQUIC ذريعي ۽ ٽي سي پي جي مقابلي ۾ وڊيو اسٽريمنگ ۾ 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