HTTP/3 समजून घेणे: ते खरंच HTTP/2 पेक्षा चांगलं आहे का?

प्रत्येकजण HTTP/3 बद्दल असं बोलतो की जणू ती एक फुकटची स्पीड अपग्रेड आहे जी तुम्ही चालू करता आणि विसरून जाता. बहुतांश वेळा तसंच असतं — पण त्या वाक्यातला “बहुतांश” हा शब्द खूप काही सांगून जातो. HTTP/3 आता जगभरात साधारण ३५% वेब रिक्वेस्ट्ससाठी वापरलं जातं [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 मध्ये, तुमचा ब्राउझर एक कनेक्शन उघडायचा आणि एका वेळी एक रिक्वेस्ट पाठवायचा. रिक्वेस्ट, रिस्पॉन्सची वाट पाहा, पुढची रिक्वेस्ट. तुम्हाला समांतरता हवी असेल, तर ब्राउझर प्रत्येक डोमेनसाठी ६ वेगवेगळी TCP कनेक्शन्स उघडायचा आणि ती सांभाळायचा. वायफळ, पण काम चालायचं.

HTTP/2 ने हे मल्टिप्लेक्सिंग ने सोडवलं: एकाच TCP कनेक्शनवर अनेक स्वतंत्र “स्ट्रीम्स”. तुमचं CSS, तुमचं JS, तुमच्या इमेजेस सगळं एकाच पाइपवर एकाच वेळी, एकमेकांत गुंफून वाहतं. कागदावर अप्रतिम. आणि स्वच्छ नेटवर्कवर खरोखरच उत्तम.

पण इथे एक अडचण आहे जी कोणी सांगत नाही. HTTP/2 स्ट्रीम्स HTTP लेयरवर मल्टिप्लेक्स करतं, तर खालचं TCP अजूनही एकच कठोरपणे क्रमबद्ध केलेला बाइट स्ट्रीम पोहोचवण्याचा आग्रह धरतं. तुमच्याकडे १०० स्वतंत्र स्ट्रीम्स आहेत हे TCP ला माहीतही नसतं किंवा पर्वाही नसते. त्याला फक्त बाइट्सचा एक क्रम दिसतो जो क्रमानेच पोहोचला पाहिजे.

मग एखादं पॅकेट हरवलं तर काय होतं?

अडथळा

जर एक पॅकेट पडलं, तर TCP त्यानंतर आलेलं सगळं थांबवतं — पूर्णपणे असंबंधित स्ट्रीम्सचे बाइट्ससुद्धा — जोपर्यंत ते हरवलेलं पॅकेट पुन्हा पाठवलं जाऊन पोहोचत नाही [5]. तुमची image1.jpg कदाचित तिथेच पूर्ण डाउनलोड होऊन, रेंडर व्हायला तयार बसलेली असेल, तिची स्वतःची नेटवर्क समस्या नसताना ब्लॉक झालेली असेल कारण styles.css चं एक पॅकेट हरवलं [5].

HTTP/2 ने प्रत्यक्षात हेड-ऑफ-लाइन ब्लॉकिंग सोडवलंच नाही. त्याने ते फक्त एक लेयर खाली ढकललं, ॲप्लिकेशन लेयरमधून ट्रान्सपोर्ट लेयरमध्ये [5]. परिपूर्ण नेटवर्कवर तुम्हाला कधीच जाणवणार नाही. पण २% पॅकेट लॉस असलेल्या नाजूक मोबाइल कनेक्शनवर? तो एक अडथळा सगळ्यावर लाटांसारखा पसरतो.

जेव्हा मी पहिल्यांदा खोलात गेलो तेव्हा हाच भाग मला खरोखर आश्चर्यचकित करून गेला. आपण वर्षानुवर्षे HTTP/2 मल्टिप्लेक्सिंगचा गौरव केला, आणि गुपित हे होतं की एका हरवलेल्या पॅकेटने TCP त्या सगळ्याचं काम मातीमोल करू शकतं.

hol blocking comparison

QUIC ते कसं संपवतं

QUIC प्रत्येक स्ट्रीमला खऱ्या अर्थाने स्वतंत्र करतं. प्रत्येक QUIC स्ट्रीम स्वतःचा पॅकेट क्रम राखतो. त्यामुळे जेव्हा स्ट्रीम #5 चं एक पॅकेट हरवतं, तेव्हा फक्त स्ट्रीम #5 थांबतो — स्ट्रीम #1 ते #4 आणि #6 पुढे लगेच पोहोचत राहतात [5]. QUIC अजूनही TCP प्रमाणेच टाइमआउटनंतर हरवलेलं पॅकेट पुन्हा पाठवतं, पण ते बाकी सगळ्यांना सोबत खाली ओढत नाही [3].

हाच मुख्य विजय आहे. स्वच्छ नेटवर्कवर त्याचा फारसा फरक पडत नाही. पण लॉसी नेटवर्कवर खूप फरक पडतो.

इतर विजय (तेसुद्धा खरे आहेत)

हेड-ऑफ-लाइन ब्लॉकिंगला मथळे मिळतात, पण QUIC आणखी काही अपग्रेड्स सोबत आणतं जी जाणून घेण्यासारखी आहेत.

वेगवान हँडशेक्स

HTTP/2 over TCP मध्ये, एक सुरक्षित कनेक्शन उघडणं म्हणजे एक 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-tuple ने ओळखतं: सोर्स IP, सोर्स पोर्ट, डेस्टिनेशन IP, डेस्टिनेशन पोर्ट. यातलं कोणतंही बदला — समजा तुमचा फोन Wi-Fi वरून 5G वर उडी मारतो — आणि IP बदलतो, त्यामुळे TCP कनेक्शन मरतं आणि पुन्हा सुरुवातीपासून बांधावं लागतं.

QUIC 4-tuple वर अवलंबून न राहता कनेक्शन ओळखण्यासाठी कनेक्शन 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 वेळेपेक्षा जास्त 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]. ब्राउझर्स हे शांतपणे HTTP/2 over TCP वर परत येऊन हाताळतात, त्यामुळे वापरकर्त्यांचं काम सहसा बिघडत नाही — पण याचा अर्थ असा की तुमच्या सर्व्हरला हिट करणाऱ्या प्रत्येकासाठी HTTP/3 हा हमखास विजय नाही.

इन्फ्रास्ट्रक्चरमधले काही सापळेही आहेत. काही NAT डिव्हाइसेस कनेक्शन मायग्रेशन योग्य रीतीने हाताळत नाहीत, ज्यामुळे मोबाइल हँडऑफदरम्यान IP बदलल्यावर कनेक्शन तुटतं [6]. आणि anycast व 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 / ओरिजिन सर्व्हर चालवता

करण्यासारखं आहे, पण डोळे उघडे ठेवून करा. तुम्हाला QUIC ला सपोर्ट करणारी nginx बिल्ड लागेल — ज्याचा अर्थ पारंपरिकपणे QUIC पॅचसह सोर्सवरून बिल्ड करणं किंवा एखादा सपोर्टेड फोर्क वापरणं असा होतो [11]. एक किमान कॉन्फिग quic पॅरामीटरसह एक दुसरी listen ओळ जोडतो आणि सपोर्टची जाहिरात करतो:

listen 443 quic reuseport;
listen 443 ssl;          # keep TCP for fallback
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]. कोणाच्या तरी ब्लॉग बेंचमार्कने नव्हे (या ब्लॉगसह), तर तुमच्या खऱ्या ट्रॅफिकने मोजा.

अवलंबन प्रत्यक्षात कुठे आहे

हे काल्पनिक नाही हे तुम्हाला कळावं म्हणून: २०२५ च्या उत्तरार्धापर्यंत HTTP/3 जागतिक रिक्वेस्ट्सच्या साधारण ३५% वर आहे [1]. वाढ मंदावली आहे — HTTP/2 आणि HTTP/3 या दोघांनीही २०२४ च्या तुलनेत २०२५ मध्ये केवळ टक्क्याचे अंश मिळवले [1] — आणि अवलंबन प्रदेशानुसार खूप वेगवेगळं आहे, १५ देश आपल्या एक तृतीयांशाहून जास्त रिक्वेस्ट्स HTTP/3 वर ढकलत आहेत [1]. सर्व प्रमुख ब्राउझर्स त्याला सपोर्ट करतात, आणि मोठ्या CDN कडे ते चालू करायला तयार आहे. ते आता मुख्य प्रवाहातलं आहे, अगदी अत्याधुनिक धार नाही.

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