پروتکل QUIC در عمل: چگونه Uber آن را برای بهینه سازی عملکرد پیاده سازی کرد

تماشای پروتکل QUIC بسیار جالب است، به همین دلیل است که ما عاشق نوشتن در مورد آن هستیم. اما اگر انتشارات قبلی در مورد QUIC بیشتر از یک ماهیت تاریخی (در صورت تمایل، افسانه های محلی) و مادی بود، امروز ما خوشحالیم که ترجمه ای از نوع متفاوت را منتشر می کنیم - در مورد کاربرد واقعی پروتکل در سال 2019 صحبت خواهیم کرد. و این مربوط به زیرساخت های کوچک مستقر در یک گاراژ مشروط نیست، بلکه مربوط به Uber است که تقریباً در سراسر جهان فعالیت می کند. چگونه مهندسان این شرکت به تصمیم برای استفاده از QUIC در تولید رسیدند، چگونه آزمایش‌ها را انجام دادند و پس از تولید آن چه چیزی دیدند - زیر برش.

تصاویر قابل کلیک هستند از خواندن لذت ببرید!

Uber یک مقیاس جهانی است، یعنی 600 شهر حضور، که در هر یک از آنها برنامه کاملاً به اینترنت بی سیم بیش از 4500 اپراتور تلفن همراه متکی است. کاربران انتظار دارند که این برنامه نه تنها سریع، بلکه در زمان واقعی باشد - برای ارائه این، برنامه Uber به تأخیر کم و یک اتصال بسیار مطمئن نیاز دارد. افسوس، اما پشته HTTP / 2 در شبکه های بی سیم پویا و با اتلاف خوب عمل نمی کند. ما متوجه شدیم که در این مورد، عملکرد ضعیف به طور مستقیم با پیاده سازی TCP در هسته سیستم عامل ها مرتبط است.

برای حل مشکل اقدام کردیم QUIC، یک پروتکل مالتی پلکس کانال مدرن که به ما کنترل بیشتری بر عملکرد پروتکل انتقال می دهد. کارگروه در حال حاضر است IETF QUIC را استاندارد می کند HTTP / 3.

پس از آزمایش‌های گسترده، به این نتیجه رسیدیم که معرفی QUIC به برنامه ما باعث می‌شود تاخیرهای دم در مقایسه با TCP کمتر شود. ما شاهد کاهش 10 تا 30 درصدی ترافیک HTTPS در برنامه‌های راننده و مسافر بوده‌ایم. QUIC همچنین به ما کنترل سرتاسر بسته‌های کاربر را داد.

در این مقاله، ما تجربه خود را از بهینه سازی TCP برای برنامه های Uber با استفاده از پشته ای که از QUIC پشتیبانی می کند، به اشتراک می گذاریم.

وضعیت هنر: TCP

امروزه TCP پرکاربردترین پروتکل انتقال برای ارائه ترافیک HTTPS در اینترنت است. TCP یک جریان قابل اعتماد از بایت ها را فراهم می کند، بنابراین با ازدحام شبکه و تلفات لایه پیوند مقابله می کند. استفاده گسترده از TCP برای ترافیک HTTPS به دلیل فراگیر بودن اولی (تقریباً هر سیستم‌عامل حاوی TCP)، در دسترس بودن در اکثر زیرساخت‌ها (به عنوان مثال، متعادل‌کننده‌های بار، پراکسی‌های HTTPS و CDN) و عملکرد خارج از جعبه است. که تقریباً در اکثر سیستم عامل ها و شبکه ها در دسترس است.

اکثر کاربران از برنامه ما در حال حرکت استفاده می‌کنند و تاخیرهای دنباله TCP با نیازهای ترافیک HTTPS بلادرنگ ما فاصله زیادی داشت. به بیان ساده، کاربران در سراسر جهان این را تجربه کرده اند - شکل 1 تاخیر در شهرهای بزرگ را نشان می دهد:

شکل 1. تأخیرهای دم در شهرهای بزرگی که اوبر در آنجا فعالیت می کند متفاوت است.

اگرچه تأخیرها در شبکه های هند و برزیل بیشتر از ایالات متحده و بریتانیا بود، تأخیرهای دنباله به طور قابل توجهی بیشتر از میانگین تأخیرها هستند. و این حتی برای ایالات متحده و بریتانیا نیز صادق است.

عملکرد TCP در هوا

TCP برای ایجاد شده است سیم دار شبکه ها، یعنی با تاکید بر پیوندهای قابل پیش بینی. با این حال، بي سيم شبکه ها ویژگی ها و مشکلات خاص خود را دارند. اول، شبکه های بی سیم به دلیل تداخل و تضعیف سیگنال مستعد از دست دادن هستند. به عنوان مثال، شبکه های Wi-Fi به امواج مایکروویو، بلوتوث و سایر امواج رادیویی حساس هستند. شبکه های سلولی از از دست دادن سیگنال رنج می برند (راه گم کرده) به دلیل انعکاس / جذب سیگنال توسط اشیا و ساختمان ها و همچنین از دخالت از همسایه برج های سلولی. این منجر به مهم تر (4-10 برابر) و متنوع تر می شود تاخیر رفت و برگشت (RTT) و از دست دادن بسته در مقایسه با اتصال سیمی.

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

در نهایت، عملکرد شبکه سلولی بر اساس حامل، منطقه و زمان متفاوت است. در شکل 2، متوسط ​​تأخیرهای ترافیک HTTPS در سلول ها را در محدوده 2 کیلومتر جمع آوری کرده ایم. داده ها برای دو اپراتور بزرگ تلفن همراه در دهلی، هند جمع آوری شده است. همانطور که می بینید، عملکرد از سلولی به سلول دیگر متفاوت است. همچنین عملکرد یک اپراتور با عملکرد دوم متفاوت است. این تحت تأثیر عواملی مانند الگوهای ورود به شبکه، در نظر گرفتن زمان و مکان، تحرک کاربر، و همچنین زیرساخت شبکه، با در نظر گرفتن تراکم برج‌ها و نسبت انواع شبکه (LTE، 3G و غیره) است.

شکل 2. تاخیرها با استفاده از شعاع 2 کیلومتری به عنوان مثال. دهلی، هند

همچنین عملکرد شبکه های سلولی در طول زمان متفاوت است. شکل 3 میانگین تاخیر را بر اساس روز هفته نشان می دهد. ما همچنین تفاوت را در مقیاس کوچکتر مشاهده کردیم - ظرف یک روز و یک ساعت.

شکل 3. تاخیرهای دم می تواند در روزهای مختلف به طور قابل توجهی متفاوت باشد، اما برای یک اپراتور.

همه موارد فوق منجر به ناکارآمدی عملکرد TCP در شبکه های بی سیم می شود. با این حال، قبل از جستجوی جایگزین‌هایی برای TCP، می‌خواستیم درک روشنی در مورد نکات زیر ایجاد کنیم:

• آیا TCP مقصر اصلی تاخیرهای دم در برنامه های ما است؟
• آیا شبکه های مدرن دارای تاخیرهای رفت و برگشت قابل توجه و متنوع (RTT) هستند؟
• تاثیر RTT و ضرر بر عملکرد TCP چیست؟

تجزیه و تحلیل عملکرد TCP

برای درک چگونگی تجزیه و تحلیل عملکرد TCP، اجازه دهید به طور خلاصه به یاد بیاوریم که چگونه TCP داده ها را از یک فرستنده به یک گیرنده منتقل می کند. فرستنده ابتدا یک اتصال TCP را با انجام سه طرفه برقرار می کند دست دادن: فرستنده یک بسته SYN می فرستد، منتظر یک بسته SYN-ACK از گیرنده می ماند، سپس یک بسته ACK ارسال می کند. گذر دوم و سوم اضافی برای ایجاد یک اتصال TCP استفاده می شود. گیرنده دریافت هر بسته (ACK) را تأیید می کند تا از تحویل قابل اطمینان اطمینان حاصل شود.

اگر یک بسته یا ACK گم شود، فرستنده پس از یک بازه زمانی باز ارسال می کند (RTO، مهلت ارسال مجدد). RTO به صورت پویا بر اساس عوامل مختلفی مانند تأخیر RTT مورد انتظار بین فرستنده و گیرنده محاسبه می شود.

شکل 4. تبادل بسته از طریق TCP/TLS شامل مکانیزم ارسال مجدد است.

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

نتایج هر دو آزمایش با یکدیگر همخوانی داشت. ما تاخیر RTT بالا را دیدیم. مقادیر دم تقریباً 6 برابر مقدار متوسط ​​بود. میانگین حسابی تاخیر بیش از 1 ثانیه است. بسیاری از اتصالات از دست رفته بودند که باعث شد TCP 3,5٪ از تمام بسته ها را دوباره ارسال کند. در مناطق پر ازدحام مانند فرودگاه ها و ایستگاه های قطار 7 درصد ضرر داشته ایم. این نتایج بر خرد متعارفی که در شبکه های سلولی استفاده می شود، شک می کند طرح های پیشرفته انتقال مجدد به طور قابل توجهی تلفات در لایه انتقال را کاهش می دهد. در زیر نتایج آزمون برنامه "شبیه ساز" آمده است:

معیارهای شبکه
معانی

RTT، میلی ثانیه [50٪، 75٪، 95٪، 99٪]
[350 ، 425 ، 725 ، 2300]

اختلاف RTT، ثانیه
میانگین ~ 1,2 ثانیه

از دست دادن بسته در پیوندهای متناوب
میانگین ~ 3.5٪ (7٪ در مناطق شلوغ)

تقریباً نیمی از این اتصالات حداقل یک بسته از دست دادن داشتند که بیشتر آنها SYN و SYN-ACK بودند. اکثر پیاده سازی های TCP از مقدار RTO 1 ثانیه برای بسته های SYN استفاده می کنند که برای تلفات بعدی به طور تصاعدی افزایش می یابد. زمان بارگذاری برنامه می تواند افزایش یابد زیرا TCP برای برقراری اتصالات بیشتر طول می کشد.

در مورد بسته‌های داده، مقادیر بالای RTO، استفاده مفید از شبکه را در صورت وجود تلفات زمانی در شبکه‌های بی‌سیم به شدت کاهش می‌دهد. ما دریافتیم که میانگین زمان ارسال مجدد تقریباً 1 ثانیه با تاخیر دم تقریباً 30 ثانیه است. چنین تأخیر بالایی در لایه TCP باعث وقفه‌های زمانی HTTPS و درخواست‌های مجدد شده و تأخیر و ناکارآمدی شبکه را بیشتر افزایش می‌دهد.

در حالی که صدک 75 از RTT های اندازه گیری شده در منطقه 425 میلی ثانیه بود، صدک 75 برای TCP تقریبا 3 ثانیه بود. این نشان می دهد که از دست دادن باعث شده TCP 7-10 پاس برای انتقال موفقیت آمیز داده ها انجام دهد. این ممکن است به دلیل محاسبه ناکارآمد RTO، ناتوانی TCP در پاسخ سریع به از دست دادن آن باشد آخرین بسته ها در پنجره و ناکارآمدی الگوریتم کنترل ازدحام، که بین از دست دادن وایرلس و از دست دادن به دلیل ازدحام شبکه تمایز قائل نمی شود. در زیر نتایج آزمایشات تلفات TCP آورده شده است:

آمار از دست دادن بسته TCP
ارزش

درصد اتصالات با حداقل 1 بسته از دست دادن
٪۱۰۰

درصد اتصالات با تلفات در هنگام برقراری اتصال
٪۱۰۰

درصد اتصالات با از دست دادن در طول ارتباط
٪۱۰۰

توزیع تاخیر در ارسال مجدد، ثانیه [50٪، 75٪، 95٪، 99٪] [1، 2.8، 15، 28]

توزیع تعداد ارسال مجدد برای یک بسته یا بخش TCP
[1,3,6,7]

کاربرد QUIC

QUIC که در اصل توسط گوگل طراحی شده است یک پروتکل حمل و نقل مدرن چند رشته ای است که در بالای UDP اجرا می شود. QUIC در حال حاضر است فرآیند استانداردسازی (ما قبلاً نوشتیم که، همانطور که بود، دو نسخه از QUIC، کنجکاو وجود دارد می توانید لینک را دنبال کنید - تقریبا مترجم). همانطور که در شکل 5 نشان داده شده است، QUIC تحت HTTP/3 قرار گرفته است (در واقع، HTTP/2 در بالای QUIC، HTTP/3 است که اکنون به شدت استاندارد شده است). تا حدی جایگزین لایه‌های HTTPS و TCP می‌شود و از UDP برای تشکیل بسته‌ها استفاده می‌کند. QUIC فقط از انتقال امن داده پشتیبانی می کند زیرا TLS به طور کامل در QUIC تعبیه شده است.

شکل 5: QUIC تحت HTTP/3 اجرا می شود، جایگزین TLS که قبلا تحت HTTP/2 اجرا می شد.

در اینجا دلایلی وجود دارد که ما را متقاعد به استفاده از QUIC برای سخت کردن TCP کرد:

• برقراری اتصال 0-RTT. QUIC اجازه استفاده مجدد از مجوزهای اتصالات قبلی را می دهد و تعداد دست دادن های امنیتی را کاهش می دهد. در آینده TLS1.3 از 0-RTT پشتیبانی می کند، اما دست دادن XNUMX طرفه TCP همچنان مورد نیاز خواهد بود.
• غلبه بر انسداد HoL HTTP/2 از یک اتصال TCP برای هر کلاینت برای بهبود عملکرد استفاده می کند، اما این می تواند منجر به مسدود شدن HoL (سرخط) شود. QUIC مالتی پلکسی را ساده می کند و درخواست ها را به طور مستقل به برنامه ارائه می کند.
• کنترل اضافه بار QUIC در لایه برنامه قرار دارد و به روز رسانی الگوریتم اصلی حمل و نقل را که مدیریت ارسال را بر اساس پارامترهای شبکه (نرخ تلفات یا RTT) مدیریت می کند، آسان تر می کند. اکثر پیاده سازی های TCP از الگوریتم استفاده می کنند مکعب، که برای ترافیک حساس به تأخیر مطلوب نیست. الگوریتم های اخیراً توسعه یافته مانند BBR، شبکه را با دقت بیشتری مدل کنید و تاخیرها را بهینه کنید. QUIC به شما امکان می دهد از BBR استفاده کنید و این الگوریتم را به عنوان آن به روز کنید بهبود.
• جبران خسارت QUIC دو TLP را فراخوانی می کند (کاوشگر از دست دادن دم) قبل از شروع RTO - حتی زمانی که تلفات بسیار قابل توجه است. این با پیاده سازی TCP متفاوت است. TLP اکثراً آخرین بسته (یا بسته جدید در صورت وجود) را مجدداً ارسال می کند تا دوباره پر کردن سریع شروع شود. مدیریت تأخیرهای دنباله به ویژه برای نحوه کار Uber با شبکه مفید است، یعنی برای انتقال داده های کوتاه، اپیزودیک و حساس به تأخیر.
• ACK بهینه شده از آنجایی که هر بسته یک شماره سریال منحصر به فرد دارد، مشکلی وجود ندارد تمایزات بسته ها در حین ارسال مجدد آنها. بسته های ACK همچنین شامل زمان پردازش بسته و تولید ACK در سمت مشتری هستند. این ویژگی ها تضمین می کند که QUIC RTT را با دقت بیشتری محاسبه می کند. ACK در QUIC حداکثر 256 باند را پشتیبانی می کند NACK، به فرستنده کمک می کند تا در برابر هم زدن بسته ها انعطاف پذیرتر باشد و از بایت های کمتری در این فرآیند استفاده کند. ACK انتخابی (گونی) در TCP این مشکل را در همه موارد حل نمی کند.
• مهاجرت اتصال اتصالات QUIC با یک شناسه 64 بیتی شناسایی می شوند، به طوری که اگر مشتری آدرس های IP را تغییر دهد، شناسه اتصال قدیمی می تواند بدون وقفه در آدرس IP جدید استفاده شود. هنگامی که کاربر بین Wi-Fi و اتصالات تلفن همراه جابجا می شود، این یک روش بسیار رایج برای برنامه های تلفن همراه است.

جایگزین های QUIC

قبل از انتخاب QUIC، رویکردهای جایگزین را برای حل مشکل در نظر گرفتیم.

اول از همه، ما سعی کردیم TPC PoP (نقاط حضور) را برای پایان دادن به اتصالات TCP نزدیک به کاربران مستقر کنیم. اساساً، PoP ها اتصال TCP به دستگاه تلفن همراه را که به شبکه سلولی نزدیک تر است خاتمه می دهند و ترافیک را به زیرساخت اصلی باز می گرداند. با پایان دادن به TCP نزدیک تر، می توانیم به طور بالقوه RTT را کاهش دهیم و اطمینان حاصل کنیم که TCP به محیط های بی سیم پویا پاسخگوتر است. با این حال، آزمایش‌های ما نشان داده‌اند که بیشتر RTT و تلفات از شبکه‌های سلولی ناشی می‌شود و استفاده از PoP ها بهبود عملکرد قابل توجهی را ارائه نمی‌کند.

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

در نهایت، ما چندین پروتکل مبتنی بر UDP را ارزیابی کردیم که جریان ویدئو را عیب‌یابی می‌کنند - می‌خواستیم ببینیم که آیا این پروتکل‌ها در مورد ما کمک می‌کنند یا خیر. افسوس، آنها در بسیاری از تنظیمات امنیتی به شدت کمبود داشتند، و همچنین به یک اتصال TCP اضافی برای فراداده و اطلاعات کنترل نیاز داشتند.

تحقیقات ما نشان داده است که QUIC شاید تنها پروتکلی است که می تواند به مشکل ترافیک اینترنت کمک کند، در حالی که هم امنیت و هم عملکرد را در نظر می گیرد.

ادغام QUIC در پلتفرم

به منظور جاسازی موفقیت آمیز QUIC و بهبود عملکرد برنامه در اتصال ضعیف، ما پشته قدیمی (HTTP/2 روی TLS/TCP) را با پروتکل QUIC جایگزین کرده ایم. ما از کتابخانه شبکه استفاده کردیم کرونت از پروژه های کرومیوم، که حاوی نسخه اصلی پروتکل Google - gQUIC است. این پیاده سازی همچنین به طور مداوم در حال بهبود است تا از آخرین مشخصات IETF پیروی کند.

ما ابتدا Cronet را در برنامه های اندروید خود ادغام کردیم تا پشتیبانی QUIC را اضافه کنیم. ادغام به گونه ای انجام شد که هزینه مهاجرت را به حداقل برساند. به جای جایگزینی کامل پشته شبکه قدیمی که از کتابخانه استفاده می کرد OkHttp، ما Cronet را تحت چارچوب OkHttp API یکپارچه کرده ایم. با ادغام به این روش، از تغییر در تماس‌های شبکه خود (که استفاده می‌کنند بازپرداخت) در سطح API.

مشابه رویکرد اندروید، ما با رهگیری ترافیک HTTP از شبکه، Cronet را در برنامه‌های Uber iOS پیاده‌سازی کرده‌ایم. APIاستفاده كردن پروتکل NSURL. این انتزاع که توسط بنیاد iOS ارائه شده است، داده‌های URL خاص پروتکل را مدیریت می‌کند و تضمین می‌کند که می‌توانیم Cronet را در برنامه‌های iOS خود بدون هزینه‌های مهاجرت قابل توجهی ادغام کنیم.

تکمیل QUIC در متعادل کننده های Google Cloud

در سمت باطن، تکمیل QUIC توسط زیرساخت تعادل بار Google Cloud ارائه می شود که از آن استفاده می کند alt-svc هدرها در پاسخ ها برای پشتیبانی از QUIC. به طور کلی، متعادل کننده هدر alt-svc را به هر درخواست HTTP اضافه می کند و از قبل پشتیبانی QUIC را برای دامنه تأیید می کند. هنگامی که یک کلاینت Cronet یک پاسخ HTTP با این هدر دریافت می کند، از QUIC برای درخواست های بعدی HTTP به آن دامنه استفاده می کند. به محض اینکه متعادل کننده QUIC را تکمیل کرد، زیرساخت ما به صراحت این اقدام را از طریق HTTP2/TCP به مراکز داده ما ارسال می کند.

عملکرد: نتایج

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

آزمایش 1

تجهیزات برای آزمایش:

• دستگاه‌های تست اندروید با پشته‌های OkHttp و Cronet برای اطمینان از اینکه ما به ترتیب به ترافیک HTTPS از طریق TCP و QUIC اجازه می‌دهیم.
• یک سرور شبیه‌سازی مبتنی بر جاوا که سربرگ‌های HTTPS از همان نوع را در پاسخ‌ها ارسال می‌کند و دستگاه‌های سرویس گیرنده را برای دریافت درخواست‌ها از آنها بارگیری می‌کند.
• پراکسی های ابری که از نظر فیزیکی در نزدیکی هند قرار دارند تا اتصالات TCP و QUIC را خاتمه دهند. در حالی که برای خاتمه TCP از یک پروکسی معکوس استفاده کردیم NGINX، یافتن یک پروکسی معکوس منبع باز برای QUIC دشوار بود. ما خودمان با استفاده از پشته QUIC پایه Chromium و یک پروکسی معکوس برای QUIC ساختیم منتشر شده است در کروم به عنوان منبع باز است.

شکل 6. مجموعه تست جاده TCP در مقابل QUIC شامل دستگاه‌های Android با OkHttp و Cronet، پراکسی‌های ابری برای پایان دادن به اتصالات و یک سرور شبیه‌سازی بود.

آزمایش 2

وقتی Google QUIC را با آن در دسترس قرار داد Google Cloud Load Balancing، ما از همان موجودی استفاده کردیم، اما با یک تغییر: به جای NGINX، متعادل کننده های Google را برای پایان دادن به اتصالات TCP و QUIC از دستگاه ها و همچنین هدایت ترافیک HTTPS به سرور شبیه سازی گرفتیم. متعادل کننده ها در سراسر جهان توزیع شده اند، اما از نزدیک ترین سرور PoP به دستگاه (به لطف موقعیت جغرافیایی) استفاده می کنند.

شکل 7. در آزمایش دوم، ما می‌خواستیم تأخیر تکمیل TCP و QUIC را با هم مقایسه کنیم: با استفاده از Google Cloud و استفاده از پروکسی ابری خود.

در نتیجه، چندین مکاشفه در انتظار ما بود:

• خاتمه از طریق PoP عملکرد TCP را بهبود بخشید. از آنجایی که بالانس‌ها اتصالات TCP را نزدیک‌تر به کاربران خاتمه می‌دهند و بسیار بهینه می‌شوند، این امر منجر به کاهش RTT می‌شود که عملکرد TCP را بهبود می‌بخشد. و اگرچه QUIC کمتر تحت تأثیر قرار گرفت، اما همچنان از نظر کاهش تأخیرهای دم (10 تا 30 درصد) TCP را دور زد.
• دم ها تحت تاثیر قرار می گیرند انتقال شبکه (Hops). اگرچه پروکسی QUIC ما از دستگاه‌ها دورتر بود (تأخیر حدود 50 میلی‌ثانیه بیشتر) نسبت به بار متعادل‌کننده‌های Google، عملکرد مشابهی را ارائه می‌کرد - کاهش 15 درصدی تأخیر در مقابل کاهش 20 درصدی در صدک 99 برای TCP. این نشان می دهد که انتقال آخرین مایل یک گلوگاه در شبکه است.

شکل 8. نتایج دو آزمایش نشان می دهد که QUIC به طور قابل توجهی برتر از TCP است.

ترافیک جنگی

با الهام از آزمایش‌ها، ما پشتیبانی QUIC را در برنامه‌های Android و iOS خود پیاده‌سازی کرده‌ایم. ما آزمایش A/B را برای تعیین تأثیر QUIC در شهرهایی که Uber در آن فعالیت می‌کند، انجام دادیم. به طور کلی، ما شاهد کاهش قابل توجه تاخیر در هر دو منطقه و اپراتورهای مخابراتی و نوع شبکه بودیم.

نمودارهای زیر درصد بهبود در دم ها (صدک های 95 و 99) را بر اساس مناطق کلان و انواع مختلف شبکه - LTE، 3G، 2G نشان می دهد.

شکل 9. QUIC از TCP در تأخیر در آزمایش های رزمی بهتر عمل کرد.

فقط رو به جلو

شاید این تازه آغاز راه باشد - عرضه QUIC به تولید فرصت های شگفت انگیزی را برای بهبود عملکرد برنامه در شبکه های پایدار و ناپایدار فراهم کرده است، یعنی:

افزایش پوشش

پس از تجزیه و تحلیل عملکرد پروتکل در ترافیک واقعی، دیدیم که تقریباً 80٪ از جلسات با موفقیت از QUIC برای از همه درخواست ها، در حالی که 15٪ از جلسات از ترکیب QUIC و TCP استفاده می کردند. ما فرض می‌کنیم که این ترکیب به دلیل بازگشت کتابخانه Cronet به TCP در یک بازه زمانی است، زیرا نمی‌تواند بین خرابی‌های واقعی UDP و شرایط بد شبکه تمایز قائل شود. ما در حال حاضر به دنبال راه حلی برای این مشکل هستیم زیرا در حال کار بر روی اجرای بعدی QUIC هستیم.

بهینه سازی QUIC

ترافیک برنامه‌های تلفن همراه به تأخیر حساس است، اما به پهنای باند حساس نیست. همچنین، برنامه های ما عمدتا در شبکه های سلولی استفاده می شود. بر اساس آزمایش‌ها، عقب‌ماندگی‌های دنباله همچنان زیاد هستند، حتی اگر از پروکسی‌ها برای پایان دادن به TCP و QUIC نزدیک به کاربران استفاده شود. ما فعالانه به دنبال راه‌هایی برای بهبود مدیریت ازدحام و افزایش کارایی الگوریتم‌های بازیابی خسارت QUIC هستیم.

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

منبع: www.habr.com