پروتکل HTTP/3 چیست و چگونه در CDN آروان‌کلاد پیاده‌سازی شده است؟

داستان پروتکل HTTP/3 از دغدغه‌ی گروهی از مهندسان خلاق در سراسر جهان آغاز می‌شود که از محدودیت‌های HTTP/2 نا امید شده بودند. آن‌ها در جست‌وجوی راهی برای غلبه بر چالش‌های سرعت، امنیت و قابلیت اطمینان بودند.

پس از سال‌ها تلاش و آزمایش، به معجزه‌ای به‌نام QUIC دست یافتند. QUIC کوتاه‌شده‌ی عبارت «Quick UDP Internet Connections» و یک پروتکل انتقال داده است که بر روی UDP ساخته شده بود. با استفاده از QUIC ،HTTP/3 می‌توانست اتصال‌ها را به‌شکل موازی برقرار کند و میزان تاخیر را کاهش دهد و از ازدحام شبکه بکاهد. به‌طور خلاصه، این پروتکل، دنیای وب را به سطح جدیدی از کارایی رساند.

اما چالش‌ها به همین جا ختم نشد. ادغام QUIC با HTTP، مستلزم همکاری بی‌سابقه‌ای بین ذی‌نفعان مختلف در صنعت فناوری بود. غول‌های فناوری مانند گوگل، مایکروسافت و موزیلا باید با یکدیگر و با جامعه گسترده‌تر توسعه‌دهندگان وب همکاری می‌کردند.

پس از ماه‌ها بحث و مذاکره، سرانجام در سال ۲۰۲۲، HTTP/3 به‌عنوان یک استاندارد رسمی پذیرفته شد. این یک نقطه‌ی عطف تاریخی بود که مسیر آینده وب را تغییر داد.

امروزه، HTTP/3 به‌طور گسترده در سراسر جهان استفاده می‌شود و به وب‌گردها تجربه‌ای سریع‌تر، امن‌تر و قابل اعتمادتر ارایه می‌دهد. ناگفته نماند که HTTP/3 هم‌چنان در حال تکامل است و پتانسیل آن برای متحول کردن نحوه‌ی تعامل ما با دنیای دیجیتال ادامه داد.

در حال حاضر آروان‌کلاد هم‌گام استانداردهای جهانی با هدف تامین امنیت و سرعت بیش‌تر محصول CDN خود، سعی کرده چالش‌های پیاده‌سازی HTTP/3 را برطرف کند و سرویسی به‌روز و قابل اعتماد را ارایه دهد. در ادامه پروتکل HTTP/3 و چالش‌های فنی پیاده‌سازی آن را شرح می‌دهیم. اما بیایید قبل از هر چیز به مفهوم کلی HTTP بپردازیم و ببینیم چیست و از کجا آمده است؟

پروتکل HTTP چیست؟

HTTP کوتاه‌شده‌ی عبارت Hypertext Transfer Protocol و یک پروتکل انتقال ابرمتن یا فرامتن است. این پروتکل پایه و اساس تبادل اطلاعات در وب جهانی را برعهده دارد و نحوه‌ی تعامل مرورگرها با سرورها را برای نمایش صفحه‌های وب، تصاویر و سایر محتوای آنلاین دیکته می‌کند. در ادامه فرآیند کار HTTP را توضیح می‌دهیم.

• ارسال درخواست از مرورگر به سرور: هنگامی که آدرسی را می‌نویسید یا روی لینکی کلیک می‌کنید، مرورگر شما از طریق HTTP  درخواستی به سرور موردنظرتان ارسال می‌کند. این درخواست شامل اطلاعاتی مانند آدرس وب‌سایت، نوع مرورگر و روش درخواست مانند GET یا POST است.
• دریافت پاسخ از سرور به مرورگر: سرور پس از دریافت درخواست، محتوا را بازیابی کرده و در قالب یک پاسخ  HTTP به مرورگر شما ارسال می‌کند. این پاسخ شامل کد وضعیت، نوع محتوا مانند HTML یا تصویر و خود محتوای درخواستی می‌شود.
• نمایش محتوای وب: مرورگر شما محتوای دریافتی از سرور را تفسیر و به‌شکل قابل مشاهده در صفحه‌ی نمایش می‌دهد. این مرحله شامل رندر کردن کد HTML، نمایش تصاویر و اجرای اسکریپت‌ها می‌شود.

حال که با مفهوم HTTP آشنا شدیم بهتر است نسخه‌های مختلف آن را بشناسیم و ببینیم چه مسیری را تا رسیدن به پروتکل HTTP/3 سپری کرده است:

پروتکل HTTP/1

نسخه‌ی اولیه‌ی HTTP/1.0 ،HTTP بود که در اوایل دهه‌ی ۱۹۹۰ میلادی معرفی شد. با گسترش وب و افزایش پیچیدگی صفحه‌های آن، نیاز به پروتکلی کارآمدتر احساس شد. به همین دلیل، نسخه‌های جدیدتر HTTP مانند HTTP 1.1 و HTTP/2 توسعه یافتند.

در HTTP/1.1 انتقال اطلاعات در قالبی که ساختار آن توسط Whitespace کنترل می‌شود؛ انجام می‌گرفت. توجه کنید که به دلیل ماهیت متنی، اطلاعات در میانه‌ی مسیر نیز قابل خواندن بود؛ که همین امر کمک بزرگی به عیب‌یابی‌ها می‌کرد. اما از طرفی، کار استخراج اطلاعات در مقصد و نوشتن Parser را دشوار کرده بود. پروتکل در این نسخه فاقد مکانیزمی اتکاپذیر برای انتقال چند درخواست هم‌زمان و پردازش پاسخ‌های غیرهم‌زمان بود. از این‌رو، وظیفه‌ی پردازش درخواست‌های موازی به لایه‌ی Transport واگذار شد و عمومن به‌شکل ساخت Connectionهای متعدد در لایه‌ی TCP انجام می‌شد.

پروتکل HTTP/2

HTTP/2 در سال ۲۰۱۵ با هدف کاهش زمان بارگذاری صفحه و بهبود تجربه‌ی کاربری طراحی و منتشر شد. این پروتکل از چندین اتصال موازی برای ارسال هم‌زمان داده‌ها استفاده می‌کند و سرعت انتقال اطلاعات را به‌طور قابل توجهی افزایش می‌دهد.

نسخه‌ی HTTP/2 و معرفی Binary Framing و Multiplexing Layer تلاشی برای برطرف کردن نواقص نسخه‌ی پیشین بود. در HTTP/2 اطلاعات و به‌طور خاص هدرها، در قالبی باینری و در حجمی بهینه‌تر به سوی مقصد ارسال می‌شوند. با پیاده‌سازی Multiplexing و معرفی Stream در لایه‌ی Application، امکان پردازش هم‌زمان چند درخواست و پاسخ‌های آن‌ها بدون نیاز به ایجاد Connectionهای جدید فراهم شد.

تداوم استفاده از TCP به‌عنوان لایه‌ی Transport در HTTP/2 باعث شد تا در کنار معماری کاملن تازه و تا حدی پیچیده در لایه‌ی Application، برخی مشکلات پروتکل هم‌چنان دست‌نخورده باقی ‌بمانند. از مهم‌ترین مشکلات این پروتکل، آسیب‌پذیری نسبت به اختلالات و اشباع در لایه‌ی دسترسی یا Access و شبکه است. از دست رفتن پکت یا Packet loss در TCP منجر به مسدود شدن پردازش تمامی پکت‌های بعدی تا زمان رسیدن پکت از دست رفته می‌شود. 

امروزه با گسترش موبایل‌ها و دیگر ابزارهای قابل حمل  که به‌طور مستمر به اینترنت دسترسی دارند، جابه‌جایی بین زیرشبکه‌ها و تغییر آدرس IP کاربران (هنگام اتصال به اینترنت) موضوعی عادی و پرتکرار شده است. 

از آن‌جایی‌که در ارتباط با پکت‌های TCP، عمومن مکانیسم توزیع بار در ابزارهای میانی در شبکه و سیستم‌عامل‌ها، بر اساس IP و پورت مبدا و مقصد شکل می‌گیرد. در هر بار تغییر آدرس IP به واسطه‌ی حرکت و جابه‌جایی بین آنتن‌های BTS به دلیل حضور در خودرو و یا موارد مشابه، این احتمال وجود دارد که Connection مبتنی‌بر TCP به‌طور کلی از دست رفته و ایجاد Connection جدید ضروری شود. 

مسدود شدن پردازش پکت‌های بعدی و ایجاد Connection جدید در هر جابه‌جایی بین زیرشبکه‌‌ها، هر دو، عامل تاخیرهای جزیی و در پی آن عامل کاهش کیفیت ارتباط بین کاربران و سرویس‌دهنده خواهند‌ بود.

برای حل این مشکلات مهندسان چه راهکاری پیش‌رو داشتند؟ آن‌ها بعد از سال‌ها تلاش به این نتیجه رسیدند که باید پروتکل TCP را کنار بگذارند و با پروتکل QUIC که مبتنی‌بر UDP است، روش جدیدی را پیش بگیرید، این‌جا بود که HTTP/3 متولد شد.

پروتکل HTTP/3 چیست؟

HTTP/3، سومین نسخه از پروتکل انتقال ابرمتن (HTTP) است که پیش‌تر به‌عنوان HTTP-over-QUIC شناخته می‌شد. QUIC (اتصالات سریع اینترنت UDP) که در ابتدا توسط گوگل توسعه یافت، جانشین HTTP/2 است. شرکت‌هایی مانند گوگل و فیس‌بوک برای افزایش سرعت وب از QUIC استفاده می‌کنند.

گفتیم HTTP زبانی است که مرورگرهای وب و سرورها برای برقراری ارتباط با یکدیگر از آن استفاده می‌کنند. HTTP/3 جدیدترین نسخه‌ی این زبان است و مانند یک روش جدید و پیشرفته این فرآیند را پیش می‌برد.

اگرچه HTTP/3 هنوز به‌نسبت جدید است، اما در حال حاضر توسط برخی از شرکت‌های بزرگ استفاده و از سوی بیش‌تر مرورگرهای وب مدرن پشتیبانی می‌شود.

کاربردهای پروتکل HTTP/3

HTTP/3 هنوز به‌طور گسترده مورد استفاده قرار نگرفته یا به اصطلاح رایج Adopted نشده است، اما پشتیبانی از آن به سرعت در حال افزایش است. مرورگرهای محبوب مانند Chrome ،Firefox و Edge از آن پشتیبانی می‌کنند و هر روز سرورهای بیش‌تری به استقبال آن می‌روند.

از مهم‌ترین کاربردهای HTTP/3 می توان به موارد زیر اشاره کرد:

• وب‌گردی: HTTP/3 می‌تواند سرعت بارگذاری صفحه را به‌طور قابل توجهی [به‌ویژه برای وب‌سایت‌های با تصاویر و ویدیو زیاد] کاهش دهد.
• Streaming ویدیو: HTTP/3 می‌تواند Streaming ویدیو را با ثبات‌تر و با کیفیت بالاتر، [به‌ویژه در شبکه‌های Congested] ارایه دهد.
• بازی‌های آنلاین: HTTP/3 می‌تواند تاخیر را در بازی‌های آنلاین کاهش دهد و تجربه کاربری را بهتری را ارایه کند.
• اپلیکیشن‌های موبایل: HTTP/3 می‌تواند مصرف داده را در اپلیکیشن‌های موبایلی کاهش دهد، این مورد برای کاربرانی که با برنامه‌هایی با دیتای محدود دارند؛ مهم و مفید است.

پروتکل HTTP/3 چگونه کار می کند؟

برای بهبود سرعت و رفع مشکلات نسخه‌های قبلی، در نسخه 3 پروتکل HTTP ،Multiplexing و Flow Control به‌طور مستقیم در QUIC پیاده‌سازی شده‌اند، در نتیجه‌ی آن از پیچیدگی معماری لایه‌ی Application کاسته‌ شد. بنابراین از دست رفتن یک پکت به دلیل مشکلات شبکه تنها باعث مسدود شدن پردازش پکت‌های آن Streamای که شامل پکت مفقود شده‌ است؛ می‌شود و مانعی برای پردازش سایر استریم‌های موازی، که حامل درخواست‌های موازی و پاسخ‌های آن‌ها هستند، نخواهد‌ بود.

به‌علاوه برای ایجاد هر کانکشن جدید، TCP نیازمند فرآیند رفت و برگشتی اطلاعات است که 3Way Handshake  نامیده می‌شود. با حذف این فرآیند در QUIC، ارتباط جدید را سریع‌تر از TCP ایجاد می کند. این موضوع اثر نامطلوب جابه‌جایی بین زیرشبکه‌های مخابراتی و نیاز به ایجاد Connection تازه در فواصل زمانی کوتاه را برای کاربران کاهش می‌دهد.

رمزنگاری اطلاعات در نسخه‌های پیشین HTTP به‌عنوان گزینه‌ای انتخابی و خارج از پروتکل تعریف شده بود. اگرچه در بیش‌تر پیاده‌سازی‌ها و وب‌سرورها، پروتکل HTTP/2 به‌همراه TLS کاربردی است، اما اجباری برای این کار وجود ندارد. در مقابل، در HTTP/3 رمزنگاری و ارتباط امن، بخشی از پیاده‌سازی QUIC به‌عنوان بستر کانکشن تعیین شده‌ است. با ضروری انگاشتن پشتیبانی از بازیابی سریع Sessionها (0RTT Resumption) تاخیر در راه‌اندازی دوباره ارتباط، بعد از جابه‌جایی بین زیرشبکه‌ها یا قطع ارتباط به‌دلیل اختلال یا اشباع، به کم‌ترین میزان ممکن رسیده که تجربه‌ی کاربران از حضور در اینترنت را به‌شکل چشم‌گیری بهبود می‌دهد.

مزایای آخرین نسخه HTTP

مزیت‌های HTTP/3 Over QUIC به‌نسبت پروتکل‌های پیشین در زیر به‌شکل دسته‌بندی شده آمده است:

• سرعت بالاتر در ایجاد ارتباط تازه (Faster Connection Establishment): پروتکل QUIC اجازه می‌دهد تا فرایند توافق میان کلاینت و سرور برای استفاده از ورژن TLS هم‌زمان با رمزنگاری و Handshake انجام شود. در واقع با یکپارچه‌سازی برقراری اتصال (Connection Establishment)  و هم‌چنین TLS Handshake سرعت اتصال را بسیار افزایش می‌دهد.

• قابلیت Zero Round-Trip Time یا (0-RTT): زمانی که بازدیدکننده به یک سرور از قبل متصل بوده باشد، می‌تواند از مراحل مربوط به Handshake برای اتصال دوباره صرف‌نظر کند. پروتکل جدید به دلیل وجود TLS 1.3 علاوه‌بر مزایای زیادی که در استفاده از UDP به‌جای TCP به‌وجود می‌آورد، مزیت دیگری هم در لایه ی رمزنگاری ایجاد می‌کند. برای آشنا شدن با این مزیت تازه ابتدا لازم است نگاهی به فرآیند TLS Handshake در نسخه‌های قبلی بیندازیم. در نسخه‌های پیشین فرآیند TLS Handshake به‌شکل زیر بود:

که در نسخه‌ی جدید با حذف مراحل برقراری اتصال TCP و هم‌چنین ترکیب برقراری اتصال TLS و QUIC به‌شکل زیر تغییر کرد:

همان‌طور که مشخص است، در ارتباط HTTP/3 با کاهش تعداد مراحل مورد نیاز برای برقراری ارتباط، سرعت بالاتری را در ایجاد ارتباط اولیه فراهم می‌کند. هم‌چنین به‌دلیل کاهش سربار TCP در مقایسه با UDP سرعت ارسال و دریافت پیام‌های HTTP نیز بهبود می‌یابد.

• رمزنگاری ضروری: نگرش پروتکل QUIC به فرآیند Handshake امکان رمزنگاری را به‌شکل پیش‌فرض (یک به‌روزرسانی عمده در مقایسه با  HTTP/2) فراهم می‌کند و می‌تواند ریسک حمله‌ها را کاهش دهد.

تفاوت‌های پروتکل‌های HTTP/2 و HTTP/3

گفتیم که HTTP/3 روی پروتکل جدید QUIC بنا شده است و بنابراین سریع‌تر از HTTP/2 است، چراکه تاخیر را کاهش و کارایی را افزایش می‌دهد. این امر به‌ویژه برای وب‌سایت‌هایی که محتوای سنگین و حجیمی مانند تصاویر، ویدیوها و … دارند، مفید است.

علاوه‌بر سرعت، HTTP/3 اتصالات قابل اعتمادی را ارایه می‌دهد که کم‌تر در برابر از دست رفتن بسته‌ها و نوسانات شبکه آسیب‌پذیر هستند. این امر برای برنامه‌های کاربردی وب که عملکرد  Real Time دارند، [مانند چت‌های ویدیویی و بازی‌های آنلاین] حایز اهمیت است.

از نظر امنیتی، HTTP/3 به‌طور پیش‌فرض از TLS 1.3 برای رمزگذاری کامل ترافیک وب استفاده می‌کند که به‌روزترین نسخه پروتکل TLS است.

در مقابل، HTTP/2  که از TCP در لایه‌ی Transport استفاده می‌کند، پروتکل قدرتمند و مطمینی است که برای بیش‌تر برنامه‌ها کافی خواهد بود.

انتخاب بین HTTP/2 و HTTP/3 به نیازهای شما بستگی دارد. اگر به‌دنبال بهترین عملکرد و امنیت ممکن هستید، HTTP/3 می‌تواند انتخاب بهتری باشد. با این‌حال، HTTP/2 هنوز یک پروتکل قابل اعتماد است و برای بیش‌تر وب‌سایت‌ها و برنامه‌های کاربردی وب، عملکردی مناسب ارایه می‌دهد. در زیر تفاوت این دو پروتکل را در جدولی مشاهده خواهید کرد:

چالش‌های پیاده‌سازی پروتکل HTTP/3 در شبکه توزیع محتوا آروان‌کلاد

تا پیش از HTTP/3 فرآیند رمزنگاری به‌شکل یک لایه‌ای بود که به نسخه‌های پیشین به‌منظور رفع دغدغه‌های امنیتی اضافه شده بود، اما پروتکل HTTP/3 با یکپارچه‌سازی فرآیند رمزنگاری با خود پروتکل ارتباطی، ارتباط سریع‌تر و امن‌تری را در مقایسه با نسخه‌های قبلی فراهم می‌کند.

این یکپارچه‌سازی به تغییرات در پروتکل رمزنگاری نیاز دارد. چراکه برخی از کتابخانه‌های پراستفاده‌ی رمزنگاری (OpenSSL) هنوز آن را به‌طور کامل پشتیبانی نمی‌کنند.

برای مثال، کتابخانه OpenSSL به‌شکل گسترده برای ایجاد ارتباط امن و انجام رمزنگاری TLS در دنیای IT استفاده می‌شود، اما پشتیبانی مناسبی از نیازمندی‌های مورد نیاز HTTP/3 در آن وجود ندارد.

شاید تغییر دادن کتابخانه‌ی SSL در میانه‌ی افزودن پشتیبانی از HTTP/3 به شبکه توزیع محتوا آروان‌کلاد کار معقولی به نظر نرسد، اما محدودیت‌های مهمی در ارتباط با OpenSSL برای دست‌یابی به HTTP/3 وجود دارد. 

با وجود گستردگی استفاده از OpenSSL به‌عنوان کتابخانه‌ی پیش‌فرض رمزنگاری در بیش‌تر ابزارهای وب، OpenSSL پشتیبانی مناسبی از TLS APIهای مورد نیاز برای QUIC را ندارد. به همین دلیل، کمیته‌ی مرکزی توسعه‌ی OpenSSL تصمیم گرفت تا یک Stack کامل QUIC را به‌شکل مستقل پیاده کند. یعنی به‌جای این‌که APIهای رمزنگاری را به تنهایی توسعه دهند، پیاده‌سازی QUIC را به کتابخانه‌ی رمزنگاری منتقل کنند.

این استک تازه تمامی عملکردهای مورد نیاز برای پروتکل QUIC را شامل می‌شود. به‌طوری دیگر کسانی که قصد استفاده از HTTP/3 را دارند، لازم نیست نگران پیاده‌سازی عملکردهای اختصاصی آن باشند و قرار است این عملکردها به‌طور کامل در OpenSSL وجود داشته باشد. اما متاسفانه این تلاش‌ها برای پشتیبانی از QUIC در نسخه‌ی 3.4 OpenSSL برنامه‌ریزی شده است، که بر اساس نقشه‌راه توسعه‌ی OpenSSL این اتفاق تا قبل از پایان سال ۲۰۲۴ اتفاق نخواهد افتاد.

بنابراین برای پیاده‌سازی HTTP/3 در CDN آروان‌کلاد یا باید تا پایان سال ۲۰۲۴ صبر کنیم و یا راه‌حل‌های جایگزین مانند کتاب‌خانه‌های BoringSSL ،LibreSSL ،QuicTLS و OpenSSL Compatibility Layer استفاده کنیم.

برتری‌های BoringSSL بر OpenSSL

پس از بررسی و مقایسه‌ی انتخاب‌های پیش‌رو، متوجه می‌شویم که استفاده از BoringSSL در مقایسه با دیگر کتابخانه‌ها گزینه‌ی بهتری به نظر می‌رسد. چراکه کتابخانه‌ی BoringSSL به‌دلیل پشتیبانی توسط گوگل و هم‌چنین انطباق بیش‌تر با سایر سرویس‌ها می‌تواند با کم‌ترین تغییر با سرویس‌های از پیش نوشته‌شده سازگار شود.

برای سازگاری آروان‌کلاد با عملکردهایی مانند قابلیت‌های پردازش Async برای کار در محیط کلاد به‌عنوان لایه‌ی رمزنگاری سرویس CDN نیاز است کتابخانه‌ی رمزنگاری از OpenSSL به BoringSSL تبدیل شود.

چراکه فرآیند پردازش یک درخواست ورودی از سمت کاربر، از لحظه‌ای که از سمت شبکه دریافت‌شده تا زمانی که پاسخ داده می‌شود مراحل مختلفی را پشت سر می‌گذارد. 

بسیاری از این مراحل باید به‌شکل Async انجام شوند تا تداخلی در درخواست‌های دیگر ایجاد نکنند. «پردازش درخواست‌ها به روش Async» چیزی است که برای دستیابی به سرعت بالا، به ماژول‌های پردازشی CDN اضافه شده بود. در حال حاضر و  پس از اضافه شدن این قابلیت و انجام تست‌های تکمیلی، با ترکیب تمامی اجزا، پشتیبانی از HTTP/3 به محصول شبکه توزیع محتوا اضافه شده است. 

جمع‌بندی

پروتکل HTTP/3 لذت رانندگی در یک اتوبان خلوت و بدون ترافیک را برایتان به‌دنبال دارد. با این پروتکل دیگر شاهد سرعت کند بارگذاری صفحه‌های وب نخواهید بود. در این مقاله، به‌شکل کامل HTTP/3 را بررسی کردیم. همین‌طور چالش‌های پیاده‌سازی آن در شبکه توزیع محتوا آروان‌کلاد را شرح دادیم. شما می‌توانید با فعال‌سازی قابلیت HTTP/3 با سرعت و امنیتی بی‌نظیر سرویس‌های آنلاین کسب‌وکارتان را در اختیار کاربران پرشمار خود قرار دهید.

هم‌چنین اگر پرسشی در این زمینه دارید، می‌توانید آن را در بخش نظرها بنویسید تا در سریع‌ترین زمان راهنمایی‌تان کنیم.