HTTP/2 در برابر HTTP/3: واقعاً چه تغییری کرد و برای سایت شما چه معنایی دارد

چرا HTTP/1.1 باید کنار می‌رفت

یک صفحه‌ی مدرن به ده‌ها منبع نیاز دارد — HTML، CSS، اسکریپت‌ها، تصاویر، فونت‌ها. HTTP/1.1 در هر اتصال فقط یک درخواست را در آنِ واحد جواب می‌داد، پس مرورگرها حدود شش اتصال موازی به هر هاست باز می‌کردند و بقیه را در صف می‌گذاشتند. هر اتصال هزینه‌ی handshake مخصوص TCP و TLS خودش را می‌پرداخت، و یک پاسخ کند همه‌ی صف پشت سرش روی همان اتصال را نگه می‌داشت. ترفندهای آن دوران — sprite sheet‌ها، domain sharding، inline کردن — همه حقه‌هایی بودند برای عبوردادن منابع بیشتر از لوله‌هایی که کم بودند.

HTTP/2 چه چیزی را درست کرد

HTTP/2 (سال 2015) لوله‌ها را با یکی جایگزین کرد: یک اتصال واحد که استریم‌های موازی متعددی را حمل می‌کند. هر تعداد درخواست و پاسخ بدون صف‌شدن پشت هم در لایه‌ی HTTP در هم بافته می‌شوند؛ هدرها به‌جای تکرار کامل در هر درخواست فشرده می‌شوند؛ هزینه‌ی handshake یک‌بار پرداخت می‌شود.

برای سایت‌های واقعی این همان جهش بزرگ بود — بازی شعبده با شش اتصال ناپدید شد و صفحه‌هایی با منابع کوچکِ فراوان به‌طرز چشمگیری سریع‌تر شدند. این همان پروتکلی است که بیشتر وب، و بیشتر CDN‌ها، امروز سرو می‌کنند. یک پانوشت صادقانه: HTTP/2 مشکل head-of-line را به‌جای حذف، یک لایه پایین‌تر برد. همه‌ی آن استریم‌های موازی همچنان سوار یک اتصال TCP‌اند، و TCP اصرار دارد بایت‌ها را به‌ترتیب تحویل بدهد — پس یک بسته‌ی گم‌شده، *همه‌ی* استریم‌ها را تا زمان ارسال مجدد متوقف می‌کند. روی شبکه‌های تمیز این اتفاق نادر است؛ روی سیگنال موبایل ضعیف، مالیاتی است که می‌پردازید.

HTTP/3 در زیرِ سطح چه چیزی را عوض می‌کند

HTTP/3 (سال 2022) به همان مالیات باقی‌مانده حمله می‌کند و TCP را با QUIC جایگزین می‌کند؛ ترانسپورتی ساخته‌شده روی UDP که TLS 1.3 در دل آن جا گرفته است. سه چیز واقعاً تغییر می‌کند. handshake‌ها ارزان‌تر می‌شوند: ترانسپورت و رمزنگاری با هم مذاکره می‌شوند، پس یک اتصال جدید به‌جای دو یا سه رفت‌وبرگشت، یکی هزینه دارد — و اتصال دوباره به سروری شناخته‌شده می‌تواند هزینه‌ی صفر داشته باشد. گم‌شدن بسته دیگر مسری نیست: QUIC استریم‌ها را مستقل دنبال می‌کند، پس یک بسته‌ی گم‌شده فقط همان استریمی را متوقف می‌کند که به آن تعلق داشت، نه هر چیز دیگری که در راه است. و اتصال‌ها از تغییر شبکه جان به در می‌برند: جابه‌جایی از Wi-Fi به داده‌ی موبایل، اتصال را مهاجرت می‌دهد نه اینکه بکشد.

به الگو دقت کنید — تک‌تک این بردها درباره‌ی شبکه‌های ناکامل‌اند. HTTP/3 دقیقاً همان‌جا می‌درخشد: لینک‌های با تأخیر بالا، Wi-Fi پراُفت، کاربران موبایل در حرکت، فاصله‌های طولانی تا سرور.

اندازه‌گیری صادقانه: هر گام چقدر می‌ارزد

روی یک اتصال خوب و نزدیک به سرور، برتری HTTP/3 بر HTTP/2 معمولاً یک بهبود کوچکِ تک‌رقمیِ درصدی است — واقعی، قابل‌اندازه‌گیری، و برای انسان نامرئی. روی یک لینک موبایلِ پراُفت در فاصله‌ی زیاد، می‌تواند تفاوتی بزرگ و محسوس باشد. در مقابل، جهش از HTTP/1.1 به HTTP/2 تقریباً برای همه بزرگ بود. اگر ترافیک شما عمدتاً موبایلی یا از راه دور است، HTTP/3 برای تأخیرهای دنباله‌ی توزیع شما مهم است؛ اگر بیشتر دسکتاپ روی شبکه‌های مناسب است، یک صیقل‌کاری است.

در همین حال، چیزهایی که بر زمان بارگذاری حکومت می‌کنند تکان نخورده‌اند: محتوا چقدر نزدیک است (کش لبه)، چقدر سنگین است (تصاویر، فشرده‌سازی)، و چقدرش رندر را مسدود می‌کند. یک صفحه‌ی کش‌شده، فشرده‌شده با Brotli و با تصاویر بهینه روی HTTP/2، هر بار و بدون استثنا از یک صفحه‌ی بهینه‌نشده روی HTTP/3 می‌برد — پروتکل‌ها میلی‌ثانیه‌ها را تعیین می‌کنند، تحویل ثانیه‌ها را. لبه‌ی ما امروز HTTP/2 سرو می‌کند، همان‌جایی که دستاورد تعیین‌کننده‌ی پروتکلی زندگی می‌کند؛ اهرم‌های تحویل روی آن، جایی است که باقی بودجه‌ی سرعت شما خرج می‌شود.

بررسی کنید سایت شما واقعاً با چه پروتکلی حرف می‌زند

نیازی به حدس نیست. در مرورگر، DevTools → Network را باز کنید، ستون Protocol را فعال کنید و بخوانید: h2 یعنی HTTP/2، h3 یعنی HTTP/3. از ترمینال، curl در یک خط جواب می‌دهد. همان‌جا به هدرهای پاسخ برای وضعیت کش هم نگاهی بیندازید — ارتقای پروتکل روی یک رفت‌وبرگشت کش‌نشده تا origin، صیقل‌دادن لایه‌ی اشتباه است.

بازرسی پروتکل توافق‌شده با curl

# which protocol does the server negotiate?
curl -sI --http2 https://www.example.com -o /dev/null -w 'protocol: %{http_version}\n'

# full picture: protocol + timing + cache status
curl -sI https://www.example.com -w 'protocol: %{http_version}  ttfb: %{time_starttransfer}s\n' | grep -i -E 'HTTP/|cache|protocol|ttfb'

یک ترتیب عملیات عاقلانه

با پروتکل مثل یک اهرم روی تخته رفتار کنید، نه خودِ تخته. اول بردهای تعیین‌کننده را بگیرید: از پشت یک کش لبه سرو کنید تا محتوا نزدیک باشد، متن را با Brotli فشرده کنید، تصاویر را در ابعاد واقعی به WebP/AVIF برسانید — این‌ها ثانیه‌ها را جابه‌جا می‌کنند و همه‌ی بازدیدکنندگان سود می‌برند. multiplexing در HTTP/2 حداقلِ استاندارد است و همین حالا درخواست‌های شما را موازی حمل می‌کند. سپس، اگر داده‌های میدانی شما نشان می‌دهد دردتان تأخیرهای دنباله‌ی موبایلی است، صیقل‌کاری‌های پروتکلی ارزش توجه دارند — سنجیده در برابر اعداد خودتان، نه بنچمارک یک فروشنده.

حقیقت ناخوشایند بحث‌های پروتکلی این است که سرگرم‌کننده و عمدتاً حل‌شده‌اند، در حالی که وزن تصاویر و نرخ اصابت کش، خسته‌کننده و تعیین‌کننده‌اند. به همان ترتیب بهینه کنید.