امنیت شبکه: شروع با QUIC و HTTP/3

به جنگجویان سایبری آینده خوش آمدید!

برای دهه‌ها، ترافیک HTTP سنتی بر روی TCP، که به آن HTTP/1 و HTTP/2 گفته می‌شود، به عنوان ستون فقرات وب عمل کرده است و ما ابزارهایی برای تجزیه و تحلیل، رهگیری و بهره‌برداری از آن داریم. اما امروزه، HTTP/3 در حال افزایش است و به طور فزاینده‌ای در وب مورد استفاده قرار می‌گیرد. در سال 2022، حدود 22% از تمام وب‌سایت‌ها از HTTP/3 استفاده می‌کردند؛ در سال 2025، این عدد به تقریباً 40% افزایش یافته است. و به عنوان جنگجویان سایبری، ما باید از این تغییرات جلوتر باشیم.

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

HTTP/3 چیست؟

HTTP/3 جدیدترین تکامل از پروتکل انتقال ابرمتن (Hypertext Transfer Protocol) است — سیستمی که به مرورگرها، برنامه‌ها و API‌ها اجازه می‌دهد داده‌ها را در اینترنت منتقل کنند. چیزی که آن را متمایز می‌کند، ترک کردن TCP است، پروتکل انتقال قدیمی که از اولین روزهای وب، موتور آن بوده است.

TCP (پروتکل کنترل انتقال) قابل اعتماد است اما انعطاف‌پذیری کمی دارد. این پروتکل برای دقت ساخته شده است، نه سرعت، به گونه‌ای که اطمینان حاصل می‌شود که همه داده‌ها به‌طور صحیح می‌رسند، حتی اگر این باعث کندی اتصال شود. هر جلسه نیاز به یک دست دادن چند مرحله‌ای دارد و اگر یک بسته تاخیر پیدا کند، همه بسته‌ها باید منتظر بمانند. این ممکن بود برای ایمیل قابل قبول باشد، اما برای ترافیک وب مدرن مناسب نیست.

برای غلبه بر این محدودیت‌ها، HTTP/3 از QUIC (اتصالات سریع UDP اینترنت) استفاده می‌کند، یک پروتکل انتقال ساخته شده بر روی UDP که برای اینترنت سریع، موبایلی و حساس به تأخیر طراحی شده است. QUIC تأخیر دست دادن را کاهش می‌دهد، از انسداد سرصفحه جلوگیری می‌کند و تقریباً تمام ارتباطات را به‌طور پیش‌فرض رمزنگاری می‌کند — از همان ابتدا.

پس از سال‌ها توسعه، IETF (سازمان مهندسی اینترنت) در سال 2022 HTTP/3 را به‌طور رسمی استاندارد کرد. امروزه این پروتکل در مرورگرهای اصلی، پلتفرم‌های ابری و تعداد فزاینده‌ای از سرورهای وب به‌طور گسترده پیاده‌سازی شده است.

QUIC چیست؟

ترافیک وب سنتی یک الگوی قابل پیش‌بینی دنبال می‌کند. یک کلاینت یک دست دادن سه‌مرحله‌ای TCP را آغاز می‌کند، سپس یک دست دادن TLS را بر روی آن ارتباط انجام می‌دهد و در نهایت درخواست‌های HTTP را ارسال می‌کند. QUIC این فرایند را به یک دست دادن واحد کاهش می‌دهد که شامل توافق حمل و نقل و رمزنگاری است. اولین بار که یک کلاینت به سرور متصل می‌شود، می‌تواند یک اتصال امن را تنها در یک گردش زمان (round trip) برقرار کند. در اتصالات بعدی، QUIC می‌تواند با استفاده از شناسایی ارتباطات، بازگشت زمان صفر (zero round-trip time) را انجام دهد، به این معنی که کلاینت می‌تواند داده‌های رمزنگاری‌شده را در همان بسته اول ارسال کند.

این پروتکل تقریباً تمام چیزها را رمزنگاری می‌کند به جز یک شناسه حداقلی برای اتصال. برخلاف TLS بر روی TCP که در آن می‌توان هدرهای TCP، شماره‌های توالی و تاییدیه‌ها را در متن‌خوانا مشاهده کرد، QUIC شماره‌های بسته، تاییدیه‌ها و حتی فریم‌های بسته شدن اتصال را رمزنگاری می‌کند. این رویکرد رمزنگاری پیش‌فرض به‌طور قابل توجهی متاداده موجود برای تجزیه و تحلیل ترافیک را کاهش می‌دهد.

QUIC همچنین قابلیت مهاجرت اتصال را پیاده‌سازی می‌کند، که به اتصال اجازه می‌دهد از تغییرات شبکه بگذرد. اگر کاربر از WiFi به سیگنال سلولی سوئیچ کند یا آدرس IP او به دلیل تجدید DHCP تغییر کند، اتصال QUIC با استفاده از شناسه‌های ارتباطی باقی می‌ماند و دیگر نیازی به استفاده از چهار تایی از آدرس IP مبدا، پورت مبدا، آدرس IP مقصد و پورت مقصد نیست.

دست دادن (Handshake) در QUIC

فرایند زمانی آغاز می‌شود که کلاینت بسته اولیه (Initial packet) خود را ارسال می‌کند. این پیام اول شامل نسخه‌های QUIC پشتیبانی‌شده توسط کلاینت، مجموعه‌های رمزنگاری موجود، یک عدد تصادفی تازه تولید شده و شناسه اتصال است — یک شناسه تصادفی که حتی اگر آدرس IP کلاینت تغییر کند، ثابت باقی می‌ماند. داخل این بسته اولیه، کلاینت پیامی از نوع TLS 1.3 (ClientHello) را به همراه پارامترهای حمل و نقل QUIC و مواد رمزنگاری اولیه لازم برای آغاز مذاکره کلید قرار می‌دهد. اگر کلاینت قبلاً به سرور متصل شده باشد، ممکن است حتی داده‌های زودهنگام برنامه مانند یک درخواست HTTP را به‌منظور ذخیره کردن یک گردش زمان اضافی در بسته گنجانده باشد.

سپس سرور با مجموعه‌ای از اطلاعات خود پاسخ می‌دهد. یکی از نسخه‌های QUIC و مجموعه‌های رمزنگاری کلاینت را انتخاب کرده، یک عدد تصادفی خود را فراهم می‌کند و شناسه اتصال سمت سرور را به همراه پارامترهای حمل و نقل QUIC ارسال می‌کند. داخل این پاسخ، TLS 1.3 ServerHello قرار دارد که مواد رمزنگاری لازم برای استخراج کلیدهای مشترک را شامل می‌شود. سرور همچنین زنجیره گواهی کامل خود را ارسال می‌کند — گواهی سرور به همراه مراجع گواهی میان‌راه (Intermediate Certificate Authorities) که آن را امضا کرده‌اند — و ممکن است داده‌های HTTP زودهنگام را ارسال کند.

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

از این لحظه به بعد، تمام ترافیک بین کلاینت و سرور با استفاده از کلیدهای جلسه ایجاد شده رمزنگاری می‌شود. برخلاف مدل سنتی TCP که با TLS ترکیب می‌شود، QUIC نیازی به فاز جداگانه‌ای برای دست دادن (TLS handshake) ندارد. در عوض، TLS به‌طور مستقیم در داخل دست دادن QUIC ادغام شده است، که به پروتکل این امکان را می‌دهد که سفرهای زمان اضافی را حذف کند. یکی از مزایای عمده این طراحی این است که هم سرور و هم کلاینت می‌توانند داده‌های واقعی برنامه — مانند درخواست‌ها و پاسخ‌های HTTP — را در داخل خود دست دادن گنجانده و ارسال کنند. در نتیجه، اعتبارسنجی گواهی و برقراری اتصال به‌طور همزمان با تبادل اولیه داده‌های واقعی انجام می‌شود، که باعث می‌شود QUIC سریع‌تر و کارآمدتر از مدل قدیمی TCP+TLS باشد.

چگونه شبکه QUIC کار می‌کند؟

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

آناتومی یک جریان QUIC

یک دیتاگرام UDP به عنوان محفظه حمل و نقل خارجی عمل می‌کند. این دیتاگرام حاوی یک هدر با اطلاعات مربوط به پورت‌های مبدا و مقصد، همراه با اطلاعات طول و بررسی صحت (checksum)، است و یک یا چند بسته QUIC را حمل می‌کند. این واحد اصلی است که بین کلاینت و سرور در شبکه منتقل می‌شود.

یک بسته QUIC واحدی است که درون یک دیتاگرام UDP قرار دارد و هر دیتاگرام ممکن است یک یا چند بسته QUIC داشته باشد. هر بسته QUIC شامل یک هدر QUIC به همراه یک یا چند فریم QUIC است.

هدر QUIC حاوی متاداده‌ای در مورد بسته است و در دو فرمت مختلف وجود دارد. هدر بلند (long header) در زمان راه‌اندازی اتصال استفاده می‌شود، در حالی که هدر کوتاه (short header) پس از برقراری اتصال به کار می‌رود. هدر کوتاه شامل شناسه اتصال، شماره بسته و مرحله کلید است که نشان‌دهنده کلیدهای رمزنگاری در حال استفاده است و از چرخش کلید پشتیبانی می‌کند. شماره‌های بسته به طور مداوم برای هر اتصال و مرحله کلید افزایش می‌یابند.

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

یک جریان یک کانال داده یک‌طرفه یا دوطرفه درون یک اتصال QUIC است. هر اتصال QUIC می‌تواند از چندین جریان مستقل پشتیبانی کند که هر کدام توسط شناسه منحصر به فرد خود شناسایی می‌شود. اگر یک بسته QUIC گم شود، تنها جریان‌های حمل‌شده در آن بسته تحت تأثیر قرار می‌گیرند، در حالی که تمام دیگر جریان‌ها بدون وقفه ادامه خواهند داشت. این استقلال است که باعث می‌شود انسداد سرصفحه (head-of-line blocking) که در HTTP/2 مشاهده می‌شود، در QUIC از بین برود. جریان‌ها می‌توانند توسط هر نقطه انتهایی ایجاد شوند و می‌توانند در هر دو جهت عمل کنند.

HTTP/3 در مقایسه با HTTP/2 و HTTP/1: چه تغییراتی به‌وجود آمده است؟

برای درک اهمیت HTTP/3، ابتدا لازم است محدودیت‌های نسخه‌های قبلی آن را در نظر بگیریم.

HTTP/1.1، پروتکلی اصلی که هنوز توسط میلیون‌ها وب‌سایت استفاده می‌شود، تنها یک درخواست را در هر اتصال TCP پردازش می‌کند. این باعث می‌شود که مرورگرها مجبور شوند برای بارگذاری یک صفحه واحد، اتصالات زیادی باز و بسته کنند که منجر به بی‌کارآمدی، عملکرد پایین‌تر و حساسیت زیاد به مشکلات شبکه می‌شود.

HTTP/2 بهبودهای عمده‌ای را معرفی کرد، از جمله مولتی‌پلکسیگ (multiplexing)، که به درخواست‌های متعدد اجازه می‌دهد تا یک اتصال TCP واحد را به اشتراک بگذارند، همچنین فشرده‌سازی هدرها و ارسال اطلاعات توسط سرور (server push). این تغییرات افزایش‌های قابل توجهی به همراه داشت، اما پروتکل هنوز به TCP وابسته است، که یک محدودیت اساسی دارد: اگر یک بسته به تأخیر بیفتد، تمام مسیر اتصال متوقف می‌شود. این پدیده که به آن انسداد سرصفحه (head-of-line blocking) گفته می‌شود، در HTTP/2 قابل اجتناب نیست.

 HTTP/3 این محدودیت را با جایگزین کردن TCP با یک لایه حمل و نقل پیشرفته‌تر حل می‌کند. ساخته شده بر پایه QUIC، HTTP/3 جلسات رمزنگاری شده را سریع‌تر برقرار می‌کند، که معمولاً تنها نیاز به یک گردش زمان (round-trip) به جای سه یا بیشتر دارد. این پروتکل انسداد سرصفحه (head-of-line blocking) را با دادن کنترل جریان مستقل به هر جریان، از بین می‌برد، به این معنی که سایر جریان‌ها حتی اگر یک بسته از دست برود، همچنان ادامه می‌دهند. HTTP/3 می‌تواند جلسات را از طریق تغییرات IP یا شبکه حفظ کند، از دست دادن بسته‌ها را به طور نرم‌تری بازیابی کند و حتی از کنترل ترافیک سفارشی برای سازگاری با حجم‌های مختلف کاری پشتیبانی کند.

به طور خلاصه، HTTP/3 تنها نسخه‌ای بهبودیافته از HTTP/2 نیست. بلکه یک پروتکل کاملاً بازطراحی شده است که برای غلبه بر محدودیت‌های نسل‌های قبلی ایجاد شده است، به ویژه برای کاربران موبایل، برنامه‌های حساس به تأخیر و ترافیک توزیع‌شده در سطح جهانی.

شروع کار با HTTP/3

نسخه‌های مدرن curl (7.66.0 و نسخه‌های جدیدتر با پشتیبانی از HTTP/3) می‌توانند آزمایش کنند که آیا یک سرور از QUIC و HTTP/3 پشتیبانی می‌کند یا نه. در اینجا نحوه بررسی یک سرور آمده است:

kali> curl –http3 -I https://www.example.com

این دستور تلاش می‌کند که با استفاده از HTTP/3 بر روی QUIC متصل شود، اما اگر QUIC پشتیبانی نشود، به HTTP/2 یا HTTP/1.1 بازمی‌گردد.

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

برای شروع، Wireshark را باز کنید و به وب‌سایتی که از QUIC پشتیبانی می‌کند مراجعه کنید. Cloudflare مثال خوبی است زیرا به طور گسترده‌ای HTTP/3 و پروتکل QUIC را پیاده‌سازی کرده است. QUIC معمولاً بر روی پورت UDP 443 اجرا می‌شود، بنابراین ساده‌ترین فیلتر برای تأیید این که ترافیک QUIC را مشاهده می‌کنید، به شرح زیر است:

udp.port == 443

این فیلتر تمام ترافیک UDP روی پورت 443 را نشان می‌دهد، که تقریباً همیشه با QUIC در وب‌سایت‌های مدرن مرتبط است.

QUIC در مراحل مختلف اتصال از انواع بسته‌های مختلف استفاده می‌کند. حتی اگر محتوا رمزنگاری شده باشد، Wireshark همچنان می‌تواند این انواع بسته‌ها را شناسایی کند.

برای نمایش فقط بسته‌های Initial، که اولین بسته‌هایی هستند که هنگام شروع یک اتصال QUIC توسط کلاینت تبادل می‌شوند، از دستور زیر استفاده کنید:

quic.long.packet_type == 0

بسته‌های Initial بخشی از مرحله دست دادن (handshake) QUIC هستند. این بسته‌ها تا حدی شبیه به پیام‌های “ClientHello” و “ServerHello” در TLS هستند، با این استثناء کهQUIC  دست دادن را در خود پروتکل تعبیه کرده است.

اگر می‌خواهید بسته‌های Handshake را مشاهده کنید، که پس از بسته‌های Initial ادامه می‌دهند و دست دادن رمزنگاری را تکمیل می‌کنند، از دستور زیر استفاده کنید:

quic.long.packet_type == 2

این بسته‌ها کمک می‌کنند تا اتصال امن تکمیل شود قبل از اینکه QUIC به بسته‌های رمزنگاری‌شده "هدر کوتاه" برای داده‌های معمولی (مانند درخواست‌ها و پاسخ‌های HTTP/3) تغییر وضعیت دهد.

همچنین، QUIC نسخه‌های مختلفی دارد و سرورها اغلب از بیش از یک نسخه پشتیبانی می‌کنند. برای مشاهده بسته‌هایی که از نسخه خاصی استفاده می‌کنند، دستور زیر را امتحان کنید:

quic.version == 0x00000001

این دستور به نسخه 1 از QUIC اشاره دارد، که در RFC 9000 استاندارد شده است. با بررسی اینکه کدام نسخه از QUIC در ترافیک مشاهده می‌شود، می‌توانید متوجه شوید که سرور از کدام نسخه پشتیبانی می‌کند و آیا از نسخه استاندارد یا نسخه‌های پیش‌نویس قدیمی‌تر استفاده می‌کند.

خلاصه

QUIC تنها یک به‌روزرسانی تدریجی نیست — بلکه یک بازآفرینی کامل از نحوه عملکرد ارتباطات اینترنتی مدرن است. در حالی که پشته سنتی TCP + TLS + HTTP/2 برای سال‌ها به خوبی از ما حمایت کرده است، هیچ‌گاه برای واقعیت‌های اینترنت امروزی طراحی نشده بود: تأخیرهای جهانی، تغییرات مداوم در ارتباطات موبایلی، و نیاز رو به رشد به عملکرد بالا و امنیت قوی. QUIC از ابتدا ساخته شده است تا این چالش‌ها را برطرف کند، و آن را سریع‌تر، مقاوم‌تر و امن‌تر برای وب مدرن می‌سازد.

ادامه دهید به بازگشت، جنگجویان سایبری آینده‌نگر، همان‌طور که ما به کاوش در مورد چگونگی بازنویسی پروتکل‌های اساسی اینترنت ادامه می‌دهیم.

منبع

https://hackers-arise.com/network-security-get-started-with-quic-and-http-3/