פרוטוקול QUIC בפעולה: איך אובר הטמיעה אותו כדי לייעל את הביצועים

פרוטוקול QUIC מעניין מאוד לצפייה, וזו הסיבה שאנחנו אוהבים לכתוב עליו. אבל אם פרסומים קודמים על QUIC היו יותר אופי וחומר היסטורי (מקומי, אם תרצו), היום אנו שמחים לפרסם תרגום מסוג אחר - נדבר על היישום בפועל של הפרוטוקול ב-2019. ולא מדובר על תשתית קטנה המבוססת במוסך מותנה, אלא על אובר, שפועלת כמעט בכל העולם. איך הגיעו מהנדסי החברה להחלטה להשתמש ב-QUIC בייצור, איך הם ערכו את הבדיקות ומה הם ראו לאחר שגלגלו אותו לייצור - תחת החתך.

התמונות ניתנות ללחיצה. קריאה מהנה!

Uber היא קנה מידה עולמי, כלומר 600 ערים של נוכחות, שבכל אחת מהן האפליקציה מסתמכת באופן מלא על אינטרנט אלחוטי של יותר מ-4500 מפעילי סלולר. המשתמשים מצפים שהאפליקציה תהיה לא רק מהירה, אלא בזמן אמת - כדי לספק זאת, אפליקציית Uber זקוקה להשהיה נמוכה וחיבור אמין מאוד. אבוי, אבל הערימה HTTP / 2 אינו מתפקד היטב ברשתות אלחוטיות דינמיות וחסרות אובדן. מצאנו שבמקרה זה, ביצועים גרועים קשורים ישירות להטמעות של TCP בקרנלים של מערכות הפעלה.

כדי לפתור את הבעיה, הגשנו בקשה QUIC, פרוטוקול ריבוי ערוצים מודרני שנותן לנו שליטה רבה יותר על הביצועים של פרוטוקול התחבורה. כרגע קבוצת העבודה IETF תקן QUIC as HTTP / 3.

לאחר בדיקות מקיפות, הגענו למסקנה שהכנסת QUIC לאפליקציה שלנו תצמצם את זמן האחזור של הזנב בהשוואה ל-TCP. ראינו ירידה בטווח של 10-30% עבור תעבורת HTTPS באפליקציית הנהג והנוסעים. QUIC גם נתן לנו שליטה מקצה לקצה על חבילות משתמש.

במאמר זה, אנו חולקים את הניסיון שלנו באופטימיזציה של TCP עבור יישומי Uber באמצעות מחסנית שתומכת ב-QUIC.

מצב האומנות: TCP

כיום, TCP הוא פרוטוקול התחבורה הנפוץ ביותר לאספקת תעבורת HTTPS באינטרנט. TCP מספק זרם אמין של בתים, ובכך מתמודד עם עומס ברשת ואובדן שכבת קישור. השימוש הנרחב ב-TCP עבור תעבורת HTTPS נובע מהנוכחות של הראשונה (כמעט כל מערכת הפעלה מכילה TCP), זמינות ברוב התשתיות (לדוגמה, מאזני עומסים, פרוקסי HTTPS ו-CDNs), ופונקציונליות מחוץ לקופסה. זה זמין כמעט ברוב הפלטפורמות והרשתות.

רוב המשתמשים משתמשים באפליקציה שלנו בדרכים, ועיכובי זנב של 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 מהערך החציוני; הממוצע האריתמטי של העיכובים הוא יותר משנייה אחת. חיבורים רבים היו אובדים, מה שגרם ל-TCP לשדר מחדש 1% מכל החבילות. באזורים צפופים כמו שדות תעופה ותחנות רכבת, ראינו הפסדים של 3,5%. תוצאות אלו מטילות ספק בחוכמה המקובלת שבה משתמשים ברשתות סלולריות תוכניות שידור חוזר מתקדמות להפחית באופן משמעותי את ההפסדים בשכבת ההובלה. להלן תוצאות הבדיקה מאפליקציית "סימולטור":

מדדי רשת
משמעויות

RTT, אלפיות שניות [50%,75%, 95%,99%]
[350, 425, 725, 2300]

סטיית RTT, שניות
ממוצע ~1,2 שניות

אובדן מנות על קישורים לסירוגין
ממוצע של ~3.5% (7% באזורים צפופים)

כמעט למחצית מהחיבורים הללו היו לפחות אובדן מנות אחד, בעיקר SYN ו-SYN-ACKs. רוב יישומי TCP משתמשים ב-RTO של שנייה אחת עבור מנות SYN, אשר גדל באופן אקספוננציאלי עבור הפסדים הבאים. זמני הטעינה של האפליקציה יכולים לעלות מכיוון של-TCP לוקח יותר זמן ליצור חיבורים.

במקרה של מנות נתונים, ערכי RTO גבוהים מפחיתים מאוד את הניצול השימושי של הרשת בנוכחות הפסדי זמן ברשתות אלחוטיות. גילינו שזמן השידור החוזר הממוצע הוא בערך שנייה אחת עם השהיית זנב של כמעט 1 שניות. זמן השהייה כה גבוה בשכבת ה-TCP גרם לפסקי זמן של HTTPS ולבקשות ניסיון חוזר, והגדיל עוד יותר את זמן האחזור וחוסר היעילות של הרשת.

בעוד שהאחוזון ה-75 של RTT שנמדד היה סביב 425 אלפיות השנייה, האחוזון ה-75 עבור TCP היה כמעט 3 שניות. זה מרמז שהאובדן גרם ל-TCP לקחת 7-10 מעברים כדי להעביר נתונים בהצלחה. זה עשוי להיות תוצאה של חישוב RTO לא יעיל, חוסר היכולת של TCP להגיב במהירות לאובדן החבילות האחרונות בחלון וחוסר היעילות של אלגוריתם בקרת הגודש, שאינו מבחין בין אובדן אלחוטי לבין אובדן עקב עומס ברשת. להלן התוצאות של בדיקות אובדן TCP:

סטטיסטיקות של אובדן מנות של TCP
ערך

אחוז החיבורים עם אובדן מנה אחת לפחות
45%

אחוז החיבורים עם הפסדים במהלך יצירת החיבור
30%

אחוז החיבורים עם אובדן במהלך חילופי נתונים
76%

התפלגות העיכובים בשידור חוזר, שניות [50%, 75%, 95%, 99%] [1, 2.8, 15, 28]

התפלגות מספר השידורים החוזרים עבור מנה אחת או קטע TCP אחד
[1,3,6,7]

יישום של QUIC

תוכנן במקור על ידי Google, 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, אך עדיין תידרש לחיצת היד התלת-כיוונית של TCP.
• התגברות על חסימת HoL. HTTP/2 משתמש בחיבור TCP אחד לכל לקוח כדי לשפר את הביצועים, אבל זה יכול להוביל לחסימת HoL (head-of-line). QUIC מפשט ריבוי ומעביר בקשות לאפליקציה באופן עצמאי.
• בקרת צפיפות. QUIC שוכן בשכבת האפליקציה, מה שמקל על עדכון אלגוריתם התעבורה הראשי השולט על השליחה על סמך פרמטרי רשת (מספר הפסדים או RTT). רוב יישומי TCP משתמשים באלגוריתם מְעוּקָב, שאינו אופטימלי עבור תעבורה רגישה לזמן השהייה. אלגוריתמים שפותחו לאחרונה כמו BBR, דגם את הרשת בצורה מדויקת יותר וייעל עיכובים. QUIC מאפשר לך להשתמש ב-BBR ולעדכן את האלגוריתם הזה כפי שהוא הַשׁבָּחָה.
• חידוש הפסדים. QUIC קורא לשני TLPs (בדיקה לאובדן זנב) לפני שה-RTO נכנס - גם כשההפסדים בולטים מאוד. זה שונה מיישומי TCP. TLP משדר מחדש בעיקר את החבילה האחרונה (או את החדשה אם יש כזו) כדי להתחיל מילוי מהיר. טיפול בעיכובים זנב שימושי במיוחד עבור האופן שבו Uber עובדת עם הרשת, כלומר עבור העברות נתונים קצרות, אפיזודיות ורגישות עיכוב.
• ACK מותאם. מכיוון שלכל חבילה יש מספר סידורי ייחודי, אין בעיה הבחנות מנות בזמן שידורן מחדש. חבילות ACK מכילות גם זמן לעיבוד החבילה ויצירת ACK בצד הלקוח. תכונות אלו מבטיחות ש-QUIC מחשב RTT בצורה מדויקת יותר. ACK ב-QUIC תומך בעד 256 פסים NACK, עוזר לשולח להיות עמיד יותר לערבוב מנות ולהשתמש בפחות בתים בתהליך. ACK סלקטיבי (סאק) ב-TCP אינו פותר את הבעיה הזו בכל המקרים.
• העברת חיבורים. חיבורי QUIC מזוהים עם מזהה של 64 סיביות כך שאם לקוח משנה כתובות IP, מזהה החיבור הישן יכול להמשיך לשמש בכתובת ה-IP החדשה ללא הפרעה. זהו נוהג נפוץ מאוד עבור אפליקציות לנייד כאשר משתמש עובר בין Wi-Fi וחיבורים סלולריים.

חלופות ל-QUIC

שקלנו גישות חלופיות לפתרון הבעיה לפני שבחרנו ב-QUIC.

קודם כל, ניסינו לפרוס TPC PoPs (נקודות נוכחות) כדי לסיים את חיבורי TCP קרוב יותר למשתמשים. בעיקרו של דבר, PoPs מפסיקים את חיבור ה-TCP למכשיר הנייד הקרוב יותר לרשת הסלולרית ומעבירים את התעבורה בחזרה לתשתית המקורית. על ידי סיום קרוב יותר של TCP, נוכל להפחית את ה-RTT ולהבטיח ש-TCP מגיב יותר לסביבות אלחוטיות דינמיות. עם זאת, הניסויים שלנו הראו שרוב ה-RTT וההפסד מגיעים מרשתות סלולריות ושימוש ב-PoPs אינו מספק שיפור משמעותי בביצועים.

בדקנו גם כוונון פרמטרי TCP. הגדרת מחסנית ה-TCP על שרתי הקצה ההטרוגניים שלנו הייתה קשה, מכיוון של-TCP יש יישומים שונים בגרסאות מערכת ההפעלה. היה קשה ליישם ולבדוק תצורות רשת שונות. הגדרת TCP ישירות במכשירים ניידים לא הייתה אפשרית עקב חוסר הרשאות. חשוב מכך, תכונות כמו חיבורי 0-RTT וחיזוי RTT משופר הם קריטיים לארכיטקטורת הפרוטוקול ולכן לא ניתן להשיג יתרונות משמעותיים על ידי כוונון TCP בלבד.

לבסוף, הערכנו מספר פרוטוקולים מבוססי UDP הפותרים בעיות בהזרמת וידאו - רצינו לראות אם הפרוטוקולים האלה יעזרו במקרה שלנו. למרבה הצער, הם היו חסרים מאוד בהגדרות אבטחה רבות, והם גם דרשו חיבור TCP נוסף עבור מטא נתונים ומידע בקרה.

המחקר שלנו הראה ש-QUIC הוא אולי הפרוטוקול היחיד שיכול לעזור בבעיית תעבורת האינטרנט, תוך התחשבות הן באבטחה והן בביצועים.

שילוב של QUIC בפלטפורמה

על מנת להטמיע בהצלחה QUIC ולשפר את ביצועי האפליקציה בקישוריות לקויה, החלפנו את המחסנית הישנה (HTTP/2 על TLS/TCP) בפרוטוקול QUIC. השתמשנו בספריית הרשת קרונט של פרויקטים של Chromium, המכיל את הגרסה המקורית של הפרוטוקול של Google - gQUIC. יישום זה גם נמצא בשיפור מתמיד כדי לעקוב אחר מפרט ה-IETF העדכני ביותר.

תחילה שילבנו את Cronet באפליקציות האנדרואיד שלנו כדי להוסיף תמיכת QUIC. האינטגרציה בוצעה בצורה כזו שתמזער את עלות ההגירה. במקום להחליף לחלוטין את ערימת הרשת הישנה שהשתמשה בספרייה OkHttp, שילבנו את Cronet תחת המסגרת של OkHttp API. על ידי שילוב בדרך זו, נמנענו משינויים בשיחות הרשת שלנו (אשר משתמשות הרהיטים חדשים) ברמת ה-API.

בדומה לגישת אנדרואיד, הטמענו את Cronet באפליקציות Uber iOS על ידי יירוט תעבורת HTTP מהרשת APIבאמצעות פרוטוקול NSURL. הפשטה זו, המסופקת על ידי קרן iOS, מטפלת בנתוני כתובת URL ספציפיים לפרוטוקול ומבטיחה שנוכל לשלב את Cronet ביישומי iOS שלנו ללא עלויות הגירה משמעותיות.

השלמת QUIC על מאזני Google Cloud

בצד האחורי, השלמת QUIC מסופקת על ידי תשתית איזון עומסי הענן של Google, המשתמשת alt-svc כותרות בתגובות לתמיכה ב-QUIC. באופן כללי, המאזן מוסיף את הכותרת alt-svc לכל בקשת HTTP והוא כבר מאמת את תמיכת QUIC עבור התחום. כאשר לקוח Cronet מקבל תגובת HTTP עם כותרת זו, הוא משתמש ב-QUIC עבור בקשות HTTP עוקבות לאותו תחום. ברגע שהמאזן משלים QUIC, התשתית שלנו שולחת את הפעולה הזו במפורש דרך HTTP2/TCP למרכזי הנתונים שלנו.

ביצועים: תוצאות

ביצועי הפלט הם הסיבה העיקרית לחיפוש שלנו אחר הפרוטוקול הטוב ביותר. מלכתחילה יצרנו דוכן עם אמולציית רשתכדי לגלות כיצד QUIC יתנהג עם פרופילי רשת שונים. כדי לבדוק כיצד QUIC עובד ברשתות אמיתיות, הרצנו ניסויים בנסיעה ברחבי ניו דלהי תוך שימוש בתעבורת רשת מדומה, בדומה לשיחות HTTP באפליקציית נוסעים.

ניסוי 1

ציוד לניסוי:

• מכשירי בדיקת אנדרואיד עם ערימות OkHttp ו- Cronet כדי לוודא שאנו מאפשרים תעבורת HTTPS דרך TCP ו-QUIC, בהתאמה;
• שרת אמולציה מבוסס Java ששולח את אותו סוג של כותרות HTTPS בתגובות וטוען התקני לקוח כדי לקבל מהם בקשות;
• פרוקסי ענן הממוקמים פיזית קרוב להודו כדי לסיים חיבורי TCP ו-QUIC. ואילו עבור סיום TCP השתמשנו בפרוקסי הפוך nginx, היה קשה למצוא פרוקסי הפוך לקוד פתוח עבור QUIC. בנינו בעצמנו פרוקסי הפוך עבור QUIC, תוך שימוש בערימת QUIC הבסיסית של Chromium ו פורסם זה בכרום כקוד פתוח.

איור 6. ערכת בדיקות הדרכים TCP לעומת QUIC כללה מכשירי אנדרואיד עם OkHttp ו- Cronet, פרוקסי ענן לביטול חיבורים ושרת אמולציה.

ניסוי 2

כאשר גוגל הפכה QUIC זמין עם איזון עומסים בענן של Google, השתמשנו באותו מלאי, אבל בשינוי אחד: במקום NGINX, לקחנו את האיזונים של גוגל כדי לסיים חיבורי TCP ו-QUIC ממכשירים, כמו גם להפנות תעבורת HTTPS לשרת האמולציה. מאזנים מופצים בכל העולם, אך משתמשים בשרת ה-PoP הקרוב ביותר למכשיר (הודות למיקום גיאוגרפי).

איור 7. בניסוי השני, רצינו להשוות זמן השלמת TCP ו-QUIC: שימוש ב-Google Cloud ושימוש ב-Proxy בענן שלנו.

כתוצאה מכך, חיכו לנו מספר גילויים:

• סיום באמצעות PoP ביצועי TCP משופרים. מכיוון שמאזנים מפסיקים את חיבורי TCP קרובים יותר למשתמשים ומיואבים מאוד, הדבר מביא ל-RTTs נמוך יותר, מה שמשפר את ביצועי TCP. ולמרות ש-QUIC הושפע פחות, הוא עדיין עקף את TCP במונחים של הפחתת עיכובי זנב (ב-10-30 אחוז).
• זנבות מושפעים מעברי רשת (הופ). למרות שהפרוקסי QUIC שלנו היה רחוק יותר מהמכשירים (השהייה גבוהה בכ-50 אלפיות השנייה) מאשר מאזני העומס של גוגל, הוא סיפק ביצועים דומים - הפחתה של 15% בהשהיה לעומת הפחתה של 20% באחוזון ה-99 עבור TCP. זה מצביע על כך שמעבר המייל האחרון הוא צוואר בקבוק ברשת.

איור 8. התוצאות של שני ניסויים מראות ש-QUIC עדיף משמעותית על TCP.

תנועה קרבית

בהשראת ניסויים, הטמענו תמיכת QUIC ביישומי Android ו-iOS שלנו. ערכנו בדיקות A/B כדי לקבוע את ההשפעה של QUIC בערים שבהן אובר פועלת. באופן כללי, ראינו ירידה משמעותית בעיכובי זנב בשני האזורים, מפעילי טלקום וסוג רשת.

הגרפים שלהלן מציגים את אחוזי השיפורים בזנבות (האחוזון ה-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