موضوع مقاله: کوییک (پروتکل) | مخاطب: عمومی | لحن: دانشنامه‌ای | ساختار: عنوان، مقدمه، 3 بخش، جمع‌بندی | مقاله: | # کوییک (پروتکل) | مقدمه: کوییک یک پروتکل لایهٔ انتقال است که در سال ۲۰۱۲ توسط جیم روسکایند در گوگل پیاده‌سازی و در سال ۲۰۱۳ منتشر شد. | ## بخش 1: کوییک (پروتکل) | این پروتکل، برای بیش از نیمی از اتصالات گوگل کروم به سرورهای گوگل استفاده می‌شود. علاوه بر این مرورگرهای ماکروسافت اج، فایرفاکس و سافاری نیز از این پروتکل پشتیبانی می‌کنند. این کار، با استفاده از پروتکل داده‌نگار کاربر به عنوان پایه‌ای برای برقراری ارتباط بین دو نقطهٔ پایانی در لایهٔ انتقال انجام می‌شود. ویژگی‌ها در خصوص پشتیبانی از پروتکل امن انتقال ابرمتن (HTTPS)، کوییک همانند پروتکل هدایت انتقال (TCP) عمل می‌کند، ولی تاخیر کمتری ارائه می‌دهد و به شکلی بهینه‌تر بسته‌های گم شده را بازیابی می‌کند. با توجه به این که بیشتر اتصالات HTTPS نیازمند پروتکل امنیتی لایهٔ انتقال (TLS) هستند، کوییک بخشی از اطلاعات لازم برای این پروتکل را در دست‌دهی اولیه منتقل می‌کند. تا پیش از این، لازم بود تا در ابتدا یک اتصال TCP برقرار شود، سپس اطلاعات لازم برای پروتکل‌های امنیتی رد و بدل شوند. دومین تفاوت، استفاده از پروتکل داده‌نگار کاربر (UDP) به عنوان پایهٔ انتقال اطلاعات است. برای جبران خدماتی که UDP ارائه نمی‌دهد (مانند بازیابی بسته‌ها)، کوییک خود در جریانی متفاوت از UDP این خدمات را پیاده‌سازی می‌کند. این تفاوت جریان باعث می‌شود که در صورت خطا در یکی از پروتکل‌ها، پروتکل دیگر کمتر تحت تاثیر قرار می‌گیرد. QUIC عملکرد برنامه های وب مبتنی بر اتصال که در حال حاضر از پروتکل کنترل انتقال (TCP)استفاده می کنند را بهبود می بخشد. این کار را با برقراری تعدادی اتصال چندگانه بین دو نقطه پایان با استفاده از پروتکل UDP (Datagram User) انجام می دهد و برای بسیاری از برنامه ها طراحی شده است تا پروتکل TCP را در الیه حمل برای بسیاری از برنامه ها منسوخ کند و به همین دلیل به پروتکل گاه به گاه "/2TCP "نامگذاری می شود. QUIC همراه با اتصالات چندگانه /3HTTP کار می کند که امکان رسیدن داده های چند جریان به تمام نقاط پایان را به طور مستقل فراهم می کند و بنابراین مستقل از از دست دادن بسته های داده مربوط به جریان های دیگر است. در مقابل، /2HTTP که بر روی TCP میزبانی می شود، ممکن است با تاخیرهای مسدود کننده خط اول مواجه شود اگر چندین جریان روی یک اتصال TCP چندگانه متعدد شوند و هر یک از بسته های TCP در آن اتصال تاخیر یا از دست بروند. اهداف فرعی اهداف فرعی QUIC شامل کاهش تاخیر اتصال و حمل و نقل و تخمین پهنای باند در هر جهت برای جلوگیری از تراکم است. همچنین، این پروتکل الگوریتم های کنترل تراکم را به فضای کاربر در هر دو نقطه پایان منتقل می کند، به جای فضای هسته، که ادعا می شود این امکان را به الگوریتم ها می دهد تا بهبود بیشتری داشته باشند. عالوه بر این، این پروتکل می تواند با استفاده از اصالح خطاهای پیش بینی شده (FCE) عملکرد را بهبود بخشد و این به عنوان مرحله بعدی در تکامل پروتکل در نظر گرفته می شود. طراحی شده است تا از تصلب پروتکل جلوگیری کند تا به عنوان TCP که تصلب قابل توجهی داشته است، قابل توسعه باقی بماند. پس زمینه پروتکل کنترل انتقال یا TCP به هدف فراهم کردن یک رابط برای ارسال جریان های داده بین دو نقطه پایان است. داده به سیستم TCP تحویل داده میشود که اطمینان میدهد داده به همان شکل به سمت دیگری منتقل شود و در غیر این صورت اتصال خطا را نشان میدهد. برای این کار، TCP داده را به بسته های شبکه تقسیم میکند و مقادیر کوچکی را به هر بسته اضافه میکند. این داده اضافی شامل یک شماره توالی است که برای تشخیص بسته های گم شده یا به ترتیب نرسیده استفاده میشود و یک چکسازی که امکان تشخیص خطاهای داخل داده بسته را فراهم میکند. | ## بخش 2: کوییک (پروتکل) | هنگامی که هر یک از این مشکلات رخ میدهد، TCP از درخواست تکرار خودکار تکراری (ARQ)استفاده میکند تا به فرستنده بگوید بسته گم شده یا آسیب دیده را مجدداً ارسال کند. در بیشتر پیاده سازی ها، TCP هر خطا در یک اتصال را به عنوان یک عملیات مسدود کننده میبیند که تا زمان حل خطا یا اتصال به عنوان ناموفق در نظر گرفته میشود، انتقال های بعدی متوقف میشود. اگر یک اتصال تنها برای ارسال چندین جریان داده استفاده شود، همانطور که در پروتکل /2HTTP رخ میدهد، تمام این جریان ها مسدود میشوند، اگرچه تنها یکی از آنها ممکن است مشکل داشته باشد. به عنوان مثال، اگر در حین بارگیری یک تصویر GIF برای استفاده در favicon یک خطا رخ دهد، صفحه به طور کامل منتظر میماند تا این مشکل حل شود. از آنجا که سیستم TCP طراحی شده است تا شبیه یک "لوله داده" یا جریان باشد ، قصداً درک کمی از داده هایی که انتقال میدهد، دارد. اگر این داده نیازهای اضافی مانند رمزگذاری با استفاده از TLS داشته باشد، باید توسط سیستم هایی که روی TCP اجرا میشوند و با نرم افزار مشابه در سمت دیگر اتصال برقرار میکنند، تنظیم شود. به دلیل تاخیر ذاتی ارتباطات در فواصل بلند، این میتواند به هزینه اضافی به انتقال کلی اضافه کند. TCP از تصلب پروتکل رنج میبرد، به دلیل اینکه تصویر سیم آن در قالب متن روشن است و بنابراین قابل مشاهده و قابل تغییر توسط میان جعبه ها است. یک اندازه گیری نشان داد که یک سوم مسیرها در سراسر اینترنت با حداقل یک واسطه مواجه میشوند که متادیتای TCP را تغییر میدهد و 6.5 درصد مسیرها از تأثیرات تصلب آسیب زا از واسطه ها رنج میبرند. ویژگی ها در زمینه پشتیبانی از ترافیک HTTP رمزنگاری شده، QUIC نقش مشابهی با TCP دارد، اما با کاهش تاخیر در فرآیند برقراری ارتباط و بازیابی از دست رفتگی های کارآمدتر هنگامی که چندین جریان HTTP را در یک ارتباط تکرار می کند. این کار را اصولا از طریق دو تغییر انجام می دهد که بر اساس درک رفتار ترافیک HTTP استوار است. زیرا اکثر ارتباطات HTTP نیاز به TLS دارند، QUIC تبادل کلیدهای راه اندازی و پروتکل های پشتیبانی شده را به عنوان بخشی از فرآیند اصلی دست دادن انجام می دهد. هنگامی که یک کلاینت یک ارتباط باز می کند، بسته پاسخ شامل داده های مورد نیاز برای استفاده از رمزنگاری برای بسته های آینده است. این باعث حذف نیاز به برقراری ارتباط TCP و سپس مذاکره پروتکل امنیتی از طریق بسته های اضافی می شود. پروتکل های دیگر نیز می توانند به همین روش خدمات دهند، ترکیب چندین مرحله را در یک جفت درخواست-پاسخ تکمیل می کنند. این داده ها می توانند همچنین برای درخواست های بعدی در تنظیم اولیه و همچنین درخواست های آینده که در غیر این صورت به عنوان ارتباط های جداگانه مذاکره می شوند، استفاده شوند. تغییر دوم استفاده از UDP به جای TCP به عنوان پایه آن است که شامل بازیابی از دست رفتگی نمی شود. این بدان معنی است که اگر خطا در یک جریان رخ دهد، مانند مثال favicon بالا ، پشته پروتکل می تواند به طور مستقل از سرویس دهی به جریان های دیگر ادامه دهد. این می تواند در بهبود عملکرد در لینک های خطاپذیر بسیار مفید باشد، زیرا در اکثر موارد ممکن است قبل از اینکه TCP توجه کند که یک بسته از دست رفته یا خراب شده است، داده های قابل توجهی اضافی دریافت شود و تمام این داده ها در حالت بلاک شده یا حتی فلاش شده است در حالی که خطا اصلاح می شود. در QUIC، این داده ها آزاد است برای پردازش در حالی که جریان تکرار شده تعمیر می شود. QUIC شامل تعدادی تغییر دیگر است که بهبود کلی تاخیر و توانایی ارتباط را بهبود می بخشد. | ## بخش 3: کوییک (پروتکل) | به عنوان مثال، بسته ها به صورت جداگانه رمزنگاری می شوند، به طوری که منجر به انتظار داده های رمزنگاری شده برای بسته های جزئی نمی شود. این به طور کلی در 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 اصلی گوگل برای بودن یک پروتکل چند منظوره طراحی شده بود، اگرچه ابتدا به عنوان یک پروتکل برای پشتیبانی از S(HTTP) در کرومیوم پیاده سازی شد. | ## جمع‌بندی | توسعه دهندگان کرومیوم ادامه دادند به پیگیری تکامل تلاش های استانداردسازی QUIC IETF برای اتخاذ و کاملا پیروی از استانداردهای اینترنت جدیدتر برای QUIC در کرومیوم.