HTTP/3 को व्यापक समर्थन मिलने के बावजूद इसका वास्तविक उपयोग बहुत कम क्यों है

• HTTP/3 का विकास 2016 से हो रहा है, और इसका आधार प्रोटोकॉल QUIC पहली बार 2013 में Google ने पेश किया था
• यह अब standardize हो चुका है और इसे व्यापक समर्थन मिला हुआ है
  • 95% ब्राउज़र इसे support करते हैं
  • Cloudflare के HTTP requests में से 32% HTTP/3 का उपयोग करते हैं
  • 35% वेबसाइटों पर HTTP/3 support दिखता है (alt-svc या DNS के माध्यम से)
• लेकिन प्रमुख भाषाओं की standard library में QUIC और HTTP/3 support की कमी है
  • Node.js, Go, Rust, Python, Ruby आदि की standard library में यह शामिल नहीं है
  • Curl ने हाल ही में HTTP/3 support जोड़ा है, लेकिन यह experimental स्थिति में है और default रूप से disabled है
  • लोकप्रिय सर्वर Nginx में support experimental है और default रूप से disabled है
  • Apache की HTTP/3 support की कोई योजना नहीं है
  • Kubernetes के Ingress-Nginx ने HTTP/3 support की योजना छोड़ दी है

HTTP/1.1 के बाद इसकी ज़रूरत

• HTTP/3 high-latency web browser और CDN traffic के लिए उपयोगी है
• HTTP/2 और HTTP/3 के मुख्य फायदे:
  • multiplexing से response latency कम होती है
  • HTTP header compression से traffic कम होता है (HPACK, QPACK का उपयोग)
  • bidirectional streaming से client और server के बीच real-time data exchange संभव होता है
  • prioritization के जरिए महत्वपूर्ण requests को पहले process किया जा सकता है
• HTTP/3 के अतिरिक्त फायदे:
  • independent stream handling से packet loss का असर दूसरी streams पर नहीं पड़ता
  • 0-RTT TLS handshake से connection initialization तेज़ होता है
  • connection migration से IP address बदलने पर भी connection बना रह सकता है
  • बेहतर congestion control से performance और reliability बढ़ती है

HTTP/3 के performance improvement का असर

• RequestMetric benchmark के नतीजे:
  • HTTP/3, HTTP/1.1 और HTTP/2 की तुलना में तेज़ response speed देता है
• Fastly का वास्तविक उदाहरण:
  • HTTP/3 में time to first byte 18% कम हुआ

HTTP/3 support की कमी की समस्या

• HTTP/3 को browser और CDN में व्यापक support है, लेकिन सामान्य developers के लिए इसका उपयोग करना कठिन है
• आज के web traffic के दो प्रकार:
  • hyperscale web: प्रमुख browsers और बड़े server platforms पर आधारित (Google, Meta, Amazon आदि)
  • long-tail web: छोटे और मध्यम server तथा client environments पर आधारित (backend API, mobile apps, IoT आदि)
• मुख्य अंतर:
  • long-tail traffic कुल traffic का 67% है
  • hyperscale में तेज़ development और deployment संभव है, जबकि long-tail में resources कम होते हैं और stability को प्राथमिकता दी जाती है
  • open source tools पर निर्भरता अधिक होती है

OpenSSL और QUIC की समस्या

• OpenSSL अधिकांश open source networking tools की नींव है
• BoringSSL ने 2018 में QUIC support API जारी किया था, लेकिन OpenSSL ने अपना अलग QUIC API पेश किया
• मुख्य समस्याएँ:
  • यह मौजूदा BoringSSL-आधारित implementations के साथ compatible नहीं है
  • Curl और प्रमुख भाषाओं के लिए OpenSSL dependency बदलना कठिन है
  • Node.js ने OpenSSL के बजाय BoringSSL उपयोग करने पर विचार किया था, लेकिन यह संभव नहीं हो पाया

आगे की दिशा

• hyperscale web द्वारा HTTP/3 अपनाने से long-tail web के साथ performance gap पैदा हो सकता है
• HTTP/3 support की कमी से ये समस्याएँ हो सकती हैं:
  • hyperscale sites की speed और reliability की बढ़त और मज़बूत हो सकती है
  • अगर HTTP/3-आधारित frameworks आम हो जाते हैं, तो long-tail web के लिए पहुँच कठिन हो सकती है
  • HTTP/3 support न होना client blocking के मानदंड के रूप में इस्तेमाल किया जा सकता है
• समाधान:
  • OpenSSL के QUIC API से जुड़ी समस्याओं का समाधान ज़रूरी है
  • मौजूदा QUIC और HTTP/3 implementations के साथ compatibility बढ़ाने वाले tools और adapters विकसित करने की ज़रूरत है
  • open source tools में HTTP/3 support बढ़ाने के लिए प्रयास आवश्यक हैं

निष्कर्ष

• HTTP/3 स्पष्ट performance और reliability लाभ देता है, लेकिन अभी यह ऐसी स्थिति में है जहाँ केवल hyperscale कंपनियाँ ही इसे आसानी से उपयोग कर सकती हैं
• long-tail web में भी HTTP/3 को आसानी से उपयोग योग्य बनाने के लिए tools और standards में सुधार की आवश्यकता है

[GN⁺]

Hacker News की राय

• यह राय है कि HTTP/3 को पूरी तरह सपोर्ट करने वाले लोकप्रिय open source tools ढूँढना मुश्किल है

  • IT admins और DevOps engineers आमतौर पर load balancer पर HTTP/3 connection terminate करते हैं, SSL terminate करने के बाद backend services तक HTTP 1.1 भेजते हैं
  • HTTP/3 और IPv6 mobile-केंद्रित technologies हैं, और data center की तुलना में अस्थायी व अस्थिर connections में अधिक उपयोगी हैं

• प्रमुख भाषाओं की standard libraries में QUIC या HTTP/3 शामिल नहीं हैं

  • .NET HTTP/3 के लिए ठीक-ठाक support देता है
  • ज़्यादातर development teams networking-केंद्रित products नहीं बनातीं, इसलिए HTTP/3 की priority कम रहती है

• HTTP/3 के बड़े पैमाने पर deployment में सबसे बड़ी समस्या यह है कि संभावित रूप से कमजोर code का attack surface बढ़ जाता है

  • यह अधिक वांछनीय है कि operating system सुरक्षित socket layer और dynamically linked SSL library प्रदान करे
  • अधिकांश client applications में request की कुछ milliseconds की latency कोई बड़ी समस्या नहीं होती

• QUIC को धीरे अपनाए जाने का कारण यह है कि OpenSSL ने मौजूदा QUIC implementations के लिए ज़रूरी building blocks उपलब्ध नहीं कराए थे

  • हाल ही में OpenSSL 3.5 ने third-party QUIC stacks के लिए API उपलब्ध कराई है

• HTTP/2 और HTTP/3 को अब application-layer protocols नहीं, बल्कि TCP और TLS स्तर की चीज़ों के रूप में देखा जाता है

  • developers अब भी "plain text HTTP 1.1" की दुनिया में रह रहे हैं

• nginx अभी भी production-ready HTTP/3 support उपलब्ध नहीं कराता

• Python में niquests इस्तेमाल किया जा रहा है, और यह HTTP/3 को support करता है

  • Python ecosystem inertia की वजह से requests package पर टिका रहा

• Node.js ने QUIC की स्थिति पर update प्रकाशित किया है, और OpenSSL के धीमे API support के कारण कठिनाइयों का सामना कर रहा है

• अगर public cloud providers के load balancer इस्तेमाल किए जाएँ, तो डिफ़ॉल्ट रूप से HTTP/3 उपयोग होता है

  • अपने server इस्तेमाल करने वाली sites को HTTP/3 के फ़ायदे नहीं मिल रहे हैं

• सभी projects किसी न किसी हद तक open source और community-driven होते हैं

  • HTTP/3 को जल्दी support करने की ज़रूरत महसूस नहीं की गई