|
|
עמוד:103
HTTP bipVOVlD 2 . 2 . 3 פרוטוקול HTTP מגדיר כיצד לקוחות Web מבקשים דפי Web משרתים , וכיצד שרתים מעבירים את הדפיס המבוקשים אל הלקוחות . הגרסה של HTTP שנמצאת בשימוש רחב כיום היא גרסה , 1 . 1 אך ישנם דפדפנים שעדיין מממשים את הגרסה הקודמת . HTTP / 1 . 0 - שני הפרוטוקולים תואמים ולכן אין בעיה בהתקשרות . שני הפרוטוקולים נשענים על השירותים שפרוטוקול התובלה TCP מספק . לקוח HTTP יוצר קשר TCP עם השרת . לאחר יצירת הקשר , שני הצדדים ניגשים לשירותי TCP באמצעות השקעים , ( sockets ) או במונחי הדוגמה שהצגנו בסעיף הקודם , באמצעות תיבות הדואר שלהם . הלקוח מעביר אל השקע בקשות ( HTTP requests ) ומקבל מהשקע תגובות , ( HTTP responses ) שמגיעות מהשרת . באופן דומה , השרת מקבל מהשקע שלו בקשות HTTP ומעביר אל השקע תגובות . HTTP ברגע שהלקוח העביר בקשת HTTP לשקע , היא יוצאת משליטתו ועוברת לאחריות . TCP פרוטוקול TCP מספק שירות אמין , ולכן לאחר פרק זמן כלשהו הבקשות יופיעו בשקע של השרת TCP ) לא מתחייב על זמן העברה כלשהו . ( באופן דומה , תגובות , HTTP שמועברות על-ידי השרת לשקע שלו יופיעו , כעבור זמן מה בשקע של הלקוח . כאן רואים את אחד היתרונות הגדולים של עיצוב הרשת בשכבות י HTTP לא צריך לטפל באובדן מידע , בשגיאות תקשורת וכוי - זה התפקיד של . TCP מתכנת של שכבת היישום לא צריך לדעת כיצד TCP מתגבר על אובדני מנות וכיצד הוא מוודא שהמנות יועברו לצד השני לפי סדר שליחתן . דבר זה מפשט מאוד את הכתיבה של יישומי תקשורת . בפרק , 3 נדון TCP-n ונתאר את האלגוריתמים שמבטיחים העברה אמינה של מידע . מבנה ההודעות של HTTP האפיון שלק ד דח מפורט ב- ( HTTP / 1 . 0 ) RFC 1945 וב- , ( HTTP / 1 . 1 ) RFC 2616 ומגדיר את המבנה של ההודעות . יש שני סוגי הודעות ו הודעות בקשה והודעות תגובה . המבנה של הודעות בקשה נציג קודם הודעת בקשה ; ( request message ) להלן דוגמה טיפוסית ? GET / path / file , html HTTP / 1 . 1 Host : www . cet . ac . il Connection : close User-agent : Mozilla / 4 . 0 Accept-language : f r
|
|