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

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 का उपयोग क्यों नहीं किया गया।
• थ्रेड यह प्रश्न उठाता है, लेकिन कोई स्पष्ट उत्तर नहीं देता।