پذیرش HTTP/3 در ۲۱٪ متوقف شده است — فیزیک پشت این رکود
وقتی IETF در سال ۲۰۲۲ HTTP/3 را استاندارد کرد، وعده واضح بود: پروتکلی مبتنی بر QUIC که head-of-line blocking TCP را حذف میکند، اتصال سریعتری دارد و روی شبکههای ناپایدار بهتر عمل میکند. چهار سال بعد، ۳۹.۵٪ وبسایتها از HTTP/3 پشتیبانی میکنند — اما فقط ۲۱.۱۱٪ درخواستهای واقعی از آن استفاده میکنند که نسبت به اوج ۲۲.۱۶٪ در ژانویه ۲۰۲۶ کاهش یافته است. منحنی پذیرش صاف شده است.
این داستان کندی توسعهدهندگان در ارتقا نیست. داستان فیزیک است.
پارادوکس شبکه سریع
روی اتصالات با پهنای باند بالا و تأخیر کم — همانهایی که بیشتر کاربران سازمانی و ترافیک دیتاسنترها استفاده میکنند — HTTP/3 بدتر از HTTP/2 عمل میکند. یک مقاله در سال ۲۰۲۴ در کنفرانس ACM Web کاهش ۴۵.۲٪ در نرخ داده برای QUIC نسبت به HTTP/2 روی شبکههای بالای ۵۰۰ مگابیت بر ثانیه اندازهگیری کرد. دلیلش: الگوریتمهای کنترل ازدحام QUIC برای شبکههای موبایل با نوسان و اتلاف طراحی شده بودند. روی فیبر، این الگوریتمها محافظهکارتر از الگوریتمهای قدیمی TCP عمل میکنند.
QUIC همچنین روی UDP اجرا میشود، بنابراین نمیتواند از Hardware Offloading کارتهای شبکه مدرن برای TCP استفاده کند. هر بسته QUIC به چرخههای CPU نیاز دارد که بستههای TCP ندارند. در مقیاس دیتاسنترهایی که میلیونها درخواست در ثانیه پردازش میکنند، این سربار قابل توجه است.
جایی که HTTP/3 واقعاً برنده میشود
داستان عملکرد روی شبکههای موبایل و بازارهای نوظهور متفاوت است. گزارش عملکرد ۲۰۲۵ Akamai کاهش ۳۰٪ تأخیر را روی اتصالات با اتلاف بسته بالای ۲٪ نشان داد — وضعیتی رایج در شبکههای سلولی آفریقا، جنوب آسیا و اروپای روستایی. برای کاربران روی Wi-Fi شلوغ یا آنهایی که در حین جلسه بین سلولها جابهجا میشوند، Connection Migration HTTP/3 (که جلسه را حتی با تغییر IP کلاینت حفظ میکند) بهبود واقعی نسبت به نیاز TCP به برقراری مجدد اتصال است.
این باعث شکاف عجیبی میشود: HTTP/3 به کاربرانی که بیشتر به آن نیاز دارند (کسانی که روی اتصالات ضعیف هستند) کمک میکند، اما برای کاربران روی اتصالات سریع که حجم بیشتری از ترافیک را حمل میکنند، اوضاع را کمی بدتر میکند.
پذیرش CDN در مقابل واقعیت ترافیک
ارائهدهندگان بزرگ CDN — Cloudflare، Fastly، Akamai — همه به صورت بومی از HTTP/3 پشتیبانی میکنند. بازار خدمات لبه CDN با قابلیت QUIC از ۲.۸۴ میلیارد دلار در ۲۰۲۵ به ۳.۷۹ میلیارد دلار در ۲۰۲۶ با CAGR ۳۳٪ رشد میکند. اما پشتیبانی از یک پروتکل و هدایت ترافیک روی آن دو تصمیم جداگانه هستند. CDNها به طور فزایندهای فعالسازی انتخابی HTTP/3 را بر اساس ویژگیهای کلاینت ارائه میدهند: کلاینتهای موبایل با تأخیر بالا QUIC دریافت میکنند، در حالی که کلاینتهای دسکتاپ روی فیبر HTTP/2 میگیرند.
این استقرار انتخابی احتمالاً سالمتر از پذیرش همگانی است. یعنی مزایای HTTP/3 جایی که واقعی هستند متمرکز میشوند و هزینههایش برای کاربرانی که سود نمیبرند نامرئی میماند.
رکود ۲۱٪ شکست نیست
قاببندی منحنی پذیرش به عنوان شکست، اشتباه است. HTTP/3 دقیقاً همان کاری را انجام داد که برایش طراحی شده بود — عملکرد را برای اتصالات با اتلاف و تأخیر بالا بهبود بخشید. اشتباه، روایت گستردهتری بود که میگفت این پروتکل به طور جهانی جایگزین HTTP/2 برای همه ترافیک میشود. پروتکلها اینطور کار نمیکنند.
خوانش دقیقتر: HTTP/3 برای ترافیک موبایل اول، اتصالات CDN به کلاینت با کیفیت متغیر، و هر سناریویی که Connection Migration یا جریانهای چندگانه سربار UDP را توجیه میکند، پیشفرض باقی میماند. HTTP/2 برای ترافیک سرور به سرور، دیتاسنتر و کلاینتهای با پهنای باند بالا که بهینهسازیهای سختافزاری TCP و کنترل ازدحام بالغ مزیت دارند، غالب خواهد بود.
برای مهندسانی که امروز تصمیمات استقرار میگیرند، نکته عملی است: قبل از فرض اینکه HTTP/3 بهبود میدهد، پروفایل ترافیک واقعی خود را اندازه بگیرید. اگر کاربران شما عمدتاً روی اتصالات با پهنای باند بالا و اتلاف کم هستند، تغییر پروتکل ممکن است هزینه throughput داشته باشد. اگر آنها روی موبایل در بازارهایی با پوشش متغیر هستند، احتمالاً کمک میکند.
چه چیزی در پیش است
گروه کاری QUIC در IETF از شکاف عملکرد در پهنای باند بالا آگاه است. کار روی الگوریتمهای کنترل ازدحام QUIC که از پهنای باند در شبکههای قابل اعتماد بهتر استفاده کنند، و نیز پشتیبانی سختافزاری از UDP Offloading که شکاف هزینه CPU با TCP را کاهش دهد، ادامه دارد. این پیشرفتها زمان میبرد تا در اکوسیستم منتشر شوند.
در این میان، سهم ۲۱٪ مصرف HTTP/3 یک سقف نیست — جایی است که پروتکل با توجه به دامنه عملکردش به طور طبیعی قرار گرفته است. اینکه بیشتر رشد کند، کمتر به پشتیبانی مرورگر (که همگانی است) بستگی دارد و بیشتر به بهبود ویژگیهای عملکرد پروتکل روی انواع شبکهای که بیشترین ترافیک را حمل میکنند.