QUIC یک پروتکل پروتکل شبکه لایه حمل و نقل است در ابتدا توسط جیم راسکیند در گوگل طراحی اجرا شده در سال 2012 مستقر، عمومی در سال 2013 به صورت گسترده ازمایش و به IETF شرح داده شده در حالی که هنوز یک پیش نویس اینترنتی است ، QUIC توسط بیش از نیمی از همه اتصالات از مرورگر وب Chrome به سرورهای Google استفاده می شود. [۱] مایکروسافت Edge [۲] و Firefox [۳] ، حتی اگر به طور پیش فرض فعال نباشند ، پشتیبانی می کنند ، همین طور Safari Technology Preview . [۴]

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

در میان برنامه های دیگر ، QUIC عملکرد برنامه های وب متصل به اتصال که در حال حاضر از TCP استفاده می کنند را بهبود می بخشد. [۱] این کار با ایجاد تعدادی از اتصالات چند ضلعی بین دو نقطه انتهایی بر روی پروتکل داده کاربر (UDP) انجام می شود. این کار به صورت دستی با اتصالات چند منظوره HTTP/2 انجام می شود ، اجازه می دهد چندین جریان داده به طور مستقل به تمام نقاط انتهایی برسند ، و از این رو مستقل از ضررهای بسته ای که شامل جریان های دیگر هستند. در مقابل ، HTTP / 2 میزبانی شده در پروتکل کنترل انتقال (TCP) ممکن است در صورت تاخیر یا گم شدن هر یک از بسته های TCP باعث تاخیر در مسدود شدن خط از همه جریان های چند برابر شود.

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

در ژانویه 2015 ، پیش نویس اینترنتی مشخصات مربوط به QUIC برای استاندارد سازی به IETF ارسال شد. [۵] یک گروه کاری QUIC در سال 2016 تأسیس شد. [۶] در اکتبر سال 2018 ، کارگروه های HTTP و QUIC IETF به طور مشترک تصمیم گرفتند که نقشه برداری HTTP را بر روی QUIC HTTP / 3 انجام دهند و آن را به یک استاندارد جهانی تبدیل کنند. [۷]

زمینهویرایش

پروتکل كنترل انتقال ( TCP) با هدف ایجاد واسط برای ارسال جریان داده ها بین دو نقطه انتهایی است. داده به سیستم TCP تحویل داده می شود ، كه تضمین می كند داده دقیقاً در همان فرم به انتهای دیگر تبدیل می شود ، یا اتصال نشان می دهد كه یك شرایط خطا وجود دارد. [۸]

برای این کار ، TCP داده ها را در بسته های شبکه تجزیه می کند و مقادیر کمی از داده ها را به هر بسته اضافه می کند. این داده های اضافی شامل یک عدد دنباله است که برای تشخیص بسته های گم شده یا خارج از نظم استفاده می شود ، و یک چک که می تواند خطاهای درون داده های بسته را تشخیص دهد. در صورت بروز هر دو مشکل ، TCP از درخواست تکرار خودکار (ARQ) برای ارسال به ارسال کننده می خواهد تا بسته بسته گمشده یا آسیب دیده را دوباره ارسال کند. [۸]

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

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

  1. ۱٫۰ ۱٫۱ Lardinois, Frederic. "Google Wants To Speed Up The Web With Its QUIC Protocol". TechCrunch. Retrieved 2016-10-25.
  2. Christopher Fernandes (April 3, 2018). "Microsoft to add support for Google's QUIC fast internet protocol in Windows 10 Redstone 5". Retrieved 2020-05-08.
  3. "How to enable HTTP3 in Chrome / Firefox / Safari". bram.us. April 8, 2020.
  4. "Release Notes for Safari Technology Preview 104". WebKit.org. April 8, 2020.
  5. "Google Will Propose QUIC As IETF Standard". InfoQ. Retrieved 2016-10-25.
  6. "QUIC - IETF Working Group". datatracker.ietf.org. Retrieved 2016-10-25.
  7. Cimpanu, Catalin (12 November 2018). "HTTP-over-QUIC to be renamed HTTP/3". ZDNet.
  8. ۸٫۰ ۸٫۱ ۸٫۲ ۸٫۳ Bright, Peter (12 November 2018). "The next version of HTTP won't be using TCP". Arstechnica.