גרסאות HTTP: 0.9, 1.0, 1.1, 2 ו-3

בכל פעם שאתה לוחץ על קישור, פוטונים דוהרים דרך סיבים אופטיים — לפעמים מעבר לאוקיינוסים שלמים. חבילה מניו יורק לטוקיו לוקחת לפחות 140 מילישניות הלוך ושוב, וזה ברשתות פיננסיות מותאמות במיוחד¹. חיבורים רגילים לוקחים יותר. כל ההיסטוריה של HTTP היא סירובה של האנושות לקבל את העיכוב הזה.

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

HTTP/0.9: פרוטוקול של שורה אחת

בשנת 1991, טים ברנרס-לי היה זקוק לדרך להביא מסמכים. הוא בנה את הדבר הפשוט ביותר האפשרי: התחבר לשרת, שלח GET /index.html, קבל HTML, התנתק. ללא כותרות. ללא קודי שגיאה. ללא אפשרות לשלוח תמונות או לדעת אם משהו השתבש. פשוט טקסט נכנס, טקסט יוצא.

זה היה HTTP/0.9 — שנקרא לפעמים "פרוטוקול של שורה אחת" כי זה בדיוק מה שהיה. שורה אחת של בקשה, זרם אחד של תשובה, חיבור נסגר.

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

HTTP/1.0: כותרות משנות הכל

עד שנת 1996, אנשים רצו לשלוח יותר מ-HTML בלבד. הם רצו תמונות, סוגי מסמכים שונים, הודעות שגיאה עם הגיון. HTTP/1.0 הוסיף את המנגנון שאפשר זאת: כותרות.

כותרות הן מטא-נתונים. Content-Type: image/png מספר לדפדפן מה הוא מקבל. User-Agent מזהה מי שואל. קודי מצב — 200 OK, 404 Not Found, 500 Internal Server Error — נתנו לשרתים אוצר מילים להסביר מה קרה.

HTTP/1.0 הוסיף גם את POST, כדי שטפסים יוכלו לשלוח נתונים, וכן HEAD, כדי שתוכל לבדוק אם משאב קיים מבלי להוריד אותו.

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

HTTP/1.1: שמור על הקו פתוח

ל-HTTP/1.1, שיצא ב-1997, היה רעיון גדול אחד: תפסיק לנתק.

חיבורים מתמשכים — הנקראים גם keep-alive — אפשרו לדפדפנים לעשות שימוש חוזר באותו חיבור TCP עבור בקשות מרובות. בקש את ה-HTML, קבל אותו, ואז בקש מיד את ה-CSS דרך אותו חיבור. ללא לחיצת יד חדשה. השרת פשוט... ממתין לבקשה הבאה.

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

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

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

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

במשך כמעט שני עשורים, HTTP/1.1 הניע את האינטרנט. זה היה מספיק טוב. עד שלא היה.

HTTP/2: תפסיק לחכות בתור

HTTP/2, שתוקנן ב-2015, תקף ישירות את חסימת ראש התור.

התובנה הייתה: למה לעבד בקשות בסדר בכלל? אם אתה ממתין לתמונה גדולה, למה קובץ CSS קטן צריך לחכות מאחוריה? HTTP/2 הכניס ריבוב — בקשות ותגובות מרובות משולבות על חיבור יחיד, מועברות כשהן מוכנות.

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

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

HTTP/2 הכניס גם דחיפת שרת: אם השרת יודע שתצטרך את style.css מיד אחרי index.html, למה לחכות שתבקש? פשוט שלח אותו. בפועל, זה התברר כקשה יותר לביצוע ממה שצפוי — שרתים לעתים קרובות ניחשו לא נכון — ואימוצו נותר מוגבל.

אבל ל-HTTP/2 הייתה בעיה עמוקה יותר שלא יכול היה לפתור. הריבוב קרה בשכבת ה-HTTP, אבל מתחת, הכל עדיין רץ על TCP. ול-TCP יש חסימת ראש תור משלו.

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

HTTP/3: החלף את הדלת

HTTP/3, שתוקנן ביוני 2022², עושה משהו רדיקלי: הוא נוטש את TCP לחלוטין.

התחלופה היא QUIC, פרוטוקול תחבורה הבנוי על UDP ותוקנן על ידי ה-IETF ב-2021³. QUIC מיישם אמינות לכל זרם בנפרד ולא לכל החיבור. אם חבילה עבור זרם אחד אובדת, רק אותו זרם נעצר. כל השאר ממשיך לזרום.

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

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

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

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

המעבר היה הדרגתי אבל יציב. נכון לסוף 2024, HTTP/3 נתמך על ידי למעלה מ-95% מהדפדפנים הגדולים ובערך שליש מ-10 מיליון האתרים המובילים⁴. השיפורים חשובים ביותר כאשר התנאים הם הגרועים ביותר — רשתות סלולריות עם אובדן חבילות, חיבורים עם השהיה גבוהה, בדיוק המצבים שבהם כל מילישניה של המתנה מיותרת כואבת.

התבנית

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

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

שאלות נפוצות על גרסאות HTTP

למה לא פשוט תיקנו את TCP במקום ליצור QUIC?

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

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

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

האם אני צריך לעדכן את האתר שלי עבור HTTP/3?

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

למה HTTP/2 משתמש בבינארי במקום בטקסט?

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

מה קרה לדחיפת השרת של HTTP/2?

זה היה רעיון טוב שהתברר כלא מעשי. שרתים לא יכלו לחזות בצורה אמינה מה לקוחות כבר שמרו במטמון, ולכן לעתים קרובות דחפו משאבים שהלקוח ממילא לא היה זקוק להם. Chrome מדד שרק 0.05% מהסשנים של HTTP/2 השתמשו בדחיפת שרת⁵. Chrome הסיר תמיכה באוקטובר 2022, ו-Firefox עקב ב-2024. האלטרנטיבה המומלצת היא 103 Early Hints, המאפשרת לדפדפנים להחליט בעצמם אם להביא משאבים מוצעים.

מקורות