HTTP/3: شکستن زمین و دنیای جدید شجاع

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

کمی تاریخچه: HTTP/1.1

در سال 1997، پروتکل تبادل اطلاعات متنی HTTP نسخه 1.1 RFC خود را به دست آورد. در آن زمان، این پروتکل برای چندین سال توسط مرورگرها استفاده می شد و استاندارد جدید پانزده سال دیگر ادامه داشت. این پروتکل فقط بر اساس اصل درخواست-پاسخ کار می کرد و عمدتاً برای انتقال اطلاعات متنی در نظر گرفته شده بود.

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

در HTTP/1.0، اتصال TCP بعد از هر درخواست بسته می شد. این بسیار بیهوده بود، زیرا ... ایجاد یک اتصال TCP (3-Way-Handshake) یک فرآیند کند است. HTTP/1.1 مکانیزم نگه داشتن زنده را معرفی کرد که به شما امکان می دهد از یک اتصال برای چندین درخواست استفاده مجدد کنید. با این حال، از آنجایی که به راحتی می‌تواند به یک گلوگاه تبدیل شود، پیاده‌سازی‌های مختلف HTTP/1.1 اجازه می‌دهد چندین اتصال TCP به یک میزبان باز شود. به عنوان مثال، کروم و نسخه های اخیر فایرفاکس تا شش اتصال را امکان پذیر می کنند.

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

تصویر Cloudflare

بنابراین HTTP/1.1 تعدادی مشکلات داشت:

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

اگر سرور-فشار حداقل با استفاده از پروتکل WebSocket پیاده‌سازی شود، باید با مشکلات باقی‌مانده به‌طور اساسی‌تر برخورد کرد.

کمی مدرنیته: HTTP/2

در سال 2012، گوگل کار بر روی پروتکل SPDY (تلفظ "سریع") را آغاز کرد. این پروتکل برای حل مشکلات اصلی HTTP/1.1 طراحی شده بود و در عین حال قرار بود سازگاری با عقب را حفظ کند. در سال 2015، گروه کاری IETF مشخصات HTTP/2 را بر اساس پروتکل SPDY معرفی کرد. در اینجا تفاوت های HTTP/2 وجود دارد:

• سریال سازی باینری
• چند پلکس کردن چندین درخواست HTTP در یک اتصال TCP.
• سرور را از جعبه خارج کنید (بدون WebSocket).

پروتکل گام بزرگی به جلو بود. او به شدت از نظر سرعت نسخه اول را شکست می دهد و نیازی به ایجاد چندین اتصال TCP ندارد: همه درخواست ها به یک میزبان در یک مالتی پلکس می شوند. یعنی در یک اتصال چندین جریان به اصطلاح وجود دارد که هر کدام شناسه مخصوص به خود را دارند. پاداش یک فشار سرور جعبه ای است.

با این حال، مالتی پلکس منجر به مشکل کلیدی دیگری می شود. تصور کنید که ما به طور ناهمزمان 5 درخواست را برای یک سرور اجرا می کنیم. هنگام استفاده از HTTP/2، همه این درخواست‌ها در همان اتصال TCP انجام می‌شوند، به این معنی که اگر یکی از بخش‌های هر درخواست گم شود یا اشتباه دریافت شود، انتقال همه درخواست‌ها و پاسخ‌ها متوقف می‌شود تا زمانی که بخش از دست رفته قطع شود. بازسازی شد. بدیهی است که هر چه کیفیت اتصال بدتر باشد، HTTP/2 کندتر کار می کند. به گفته دانیل استنبرگدر شرایطی که بسته‌های از دست رفته 2 درصد از کل بسته‌ها را تشکیل می‌دهند، HTTP/1.1 در مرورگر بهتر از HTTP/2 عمل می‌کند، زیرا به جای یک اتصال، 6 اتصال را باز می‌کند.

به این مشکل "مسدود کردن سر خط" می گویند و متاسفانه در هنگام استفاده از TCP امکان حل آن وجود ندارد.

تصویر توسط دانیل اشتاینبرگ

در نتیجه، توسعه دهندگان استاندارد HTTP/2 کار بزرگی انجام دادند و تقریباً هر کاری را که در لایه کاربردی مدل OSI می‌توان انجام داد، انجام دادند. وقت آن است که به لایه انتقال بروید و یک پروتکل حمل و نقل جدید اختراع کنید.

ما به یک پروتکل جدید نیاز داریم: UDP در مقابل TCP

خیلی سریع مشخص شد که پیاده‌سازی یک پروتکل لایه انتقال کاملاً جدید در واقعیت‌های امروزی یک کار غیرممکن است. واقعیت این است که سخت افزار یا جعبه های میانی (روترها، فایروال ها، سرورهای NAT...) در مورد لایه انتقال اطلاعات دارند و آموزش چیزهای جدید به آنها کار بسیار دشواری است. علاوه بر این، پشتیبانی از پروتکل های انتقال به هسته سیستم عامل ها متصل می شود و هسته ها نیز تمایل زیادی به تغییر ندارند.

و در اینجا می‌توان دست‌های خود را بالا برد و گفت: «البته، ما یک HTTP/3 جدید را با اولویت و با محبت اختراع خواهیم کرد، اما پیاده‌سازی آن 10 تا 15 سال طول می‌کشد (تقریباً پس از این مدت، اکثر سخت‌افزارها جایگزین شده است)، اما یک گزینه دیگر وجود دارد که اینطور نیست. گزینه واضح استفاده از پروتکل UDP است. بله، بله، همان پروتکلی که در اواخر دهه نود و اوایل دهه XNUMX برای پرتاب فایل ها روی LAN استفاده می کردیم. تقریباً تمام سخت افزارهای امروزی می توانند با آن کار کنند.

مزایای UDP نسبت به TCP چیست؟ اول از همه، ما جلسه لایه انتقالی نداریم که سخت افزار از آن اطلاع داشته باشد. این به ما این امکان را می دهد که خودمان جلسه را در نقاط پایانی تعیین کنیم و تضادها را در آنجا حل کنیم. به این معنا که ما محدود به یک یا چند جلسه (مانند TCP) نیستیم، بلکه می توانیم به تعداد مورد نیاز از آنها ایجاد کنیم. ثانیا، انتقال داده از طریق UDP سریعتر از TCP است. بنابراین، در تئوری، می‌توانیم از سقف سرعت فعلی به‌دست‌آمده در HTTP/2 عبور کنیم.

با این حال، UDP انتقال داده قابل اعتماد را تضمین نمی کند. در واقع، ما به سادگی بسته هایی را ارسال می کنیم، به این امید که طرف دیگر آنها را دریافت کند. دریافت نکرده اند؟ خوب، شانسی نیست... این برای انتقال ویدیو برای بزرگسالان کافی بود، اما برای چیزهای جدی تر به قابلیت اطمینان نیاز دارید، به این معنی که باید چیز دیگری را در بالای UDP قرار دهید.

همانند HTTP/2، کار روی ایجاد یک پروتکل جدید در گوگل در سال 2012 آغاز شد، یعنی تقریباً همزمان با شروع کار روی SPDY. در سال 2013، جیم راسکیند به عموم مردم ارائه شد پروتکل QUIC (اتصالات سریع UDP اینترنت).و قبلاً در سال 2015 پیش نویس اینترنت برای استانداردسازی در IETF معرفی شد. قبلاً در آن زمان، پروتکل توسعه یافته توسط Roskind در Google بسیار متفاوت از استاندارد بود، بنابراین نسخه Google شروع به نامگذاری gQUIC کرد.

QUIC چیست

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

تصویر توسط دانیل اشتاینبرگ

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

ثالثاً، مفهوم جریان نور به شما امکان می دهد تا اتصال را از آدرس IP مشتری جدا کنید. این مهم است، به عنوان مثال، زمانی که یک کلاینت از یک نقطه دسترسی Wi-Fi به نقطه دیگر سوئیچ می کند و IP خود را تغییر می دهد. در این مورد، هنگام استفاده از TCP، یک فرآیند طولانی رخ می دهد که در طی آن زمان اتصالات TCP موجود به پایان می رسد و اتصالات جدید از یک IP جدید ایجاد می شود. در مورد QUIC، مشتری به سادگی به ارسال بسته ها به سرور از یک IP جدید با شناسه جریان قدیمی ادامه می دهد. زیرا شناسه جریان اکنون منحصربه‌فرد است و مجدداً استفاده نمی‌شود؛ سرور متوجه می‌شود که مشتری IP را تغییر داده است، بسته‌های گمشده را دوباره ارسال می‌کند و به ارتباط در آدرس جدید ادامه می‌دهد.

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

و در نهایت سرفصل ها. فشرده سازی هدر یکی از مواردی است که بین QUIC و gQUIC متفاوت است. اختصاص زمان زیادی به این موضوع را فایده ای نمی بینم، فقط می گویم که در نسخه ارائه شده برای استانداردسازی، فشرده سازی هدر تا حد امکان شبیه به فشرده سازی هدر در HTTP/2 ساخته شده است. می توانید بیشتر بخوانید اینجا.

چقدر سریعتر است؟

سوال سختی است. واقعیت این است که تا زمانی که استاندارد نداشته باشیم چیز خاصی برای اندازه گیری وجود ندارد. شاید تنها آماری که داریم آماری از گوگل باشد که از سال 2013 و در سال 2016 از gQUIC استفاده کرده است. به IETF گزارش شدکه حدود 90٪ از ترافیکی که از مرورگر کروم به سرورهای آنها می رود اکنون از QUIC استفاده می کند. در همان ارائه، آنها گزارش دادند که صفحات در حدود 5٪ سریعتر از طریق gQUIC بارگیری می شوند و 30٪ لکنت کمتری در جریان ویدئو در مقایسه با TCP وجود دارد.

در سال 2017 گروهی از محققان به سرپرستی آرش مولوی کاخکی منتشر کردند کارت عالی بود برای مطالعه عملکرد gQUIC در مقایسه با TCP.
این مطالعه چندین ضعف gQUIC را نشان داد، مانند ناپایداری در اختلاط بسته‌های شبکه، حریص (ناعادلانه) برای پهنای باند کانال و انتقال کندتر اشیاء کوچک (تا 10 کیلوبایت). با این حال، دومی را می توان با استفاده از 0-RTT جبران کرد. در سایر موارد مورد مطالعه، gQUIC افزایش سرعت را در مقایسه با TCP نشان داد. در اینجا صحبت در مورد اعداد خاص دشوار است. بهتره بخون خود مطالعه یا پست کوتاه.

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

کمی از آینده: HTTP/3 چطور؟

اما در اینجا همه چیز کاملاً واضح است: API به هیچ وجه تغییر نخواهد کرد. همه چیز دقیقاً همان چیزی است که در HTTP/2 بود. خوب، اگر API ثابت بماند، انتقال به HTTP/3 باید با استفاده از نسخه جدیدی از کتابخانه در باطن که از انتقال QUIC پشتیبانی می‌کند، حل شود. درست است، شما باید نسخه های قدیمی HTTP را برای مدتی طولانی نگه دارید، زیرا اینترنت در حال حاضر برای انتقال کامل به UDP آماده نیست.

که قبلاً حمایت می کند

در اینجا این است فهرست پیاده سازی های QUIC موجود با وجود عدم وجود استاندارد، لیست بد نیست.

در حال حاضر هیچ مرورگری از QUIC در نسخه تولیدی پشتیبانی نمی کند. اخیراً اطلاعاتی مبنی بر اینکه پشتیبانی از HTTP/3 در کروم گنجانده شده بود، وجود داشت، اما تاکنون فقط در Canary.

از میان پشتیبان ها، HTTP/3 فقط پشتیبانی می کند توپ تنیس и CloudFlare را، اما هنوز آزمایشی است. NGINX در پایان بهار 2019 اعلام کرد، که آنها شروع به کار بر روی پشتیبانی HTTP/3 کردند، اما هنوز آن را به پایان نرسانده اند.

مشکلات چیست؟

من و شما در دنیای واقعی زندگی می کنیم، جایی که هیچ فناوری بزرگی نمی تواند بدون مواجهه با مقاومت به توده ها برسد، و QUIC نیز از این قاعده مستثنی نیست.

مهمترین چیز این است که باید به نوعی به مرورگر توضیح دهید که "https://" دیگر یک واقعیت نیست که به پورت TCP 443 منتهی می شود. ممکن است اصلا TCP وجود نداشته باشد. برای این کار از هدر Alt-Svc استفاده می شود. به شما امکان می دهد به مرورگر بگویید که این وب سایت در فلان پروتکل در فلان آدرس نیز موجود است. در تئوری، این باید مانند یک جذابیت عمل کند، اما در عمل با این واقعیت مواجه خواهیم شد که برای مثال، UDP را می‌توان در فایروال ممنوع کرد تا از حملات DDoS جلوگیری شود.

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

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

علاوه بر این، همانطور که قبلاً توضیح داده شد، QUIC استفاده از CPU را تا حد زیادی افزایش می دهد. دانیل استنبرگ استقبال مینماید رشد پردازنده تا سه برابر

چه زمانی HTTP/3 وارد می شود؟

استاندارد می خواهند بپذیرند تا می 2020، اما با توجه به اینکه اسناد برنامه ریزی شده برای ژوئیه 2019 در حال حاضر ناتمام مانده است، می توان گفت که تاریخ به احتمال زیاد به عقب کشیده خواهد شد.

خوب، گوگل از سال 2013 از پیاده سازی gQUIC خود استفاده می کند. اگر به درخواست HTTP که به موتور جستجوی گوگل ارسال شده است نگاه کنید، این را خواهید دید:

یافته ها

اکنون QUIC یک فناوری نسبتاً خام، اما بسیار امیدوارکننده به نظر می رسد. با توجه به اینکه در 20 سال گذشته، تمام بهینه‌سازی‌های پروتکل‌های لایه انتقال عمدتاً مربوط به TCP، QUIC بوده است که در بیشتر موارد بهترین عملکرد را دارد، در حال حاضر بسیار خوب به نظر می‌رسد.

با این حال، هنوز مشکلات حل نشده ای وجود دارد که باید در چند سال آینده با آنها برخورد کرد. ممکن است به دلیل وجود سخت افزاری که هیچ کس دوست ندارد آن را به روز کند، روند به تعویق بیفتد، اما با این وجود، همه مشکلات کاملاً قابل حل به نظر می رسند و دیر یا زود همه ما HTTP/3 خواهیم داشت.

آینده نزدیک است!

منبع: www.habr.com