You can edit almost every page by Creating an account. Otherwise, see the FAQ.

QUIC

از EverybodyWiki Bios & Wiki
پرش به:ناوبری، جستجو


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 برای ارتباط با نرم افزارهای مشابه در انتهای دیگر اتصال استفاده شود. هر یک از این نوع کارهای تنظیم نیاز به روند دستیابی به خود دارد. این کار اغلب تا زمان برقراری اتصال به چندین سفر درخواستی و پاسخی نیاز دارد. با توجه به تأخیر ذاتی ارتباطات از راه دور ، این می تواند سربار قابل توجهی به انتقال کلی اضافه کند. [۸]


This article "QUIC" is from Wikipedia. The list of its authors can be seen in its historical and/or the page Edithistory:QUIC. Articles copied from Draft Namespace on Wikipedia could be seen on the Draft Namespace of Wikipedia and not main one.

  1. ۱٫۰ ۱٫۱ Lardinois, Frederic. "Google Wants To Speed Up The Web With Its QUIC Protocol". TechCrunch. Retrieved 2016-10-25.صفحه پودمان:Citation/CS1/en/styles.css محتوایی ندارد.
  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.صفحه پودمان:Citation/CS1/en/styles.css محتوایی ندارد.
  3. "How to enable HTTP3 in Chrome / Firefox / Safari". bram.us. April 8, 2020.صفحه پودمان:Citation/CS1/en/styles.css محتوایی ندارد.
  4. "Release Notes for Safari Technology Preview 104". WebKit.org. April 8, 2020.صفحه پودمان:Citation/CS1/en/styles.css محتوایی ندارد.
  5. "Google Will Propose QUIC As IETF Standard". InfoQ. Retrieved 2016-10-25.صفحه پودمان:Citation/CS1/en/styles.css محتوایی ندارد.
  6. "QUIC - IETF Working Group". datatracker.ietf.org. Retrieved 2016-10-25.صفحه پودمان:Citation/CS1/en/styles.css محتوایی ندارد.
  7. Cimpanu, Catalin (12 November 2018). "HTTP-over-QUIC to be renamed HTTP/3". ZDNet.صفحه پودمان:Citation/CS1/en/styles.css محتوایی ندارد.
  8. ۸٫۰ ۸٫۱ ۸٫۲ ۸٫۳ Bright, Peter (12 November 2018). "The next version of HTTP won't be using TCP". Arstechnica.صفحه پودمان:Citation/CS1/en/styles.css محتوایی ندارد.


Read or create/edit this page in another language[ویرایش]