HTTP/3 को समझना: क्या यह वाकई HTTP/2 से बेहतर है?

हर कोई HTTP/3 के बारे में ऐसे बात करता है जैसे यह एक मुफ़्त स्पीड अपग्रेड हो जिसे आप चालू करके भूल जाते हैं। ज़्यादातर ऐसा है ही — पर उस वाक्य में “ज़्यादातर” शब्द बहुत कुछ कह रहा है। HTTP/3 अब दुनिया भर में लगभग 35% वेब रिक्वेस्ट्स के लिए इस्तेमाल होता है [1], तो यह अब कोई रिसर्च का खिलौना नहीं रहा। बात यह है कि लगभग कोई नहीं समझाता कि यह क्यों तेज़ है, यह असल में HTTP/2 से कहाँ हार जाता है, और — वह सवाल जो कोई नहीं पूछता — कि आपकी अपनी साइट को इससे फ़ायदा भी होता है या नहीं। चलिए मैं इसे ऐसे समझाता हूँ जैसे चाय पर किसी दोस्त को समझाऊँ।

असल में बदला सिर्फ़ एक चीज़

यहीं पर लोग ग़लती करते हैं। वे सोचते हैं कि HTTP/3 रिक्वेस्ट लिखने का एक नया तरीका है, नए हेडर, नए मेथड, सब कुछ नया। ऐसा नहीं है।

HTTP सेमांटिक्स — मेथड, स्टेटस कोड, हेडर — HTTP/2 और HTTP/1.1 के बिल्कुल समान हैं [2]। एक GET अब भी GET ही है। एक 404 अब भी 404 ही है। जो बदला वह है ट्रांसपोर्ट: वे बाइट्स इंटरनेट पर कैसे धकेले जाते हैं। HTTP/1.1 और HTTP/2 दोनों TCP पर चलते हैं। HTTP/3 TCP को बाहर फेंक देता है और QUIC नामक एक बिल्कुल नए प्रोटोकॉल पर चलता है, जो खुद UDP पर चलता है [3]।

तो फ़र्क कैसे में है, क्या में नहीं [4]। वह एक अदला-बदली — TCP बाहर, QUIC अंदर — ही पूरी कहानी है। HTTP/3 की हर अच्छी और हर परेशान करने वाली चीज़ इसी से निकलती है।

यह समझने के लिए कि किसी ने इतनी मेहनत क्यों की, आपको वह समस्या समझनी होगी जिससे TCP कभी छुटकारा नहीं पा सका।

हेड-ऑफ़-लाइन ब्लॉकिंग: वह बग जो कभी मरा ही नहीं

यही पूरी कहानी का खलनायक है, तो चलिए इसे ठीक से समझते हैं।

हम यहाँ तक पहुँचे कैसे

पुराने HTTP/1.1 में, आपका ब्राउज़र एक कनेक्शन खोलता और एक बार में एक रिक्वेस्ट भेजता। रिक्वेस्ट, रिस्पॉन्स का इंतज़ार, फिर अगली रिक्वेस्ट। अगर आपको समानांतरता (parallelism) चाहिए थी, तो ब्राउज़र प्रति डोमेन 6 अलग-अलग TCP कनेक्शन खोलता और उन्हें संभालता। बेकार था, पर काम चल जाता था।

HTTP/2 ने इसे मल्टिप्लेक्सिंग से ठीक किया: एक ही TCP कनेक्शन साझा करती कई स्वतंत्र “स्ट्रीम्स”। आपकी CSS, आपकी JS, आपकी इमेजेज़ सब एक ही पाइप पर एक साथ, गुथे हुए बहती हैं। काग़ज़ पर शानदार। और एक साफ़ नेटवर्क पर, वाकई बेहतरीन।

पर यहाँ एक पेच है जिसका ज़िक्र कोई नहीं करता। HTTP/2 स्ट्रीम्स को HTTP लेयर पर मल्टिप्लेक्स करता है, जबकि नीचे TCP अब भी एक सख़्ती से क्रमबद्ध बाइट स्ट्रीम पहुँचाने पर अड़ा रहता है। TCP को न तो पता है न परवाह कि आपके पास 100 स्वतंत्र स्ट्रीम्स हैं। उसे तो बाइट्स का एक ही क्रम दिखता है जो अवश्य क्रम में आना चाहिए।

तो क्या होता है जब एक अकेला पैकेट खो जाता है?

अटकाव

अगर एक पैकेट गिर जाए, तो TCP उसके बाद आने वाली हर चीज़ को रोक देता है — पूरी तरह असंबंधित स्ट्रीम्स के बाइट्स समेत — जब तक वह खोया पैकेट दोबारा भेजकर आ नहीं जाता [5]। आपकी image1.jpg शायद वहाँ पूरी डाउनलोड होकर, रेंडर के लिए तैयार बैठी हो, पर अपनी किसी नेटवर्क दिक़्क़त से नहीं बल्कि इसलिए ब्लॉक हो क्योंकि styles.css का एक पैकेट खो गया [5]।

HTTP/2 ने असल में हेड-ऑफ़-लाइन ब्लॉकिंग को हल नहीं किया। उसने बस इसे एक लेयर नीचे धकेल दिया, एप्लिकेशन लेयर से ट्रांसपोर्ट लेयर में [5]। एक परफ़ेक्ट नेटवर्क पर आप कभी नोटिस ही नहीं करेंगे। पर 2% पैकेट लॉस वाले एक डगमगाते मोबाइल कनेक्शन पर? वह एक अटकाव हर चीज़ पर लहर की तरह फैल जाता है।

यही वह हिस्सा है जिसने मुझे सचमुच चौंकाया जब मैंने पहली बार गहराई से देखा। हमने सालों HTTP/2 मल्टिप्लेक्सिंग का जश्न मनाया, और गंदा राज़ यह था कि TCP एक अकेले गिरे पैकेट से उस सब को बेकार कर सकता था।

hol blocking comparison

QUIC इसे कैसे ख़त्म करता है

QUIC हर स्ट्रीम को सचमुच स्वतंत्र बनाता है। हर QUIC स्ट्रीम अपना ख़ुद का पैकेट क्रम रखती है। तो जब स्ट्रीम #5 एक पैकेट खोती है, तो सिर्फ़ स्ट्रीम #5 अटकती है — स्ट्रीम #1 से #4 और #6 आगे तक तुरंत डिलीवर होती रहती हैं [5]। QUIC अब भी टाइमआउट के बाद खोए पैकेट को दोबारा भेजता है, बिल्कुल TCP की तरह, पर वह बाक़ी सबको साथ में नीचे नहीं खींचता [3]।

यही सबसे बड़ी जीत है। एक साफ़ नेटवर्क पर इससे बमुश्किल फ़र्क पड़ता है। एक लॉसी नेटवर्क पर बहुत फ़र्क पड़ता है।

बाक़ी जीतें (वे भी असली हैं)

सुर्खियाँ हेड-ऑफ़-लाइन ब्लॉकिंग को मिलती हैं, पर QUIC कुछ और जानने लायक अपग्रेड भी साथ बंडल करता है।

तेज़ हैंडशेक

TCP पर HTTP/2 के साथ, एक सुरक्षित कनेक्शन खोलने का मतलब है एक TCP हैंडशेक और फिर उसके ऊपर एक अलग TLS हैंडशेक। QUIC ट्रांसपोर्ट हैंडशेक और क्रिप्टोग्राफ़िक हैंडशेक को एक ही ऑपरेशन में मोड़ देता है — कनेक्शन एक ही फ़्लाइट में स्थापित और एन्क्रिप्टेड [3]।

लोग जो आँकड़े उछालते हैं: HTTP/3 1-RTT कनेक्शन सेटअप और 0-RTT रिज़म्पशन देता है, जबकि HTTP/2 को एक सुरक्षित कनेक्शन के लिए लगभग 3 RTT चाहिए [3]। सीधे शब्दों में, HTTP/3 कनेक्शन HTTP/2 से ~50% तक तेज़ी से सेट कर सकता है [4]। अगर आपके यूज़र आपके सर्वर से दूर हैं — हाई लेटेंसी — तो वे बचे हुए राउंड ट्रिप असली, महसूस होने वाला समय हैं।

एन्क्रिप्शन अब वैकल्पिक नहीं रहा

HTTP/1.1 और HTTP/2 में, TLS एक अलग लेयर के रूप में ऊपर बैठता है जिसे आप जोड़ते हैं। QUIC में, TLS 1.3 एक अभिन्न घटक के रूप में अंदर ही बना हुआ है [3]। बिना एन्क्रिप्शन वाला HTTP/3 जैसी कोई चीज़ है ही नहीं। सच कहूँ तो, मुझे लगता है यह अच्छी बात है — यह “उफ़, प्लेनटेक्स्ट” जैसी ग़लत कॉन्फ़िगरेशन्स की एक पूरी श्रेणी ही हटा देता है।

कनेक्शन माइग्रेशन (कम आँका गया फ़ीचर)

यह मेरा पसंदीदा फ़ीचर है और इसके बारे में लगभग कोई बात नहीं करता।

TCP एक कनेक्शन को क्लासिक 4-ट्यूपल से पहचानता है: सोर्स IP, सोर्स पोर्ट, डेस्टिनेशन IP, डेस्टिनेशन पोर्ट। इनमें से कोई भी बदलिए — मान लीजिए आपका फ़ोन Wi-Fi से 5G पर कूदता है — तो IP बदल जाता है, इसलिए TCP कनेक्शन मर जाता है और उसे शुरू से दोबारा बनाना पड़ता है।

QUIC 4-ट्यूपल पर निर्भर रहने के बजाय एक कनेक्शन की पहचान के लिए एक कनेक्शन ID इस्तेमाल करता है [6]। तो जब आपका फ़ोन नेटवर्क बदलता है, QUIC बस वही कनेक्शन ID बनाए रखता है और चलता रहता है [6]। आपका वीडियो चलता रहता है, आपका डाउनलोड डाउनलोड होता रहता है। यह देखते हुए कि इंटरनेट का कितना बड़ा हिस्सा अब इधर-उधर घूमते नेटवर्क बदलते मोबाइल यूज़र्स हैं, यह सचमुच एक बड़ी बात है।

एक झटपट तुलना

	HTTP/1.1	HTTP/2	HTTP/3
ट्रांसपोर्ट	TCP	TCP	QUIC (UDP पर)
मल्टिप्लेक्सिंग	नहीं (6 कनेक्शन)	हाँ	हाँ
हेड-ऑफ़-लाइन ब्लॉकिंग	हाँ (ऐप लेयर)	हाँ (ट्रांसपोर्ट लेयर)	काफ़ी हद तक हल [5]
एन्क्रिप्शन	TLS वैकल्पिक, ऊपर से जुड़ा	TLS वैकल्पिक, ऊपर से जुड़ा	TLS 1.3 अनिवार्य, अंदर निर्मित [3]
सुरक्षित तक हैंडशेक	कई RTT	~3 RTT [3]	1-RTT / 0-RTT रिज़म [3]
नेटवर्क बदलने पर टिकता है	नहीं	नहीं	हाँ (कनेक्शन माइग्रेशन) [6]

तो क्या HTTP/3 बस… बेहतर है? हमेशा नहीं।

यहीं पर मार्केटिंग पेज चुप हो जाते हैं और मैं साफ़-साफ़ कहूँगा। HTTP/3 हमेशा HTTP/2 से तेज़ नहीं होता [7], और इसके उलट दिखावा करना आपको निराशा की ओर ले जाता है।

CPU की क़ीमत असली है

TCP को दशकों का कर्नेल-स्तर का ऑप्टिमाइज़ेशन मिला है। QUIC UDP पर यूज़रस्पेस में चलता है, जो बिल्कुल वही चीज़ है जो इसे अपडेट और डिप्लॉय करना आसान बनाती है — पर इसकी एक परफ़ॉर्मेंस क़ीमत है [8]।

क्योंकि QUIC यूज़रस्पेस में रहता है, इसे लगातार सिस्टम कॉल्स के ज़रिए ACK पढ़ने पड़ते हैं, और QUIC पैकेट छोटे होते हैं (~1KB), तो उन सभी पैकेट-वार ACK को प्रोसेस करना CPU का एक बड़ा हिस्सा खा जाता है [8]। नतीजा: तेज़, कम-लॉस वाले नेटवर्क पर भरपूर बैंडविड्थ के साथ, एक HTTP/3 ट्रांसफ़र उसी ट्रांसफ़र की तुलना में HTTP/2 पर ज़्यादा CPU समय जला सकता है [8]। हाई-बैंडविड्थ परिदृश्यों में जहाँ CPU अड़चन बन जाता है, HTTP/3 HTTP/1.1 से भी कम थ्रूपुट दिखा सकता है [8]।

इसे फिर से पढ़िए। एक मोटे, साफ़ पाइप पर, “नया, तेज़” प्रोटोकॉल धीमा हो सकता है क्योंकि वह CPU-बाउंड है। एक CPU-बाउंड सर्विस के लिए, HTTP/3 असल में आपकी प्रभावी क्षमता घटा सकता है [8]।

UDP कभी-कभी पहुँचता ही नहीं

QUIC UDP पर चलता है, और कुछ नेटवर्क UDP को संदिग्ध मानते हैं। कुछ फ़ायरवॉल और डिवाइस अनजान UDP प्रोटोकॉल्स को ब्लॉक कर देते हैं, तो QUIC सर्वर से बिना किसी रिस्पॉन्स के टाइमआउट हो जाता है [9]। कुछ कैरियर सेटअप्स पर QUIC के फ़ेल होने की असली रिपोर्ट्स हैं — जैसे कुछ 5G होम इंटरनेट पर UDP का ब्लॉक होना [9]। ब्राउज़र इसे चुपचाप TCP पर HTTP/2 में फ़ॉलबैक करके संभाल लेते हैं, तो यूज़र्स का आमतौर पर कुछ नहीं बिगड़ता — पर इसका मतलब है कि आपके सर्वर पर पहुँचने वाले हर किसी के लिए HTTP/3 एक पक्की जीत नहीं है।

कुछ इन्फ़्रास्ट्रक्चर के पेच भी हैं। कुछ NAT डिवाइस कनेक्शन माइग्रेशन को ठीक से नहीं संभालते, जिससे मोबाइल हैंडऑफ़ के दौरान IP बदलने पर ड्रॉप होते हैं [6]। और एनीकास्ट और ECMP रूटिंग इस्तेमाल करने वाले नेटवर्क के लिए, एक ही QUIC कनेक्शन के पैकेट NAT रीबाइंड या माइग्रेशन के बाद अलग-अलग बैकएंड सर्वर पर रूट हो सकते हैं [6]। इनमें से कोई भी डील-ब्रेकर नहीं है, पर ये उस तरह की चीज़ें हैं जो अपना ख़ुद का एज चलाने पर आपकी एक दोपहर डिबगिंग में बर्बाद करवा देती हैं।

0-RTT वाला फुटगन

वह प्यारा 0-RTT रिज़म्पशन याद है? उसका एक तेज़ धार वाला किनारा है। 0-RTT अर्ली डेटा को रीप्ले किया जा सकता है [10]।

यह तंत्र पिछले सेशन से एक प्री-शेयर्ड की का इस्तेमाल करता है, और क्योंकि अर्ली डेटा सर्वर के यह पुष्टि करने से पहले भेजा जाता है कि वह एक ताज़ा, जीवित क्लाइंट से बात कर रहा है, एक हमलावर उस एन्क्रिप्टेड 0-RTT डेटा की एक कॉपी पकड़कर उसे सेकंडों या मिनटों बाद सर्वर को दोबारा भेज सकता है [10]। सर्वर को एक दोहराई गई रिक्वेस्ट दिखती है जबकि असल में सिर्फ़ एक ही की गई थी [10]। यह चुपचाप उस आइडेम्पोटेन्सी मान्यता को तोड़ देता है जिस पर वेब बना है।

समाधान कोई अनोखी चीज़ नहीं है: 0-RTT पर नॉन-आइडेम्पोटेंट रिक्वेस्ट्स (जैसे POST) की अनुमति न दें। Cloudflare जैसे कुछ CDN पहले से ही नॉन-आइडेम्पोटेंट 0-RTT रिक्वेस्ट्स को डिफ़ॉल्ट रूप से ब्लॉक करते हैं, पर nginx जैसी अन्य इम्प्लीमेंटेशन्स शायद आपको बॉक्स से बाहर सुरक्षा न दें [10]। तो अगर आप ख़ुद हाथ से HTTP/3 तैयार कर रहे हैं, तो इसे सही करना आपके ज़िम्मे है। सच कहूँ तो, यहीं पर यह पेचीदा हो जाता है और यहीं बहुत से लोग चीज़ें ग़लत कॉन्फ़िगर कर बैठेंगे [10]।

असल में इसे इस्तेमाल किसे करना चाहिए?

अब असली सवाल। चलिए इसे इस आधार पर तोड़ता हूँ कि आप कौन हैं, क्योंकि जवाब सचमुच अलग होता है।

आप एक CDN के पीछे एक सामान्य वेबसाइट चलाते हैं

बस इसे चालू कर दीजिए। यह आसान मामला है। अगर आप Cloudflare, Fastly, Cloudron, या इन जैसी किसी पर हैं, तो CDN एज पर HTTP/3 संभाल लेता है — कोई रीकम्पाइलिंग नहीं, कोई कर्नेल पैच नहीं। Cloudflare पर आप शाब्दिक रूप से डैशबोर्ड में इसे टॉगल करते हैं और एज Alt-Svc हेडर के ज़रिए कम्पैटिबल क्लाइंट्स को HTTP/3 का विज्ञापन देना शुरू कर देता है [11]।

वैसे, वह Alt-Svc हेडर ही वह तरीका है जिससे पूरी चीज़ बूटस्ट्रैप होती है। क्लाइंट पहले HTTP/2 पर कनेक्ट होता है, इस तरह का एक रिस्पॉन्स हेडर देखता है, और जान जाता है कि अगली बार वह HTTP/3 आज़मा सकता है [11]:

alt-svc: h3=":443"; ma=86400

CDN आपके लिए CPU ओवरहेड और UDP-फ़ॉलबैक की झंझटें सोख लेता है। मूलतः कोई नुक़सान नहीं है। कर दीजिए।

आप अपना ख़ुद का nginx / ओरिजिन सर्वर चलाते हैं

करने लायक है, पर आँखें खुली रखकर कीजिए। आपको एक ऐसा nginx बिल्ड चाहिए होगा जो QUIC सपोर्ट करे — जिसका ऐतिहासिक रूप से मतलब था QUIC पैच के साथ सोर्स से बिल्ड करना या एक सपोर्टेड फ़ोर्क इस्तेमाल करना [11]। एक न्यूनतम कॉन्फ़िग quic पैरामीटर के साथ एक दूसरी listen लाइन जोड़ती है और सपोर्ट का विज्ञापन देती है:

listen 443 quic reuseport;
listen 443 ssl;          # फ़ॉलबैक के लिए TCP रखें
ssl_protocols TLSv1.3;

add_header alt-svc 'h3=":443"; ma=86400';

सामान्य TCP listen 443 ssl लाइन भी रखें — वह उन क्लाइंट्स और नेटवर्कों के लिए आपका फ़ॉलबैक है जो QUIC नहीं कर सकते [9]। और अर्ली डेटा चालू करने से पहले 0-RTT के बारे में अच्छे से सोचें [10]। अगर आप एक साफ़ डेटासेंटर नेटवर्क पर एक CPU-भारी, हाई-बैंडविड्थ API सर्व करते हैं, तो इसका बेंचमार्क लें — आप पा सकते हैं कि HTTP/2 असल में आपके लिए सस्ता है [8]।

आपके यूज़र मोबाइल पर, दूर, या ख़राब नेटवर्क पर हैं

यहीं HTTP/3 सबसे ज़्यादा चमकता है। हाई लेटेंसी का मतलब है कि तेज़ हैंडशेक असल में महसूस होने वाला समय बचाता है [3]। लॉसी कनेक्शन का मतलब है कि प्रति-स्ट्रीम स्वतंत्रता आपके पेज को चलता रखती है जबकि एक स्ट्रीम रिकवर होती है [5]। और Wi-Fi और सेल्युलर के बीच स्विच करने वाले मोबाइल यूज़र्स को कनेक्शन माइग्रेशन से सीधा फ़ायदा होता है [6]। अगर आपका ऑडियंस “पैची नेटवर्क वाली जगहों में फ़ोन पर लोग” है — असल दुनिया का बड़ा हिस्सा — तो HTTP/3 एक साफ़ जीत है।

आप एक साफ़ नेटवर्क पर एक CPU-बाउंड, हाई-थ्रूपुट बैकएंड चलाते हैं

रुकिए। प्रतिबद्ध होने से पहले बेंचमार्क लीजिए। यही एकमात्र समूह है जिसे शायद फ़ायदा न हो। अगर आपके सर्वर CPU-कंस्ट्रेंड हैं और आपका नेटवर्क तेज़ और भरोसेमंद है, तो यूज़रस्पेस QUIC ओवरहेड आपके थ्रूपुट को खा सकता है [8]। अपने असली ट्रैफ़िक से मापिए, किसी के ब्लॉग बेंचमार्क से नहीं (इस वाले समेत)।

अपनाव असल में कहाँ है

बस ताकि आप जानें कि यह कल्पना नहीं है: 2025 के अंत तक HTTP/3 वैश्विक रिक्वेस्ट्स के लगभग 35% पर बैठता है [1]। वृद्धि धीमी हुई है — HTTP/2 और HTTP/3 दोनों ने 2024 की तुलना में 2025 में सिर्फ़ प्रतिशत के अंश ही हासिल किए [1] — और अपनाव क्षेत्र के हिसाब से काफ़ी अलग है, जहाँ 15 देश अपनी एक-तिहाई से ज़्यादा रिक्वेस्ट्स HTTP/3 पर धकेल रहे हैं [1]। सभी बड़े ब्राउज़र इसे सपोर्ट करते हैं, और बड़े CDN इसे चालू करने के लिए तैयार रखते हैं। यह अब मेनस्ट्रीम है, अत्याधुनिक प्रयोग नहीं।

ईमानदार सारांश? HTTP/3 उन परिस्थितियों के लिए एक असली सुधार है जिनके लिए इसे डिज़ाइन किया गया था — लॉसी नेटवर्क, मोबाइल यूज़र्स, हाई लेटेंसी, ढेर सारी छोटी रिक्वेस्ट्स। यह “सब कुछ तेज़ कर दो” वाला कोई जादुई स्विच नहीं है, और एक साफ़-सुथरे नेटवर्क पर एक CPU-बाउंड सर्विस पर यह चुपचाप आपको महँगा पड़ सकता है। इसे CDN पर चालू कर दीजिए जहाँ यह मुफ़्त और सुरक्षित है। अपने ख़ुद के ओरिजिन पर इसके बारे में सोच-समझकर कीजिए। और चाहे जो हो, POST रिक्वेस्ट्स के लिए 0-RTT चालू करके चलते मत बन जाइए।