آشنایی با پروتکل QUIC

در واقع موضوع "دو پروتکل" با نام یکسان است؛ یعنی:

1) Google QUIC (gQUIC) پروتکلی است که چند سال پیش توسط مهندسین گوگل طراحی شد که در نهایت پس از چند سال توسط IETF وارد مرحله استاندارد سازی شده است.

2) IETF QUIC که به تازگی از gQUIC جدا و تبدیل به یک پروتکل مجزا شده است.

از بسته های ارتباطی قدیمی (فرمت سیمی) تا Handshake و مسیریابی HTTP، پروتکل QUIC با همکاری چندین سازمان و متخصص با هدف افزایش سرعت و امنیت اینترنت طراحی و توسعه داده شد.

ویژگی های QUIC

امنیت Built-in (و عملکرد بهینه)

یکی از تغییرات QUIC نسبت به TCP طراحی پروتکلی است که به صورت پیش فرض دارای تمهیدات امنیتی برای ارتباطات باشد. QUIC توانسته با فراهم سازی ویژگی های امنیتی این مهم را محقق کند؛ نظیر اعتبارسنجی و رمزنگاری از همان لایه انتقال (که در حال حاضر معمولاً توسط یک لایه بالاتر مثل TLS اداره می شود).

Handshake اولیه در QUIC ، حالت Handshake سه طرفه همیشگی که در TCP اتفاق می افتد را با Handshake پروتکل TLS 1.3 ترکیب کرده و اعتبارسنجی Endpoint ها و تبادل پارامترهای رمزنگاری را یکجا فراهم می کند.

موضوع کمی پیچیده است؛ اما برای آنهایی که با پروتکل TLS آشنا هستند، باید بگوییم که QUIC لایه رکورد TLS را با فرمت بندی خاص خود تعویض می کند؛ ولی پیغام های TLS Handshake را نگه می دارد.

این موضوع نه تنها از امنیت، اعتبارسنجی و رمزنگاری ارتباطات اطمینان حاصل می کند، بلکه اتصال اولیه را سریعتر خواهد کرد.

یک Handshake عادی در QUIC تنها یک مسیر رفت و برگشتی بین کلاینت و سرور طی خواهد کرد. برخلاف TCP و TLS 1.3 که این مسیر را دو بار طی می کنند.

به این تصویر نگاه کنید؛ یک درخواست HTTP با پروتکل های TCP و TLS در حالت عادی این تبادلات را طی خواهد کرد:

اما همین درخواست می تواند با استفاده از پروتکل QUIC تنها این مسیرها را طی کند:

جالب اینجاست که پروتکل QUIC حتی از این موضوع نیز فراتر رفته و سایر Metadata های ارتباط را نیز برای جلوگیری از دخالت و سوء استفاده مزاحمین خارجی، رمزنگاری می کند.

برای مثال، تعداد بسته ها می تواند توسط یک هکر ناشناس دستکاری شوند، که در صورت استفاده از QUIC و رمزنگاری، تعداد بسته های یک اتصال نمی توانند برای شبیه سازی فعالیت ها از یک Endpoint دیگر استفاده شوند.

مسدود سازی Head-of-line

یکی از مهمترین ویژگی هایی که توسط HTTP/2 ارائه شد، امکان تجمیع کردن درخواست های HTTP مختلف در یک اتصال TCP یکسان است. این موضوع باعث می شود تا اپلیکیشن های HTTP/2 بتوانند درخواست ها را به صورت موازی پردازش کرده و از پهنای باند شبکه بهتر استفاده کنند.

مورد فوق یک پیشرفت عظیم نسبت به وضعیت قبل بود که در آن اپلیکیشن ها برای پردازش همزمان چند درخواست HTTP/1.1 می بایست چند اتصال TCP+TLS مختلف ارسال می کردند (مثل زمانی که مرورگر باید برای رندر کردن یک صفحه وب، هر دو فایل CSS و Javascript را دریافت کند).

برقراری ارتباطات جدید به تکرار handshake های اولیه نیاز دارد که باید مجدداً وارد ترافیک ramp-up شود. این موضوع سرعت لود یک صفحه وب را کاهش خواهد داد.

البته این روش یک نقطه ضعف نیز دارد؛ از آنجا که چندین درخواست و پاسخ در یک اتصال TCP منتقل می شوند، تمام آنها به یک اندازه تحت تأثیر packet loss قرار خواهند گرفت. به این مشکل "head of line blocking" گویند.

برای حل مشکل فوق، QUIC راهکاری یافته و طوری از Multiplexing پشتیبانی می کند که در آن چندین درخواست HTTP مختلف می توانند در مسیرهای انتقالی QUIC متفاوتی قرار گیرند؛ اما با توجه به اینکه آنها همچنان در یک اتصال QUIC مشترک هستند، دیگر نیازی به برقراری Handshake اضافی وجود نخواهد داشت.

به عبارتی، جریانات QUIC به طور مستقل برقرار خواهند شد، به طوری که در بیشتر موارد اگر در یک جریان Packet Loss رخ دهد، بر جریانات دیگر تأثیری نخواهد گذاشت.

این موضوع می تواند به طور چشم گیری زمان مورد نیاز برای رندر کردن یک صفحه کامل را کاهش دهد، بخصوص در زمان های پرترافیک شبکه و نرخ بالای packet loss.

شاید به نظر اینکار آسان رسد اما برای اجرای چنین تمهیداتی QUIC به ترک برخی از عادات قبلی توسط اپلیکیشن ها نیاز دارد.

QUIC طوری طراحی شده است که بالا سر دیتاگرام UDP تحویل شود، تا اجرای تمهیدات فوق الذکر را آسان تر کرده و از بروز مشکلات شبکه ای و Packet Loss برگرفته از پروتکل های ناشناس جلوگیری کند.

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

مشکل NAT روترها در استفاده از QUIC

برخی از روترها از NAT یا "ترجمه آدرس شبکه" پشتیبانی می کنند؛ این ویژگی می تواند اتصالات TCP را ردیابی کرده و آدرس IP و پورت مرجع و مقصد را رصد کند.

علاوه بر این با رصد TCP SYN, ACK و FIN بسته های انتقالی در شبکه، این روترها می توانند زمان برقراری یک اتصال جدید و زمان بسته شدن آن را شناسایی کنند. در کل این روش باعث می شود روتر بتواند تبادلات بین آدرس های IP و پورت های مبدا و مقصد و مداخلات خارجی را بهتر مدیریت کند.

اما متاسفانه این روش هنوز در QUIC قابل اجرا نیست! چراکه روترهای NAT که امروزه تقریباً در همه جا مورد استفاده قرار گرفته اند، هنوز پروتکل QUIC را درک نمی کنند. به همین دلیل همچنان از همان فرآیند و جریانات UDP استفاده می شود.

در واقع مشکل در اینجاست:

زمانی که تغییر آدرس (Rebinding) NAT رخ می دهد (برای مثال به دلیل Timeout شدن)، مقصد نهایی خارج از پیرامون NAT بسته هایی را مشاهده خواهد کرد که از یک پورت متفاوت ارسال می شوند؛ یعنی پورتی که با پورت اولین اتصال متفاوت باشد؛

پس در نتیجه نمی تواند اتصالات را تنها با استفاده از 4-tuple (آدرس های IP و پورت های مبدا و مقصد) ردیابی کند.

البته مشکل فقط NAT نیست! یکی از فیچرهای QUIC این است که می توان در صورت نیاز اتصالات را به یک آدرس IP دیگر یا مسیر شبکه ای متفاوت هدایت کرد (Connection migration).

برای حل این مشکل، QUIC مفهوم Connection ID را معرفی کرده است. یک رقم تصادفی Binary شکل که با بسته های QUIC همراه شده و می تواند برای شناسایی یک اتصال مورد استفاده قرار گیرد.

Endpoint ها می توانند از این ID برای ردیابی اتصالات تحت نظر "بدون نیاز به 4-tuple" استفاده کنند.

با این وجود، شاید این روش نیز برای اپراتورهای شبکه ای که از Anycast استفاده می کنند، مشکل زا باشد؛ یا آنهایی که از مسیردهی ECMP استفاده می کنند که در آن یک آدرس IP مقصد واحد می تواند به راحتی صدها تا هزاران سرور را شناسایی کند.

از آنجا که روترهای Edge این شبکه ها نیز هنوز نمی دانند چطور ترافیک QUIC را هندل کنند، این احتمال وجود دارد که بسته های UDP با 4-tuple متفاوت، به سمت سرورهای دیگری هدایت شوند.

برای حل این چالش، اپراترهای شبکه باید به دنبال راهکار هوشمندتری در توزیع بار لایه 4 باشند که  بتواند به عنوان یک نرم افزاری جانبی و بدون نیاز به دستکاری روترهای edge پیکربندی شود.

ویژگی OPACK

یک ویژگی جذاب دیگر در HTTP/2 ، فشرده سازی هدر یا HPACK است که به HTTP/2 Endpoints این اجازه را می دهد تا حجم داده های انتقالی در شبکه را با حذف اضافات درخواست ها و پاسخ های HTTP کاهش دهد.

در واقع، در کنار تکنیک های دیگر، HPACK از جداول داینامیک درون هدرهایی که در درخواست HTTP قبلی ارسال شده بودند استفاده می کند؛ که به Endpoint این امکان را می دهد تا هدرهای تبادلی قبلی را مجدداً در درخواست های جدید استفاده کنند.

جداول داینامیک HPACK باید بین طرفین ارتباط یکسان‌سازی (synchronized) شوند. یعنی بین Encoder و Decoder؛ وگرنه مقصد نمی تواند آنچه دریافت می کند را رمزگشایی کند.

در HTTP/2 جریانات TCP این یکسان سازی پنهان است. چراکه لایه انتقال (TCP) درخواست ها و پاسخ های HTTP را به همان ترتیبی که دریافت می شوند، ارسال می کند. اما در QUIC این موضوع کمی پیچیده تر است.

QUIC می تواند چندین درخواست HTTP را به طور مستقل از چند مسیر مختلف عبور دهد؛ که با وجود رعایت ترتیب داده ها در هر مسیر (stream)، تضمینی برای رعایت ترتیب در مسیرهای مختلف وجود ندارد.

برای مثال، اگر کلاینتی یک درخواست HTTP از مسیر A در QUIC ارسال کند، و یک درخواست از مسیر B، این احتمال وجود دارد که درخواست دوم سریعتر از درخواست اول به سرور مقصد برسد!

اگر درخواست دوم طوری رمزنگاری شده باشد که به هدری در درخواست A ارجاع داده باشد، دیگر سرور نمی تواند آن را رمزگشایی کند؛ چون هنوز درخواست اول دریافت نشده!

در پروتکل gQUIC این مشکل تنها از طریق سری سازی (ترتیب دهی) به تمام هدرهای HTTP در درخواست ها و پاسخ (و البته در همان مسیر gQUIC) حل شده است.

یعنی هدرها دقیقا با همان ترتیب به مقصد تحویل می شوند.

این روش به پیاده سازی همان کدهای HTTP/2 کمک می کند ولی head-of-line blocking را افزایش خواهد داد؛ چیزی که قرار بود QUIC کاهش دهد.

به همین دلیل گروه IETF QUIC یک روش مسیردهی بین HTTP و QUIC و یک طرح فشرده سازی هدر جدید طراحی کردند؛ تحت عنوان "QPACK".

در آخرین نسخه HTTP/QUIC و QPACK، هر درخواست و پاسخ HTTP از مسیر دوگانه مختص خود استفاده می کند تا دیگر مشکل head-of-line blocking رخ ندهد.

بعلاوه برای پشتیبانی از QPACK، هر سمت ارتباط دو مسیر QUIC دوگانه مازاد ایجاد می کند؛ یکی برای ارسال نسخه های جدید جداول QPACK به طرف دیگر، و یکی برای تایید آپدیت ها توسط سمت مقابل.

به این ترتیب، یک QPACK encoder می تواند از ارجاع دهی جداول داینامیک بلافاصله پس از دریافت تاییدیه از سمت decoder استفاده کند.

جمع بندی

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