IETF (Internet Engineering Task Force), שאחראי לפיתוח פרוטוקולי אינטרנט וארכיטקטורת אינטרנט, השלים את היווצרותו של RFC עבור פרוטוקול HTTP/3.0 ופרסם מפרטים קשורים תחת המזהים RFC 9114 (פרוטוקול) ו-RFC 9204 ( טכנולוגיית דחיסת כותרות QPACK עבור HTTP/3) . מפרט ה-HTTP/3.0 קיבל מעמד של "Proposed Standard", שלאחריו יתחילו עבודה לתת ל-RFC סטטוס של טיוטת תקן (Draft Standard), כלומר למעשה ייצוב מוחלט של הפרוטוקול ובהתחשב בכל ההערות שהועלו. במקביל, פורסמו גרסאות מעודכנות של המפרטים עבור פרוטוקולי HTTP/1.1 (RFC 9112) ו-HTTP/2.0 (RFC 9113), וכן מסמכים המגדירים את הסמנטיקה של בקשות HTTP (RFC 9110) וכותרות בקרת מטמון HTTP (RFC 9111).
פרוטוקול HTTP/3 מגדיר את השימוש בפרוטוקול QUIC (Quick UDP Internet Connections) כתחבורה עבור HTTP/2. QUIC הוא הרחבה של פרוטוקול UDP התומך בריבוי של מספר חיבורים ומספק שיטות הצפנה שוות ערך ל-TLS/SSL. הפרוטוקול נוצר בשנת 2013 על ידי גוגל כחלופה לשילוב TCP+TLS עבור האינטרנט, פותר בעיות עם הגדרת חיבור וזמני משא ומתן ארוכים ב-TCP ומבטל עיכובים כאשר מנות אובדות במהלך העברת הנתונים.
נכון לעכשיו, תמיכת QUIC ו-HTTP/3.0 כבר מיושמת בכל דפדפני האינטרנט הפופולריים (ב-Chrome, Firefox ו-Edge, תמיכה ב-HTTP/3 מופעלת כברירת מחדל, וב-Safari היא דורשת את ההגדרה "מתקדם > תכונות ניסוי > HTTP/3" להיות מופעל). בצד השרת, הטמעות HTTP/3 זמינות עבור nginx (בסניף נפרד ובצורת מודול נפרד), Caddy, IIS ו-LiteSpeed. תמיכת HTTP/3 מסופקת גם על ידי רשת אספקת התוכן Cloudflare.
תכונות עיקריות של QUIC:
- אבטחה גבוהה בדומה ל-TLS (בעצם QUIC מספק את היכולת להשתמש ב-TLS על UDP);
- בקרת שלמות זרימה, מניעת אובדן מנות;
- היכולת ליצור חיבור מיידי (0-RTT, בכ-75% מהמקרים ניתן להעביר נתונים מיד לאחר שליחת חבילת הגדרת החיבור) ולספק עיכובים מינימליים בין שליחת בקשה לקבלת תגובה (RTT, Round Trip Time);
- שימוש במספר רצף אחר בעת שידור חוזר של חבילה, מה שמונע אי בהירות בזיהוי מנות שהתקבלו ונפטר מפסקי זמן;
- אובדן מנה משפיע רק על מסירת הזרם הקשור אליה ואינו מפסיק את מסירת הנתונים בזרמים מקבילים המועברים דרך החיבור הנוכחי;
- תכונות תיקון שגיאות הממזערות עיכובים עקב שידור חוזר של מנות אבודות. שימוש בקודי תיקון שגיאות מיוחדים ברמת החבילה כדי לצמצם מצבים הדורשים שידור חוזר של נתוני מנות שאבדו.
- גבולות בלוקים קריפטוגרפיים מיושרים עם גבולות מנות QUIC, מה שמפחית את ההשפעה של הפסדי מנות על פענוח התוכן של מנות עוקבות;
- אין בעיות עם חסימת תור TCP;
- תמיכה במזהה חיבור, שמפחית את הזמן שלוקח ליצירת חיבור מחדש עבור לקוחות ניידים;
- אפשרות לחיבור מנגנוני בקרת גודש בחיבור מתקדמים;
- משתמש בטכניקות חיזוי תפוקה לכל כיוון כדי להבטיח שמנות נשלחות בקצבים אופטימליים, ולמנוע מהן להיעשות עמוס ולגרום לאובדן מנות;
- עלייה משמעותית בביצועים ובתפוקה בהשוואה ל-TCP. עבור שירותי וידאו כגון YouTube, הוכח כי QUIC מפחית את פעולות ההדחה בעת צפייה בסרטונים ב-30%.
בין השינויים במפרט ה-HTTP/1.1, ניתן לציין את האיסור על שימוש מבודד בתו החזרה (CR) מחוץ לגוף עם תוכן, כלומר. ברכיבי פרוטוקול, תו ה-CR יכול לשמש רק בשילוב עם תו הזנת השורה (CRLF). אלגוריתם פריסת הבקשה החתוכה שופר כדי לפשט את ההפרדה בין שדות וקטעים מצורפים עם כותרות. נוספו המלצות לטיפול בתוכן מעורפל כדי לחסום התקפות "הברחת בקשות HTTP", המאפשרות לנו להכנס לתוכן של בקשות של משתמשים אחרים בזרימה בין ה-frontend ל-backend.
עדכון מפרט HTTP/2.0 מגדיר במפורש תמיכה ב-TLS 1.3. הוצא משימוש ערכת העדיפויות ושדות הכותרת המשויכים. המנגנון שאינו בשימוש לעדכון החיבור עם HTTP/1.1 הוכרז מיושן. דרישות מופחתות לבדיקת שמות וערכים של שדות. כמה סוגי מסגרת ופרמטרים ששמורים בעבר מוצעים לשימוש. שדות הכותרת האסורים הקשורים לחיבור מוגדרים בצורה מדויקת יותר.
מקור: OpenNet.ru