- QUIC प्रोटोकॉल को Linux kernel में आधिकारिक रूप से एकीकृत करने वाला पहला पैच सबमिट किया गया है
- इसका उद्देश्य मौजूदा TCP की सीमाओं, जैसे latency, head-of-line blocking, और मध्यवर्ती डिवाइसों के कारण होने वाली protocol ossification, को सुधारना है
- QUIC UDP-आधारित है और multistream support तथा end-to-end encryption देता है, इसलिए kernel में आने पर अधिक व्यापक platforms और hardware के उपयोग की संभावना बढ़ती है
- शुरुआती kernel implementation का performance मौजूदा TCP और kernel TLS की तुलना में कम मापा गया, लेकिन आगे hardware offloading और optimization के जरिए performance बेहतर होने की उम्मीद है
- फिलहाल Samba, kernel-आधारित SMB/NFS, curl आदि में इसके समर्थन पर सक्रिय चर्चा चल रही है, लेकिन mainline merge तक अभी और समय लगने की संभावना है
QUIC प्रोटोकॉल के आने की पृष्ठभूमि और TCP की सीमाएँ
- QUIC को मौजूदा इंटरनेट में TCP की कई समस्याओं को हल करने के उद्देश्य से बनाया गया था
- TCP के connection process में होने वाली 3-way handshake से latency बढ़ती है, multistream support कमजोर है, और packet loss होने पर head-of-line blocking जैसी समस्या के कारण web experience खराब होता है
- TCP metadata बिना encryption के ट्रांसफर होता है, जिससे information leak का जोखिम रहता है, और इंटरनेट के middleboxes connection information के आधार पर traffic filter करते हैं, जिसके परिणामस्वरूप protocol ossification बढ़ती है
- TCP को सुधारने की कोशिशें, जैसे Multipath TCP, भी अक्सर तब तक ठीक से काम नहीं कर पातीं जब तक वे खुद को मौजूदा TCP जैसा दिखाएँ नहीं
QUIC की विशेषताएँ और तकनीकी फायदे
- QUIC UDP के ऊपर काम करता है और connection process में अलग से 3-way handshake के बिना तेज़ी से connection set up कर सकता है
- packet loss पूरे stream को प्रभावित न करे, इसके लिए multistream transmission design अपनाया गया है
- QUIC से संबंधित transport data हमेशा end-to-end encrypted (TLS-आधारित) रहता है, इसलिए middleboxes internal messages तक पहुँच नहीं पाते
- अगर network environment में UDP packets गुजर सकते हैं, तो QUIC भी सामान्य रूप से काम कर सकता है
Linux kernel में QUIC integration patch का सार
- सबमिट किए गए patch में IPPROTO_QUIC नाम का नया protocol type जोड़ा गया है, जिससे मौजूदा socket() system call का उपयोग किया जा सकता है
- TCP की तरह bind(), connect(), listen(), accept() जैसी calls इस्तेमाल की जा सकती हैं, लेकिन उसके बाद की processing में अंतर है
- TLS session management तथा authentication/encryption process user space में handle किए जाते हैं, और connection के बाद दोनों तरफ TLS handshake पूरा होने पर ही data send/receive किया जा सकता है
- शुरुआती connection के बाद TLS negotiation result को cache किया जा सकता है, जिससे दो systems के बीच reconnect होने पर गति काफी बढ़ सकती है
Performance से जुड़ी चुनौतियाँ और आगे की दिशा
- सबमिट किया गया in-kernel QUIC implementation अभी performance के मामले में मौजूदा kernel TLS और TCP से पीछे है
- in-kernel TLS की तुलना में throughput 3 गुना से भी कम है, और encryption बंद होने पर भी TCP की तुलना में throughput अधिकतम 4 गुना तक कम है
- इसके कारणों में segmentation offloading का अभाव, transmit path में अतिरिक्त data copy, और header encryption process शामिल बताए गए हैं
- आगे hardware offloading support जुड़ने और in-kernel implementation के optimize होने पर performance बेहतर होने की उम्मीद है
अपनाने की स्थिति और आगे का अनुमान
- Samba server/client, kernel SMB और NFS filesystem, curl जैसे कई projects में in-kernel QUIC support पर चर्चा सक्रिय है
- यह patch लगभग 9,000 lines का है और फिलहाल इसमें सिर्फ low-level support code शामिल है। पूरी implementation आगे आने वाले patches में जोड़ी जानी है
- code review और merge पर चर्चा अभी शुरुआती चरण में है, इसलिए वास्तविक उपयोग तक पहुँचने में अभी समय लगेगा
- हाल में Homa protocol को kernel में merge होने के लिए 9 महीनों में 11 submissions की ज़रूरत पड़ी थी; इस उदाहरण को देखते हुए QUIC के भी 2026 के बाद mainline में आने की संभावना है
अभी कोई टिप्पणी नहीं है.