HTTP - למה הוא נראה פשוט, אבל רחוק מלהיות כזה

אחרי שדיברנו על תורים, Latency ופשרות ברמת התקשורת, אפשר סוף-סוף להגיע לפרוטוקול שרוב האנשים פוגשים יום-יום - HTTP.

הוא נתפס כפרוטוקול “קל”: שולחים בקשה, מקבלים תשובה, וזהו.

אבל הפשטות הזו היא אשליה מכוונת.

HTTP הוא פרוטוקול של משמעת

HTTP אינו מנסה לפתור בעיות רשת. הוא מניח שהרשת בעייתית - ומתאים את עצמו לכך.

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

אין זיכרון, אין הבטחה להמשכיות, ואין ציפייה שהצד השני “יזכור” משהו.

זו אינה מגבלה - זו בחירה מודעת.

Statelessness כיתרון, לא כחיסרון

HTTP מוגדר כ-Stateless: כל בקשה היא עולם בפני עצמו.

המשמעות:

• השרת לא צריך לזכור מי ביקש קודם
• אין תלות בבקשות קודמות
• וכל בקשה יכולה להגיע לכל שרת זמין

זה מה שמאפשר:

• סקייל גבוה
• איזון עומסים
• והחלפת שרתים בלי לשבור את המערכת

המחיר: כל הקשר צריך להישלח שוב ושוב.

למה זה עובד למרות חוסר היעילות

לכאורה, לשלוח שוב הקשר זה בזבוז. בפועל, זה מה שמאפשר שרידות.

כשאין State:

• קריסה מקומית לא שוברת שיחות אחרות
• תורים מתקצרים מהר יותר
• והמערכת מתאוששת בקלות

HTTP מקריב אלגנטיות לטובת יציבות.

המשל

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

זה איטי יותר מאשר “להמשיך שיחה”, אבל אם הפקיד מתחלף - שום דבר לא הולך לאיבוד.

HTTP לא עומד לבד

HTTP יושב מעל:

• TCP (או פרוטוקול דומה)
• תורים
• ניתוב
• ומנגנונים שלא נראים לעין

הוא נראה פשוט רק כי שכבות אחרות סופגות את המורכבות במקומו.

ההשלכה המערכתית

כשמערכת מבוססת HTTP נראית איטית או לא יציבה, הבעיה כמעט אף פעם אינה ב-HTTP עצמו.

היא נמצאת:

• בתורים שמתחת
• ב-Latency שלא נמדד
• או ב-State שהוכנס “בטעות” מעליו

HTTP עובד טוב כל עוד לא מנסים להפוך אותו למשהו שהוא לא.

מבט קדימה

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

בפוסט הבא נעסוק בשאלה הזו בדיוק: למה פרוטוקולים כמעט אף פעם לא מוחלפים - ואיך העולם ממשיך קדימה בלי לעצור.