HTTP/3 ו-QUIC

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

HTTP/3 נוטש את TCP לחלוטין. במקומו, הוא משתמש ב-QUIC — פרוטוקול תעבורה חדש שפותר בעיות שTCP אינו יכול לפתור, מפני שעיצובו של TCP מונע זאת.

הבעיה שTCP לא יכול לתקן

HTTP/2 הכניס ריבוב: בקשות מרובות שחולקות חיבור יחיד. עשר תמונות שנטענות בו-זמנית דרך חיבור TCP אחד במקום עשרה חיבורים נפרדים. יעיל.

אבל TCP רואה רק בייטים. הוא לא יודע על תמונות, בקשות, או זרמים. הוא יודע: בייט 41 מגיע לפני בייט 42, לפני בייט 43. תמיד. ללא יוצאים מן הכלל.

כאשר פקטה 42 אובדת ברשת, TCP ממתין. פקטות 43 עד 100 עשויות להגיע בהצלחה, אבל TCP מחזיק אותן כבני ערובה עד שפקטה 42 תישלח מחדש. האפליקציה לא יכולה לגעת בהן.

זה נקרא חסימת ראש השורה. אם פקטה 42 מכילה נתונים לתמונה 5, תמונות 6 עד 10 ממתינות — למרות שהנתונים שלהן הגיעו שלמים. עוצמתו הגדולה ביותר של TCP הפכה לחולשתו הגדולה ביותר: ההבטחה שבייטים מגיעים בסדר הפכה להבטחה שכל זרם חייב לחכות לבעיות של כל זרם אחר.

אי אפשר לתקן את זה ב-TCP. ערובת הסדר היא TCP. הסרתה תיצור פרוטוקול אחר.

אז הם יצרו פרוטוקול אחר.

מה זה QUIC

QUIC בנוי על גבי UDP, שלא מבטיח כמעט דבר — פקטות עשויות להגיע, עשויות שלא, עשויות להגיע שלא בסדר. זה נשמע כמו ירידה לדרגה. בפועל, זו חירות.

ריקנותו של UDP מאפשרת ל-QUIC ליישם בדיוק את מה שאפליקציות מודרניות צריכות:

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

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

מזהי חיבור מזהים חיבורים ללא תלות בכתובות IP. זה חשוב יותר ממה שנשמע.

מהפכת לחיצת היד

TCP + TLS דורשים טקס היכרות:

1. TCP SYN
2. TCP SYN-ACK
3. TCP ACK
4. TLS ClientHello
5. TLS ServerHello ואישור
6. TLS Finished
7. ורק אז — הבקשה האמיתית שלך

לפחות שני סיבובים לפני שבייט אחד של נתוני אפליקציה זורם.

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

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

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

נדידת חיבור

חיבור TCP מוגדר על ידי ארבעה דברים: IP מקור, פורט מקור, IP יעד, פורט יעד. שנה אחד מהם והחיבור נקטע.

אתה בשיחת וידאו בבית. אתה יוצא החוצה. הטלפון שלך עובר מ-WiFi לרשת סלולרית. כתובת ה-IP שלך משתנה. חיבור ה-TCP שלך מת. אפליקציית הוידאו חייבת להתחבר מחדש, לנהל מחדש משא ומתן על TLS, לשחזר את המצב.

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

זה טרנספורמטיבי עבור משתמשי מובייל שעוברים כל הזמן בין רשתות. חיבורים שורדים את מה שפעם היה הורג אותם.

אבטחה כבסיס

TCP מתייחס להצפנה כאופציה — משהו שאפשר להוסיף מעל אם רוצים. QUIC מתייחס להצפנה כחובה.

כל פקטת QUIC מוצפנת באמצעות TLS 1.3. לא רק המטען — רוב שדות הכותרת מוצפנים גם הם. ציוד רשת לא יכול לבדוק או לשנות תעבורת QUIC כפי שניתן לעשות עם TCP.

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

HTTP/3: HTTP מעל QUIC

HTTP/3 הוא סמנטיקת HTTP — שיטות, כותרות, קודי מצב — המועברת דרך QUIC במקום TCP.

ההתאמה פשוטה: כל בקשת HTTP משתמשת בזרם QUIC נפרד. דחיסת כותרות (QPACK) מחליפה את HPACK של HTTP/2, ועוצבה מחדש לזרמים שעשויים להגיע שלא בסדר.

HTTP/3 מסיר דחיפת שרת, שהתגלתה כמורכבת מדי ולא מנוצלת מספיק ב-HTTP/2. הוא מפשט את איתות העדיפות בהתבסס על מה שהוכיח את עצמו בפועל.

השינויים הם בשכבת התעבורה. קוד האפליקציה כמעט ולא צריך שינוי.

מה המספרים מראים

ברשתות טובות: מהיר ב-5–10% מ-HTTP/2. שיפורי לחיצת היד חשובים, אבל TCP מתמודד בסבירות עם רשתות אמינות.

ברשתות עם אבדן פקטות: מהיר ב-20–30%. כאן QUIC מבריק. אבדן פקטות כבר לא מתפשט בין הזרמים. משתמשי מובייל עם חיבורים לא יציבים רואים את הרווחים הגדולים ביותר.

נדידת חיבור מספקת יתרונות שלא ניכרים במדדים פשוטים. משתמשים שעוברים בין רשתות חווים המשכיות במקום התחברות מחדש.

למה האימוץ לוקח זמן

ל-UDP יש בעיית מוניטין. חומות אש ארגוניות לעיתים קרובות חוסמות אותו. רשתות ציבוריות מגבילות את קצב שלו. ניצול לרעה בעבר — מתקפות DNS amplification, הצפות UDP — הפך את מנהלי הרשת לחשדנים.

HTTP/3 נסוג ל-HTTP/2 כאשר UDP נכשל. נסיגה חלקה, אבל היתרונות נעלמים.

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

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

איפה אנחנו עכשיו

כל דפדפן מודרני תומך ב-HTTP/3. Chrome, Firefox, Safari, Edge — כולם.

רשתות CDN גדולות מגישות HTTP/3: Cloudflare, Fastly, Akamai, Amazon CloudFront. Google, Facebook, ורוב הרשת המודרנית משתמשות בו.

הערכות נוכחיות: 25–30% מתעבורת הרשת משתמשת ב-HTTP/3, ומספר זה עולה.

גילוי מתרחש דרך כותרות Alt-Svc — שרתים מפרסמים בהן את זמינות HTTP/3 — או רשומות DNS HTTPS, לשימוש כבר בחיבור הראשון. שניהם מאפשרים נסיגה חלקה.

המשמעות הרחבה יותר

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

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

QUIC כבר מותאם לשימושים שאינם HTTP. DNS over QUIC. WebTransport לאפליקציות בזמן אמת. היתרונות של זרמים מובנים, לחיצות יד מהירות ונדידת חיבור חלים באופן רחב.

שכבת התעבורה של האינטרנט, קפואה במשך עשרות שנים, נעה שוב.

שאלות נפוצות על HTTP/3 ו-QUIC

למה לבנות על UDP במקום ליצור פרוטוקול חדש לגמרי?

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

האם אני יכול להשתמש ב-HTTP/3 אם הרשת שלי חוסמת UDP?

הדפדפן שלך יחזור אוטומטית ל-HTTP/2 או HTTP/1.1 מעל TCP. לא תראה שגיאה — פשוט לא תקבל את היתרונות של HTTP/3. נסיגה חלקה זו אומרת שפריסת HTTP/3 לא שוברת דבר, אבל רשתות מגבילות מפספסות את שיפורי הביצועים.

האם HTTP/3 תמיד מהיר יותר מ-HTTP/2?

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

האם HTTP/3 דורש שינויים בקוד האתר שלי?

כמעט לעולם לא. HTTP/3 משנה את שכבת התעבורה, לא את שכבת האפליקציה. ה-HTML, JavaScript, ממשקי ה-API והלוגיקה של השרת שלך נשארים ללא שינוי. אתה צריך תוכנת שרת שתומכת ב-HTTP/3, אבל קוד האפליקציה בדרך כלל אינו דורש שינוי.

למה 0-RTT resumption לא משמש לכל הבקשות?

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