עודכן לפני חודש
כל חיבור TCP מתחיל בטקס. המכשיר שלך שולח SYN. השרת מגיב עם SYN-ACK. אתה מגיב עם ACK. זהו סיבוב הלוך-חזור אחד לפני שמשהו אמיתי קורה. עכשיו הוסף הצפנת TLS: עוד הודעות, עוד סיבוב. על חיבור סיבי אופטי באותה עיר, כמעט לא תרגיש. על רשת סלולרית בהודו הכפרית, אתה ממתין 400 מילישניות לפני שבית אחד מהבקשה האמיתית שלך עובר על הכבל.
QUIC מבטל את הטקס הזה. הוא מקים חיבורים מוצפנים בסיבוב הלוך-חזור אחד — לפעמים אפס. וזה רק ההתחלה של מה שמשתנה כשבונים תחבורה אמינה מחדש מהיסוד על גבי UDP.
הבעיה עם TCP
TCP תוכנן בשנת 19741. הוא שירת היטב במיוחד, אך שלוש מגבלות הפכו לכואבות יותר ויותר עם התפתחות האינטרנט.
מס לחיצת היד. כל חיבור TCP חדש מצריך לחיצת יד משולשת. הוסף TLS להצפנה, ותצטרך חילופי מידע נוספים. זה שני סיבובים לפחות לפני שנתוני האפליקציה זורמים. ברשתות עם זמן אחזור גבוה, זה מוסיף מאות מילישניות לכל חיבור חדש.
חסימת ראש התור. TCP מבטיח שבתים מגיעים בסדר. אם מנת נתונים מספר 5 אובדת, מנות 6, 7 ו-8 חייבות לחכות — גם אם הן מכילות נתונים שאין ביניהם קשר. HTTP/2 ניסה להריץ בקשות מרובות על חיבור TCP אחד, אך זה החמיר את הבעיה: אבדה מנת נתונים אחת, וכל הבקשות נעצרות.
זהות שבירה. TCP מזהה חיבורים לפי ארבעה מספרים: IP מקור, פורט מקור, IP יעד, פורט יעד. שנה אחד מהם — כמו כשהטלפון שלך עובר מ-WiFi לרשת סלולרית — והחיבור מת. אתה מתחיל מחדש.
אלה אינן תקלות. הן תוצאות של החלטות שנתקבלו לפני חמישים שנה, ושובצו בגרעינים של מערכות הפעלה ברחבי העולם. לא ניתן לתקן TCP מבלי לעדכן כל מכשיר באינטרנט.
מה QUIC באמת הוא
QUIC הוא פרוטוקול תחבורה המספק מסירה אמינה ומסודרת — כמו TCP — אך פועל על גבי UDP. גוגל החלה לפתח אותו בשנת 2012; ה-IETF תקנן אותו בשנת 2021.
הבסיס של UDP חשוב. UDP פשוט: הוא שולח מנות ללא ערבויות. אין לחיצות יד, אין סדר, אין אמינות. QUIC בונה את כל התכונות הללו על גבי UDP, אך בקוד אפליקציה ולא בגרעין. פירוש הדבר שהוא יכול להתפתח מבלי לחכות לעדכוני מערכת הפעלה.
TCP הוא תשתית קבורה באדמה. שינויה מצריך עדכון מיליארדי מכשירים שתחזוקם בידי אלפי ארגונים — טלפונים, שרתים, נתבים, חיישני IoT. אפילו שינויים קטנים ב-TCP לוקחים שנים להתפשט. QUIC עוקף זאת על ידי ריצה במרחב המשתמש, שם אפליקציות שולטות בעדכונים שלהן.
חיבורים בסיבוב אחד
QUIC משלב את לחיצת יד התחבורה עם לחיצת יד ה-TLS לחילוף אחד. הלקוח שולח את ה-hello שלו ופרמטרים קריפטוגרפיים; השרת מגיב עם ה-hello שלו והחיבור נוצר. סיבוב אחד, ואתה שולח נתונים מוצפנים.
למבקרים חוזרים, זה עוד יותר טוב. QUIC יכול לחדש סשנים קודמים ללא אף סיבוב. הלקוח שולח נתוני אפליקציה מוצפנים במנה הראשונה שלו. השרת יכול להגיב מיד. מצב 0-RTT הזה הוא מה שגורם ל-QUIC להרגיש מיידי בביקורים חוזרים.
זרמים שלא חוסמים זה את זה
בתוך חיבור QUIC יחיד, ניתן לפתוח מספר זרמים עצמאיים. לכל זרם יש ערבויות סדר משלו. אם מנה השייכת לזרם 4 אובדת, רק זרם 4 ממתין לשידור חוזר. זרמים 1, 2 ו-3 ממשיכים ללא הפרעה.
זה פותר את בעיית ה-Multiplexing של HTTP/2. כשהדפדפן שלך מבקש תמונה, גיליון סגנונות ותסריט דרך HTTP/2 על TCP, הם חולקים זרם בתים מסודר אחד. אבדה מנה מהתמונה, וגיליון הסגנונות והתסריט ממתינים גם הם. על QUIC, כל משאב מקבל זרם משלו. אובדן מנה משפיע רק על המשאב שאיבד אותה.
זו הסיבה שקיים HTTP/3 — גרסת HTTP הבנויה על QUIC. הפרוטוקול לא יכול היה להגיע לפוטנציאל שלו על TCP.
מיגרציית חיבורים
TCP זוכר אותך לפי מיקומך: כתובת ה-IP והפורט שלך. התזוז — החלף רשת — וה-TCP שוכח שאתה קיים. החיבור נשבר. אתה מתחיל שוב בטקס לחיצת היד.
QUIC מעניק לחיבורים מזהה במקום זאת. כשהטלפון שלך עובר מ-WiFi לרשת סלולרית, כתובת ה-IP שלך משתנה, אך מזהה החיבור שלך לא. חיבור ה-QUIC נודד לנתיב הרשת החדש ללא הפרעה. שיחת הווידאו שלך נמשכת. ההורדה שלך מתחדשת.
בילינו עשרות שנים בבניית אינטרנט אמין על בסיס שנשבר ברגע שאתה עובר מהסלון למטבח. מיגרציית חיבורים פותרת זאת.
הצפנה אינה אופציונלית
TCP מתייחס להצפנה כעניין נפרד. ניתן להריץ TCP ללא TLS. אפליקציות רבות עושות זאת, בין אם בכוונה ובין אם בשגגה.
QUIC מצפין הכל מלבד לחיצת היד הראשונית. אין מצב לא מוצפן. לא ניתן לפרוס QUIC בשגגה ללא הצפנה, מכיוון שהפרוטוקול אינו תומך בכך.
זה הופך את האינטרנט לבטוח יותר כברירת מחדל. זה גם מקשה יותר להתערב ב-QUIC — middleboxes לא יכולים לבדוק או לשנות את מה שהם לא יכולים לקרוא.
HTTP/3: היישום העיקרי של QUIC
HTTP/3 הוא הפרוטוקול הגדול הראשון באינטרנט הבנוי על QUIC. בעוד ש-HTTP/1.1 ו-HTTP/2 פועלים על TCP, HTTP/3 פועל על QUIC בלבד.
השילוב פותר כל בעיית ביצועים שעמה התמודד HTTP/2. אין חסימת ראש תור בין בקשות. אין הקמת חיבור בשני סיבובים. אין חיבורים שנשברים כשרשתות משתנות. HTTP/3 הוא מה ש-HTTP/2 רצה להיות, אפשרי סוף סוף מכיוון ששכבת התחבורה משתפת פעולה.
מציאות הפריסה
אימוץ QUIC גדל במהירות. Chrome, Firefox, Safari ו-Edge תומכים כולם ב-HTTP/3. Cloudflare, Fastly וספקי ענן גדולים מציעים נקודות קצה של QUIC. נכון לשנת 2025, כ-30–36% מהאתרים תומכים ב-HTTP/3, ובסביבות 40% מתעבורת Chrome משתמשת ב-QUIC2.
אך אתגרים נותרים. חלק מחומות האש הארגוניות חוסמות UDP פרט לפורטים ספציפיים. ציוד בדיקת מנות מעמיקה (deep packet inspection) עשוי שלא לטפל ב-QUIC כראוי. דפדפנים מיישמים מנגנון נסיגה: נסה QUIC תחילה, ואם נכשל — חזור ל-HTTP/2 על TCP.
תבנית הנסיגה הזו אומרת שאימוץ QUIC יכול לקרות בהדרגה. אתרים יכולים להפעיל HTTP/3 מתוך ידיעה שרשתות שאינן תואמות עדיין יעבדו. עם הזמן, כשציוד הרשת יהפוך למודע ל-QUIC, חיבורים רבים יותר ישתמשו בפרוטוקול המהיר יותר.
מדוע זה חשוב
QUIC מספק את אותן ערבויות כמו TCP — מסירה אמינה ומסודרת עם בקרת עומס — ללא המגבלות שנארזו עם הערבויות הללו לפני חמישים שנה. אין טקסי לחיצת יד. אין חסימת ראש תור בין נתונים שאין ביניהם קשר. אין זהות קשורה למיקום הרשת.
יתרונות הביצועים אמיתיים ומדידים, במיוחד ברשתות סלולריות, חיבורים עם זמן אחזור גבוה, וקישורים אלחוטיים עם אובדן מנות. אך השיעור העמוק יותר הוא אדריכלי: על ידי בנייה על גבי UDP במרחב המשתמש, QUIC יכול להתפתח במהירות עדכוני אפליקציה ולא במהירות עדכוני גרעין.
TCP לא הולך לשום מקום. אך האינטרנט יכול סוף סוף לקבל תחבורה אמינה שאינה מעניישת אותך על תנועה.
שאלות נפוצות על QUIC
מדוע QUIC משתמש ב-UDP במקום ליצור פרוטוקול חדש?
Middleboxes — חומות אש, NAT, מאזני עומס — מבינים UDP ומאפשרים מעבר. פרוטוקול תחבורה חדש לגמרי היה נחסם על ידי ציוד שאינו מזהה אותו. UDP מספק פונקציונליות בסיסית (מסירת מנות בסיסית) כדי ש-QUIC יוכל לבנות הכל על גביה, תוך שמירה על יכולת פריסה באינטרנט של היום.
האם QUIC תמיד מהיר יותר מ-TCP?
בדרך כלל, אך לא תמיד. ברשתות אמינות עם זמן אחזור נמוך ועם חיבורים ממושכים, ההבדל מצטמצם. יתרונות QUIC בולטים ביותר ברשתות עם זמן אחזור גבוה, בחיבורים סלולריים, ובתרחישים עם הקמת חיבורים תכופה. חידוש 0-RTT ועצמאות הזרמים חשובים ביותר כשהתנאים קשים.
האם אני יכול להשתמש ב-QUIC עבור אפליקציות שאינן HTTP?
כן. בעוד ש-HTTP/3 הוא יישום ה-QUIC הבולט ביותר, הפרוטוקול הוא לשימוש כללי. DNS-over-QUIC קיים. פרוטוקולי גיימינג, תקשורת בזמן אמת ואפליקציות מותאמות אישית יכולים כולם להשתמש בזרמים האמינים של QUIC. ה-IETF תכנן את QUIC כשכבת תחבורה, לא ספציפית לתעבורת אינטרנט.
מדוע לא ניתן לעדכן TCP כדי שיהיו לו תכונות אלה?
TCP מיושם בגרעיני מערכות הפעלה. שינויו מצריך עדכון לכל מערכת הפעלה בכל מכשיר — טלפונים, שרתים, נתבים, מכשירי IoT. זה מיליארדי מערכות שתחזוקן בידי אלפי ארגונים. אפילו שינויים קטנים ב-TCP לוקחים שנים להתפשט. QUIC עוקף זאת על ידי ריצה במרחב המשתמש, שם אפליקציות שולטות בעדכונים שלהן.
מקורות
האם דף זה היה מועיל?