הקדמה.
אינטרנט כבר מלא בעמודים ופוסטים שמסבירים מה זה ואיך אוכלים את זה ברמת RFC ובאנגלית של application delivey experts. אני אנסה להסביר על HTTP/2 (או HTTPbis) בצורה יותר מופשטת, לאנשים שיודעים תקשורת, איך לא עוסקים בהקמת שרתי ווב לפרנסתם ורוצים רק להיות מעודכנים טכנולוגית. אם זאת, אשתדל להביא כמה שיותר מידע אודות הפרוטוקול. אז בוא נתחיל...
מה זה HTTP?
HTTP ממלא חלק קריטי בעידן האינטרנט העולמי. הוא מהווה כלי התחבורה מרכזי של כל התוכן האינטרנטי וקשה לראות עולם של היום ללא HTTP. כל אתר, אפליקציה, מכוניות וכל מיני דברים חכמים עם תקשורת נשענים על הפרוטוקול הזה. אז מה זה בעצם HTTP? בקצרה, זה אוסף של נוהלים שמגדירים איך יתקשרו השרת (אתר) והקליינט (דפדפן במכשיר הטלפון או במחשב, אפליקציה וכו׳). יש נוהל איך לפנות לשרת, יש נוהל איך לסיים את השיחה, איך לשלוח תמונה או סרטון, איך לזהות משתמש ועוד מלא מלא תרחישים ומסודרים בתוך נוהלים. את הנוהלים הללו ,שהופכים בסופו של דבר לתקן, מיישמים יצרני תוכנה וחומרה במוצרים שלהם וכך כולם מצליחים לעבוד מול כולם. מי שבעצם אחראי על כתיבה והמצאת התקנים הם שני גופים - IETF וW3C.
קצת היסטוריה.
פיתוח של הפרוטוקול כפי שאנו מכירים היום החל בתחילת שנות ה90 (למראות שרעיון של HTTP הולך הרבה יותר אחורה אל שנות ה80). הגרסה הראשונה של HTTP נחשפה ציבורית ב1996. כבר ב97 יצא גרסה 1.1 עם המון עדכונים מהותיים המון יכולות חדשות והיא למעשה הגרסה שנמצאת בשימוש עד היום על רוב השרתים. איך העולם התקדם והפרוטוקול של כמעט 20 שנה הופך לאט לאט למיושן וחברות החלו לחפש פתונות חדשים. ביולי 2012 חברת גוגל הוציא טיוטה של פרוטוקול ספידי (SPDY) שדי הפך לאבן היסוד של HTTP/2. במאי 2015 יצא התקן הרשמי וגוגל הודיעו שהם מפסיקים פיתוח ותמיכה בספידי לטובת HTTP/2.
מה כל כך צריך את HTTP/2?
HTTP/2 נועד לתת שיפורים מהותיים ולספק מענה למספר בעיות שקיימות בHTTP1.1:
- הקטנת ״זמן מבוזבז״. השאילתות של HTTP 1.1 לא יעילות בצורת עבודתם, ועל כל שאילתא על השרת לעבד אותה ולהחזיר תשובה נפרדה. הוא לא מודע לקונטקסט (לפעמים, על מנת להציג תוצאה אחת שלמה בצד הקליינט נדרשות מס׳ שאילתות ואפשר לאחד אותם לתשובה אחת ובכך לחסוך המון זמן ותעבורה מיותרת).
- שיפור ״יחסי עבודה״ בין HTTP וTCP. לTCP יש מנגנונים לתקשורת יעילה, אך HTTP 1.1 לא התשתמש בהם, למעשה את HTTP 1.1 לא עניין בכלל מצב הTCP, מה שיצר לפעמים כפל תעבורה והרבה בייטים מבוזבזים. התקן המקורי של HTTP 1.1 הגדיר 2 TCP קונקשנים לאתר. על מנת לעמוד בתקן, המפתחים היו מתחכמים, יוצרים דומיין חדש ובקוד היו מבקשים חלק מהעמוד מהדומיין השני. עם הזמן, מספר הקונקשנים בתקן עלה והיום ניתן לראות מספרים כמו 20-30 קונקשנים לקליינט, אך עדיין זה צורת עבודה מיושנת. מנגנונים כמו multiplexing של HTTP/2 באים לתת מענה לבעיה הזאת. HTTP/2 יודע להעביר את כל התעבורה במקביל על גבי TCP קונקשן בודד.
-דחיסה. בכל שאילתת HTTP, בראש השאילתא, נמצאים HTTP headers. תפקידם, לעזור לשרת (וגם לקליינט) להבין מה סוג המכונה שנמצאת בכל צד. האם זה טלפון? במידה וכן, השרת יציג אתר מותאם למכשירים ניידים. מה גודל המסך של הקליינט? איזה סוג קובץ הוא מבקש? באיזה שפה להציג את העמוד? האם זה בכלל אלפיקציה ולא דפדפן. הכל כתוב בheaderים. הבעיה היא האותם headerים נשלחים בכל שאילתה ולפעמים נוצר מצב אבסורדי שעבור 1 קילובייט מידע נשלחים 3, כאשר 2 מתוכם רק הheaderים. HTTP/2 פתור את הבעיה על משהו שנקרה HPACK וזה עובד ככה: בשאילתא הראשונה נשלחים כל הheaderים, הם נשמרים במטמון של כל צד, ובהמשך הסשן, נשלחים רק headerים חדשים או שונים.יכולת זו חוסכת המון זמן ותעבורה מיותרת.
-דחיפת שרת. עד היום אם הינו רוצים לקבל עדכני תוכן מתמשך, היינו עושים זאת בעזרת javascript למשל, שהיה בסופו של דבר מתורגם לשאילתות HTTP קצובות לפני הקצב של אותו javascript. בHTTP/2 דחיפת שרת נעשית ברמת הפרוטוקול, זאת אומרת שאפשר להגיד לשרת ״תשלח לי עדכונים כל חמש דקות״ בשאילתא הראשונה והוא כבר ידעג לשלוח. שוב, חסכון בטראפיק ומשאבים בשני הצדדים.
אלו החידושים הבולטים ורובם יתנו מענה ושיפור גם במהירות טעינת הדפים וגם בחיסכון בסוללה במכשירים הניידים.
כאן המקום להראות השוואה בין HTTP 1.1 וHTTP/2 (טוב, לא בדיוק 2, אלא SPDY, הHTTP/2 מציג תוצאות אף יותר טובות).
בתמונה הראשונה אני ניגשתי ליוטיוב, שתומך בSPDY בפרוטוקול HTTPS רגיל:
זום של ציר הזמן:
ניתן לראות ששאילתא ראשונה לקחה 1.36ש׳.
עכשיו בוא נפעיל את SPDY:
והנה הזום שלנו:
שימו לב, הפערים מגיעים ל300%!!! למה זה קורה ? כפי שהסברתי קודם, HTTP בפעול לא מסוגל לעבד יותר משאילתא אחת פר קונקשן, וזה יוצר את הblocking time שמצויין בעפור בציר הזמן של HTTPS. בHTTP/2 השאילתות נשלחות במקביל וזה חוסך כמויות אדירות של זמן יקר של שרת, קליינט וצרכן המידע.
רגע, אבל מה עם אבטחת מידע ?
בעקרון, תקן הHTTP/2 אינו מחייב הצפנה, למראת שגוגל די דחפה לכיוון הזה. כתוצאה מכך, רוב מפתחי SPDY/HTTP2 אימצו את העדפה כן לעבוד בSSL עם TLS 1.2 לפחות, אבל בהחלט ניתן לעבוד ללא הצפנה כמו שהיה בHTTP.
מאחר והתקן נמצא בחיטוליו, אני צופה חשיפות של פגיעויות (vulnerabilities) הן ברמת יישם התקן ע״י המפתח והן ברמה ההנדסית של התקן. למשל, יכולת דחיסת הheaderים כבר שנויה במחלוקת על פטנציאל להתקפות DoS על השרת. אני מניח שימצאו פתרונות גם לבעיות הללו, מאחר ויש יתרון מובהק לפרוטוקול החדש, ובמיוחד כשמדובר בחיסכון בעלויות, אני לא רואה אופציה לכישלון.
דבר נוסף שלא שייך לפרוטוקול עצמו, אבל די קשור אליו - כיום, רוב אתרי ווב מוגנים בעזרת חומת אש אפלקטיבית, הWAF. לא כל יצרני הWAF תומכים עדיין בHTTP/2 וגם אם תומכים, לא בטוח שגרסת תוכנה (או אפילו חומרה) אכן תומכת בזה. צריך להבין, WAF שלא תומך בHTTP/2 עיוור לחלוטין לכל תעבורה בHTTP/2, ואם מנהל האתר בחברה שלכם החליט ״איזה נחמד! בוא נפעיל HTTP/2 על האתר שלנו!״ מבלי להודיע לכם, זה כאילו הלך וכיבה את הWAF, כך שזאת נקודה חשובה שצריך לשים אליה לב.
איך HTTP/2 משפיע על ביצועי שרתים ?
-ביחס לHTTPS, הHTTP/2 צורך פחות CPU וזכרון של השרת.
-ביחס לHTTP, הHTTP/2 צורך פחות זכרון, אך קצת יותר CPU.
-ביחס לHTTP/S הHTTP/2 עובד עם הרבה פחות קונקשנים ובכח מעלה משמעותית את קיבולת השרת.
דברים שצריך לקחת בחשבון לפני שעוברים לHTTP/2.
החלטתם להתקדם לפרוטוקול החדש, סבבה, אבל אם אתם רוצים להקטין את הבעיות שבדרך, כדאי להתכונן לכך מראש.
צריך לזכור, שאם אתם מחליטים לעבור לHTTP/2 ולהנות מיכולות הביצועים שלו, כל הרכיבים בדרך מה קליינט עד לשרת צריכים להיות מסוגלים לתמוך גם הם בפרוטוקול. מווסתי עומסים, WAFים, רכיבי תוכן, ועוד ציודים שפותחים את HTTP/S צריכים לעבור בדיקה האם הם תומכים ומוגדרים לתמוך בHTTP/2.
שרתים - אני ממליץ לעכוב אחרי אתרי תמיכה של יצרני תוכנה של השרתים. מדובר בפרוטוקול ״צעיר״ ביש סיכוי גדול למציאת באגים ופגיעויות וכתוצאה מכך לעדכוני תוכנה לעתים קרובות.
הבדל בולט נוסף בין HTTP 1.1 וHTTP/2 הא שHTTP/2 פרוטוקול בינרי ולא טקסטואלי כמו קודמו. לכן, הtroubleshooting כאן הוא יותר מורכב, זאת אומרת שבשביל לצפות בתשדורות על השרת, נדרשים פארסרים או ספריות ש״לועסות״ את התעבורה ומציגות אותו בשפה אנושית. גם כלים כמו wireshark הוציאו תמיכה בסיסית בHTTP/2 עם טעינת מפתח לתוכו.
סיכום.
לפי כל הקריטריונים, הHTTP/2 מסתמן כמחליף מובהק לHTTP הישן, במיוחד אחרי שמפלצות כמו גוגל, פייסבוק, אפל ומייקורסופט עברו עליו. מהפוסט שלי ניתן לראות שיתרונות הפרוטוקול עולים בהרבה על חסרונותיו, הוא מהיר יותר, יעיל יותר, חסכוני יותר. אני מניח שחברות גדולות יעברו עליו הרבה יותר מוקדם מארגונים בינוניים וקטנים, וכנראה ישארו עם HTTP 1.1 עוד הרבה זמן, הרי זה עובד, למה לגעת (:?
נ.ב.
לצורך כתיבת פוסט זה עשיתי עבודת תחקיר די מקיפה, וזאת בנוסף לניסיון רב שנים שיש לי בתחום. אם בכל זאת הטעתי, לא הייתי ברור, לא חידדתי מספיק או סתם יש לכם הצעות לשיפור והערות מקצועיות לנושא, תפנו אליי. אתם יודעים איך למצוא אותי.
חג סוכות שמח וביי,
קובי.