तेज़ इंटरनेट पर भी QUIC तकनीक पर्याप्त तेज़ नहीं है

 (arxiv.org)
2 पॉइंट द्वारा GN⁺ 2024-10-20 | 1 टिप्पणियां | WhatsApp पर शेयर करें

QUIC तेज़ इंटरनेट पर पर्याप्त तेज़ नहीं है

  • शोध की पृष्ठभूमि

    • QUIC से वेब applications की performance बेहतर होने में अहम भूमिका निभाने की उम्मीद की जाती है.
    • यह शोधपत्र high-speed network में QUIC की performance की व्यवस्थित जाँच करता है.

  • मुख्य निष्कर्ष

    • high-speed internet में UDP+QUIC+HTTP/3 stack, TCP+TLS+HTTP/2 की तुलना में data transfer speed को अधिकतम 45.2% तक कम कर देता है.
    • base bandwidth बढ़ने के साथ QUIC और HTTP/2 के बीच performance gap और बढ़ता है.
    • यह समस्या सिर्फ file transfer तक सीमित नहीं है, बल्कि video streaming (अधिकतम 9.8% video bitrate reduction) और web browsing जैसे विभिन्न applications को भी प्रभावित करती है.

  • विश्लेषण की विधि

    • packet trace analysis तथा kernel और user space profiling के जरिए समस्या के root cause की पहचान की गई.
    • receiver-side processing overhead अधिक है, और खास तौर पर excessive data packets तथा QUIC के user-space ACK इस समस्या के कारण हैं.

  • सुधार के लिए सिफारिशें

    • देखी गई performance समस्याओं को कम करने के लिए ठोस सिफारिशें दी गई हैं.

GN⁺ का सार

  • यह शोधपत्र high-speed network environment में QUIC की performance समस्याओं का विश्लेषण करके ऐसे महत्वपूर्ण insights देता है, जो web application performance सुधारने में मदद कर सकते हैं.
  • यह QUIC की performance degradation के कारण को receiver-side processing overhead के रूप में चिन्हित करता है, और इसे हल करने के लिए ठोस उपाय सुझाकर network engineers और developers के लिए उपयोगी जानकारी प्रदान करता है.
  • समान कार्यक्षमता वाले दूसरे protocol के रूप में HTTP/2 है, और इसके साथ performance comparison के जरिए QUIC के सुधार की दिशा सुझाई गई है.

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-10-20
Hacker News राय

  • इंडस्ट्री हल्की वेबसाइटें बनाने के अलावा सब कुछ आज़मा रही है। 90 के दशक के आखिर में, अगर आपके पास तेज़ इंटरनेट कनेक्शन होता था, तो पेज छोटे होते थे और JavaScript लगभग न के बराबर होता था। आज भी ऐसे तेज़ी से लोड होने वाले हल्के पेज मिल जाते हैं, और अनुभव लगभग अवास्तविक लगता है। अगर user experience बेहतर होता, तो इसे ज़्यादा सहा जा सकता था।

  • मैंने Google में pure JS Speedtest पर काम किया था। उस समय Ookla Flash-आधारित था, इसलिए वह Chromebooks पर काम नहीं करता था। मैंने बहुत कुछ सीखा कि TCP अलग-अलग कारकों पर कैसे प्रतिक्रिया करता है। यह लेख देखकर नतीजे अपेक्षा के अनुरूप लगते हैं। क्योंकि यह flow control को kernel से user space में धकेल देता है। TCP में flow control और sequencing होती है। QUIC इन्हें खुद manage करने देता है। TCP congestion control आधुनिक कनेक्शन स्पीड के अनुरूप नहीं है, इसलिए BRR जैसे नए algorithm की ज़रूरत पड़ती है, लेकिन उसकी भी लागत होती है। सबसे बड़ा सबक यह है कि network testing में latency के महत्व को नज़रअंदाज़ नहीं करना चाहिए। एशिया या ऑस्ट्रेलिया में रहने वाले लोग जानते होंगे कि 100ms RTT latency कितनी घातक हो सकती है। QUIC का overhead व्यावहारिक रूप से इतना महत्वपूर्ण न भी हो सकता है। क्योंकि एक single TCP connection या QUIC stream के ज़रिए मिलने वाली वास्तविक bandwidth, raw bandwidth से कहीं कम हो सकती है।

  • Curl के संस्थापक और maintainer Daniel Stenberg ने HTTP/3 पर ब्लॉग में लिखा था। उन्होंने HTTP/3 के उच्च CPU उपयोग को रेखांकित किया और कहा कि CPU throughput को सीमित कर सकता है। जिज्ञासा है कि यह implementation की अपरिपक्वता के कारण है, या QUIC की design के कारण।

  • कहा गया है कि तेज़ इंटरनेट पर UDP+QUIC+HTTP/3 stack, TCP+TLS+HTTP/2 की तुलना में data transfer speed को अधिकतम 45.2% तक घटा देता है। मैंने अभी पूरा paper नहीं पढ़ा है, लेकिन 600 Mbit/s से कम को "धीमा इंटरनेट" माना जा रहा है।

  • कहा गया है कि QUIC तेज़ इंटरनेट पर पर्याप्त तेज़ नहीं है। quic+http3 पर 900mbps स्पीड हासिल की गई, और सवाल है कि क्या TLS implementation खराब है, या शुरुआती implementation अक्षम हैं। CPU उपयोग gen 2 epyc core पर औसतन लगभग 5% था।

  • यहाँ "तेज़ इंटरनेट" का मतलब 500Mbps है, और कहा गया है कि quic CPU पर निर्भर है। मैंने यह नहीं देखा कि test system कोई सामान्य consumer system था या high-end desktop पर भी यही समस्या आती है।

  • मेरा मानना था कि QUIC latency के लिए optimize किया गया है। यह वेबपेज और वीडियो गेम में बहुत सारे छोटे packet लोड करने के लिए optimize है। केवल कुल throughput मापने पर यह कमतर लग सकता है। जिज्ञासा है कि क्या protocol स्तर पर बड़े file transfer या high-bandwidth video streaming को पहचानकर किसी कम CPU-intensive विकल्प पर switch किया जा सकता है। यह भी जिज्ञासा है कि क्या QUIC, TCP की तुलना में hardware/OS स्तर पर कम optimize है।

  • काश QUIC में TLS के बिना कोई mode होता। लोकल development के दौरान कभी-कभी ट्रांसफ़र होते हुए डेटा को देखना चाहेंगे, और यह अनावश्यक friction जोड़ता है।