מחזור הבקשה-תגובה

כל לחיצה היא שאלה. כל טעינת דף היא תשובה.

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

הלקוח תמיד מדבר ראשון

HTTP עוקב אחר כלל ברור: לקוחות שואלים, שרתים עונים. השרת אינו יכול לשלוח לך נתונים מיוזמתו — הוא יכול רק להגיב לבקשות שביצעת.

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

השרת שוכח אותך מיד

כאן נמצא החלק המוזר: השרת לא זוכר אותך.

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

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

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

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

בנינו את הזיכרון של האינטרנט על פרוטוקול שתוכנן לשכוח.

מה יש בבקשה

כל בקשת HTTP מכילה ארבעה חלקים:

השיטה מצהירה על הכוונה:

• GET: אחזר משהו מבלי לשנות אותו
• POST: שלח נתונים כדי ליצור משהו חדש
• PUT: החלף משהו לחלוטין
• PATCH: עדכן חלק ממשהו
• DELETE: הסר משהו

טוענים דף? GET. שולחים טופס? POST.

ה-URL מציין את היעד:

https://api.example.com/users/123?include=profile

הנתיב (/users/123) מזהה את המשאב. מחרוזת השאילתא (?include=profile) מעבירה פרמטרים.

כותרות מספקות הקשר — זוגות מפתח-ערך המתארים אותך ואת מה שאתה יכול לעבד:

• Host: לאיזה דומיין אתה פונה
• User-Agent: איזה תוכנה שולחת את הבקשה
• Accept: אילו פורמטים של תגובה אתה מבין
• Authorization: האישורים שלך
• Content-Type: הפורמט של הנתונים שאתה שולח
• Cookie: נתוני סשן ומזהים

הגוף נושא מטען עבור בקשות POST, PUT ו-PATCH — שליחות טפסים, נתוני JSON, העלאות קבצים. כותרת ה-Content-Type אומרת לשרת כיצד לפרש אותו.

מה יש בתגובה

תשובת השרת מורכבת משלושה חלקים:

קוד הסטטוס מסכם את התוצאה בשלוש ספרות:

• 2xx: הצלחה. קיבלת את מה שביקשת.
• 3xx: הפניה מחדש. מה שאתה רוצה נמצא במקום אחר.
• 4xx: שגיאת לקוח. שאלת לא נכון.
• 5xx: שגיאת שרת. השרת נשבר.

תראה 200 (OK) ללא הרף. 404 (Not Found) כשמשאבים לא קיימים. 500 (Internal Server Error) כשמשהו נכשל בצד השרת. 301 (Moved Permanently) כשתוכן עבר מיקום.

כותרות מספקות מטא-נתונים על התגובה:

• Content-Type: הפורמט של הגוף
• Content-Length: כמה בייטים מגיעים
• Set-Cookie: הוראות לאחסון נתונים לבקשות עתידיות
• Cache-Control: כמה זמן ניתן לעשות שימוש חוזר בתגובה זו
• Location: לאן ללכת (עבור הפניות מחדש)

הגוף מכיל את התוכן בפועל — HTML, JSON, תמונות, כל מה שביקשת.

חילופין שלמים

הדפדפן שלך מאחזר נתוני משתמש מ-API:

בקשה:

GET /api/users/123 HTTP/1.1
Host: api.example.com
User-Agent: Mozilla/5.0
Accept: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

תגובה:

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 145
Cache-Control: max-age=300

{
  "id": 123,
  "name": "Jane Smith",
  "email": "jane@example.com",
  "created_at": "2024-01-15T10:30:00Z"
}

ביקשת את משתמש 123 עם האישורים המתאימים. השרת אישר הצלחה (200), אמר לך שמדובר ב-JSON, ושלח את הנתונים. השיחה הסתיימה.

להישאר על הקו

HTTP המוקדם פתח חיבור TCP חדש עבור כל בקשה — כמו לנתק ולחייג מחדש בין כל משפט בשיחת טלפון.

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

השיחה הפכה מהירה יותר כשהפסקנו לנתק.

לאן הזמן הולך

מחזור בקשה-תגובה אינו מיידי. הזמן מצטבר:

1. חיפוש DNS: תרגום שם המארח לכתובת IP
2. לחיצת יד TCP: יצירת החיבור
3. משא ומתן TLS: הגדרת ההצפנה (עבור HTTPS)
4. עיבוד השרת: יצירת התגובה
5. העברת תוכן: שליחת הבייטים

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

להבין לאן הזמן הולך הוא האופן שבו גורמים לאינטרנט להרגיש מיידי.

שאלות נפוצות על מחזור הבקשה-תגובה

מדוע שרתים לא יכולים לשלוח נתונים ללא בקשה מקדימה?

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

מה קורה אם בקשה לא מקבלת תגובה?

לקוחות מגדירים זמן קצוב לתגובה. אם לא מגיעה תגובה בתוך פרק זמן מוגדר (לרוב 30 עד 60 שניות), החיבור נזנח ומוצגת שגיאה. ייתכן שהשרת קיבל את הבקשה ועיבד אותה — לא תדע. אי-ודאות זו היא הסיבה שפעולות אידמפוטנטיות (כאלה הבטוחות לנסות שוב) חשובות ברשתות לא אמינות.

כיצד קוקיות שומרות מצב אם HTTP חסר מצב?

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