די QUIC פּראָטאָקאָל אין קאַמף: ווי Uber ימפּלאַמענאַד עס צו אַפּטאַמייז פאָרשטעלונג

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

די בילדער זענען קליקקאַבלע. הנאה לייענען!

Uber האט אַ גלאבאלע וואָג, ניימלי 600 שטעט פון בייַזייַן, אין יעדער פון וואָס די אַפּלאַקיישאַן רילייז לעגאַמרע אויף וויירליס אינטערנעט פון מער ווי 4500 סעליאַלער אָפּערייטערז. יוזערז דערוואַרטן אַז די אַפּ איז נישט בלויז שנעל, אָבער אין פאַקטיש צייט - צו דערגרייכן דעם, די Uber אַפּ דאַרף נידעריק לייטאַנסי און אַ זייער פאַרלאָזלעך קשר. וויי, אָבער די אָנלייגן הטטפּ / קסנומקס טוט נישט גוט אין דינאַמיש און אָנווער-פּראָנע וויירליס נעטוואָרקס. מיר איינגעזען אַז אין דעם פאַל, נידעריק פאָרשטעלונג איז גלייַך שייַכות צו טקפּ ימפּלאַמאַנץ אין אַפּערייטינג סיסטעם קערנאַלז.

צו סאָלווע די פּראָבלעם, מיר געווענדט QUIC, אַ מאָדערן קאַנאַל מולטיפּלעקסינג פּראָטאָקאָל וואָס גיט אונדז מער קאָנטראָל איבער די פאָרשטעלונג פון די אַריבערפירן פּראָטאָקאָל. איצט די אַרבעט גרופּע IETF סטאַנדערדייזיז קוויק ווי הטטפּ / קסנומקס.

נאָך ברייט טעסטינג, מיר געפונען אַז ימפּלאַמענינג QUIC אין אונדזער אַפּלאַקיישאַן וואָלט רעזולטאַט אין נידעריקער עק לייטאַנסיז קאַמפּערד מיט TCP. מיר האָבן באמערקט אַ רעדוקציע אין די קייט פון 10-30% פֿאַר HTTPS פאַרקער אין די שאָפער און פּאַסאַזשיר אַפּלאַקיישאַנז. QUIC אויך געגעבן אונדז סוף-צו-סוף קאָנטראָל איבער באַניצער פּאַקאַדזשאַז.

אין דעם אַרטיקל, מיר טיילן אונדזער דערפאַרונג אין אָפּטימיזינג TCP פֿאַר ובער אַפּלאַקיישאַנז מיט אַ אָנלייגן וואָס שטיצט QUIC.

די לעצטע טעכנאָלאָגיע: TCP

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

רובֿ יוזערז נוצן אונדזער אַפּ אויף די גיין, און TCP עק לייטאַנסיז זענען ינ ערגעצ ניט לעבן די פאדערונגען פון אונדזער פאַקטיש-צייט HTTPS פאַרקער. פשוט, יוזערז איבער די וועלט האָבן יקספּיריאַנסט דעם - פיגורע 1 ווייזט דילייז אין הויפּט שטעט:

פיגורע 1: עק לייטאַנסי וועריז צווישן Uber ס הויפּט שטעט.

כאָטש לייטאַנסי אין ינדיאַן און בראַזיליאַן נעטוואָרקס איז געווען העכער ווי אין די יו. עס. און וק, עק לייטאַנסי איז באטייטיק העכער ווי דורכשניטלעך לייטאַנסי. און דאָס איז אמת אפילו פֿאַר די יו. עס. און וק.

TCP איבער די לופט פאָרשטעלונג

TCP איז באשאפן פֿאַר ווייערד נעטוואָרקס, דאָס איז, מיט אַ טראָפּ אויף העכסט פּרידיקטאַבאַל פֿאַרבינדונגען. אָבער, וויירליס נעטוואָרקס האָבן זייער אייגענע קעראַקטעריסטיקס און שוועריקייטן. ערשטער, וויירליס נעטוואָרקס זענען סאַסעפּטאַבאַל צו לאָססעס רעכט צו ינטערפיראַנס און סיגנאַל אַטטענואַטיאָן. פֿאַר בייַשפּיל, Wi-Fi נעטוואָרקס זענען שפּירעוודיק צו מייקראַווייוו, בלועטאָאָטה און אנדערע ראַדיאָ כוואליעס. סעליאַלער נעטוואָרקס ליידן פון סיגנאַל אָנווער (פאַרפאַלן וועג) רעכט צו אָפּשפּיגלונג / אַבזאָרפּשאַן פון די סיגנאַל דורך אַבדזשעקץ און בנינים, ווי געזונט ווי פון ינטערפיראַנס פון די שכנות צעל טאָווערס. דאָס פירט צו מער באַטייַטיק (4-10 מאל) און מער דייווערס ראָונד יאַזדע צייט (RTT) און פּאַקאַט אָנווער קאַמפּערד צו אַ ווייערד קשר.

צו קאַמבאַט באַנדווידט פלאַקטשויישאַנז און לאָססעס, סעליאַלער נעטוואָרקס טיפּיקלי נוצן גרויס באַפערז פֿאַר פאַרקער בערסץ. דאָס קען פירן צו יבעריק ריי, וואָס מיטל מער דילייז. זייער אָפט TCP באהאנדלט דעם ריי ווי אַ וויסט רעכט צו אַ עקסטענדעד טיימאַוט, אַזוי TCP טענדז צו רעלע און דערמיט פּלאָמבירן די באַפער. דעם פּראָבלעם איז באקאנט ווי bufferbloat (יבעריק נעץ באַפערינג, באַפער בלאָוטינג), און דאָס איז זייער ערנסט פּראָבלעם מאָדערן אינטערנעט.

צום סוף, סעליאַלער נעץ פאָרשטעלונג וועריז לויט טרעגער, געגנט און צייט. אין פיגורע 2, מיר געזאמלט די מידיאַן דילייז פון HTTPS פאַרקער אַריבער סעלז אין אַ 2-קילאָמעטער קייט. דאַטן געזאמלט פֿאַר צוויי הויפּט סעליאַלער אָפּערייטערז אין דעלי, ינדיאַ. ווי איר קענען זען, פאָרשטעלונג וועריז פון צעל צו צעל. אויך, די פּראָודאַקטיוואַטי פון איין אָפּעראַטאָר איז אַנדערש פון די פּראָודאַקטיוואַטי פון די רגע. דאָס איז ינפלואַנסט דורך סיבות אַזאַ ווי נעץ פּאָזיציע פּאַטערנז גענומען אין חשבון צייט און אָרט, באַניצער מאָביליטי, ווי געזונט ווי נעץ ינפראַסטראַקטשער, גענומען אין חשבון טורעם געדיכטקייַט און די פאַרהעלטעניש פון נעץ טייפּס (לטע, 3 ג, אאז"ו ו).

פיגורע 2. דילייז ניצן אַ 2 קילאמעטער ראַדיוס ווי אַ בייַשפּיל. דעלי, ינדיאַ.

אויך, די פאָרשטעלונג פון סעליאַלער נעטוואָרקס וועריז איבער צייַט. פיגורע 3 ווייזט די מידיאַן לייטאַנסי לויט טאָג פון די וואָך. מיר אויך באמערקט דיפעראַנסיז אויף אַ קלענערער וואָג, אין אַ איין טאָג און שעה.

פיגורע 3. עק דילייז קענען בייַטן באטייטיק צווישן טעג, אָבער פֿאַר דער זעלביקער אָפּעראַטאָר.

אַלע פון ​​די אויבן ז די TCP פאָרשטעלונג צו זיין יניפעקטיוו אין וויירליס נעטוואָרקס. אָבער, איידער מיר זוכן אַלטערנאַטיוועס צו TCP, מיר געוואלט צו אַנטוויקלען אַ גענוי פארשטאנד אויף די פאלגענדע פונקטן:

• איז TCP דער הויפּט קולפּריט הינטער עק לייטאַנסיעס אין אונדזער אַפּלאַקיישאַנז?
• צי מאָדערן נעטוואָרקס האָבן באַטייַטיק און וועריד דילייז (RTT)?
• וואָס איז די פּראַל פון RTT און אָנווער אויף TCP פאָרשטעלונג?

טקפּ פאָרשטעלונג אַנאַליסיס

צו פֿאַרשטיין ווי מיר אַנאַלייזד TCP פאָרשטעלונג, לאָמיר נעמען אַ שנעל קוק ווי TCP טראַנספערס דאַטן פון אַ סענדער צו אַ ופנעמער. ערשטער, דער סענדער יסטאַבלישיז אַ טקפּ קשר, פּערפאָרמינג אַ דריי-וועג האַנדשאַפֿט: דער סענדער סענדז אַ SYN פּאַקאַט, ווייץ פֿאַר אַ SYN-ACK פּאַקאַט פון די ופנעמער, און סענדז אַ ACK פּאַקאַט. אַן נאָך רגע און דריט פאָרן איז פארבראכט צו גרינדן די TCP פֿאַרבינדונג. דער באַקומער יקנאַלידזשז קאַבאָלע פון ​​יעדער פּאַקאַט (ACK) צו ענשור פאַרלאָזלעך עקספּרעס.

אויב אַ פּאַקאַט אָדער ACK איז פאַרפאַלן, דער סענדער ריטראַנסמיטז נאָך אַ טיימאַוט (RTO, ריטראַנסמיסיע צייט). RTO איז קאַלקיאַלייטיד דינאַמיקאַללי באזירט אויף פאַרשידן סיבות, אַזאַ ווי די דערוואַרט RTT פאַרהאַלטן צווישן די סענדער און באַקומער.

פיגורע 4. פּאַקאַט וועקסל איבער טקפּ / טלס כולל אַ רעטראַנסמיססיאָן מעקאַניזאַם.

צו באַשליסן ווי TCP איז דורכגעקאָכט אין אונדזער אַפּלאַקיישאַנז, מיר מאָניטאָרעד TCP פּאַקיץ ניצן טקפּדומפּ פֿאַר אַ וואָך אויף קאַמבאַט פאַרקער פֿון אינדיאַנישער ברעג סערווערס. דערנאָך מיר אַנאַלייזד די TCP קאַנעקשאַנז ניצן tcptrace. אַדדיטיאָנאַללי, מיר באשאפן אַן אַנדרויד אַפּלאַקיישאַן אַז סענדז עמולאַטעד פאַרקער צו אַ פּראָבע סערווער, נאָכמאַכן פאַקטיש פאַרקער ווי פיל ווי מעגלעך. סמאַרטפאָנעס מיט דעם אַפּלאַקיישאַן זענען פונאנדערגעטיילט צו עטלעכע עמפּלוייז, וואָס געזאמלט לאָגס איבער עטלעכע טעג.

די רעזולטאַטן פון ביידע יקספּעראַמאַנץ זענען קאָנסיסטענט מיט יעדער אנדערע. מיר געזען הויך RTT לייטאַנסיז; עק וואַלועס זענען כּמעט 6 מאל העכער ווי די מידיאַן ווערט; די אַריטמעטיק דורכשניטלעך פון דילייז איז מער ווי 1 רגע. פילע קאַנעקשאַנז זענען לאָססי, וואָס געפֿירט TCP צו ריטראַנסמיט 3,5% פון אַלע פּאַקיץ. אין קאַנדזשעסטיד געביטן אַזאַ ווי ערפּאָרץ און באַן סטיישאַנז, מיר געזען 7% לאָססעס. די רעזולטאַטן וואַרפן צווייפל אויף די קאַנווענשאַנאַל חכמה וואָס די געוויינט אין סעליאַלער נעטוואָרקס אַוואַנסירטע רעטראַנסמיססיאָן סערקאַץ באטייטיק רעדוצירן לאָססעס אין די אַריבערפירן מדרגה. ונטער זענען די פּראָבע רעזולטאַטן פון די "סימולאַטאָר" אַפּלאַקיישאַן:

נעץ מעטריקס
וואַלועס

RTT, מיליסעקאַנדז [50%, 75%, 95%, 99%]
[350, 425, 725, 2300]

RTT דיווערדזשאַנס, סעקונדעס
אין דורכשניטלעך ~ 1,2 s

פּאַקאַט אָנווער אויף אַנסטייבאַל קאַנעקשאַנז
דורכשניטלעך ~ 3.5% (7% אין אָוווערלאָודיד געביטן)

כּמעט האַלב פון די קאַנעקשאַנז האָבן בייַ מינדסטער איין פּאַקאַט אָנווער, רובֿ פון זיי SYN און SYN-ACK פּאַקיץ. רובֿ טקפּ ימפּלאַמאַנץ נוצן אַ RTO ווערט פון 1 סעקונדע פֿאַר SYN פּאַקיץ, וואָס ינקריסיז עקספּאָונענשאַלי פֿאַר סאַבסאַקוואַנט לאָססעס. אַפּפּליקאַטיאָן לאָודינג צייט קען פאַרגרעסערן ווייַל TCP נעמט מער צו פאַרלייגן קאַנעקשאַנז.

אין די פאַל פון דאַטן פּאַקיץ, הויך RTO וואַלועס שטארק רעדוצירן די נוציק יוטאַלאַזיישאַן פון די נעץ אין דעם בייַזייַן פון טראַנזשאַנט לאָססעס אין וויירליס נעטוואָרקס. מיר געפֿונען אַז די דורכשניטלעך רעטראַנסמיססיאָן צייט איז בעערעך 1 סעקונדע מיט אַ עק פאַרהאַלטן פון כּמעט 30 סעקונדעס. די הויך לייטאַנסי אויף די טקפּ מדרגה געפֿירט HTTPS טיימאַוץ און שייַעך-ריקוועס, נאָך ינקריסינג נעץ לייטאַנסי און יניפעקטיוונאַס.

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

טקפּ פּאַקאַט אָנווער סטאַטיסטיק
ווערט

פּראָצענט פון קאַנעקשאַנז מיט בייַ מינדסטער 1 פּאַקאַט אָנווער
קסנומקס%

פּראָצענט פון קאַנעקשאַנז מיט לאָססעס בעשאַס קשר סעטאַפּ
קסנומקס%

פּראָצענט פון קאַנעקשאַנז מיט לאָססעס בעשאַס דאַטן וועקסל
קסנומקס%

פאַרשפּרייטונג פון דילייז אין ריטראַנסמיססיאָן, סעקונדעס [50%, 75%, 95%,99%] [1, 2.8, 15, 28]

פאַרשפּרייטונג פון די נומער פון רעטראַנסמישאַנז פֿאַר איין פּאַקאַט אָדער טקפּ אָפּשניט
[קסנומקס]

אַפּלאַקיישאַן פון QUIC

אָריגינאַללי דעוועלאָפּעד דורך Google, QUIC איז אַ מולטי-טרעדיד מאָדערן אַריבערפירן פּראָטאָקאָל וואָס לויפט אויף שפּיץ פון UDP. דערווייַל QUIC איז אין סטאַנדערדיזיישאַן פּראָצעס (מיר האָבן שוין געשריבן אַז עס זענען, ווי עס איז, צוויי ווערסיעס פון QUIC, טשיקאַווע קענען נאָכגיין די לינק – בעערעך. איבערזעצער). ווי געוויזן אין פיגורע 5, QUIC איז געשטעלט אונטער הטטפּ / 3 (אין פאַקט, הטטפּ / 2 אויף שפּיץ פון QUIC איז הטטפּ / 3, וואָס איז איצט ינטענסיוולי סטאַנדערדייזד). עס טייל ריפּלייסיז די HTTPS און TCP לייַערס דורך ניצן UDP צו פאָרעם פּאַקיץ. QUIC שטיצט בלויז זיכער דאַטן אַריבערפירן ווייַל TLS איז גאָר געבויט אין QUIC.

פיגורע 5: QUIC לויפט אונטער הטטפּ / 3, ריפּלייסינג TLS, וואָס ביז אַהער געלאפן אונטער הטטפּ / 2.

ונטער זענען די סיבות וואָס קאַנווינסט אונדז צו נוצן QUIC פֿאַר TCP אַמפּלאַפאַקיישאַן:

• 0-רטט קשר פאַרלייגן. QUIC אַלאַוז די רייוז פון דערלויבעניש פון פריערדיקן קאַנעקשאַנז, רידוסינג די נומער פון זיכערהייט כאַנדשייקס. אין צוקונפֿט TLS1.3 וועט שטיצן 0-RTT, אָבער אַ דריי-וועג TCP כאַנדשייק וועט נאָך זיין פארלאנגט.
• אָוווערקאַמינג האָל בלאַקינג. הטטפּ / 2 ניצט איין TCP פֿאַרבינדונג פּער קליענט צו פֿאַרבעסערן פאָרשטעלונג, אָבער דאָס קען פירן צו בלאַקינג האָל (קאָפּ-פון-שורה). QUIC סימפּלאַפייז מולטיפּלעקסינג און דיליווערז ריקוועס צו די אַפּלאַקיישאַן ינדיפּענדאַנטלי.
• קאַנדזשעסטשאַן קאָנטראָל. QUIC ריזיידז אין די אַפּלאַקיישאַן שיכטע, וואָס מאכט עס גרינגער צו דערהייַנטיקן די הויפּט אַריבערפירן אַלגערידאַם וואָס קאָנטראָלס שיקט באזירט אויף נעץ פּאַראַמעטערס (נומער פון לאָססעס אָדער RTT). רובֿ טקפּ ימפּלאַמאַנץ נוצן די אַלגערידאַם קוביק, וואָס איז נישט אָפּטימאַל פֿאַר לייטאַנסי-שפּירעוודיק פאַרקער. לעצטנס דעוועלאָפּעד אַלגערידאַמז ווי בבר, מער אַקיעראַטלי מאָדעל די נעץ און אַפּטאַמייז לייטאַנסי. QUIC אַלאַוז איר צו נוצן BBR און דערהייַנטיקן דעם אַלגערידאַם ווי עס איז געניצט. פֿאַרבעסערונג.
• ריפּלענישמאַנט פון לאָססעס. QUIC רופט צוויי טלפּס (עק אָנווער זאָנד) איידער די RTO איז טריגערד - אפילו ווען די לאָססעס זענען זייער באמערקט. דאָס איז אַנדערש פון TCP ימפּלאַמאַנץ. TLP ריטראַנסמיטז דער הויפּט די לעצטע פּאַקאַט (אָדער די נייַע, אויב עס איז איין) צו צינגל שנעל ריפּלענישמאַנט. די האַנדלינג פון עק דילייז איז ספּעציעל נוציק פֿאַר די וועג Uber אַפּערייץ זיין נעץ, ניימלי פֿאַר קורץ, ספּאָראַדיש און לייטאַנסי-שפּירעוודיק דאַטן טראַנספערס.
• אָפּטימיזעד ACK. זינט יעדער פּאַקאַט האט אַ יינציק סיקוואַנס נומער, עס איז קיין פּראָבלעם דיסטינגקשאַנז פּאַקיץ ווען זיי זענען ריטראַנסמיטטעד. ACK פּאַקיץ אויך אַנטהאַלטן צייט צו פּראָצעס דעם פּאַקאַט און דזשענערייט אַן ACK אויף דער קליענט זייַט. די פֿעיִקייטן ענשור אַז QUIC קאַלקיאַלייץ RTT מער אַקיעראַטלי. ACK אין QUIC שטיצט אַרויף צו 256 באַנדס NACK, העלפּינג די סענדער זיין מער ריזיליאַנט צו פּאַקאַט שאַפלינג און נוצן ווייניקערע ביטעס אין דעם פּראָצעס. סעלעקטיוו ACK (SACK) אין טקפּ טוט נישט סאָלווע דעם פּראָבלעם אין אַלע קאַסעס.
• קשר מייגריישאַן. QUIC קאַנעקשאַנז זענען יידענאַפייד דורך אַ 64-ביסל שייַן, אַזוי אויב אַ קליענט ענדערונגען IP אַדרעסעס, די אַלט קשר שייַן קענען פאָרזעצן צו זיין געוויינט אויף די נייַע IP אַדרעס אָן יבעררייַס. דאָס איז אַ זייער פּראָסט פיר פֿאַר רירעוודיק אַפּלאַקיישאַנז ווו דער באַניצער סוויטשיז צווישן Wi-Fi און סעליאַלער קאַנעקשאַנז.

אַלטערנאַטיוועס צו QUIC

מיר באַטראַכטן אָלטערנאַטיוו אַפּראָוטשיז צו סאַלווינג די פּראָבלעם איידער טשוזינג QUIC.

דער ערשטער זאַך וואָס מיר געפרוווט איז צו צעוויקלען TPC פּאָפּס (פּוינטס פון פּרעזאַנס) צו פאַרענדיקן TCP קאַנעקשאַנז נעענטער צו יוזערז. יסענשאַלי, פּאָפּס פאַרענדיקן אַ TCP פֿאַרבינדונג מיט אַ רירעוודיק מיטל נעענטער צו די סעליאַלער נעץ און פּראַקסי די פאַרקער צוריק צו דער אָריגינעל ינפראַסטראַקטשער. דורך טערמאַנייטינג TCP נעענטער, מיר קענען פּאַטענטשאַלי רעדוצירן די RTT און ענשור אַז TCP איז מער אָפּרופיק צו אַ דינאַמיש וויירליס סוויווע. אָבער, אונדזער יקספּעראַמאַנץ האָבן געוויזן אַז רובֿ פון די RTT און אָנווער קומט פון סעליאַלער נעטוואָרקס און די נוצן פון פּאָפּס טוט נישט צושטעלן אַ באַטייטיק פאָרשטעלונג פֿאַרבעסערונג.

מיר אויך געקוקט אויף טונינג טקפּ פּאַראַמעטערס. באַשטעטיקן אַ טקפּ אָנלייגן אויף אונדזער כעטעראַדזשיניאַס ברעג סערווערס איז געווען שווער ווייַל טקפּ האט דיספּעראַט ימפּלאַמאַנץ צווישן פאַרשידענע אַס ווערסיעס. עס איז געווען שווער צו ינסטרומענט דעם און פּרובירן פאַרשידענע נעץ קאַנפיגיעריישאַנז. קאַנפיגיערינג TCP גלייַך אויף רירעוודיק דעוויסעס איז ניט מעגלעך ווייַל פון פעלן פון פּערמישאַנז. מער ימפּאָרטאַנטלי, פֿעיִקייטן אַזאַ ווי 0-RTT קאַנעקשאַנז און ימפּרוווד RTT פּראָגנאָז זענען קריטיש פֿאַר די פּראָטאָקאָל ס אַרקאַטעקטשער, און דעריבער עס איז אוממעגלעך צו דערגרייכן באַטייטיק בענעפיץ דורך טונינג TCP אַליין.

צום סוף, מיר עוואַלואַטעד עטלעכע UDP-באזירט פּראָטאָקאָלס וואָס טראָובלעשאָאָט ווידעא סטרימינג - מיר געוואלט צו זען אויב די פּראָטאָקאָלס וואָלט העלפֿן אין אונדזער פאַל. צום באַדויערן, זיי זענען סאַווירלי פעלנדיק אין פילע זיכערהייט סעטטינגס, און אויך פארלאנגט אַן נאָך TCP פֿאַרבינדונג פֿאַר מעטאַדאַטאַ און קאָנטראָל אינפֿאָרמאַציע.

אונדזער פאָרשונג האט געוויזן אַז QUIC איז טאָמער דער בלויז פּראָטאָקאָל וואָס קענען העלפֿן מיט דעם פּראָבלעם פון אינטערנעט פאַרקער, בשעת איר נעמען אין חשבון ביידע זיכערהייט און פאָרשטעלונג.

ינאַגריישאַן פון QUIC אין דער פּלאַטפאָרמע

צו הצלחה ימבעד QUIC און פֿאַרבעסערן אַפּלאַקיישאַן פאָרשטעלונג אין נעבעך קאַנעקטיוויטי ינווייראַנמאַנץ, מיר ריפּלייסט די אַלט אָנלייגן (HTTP / 2 איבער TLS / TCP) מיט די QUIC פּראָטאָקאָל. מיר געוויינט די נעץ ביבליאָטעק Cronet פון קראָומיאַם פּראַדזשעקס, וואָס כּולל דער אָריגינעל Google ווערסיע פון ​​​​דעם פּראָטאָקאָל - gQUIC. די ימפּלאַמענטיישאַן איז אויך קעסיידער ימפּרוווד צו נאָכפאָלגן די לעצטע IETF באַשרייַבונג.

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

ענלעך צו דער צוגאַנג פֿאַר אַנדרויד דעוויסעס, מיר ימפּלאַמענאַד Cronet אין Uber אַפּפּס אויף יאָס, ינטערסעפּטינג הטטפּ פאַרקער פון נעץ אַפּיניצן NSURL פּראָטאָקאָל. די אַבסטראַקציע, צוגעשטעלט דורך די יאָס וויקיפּעדיע, כאַנדאַלז פּראָטאָקאָל-ספּעציפיש URL דאַטן און ינשורז אַז מיר קענען ויסשטימען Cronet אין אונדזער יאָס אַפּלאַקיישאַנז אָן באַטייטיק מיגראַטיאָן קאָס.

פאַרענדיקן QUIC אויף Google קלאָוד באַלאַנסערז

אויף די באַקענד זייַט, QUIC קאַמפּלישאַן איז צוגעשטעלט דורך די Google קלאָוד לאָוד באַלאַנסינג ינפראַסטראַקטשער, וואָס ניצט alt-svc כעדערז אין רעספּאָנסעס צו שטיצן QUIC. אין אַלגעמיין, די באַלאַנסער מוסיף אַן alt-svc כעדער צו יעדער הטטפּ בעטן, און דאָס שוין וואַלאַדייץ QUIC שטיצן פֿאַר די פעלד. ווען אַ Cronet קליענט באקומט אַ הטטפּ ענטפער מיט דעם כעדער, עס ניצט QUIC פֿאַר סאַבסאַקוואַנט הטטפּ ריקוועס צו דעם פעלד. אַמאָל די באַלאַנסער קאַמפּליץ די QUIC, אונדזער ינפראַסטראַקטשער בפירוש סענדז דעם קאַמף איבער HTTP2 / TCP צו אונדזער דאַטן סענטערס.

פאָרשטעלונג: רעזולטאַטן

רעזולטאַט פאָרשטעלונג איז די הויפּט סיבה פֿאַר אונדזער זוכן פֿאַר אַ בעסער פּראָטאָקאָל. צו אָנהייבן מיט, מיר באשאפן אַ שטיין מיט נעץ עמיאַליישאַןצו געפֿינען זיך ווי QUIC וועט ביכייווז אונטער פאַרשידענע נעץ פּראָופיילז. צו פּרובירן די פאָרשטעלונג פון QUIC אויף פאַקטיש-וועלט נעטוואָרקס, מיר לויפן יקספּעראַמאַנץ בשעת דרייווינג אַרום ניו דעלי ניצן עמיאַלייטיד נעץ פאַרקער זייער ענלעך צו הטטפּ קאַללס אין די פּאַסאַזשיר אַפּ.

עקספּערימענט 1

ויסריכט פֿאַר די עקספּערימענט:

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

פיגורע 6. די TCP ווס QUIC וועג פּרובירן סוויט קאָנסיסטעד פון אַנדרויד דעוויסעס מיט OkHttp און Cronet, וואָלקן פּראַקסיז פֿאַר טערמאַנייטינג קאַנעקשאַנז און אַן עמיאַליישאַן סערווער.

עקספּערימענט 2

ווען Google געמאכט QUIC בנימצא מיט Google קלאָוד לאָוד באַלאַנסינג, מיר געוויינט די זעלבע ינוואַנטאָרי, אָבער מיט איין מאָדיפיקאַטיאָן: אַנשטאָט פון NGINX, מיר גענומען Google מאַסע באַלאַנסערז צו פאַרענדיקן TCP און QUIC קאַנעקשאַנז פון דעוויסעס, ווי געזונט ווי צו מאַרשרוט HTTPS פאַרקער צו די עמיאַליישאַן סערווער. באַלאַנסערס זענען פונאנדערגעטיילט איבער די וועלט, אָבער נוצן די פּאָפּ סערווער קלאָוסאַסט צו די מיטל (דאַנק צו געאָלאָקאַטיאָן).

פיגורע 7. אין די רגע עקספּערימענט, מיר געוואלט צו פאַרגלייַכן די קאַמפּלישאַן לייטאַנסי פון TCP און QUIC: ניצן Google קלאָוד און ניצן אונדזער וואָלקן פראקסי.

ווי אַ רעזולטאַט, עטלעכע התגלות אַווייטאַד אונדז:

• טערמאַניישאַן דורך פּאָפּ ימפּרוווד טקפּ פאָרשטעלונג. זינט באַלאַנסערז פאַרענדיקן TCP קאַנעקשאַנז נעענטער צו יוזערז און זענען העכסט אָפּטימיזעד, דאָס רעזולטאטן אין נידעריקער RTTs, וואָס ימפּרוווז TCP פאָרשטעלונג. און כאָטש QUIC איז געווען ווייניקער אַפעקטאַד, עס נאָך אַוטפּערפאָרמד TCP אין טערמינען פון רידוסינג עק לייטאַנסי (מיט 10-30 פּראָצענט).
• עקן זענען אַפעקטאַד נעץ האָפּס. כאָטש אונדזער QUIC פראקסי איז געווען ווייַטער פון די דעוויסעס (וועגן 50 מיז העכער לייטאַנסי) ווי Google ס מאַסע באַלאַנסערז, עס דעליווערד ענלעך פאָרשטעלונג - אַ 15% רעדוקציע אין לייטאַנסי קעגן אַ 20% רעדוקציע אין די 99 פּערסענטיל פֿאַר TCP. דאָס סאַגדזשעסץ אַז די לעצטע מייל יבערגאַנג איז אַ באַטאַלנעק אין די נעץ.

פיגורע 8: רעזולטאַטן פון צוויי יקספּעראַמאַנץ ווייַזן אַז QUIC באטייטיק אַוטפּערפאָרמז TCP.

קאַמבאַט פאַרקער

ינספּייערד דורך יקספּעראַמאַנטיישאַן, מיר האָבן ימפּלאַמענאַד QUIC שטיצן אין אונדזער אַנדרויד און יאָס אַפּלאַקיישאַנז. מיר האָבן דורכגעקאָכט אַ / ב טעסטינג צו באַשליסן די פּראַל פון QUIC אין די שטעט ווו Uber אַפּערייץ. אין אַלגעמיין, מיר האָבן געזען אַ באַטייטיק רעדוקציע אין עק דילייז אין ביידע מקומות, טעלעקאָם אָפּערייטערז און נעץ טיפּ.

די גראַפס אונטן ווייַזן די פּראָצענט ימפּרווומאַנץ אין עקן (95 און 99 פּערסענטיילז) לויט מאַקראָו געגנט און פאַרשידענע נעץ טייפּס - לטע, 3 ג, 2 ג.

פיגורע 9. אין שלאַכט טעסץ, QUIC אַוטפּערפאָרמד TCP אין טערמינען פון לייטאַנסי.

בלויז פאָרויס

טאָמער דאָס איז נאָר דער אָנהייב - די מעלדונג פון QUIC אין פּראָדוקציע האט צוגעשטעלט אַמייזינג אַפּערטונאַטיז צו פֿאַרבעסערן אַפּלאַקיישאַן פאָרשטעלונג אין סטאַביל און אַנסטייבאַל נעטוואָרקס, ניימלי:

געוואקסן קאַווערידזש

נאָך אַנאַלייזד די פאָרשטעלונג פון דעם פּראָטאָקאָל אויף פאַקטיש פאַרקער, מיר געזען אַז בעערעך 80% פון סעשאַנז הצלחה געוויינט QUIC פֿאַר אַלע ריקוועס, בשעת 15% פון סעשאַנז געוויינט אַ קאָמבינאַציע פון ​​QUIC און TCP. מיר יבערנעמען אַז די קאָמבינאַציע איז רעכט צו דער קראָנעט ביבליאָטעק צוריק צו TCP, ווייַל עס קען נישט ויסטיילן צווישן פאַקטיש UDP פייליערז און נעבעך נעץ טנאָים. מיר קוקן איצט אין אַ לייזונג צו דעם פּראָבלעם ווען מיר אַרבעטן צו די סאַבסאַקוואַנט ימפּלאַמענטיישאַן פון QUIC.

קוויק אַפּטאַמאַזיישאַן

פאַרקער פון רירעוודיק אַפּפּס איז לייטאַנסי שפּירעוודיק, אָבער נישט באַנדווידט שפּירעוודיק. אויך, אונדזער אַפּלאַקיישאַנז זענען בפֿרט געניצט אויף סעליאַלער נעטוואָרקס. באַזירט אויף יקספּעראַמאַנץ, עק לייטאַנסיז זענען נאָך הויך, כאָטש ניצן אַ פּראַקסי צו פאַרענדיקן TCP און QUIC נאָענט צו יוזערז. מיר זענען אַקטיוולי קוקן פֿאַר וועגן צו פֿאַרבעסערן קאַנדזשעסטשאַן פאַרוואַלטונג און פֿאַרבעסערן די עפעקטיווקייַט פון QUIC אָנווער אָפּזוך אַלגערידאַמז.

מיט די און עטלעכע אנדערע ימפּרווומאַנץ, מיר פּלאַנירן צו פֿאַרבעסערן די באַניצער דערפאַרונג ראַגאַרדלאַס פון נעץ און געגנט, מאכן באַקוועם און סימלאַס פּאַקאַט אַריבערפירן מער צוטריטלעך אַרום די וועלט.

מקור: www.habr.com