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 לאותו מארח. לדוגמה, Chrome וגרסאות אחרונות של Firefox מאפשרות עד שישה חיבורים.

ההצפנה הייתה אמורה להיות גם להשאיר לפרוטוקולים אחרים, ולשם כך נעשה שימוש בפרוטוקול 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. כן, כן, אותו פרוטוקול שהשתמשנו בו כדי לזרוק קבצים דרך LAN בסוף שנות התשעים ותחילת שנות ה-XNUMX. כמעט כל החומרה של היום יכולה לעבוד איתה.

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

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

בדומה ל-HTTP/2, העבודה על יצירת פרוטוקול חדש החלה בגוגל ב-2012, כלומר בערך באותו זמן שהחלה העבודה על SPDY. בשנת 2013, ג'ים רוסקינד הציג לציבור הרחב פרוטוקול QUIC (Quick UDP Internet Connections)., וכבר ב-2015 הוצגה טיוטת האינטרנט לסטנדרטיזציה ב-IETF. כבר באותה תקופה הפרוטוקול שפיתח רוסקינד בגוגל היה שונה מאוד מהסטנדרט, ולכן הגרסה של גוגל החלה להיקרא 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. אתה יכול לקרוא עוד כאן.

כמה מהיר יותר?

זו שאלה קשה. העובדה היא שעד שיש לנו תקן, אין שום דבר מיוחד למדוד. אולי הסטטיסטיקה היחידה שיש לנו היא סטטיסטיקה של גוגל, שמשתמשת ב-gQUIC מאז 2013 ובשנת 2016 דווח ל-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 יצטרך להיפתר על ידי שימוש בגרסה רעננה של הספרייה ב-backend שתומכת ב-QUIC transport. נכון, תצטרך לשמור על החזרה על גרסאות ישנות של HTTP במשך די הרבה זמן, כי האינטרנט אינו מוכן כרגע למעבר מלא ל-UDP.

מי כבר תומך

כאן список יישומי QUIC קיימים. למרות היעדר תקן, הרשימה לא רעה.

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

מבין הקצה האחורי, 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 מגדיל מאוד את השימוש במעבד. דניאל סטנברג מוערך גידול מעבד עד פי שלושה.

מתי יגיע HTTP/3?

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

ובכן, גוגל משתמשת ביישום gQUIC שלה מאז 2013. אם תסתכל על בקשת ה-HTTP שנשלחת למנוע החיפוש של גוגל, תראה את זה:

ממצאים

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

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

העתיד ממש מעבר לפינה!

מקור: www.habr.com