Curl HTTP/3 प्रदर्शन
curl के नए HTTP/3/QUIC support के बेंचमार्क दिखाते हैं कि यह अभी localhost पर raw throughput में HTTP/1.1 और HTTP/2 से पीछे है, जिससे QUIC की अधिक CPU लागत और अत्यधिक optimized TCP stacks की परिपक्वता सामने आती है। टिप्पणीकार ध्यान दिलाते हैं कि ये परीक्षण मुख्यतः efficiency मापते हैं, न कि latency और packet loss के तहत वास्तविक-विश्व प्रदर्शन, जहाँ बेहतर multiplexing, congestion control, और connection migration के कारण HTTP/3 बेहतर प्रदर्शन कर सकता है। थ्रेड में implementation details (OpenSSL QUIC, UDP GSO की कमी, Caddy और Debian packaging), HTTP/3 के लिए security और certificate requirements, और नए protocol code के लिए C बनाम Rust के व्यापक प्रश्न भी शामिल हैं.
HTTP/3 / QUIC प्रदर्शन बनाम HTTP/1.1 और HTTP/2
- बेंचमार्क दिखाते हैं कि localhost पर HTTP/1.1 की थ्रूपुट सबसे अधिक है, HTTP/2 धीमा है, और HTTP/3 उससे भी धीमा है।
- कुछ पाठक हैरान या चिंतित हैं; अन्य ज़ोर देते हैं कि यह नेटवर्क प्रदर्शन नहीं, बल्कि loopback पर CPU दक्षता को मापता है।
- कई टिप्पणियाँ इस बात पर ज़ोर देती हैं कि HTTP/2/3 का लक्ष्य latency, multiplexing, और loss की स्थिति में व्यवहार है, न कि केवल कच्ची bandwidth।
- थ्रेड में उद्धृत वास्तविक-विश्व अध्ययनों को Internet परिस्थितियों में HTTP/2 की तुलना में बेहतर HTTP/3 थ्रूपुट दिखाने वाला बताया गया है।
CPU दक्षता बनाम नेटवर्क व्यवहार
- QUIC को स्वाभाविक रूप से TCP+TLS की तुलना में कम CPU-दक्ष माना गया है।
- चर्चा किए गए कारण: प्रति-पैकेट encryption, कई छोटे UDP packets, packet assembly और crypto के लिए अतिरिक्त userspace काम, और connection/stream bookkeeping की अधिक जटिलता।
- एक प्रयोग के अनुसार, mature hardware offload की कमी और TCP kernel/NIC optimizations की लंबी परंपरा कुछ high-throughput server workloads के लिए QUIC को लगभग एक order of magnitude कम दक्ष बनाती है।
Benchmark सेटअप और implementation की परिपक्वता
- संभवतः यह परीक्षण localhost पर चलता है और अपेक्षाकृत पुराने Caddy / quic-go stack का उपयोग करता है, जिसमें GSO नहीं है और UDP buffer tuning भी उपयुक्त नहीं है।
- कुछ लोगों का तर्क है कि इससे QUIC के साथ अनुचित व्यवहार होता है और अत्यधिक tuned TCP stacks को लाभ मिलता है।
- अन्य लोग नोट करते हैं कि HTTP/1.1 को 50 parallel TCP connections दिए गए थे, जबकि वास्तविक browsers आम तौर पर इससे कहीं कम का उपयोग करते हैं।
Protocol trade-offs: Parallelism, HOL blocking, और connections
- इस पर बहस है कि क्या HTTP/1.1 में सचमुच head-of-line blocking “होता” है: protocol की सीमा बनाम व्यावहारिक सीमाएँ (browser connection caps, connection setup cost)।
- HTTP/2/3 multiplexing को parallelism और HOL समस्याओं के समाधान के रूप में देखा जाता है, हालांकि कुछ का तर्क है कि multiple TCP connections पहले से ही उच्च प्रदर्शन दे सकते हैं।
- TCP 64k port/connection limits बनाम multiple IPs, DSR, और SO_REUSEPORT जैसी तकनीकों पर चर्चा हुई; यह context-dependent है और कुछ हद तक विवादास्पद भी।
Deployment मुद्दे और implementations (curl, nginx, Debian, Caddy)
- curl maintainers HTTP/3 को सक्षम करने की दिशा में बढ़ रहे हैं (GnuTLS या OpenSSL QUIC के माध्यम से) और WebSocket support पर भी विचार कर रहे हैं; अभी भी experimental है।
- कुछ लोगों ने nginx के माध्यम से HTTP/2 में गंभीर latency समस्याएँ बताई हैं (विशेषकर Kubernetes में), जिन्हें HTTP/1.1 पर वापस जाकर ठीक किया गया; अन्य कहते हैं कि nginx का non-H1 support कमज़ोर है।
- Debian में Caddy versioning को outdated और under-patched कहा गया है; “stable” packaging और समय पर security/perf fixes के बीच तनाव है।
Security, certificates, और “Human Web”
- HTTP/3 में mandatory TLS और null cipher / TLS-less modes की अनुपस्थिति self-signed और hobbyist sites के लिए चिंता पैदा करती है।
- कुछ लोगों को आशंका है कि public CAs और browser policies पर निर्भरता self-hosted, non-corporate sites को और हाशिए पर धकेल देगी, जबकि TOFU/self-signed workflows कमजोर पड़ेंगे।
Language और implementation विकल्प (C vs Rust)
- यह निराशा व्यक्त की गई कि नया QUIC code C में लिखा जा रहा है, जबकि Rust QUIC implementations मौजूद हैं और curl में पहले Rust का उपयोग हुआ है।
- प्रतिवाद: Rust toolchains कई niche और embedded architectures के लिए उपलब्ध या सत्यापित नहीं हैं; Rust की binary size और build cost अधिक होती है; ecosystem की परिपक्वता और target coverage अभी भी व्यावहारिक सीमाएँ हैं।