ما پشتیبانی اولیه را از QUIC و HTTP / 3 (یا "HTTP بیش از QUIC" که در آن زمان مشخص بود) اعلام کردیم ، استاندارد جدید وب است که امکان اتصال سریعتر ، مطمئن تر و ایمن تر به وب را فراهم می کند. مانند وب سایت ها و API ها. ما همچنین به مشتریان خود اجازه می دهیم تا به محض دسترسی ، به لیست انتظار بپیوندند تا QUIC و HTTP / 3 را امتحان کنند
از آن زمان ، ما با همتایان صنعت از طریق کارگروه مهندسی اینترنت ، از جمله Google Chrome و Mozilla Firefox ، همکاری کرده ایم تا داکیومنت های HTTP / 3 و QUIC را تکرار کنیم . به موازات بالغ شدن داکیومنت ها ، ما در زمینه بهبود پشتیبانی در شبکه خود نیز کار کرده ایم.
اکنون خوشحالیم که اعلام کردیم که پشتیبانی QUIC و HTTP / 3 در شبکه Cloudflare edge وجود دارد. ما از اینکه Google Chrome و Mozilla Firefox ، دو فروشنده پیشرو مرورگر و شرکای ما در تلاش برای ایجاد سریعتر و مطمئن تر وب برای همه هستند ، بسیار خوشحالیم.
به گفته Ryan Ryan Hamilton ، مهندس نرم افزار Staff در Google ، "HTTP / 3 باید وب را برای همه بهتر کند. تیم های Chrome و Cloudflare با هم همکاری کرده اند تا HTTP / 3 و QUIC را از استانداردهای نوپا به فناوریهای گسترده اتخاذ شده برای بهبود وب ببرند. مشارکت جدی بین رهبران صنعت، چیزی است که باعث می شود نوآوری های استاندارد اینترنت امکان پذیر باشد ، و ما مشتاقانه منتظر ادامه کار مشترک خود هستیم. "
این برای شما مشتری Cloudflare که از خدمات و شبکه edge ما استفاده می کند برای حضور شما در وب سریعتر و ایمن تر است ، چه معنایی دارد؟ هنگامی که پشتیبانی HTTP / 3 برای دامنه شما در داشبورد Cloudflare فعال شود ، مشتریان می توانند با استفاده از HTTP / 3 با وب سایت ها و API های شما ارتباط برقرار کنند. ما به طور پیوسته از مشتریان در لیست انتظار HTTP / 3 دعوت کرده ایم تا این ویژگی را فعال کنند (بنابراین از طریق ایمیل برای ما ایمیل بفرستید) و در هفته های آینده این ویژگی را در دسترس همه قرار خواهیم داد.
اگر شما کاربر اینترنت با سایت ها و API ها از طریق مرورگر و سایر مشتری ها در تعامل هستید ، این اطلاعیه به چه معنی است؟ از امروز ، می توانید از Chrome Canary برای تعامل با Cloudflare و سایر سرورهای HTTP / 3 استفاده کنید. برای کسانی که به دنبال مشتری خط فرمان هستید ، curl از HTTP / 3 نیز پشتیبانی می کند. دستورالعمل استفاده از Chrome و Curl با HTTP / 3 در ادامه در این پست دنبال می کنید.
نوآوری استانداردها در اینترنت از لحاظ تاریخی به دلیل مشکلchicken و egg دشوار بوده است: چه کسی ابتدا نیاز به پشتیبانی سرور (مانند Cloudflare یا سایر منابع بزرگ داده های پاسخ) یا پشتیبانی مشتری (مانند مرورگرها ، سیستم عامل ها و غیره) دارد؟ هر دو طرف یک اتصال باید از یک پروتکل ارتباطی جدید پشتیبانی کنند که به هیچ وجه قابل استفاده باشد.
شرکتCloudflare سابقه طولانی در ایجاد استانداردهای وب را دارد ، از HTTP / 2 (نسخه HTTP قبلی HTTP / 3) گرفته تا TLS 1.3 تا مواردی مانند SNI رمزگذاری شده. ما با همکاری با سازمانهای هم اندیشی که تمایل ما برای کمک به ایجاد یک اینترنت بهتر را دارند ، معیارها را به جلو سوق داده ایم. تلاشهای ما برای انتقال HTTP / 3 به جریان اصلی هیچ تفاوتی ندارد.
در طول فرآیند توسعه استانداردهای HTTP / 3 ، ما با همکاران صنعت همکاری کرده ایم تا پشتیبانی HTTP / 3 مشتری سازگار با پشتیبانی edgeخود را بسازیم و اعتبار دهیم. ما از این که Google Chrome و Curl به آن ملحق شده ایم ، بسیار هیجان زده ایم. هر دو مورد امروزه می توانند برای درخواست های Cloudflare از HTTP / 3 استفاده کنند. موزیلا فایرفاکس انتظار دارد به زودی پشتیبانی را نیز در یک نسخه شبانه ارسال کند.
همه اینها را با هم جمع کنید: امروز روز خوبی برای کاربران اینترنت است. پخش گسترده HTTP / 3 به معنای تجربه سریعتر وب برای همه خواهد بود ، و پشتیبانی امروز گامی بزرگ در این راه است.
مهمتر از همه ، امروز روز خوبی برای اینترنت است: Chrome ، Curl ، و Cloudflare و به زودی ، موزیلا ، با پشتیبانی آزمایشی اما کاربردی ، پشتیبانی از HTTP / 3 را در موفقیت سریع نشان می دهد که روند ایجاد استانداردهای اینترنت کار می کند. با هماهنگی کارگروه مهندسی اینترنت ، شرکای صنعت ، رقبا و سایر ذینفعان کلیدی می توانند برای تهیه استاندارد هایی که به نفع کل اینترنت باشد ، نه فقط در کلاهبرداری ها ، گردهم آیند.
اریک مدیر فایرفاکس ، آن را به طور خلاصه بیان کرد: "تهیه یک پروتکل جدید شبکه سخت است و گرفتن درست آن نیاز به همه دارد تا با هم همکاری کنند. در طی چند سال گذشته ، ما با Cloudflare و سایر شرکای صنعت همکاری کرده ایم تا TLS 1.3 و اکنون HTTP / 3 و QUIC را آزمایش کنیم. پشتیبانی اولیه Cloudflare از سمت سرور برای این پروتکل ها به ما کمک کرده است که عملکردهای عملیاتی را از اجرای Firefox در سمت مشتری خود خارج کنیم. ما مشتاقانه می خواهیم امنیت و عملکرد اینترنت را با هم پیش ببریم. "
قبل از اینکه عمیق تر به HTTP / 3 وارد شویم ، بیایید نگاهی سریع به تکامل HTTP در طی سالها بیندازیم تا درک بهتر از HTTP / 3 را داشته باشیم.
همه این موارد در سال 1996 با انتشار مشخصات HTTP / 1.0 آغاز شد و فرم اولیه سیم متنی HTTP را آنگونه که امروزه می شناسیم تعریف کرد (برای اهداف این پست وانمود می کنم HTTP / 0.9 هرگز وجود ندارد). در HTTP / 1.0 اتصال TCP جدیدی برای هر تبادل نظر درخواست / پاسخ بین مشتری و سرور ایجاد می شود ، بدین معنی که تمام درخواست ها مجازات تاخیری را متحمل می شوند زیرا عملکردهای TCP و TLS قبل از هر درخواست تکمیل می شوند.
از این بدتر ، به جای ارسال سریع تمام داده های برجسته به محض برقراری اتصال ، TCP یک دوره گرم شدن بنام "slow start" را اعمال می کند ، که به الگوریتم کنترل تراکم TCP اجازه می دهد تا مقدار داده هایی را که می توانند در پرواز باشند تعیین کنند. در هر لحظه قبل از وقوع احتقان در مسیر شبکه ، و از جاری شدن شبکه با بسته هایی که نمی توان از آن استفاده کرد جلوگیری کنید. اما از آنجا که اتصالات جدید باید روند شروع کند را طی کنند ، آنها نمی توانند بلافاصله از همه پهنای باند شبکه موجود استفاده کنند.
با بازنگری در مورد HTTP / 1.1 مشخصات HTTP ، چند سال بعد با معرفی مفهوم اتصالات "keep-alive" ، این مشکلات برطرف شد و به مشتریان امکان استفاده مجدد از اتصالات TCP داده می شود و بدین ترتیب هزینه برقراری اتصال اولیه را کم کرده و کند می کند. از چندین درخواست شروع کنید. اما این هیچ گلوله نقره ای نبود: در حالی که چندین درخواست می توانند یکسان باشند ، اما هنوز هم باید یکی پس از دیگری سریال شوند ، بنابراین یک مشتری و سرور می توانند تنها در هر زمان معینی برای هر اتصال ، یک درخواست / پاسخ صرافی را انجام دهند.
پروتکل HTTP / 2 مشکل اصلی - استفاده ناکارآمد از یک اتصال TCP واحد را حل می کند - از آنجا که چندین درخواست / پاسخ اکنون می توانند همزمان با همان اتصال منتقل شوند. با این حال ، تمام درخواست ها و پاسخ ها به همان اندازه در از دست دادن پکت ها (به عنوان مثال به دلیل تراکم شبکه) تحت تأثیر قرار می گیرند ، حتی اگر داده های از بین رفته فقط مربوط به یک درخواست واحد باشند. این امر به این دلیل است که در حالی که لایه HTTP / 2 می تواند مبادلات مختلف HTTP را در جریانهای جداگانه تفکیک کند ، TCP هیچ اطلاعی از این انتزاع ندارد و تمام آنچه می بیند ، جریانی از بایتها است که معنی خاصی ندارند.
نقش TCP این است که کل جریان بایت ها را به ترتیب صحیح ، از یک نقطه انتهایی به دیگری منتقل کند. هنگامی که یک بسته TCP حامل برخی از آن بایت ها در مسیر شبکه گم شد ، شکافی را در جریان ایجاد می کند و TCP هنگام بازگرداندن بسته آسیب دیده ، می تواند آن را پر کند. در ضمن انجام این کار ، هیچ یک از بایت های با موفقیت تحویل داده شده که از بین گمشده ها پیروی می کنند ، نمی توانند به برنامه تحویل داده شوند ، حتی اگر خودشان گم نشدند و به یک درخواست HTTP کاملاً مستقل تعلق دارند. بنابراین آنها در نهایت به تأخیر می افتند که TCP نمی داند آیا این برنامه قادر به پردازش آنها بدون بیت های گمشده است. این مشکل به عنوان "انسداد خط" شناخته شده است.
اینجاست که HTTP / 3 به مرحله اجرا در می آید: به جای استفاده از TCP به عنوان لایه حمل و نقل برای جلسه ، از QUIC ، یک پروتکل جدید حمل و نقل اینترنتی استفاده می کند ، که از جمله موارد دیگر ، جریان ها را به عنوان شهروندان درجه یک در لایه حمل و نقل معرفی می کند. جریان های QUIC با همان اتصال QUIC به اشتراک می گذارند ، بنابراین برای ایجاد موارد جدید دیگر نیازی به دست زدن و شروع آهسته نیست ، اما جریان های QUIC بطور مستقل تحویل می شوند به طوری که در بیشتر موارد از بین رفتن بسته ای که روی یک جریان تأثیر می گذارد ، روی دیگران تأثیر نمی گذارد. این امکان پذیر است زیرا بسته های QUIC در بالای داده های UDP محصور می شوند.
استفاده از UDP امکان انعطاف پذیری بسیار بیشتری را در مقایسه با TCP ایجاد می کند و پیاده سازی های QUIC را قادر می سازد تا کاملاً در فضای کاربر زندگی کنند - به روزرسانی های مربوط به پیاده سازی پروتکل با به روزرسانی سیستم عامل ها مطابق با TCP مرتبط نیست. با QUIC ، جریانهای سطح HTTP را می توان به سادگی در بالای جریانهای QUIC نقشه برداری کرد تا تمام مزایای HTTP / 2 را بدون مسدود کردن خط از آن به دست آورید.
پروتوکل QUIC همچنین ترکیبی از دستی سه بعدی TCP را با استفاده از لرزش TLS 1.3 در اختیار شما قرار می دهد. ترکیب این مراحل بدان معنی است که رمزگذاری و تأیید اعتبار به صورت پیش فرض ارائه می شود ، و همچنین امکان برقراری اتصال سریعتر را فراهم می کند. به عبارت دیگر ، حتی هنگامی که یک اتصال QUIC جدید برای درخواست اولیه در یک جلسه HTTP لازم باشد ، تأخیر قبل از شروع جریان داده ها کمتر از TCP با TLS است.
اما چرا فقط به جای ایجاد یک نسخه کامل جدید HTTP ، از HTTP / 2 در بالای QUIC استفاده نمی کنیم؟ از این گذشته ، HTTP / 2 ویژگی چند برابر کننده جریان را نیز ارائه می دهد. به نظر می رسد ، پیچیده تر از آن است.
اگرچه صحیح است که بعضی از ویژگی های HTTP / 2 را می توان در بالای QUIC به راحتی نقشه برداری کرد ، در مورد همه آنها صادق نیست. به خصوص ، طرح فشرده سازی هدر HTTP / 2 به نام HPACK ، به شدت بستگی به نظمی دارد که در آن درخواست ها و پاسخ های مختلف HTTP به نقاط انتهایی تحویل می شود. QUIC ترتیب تحویل بایت را در جریانهای مجزا اعمال می کند ، اما سفارش در بین جریان های مختلف را تضمین نمی کند.
این رفتار نیاز به ایجاد یک طرح فشرده سازی هدر HTTP جدید با نام QPACK دارد که این مشکل را برطرف می کند اما نیاز به تغییراتی در نقشه برداری HTTP دارد. علاوه بر این ، برخی از ویژگی های ارائه شده توسط HTTP / 2 (مانند کنترل جریان در هر جریان) قبلاً توسط QUIC ارائه شده است ، بنابراین آنها برای از بین بردن پیچیدگی های غیر ضروری از پروتکل ، از HTTP / 3 حذف شدند.
پروتکلHTTP / 3 ، طراحی شده توسط یک کوئوی است.QUIC و HTTP / 3 استانداردهای بسیار هیجان انگیزی هستند ، وعده می دهند که بسیاری از کاستی های استانداردهای قبلی را برطرف کرده و در دوره جدیدی از عملکرد در وب را برطرف می کنند. بنابراین چگونه می توانیم از داکیومنت های استاندارد هیجان انگیز به اجرای کار برویم؟
پشتیبانی QUIC و HTTP / 3 از Cloudflare با استفاده از quiche ، اجرای منبع باز خود ماست که در Rust نوشته شده است.
