HTTP/2 और HTTP/3 समझाए गए

मूल लेख ↗ Hacker News चर्चा ↗

HTTP/1.1 पाइपलिनिंग और मिडिलबॉक्सेस

  • स्पेक के अनुसार, HTTP/1.1 एक ही TCP कनेक्शन पर पहले वाली प्रतिक्रियाएँ आए बिना कई अनुरोध भेजने की अनुमति देता है।
  • कई टिप्पणीकार कहते हैं कि व्यवहार में यह “कभी सच में काम नहीं किया”: खराब प्रॉक्सी, antivirus MITM, और middleboxes प्रतिक्रियाओं को बिगाड़ देते हैं या आपस में मिला देते हैं।
  • इसी वजह से, सैद्धांतिक रूप से सही होने के बावजूद, ब्राउज़र ने बड़े पैमाने पर पाइपलिनिंग छोड़ दी।

Head-of-Line Blocking, Multiplexing, और प्रदर्शन

  • स्पष्टता: HTTP/1.1 में, आप कई अनुरोध भेज सकते हैं, लेकिन अक्सर बाद वाले अनुरोधों का उपयोग करने से पहले पहले वाली प्रतिक्रियाओं की प्रतीक्षा करनी पड़ती है।
  • ब्राउज़र प्रति origin concurrent TCP connections की संख्या सीमित करते हैं (ऐतिहासिक रूप से कम, बाद में लगभग ~6–10), जिससे blocking हो सकती है।
  • कुछ लोगों का तर्क है कि HTTP/2 की single-connection multiplexing TCP स्तर पर head-of-line पैदा करती है: एक stream पर packet loss अन्य streams को रोक सकता है।
  • अन्य लोग जवाब देते हैं कि कई HTTP/1.1 connections की अपनी कमियाँ होती हैं (handshakes, slow start, kernel limits)।

व्यवहार में HTTP/2

  • राय बंटी हुई है:
    • सकारात्मक: सामान्य connections पर आम तौर पर तेज़; साफ़ डिज़ाइन (सारा metadata headers के रूप में, streams, HPACK); RPC और कई web workloads के लिए अच्छा काम करता है।
    • नकारात्मक: कुछ लोग mobile load times में 5–25% खराबी की रिपोर्ट करते हैं, खासकर high latency/loss और interactive + lazy-loading use cases में। डेटा का संदर्भ दिया जाता है लेकिन साझा नहीं किया जाता, जिससे anecdote बनाम evidence के आरोप लगते हैं।
  • server push को व्यापक रूप से एक असफल feature माना जाता है; major browsers ने इसे हटा दिया है।

HTTP/3 / QUIC और UDP

  • HTTP/3/QUIC को unstable/mobile networks के लिए connection migration और loss के बेहतर handling के कारण सराहा जाता है।
  • एक टिप्पणीकार कहता है कि satellite links पर HTTP/3, HTTP/1.1 + satellite “PEP” से खराब प्रदर्शन करता है।
  • QUIC के UDP पर DDoS implications और “QUIC over TCP” प्रस्तावों को लेकर चिंताएँ उठाई गई हैं, जो वास्तविक दुनिया की friction का संकेत मानी जाती हैं।
  • इस पर चर्चा कि UDP कम optimized क्यों है: hardware और OS TCP offloads (segmentation, coalescing) UDP पर साफ़ तौर पर लागू नहीं होते।

जटिलता बनाम लाभ

  • कुछ लोगों का तर्क है कि यदि HTTP/2/3 को HTTP/1.1 की तुलना में implement करना अधिक जटिल और महँगा है, तो यह एक गलती है।
  • अन्य लोग जवाब देते हैं कि जब कुछ ही implementations अरबों उपयोगकर्ताओं को सेवा देते हैं, तब जटिलता उचित है, और HTTP/3 प्रभावी रूप से TCP+TLS+HTTP को एक stack में मिला देता है, जिसकी कुल जटिलता समान होती है।
  • आधुनिक cloud platforms पर app developers के लिए, HTTP/3 managed load balancers के ज़रिए “free” हो सकता है।

TLS, CAs, और दीर्घायु / सेंसरशिप

  • HTTP/3 के लिए mandatory CA-based TLS पर तीखी असहमति है:
    • समर्थन पक्ष: असुरक्षित/plain या self-signed deployments को सार्वजनिक रूप से expose नहीं करना चाहिए; user safety और privacy सुविधा से ऊपर हैं।
    • विरोध पक्ष: CA पर निर्भरता दीर्घायु को नुकसान पहुँचाती है (cert expiry, ACME fragility), सेंसरशिप के लिए शक्ति केंद्रीकृत करती है, और सरल personal sites को रोकती है; self-signed या plain-text संभव रहना चाहिए (warnings के साथ)।
  • इस पर बहस कि क्या read-only content के लिए encryption हमेशा आवश्यक है; विरोधी hostile jurisdictions में surveillance को इसका कारण बताते हैं।

उपयोग-क्षेत्र और “HTTP/2/3 किसके लिए हैं”

  • एक टिप्पणीकार का तर्क है कि HTTP/2/3 मुख्यतः ad-heavy, multi-domain pages की समस्याएँ हल करते हैं, जो बड़े ad और CDN कंपनियों द्वारा संचालित होती हैं, न कि सरल text retrieval की।
  • उनका दावा है कि single-domain text fetching के लिए HTTP/1.1 pipelining अभी भी बेहतर है; अन्य लोग इससे असहमत हैं लेकिन कोई counter-benchmark नहीं देते।
  • कई images को अलग-अलग browsers/HTTP versions पर लोड करने का एक छोटा test विभिन्न parallelism और ordering दिखाता है, जो implementation variance को उजागर करता है।

Higher-Layer Multiplexing बनाम SCTP

  • एक अनसुलझा प्रश्न: HTTP/2/3 multiplexing application layer पर (TCP/UDP के ऊपर) क्यों किया गया, सीधे SCTP का उपयोग क्यों नहीं किया गया।
  • थ्रेड यह प्रश्न उठाता है, लेकिन कोई स्पष्ट उत्तर नहीं देता।