HTTP/2 משפר העברה באמצעות ריבוב בקשות בחיבור אחד ודחיסת כותרות. HTTP/3 מעביר HTTP מעל QUIC, שיכול לצמצם חסימה בין זרמים בעקבות אובדן נתונים ולתמוך במעבר חיבור בין נתיבי רשת. פרוטוקול חדש אינו מבטל עבודת יישום, משאבים גדולים או ציור. בודקים את הגרסה שסוכמה בפועל ומודדים את מסלולי השימוש החשובים.
מזהים את מגבלות HTTP/1.1
משמעות HTTP כוללת שיטות, קודי מצב, כותרות ומשאבים. שכבת ההעברה קובעת איך ההודעות נעות. מעבר גרסה אינו משנה פעולת GET ביישום ואינו הופך תגובה אוטומטית לזכאית למטמון. לכן מאבחנים שינויי פרוטוקול ומדיניות שמירה בנפרד.
HTTP/1.1 תומך בחיבורים מתמשכים, אבל בשימוש דפדפן רגיל אינו מאפשר לשלב תגובות בחופשיות בחיבור אחד. Pipelining מוגבל בסדר ולא היה פתרון כללי מעשי לדפדפנים. לכן משתמשים בכמה חיבורים, עם מגבלות לפי מימוש. כל חיבור עשוי להוסיף הקמה ותחרות על משאבים.
כך התפתחו איחוד קבצים ופיזורם בין מארחים. לעיתים הם צמצמו המתנה, אך גם יצרו חבילות גדולות, DNS נוסף והקמת חיבורים. פרוטוקול מודרני משנה את האיזון, לא מצדיק ביטול אוטומטי של כל אופטימיזציה קודמת.
המדריך לזמן תגובת השרת מפריד המתנה לחיבור מהמתנה ליישום. כאשר יצירת HTML היא העיכוב המרכזי, שדרוג התעבורה יכול להשאירו כמעט ללא שינוי.
מבינים מה ריבוב ב-HTTP/2 משנה
HTTP/2 מייצג הודעות כמסגרות בינריות בזרמים. כמה זרמים יכולים לחלוק חיבור TCP ולהתקדם בלי להמתין לסיום כל תגובה מלאה. HPACK דוחס שדות כותרת ומצמצם מידע חוזר בחיבור.
ריבוב אינו רוחב פס בלתי מוגבל. הזרמים מתחרים על הקיבולת ותלויים בתזמון ובבקרת זרימה. בקשת כל המשאבים האופציונליים מיד יכולה לפגוע בקיבולת של תמונה או CSS חיוניים. גילוי ותעדוף משאבים חשובים גם כשההמתנה לחיבורים נראית אחרת.
HTTP/2 יורש את זרם הבתים המסודר של TCP. כשאובדן יוצר פער, TCP צריך לתקנו לפני מסירת הבתים המאוחרים לפי סדר. גם זרמי HTTP עצמאיים עלולים להתעכב. חסימת ראש תור בשכבת התעבורה שונה מסדר התגובות ב-HTTP/1.1 ומסבירה יתרון אפשרי של HTTP/3.
Server push הוא חלק מההיסטוריה של HTTP/2, אך אינו אופטימיזציה כללית שכדאי להסתמך עליה בדפדפנים מודרניים. הוא לא תחליף לגילוי ברור של משאבים. בודקים את התמיכה בפועל ומשתמשים במנגנוני טעינה נתמכים למשאבים הקריטיים.
בוחנים מה QUIC מוסיף ל-HTTP/3
HTTP/3 ממפה HTTP ל-QUIC, שכבת תעבורה מאובטחת ומרובבת מעל הודעות UDP. QUIC מספק זרמים אמינים, התאוששות מאובדן ובקרת גודש. שימוש ב-UDP אינו אומר שבתים נעלמים מהתגובה בלי תיקון. ההצפנה משולבת בהקמת החיבור.
אובדן בזרם אחד אינו מחייב זרמים אחרים להמתין לנתוניו באותה דרך כמו HTTP/2 מעל TCP. בקרת גודש משותפת, קיבולת ותלויות פרוטוקול עדיין קיימות. לכן לא נכון לומר שכל חסימה נעלמת או שהגרסה תמיד מהירה יותר ברשת עם אובדן.
מזהי חיבור QUIC יכולים לאפשר המשכיות כאשר נתיב הרשת משתנה, בכפוף לתמיכת הצדדים ולאימות הנתיב. מעבר בין Wi-Fi לסלולר הוא תרחיש בדיקה מועיל, לא הבטחה להמשך חלק בכל מכשיר. רשתות מסוימות מגבילות UDP ולכן מסלול חלופי חשוב.
חידוש חיבור עשוי לאפשר נתונים מוקדמים, המכונים 0-RTT. זה מתאים לחיבורים מחודשים מסוימים ולא לכל ביקור ראשון. סיכוני שידור חוזר מחייבים הגנות בשרת וביישום. אין להפעיל זאת ללא הבחנה לשינוי חשבון או תשלום. השקה תקינה של HTTP/3 אינה דורשת את כל האפשרויות הנוספות.
אלה ההבדלים המרכזיים בין הפרוטוקולים.
| מאפיין | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|
| תעבורה מקובלת בדפדפן | TCP, עם TLS ב-HTTPS | TCP עם TLS | QUIC מעל UDP |
| תגובות מקבילות בחיבור | מוגבלות לפי סדר תגובות | זרמים מרובבים | זרמי QUIC מרובבים |
| דחיסת כותרות | ללא HPACK או QPACK | HPACK | QPACK |
| הפרדה בעת אובדן | סדר TCP חל | TCP יכול לעכב את כל הזרמים | מסירה עצמאית יותר |
| צווארי בקבוק ביישום | נשארים | נשארים | נשארים |
בודקים מה הדפדפן באמת סיכם
ב-Network של Chrome DevTools מפעילים את עמודת Protocol דרך תפריט כותרות הטבלה. מרעננים ובודקים בנפרד את המסמך והמשאבים החשובים. h2 או h3 מתארים את החיבור לבקשה המסוימת. מקורות שונים באותו עמוד יכולים להשתמש בגרסאות שונות.
כאשר CDN מסיים את החיבור, העמודה מתארת דפדפן לקצה. בין ה-CDN למקור עשויה לפעול גרסה אחרת. מסמך h3 אינו מוכיח שהמקור תומך ב-HTTP/3, ופרוטוקול ישן מאחוריו אינו מבטל כל יתרון בצד המבקר. מדריך CDN ומטמון קצה מסביר את ההפרדה.
הדפדפן עשוי לגלות HTTP/3 דרך Alt-Svc או מנגנוני DNS נתמכים. בקשה ראשונה יכולה להשתמש בגרסה שונה מהבאות. חיבורים קיימים, הודעות שמורות, תעודות ו-UDP חסום משפיעים. מתעדים אם התחילה בדיקה בחיבור חדש ולא רק מרעננים שוב ושוב.
משתמשים ב-curl לאחר בדיקת היכולות של הבנייה המותקנת; לא כל גרסה תומכת ב-HTTP/3.
curl --version
curl --http2 -sS -o /dev/null -w '%{http_version}\n' https://example.com/
curl --http3-only -sS -o /dev/null -w '%{http_version}\n' https://example.com/בקשה ל-HTTP/3 בלבד מונעת בכוונה מעבר לחלופה ויכולה לחשוף בעיית תמיכה או חיבור. זו בדיקת אבחון ולא הדמיה מלאה של דפדפן. הגרסה שמודפסת לאחר הצלחה משמעותית יותר מהנחה שהאפשרות המבוקשת מבטיחה שימוש בה.
מפעילים בשכבה שבשליטתכם
באחסון מנוהל או CDN מתחילים בתיעוד הנוכחי ובלוח הבקרה. מוודאים איזה מארח ואיזה מקטע מושפעים. בודקים תעודה, חיבור למקור וחלופת HTTP/2. מתג פעיל ובקשת h3 ממשית הם ראיות שונות.
Apache HTTP Server 2.4 עם mod_http2 טעון מתעד את Protocols. בשרת וירטואלי עם TLS אפשר להציע HTTP/2 עם חלופת HTTP/1.1 באמצעות הקטע הבא.
Protocols h2 http/1.1שומרים את תצורת TLS והתעודות הקיימת. אין להסיק תמיכת HTTP/3 מ-mod_http2, משום שזו יכולת נפרדת. בודקים חבילה ושרת חזיתי נתמך לפני בחירת נקודת סיום החיבור.
ב-Nginx ההוראה העצמאית http2 on קיימת מגרסה 1.25.1. HTTP/3 דורש מודול מתאים וספריית TLS תואמת; התיעוד מתאר את המודול כניסיוני. ההוראות הבאות שייכות לבלוק TLS קיים עם תעודות תקינות והמודולים הדרושים.
הקטע מפעיל HTTPS מעל TCP ו-QUIC באותו מספר פורט, בשכבות תעבורה שונות.
listen 443 ssl;
listen 443 quic reuseport;
http2 on;
add_header Alt-Svc 'h3=":443"; ma=86400';משלבים מאזינים קיימים בלי לשכפל, במיוחד כאשר כמה שרתים וירטואליים חולקים כתובת. בודקים ירושת כותרות לפני add_header. מאפשרים UDP בפורט 443 בכל חומת אש ומאזן עומסים רלוונטיים ומשאירים TCP 443. משך הפרסום הוא ערך דוגמה ואינו הוכחה לנגישות QUIC.
מאמתים עם nginx -t ובודקים מלקוח חיצוני לפני הרחבה. אפשרויות בנייה, TLS ונתונים מוקדמים משתנות; משתמשים בתיעוד של הגרסה המותקנת. הקטע ובדיקת תחביר מוצלחת אינם תצורת אבטחה מלאה.
בוחנים מחדש פיזור דומיינים, sprites וחבילות גדולות
Domain sharding מפזר קבצים בין מארחים כדי להשיג חיבורים מקבילים. בריבוב מודרני הוא עלול להוסיף DNS וחיבורים מיותרים ולצמצם שימוש חוזר. מאחדים רק אחרי בדיקת תעודות, מטמון, עדיפויות ותוצאה בפועל. לעיתים חיבורים מתאחדים, אך אין להסיק שכל מארח נוסף נטול עלות.
Sprites מאחדים תמונות ועשויים להתאים לעיצוב מסוים. עם זאת, קובץ גדול עלול להוריד פיקסלים לא נחוצים ולבטל תוקף לתוכן לא קשור בעת שינוי. גם חבילת JavaScript אחת יכולה לצמצם בקשות ובמקביל לחייב כל מסלול לעבד יכולות שאינו צריך.
נמנעים גם מפיצול קיצוני לקבצים זעירים. לבקשות, כותרות, דחיסה ותיאום תלות עדיין יש עלות. מעדיפים גבולות פונקציונליים ומשווים טעינה ראשונה לניווט חוזר. מדריך מטמון הדפדפן מסביר כיצד קבצים יציבים עם טביעה משנים את ההשוואה.
מודדים יותר מרענון מהיר אחד
משווים מכשירים ורשתות מייצגים עם אותן גרסאות משאב, מצב מטמון ותנאי שרת. כוללים חיבורים חדשים ומחודשים, ביקורים חוזרים ומסלול שבו HTTP/3 אינו זמין. רושמים את הפרוטוקול שסוכם בפועל, לא רק את ההגדרה הרצויה.
מודדים הקמת חיבור, TTFB, השלמת משאב קריטי וביצועים נראים. אין לשנות יחד ניתוב CDN, דחיסה, מטמון ופרוטוקול כאשר רוצים לזהות סיבה. מטמון חם או צומת אחר יכולים להיראות כשיפור פרוטוקול.
מתעדים הגדרה וחלופות ברשימת בדיקת הביצועים. להעמקה משתמשים במאגר מדריכי השרת ובמפרט HTTP/3. שומרים את ההפעלה כאשר מסלולי השימוש אמינים והמדידה תומכת בתועלת, גם אם היא קטנה מהיתרון התאורטי.
