HyperText Transfer Protocol
מתוך ויקיפדיה, האנציקלופדיה החופשית
HTTP, SMTP, FTP, IRC, SNMP ... | Application |
MIME, ASCII, Unicode ... | Presentation |
ASP, PPTP, SSH, NFS, RPC, DNS, SSL ... | Session |
TCP, UDP, SCTP, RTP, DCCP ... | Transport |
IPv4, IPv6, ICMP, RIP, IPX ... | Network |
Ethernet, Token ring, FDDI ... | Data Link |
802.11x WiFi, 10Base-T, Blue Tooth, DSL ... | Physical |
Application | HTTP, SMTP, FTP, DNS, DHCP, SSH, IRC, SNMP, SIP, IMAP4, MIME • TELNET, RPC, SOAP ... |
Transport | TCP, UDP, SCTP, RTP, DCCP, ICMP ... |
Network | IPv4, IPv6, ARP, IPX ... |
Physical | Ethernet, 802.11 WiFi, Token ring, FDDI ... |
HyperText Transfer Protocol (בראשי תיבות: HTTP) הוא פרוטוקול תקשורת שנועד להעברת דפי HTML ואובייקטים שהם מכילים (כמו תמונות, קובצי קול, סרטוני פלאש וכו') ברשת האינטרנט וברשתות אינטראנט. הפרוטוקול פועל בשכבת התוכנה של מודל OSI ובשכבת התוכנה של מודל TCP/IP.
התקשורת בין השרת ללקוח ב-HTTP נעשית באמצעות בקשות ששולח הלקוח ותשובות שמחזיר השרת. ראשית, הלקוח יוצר חיבור לכתובת ה-IP ולפורט שבו השרת נמצא, בדרך כלל פורט 80. לאחר מכן נשלחת הבקשה, הכוללת את הכתובת של האובייקט המבוקש (למשל, דף HTML) ופרטים נוספים על הבקשה ועל הלקוח. השרת קורא את הבקשה, מפענח אותה, שולח ללקוח תשובה בהתאם ולרוב מנתק את החיבור ללקוח כשהשליחה הסתיימה.
תוכן עניינים |
[עריכה] היסטוריה
הגרסה הראשונה של הפרוטוקול שהייתה בשימוש (0.9) הייתה פשוטה ביותר ולא תמכה ברוב האפשרויות הקיימות כיום. שיטת הבקשה היחידה בגרסה זו הייתה GET, לא הוגדרו שדות כותרת והבקשות לא כללו את גרסת ה-HTTP כפי שהן כיום. כתוצאה מכך הלקוח לא יכול היה להעביר לשרת שום אינפורמציה נוספת פרט לכתובת של העמוד המבוקש. התשובה של השרת הכילה את האובייקט שכתובתו ניתנה בבקשה, גם כן ללא שדות כותרת, ואינדיקציה לסוף ההודעה ניתנה על ידי ניתוק חיבור ה-TCP על ידי השרת. מכיוון שהתשובות הכילו רק את האובייקט המבוקש, הודעות שגיאה נשלחו גם הן בפורמט HTML ולא היה ניתן להבחין ביניהן לבין דפים רגילים.
במאי 1996 התפרסמה גרסה 1.0 של הפרוטוקול, שנמצאת עדיין בשימוש נרחב בעיקר על ידי שרתי פרוקסי. בגרסה זו נוספו שיטות הבקשה HEAD, POST, PUT, DELETE, LINK ו-UNLINK ובקשות נדרשו לציין את גרסת הפרוטוקול. תשובות השרת כללו עתה פרט לתוכן הדף המבוקש, קוד מיוחד שמציין את תוצאת הבקשה (ראו להלן), מלווה בהסבר טקסטואלי בן מספר מילים על משמעות הקוד. הוגדרו כ-30 שדות כותרת, שנועדו בין השאר לייעל את השימוש במטמון, לציין מראש את אורך ההודעה, לאפשר הפניות אוטומטיות בין דפים ולהעביר מידע נוסף.
הגרסה הנוכחית, 1.1, פורסמה ביוני 1999 והתבססה ברובה על גרסה 1.0. ההבדלים העיקריים בין גרסה זו לקודמתה הם שליטה טובה יותר במטמון, הוספת שיטות הבקשה OPTIONS ו-TRACE, תמיכה ב-multiple hosts ותוספות מתקדמות שמטרתן לייעל את אופן הפעולה של הפרוטוקול. כמו כן, הוסרו מספר אפשרויות שהיו קיימות בגרסה הקודמת, לרוב משום שנמצאו לא שימושיות. מאפיין חשוב שנתמך בגרסה זו הוא האפשרות להשתמש בחיבור יחיד עבור מספר בקשות, במקום לפתוח חיבור חדש עבור כל אובייקט שנמצא בדף שהתקבל בתשובה הראשונה.
נעשו נסיונות להרחיב את הפרוטוקול וליצור גרסה 1.2, אך הם לא יצאו לפועל.
[עריכה] בקשות HTTP
בקשות HTTP מורכבות מהנתונים הבאים:
- שיטת הבקשה.
- כתובת של האובייקט המבוקש.
- גרסת הפרוטוקול שלפיו מורכבת הבקשה.
- שדות כותרת המתייחסים לבקשה, ללקוח, או לתוכן הנמצא בגוף הבקשה.
- גוף הבקשה (אופציונלי).
[עריכה] שיטות בקשה
נכון לגרסה 1.1, קיימות 8 שיטות בקשה: GET, HEAD, POST, PUT, DELETE, OPTIONS, TRACE ו-CONNECT. ניתן לסווג אותן בשני אופנים: שיטות בטוחות לעומת שיטות לא בטוחות, ושיטות אידמפוטנטיות (idempotent) לעומת שיטות שאינן אידמפוטנטיות. סיווגים אלו נועדו להוות אינדקציה כללית עבור שרתים, דפדפנים ובוני אתרים באשר למידת ההשפעה של כל אחת מהשיטות על השרת ועל הלקוח.
שיטות בטוחות מוגדרות ככאלה שמיועדות רק לשם קבלת מידע מהשרת; הן לא אמורות לשמש, למשל, לשליחת מידע מהלקוח לשרת, לביצוע שינויים כלשהם במסדי נתונים שנמצאים על השרת וכו'. במילים אחרות, אין לשיטות אלה "תופעות לוואי" פרט לקבלת מידע. GET ו-HEAD נחשבות לשיטות בטוחות.
שיטות אידמפוטנטיות הן שיטות ששליחה חוזרת שלהן גורמת לאותן תופעות לוואי כמו שליחה אחת. שיטות שהן בטוחות הן, לפי ההגדרה, גם אידמפוטנטיות, משום שאין להן כלל תופעות לוואי. השיטות PUT ו-DELETE גם הן נכללות בסיווג זה.
אלו הן שיטות הבקשה הנתמכות בגרסה 1.1:
- GET
- מיועדת לקבלת אובייקט שנמצא על השרת, בכתובת שניתנת בתחילת ההודעה. בקשות GET הן הנפוצות ביותר ברשת האינטרנט.
- HEAD
- מבקשת מהשרת לשלוח את כל שדות הכותרת שהיו נשלחים לבקשת GET, אך בלי האובייקט עצמו. השיטה נועדה, בין השאר, לאפשר בדיקה של קישורים שבורים או זמני שינויים של אובייקטים מבלי לבקש את כל האובייקט.
- POST
- בקשות המכילות גוף הודעה. בקשות POST משמשות בדרך כלל לשליחה של נתונים מטפסי HTML לשרת לשם עיבוד.
- PUT
- מבקשת מהשרת לשמור את גוף ההודעה המצורף לבקשה בתור אובייקט, שכתובתו היא הכתובת שניתנה בתחילת הבקשה.
- DELETE
- מבקשת מהשרת למחוק את האובייקט שכתובתו מצוינת בתחילת הבקשה.
- OPTIONS
- מבקשת מהשרת מידע על דרכי התקשורת האפשריות ביחס לאובייקט מסוים או ביחס לשרת עצמו.
- TRACE
- מבקש מהשרת לשלוח את הבקשה בדיוק כפי שקיבל אותה. הדבר שימושי לבדיקה של תחנות הביניים שנמצאות בין הלקוח לשרת ומעבדות את ההודעות העוברות דרכן.
- CONNECT
- הפרוטוקול אינו מגדיר את השימוש ב-CONNECT, אך שומר את השיטה הזו לשימוש עבור שרתי פרוקסי שמסוגלים להתנהג כמו תעלות SSL (SSL tunnels).
[עריכה] כתובות בבקשות HTTP
כתובת בבקשת HTTP יכולה להיות כתובת מלאה (כמו: http://he.wikipedia.org/index.php) או כתובת יחסית לשרת (כמו: /index.php). השימוש בכתובות יחסיות הוא הנפוץ ביותר, דבר שהקשה בעבר על אחסון של מספר אתרים על אותו שרת, משום שהשרת לא יכול היה לדעת לאיזה אתר מבין האתרים המאוחסנים אצלו מכוונת הבקשה. כדי לפתור את הבעיה מבלי לאבד את התמיכה לאחור בגרסאות קודמות, גרסה 1.1 מחייבת כל בקשה לכלול שדה כותרת בשם host, שערכו הוא שם המתחם של האתר אליו מיועדת הבקשה.
[עריכה] תשובות HTTP
לאחר קריאת הבקשה ששלח הלקוח, השרת מחזיר תשובה שמכילה:
- גרסת הפרוטוקול שלפיה נבנתה הודעת התשובה.
- קוד מצב המציין את התוצאה של ניסיון השרת למלא את הבקשה שנשלחה. הקוד מורכב ממספר תלת-ספרתי והסבר טקסטואלי קצר על משמעותו.
- שדות כותרת המכילים מידע על הודעת התשובה ועל השרת.
- גוף הודעה שתוכנו תלוי בשיטת הבקשה ובקוד המצב.
[עריכה] קוד המצב ומשמעותו
כאמור, קוד המצב מורכב ממספר תלת ספרתי והסבר קצר (בן שורה אחת) על משמעות הקוד. המספרים מתחלקים ל-5 מחלקות, בהתאם לספרה הראשונה שלהם:
1xx - ההודעה מכילה מידע אינפורמטיבי בלבד.
2xx - הבקשה ששלח הלקוח בוצעה בהצלחה על ידי השרת, והתשובה מכילה את מה שהשרת נתבקש לשלוח בהתאם לשיטת הבקשה.
3xx - הבקשה פוענחה בהצלחה, אך מסיבות כלשהן התשובה אינה כוללת את האובייקט המבוקש (למשל, משום שהעמוד מפנה אוטומטית לעמוד אחר).
4xx - נמצאה שגיאה כלשהי בבקשה עצמה.
5xx - השרת לא הצליח למלא אחר הבקשה כתוצאה מכשל פנימי.
אם לקוח מקבל תשובה מהשרת שמכילה קוד שלא מוכר לו, הפרוטוקול מציע ללקוח לשייך את הקוד לאחת המחלקות הנ"ל לפי הספרה הראשונה ולפעול כאילו שתי הספרות הנותרות היו 00. כך מתאפשרת הרחבה של הפרוטוקול תוך שמירה על תמיכה לאחור.
HTTP 1.1 מגדיר 41 מספרי מצב בצירוף ההסבר הטקסטואלי הנלווה להם, למרות שאין חובה להשתמש בהסברים המופיעים בפרוטוקול.
[עריכה] שדות כותרת
הגרסה הנוכחית של HTTP תומכת ב-47 שדות כותרת, נוסף על מספר הרחבות שהתווספו עם הזמן (כגון תמיכה בקוקיות). רבים מהם מבוססים על פרוטוקול MIME המשמש לשליחת הודעות בדואר אלקטרוני. כמעט כל השדות הם אופציונליים, פרט ל-host עבור בקשות, ושדות מסוימים המציינים את אורך גוף ההודעה עבור הודעות שבהן הוא לא ריק. עם זאת, מספר שרתים (כגון זה של ויקיפדיה העברית) מחייבים שימוש בשדות שאינם חובה בדרך כלל.
[עריכה] persistent connections
בגרסה 1.0 הלקוח נאלץ לפתוח ולסגור את החיבור מחדש פעמים רבות, גם כשהיה ידוע מראש על מספר בקשות שעתידות להישלח לשרת. מצבים כאלה יצרו עומס מיותר, ולכן לקוחות ושרתים ניסו ליישם שיטה לשימוש בחיבור יחיד עבור מספר בקשות. השיטה ייעלה מצבים כמתוארים לעיל, אך יצרה מספר בעיות בחיבורים לשרתי פרוקסי.
גרסה 1.1 שיפרה את המנגנון כך שיהיה ניתן להשתמש בו גם עם שרתי פרוקסי. המנגנון נוצר כך שיתאם גם למנגנון הקודם וגם לשרתים ישנים יותר. בנוסף, תוארו מספר מנגנונים ומוסכמות לשימוש יעיל ב-persistent connections, הוגדר אופן הטיפול בבעיות שעלולות להיווצר באחת או יותר מהבקשות והוקדש קוד מצב מיוחד (שמספרו 100) לניצול נוסף של המנגנון.
[עריכה] מטמון
השליטה במטמון ב-HTTP נעשית בשני אופנים, הנקראים "מנגנון האימות" ו"מנגנון התפוגה". מנגנון האימות מבוסס על פריט מידע שמוצמד לכל עמוד ונשלח יחד איתו. פריט המידע הזה יכול להיות התאריך האחרון בו שונה העמוד או מספר זיהוי הקרוי Entity tag המשתנה בכל פעם שתוכן העמוד משתנה. כשלקוח או שרת מטמון שולחים בקשה לעמוד מסוים שיש בידם עותק שלו שהתקבל מבקשה קודמת, הם מצרפים לבקשה את אחד מהנתונים האלו שנשלח בפעם האחרונה שהעמוד התקבל. לפי הנתון הזה, השרת יכול לדעת אם העותק עדכני, ואם לא לשלוח את העמוד המעודכן במלואו, כפי שהיה שולח בתגובה לבקשה רגילה (כולל הנתונים החדשים שמצורפים אליו). אם העמוד לא השתנה, השרת שולח תשובה קצרה ללא גוף, שקוד המצב שלה הוא 304 (Not Modified), ובכך חוסך את שליחת העמוד כולו.
מנגנון התפוגה מבוסס על הצמדת "תאריך תפוגה" לכל עמוד שמתקבל מהשרת. עד לתאריך זה, ניתן להשתמש בעמוד שהתקבל ללא כל תקשורת נוספת עם השרת. לאחר שהתאריך עבר, הבקשה הראשונה שתתקבל תישלח אל השרת לשם קבלה מחודשת של העמוד, לעתים תוך שימוש במנגנון האימות. תאריך התפוגה יכול להיקבע על ידי השרת, אולם לרוב הוא נקבע בעזרת כללי אצבע על ידי המטמון בהתחשב בתאריך הנוכחי, בתאריך השינוי האחרון של העמוד אם הוא ידוע ובנתונים נוספים.
השליטה במטמון נעשית בעזרת מספר שדות כותרת מיוחדים, ובעיקר בעזרת השדה Cache-Control המשמש הן לקוחות והן שרתים לשליטה באופן שבו הצד השני יטפל במטמון. בעזרתו, לקוח יכול להורות לשרת מטמון שעשוי להימצא בינו לבין השרת המקורי לאמת את העמוד שהוא מבקש אפילו אם הוא נמצא אצלו ותאריך התפוגה שלו עדיין לא עבר, או לחילופין לשלוח לו את העמוד רק אם הוא נמצא אצלו בזיכרון מבלי לתקשר עם השרת. שרתים יכולים להורות ללקוח או לשרתי מטמון לא לשמור את העמוד שהם שולחים, לשמור אותו רק בתנאים מסוימים וכו'. שדות כותרת נוספים משמשים להצמדת נתונים רלוונטיים לעמודים שהשרת שולח או לבקשות אימות של עמודים שנמצאים בזיכרון מטמון.