HTTP over UDP - שימוש טוב בפרוטוקול QUIC

QUIC (Quick UDP Internet Connections) הוא פרוטוקול על גבי UDP התומך בכל התכונות של TCP, TLS ו-HTTP/2 ופותר את רוב הבעיות שלהם. זה נקרא לעתים קרובות פרוטוקול חדש או "ניסיוני", אבל הוא האריך ימים את שלב הניסוי: הפיתוח נמשך כבר יותר מ-7 שנים. בתקופה זו הפרוטוקול לא הצליח להפוך לסטנדרט, אך עדיין הפך לנפוץ. לדוגמה, QUIC משמש ענקיות כמו גוגל ופייסבוק כדי להאיץ את התעבורה ולצמצם עיכובים ברשתות סלולריות, וה-IETF הכריז על המזלג שלו בפרוטוקול כבסיס לתקן HTTP/3 (למרות ש-HTTP/2 משתמש רק 44.8% אתרים).

מושג

QUIC פותח כתחליף ל-TCP מדור קודם, אשר תוכנן במקור עבור רשתות קוויות בעלות אובדן נמוך. TCP מספק מנות לפי הסדר, כך שאם חבילה אחת אובדת, כל התור נעצר (חסימת ראש קו), מה שמשפיע לרעה על איכות ויציבות החיבור. כדי למנוע הפסדים מסיביים, רשתות סלולריות נוקטות בשימוש במאגרים גדולים, מה שמוביל בתורו ליותר ולתגובה שלילית כוזבת של הפרוטוקול (נפוח חוצץ). בנוסף, TCP מבלה זמן רב ביצירת חיבור: בקשות SYN/ACK ו-TLS מעובדות בנפרד, הדורשות שלוש נסיעות הלוך ושוב במקום אחת, כפי שעושה QUIC.

מכיוון ש-QUIC משלב תחליף TCP ויישום של TLS 1.3, כל החיבורים תמיד מוצפנים, ופענוח תעבורה כזו אינה קלה יותר מאשר אם היא הייתה עוברת ב-HTTPS. בנוסף, QUIC מיושם ברמת האפליקציה, כפי שתידרש החלפה מלאה של מחסנית ה-TCP לנצח.

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

להשתמש

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

עד כה, לא דובר על הכללת HTTP/3 כפרוטוקול הראשי, כי הוא עדיין לא הסתיים וכמעט לא נתמך:

אבל QUIC יכול להיות מיושם כתחבורה בין האפליקציה לשרת, מה שנעשה בהצלחה ב- Uber:

הערה של אובר על הצגת 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 lb, אשר תומך בפרוטוקול מאז אמצע 2018.

זה לא מפתיע ש-Google Cloud עובד מצוין עם הפרוטוקול שפותח בגוגל, אבל מהן האלטרנטיבות?

nginx

לא מזמן CloudFlare ניסיתי לחצות nginx (שאינו תומך ב-HTTP/3 כברירת מחדל) עם הכלי Quiche שלו. היישום זמין כקובץ .patch יחיד, שמגיע עם מדריך התקנה:

curl -O https://nginx.org/download/nginx-1.16.1.tar.gz
tar xvzf nginx-1.16.1.tar.gz
git clone --recursive https://github.com/cloudflare/quiche
cd nginx-1.16.1
patch -p01 < ../quiche/extras/nginx/nginx-1.16.patch

כאן תוכל לחבר את המודולים שלך במידת הצורך

./configure                          	
   	--prefix=$PWD                       	
   	--with-http_ssl_module              	
   	--with-http_v2_module               	
   	--with-http_v3_module               	
   	--with-openssl=../quiche/deps/boringssl 
   	--with-quiche=../quiche
 make

כל מה שנותר הוא לאפשר תמיכה ב-HTTP/3

events {
    worker_connections  1024;
}

http {
    server {
        # Enable QUIC and HTTP/3.
        listen 443 quic reuseport;

        # Enable HTTP/2 (optional).
        listen 443 ssl http2;

        ssl_certificate      cert.crt;
        ssl_certificate_key  cert.key;

        # Enable all TLS versions (TLSv1.3 is required for QUIC).
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;

        # Request buffering in not currently supported for HTTP/3.
        proxy_request_buffering off;

        # Add Alt-Svc header to negotiate HTTP/3.
        add_header alt-svc 'h3-27=":443"; ma=86400';
    }
}

עדיין לא ניתן להתחבר באמצעות HTTP/3 בדפדפנים רגילים, אך ניתן להשתמש Chrome הקנריים ולהפעיל אותו עם הדגל --enable-quic, עבור אל השרת שלך או, למשל, לאתר quic.rocks ועיין בסוג החיבור בכלי המפתחים:

במקום HTTP/3 הוא כתוב http2+quic/99, אבל זה בעצם אותו דבר.

טכנולוגיות אחרות

• QUIC גם תומך LiteSpeed (שהתחברה לפייסבוק דרך HTTP/3 בקול תרועה רמה) ומתקדמת נושא כלים. Apache עדיין לא יכול לעשות את זה, אבל העבודה מתבצעת בתנופה מלאה.
• 21 בינואר עודכן טיוטת תקן עבור WebRTC
• רק לפני כמה ימים מיקרוסופט נפתחה קוד יישום msquic, שבו עדיין לא כל הפונקציות מתקן IETF זמינות, אבל זו כבר פריצת דרך גדולה.

מסקנה

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

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

מקור: www.habr.com