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

 (arxiv.org)
2 पॉइंट द्वारा GN⁺ 2024-10-20 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • हाई-स्पीड wired नेटवर्क, WiFi 6/7, और 5G जैसे ऐसे वातावरण में जहाँ प्रति connection 500Mbps~1Gbps से अधिक संभव है, UDP+QUIC+HTTP/3 stack ने TCP+TLS+HTTP/2 की तुलना में अधिकतम 45.2% कम data transfer rate दिखाया
  • सिर्फ़ साधारण file download से आगे बढ़कर, Chrome, Edge, Firefox, Opera और desktop·mobile वातावरणों में जैसे-जैसे bandwidth बढ़ती है, QUIC और HTTP/2 के बीच performance gap भी बढ़ता है
  • packet tracing और kernel·user space profiling के नतीजे बताते हैं कि bottleneck sender side से ज़्यादा receiver-side processing overhead के करीब है, और QUIC receive करते समय अधिक packets तथा user-space ACK processing होती है
  • application impact के रूप में DASH video में अधिकतम 9.8% bitrate कमी और 100 प्रमुख websites पर औसतन 3.0% अधिक page load time देखा गया
  • mitigation के लिए receiver side पर UDP GRO deployment, GSO/GRO में QUIC-friendly सुधार, receive logic में सुधार, और कई CPU cores के उपयोग की ज़रूरत है, लेकिन client devices और OS की विविधता इसे लागू करना कठिन बनाती है

हाई-स्पीड नेटवर्क में सामने आया QUIC performance gap

  • QUIC, UDP के ऊपर चलने वाला एक multiplexed transport-layer protocol है, और HTTP/3 के transport base के रूप में IETF द्वारा standardize किया गया है
  • Google, Akamai, Meta, Cloudflare जैसी कई कंपनियाँ 2013 के बाद से QUIC को production में deploy करती रही हैं, और HTTP/3 के साथ इसे web performance बदलने वाले संभावित विकल्प के रूप में देखा जाता रहा है
  • QUIC performance पर पहले के शोधों में implementation, computing environment, और network conditions बहुत अलग-अलग थे, और उनमें से कई low-throughput use cases पर केंद्रित थे
  • माप का फोकस ऐसे हाई-स्पीड नेटवर्क में QUIC के व्यवहार पर है जहाँ high-speed wired links, WiFi 6/7, और 5G के साथ प्रति connection 500Mbps से अधिक या 1Gbps से अधिक तक पहुँचना संभव है
  • तुलना किसी एक protocol की नहीं बल्कि पूरे stack की है
    • QUIC पक्ष: UDP+QUIC+HTTP/3
    • पारंपरिक पक्ष: TCP+TLS+HTTP/2
    • संक्षेप में इन्हें क्रमशः QUIC और HTTP/2 कहा गया है

file download प्रयोगों में दिखा अंतर

  • cURL और Chromium-आधारित quic_client का उपयोग कर किए गए साधारण file download प्रयोगों में congestion control algorithm, server configuration, और network conditions को समान रखकर तुलना की गई
  • अपेक्षाकृत कम लगभग 600Mbps से कम bandwidth पर QUIC और HTTP/2 का performance समान था, लेकिन इससे अधिक bandwidth पर QUIC throughput, HTTP/2 से अधिकतम 15.7% कम रहा
  • bandwidth बढ़ने के साथ performance gap और स्पष्ट हुआ, और packet receive करते समय QUIC ने आधुनिक client host पर HTTP/2 की तुलना में काफ़ी अधिक CPU usage दिखाया
  • प्रमुख browsers के प्रयोगों में यह अंतर और बड़ा था
    • परीक्षण किए गए browsers: Chrome, Edge, Firefox, Opera
    • Chrome में bandwidth लगभग 500Mbps से ऊपर जाते ही QUIC पीछे रहना शुरू करता है
    • bandwidth 1Gbps तक पहुँचने पर QUIC, HTTP/2 से 45.2% धीमा हो जाता है
    • mobile जैसे अपेक्षाकृत कमज़ोर clients पर यह gap और बढ़ जाता है

web applications पर प्रभाव

  • performance गिरावट केवल बड़े file transfer तक सीमित नहीं है, बल्कि intermittent traffic patterns वाले applications में भी दिखाई देती है
  • हाई-स्पीड Ethernet और 5G पर DASH video chunks पहुँचाते समय QUIC ने HTTP/2 की तुलना में अधिकतम 9.8% कम video bitrate दिखाया
  • यह QoE गिरावट केवल तब सामने आती है जब आधार bandwidth काफ़ी अधिक हो
    • 4G में इसका प्रभाव छिप जाता है
    • 5G में इसका प्रभाव दिखाई देता है
  • web browsing प्रयोगों में 100 प्रमुख websites के औसत के आधार पर QUIC का page load time (PLT), HTTP/2 की तुलना में 3.0% अधिक था
  • long tail में ऐसे मामले भी थे जहाँ page load time का अंतर 50% से अधिक था

bottleneck का कारण: receiver-side processing और user-space ACK

  • packet tracing और performance data से पता चलता है कि QUIC client, HTTP/2 download की तुलना में काफ़ी अधिक packets receive करता है
  • जब QUIC ऊँची data transfer rate पर receive करता है, तो आने वाले data packets और उनके अनुरूप ACK packets के बीच delay बढ़ जाती है, जिससे QUIC packet processing time भी बढ़ता है
  • ये दोनों observations संकेत देते हैं कि हाई-स्पीड इंटरनेट में QUIC performance degradation का कारण receiver-side processing capacity की सीमा है
  • receiver side को bottleneck माने जाने के दो कारण हैं
    • server सामान्यतः desktop, laptop, और smartphone जैसे clients की तुलना में अधिक शक्तिशाली होते हैं
    • QUIC के design के कारण data receive processing में कुछ अंतर्निहित कठिनाइयाँ हैं
  • गहन profiling में दो मुख्य कारण सामने आए
    • अत्यधिक data packets
      • एक ही file download करते समय kernel के अंदर UDP stack, TCP की तुलना में कहीं अधिक netif_receive_skb packet reads उत्पन्न करता है
      • जाँची गई QUIC implementations में से किसी ने भी UDP generic receive offload, यानी UDP GRO, का उपयोग नहीं किया
      • UDP GRO वह तरीका है जिसमें link-layer module कई received UDP datagrams को transport layer तक भेजने से पहले एक बड़े datagram में जोड़ देता है
      • यह उस स्थिति के विपरीत है जहाँ TCP segmentation offload व्यापक रूप से deploy है और UDP sender-side offloading यानी GSO पर हाल में अधिक ज़ोर दिया गया है
    • user-space ACK processing
      • user space में QUIC, received packets की processing और response generation के लिए अधिक overhead रखता है
      • इसके कारणों में kernel से आने वाले अत्यधिक packets, QUIC ACK की user-space processing, और QUIC में delayed ACK जैसी कुछ optimizations की अनुपस्थिति शामिल है

प्रारंभिक माप और mitigation की दिशा

  • Chrome browser में 1GB file download के एक प्रारंभिक प्रयोग में QUIC सक्षम होने पर download time लगभग दोगुना होता दिखा
  • sample results 10 runs के औसत हैं
    • desktop Ethernet: HTTP/2 9.32 सेकंड, HTTP/3 18.60 सेकंड में 99% वृद्धि, CPU usage 77.5% से 96.9% तक बढ़ा
    • Pixel 5 low-band 5G: HTTP/2 37.11 सेकंड, HTTP/3 78.65 सेकंड में 112% वृद्धि, CPU usage 121.55% से 161.77% तक बढ़ा
    • Pixel 5 mmWave 5G: HTTP/2 30.10 सेकंड, HTTP/3 63.20 सेकंड में 110% वृद्धि, CPU usage 128.43% से 165.20% तक बढ़ा
  • desktop CPU usage browser network service के आधार पर है, और smartphone measurements पूरे browser process के आधार पर हैं
  • CPU usage का 100% से ऊपर जाना यह दर्शाता है कि multicore system में browser process ने एक से अधिक core का उपयोग किया
  • प्रस्तावित mitigation में receiver-side UDP GRO deployment, GSO और GRO में QUIC-friendly सुधार, receiver-side QUIC logic में सुधार, और कई CPU cores के माध्यम से QUIC data receive करना शामिल है
  • client hosts में PC, mobile devices, embedded devices और विभिन्न OS शामिल होने के कारण वे servers की तुलना में अधिक heterogenous हैं, इसलिए इन mitigation उपायों को व्यवहार में लागू करना कठिन है
  • measurement data और source code संबंधित शोध के साथ सार्वजनिक किए गए हैं

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

1 टिप्पणियां

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

  • लगता है industry हल्की-फुल्की साइटें बनाने के अलावा सब कुछ करने को तैयार है
    90s के आखिर में भी अगर तेज़ connection हो तो internet तुरंत जैसा लगता था, pages छोटे होते थे और JavaScript भी मुश्किल से होती थी
    आज भी ऐसी तेज़ lightweight pages मिल जाती हैं, और वे लगभग अवास्तविक लगती हैं—mouse button छोड़ने से पहले ही page पूरा load हो गया हो जैसे
    अगर user experience बेहतर हुआ होता तो सहा जा सकता था, लेकिन वह भी नहीं मिला

    • जिस project पर अभी काम कर रहा/रही हूँ, उसके React app से JavaScript हटाने का काम चल रहा है और यह काफ़ी मज़ेदार है
      यह तेज़ और कहीं ज़्यादा robust हो गया है, और frontend व backend के बीच state mismatch भी खत्म हो गया है
      सुविधा के लिए न्यूनतम JavaScript स्वीकार कर रहे हैं; अभी कुछ सौ lines हैं, और इसे अभी भी single-page app जैसा दिखाने के लिए थोड़ा और जोड़ेंगे
      इससे लगभग 40 हज़ार lines React और लगभग 20 हज़ार lines Kotlin हटाई जा सकती हैं, लेकिन backend code करीब 30 हज़ार lines दोबारा लिखना होगा
      फिर भी यह पसंद है
    • university खत्म करते समय मैंने framework-based web development के trend पर पूरी तरह भरोसा कर लिया था, और सोचा था कि “enterprise” web development ऐसे ही किया जाता है
      इसलिए अनुभव लेने के लिए अपनी homepage को static VUE.JS version में migrate करने की कोशिश की, लेकिन variable names को strings के रूप में पास करके view और state को बाँधने का तरीका अजीब था, build environment को extend करना बेवजह जटिल था, और सब कुछ धीमा था तथा सिर्फ एक खास तरीके से ही करना पड़ता था
      सब लोग इस्तेमाल कर रहे हैं तो सही ही होगा, ऐसा लगा था, लेकिन अब उस नजरिए से बाहर आ चुका/चुकी हूँ और नए version को raw HTML और static site generator templates से ही पूरा कर दिया
      HTML size 90% घट गया, JS usage 97% घट गया, और build time 20 seconds से 2 seconds हो गया
      user experience भी बेहतर हुआ और नए version के बाद visits भी 30% बढ़ीं
      web का कम इस्तेमाल करें तो web कहीं ज़्यादा शानदार हो सकता है
    • हल्की-फुल्की site चमकदार résumé नहीं बनती
      backend में भी आजकल सोने का अंडा API से जुड़े headless SaaS products के जरिए microservices बेचना है, और performance तो अपने-आप बेहतर हो जाएगी—ऐसा मान लिया जाता है
      https://macharchitecture.com/
      अगर लोग ऐसे फावड़े खरीदना चाहते हैं, तो IT की दुनिया में हमारे पास भी ऐसे फावड़ों का ढेर लगाने के अलावा चारा नहीं है
    • personal projects सब server-rendered HTML से बनाता/बनाती हूँ
      blog statically rendered Hugo site है इसलिए उसमें बिल्कुल JS नहीं है, और projects Rails व server-rendered HTML पर आधारित हैं, सिर्फ nice-to-have features जोड़ने के लिए न्यूनतम JS है
      JS न हो तब भी काम करता है
      शायद अपनी site है इसलिए कह रहा/रही हूँ, लेकिन web के अधिकांश हिस्से की तुलना में experience कहीं बेहतर है, और हमने बहुत कुछ खो दिया है
    • आज के दौर में लगभग तुरंत खुलने वाली webpage का उदाहरण: https://www.mcmaster.com/

  • Google ने एक बार pure JS आधारित Speedtest बनाया था
    उस समय Ookla अभी भी Flash आधारित था, इसलिए Chromebook पर काम नहीं करता था, और installer के लिए installation status verify करना समस्या बन गया था
    उस प्रक्रिया में मैंने बहुत कुछ सीखा कि TCP अलग-अलग factors पर कैसे react करता है
    इस लेख के नतीजे लगभग उम्मीद के मुताबिक हैं, क्योंकि flow control को kernel और शायद network adapter से user space में धकेल दिया गया है
    TCP में flow control और ordering guarantee होती है, और QUIC उसे खुद manage करवाता है
    बेशक ऐसा करने के अच्छे कारण भी हैं
    TCP congestion control आधुनिक connection speeds से पीछे रहने के लिए मशहूर है, और BBR जैसे नए algorithms भी आए हैं, लेकिन उनकी cost है [1]
    network testing या web application testing में जो अहम चीज़ बहुत बार छूट जाती है, वह latency है
    एशिया या ऑस्ट्रेलिया में रहने वाले लोग जानते होंगे कि 100ms round-trip latency कितनी घातक हो सकती है
    जो चीज़ पूरी तरह responsive थी उसे बिल्कुल unusable बना सकती है, और windows की वजह से connection जिस bandwidth को support कर सकता है उसे कम करती है, साथ ही errors और congestion control के प्रति भी सुस्त बना देती है
    अगर आप network या web app test कर रहे हैं, तो latency में randomly 100ms जोड़ने वाला test करने की strongly सलाह देता हूँ [2]
    इसलिए QUIC का overhead असल में शायद मायने न रखे
    क्योंकि single TCP connection या QUIC stream पर effective bandwidth असली raw bandwidth से काफी कम हो सकती है
    दूसरे शब्दों में, 45% extra data होने पर भी, अगर congestion control को सीधे manage करने से दो points के बीच effective speed ज़्यादा हो जाती है, तो यह फायदा हो सकता है
    [1]: https://atoonk.medium.com/tcp-bbr-exploring-tcp-congestion-c...
    [2]: https://bencane.com/simulating-network-latency-for-testing-i...

    • अपने file transfer app[1] के साथ मैंने real-world testing बहुत की, और शुरुआत में उम्मीद थी कि QUIC कमाल का होगा, लेकिन कई वजहों से निराश होकर TCP पर लौट गया
      पीछे मुड़कर देखें तो obvious है, लेकिन TCP में आप बस “kernel, यह बड़ा buffer भेज दो” कह सकते हैं, जबकि UDP packet exchange तरीका है, इसलिए 0 भेजना भी ज्यादातर operating systems और consumer hardware पर mode switch की वजह से CPU cost बढ़ा देता है
      workaround हैं, लेकिन वे आसान नहीं हैं, और मेरे अनुभव में वे पूरी तरह ready भी नहीं थे; साथ ही वे इस्तेमाल की जाने वाली language, library और platform के choices को भी limit करते हैं
      बोनस के तौर पर, battery पर MacBook इस्तेमाल करते समय throughput में बड़ी गिरावट देखी, जो शायद efficiency cores से जुड़ी लगती है
      दूसरा, QUIC congestion control ठीक से नहीं कर पाया
      मैंने quic-go इस्तेमाल किया था, इसलिए environment के हिसाब से फर्क हो सकता है, लेकिन कोई tuning खास मददगार नहीं रही, और जब TCP stream के साथ था तो TCP ज़्यादा bandwidth ले गया
      तीसरा, API अजीब है
      QUIC खुद multiple streams रखता है, इसलिए यह TCP का drop-in replacement नहीं है
      हालांकि इरादा HTTP/3 को higher layer पर drop-in replacement बनाने का है, लेकिन मैंने वह try नहीं किया, इसलिए उस पर कुछ नहीं कह सकता
      अगर आप stream level पर काम करते हैं, तो इसे ध्यान में रखने लायक है
      कुल मिलाकर काफी हार जैसा महसूस हुआ, लेकिन साथ ही पुराने दोस्त TCP की optimization और resilience के प्रति नया सम्मान पैदा हुआ
      यह वाकई अद्भुत technology है, और operating system इसे हमेशा मुफ्त में देता है
      TCP की कुछ मुख्य समस्याएँ भी design flaws से ज़्यादा conservative या legacy defaults की वजह से हैं
      जैसे Linux की buffer limits, Nagle वगैरह
      wheel को फिर से invent करने के बजाय अगर हम बस TCP को बेहतर बना सकें तो अच्छा होगा
      [1]: https://payload.app/
    • “flow control को kernel और network adapter से user space में धकेल दिया गया” यह QUIC protocol की intrinsic property नहीं है, सिर्फ implementation decision है
      QUIC को शुरू करने के लिए यह decision ज़रूरी था, लेकिन अब जब यह मौजूद है, तो इसे फिर से review किया जा सकता है
      QUIC को kernel में implement करने में कोई technical obstacle नहीं है, और अगर performance benefits बड़े हुए तो कोई न कोई जल्द ही लगभग निश्चित रूप से ऐसा करेगा
    • चीन से चीन के बाहर servers तक latency अक्सर 300ms से ऊपर होने के अनुभव के आधार पर मैं QUIC का मजबूत supporter हूँ
      फर्क जमीन-आसमान का है
    • Chrome Developer Tools के Network tab में connection quality घटाई जा सकती है
      Slow/Fast 4G, 3G presets हैं, और custom preset बना सकते हैं जिसमें download/upload speed, ms में latency, packet loss rate, packet queue length खुद specify कर सकते हैं और packet reordering भी on कर सकते हैं
    • यह assumption है कि user space धीमा होता है, लेकिन कुछ या ज्यादातर सबसे तेज़ high-performance TCP/IP stacks user space में बनाए जाते हैं

  • curl के निर्माता और maintainer Daniel Stenberg ने कुछ महीने पहले curl में HTTP/3 के बारे में एक लेख लिखा था: https://daniel.haxx.se/blog/2024/06/10/http-3-in-curl-mid-20...
    उन्होंने जिन बातों पर जोर दिया, उनमें से एक थी HTTP/3 का ज्यादा CPU उपयोग, और CPU throughput को सीमित करने की हद तक पहुंच रहा था
    मुझे उत्सुकता है कि इसमें से कितना implementation की अपरिपक्वता की वजह से है, और कितना QUIC design की अपनी विशेषताओं की वजह से

    • सिफारिशों में से दो receiving-side implementation में सुधार, यानी optimization और multi-threading, की बात करती हैं, इसलिए यह संकेत लगता है कि implementation अभी अपरिपक्व है
      तीसरी सिफारिश UDP GRO है, जिसमें incoming UDP packets को एक साथ bundle करने के लिए kernel, और ideally NIC hardware, में बदलाव किया जाता है ताकि प्रति-packet काम घटकर प्रति-group काम में बदल जाए
      TCP में यह पहले से है, और sending side पर भी TSO तथा Linux का GSO जैसी मिलती-जुलती चीजें हैं
      यह भी अपरिपक्वता जैसा लगता है, लेकिन hardware feature की कमी की संभावना सोचें तो इसे ठीक करना ज्यादा मुश्किल हो सकता है
      abstract में QUIC के ACK तरीके की cost की बात है, लेकिन मैंने उस दावे को विस्तार से नहीं देखा
      modern TCP-based servers में दिखने वाला एक और feature TLS को hardware पर offload करना है
      एक साथ कई TCP streams भेजने वाले servers में यह ज्यादा महत्वपूर्ण लगता है
      Linux में यह userspace networking का इस्तेमाल करके या ‘kernel tls’ के जरिए संभव है, और संभव हो तो hardware पर offload हो जाता है
      यह feature Linux की एक खास capability से भी जुड़ा है, जो TCP stream को ‘messages’ में तोड़कर दूसरे threads को भेजने देती है; हालांकि मुझे नहीं पता कि पहले के packets खो जाने पर पीछे के messages को पहले से आगे पास किया जा सकता है या नहीं
    • मैंने हमेशा समझा है कि QUIC उन connections के लिए design किया गया था जो stable या fast होने की guarantee नहीं देते, जैसे mobile networks
      मुझे कभी ऐसा impression नहीं मिला कि इसका उद्देश्य सभी connections को faster बनाना था
      उस नजरिए से देखें तो trade-off समझ में आता है
      मैं expert नहीं हूं, इसलिए जो ज्यादा जानते हों वे सुधार दें
    • यहां “implementation की अपरिपक्वता” वाला phrase दिलचस्प है
      QUIC इसलिए बनाया गया क्योंकि internet भर के सारे hardware, middleware सहित, को नया TCP या TLS standard support करवाने का कोई तरीका था ही नहीं
      इसलिए QUIC, legacy internet hardware के ऊपर UDP पर नया transport standard चढ़ाने का एक elegant solution है
      आदर्श दुनिया में हम नए TCP और TLS standards बनाते और दुनिया भर के सारे internet routers और hardware को बदलते या update करते, ताकि इसे कम CPU usage के साथ implement किया जा सके
    • वे performance results मुझे भी चौंकाने वाले लगे
      test में CPU-bound quiche 200MB/s से कम था और nghttp2 900MB/s से ऊपर था
      मुझे आश्चर्य है कि क्या CPU throttling हो रही थी
      अगर HTTP/3 implementation CPU का 4 गुना उपयोग करता है तो यह दिलचस्प है, लेकिन अगर absolute value शुरू से ही बहुत कम थी तो जरूरी नहीं कि यह कोई बड़ी समस्या हो

  • “तेज internet पर UDP+QUIC+HTTP/3 stack, TCP+TLS+HTTP/2 की तुलना में data speed को अधिकतम 45.2% तक घटा देता है” वाला हिस्सा मुख्य है; मैंने अभी पूरा paper नहीं पढ़ा है, लेकिन introduction में लगता है कि 600Mbit/s से कम को slow internet माना गया है

    • दूसरे शब्दों में, इसका मतलब है कि client browser <> edge segment में HTTP/3 + QUIC enable करें, और edge <> origin segment को HTTP/2 या HTTP/1 तक सीमित रखें
      Cloudflare को उदाहरण मानें तो वह client <> edge के बीच ही QUIC support करता है और origin connections के लिए support नहीं करता
      अगर edge <> origin connection reusable, stable और “fast” है, तो यह समझ में आता है
      https://developers.cloudflare.com/speed/optimization/protoco...
    • उतना ही महत्वपूर्ण हिस्सा यह है कि कारण high receiving-side processing overhead है, खासकर अत्यधिक data packets और QUIC के userspace ACK
      ऐसा नहीं लगता कि protocol में ही कोई बुनियादी समस्या है
    • मेरा मानना है कि मुख्य रूप से browser implementations में inefficiency या बहुत ज्यादा system calls के कारण पैदा हुई latency problem की वजह से throughput में गिरावट दिखी
      लेकिन ऐसी latency problems, CPU को boost कराने वाली CPU usage problems के उलट, battery usage को बहुत ज्यादा नहीं बढ़ातीं
      server-to-server communication में भी यह समस्या नहीं है
      मूल रूप से end-user devices पर, 2024 के हिसाब से भी बहुत fast connection इस्तेमाल करते समय high-bandwidth transfer “slow” हो जाता है
      यहां जिस speed की बात है वह विज्ञापन में खरीदी गई speed नहीं, बल्कि actual device से server तक की effective speed है
      इसका मतलब यह नहीं कि paper बेकार है; browser implementations में सुधार होना चाहिए, और यह बात paper अच्छी तरह दिखाता है
      हालांकि paper का title लगभग 100% clickbait है
    • internet access आगे और तेज होना ही है
      gigabit internet के फैलने के समय पर ज्यादा slow transfer method अपनाना साफ तौर पर गलती है
    • Switzerland में 60 डॉलर प्रति माह में 25Gbit/s मिल सकता है
      30 साल बाद यह और तेज होगा; अगर line speed पूरी तरह इस्तेमाल करने के लिए पुराने protocol का इस्तेमाल करना पड़े, तो यह मूर्खता होगी

  • सितंबर में भी यही लेख पोस्ट हुआ था: QUIC is not quick enough over fast internet (acm.org)
    https://news.ycombinator.com/item?id=41484991 (327 comments)

    • व्यक्तिगत रूप से मेरा निष्कर्ष यह था कि Google को Chromium के जरिए internet protocol usage को practically एकतरफा design और enforce करने की अनुमति नहीं दी जानी चाहिए
      Brave/Vivaldi/Opera आदि को consciously choose करना चाहिए
    • QUIC एक ad company द्वारा consumers तक ads delivery guarantee करने की technology है
      अगर ads जल्दी पहुंच जाएं तो बाकी चीजें मायने नहीं रखतीं—ऐसा रवैया है

  • यह सचमुच बहुत अजीब लगता है
    मैंने केवल QUIC+HTTP/3 से ही नहीं, बल्कि सिर्फ QUIC से भी 900mbps speed हासिल की है
    यह खराब TLS implementation या inefficient early implementation जैसा लगता है
    CPU usage 2nd-gen EPYC core पर लगभग 5% था, जो काफी average है

    • असल में यह well-known है कि browsers की मौजूदा QUIC implementation stable नहीं है और rustls-based है या कुछ इसी तरह patchwork तरीके से बनाई गई है

  • एक किस्से के तौर पर, wordpress.org एक्सेस करने में समस्या थी
    Wordpress पहली बार इस्तेमाल करते समय दस्तावेज़ ठीक से देख पा रहा था, लेकिन किसी समय वेबसाइट पर बिल्कुल भी एक्सेस नहीं हो पा रहा था
    Linux के साथ dual boot किया, तो Windows की समस्या भी नहीं थी; ping ठीक चल रहा था, और तीन browser बदलने पर भी वही हाल था
    साइट पर जाने पर वह रुकी रहती और बिल्कुल load नहीं होती, या कभी-कभी page बीच में ही load होना बंद कर देता था
    आज समाधान मिला: Chrome settings में Experimental QUIC Protocol को बंद करना
    कई महीनों तक wordpress.org एक्सेस करने में समस्या थी, लेकिन यह QUIC की वजह से है, इसका कोई संकेत बिल्कुल नहीं था, इसलिए चिंता होती है
    Developer tools में QUIC से जुड़ी error कभी-कभार ही दिखती थी, उसी से मुश्किल से पता चला
    सोचता हूँ, इस protocol की वजह से ऐसी और कितनी websites inaccessible हो गई होंगी जिनका कारण users को पता ही नहीं चलता होगा

  • यहाँ तेज़ internet से मतलब 500Mbps है, और वजह यह है कि QUIC उससे ऊपर CPU-bound होता दिखता है
    यह जांचने लायक विस्तार से नहीं देखा कि test system आम consumer-grade था या high-performance desktop पर भी समस्या बनी रहती है

  • मज़ेदार बात यह है कि हम details ठीक से न जानते हुए भी तेज़ = अच्छा की वजह से “QUIC नया HTTP/2 है” जैसी सोच को चुपचाप मान लेते हैं
    यह वैसा ही है जैसे नया 5G phone 4G से कई गुना तेज़ है, इसलिए खरीद लेना
    असल में 1) मेरा 4G phone कभी भी 4G की maximum speed पर चला ही नहीं, और 2) connection problems लगभग हमेशा internet line की speed की वजह से नहीं, बल्कि DNS server, target website, या telecom operator की तरफ़ के connection multiplexing equipment में गड़बड़ी की वजह से होती हैं
    फिर भी बात “लेकिन यह 5G है” पर आ जाती है
    “fiber broadband” के विज्ञापनों में लोगों को TV देखते हुए ऐसे दिखाना कि उनके बाल हवा में उड़ रहे हों, यह भी हँसाने वाला है
    असल में यह उस तरह काम नहीं करता
    पहले 8Mb connection पर भी streaming हो जाती थी, इसलिए 300Mb कुछ कामों के लिए अच्छा होगा, लेकिन कितना बड़ा फर्क महसूस होगा, इस पर संदेह है

  • काश QUIC में non-TLS mode होता
    local development के दौरान कभी-कभी मैं बस यह देखना चाहता हूँ कि wire पर क्या आ-जा रहा है, लेकिन यह बहुत सारी अनावश्यक friction जोड़ देता है

    • server की private key Wireshark में जोड़ दें, तो वह packets को अपने-आप decrypt कर देता है
    • QUIC, TLS specification के कुछ हिस्सों—जैसे handshake और transport state—को reuse करता है
      इसलिए उसके बिना यह काम नहीं कर सकता