savearoundtrip: HTTPS DNS रिकॉर्ड प्रकाशित करें और एक round trip बचाएँ

 (savearoundtrip.com)
1 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • अगर कोई वेबसाइट HTTPS DNS रिकॉर्ड में HTTP/3 सपोर्ट प्रकाशित करती है, तो ब्राउज़र पहली कनेक्शन से ही QUIC/HTTP/3 इस्तेमाल कर सकता है, जिससे एक connection round trip कम हो सकता है
  • ब्राउज़र पहले HTTP/1 या HTTP/2 से कनेक्ट होकर Alt-Svc header पढ़कर, या DNS lookup चरण में HTTPS रिकॉर्ड पढ़कर HTTP/3 सपोर्ट खोजता है
  • Firefox Nightly माप में 31.4% कनेक्शनों ने HTTP/3 की जानकारी सिर्फ Alt-Svc header से दी; ऐसे मामलों में HTTP/3 केवल बाद की कनेक्शनों में इस्तेमाल होता है {p:31}
  • HTTPS रिकॉर्ड alpn, ech, ipv4hint, ipv6hint रख सकता है, जिससे पहली कनेक्शन के protocol selection, ECH, और address hints DNS response के भीतर ही संभाले जाते हैं
  • HTTPS रिकॉर्ड मौजूदा clients के साथ अतिरिक्त रूप से काम करता है, और Alt-Svc को रिकॉर्ड न पाने वाले clients के लिए fallback के रूप में बनाए रखना चाहिए

मुख्य अवधारणा

  • ब्राउज़र किसी साइट के HTTP/3 सपोर्ट को दो तरीकों से खोजता है
    • पहले HTTP/1 या HTTP/2 से कनेक्ट होने के बाद Alt-Svc HTTP header पढ़ने का तरीका
    • कनेक्शन खोलने से पहले HTTPS DNS रिकॉर्ड lookup में सीधे देख लेने का तरीका
  • केवल HTTPS DNS रिकॉर्ड इस्तेमाल करने पर ही ब्राउज़र पहली कनेक्शन से HTTP/3 इस्तेमाल कर सकता है, और QUIC के जरिए एक round trip बचा सकता है
  • Firefox Nightly के हालिया build के औसत अनुमान में 31.4% कनेक्शनों ने HTTP/3 की जानकारी DNS से नहीं, बल्कि सिर्फ Alt-Svc header से दी
  • अभी इस server तक एक round trip लगभग 28ms मापा गया है

डोमेन जाँच

  • savearoundtrip.com खुद h3, IP hints, और ECH वाले HTTPS रिकॉर्ड प्रकाशित करता है
  • दर्ज किए गए डोमेन का HTTPS रिकॉर्ड ब्राउज़र में Cloudflare के DNS-over-HTTPS endpoint के जरिए lookup किया जाता है
  • Alt-Svc header और वास्तविक HTTP/3 handshake को सीधे ब्राउज़र में सत्यापित नहीं किया जा सकता
    • CORS cross-origin headers को छिपा देता है
    • ब्राउज़र को cold QUIC connection बनाने के लिए मजबूर नहीं किया जा सकता
  • दर्ज किया गया डोमेन एक छोटे open source backend को भेजा जाता है, और वह backend सिर्फ Alt-Svc जाँच और वास्तविक HTTP/3 handshake जाँच करता है
  • कोई data स्टोर नहीं किया जाता, और वास्तविक HTTP/3 handshake quic-go से किया जाता है

एक round trip की लागत

  • एक round trip server को संदेश भेजने और वापस पाने की प्रक्रिया है, और यह प्रकाश की गति से सीमित होती है
  • मोटे तौर पर round-trip समय एक ही शहर में 5~20ms, देशों के बीच 40~80ms, और समुद्र पार या mobile network पर 150ms से अधिक हो सकता है
  • Cloudflare Radar real-time आँकड़े देता है
  • लगभग 100ms से कम की interaction तुरंत महसूस होती है, और उससे ऊपर इंतज़ार जैसा लगता है
  • इस पेज में connection start से first paint तक लगभग 41ms लगे, और इस server तक real-time एक round trip लगभग 28ms है
  • प्रकाशित HTTPS रिकॉर्ड ब्राउज़र को पहली कनेक्शन में TCP की जगह QUIC इस्तेमाल करने देता है, जिससे यह round-trip समय बच सकता है
  • यह पेज static और छोटा है, इसलिए कुल time budget कम है, लेकिन वास्तविक apps में भी एक round trip front-end पर चुकाई जाने वाली fixed cost है और कई origins पर बार-बार लग सकती है

बर्बाद होने वाला round trip

  • Alt-Svc RFC 7838 का HTTP response header है
  • Alt-Svc पढ़ने के लिए client को पहले ही TCP connection खोलना, TLS handshake पूरा करना, और HTTP/1.1 या HTTP/2 से request खत्म करना पड़ता है
  • इस तरीके में server के HTTP/3 सपोर्ट का पता पिछली कनेक्शन के बाद ही चलता है, इसलिए HTTP/3 upgrade अगली कनेक्शन में होता है
  • RFC 9460 का HTTPS रिकॉर्ड HTTP/3 सपोर्ट का यही संकेत DNS में रखता है
  • client यह रिकॉर्ड वैसे ही name resolution के दौरान पढ़ता है, इसलिए कनेक्शन खोलने से पहले HTTP/3 सपोर्ट का पता चल सकता है
  • HTTPS DNS रिकॉर्ड के साथ पहली कनेक्शन से QUIC/HTTP/3 इस्तेमाल किया जा सकता है, और पहले HTTP/1 या HTTP/2 connection खर्च करने की जरूरत नहीं रहती

HTTPS रिकॉर्ड बेहतर क्यों है

  • first byte से पहले HTTP/3 की खोज

    • alpn SvcParam endpoint द्वारा समर्थित ALPN protocol IDs की सूची देता है
    • उदाहरण के तौर पर h3 यानी HTTP/3, और h2
    • यह जानकारी name resolution के दौरान मिल जाती है, इसलिए client पहले HTTP/1 या HTTP/2 कनेक्शन के बाद h3 खोजने के बजाय पहली कनेक्शन से ही QUIC चुन सकता है

  • ECH: encrypted Client Hello

    • ech SvcParam endpoint की ECHConfigList public key रखता है
    • ECH, TLS ClientHello को — जिसमें SNI server name शामिल होता है — encrypt करता है ताकि network observer यह न देख सके कि कौन-सी site देखी जा रही है
    • इसे HTTP headers से हल नहीं किया जा सकता, क्योंकि पहली ClientHello भेजने से पहले public key चाहिए होती है
    • key उस समय चाहिए जब अभी कोई connection मौजूद ही नहीं होता, इसलिए DNS के HTTPS रिकॉर्ड जैसा out-of-band channel ही ECH को bootstrap कर सकता है
    • HTTPS RR के बिना ECH भी इस्तेमाल नहीं किया जा सकता

  • IP hints से तेज़ connection start

    • Happy Eyeballs v3 A, AAAA, और HTTPS queries को parallel चलाता है
    • HTTPS response में ipv4hint और ipv6hint तब connection candidate addresses देते हैं जब वे A/AAAA records से पहले पहुँचते हैं
    • client A/AAAA response का इंतज़ार करने के बजाय hinted addresses पर connection शुरू कर सकता है
    • A/AAAA records आते रहते हैं, और आने के बाद hints को replace कर देते हैं
    • Alt-Svc में इसके बराबर कोई सुविधा नहीं है

  • एक authoritative source और caching

    • reachability information सामान्य TTL के साथ DNS में रह सकती है
    • Alt-Svc तरीके में जानकारी origin-specific HTTP header cache में बिखर जाती है और max-age की दुविधा बनती है
    • max-age बहुत लंबा हो तो client पुराने alternatives इस्तेमाल करता रहता है, और बहुत छोटा हो तो बार-बार पुराने protocol पर लौटता है
    • ब्राउज़र वैसे भी DNS lookup करता है, इसलिए HTTPS रिकॉर्ड उस lookup के साथ optimal connection information भी दे सकता है

  • फीचर तुलना

    • | फीचर | Alt-Svc HTTP header (RFC 7838) | HTTPS RR (RFC 9460) |
    • | --- | --- | --- |
    • | सीखने का समय | पूरी connection के बाद | DNS lookup के दौरान |
    • | पहली connection में h3 | नहीं | हाँ |
    • | IP hints | लागू नहीं | ipv4hint / ipv6hint |
    • | ECH key | संभव नहीं | ech parameter |
    • | source of truth | HTTP headers और कमजोर cache | TTL वाला DNS |

वास्तविक ब्राउज़र माप

  • Firefox Nightly माप में ब्राउज़र HTTP/3 सपोर्ट को Alt-Svc HTTP response header या HTTPS DNS रिकॉर्ड से जान सकता है
  • Alt-Svc केवल पहले से कनेक्ट होने के बाद दिखता है, जबकि HTTPS DNS रिकॉर्ड connection से पहले दिखता है
  • सभी connections चार समूहों में से किसी एक में आते हैं
    • Neither वे connections हैं जिनमें HTTP/3 का कोई advertisement नहीं था
    • Alt-Svc only वे connections हैं जिनमें केवल header से advertisement था, इसलिए पहली connection में HTTP/3 इस्तेमाल नहीं हो सका
    • HTTPS record only वे connections हैं जिनमें DNS में advertisement था, इसलिए पहली connection से ही HTTP/3 पर जाया जा सकता था
    • Both वे connections हैं जिनमें DNS और header दोनों में advertisement था
  • मापे गए connection shares थे: Neither 59.8%, Alt-Svc only 31.4%, HTTPS record only 2.8%, Both 6% {b:60,31,3,6}
  • ये चारों समूह सभी connections को पूरी तरह cover करते हैं, इसलिए कुल 100% बनता है
  • HTTPS record only और Both में उपयोग योग्य HTTPS रिकॉर्ड मौजूद था, और Alt-Svc only वह gap था जिसे रिकॉर्ड होने पर कम किया जा सकता था
  • ये आँकड़े Firefox Nightly के GLAM histogram से पुनर्निर्मित per-connection estimates हैं, इसलिए हालिया build averages के रूप में approximate हैं

HTTPS रिकॉर्ड प्रकाशित करना

  • h3 और address hints का advertisement करने वाला ServiceMode HTTPS रिकॉर्ड एक लाइन में प्रकाशित किया जा सकता है
; zone file (BIND-style)
example.com.  3600  IN  HTTPS 1 . alpn="h3,h2" ipv4hint=203.0.113.10 ipv6hint=2001:db8::10
  • example.com. वह नाम है जिस पर रिकॉर्ड प्रकाशित किया जाता है, और अंत का dot पूर्ण domain name को दर्शाता है
  • 3600 सेकंड में TTL है, जितने समय तक resolver इस रिकॉर्ड को cache कर सकता है
  • IN वही Internet DNS class है जो बाकी web records में होती है
  • HTTPS RFC 9460 का record type है
  • 1 priority है, और 1 या उससे ऊपर parameter रखने वाला ServiceMode है
  • 0 AliasMode है, जो सिर्फ किसी दूसरे target की ओर संकेत करता है
  • . target host है, जो owner name itself यानी example.com को दर्शाता है
  • alpn="h3,h2" server द्वारा समर्थित protocols को अच्छे क्रम में सूचीबद्ध करता है; h3 HTTP/3 है और h2 HTTP/2
  • ipv4hint और ipv6hint वे addresses हैं जिन पर client A/AAAA lookup के साथ तुरंत connection शुरू कर सकता है
  • Cloudflare, Route 53 जैसे अधिकांश managed DNS providers सीधे HTTPS record type उपलब्ध कराते हैं
  • domain सपोर्ट है या नहीं, यह checker से देखा जा सकता है

वास्तविक HTTPS रिकॉर्ड किन फीचर्स को रखता है

  • Firefox Nightly में उन connections का अनुपात मापा गया जिनमें HTTPS रिकॉर्ड देखा गया और जिनमें अलग-अलग फीचर्स मौजूद थे
  • ALPN का h3 80.3% था, और IPv4 hint 52.9% था
  • IPv6 hint 49.4% था, और ECH 12.8% था {b:80,53,49,13}
  • ये आँकड़े GLAM histogram से पुनर्निर्मित per-connection estimates हैं, इसलिए approximate हैं

FAQ

  • क्या CDN इसे अपने-आप प्रकाशित करता है

    • कुछ CDN HTTPS रिकॉर्ड अपने-आप प्रकाशित करते हैं
    • Cloudflare proxied zones के लिए alpn="h3" वाला HTTPS रिकॉर्ड अपने-आप देता है
    • दूसरे CDN में इसे user को खुद configure करना पड़ सकता है
    • सबसे तेज़ जाँच का तरीका ऊपर दिया गया डोमेन जाँच है

  • क्या HTTPS रिकॉर्ड पुराने clients को तोड़ देता है

    • जो clients HTTPS रिकॉर्ड नहीं समझते, वे उसे ignore करके सामान्य A/AAAA lookup पर लौट जाते हैं
    • अगर आप अब भी Alt-Svc header भेज रहे हैं, तो ऐसे clients उसका भी इस्तेमाल कर सकते हैं
    • HTTPS रिकॉर्ड प्रकाशित करना मौजूदा व्यवहार के ऊपर अतिरिक्त रूप से जुड़ता है

  • दोबारा आने पर क्या होता है

    • client एक बार HTTP/3 पर बात कर लेने के बाद अगली visit पर QUIC connection को 0-RTT के साथ resume कर सकता है
    • 0-RTT में handshake round trip के बिना पहली request तुरंत भेजी जा सकती है
    • HTTPS रिकॉर्ड खुद भी बाकी DNS responses की तरह TTL तक cache रहता है, इसलिए revisit पर अक्सर lookup भी छूट जाता है

  • कौन-से ब्राउज़र HTTPS रिकॉर्ड इस्तेमाल करते हैं

    • प्रमुख engines HTTPS रिकॉर्ड को default enabled स्थिति में सपोर्ट करते हैं
    • visitor ने DNS-over-HTTPS चालू किया हो या नहीं, रिकॉर्ड पढ़ा जाता है
    • Safari operating system resolver का इस्तेमाल करता है
    • Chrome अपना built-in resolver इस्तेमाल करता है, और DoH या सामान्य DNS दोनों के जरिए काम कर सकता है
    • Firefox दोनों तरीकों का इस्तेमाल कर सकता है

  • क्या Alt-Svc header हटा देना चाहिए

    • Alt-Svc header नहीं हटाना चाहिए
    • पुराने clients और ऐसे resolvers या networks के लिए इसे fallback के रूप में भेजते रहना चाहिए जो HTTPS रिकॉर्ड नहीं पहुँचाते
    • जो ब्राउज़र HTTPS रिकॉर्ड पढ़ते हैं, वे DNS से ही HTTP/3 का पता लगा लेते हैं और HTTP/3 discovery के लिए एक round trip खर्च नहीं करते

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

1 टिप्पणियां

 
GN⁺ 4 시간 전
Lobste.rs की राय
  • वेब होस्टिंग प्रदाता अभी H3 को सपोर्ट नहीं करता, लेकिन नए server version पर मुफ़्त upgrade करके इसे आज़माया जा सकता है
    यह पूरा होने पर HTTPS DNS record सेट करने की योजना है
  • Apple का dig 9.10.6 है, इसलिए लगता है कि यह इस record type से भी पुराना version है
    लगता है Apple को dig का नया version देना चाहिए, और सोच रहा हूँ कि macOS पर DNS lookup के लिए कोई पसंदीदा tool है क्या

    • मैं कई platforms पर doggo पसंद से इस्तेमाल करता हूँ
      यह परफ़ेक्ट नहीं है, लेकिन कुल मिलाकर काफ़ी अच्छा चला और मेरी ज़रूरत की काफ़ी सुविधाएँ देता है

    • मैं Homebrew से इंस्टॉल किया हुआ ldns का drill इस्तेमाल करता हूँ

      % drill -Q https savearoundtrip.com  
1 . alpn=h3,h2 ipv4hint=104.21.20.43,172.67.191.84 ech=AEX+DQBBzwAgACAdG3AfYFkusczSXA/kky1bgK67QViv5mNKyS3ITnrWbAAEAAEAAQASY2xvdWRmbGFyZS1lY2guY29tAAA= ipv6hint=2606:4700:3030::ac43:bf54,2606:4700:3037::6815:142b
  • अगर HTTPS resource record मौजूद हो, तो उसे पढ़ने वाले सभी clients सुरक्षित रूप से connect करेंगे
    भले ही वे QUIC को सपोर्ट न करते हों
  • समझ नहीं आता कि इस पोस्ट पर vibe coding टैग क्यों लगाया गया है
    ज़्यादा से ज़्यादा इतना ही कि CSS ऐसा लग सकता है जैसे वह LLM से निकला हो
    • शुरुआती commit तो पक्का LLM से बना हुआ लगता है: https://github.com/mxinden-bot/savearoundtrip/…
      और लेख बहुत ज़्यादा लंबा-चौड़ा है। इसमें दोहराव, बेकार की बातें और अजीब visualizations बहुत हैं, इसलिए लगभग 1700 शब्दों में page की full-width लंबाई 7300px से भी ज़्यादा हो जाती है
      इसे 500 शब्द, 2 diagrams, और कुल लंबाई 2000px से कम तक घटा दिया जाए तो यह काफ़ी बेहतर होगा