پروتکل کوییک

پروتکل کوییک

استاندارد بین المللی	RFC 9000
توسعه یافته توسط	جیم روسکایند، Google
تاریخ معرفی	۲۰۱۳؛ ۱۱ سال پیش (۲۰۱۳-خطا: زمان نامعتبر}})
وبگاه	https://quicwg.org/

کوییک (به انگلیسی: QUIC) یک پروتکل لایهٔ انتقال^[۱] است که در سال ۲۰۱۲ توسط جیم روسکایند در گوگل پیاده‌سازی و در سال ۲۰۱۳ منتشر شد.^[۲][۳] این پروتکل، برای بیش از نیمی از اتصالات گوگل کروم به سرورهای گوگل استفاده می‌شود.^[۴] علاوه بر این مرورگرهای ماکروسافت اج^[۵]، فایرفاکس و سافاری^[۶] نیز از این پروتکل پشتیبانی می‌کنند.

کوییک، عملکرد پروتکل پیشین خود، یعنی پروتکل هدایت انتقال را بهبود می‌بخشد.^[۱] این کار، با استفاده از پروتکل داده‌نگار کاربر به عنوان پایه‌ای برای برقراری ارتباط بین دو نقطهٔ پایانی در لایهٔ انتقال انجام می‌شود.^[۷] علاوه بر این، کوییک به کاهش تاخیر و جلوگیری از ازدحام در شبکه کمک می‌کند.

در سال ۲۰۲۱، کارگروه مهندسی اینترنت پروتکل کوییک را استانداردسازی کرد.

ویژگی‌ها

در خصوص پشتیبانی از پروتکل امن انتقال ابرمتن (HTTPS)، کوییک همانند پروتکل هدایت انتقال (TCP) عمل می‌کند، ولی تاخیر کمتری ارائه می‌دهد و به شکلی بهینه‌تر بسته‌های گم شده را بازیابی می‌کند. این بهبودها به سبب دو تفاوت عمده بین این کوییک و TCP به وجود آمده‌اند.^[۸]

اولین تفاوت، کاهش زمان لازم برای اتصال اولیه در کوییک است. با توجه به این که بیشتر اتصالات HTTPS نیازمند پروتکل امنیتی لایهٔ انتقال (TLS) هستند، کوییک بخشی از اطلاعات لازم برای این پروتکل را در دست‌دهی اولیه منتقل می‌کند. تا پیش از این، لازم بود تا در ابتدا یک اتصال TCP برقرار شود، سپس اطلاعات لازم برای پروتکل‌های امنیتی رد و بدل شوند.^[۸]

دومین تفاوت، استفاده از پروتکل داده‌نگار کاربر (UDP) به عنوان پایهٔ انتقال اطلاعات است. برای جبران خدماتی که UDP ارائه نمی‌دهد (مانند بازیابی بسته‌ها)، کوییک خود در جریانی متفاوت از UDP این خدمات را پیاده‌سازی می‌کند. این تفاوت جریان باعث می‌شود که در صورت خطا در یکی از پروتکل‌ها، پروتکل دیگر کمتر تحت تاثیر قرار می‌گیرد.^[۸]

اگر چه در ابندا نام آن به عنوان مخفف "اتصالات اینترنتی UDP سریع" انتخاب شد ، اما در استفاده IETF از کلمه QUIC مخفف نیست .

بلکه فقط نام پروتکل است. QUIC عملکرد برنامه های وب مبتنی بر اتصال که در حال حاضر از پروتکل کنترل انتقال (TCP)استفاده می کنند را بهبود می بخشد. این کار را با برقراری تعدادی اتصال چندگانه بین دو نقطه پایان با استفاده از پروتکل UDP (Datagram User) انجام می دهد و برای بسیاری از برنامه ها طراحی شده است تا پروتکل TCP را در الیه حمل برای بسیاری از برنامه ها منسوخ کند و به همین دلیل به پروتکل گاه به گاه "/2TCP "نامگذاری می شود.

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

اهداف فرعی

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

در ژوئن ،2015 یک پیش نویس اینترنتی از یک مشخصه برای QUIC به IETF برای استاندارد سازی ارسال شد. یک گروه کاری QUIC در سال 2016 تشکیل شد. در اکتبر ،2018 گروه های کاری HTTP و QUIC IETF به طور مشترک تصمیم گرفتند که نگاشت HTTP روی QUIC را "/3HTTP "نامگذاری کنند قبل از آنکه آن را به عنوان یک استاندارد جهانی اغلام کنند. در ماه مه ،2021 QUIC IETF را در 9000 RFC استاندارد سازی کرد، که توسط 8999 RFC، 9001 RFC و 9002 RFC پشتیبانی می شود. -DNS QUIC-over نیز یک برنامه دیگر است.

پس زمینه

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

در بیشتر پیاده سازی ها، TCP هر خطا در یک اتصال را به عنوان یک عملیات مسدود کننده میبیند که تا زمان حل خطا یا اتصال به عنوان ناموفق در نظر گرفته میشود، انتقال های بعدی متوقف میشود. اگر یک اتصال تنها برای ارسال چندین جریان داده استفاده شود، همانطور که در پروتکل /2HTTP رخ میدهد، تمام این جریان ها مسدود میشوند، اگرچه تنها یکی از آنها ممکن است مشکل داشته باشد. به عنوان مثال، اگر در حین بارگیری یک تصویر GIF برای استفاده در favicon یک خطا رخ دهد، صفحه به طور کامل منتظر میماند تا این مشکل حل شود. این پدیده به عنوان مسدود شدن سر خط شناخته میشود.

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

TCP از تصلب پروتکل رنج میبرد، به دلیل اینکه تصویر سیم آن در قالب متن روشن است و بنابراین قابل مشاهده و قابل تغییر توسط میان جعبه ها است. یک اندازه گیری نشان داد که یک سوم مسیرها در سراسر اینترنت با حداقل یک واسطه مواجه میشوند که متادیتای TCP را تغییر میدهد و 6.5 درصد مسیرها از تأثیرات تصلب آسیب زا از واسطه ها رنج میبرند. توسعه هایی برای TCP تحت تأثیر قرار گرفته اند: طراحی MPTCP (TCP Multipath ) به دلیل رفتار میان جعبه ها محدود شده است و استقرار Open Fast TCP نیز به همین دلیل متعذر شده است.

ویژگی ها

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

تغییر دوم استفاده از UDP به جای TCP به عنوان پایه آن است که شامل بازیابی از دست رفتگی نمی شود. به جای آن، هر جریان QUIC به طور جداگانه کنترل جریان می شود و داده های از دست رفته در سطح QUIC و نه UDP مجدداً ارسال می شوند. این بدان معنی است که اگر خطا در یک جریان رخ دهد، مانند مثال favicon بالا ، پشته پروتکل می تواند به طور مستقل از سرویس دهی به جریان های دیگر ادامه دهد. این می تواند در بهبود عملکرد در لینک های خطاپذیر بسیار مفید باشد، زیرا در اکثر موارد ممکن است قبل از اینکه TCP توجه کند که یک بسته از دست رفته یا خراب شده است، داده های قابل توجهی اضافی دریافت شود و تمام این داده ها در حالت بلاک شده یا حتی فلاش شده است در حالی که خطا اصلاح می شود. در QUIC، این داده ها آزاد است برای پردازش در حالی که جریان تکرار شده تعمیر می شود.

QUIC شامل تعدادی تغییر دیگر است که بهبود کلی تاخیر و توانایی ارتباط را بهبود می بخشد. به عنوان مثال، بسته ها به صورت جداگانه رمزنگاری می شوند، به طوری که منجر به انتظار داده های رمزنگاری شده برای بسته های جزئی نمی شود. این به طور کلی در TCP ممکن نیست، جایی که رکوردهای رمزنگاری در یک جریان بایتی هستند و پشته پروتکل از مرزهای لایه بالاتردر این جریان آگاه نیست. این می تواند توسط لایه هایی که روی آن اجرا می شوند مذاکره شود، اما هدف QUIC این است که همه این کارها را در یک فرآیند دست دادن تکمیل کند.

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

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

در نهایت تفاوت ممکن است بسیار کوچک باشد زیرا بخش های زیادی از پشته /2HTTP به طور کلی در برنامه ها ( یا کتابخانه های آنها، بیشتر به کار میروند) قرار دارند. قرار دادن بخش های باقیمانده در آن کتابخانه ها، به طور جزئی اصلاح خطا، تأثیر کمی بر اندازه یا پیچیدگی کل پشته /2HTTP ندارد.

این سازماندهی امکان تغییرات آینده را به راحتی فراهم میکند زیرا برای به روزرسانی ها نیازی به تغییرات در هسته ندارد. یکی از اهداف بلندمدت QUIC اضافه کردن سیستم های جدید برای اصلاح خطا به جلو (FEC) و کنترل بهبود یافته از ازدحام است.

یکی از نگرانی ها درباره انتقال از TCP به UDP این است که TCP به طور گسترده پذیرفته شده است و بسیاری از "جعبه های وسط" در زیرساخت اینترنت برای TCP تنظیم شده اند و ممکن است سرعت یا حتی UDP را محدود کنند یا مسدود کنند.

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

QUIC به طور خاص برای قابل اجرا، تکامل پذیر و دارای ویژگیه ای ضد-استخوان گذاری طراحی شده است؛ این اولین پروتکل انتقال IETF است که به طور عمدی تصویر سیم خود را برای این اهداف کمینه کرده است. غلاوه بر هدرهای رمزنگاری شده، آن 'روغن دار' است و دارای ویژگی های پروتکل به صورت صریح مشخص شده است.

گوگل

پروتکلی که توسط گوگل ایجاد شده و تحت عنوان QUIC به IETF منتقل شده است ( قبلا در سال 2012 حول نسخه 20 QUIC )کاملا متفاوت از QUIC است که در IETF ادامه یافته و بهبود یافته است. QUIC اصلی گوگل برای بودن یک پروتکل چند منظوره طراحی شده بود، اگرچه ابتدا به عنوان یک پروتکل برای پشتیبانی از S(HTTP) در کرومیوم پیاده سازی شد. تکامل کنونی پروتکل QUIC IETF یک پروتکل حمل و نقل چند منظوره است. توسعه دهندگان کرومیوم ادامه دادند به پیگیری تکامل تلاش های استانداردسازی QUIC IETF برای اتخاذ و کاملا پیروی از استانداردهای اینترنت جدیدتر برای QUIC در کرومیوم.

برنامه های کاربردی

QUIC با در نظر گرفتن HTTP توسعه یافته است و /3HTTP اولین برنامه ای است که از آن استفاده می کند.[34][35] QUIC-over-DNS یک برنامه از QUIC برای رزولوشن نام است که امنیت برای انتقال داده ها بین رزولورها را فراهم می کند مشابه IETF[36].TLS-over-DNS در حال توسعه برنامه های کاربردی QUIC برای تونلینگ امن شبکه[35] و تحویل رسانی رسانه های جریانی است.[37]XMPP به صورت تجربی به QUIC تطبیق داده شده است. استفاده کنید.[38] برنامه دیگر QUIC over SMB است که طبق گفته مایکروسافت می تواند "یک VPN SMB "را بدون تأثیر بر تجربه کاربر ارائه دهد.[39] مشتریان SMB به طور پیش فرض از TCP استفاده می کنند و در صورت عدم موفقیت تلاش TCP یا در صورت نیاز قصد داشتن QUIC، تلاش می کنند.

پشتیبانی مرورگر

کد QUIC به صورت تجربی در Chrome Google از سال 2012 توسعه یافته است [4] و به عنوان بخشی از نسخه 29 Chromium( منتشر شده در 20 اوت 2013 ) اغلام شد.[18] در حال حاضر به صورت پیش فرض در Chromium و Chrome فعال است.[40] پشتیبانی در Firefox در ماه مه 2021 رسید.[41][12] پل در آوریل 2020 پشتیبانی تجربی را در موتور WebKit از طریق Preview Technology Safari 104 اضافه کرد.

پشتیبانی رسمی در 14 Safari اضافه شد که در Sur Big macOS و 14 iOS گنجانده شده است.[43] ما برای استفاده از این ویژگی باید به صورت دستی آن را فعال کنید.[44] بعدها به صورت پیش فرض در 16 Safari فعال شد.[13]

پشتیبانی مشتری

کتابخانه cronet برای QUIC و سایر پروتکل ها به عنوان یک ماژول قابل بارگذاری از طریق Google Services Play برای برنامه های اندروید در دسترس است.[45] 7.66 cURL که در تاریخ 11 سپتامبر 2019 منتشر شد، پشتیبانی از /3HTTP( و بنابراین QUIC )را دارد.[46][47]

در اکتبر ،2020 فیس بوک اعلام کرد[48] که برنامه های خود، از جمله اینستاگرام، و زیرساخت سرور خود را به QUIC با موفقیت انتقال داده است و در حال حاضر ٪75 از ترافیک اینترنت خود را با استفاده از QUIC دارد. تمام برنامه های موبایل از گوگل از QUIC پشتیبانی می کنند، از جمله یوتیوب و [[50][49].Gmail]برنامه موبایل Uber نیز از QUIC استفاده می کند.[50]

پشتیبانی سرور

به عنوان ،2017 چندین پیاده سازی فعال وجود دارد. سرورهای گوگل پشتیبانی از QUIC و گوگل یک سرور نمونه منتشر کرده است.[51] شرکت Technologies Akamai از ژوئیه 2016 پشتیبانی از QUIC را ارائه می دهد.[52][53] یک پیاده سازی Go به نام [[54]go-quic ]نیز در دسترس است و پشتیبانی تجربی QUIC را در سرور Caddy تأمین می کند.[55] در تاریخ 11 ژوئیه 2017 شرکت LiteSpeed Technologies رسماً پشتیبانی از QUIC را در توزیع کننده بار خود [56[(WebADC ]و محصولات Server Web LiteSpeed آغاز کرد.[57] به عنوان اکتبر ،2019 ٪88.6 از وب سایت های QUIC از LiteSpeed و ٪10.8 از Nginx استفاده می کنند.[58] اگرچه در ابتدا تنها سرورهای گوگل از اتصالات QUIC-over-HTTP پشتیبانی می کردند، فیس بوک نیز در سال 2018 این تکنولوژی را راه اندازی کرد.[18]و Cloudflare از سال 2018 پشتیبانی QUIC را به صورت آزمایشی ارائه می دهد [59] بارگذاری HAProxy در مارس 2022 پشتیبانی تجربی برای QUIC را اضافه کرد[60]

و در مارس 2023 آن را آماده تولید اعلام کرد.[61] به عنوان آوریل ،2023 ٪8.9 از تمام وب سایت ها از QUIc استفاده می کنند،[62] که در مارس 2021 از ٪5 افزایش یافته است. Windows Microsoft 2022 Server هر دو پروتکل [[63]/3HTTP ]و [64]QUIC over SMB را از طریق MsQuic پشتیبانی می کند. کنترل کننده تحویل برنامADC Citrix (Citrix، NetScaler )می تواند به عنوان یک پروکسی QUIC عمل کند از نسخه 13 به بعد.[66][65]علاوه بر این، چندین پروژه جامعه خاموش وجود دارد: [[67]libquic]توسط استخراج پیاده سازی Chromium از QUIC ایجاد شده است و به منظور کاهش نیازهای وابستگی آن تغییر داده شده است و [68]goquic ]بسته بندی های Go از libquic را فراهم می کند. در نهایت، -reverse-quic 69]proxy ]یک تصویر Docker است که به عنوان یک سرور پروکسی معکوس عمل می کند و درخواست های QUIC را به HTTP ساده ترجمه می کند که توسط سرور منبع قابل درک است. 5. NET پشتیبانی تجربی برای QUIC با استفاده از کتابخانه MsQuic را معرفی می کند.[70]

1. «Connecting on the QUIC [LWN.net]». lwn.net. دریافت‌شده در ۲۰۲۴-۰۶-۱۹.
2. «QUIC: Design Document and Specification Rationale». Google Docs. دریافت‌شده در ۲۰۲۴-۰۶-۱۹.
3. "Experimenting with QUIC". Chromium Blog (به انگلیسی). Retrieved 2024-06-19.
4. Lardinois، Frederic (۲۰۱۵-۰۴-۱۸). «Google Wants To Speed Up The Web With Its QUIC Protocol». TechCrunch (به انگلیسی). دریافت‌شده در ۲۰۲۴-۰۶-۱۹.
5. Fernandes، Christopher (۲۰۱۸-۰۴-۰۲). «Microsoft to add support for Google's QUIC fast internet protocol in Windows 10 Redstone 5». Windows Latest (به انگلیسی). دریافت‌شده در ۲۰۲۴-۰۶-۱۹.
6. "Examining HTTP/3 usage one year on". The Cloudflare Blog (به انگلیسی). 2023-06-06. Retrieved 2024-06-19.
7. Kurose، James. Computer Networking - A Top Down Approack (ویراست ۸). ص. ۲۸۰.
8. Staff، Ars (۲۰۱۸-۱۱-۱۲). «The next version of HTTP won't be using TCP». Ars Technica (به انگلیسی). دریافت‌شده در ۲۰۲۴-۰۶-۱۹.