1. תקשורת מחשבים ואלגוריתמים מבוזרים
קורס מס'
הרצאה שישית – שכבת היישום
תקשורת מחשבים ואלגוריתמים מבוזרים (חורף )

2. שכבת האפליקציה (Application Layer)
Physical
Link
Network
Transport
Session
Presentation
The 7-layer OSI Model
Application
Presentation
Session
Introduction to Communication Networks 2/2009

3. שכבת היישום אפליקציות P2P הבנת העיקרון TCP עם Socket Programming
עקרונות של UDP עם Programming Socket
עקרונות הפרוטוקולים של השכבה.
הבנת המושגים Web, HTTP.
עקרון פעולת .FTP
עקרונות הפעולה של פרוטוקולי דוא"ל: SMTP, POP3, IMAP.
הבנת המושג DNS ועקרון פעילותו.
Introduction to Communication Networks 2/2009

4. שכבת היישום המטרה שלנו: להבין רעיונית את יישום של פרוטוקולי רשת:
מודל שירות שכבת ההובלה.
מודל תקשורת שרת – לקוח (client-server).
מודל תקשורת "קצה לקצה" (peer-to-peer).
ללמוד על הפרוטוקולים על ידי בחינת יישום פופולרי ברמת פרוטוקולים:
HTTP
FTP
SMTP / POP3 / IMAP
DNS
תכנות יישומים ברשת:
socket API
Introduction to Communication Networks 2/2009

5. מספר יישומי הרשת voice over IP real-time video conferencing
grid computing
web
instant messaging
remote login
P2P file sharing
multi-user network games
streaming stored video clips
Introduction to Communication Networks 2/2009

6. יצירת רשת היישום נכתוב תוכנית ש: אין צורך לכתוב תוכנה עבור התקני
application
transport
network
data link
physical
נכתוב תוכנית ש:
תרוץ כל מערכות קצה (שונות).
תתקשר דרך הרשת.
לדוגמא, תוכנת שרת web מתקשרת עם תוכנת הדפדפן.
אין צורך לכתוב תוכנה עבור התקני
ליבת הרשת:
התקני ליבת הרשת אינם מריצים יישומי משתמש.
יישומים על מערכות הקצה מאפשרים פיתוח מהיר של יישומים והפצתם.
application
transport
network
data link
physical
application
transport
network
data link
physical
Introduction to Communication Networks 2/2009

7. שכבת היישום אפליקציות P2P הבנת העיקרון TCP עם Socket Programming
עקרונות של UDP עם Programming Socket
עקרונות הפרוטוקולים של השכבה.
הבנת המושגים Web, HTTP.
עקרון פעולת .FTP
עקרונות הפעולה של פרוטוקולי דוא"ל: SMTP, POP3, IMAP.
הבנת המושג DNS ועקרון פעילותו.
Introduction to Communication Networks 2/2009

8. שרת – לקוח (Client-server). קצה לקצה (Peer-to-peer (P2P)).
ארכיטקטורות היישומים
שרת – לקוח (Client-server).
קצה לקצה (Peer-to-peer (P2P)).
"הכלאה" של שרת – לקוח ו-קצה לקצה.
Introduction to Communication Networks 2/2009

9. Introduction to Communication Networks 2/2009
ארכיטקטורת שרת-לקוח
שרת:
תמיד ב-מארח.
כתובת IP קבועה.
ניתן לעבוד עם חוות שרתים עבור קנה מידה גדול.
לקוח:
מתקשר עם השרת.
עשויים להיות מחובר לסירוגין
יכול לקבל כתובת IP משתנה.
אין קשר ישיר עם כל אחד אחר.
client/server 9
Introduction to Communication Networks 2/2009

10. ארכיטקטורת קצה לקצה טהורה (Pure P2P )
לא תמיד ב-Server
באופן שרירותי מערכות הקצה מתקשרות ישירות.
העמיתים מתקשרים לסרוגין ומשנים את כתובות ה-IP שלהם.
מדרגי אבל קשה מאוד לניהול
peer-peer 10
Introduction to Communication Networks 2/2009

11. "הכלאה" של שרת – לקוח ו-קצה לקצה.
Skype:
אפליקציה של P2P ו-voice-over-IP.
שרת מרכזי: מציאת כתובת של צד מרחוק.
חיבור בין לקוח ללקוח: ישיר (לא דרך שרת).
Instant messaging:
צ 'אט בין שני משתמשים הוא P2P.
שרת מרכזי: נוכחות לקוח, כיוון / מיקום.
המשתמש רושם את כתובת ה-IP שלו בשרת המרכזי כאשר הוא הופך למקוון (online).
המשתמש מתקשר לשרת המרכזי כדי למצוא כתובות IP של חברים.
Introduction to Communication Networks 2/2009

12. תהליכים בתקשורת תהליך (Process): תוכנית הרצה בתוך מחשב מארח.
בתוך אותו המארח, שני תהליכים מתקשרים משתמשים בתקשורת בין תהליכים (שמוגדרת על ידי מערכת ההפעלה).
תהליכים במחשבים מארחים שונים מתקשרים ע"י החלפת הודעות.
תהליך לקוח: תהליך שמאתחל
את התקשורת.
/תהליך שרת: תהליך שממתין מחכה להיות
בקשר
שים לב: אפליקציות עם ארכיטקטורות קצה לקצה (P2P) יש תהליך לקוח ותהליך שרת.
Introduction to Communication Networks 2/2009

13. Introduction to Communication Networks 2/2009
ממשקים (Sockets)
Socket - ממשק כלשהו בין האפליקציה לרמה התחתונה, הנותנת את השירות.
בTCP ה-socket (ממשק) מזוהה ע"י 4 שדות:
כתובת IP יעד.
מס' port יעד.
כתובת IP מקור.
מס' port מקור.
תהליך שולח/מקבל הודעות מ/אל הממשק.
ממשק מקביל לדלת
תהליך שליחת הודעה דוחף את הדלת החוצה.
תהליך השליחה מסתמך על תשתית תעבורה בצד השני של הדלת אשר מביא את ההודעה לממשק בתהליך הקבלה.
process
TCP with
buffers,
variables
socket
host or
server
process
TCP with
buffers,
variables
socket
host or
server
controlled by
app developer
Internet
controlled
by OS
API(Application Program Interface):
(1) בוחר את פרוטוקול התעבורה.
(2) יכול לתקן מספר פרמטרים. 13
Introduction to Communication Networks 2/2009

14. API ממשק (Application Program Interface)
כדי לקבל מידע האפליקציה מתקשרת לפרוטוקול בעזרת ממשק Socket API.
הפונקציות שנקבעות ע"י Socket API:
בחירה של סוג שירות התעבורה – TCP / UDP.
האם השירות קשור ב- connection (ואז צריך לפתוח, להעביר הודעה, לקבל הודעה ולסגור).
זיהוי היעד – היעד הוא האפליקציה שאיתה רוצים לדבר במחשב היעד.
בעזרת ה- API אנחנו מסמנים עם איזו אפליקציה אנחנו מדברים.
לכל תהליך במחשב צריך להיות מזהה. המזהה הינו זיהוי המחשב, IP Address, שהינו כתובת של 32 ביט. אך כתובת המחשב אינה מספיקה כי על אותו מחשב יכולים לרוץ מספר תהליכים ומספר אפליקציות, ויש צורך לזהות לאיזה מהם נשלחת הודעה מסוימת. לכן מציינים בנוסף גם מהו ה- port שעליו יושבת האפליקציה.
ה- port הוא שער שמזהה את האפליקציה באופן ייחודי על אותו המחשב.
דוגמאות ל- port קבועים:
port 80 משרת את שרת ה- HTTP.
port 25 משרת את שרת הדואר SMTP.
מה קורה אם מספר אפליקציות מנסות לקרוא מאותו ה- port? – זהו מצב אסור וגורם לשגיאות. על מנת להתגבר על כך יש כמה מנגנונים - יש מנגנון שבוחר port לכל אפליקציה וכן יש מנגנון שמקצה Port בצורה דינמית. 14
Introduction to Communication Networks 2/2009

15. Introduction to Communication Networks 2/2009
ממשקים (המשך)
בחירת שירות תעבורה
אובדן מידע – בחלק מהיישומים אמינות העברת הנתונים חשובה מאוד.
תקורה – מספר הסיביות ליחידת מידע שאינן כוללות את המידע אלה מספקות אינפורמציית בקרה.
תקורה התחלתית – פרמטר משמעותי ליישומים ששולחים התרעות לא באופן קבוע ופחות קריטי ליישומים עם קשר ארוך.
רוחב פס – פרמטר קריטי לתעבורה
זמן השהיה – קריטי לתעבורה
תהליך הפניה
לצורך הגדרת נמען/שולח, יש להגדיר במדויק את הכתובת של תחנת קצה. זוהי הכתובת IP.
כתובת IP מכילה 32 סיביות. כתובת מלאה של התחנה מכילה IP ומספר ה-port שאליו פונה אפליקציה מסוימת.
לחלק של האפליקציות קיימים port קבועים וידועים כמו כן יש גם אפליקציות שמשתמשות ב-port דינאמיים. 15
Introduction to Communication Networks 2/2009

16. על סמך מה מתבצעת בחירת שירותי התעבורה?
הבחירה מתבצעת על סמך מאפייני שירות התעבורה:
אמינות יש צורך באמינות של התעבורה. שירות TCP למשל, מבטיח אמינות גבוהה. בשירות זה כאשר מגיע מידע שגוי הדבר יזוהה ויישלח מחדש. הסיבה שלא כל היישומים משתמשים בשירות זה הוא בגלל התקורה (overhead) הגבוהה.
רוחב פס יש אפליקציות שרוחב הפס אינו קריטי עבורן. לדוגמא – דואר אלקטרוני, גלישה לאתרים. ולעומת זאת ישנן הרבה אפליקציות אחרות שבהן רוחב הפס הוא גורם מהותי לתפקודן, כגון video conference, streaming audio. באפליקציות מהסוג האחרון, אם לא יהיה רוחב פס מינימלי אזי אין טעם לשרות.
השהיה (עיכוב) יש אפליקציות שיכולות לעבוד עם השהיה מקסימלית מסוימת ויותר ממנה הן אינן יכולות לעבוד.
setup overhead באפליקציות מסוימות ההודעה הנשלחת בכל פעם קצרה מאוד, ולעיתים קורה מצב בו יצירת הקשר וה- hand shaking לוקחים יותר זמן מאשר שליחת ההודעה עצמה.
בדרך כלל, מערכת שצריכה רוחב פס גדול מבטיחה להשהיה קצרה, אך לא תמיד – לווין לדוגמא זקוק לרוחב פס גדול וגם ההשהיה גדולה. 16

17. הגדרת פרוטוקולי שכבת יישומים
פרוטוקולים ציבורים (Public-domain)
מוגדרים ב- RFCs.
מאפשרים יכולת פעולה הדדית (היכולת של שני מחשבים מסוג שונה לתפקד ביחד ולתקשר).
לדוגמא: HTTP, SMTP
פרוטוקולים בעלי קניין
(Proprietary):
לדוגמא: SKYPE.
סוג של החלפת מידע:
לדוגמא בקשה, תגובה.
תחביר ההודעה:
מה בשדה הודעות & כיצד השדות מותוות
Message semantics
סמנטיקה ההודעה:
משמעות המידע בשדות.
כללים עבור מתי וכיצד תהליכים נשליחים & תגובה להודעות.
Introduction to Communication Networks 2/2009

18. לאיזה שירות תעבורה שכבת היישום זקוקה?
קצב העברה (Throughput, כמות
הנתונים שניתן להעביר באפיק נתונים
או דרך התקן בשנייה אחת)
חלק מהיישומים (לדוגמא multimedia) דורשים סכום המינימלי של קצב העברה על מנת להיות יעילים.
ישומים אחרים ("יישומים גמישים") יכולים להשתמש בכל קצב העברה שהם מקבלים.
אבטחה (Security):
הצפנה, שלמות הנתונים (Encryption, data integrity)...
אובדן מידע (Data loss):
חלק מהיישומים (לדוגמא קול) יכולים לסבול חלק מהאובדנים.
יישומים אחרים (לדוגמא file transfer, telnet) דורשים 100% אמינות בהעברת המידע.
תזמון (Timing):
חלק מהיישומים (לדוגמא טלפונית אינטרנט, משחקים) דורשים עיכוב קטן ביותר על מנת להיות "יעילים".

19. שירות תעבורה הנדרש עבור יישומים נפוצים
שירות תעבורה הנדרש עבור יישומים נפוצים
Application
file transfer
Web documents
real-time audio/video
stored audio/video
interactive games
instant messaging
Data loss
no loss
loss-tolerant
Throughput
elastic
audio: 5kbps-1Mbps
video:10kbps-5Mbps
same as above
few kbps up
Time Sensitive no
yes, 100’s msec
yes, few secs
yes and no
Introduction to Communication Networks 2/2009

20. פרוטוקולי תעבורה באינטרנט
שרות UDP:
אין תהליך של handshaking, אין הקמת קשר ואין תהליך של סגירת קשר בצורה מסודרת.
אין אמינות, המידע פשוט נשלח, ואין שום אינדיקציה האם הוא הגיע ליעד או לא.
אין בקרת זרימה.
אין בקרת עומס.
שרות :TCP
שירות connection oriented. בתחילת השידור יש handshaking על מנת לקבוע את צורת הקשר.
אמינות – מבטיח כי כל החבילות יגיעו ובאותו הסדר שנשלחו.
בקרת זרימה – השולח לא ישלח יותר ממה שהיעד יכול לקבל ולטפל. על מנת להבטיח זאת יש שימוש בחוצצים אם מגיעות יותר מדי הודעות.
בקרת עומס – אם הרשת איטית מדי, אפליקציית השולח מקבלת הודעה על כך על מנת שתתאים את הקצב שלה לקצב הרשת.
התעבורה זורמת דרך נתבים, אך שירות התעבורה נמצא רק בשרת ובלקוח.
TCP לא מבטיח לשים חסם על ההשהיה או השהיה מקסימלית, וכן הוא אינו מבטיח רוחב פס. אך הוא ייתן אינדיקציה על כך.
Introduction to Communication Networks 2/2009

21. דוגמאות לאפליקציות ולפרוטוקולים בהן הן משתמשות:
Transport Protocol
Application Layer Protocol
Application
TCP
SMTP
Telnet
remote terminal access
HTTP
Web
FTP
file transfer
TCP or UDP
proprietary
streaming multimedia
usually UDP
Internet telephony
Introduction to Communication Networks 2/2009

22. שכבת היישום אפליקציות P2P הבנת העיקרון TCP עם Socket Programming
עקרונות של UDP עם Programming Socket
עקרון בניית שרת Web.
הרעיון של שכפול תוכן (Content distribution).
עקרונות הפרוטוקולים של השכבה.
הבנת המושגים Web, HTTP.
עקרון פעולת .FTP
עקרונות הפעולה של פרוטוקולי דוא"ל: SMTP, POP3, IMAP.
הבנת המושג DNS ועקרון פעילותו.
Introduction to Communication Networks 2/2009

23. Web and HTTP מספר מושגים בז'רגון: עמוד WEB מכיל אובייקטים.
אובייקט יכול להיות קובץ HTML, תמונה JPEG וכו'
עמוד WEB מבוסס על קובץ HTML ובד"כ מכיל אובייקטים נוספים
לכל עמוד כזה ניתן לגשת בעזרת כתובת URL
דוגמא ל- URL:
host name
path name
Introduction to Communication Networks 2/2009

24. פרוטוקול של אפליקציות WEB. תומך במודל לקוח/שרת
HTTP סקירה על
HTTP (hypertext transfer protocol)
פרוטוקול של אפליקציות WEB.
תומך במודל לקוח/שרת
לקוח: דפדפן שמבקש, מקבל ומציג אוביקטי WEB.
שרת: שרת WEB שולח אוביקטים כתגובה לבקשה.
HTTP request
PC running
Explorer
HTTP response
HTTP request
Server
running
Apache Web
server
HTTP response
Mac running
Navigator
Introduction to Communication Networks 2/2009

25. (המשך) HTTP סקירה על הוא חסר מצב HTTP “stateless”)): שימוש ב-TCP:
השרת לא שומר מידע על בקשות הלקוח האחרון.
שימוש ב-TCP:
לקוח יוזם חיבור TCP (יוצר ממשק) לשרת ב-port 80.
השרת מקבל חיבור TCP מהלקוח.
הודעות HTTP (application-layer protocol messages) מוחלפות בין הדפדפן (לקוח HTTP) ושרת Web (שרת HTTP).
חיבור TCP נסגר.
הפרוטוקולים ששומרים על "מצב" הם
מורכבים!
ההיסטוריה שעברה (מצב) חייבת להיות מוחזקת.
אם השרת/לקוח קורסים, המבט שלהם של "המצב" יכול להיות לא עקבי, בעיה זו חייב להיות מוסדרת.
Introduction to Communication Networks 2/2009

26. חיבור HTTP HTTP לא עקבי לכל היותר אובייקט אחד נישלח מעל חיבור TCP.
פרוטוקול HTTP/1.0 משמש עבור HTTP לא עקבי (nonpersistent HTTP).
HTTPעקבי
מספר אובייקטים ניתנים לשליחה מעל חיבורTCP בין הלקוח לבין השרת.
פרוטוקול HTTP/1.1 משמש עבור HTTP עקבי (Persistent HTTP).
Introduction to Communication Networks 2/2009

27. סיכום סקירה על HTTP
פרוטוקול זה משתמש תמיד ב-TCP. מספר ה-port שאליו מתחבר הלקוח הוא 80.
HTTP הוא פרוטוקול stateless. השרת לא שומר רשימת מצבים, ואינו יודע מה היו הבקשות הקודמות של הלקוח. לכן כל בקשה צריכה להכיל מספיק מידע. לשם ההשוואה, FTP הוא lstatefull, כלומר השרת זוכר את המצב ויודע מהן הבקשות הקודמות. היתרון בשימוש בפרוטוקול statelessב-HTTP הוא שמימוש הפרוטוקול יותר פשוט. לכן, אם יש פרוטוקול שניתן לעשותו גם כ- stateless וגם כ- statefull" עדיף להשתמש ב- stateless.
בגרסא הראשונה (1.0) של HTTP לא שמרו על עקביות הקשר (היא היתה non-persistent connection). אחר כך זיהו שניתן להשתמש באותו הקשר למספר בקשות ובגרסא 1.1 הפכו מצב זה למצב הרגיל (connection persistent).
HTTP זוהי אפליקציה חשובה ושימושית ביותר באינטרנט. היא מורכבת מאובייקטים כגון דף HTML, תמונה, Java applet, קבצי מדיה וכו'. האובייקט הראשי הוא קובץ HTML הכולל בתוכו קישורים לקבצים אחרים.
כל אובייקט מזוהה על ידי URL/URI המורכב משם הפרוטוקול, DNS וכתובת פנימית.
ה-HTTP זהו הפרוטוקול של רמת האפליקציה בו משתמשים ב- web. הוא מדמה מודל של שרת-לקוח, כאשר הלקוח הוא הדפדפן אשר מבקש, מקבל ומציג אוביקטים כמתואר בפסקה קודמת, והשרת הוא שרת ה- web ששולח את האובייקטים ללקוח לפי בקשתו.
בתחילה השתמשו ב- HTTP 1.0 שמתואר ב- RFC 1945, וכיום משתמשים ב- HTTP 1.1 שמתואר ב- RFC 2068.
Introduction to Communication Networks 2/2009

28. לא עקבי HTTP
נניח המשתמש מקיש את ה-URL הבא:
(contains text, references to 10
jpeg images)
.1a הלקוח (הדפדפן) מתחיל קשר עם שרת web על פי ה- domain שלו ב-port 80.
1b. השרת מקבל את הקשר
ומודיע על כך ללקוח.
2. הלקוח שולח בקשה לקבל דף HTML מסוים (מזוהה על ידי URL).
.3 השרת מקבל את הבקשה, שולח הודעת תשובה שמכילה בתוכה את אובייקט ה- HTML.
time
Introduction to Communication Networks 2/2009

29. (המשך) לא עקבי HTTP 4. הלקוח מקבל את ההודעה ומציג את דף ה- HTML.
.5 הלקוח מבצע parsing של דף ה- HTML שהתקבל.
time
6. וחוזרים על שלבים 1-5 עבור כל אובייקט נוסף שנמצא בדף ה- HTML (כגון תמונות, קבצי מדיה וכו').
Introduction to Communication Networks 2/2009

30. ניתוח זמן תגובה ו-RTT (Round Trip Time)
זמן תגובה (response time) עבור חיבור לא עקבי:
RTT אחד על מנת ליצור את הקשר.
RTT נוסף על מנת לשלוח את הבקשה הראשונה ולקבל את התשובה.
זמן שליחת הקובץ.
total = 2RTT+transmit time
time to
transmit
file
initiate TCP
connection
RTT
request
received
time 30

31. השוואה בין סוגי ההתחברות השונים
HTTP לא עקבי :
דורש 2RTT עבור כל אובייקט.
בהרבה מקרים אובייקט אחד דורש שימוש בכמה TCP connections.
כל TCP connection דורש משאבים, ולכן שיטה זו בזבזנית מאוד.
HTTP עקבי:
דורש RTT ליצירת הקשר, ורק RTT אחד עבור כל אובייקט.
לאורך כל הקשר משתמשים באותו TCP connection בין השרת ללקוח.
שיטה זו חסכונית יותר, משום שהיא זקוקה ליצירת קשר פעם אחת בלבד.
HTTP עקבי עם חפיפה (pipelining):
דורש RTT אחד עבור כל הבקשות הנשלחות במקביל.
הלקוח שולח בקשות ברגע שהוא מזהה את הצורך באובייקט חדש.
זהו מצב ה- default ב- HTTP 1.1.
HTTP עקבי ללא חפיפה (pipelining):
דורש RTT ליצירת הקשר, ורק RTT אחד עבור כל אובייקט.
השרת מטפל בבקשה חדשה רק כאשר הלקוח סיים לקבל את התשובה הקודמת.
Introduction to Communication Networks 2/2009

32. פורמט הבקשה ב- HTTP 32 GET /somedir/page.html HTTP/1.1
ישנם שני סוגי הודעות: request (בקשה) ו- response (תשובה).
השורה הראשונה מתארת את צורת העברת המידע (get, post), את ה-URL של הקובץ המבוקש ואת הפרוטוקול (לדוגמא – HTTP/1.1).
GET /somedir/page.html HTTP/1.1
Host:
User-agent: Mozilla/4.0
Connection: close
Accept-language:fr
(extra carriage return, line feed)
לאחר שורה זו בא שאר ה- header של ההודעה המכיל מידע חיוני ושימושי, כגון שם השרת, השפה וכו'.
לאחר מכן יש שורה רווח המזהה את סוף ההודעה.
השורה הראשונה היא שורת הבקשה, המודיעה כי מבקשים את האובייקט /somedir/page.html ב-
HTTP גרסא 1.1 בצורת GET .
השורה השניה מודיעה כי הבקשה ממוענת לשרת בשם
השורה השלישית מכילה מידע לגבי סוג וגרסת הדפדפן, במקרה זה Mozilla גרסא 4.0.
השורה הרביעית מודיעה לשרת כי הלקוח רוצה שהשרת יסגור את קשר ה- TCP אחרי שליחת האובייקט.
השורה החמישית מודיעה מהי השפה שבה הלקוח מעדיף לקבל את האובייקט.
לאחר מכן באה שורה רווח המזהה את סוף ההודעה. 32

33. שיטות להעברת המידע ישנן שלוש צורות עיקריות להעברת המידע: שיטת GET:
המידע מועבר בכותרת, לאחר סימן שאלה, ואין שימוש בגוף ההודעה. כלומר מיועדת לקבלת אובייקט שנמצא על השרת, בכתובת שניתנת בתחילת ההודעה. הצורה הנפוצה ביותר באינטרנט.
שיטת POST:
המידע מועבר בגוף ההודעה. בקשות POST משמשות בדרך כלל לשליחה של נתונים מטפסי HTML לשרת לשם עיבוד.
שיטת HEAD :
צורה זו דומה מאוד ל- POST, כאשר בתשובה השרת לא מעביר את האובייקט המבוקש. כלומר מבקשים מהשרת לשלוח את כל שדות הכותרת שהיו נשלחים לבקשת GET, אך בלי האובייקט עצמו. השיטה נועדה, בין השאר, לאפשר בדיקה של קישורים שבורים או זמני שינויים של אובייקטים מבלי לבקש את כל האובייקט. שיטה זו נפוצה בעיקר עבור בדיקות שנעשות על ידי המתכנתים בשלבי הפיתוח.
Introduction to Communication Networks 2/2009

34. פורמט הבקשה ב- HTTP (המשך)
הפורמט הכללי של הודעת הבקשה נראה כך:
השורה הראשונה נקראת "שורת הבקשה" (request line) והיא מתארת את צורת העברת המידע
(get, post), את ה- URL של הקובץ המבוקש ואת הפרוטוקול (לדוגמא – HTTP/1.1).
לאחר שורה זו ישנן "שורות הכותרת" ((header lines של ההודעה המכילות מידע חיוני ושימושי,
כגון שם השרת, השפה וכו'.
לאחר מכן יש שורה רווח, ואז בא "גוף ההודעה" (entity body).

35. Introduction to Communication Networks 2/2009
טעינת טופס הקלט
שיטת POST:
לעתים קרובות דף אינטרנט כולל את טופס קלט.
קלט מועלה אל השרת בגוף ההודעה.
שיטת URL:
משתמש בשיטת GET.
קלט יועלה בשדה ה-URL של "שורת הבקשה" :
Introduction to Communication Networks 2/2009

36. סוגי השיטות HTTP/1.0 GET POST HEAD HTTP/1.1 GET, POST, HEAD PUT DELETE
מבקש מהשרת לא להעביר את האובייקט המבוקש.
HTTP/1.1
GET, POST, HEAD
PUT
טוען קובץ לגוף ההודעה לנתיב שצוין בשדה כתובת האתר
DELETE
מוחק קובץ שצוין בשדה האתר.
Introduction to Communication Networks 2/2009

37. צורת הודעת ה-HTTP response
status line
(protocol
status code
status phrase)
HTTP/ OK
Connection close
Date: Thu, 06 Aug :00:15 GMT
Server: Apache/1.3.0 (Unix)
Last-Modified: Mon, 22 Jun 1998 …...
Content-Length: 6821
Content-Type: text/html
data data data (e.g., <html><body>)
header
lines
data, e.g.,
requested
HTML file
הסבר לדוגמא:
השורה הראשונה היא שורת הסטטוס, המודיעה כי האובייקט נמצא והוא תקין ונשלח ב- HTTP גרסא 1.1.
השורה השניה מודיעה ללקוח כי השרת סוגר את קשר ה- TCP אחרי שליחת ההודעה.
השורה השלישית מכילה את הזמן המדויק בו נוצרה הודעת התשובה ונשלחה על ידי השרת.
השורה הרביעית מכילה מידע לגבי סוג וגרסת השרת, במקרה זה Apache גרסא למערכת unix.
השורה החמישית מודיעה מהו תאריך העדכון האחרון של האובייקט שנשלח בגוף ההודעה.
השורה השישית מודיעה מהו גודל האובייקט הנשלח.
השורה השביעית מודיעה מהו סוג האובייקט, במקרה זה דף HTML.
לאחר מכן באה שורה רווח ואז האובייקט עצמו.
Introduction to Communication Networks 2/2009

38. צורת הודעת ה-HTTP response
הפורמט הכללי של הודעת הבקשה נראה כך:
השורה הראשונה נקראת "שורת הסטטוס" (status line) והיא מתארת את הפרוטוקול, קוד המצב וביטוי המתאר את המצב (טבלה בשקף הבא).
לאחר שורה זו ישנן "שורות הכותרת" ((header lines של ההודעה המכילות מידע חיוני ושימושי, כגון תאריך ושעה, סוג השרת וכו'.
לאחר מכן יש שורה רווח, ואז בא "גוף ההודעה" (entity body). בהודעת התשובה, גוף ההודעה מכיל את האובייקט עצמו.
Introduction to Communication Networks 2/2009

39. דוגמאות לקודי מצב ב-HTTP
הטבלה הבאה מכילה כמה דוגמאות לקודי מצב:
ביטוי המתאר את המצב
קוד המצב
תיאור המצב OK
200
הבקשה התקבלה, והאובייקט המבוקש מצורף לתשובה
Moved Permanently
301
האובייקט המבוקש זז, המיקום החדש המצוין בהמשך ההודעה (מיקום:)
Bad Request
400
השרת לא מסוגל לפענח את הבקשה
Not Found
404
האובייקט המבוקש לא נמצא על השרת
HTTP Version Not Supported
505
גירסת HTTP לא נתמכת
Introduction to Communication Networks 2/2009

40. הרשאות גישה
לעיתים ישנו על השרת מידע שלא כל אחד יכול לגשת אליו. במצב זה השרת צריך לבדוק את הרשאות הגישה של המשתמש. בדרך כלל אישור הרשאות הגישה נעשה על ידי שימוש בשם משתמש וסיסמא.
תהליך אישור הרשאות הגישה מתבצע כך:
בשלב הראשון, הלקוח שולח בקשה רגילה לקבלת האובייקט.
בשלב השני, השרת עונה לו עם גוף הודעה ריק ועם סטטוס בקשה 401 Authorization Required. בהודעה זו השרת גם מוסיף שדה המכיל פרטים על כיצד לבצע את אישור הרשאות הגישה.
בשלב השלישי, הלקוח מקבל את התשובה ושולח חזרה לשרת הודעה חוזרת של בקשה לקבלת האובייקט, אך כעת נוספת שורה לכותרת המכילה את הפרטים הנחוצים לשם אישור הרשאות הגישה.
בפרוטוקול stateless, בכל בקשה לאובייקט שדרושה לו הרשאת גישה יש לבצע את כל התהליך מחדש.
Introduction to Communication Networks 2/2009

41. "עוגיות" (cookies)
מנגנון זה מאפשר לשרת לשמור מידע מסוים אצל לקוח. זה עוזר לתקשורת וזיהוי בין שרת ללקוח.
מבנה ה- Cookies מכיל 4 רכיבים:
שדה כותרת בהודעה מכיל תגובה של HTTP
שורת הכותרת מכילה בקשה של HTTP
קובץ שנשמר במחשב הלקוח
פרטים שנשמרים בבסיס נתונים של השרת
מה Cookie יכול להביא לשרת :
זיהוי משתמש.
כרטיסי קניה.
הודעות .
מידע על פעילות המשתמש אינטרנט.
סכנה : פריצת אבטחה וחשיפת פרטיות במחשבי קצה.
Introduction to Communication Networks 2/2009

42. סקירה על "עוגיות"
על מנת לשמור את הרשאות המשתמש ולמנוע את החזרה על תהליך אישור הרשאות הגישה, ישנם אתרים רבים המחזיקים "עוגיות" (cookies). הדפדפן שומר את העוגיות הללו המכילות פרטים על המשתמש, ובכל פעם שהוא שולח בקשה לשרת, הוא מצרף ל- header את הפרטים השמורים בעוגיה המתאימה לשרת אליו הוא פונה.
מתי השימוש בעוגיות יעיל? כאשר המשתמש נוהג לגשת לאתר מסוים רק ממחשב אחד. במצב כזה, במקום להזין בכל פעם מחדש את שם המשתמש והסיסמא (או אפילו את פרטי כרטיס האשראי באתרי e-commerce), עליו לעשות זאת פעם אחת בלבד, ומאותו הרגע, הדפדפן יודע לשלוח את המידע הזה באופן אוטומטי לשרת.
עוגיה יכולה להמחק באחת משתי דרכים – או שהמשתמש מוחק ידנית את הקובץ בו נשמר המידע, או ש"פג תוקפה". לכל עוגיה יש תאריך ושעה בו היא נמחקת לבד ואז יש לאשר מחדש את הפרטים, הנשמרי בעוגיה חדשה המחליפה את העוגיה הקודמת.
Introduction to Communication Networks 2/2009

43. "העוגיות" שומרות על מצב server creates ID 1678 for user
client
server
usual http request msg
usual http response +
Set-cookie: 1678
cookie: 1678
usual http response msg
cookie-
specific
action
spectific
Cookie file
ebay: 8734
server
creates ID
1678 for user
entry in backend
database
Cookie file
amazon: 1678
ebay: 8734
access
one week later:
access
Cookie file
amazon: 1678
ebay: 8734
Introduction to Communication Networks 2/2009

44. עוגיות (המשך) מה "העוגיות" יכולות להביא: הרשאה כרטיסי הקניה המלצות
בצד
מה "העוגיות" יכולות להביא:
הרשאה
כרטיסי הקניה
המלצות
משתמש ברשת (אינטרנט דואר אלקטרוני)
קבצי Cookie ופרטיות:
קבצי ה-Cookie באתר מאפשרים ללמוד הרבה עלייך.
תוכל לספק שם ודואר אלקטרוני לאתרים.
מנועי חיפוש משתמשים ניתוב מחדש & בקבצי Cookie כדי ללמוד עוד יותר.
חברות פרסום משיגות מידע דרך גישה לאתרים.
כיצד לשמור על "מצב":
פרוטוקלי נקודות קצה: שומרים על מצב בשולח/ במקבל במשך מספר עסקאות.
"עוגיות": הודעות http נושאות את "המצב".
Introduction to Communication Networks 2/2009

45. מטמוני אינטרנט (Web caching (proxy server))
מטרה: לספק את בקשת הלקוח ללא מעורבות של השרת המקורי.
origin
server
המשתמש מגדיר דפדפן: כניסות לאינטרנט דרך המטמון.
הדפדפן שולח את כל בקשות
ה-HTTP למטמון
אובייקט המטמון: המטמון מחזיר אובייקט
אחרת המטמון מבקש אובייקט מהשרת המקורי, ואז מחזיר אוביקט לקוח.
HTTP response
Proxy
server
HTTP request
client
HTTP request
HTTP response
client
origin
server
הגדרה: מטמון (cache) הוא רכיב לאחסון מידע שבו נשמרים נתונים כדי שניתן יהיה לאחזרם במהירות או בזול. ברשת מטמון הוא העתק של עמוד רשת אשר נמצא ומאוחסן לדוגמא במנוע החיפוש.
Introduction to Communication Networks 2/2009

46. עוד על Web caching המטמון (cache) פועל גם בלקוח וגם בשרת.
מטמון מותקן בדרך כלל על ידי ספק שירותי האינטרנט (אוניברסיטה, חברה מסחרית וכו').
למה Web caching:
לצמצם את זמן התגובה לבקשת הלקוח.
להקטין את התנועה על מוסד הגישה של הקישור.
אינטרנט צפוף עם מטמון: מאפשרת לספק תוכן "עני" ביעילות.
Introduction to Communication Networks 2/2009

47. דוגמא ל- Caching הנחות: תוצאות: ממוצע גודל האובייקט= 100,000 bits
קצב בקשות ממוצע מהדפדפנים לשרת המקור = 15/sec
עיכוב מהנתבים המוסדיים לכל שרת מקור וחזרה לנתב = 2 sec
תוצאות:
ניצול על ה-LAN = 15%.
ניצול על גישות לערוץ = 100%.
עיכוב כללי =
עיכוב באיטרנט + עיכוב בגישה + עיכוב ב-LAN =
2 sec + minutes + milliseconds
origin
servers
public
Internet
1.5 Mbps
access link
institutional
network
10 Mbps LAN
institutional
cache
Introduction to Communication Networks 2/2009

48. דוגמא ל- Caching(המשך)
origin
servers
פתרון אפשרי:
להגדיל את רוחב הפס של הגישה לערוץ, נאמר, 10 Mbps
תוצאות:
ניצול על ה-LAN = 15%.
ניצול על גישות לערוץ = 15%.
עיכוב כללי = עיכוב באיטרנט + עיכוב בגישה + עיכוב ב-LAN =
2 sec + msecs + msecs
בדרך כלל יקר לשדרוג.
public
Internet
10 Mbps
access link
institutional
network
10 Mbps LAN
institutional
cache
Introduction to Communication Networks 2/2009

49. דוגמא ל- Caching(המשך)
origin
servers
פתרון אפשרי שימוש במטמון
(cache):
נניח שנגיע להסתברות פגיעה בcache- היא 0.4
תוצאות:
40% מהבקשות יענו כמעט תמיד באופן מידי.
60% מהבקשות יענו ע"י השרת המקורי.
הניצול של הגישה לערוץ ירד ל-60%, כתוצאה מכך זניח עיכובים
נניח 10 msec.
עיכוב כללי = עיכוב באיטרנט + עיכוב בגישה + עיכוב ב-LAN =
.6*(2.01) secs + .4*milliseconds < 1.4 secs
public
Internet
1.5 Mbps
access link
institutional
network
10 Mbps LAN
institutional
cache
Introduction to Communication Networks 2/2009

50. If-modified-since: <date> If-modified-since: <date>
Conditional GET
cache
server
לכל משתמש יש אובייקטים השמורים ב- cache. אלו אובייקטים בהם צפה בעבר.
מטרת ה-conditional GET היא לצמצם את זמן הגישה והיא עושה זאת על ידי כך שאם תאריך העדכון האחרון של הדף על השרת זהה לתאריך העדכון של הדף שכבר קיים ב- cache של המשתמש, הוא לא יישלח שנית אלא הדף הקיים יוצג.
השימוש בשיטה זו נעשה על ידי הוספת שדה ב-header, המבקש לשלוח את הדף רק אם הוא עודכן אחרי תאריך מסוים. פורמט הבקשה:
If-modified-since:<date>
אם הדף שאצל המשתמש ישן יותר מזה שבשרת, השרת פשוט שולח את הדף. ואם הוא מעודכן, אזי בשורת הסטטוס נשלח קוד 304. פורמט התשובה:
HTTP/ Not Modified
HTTP request msg
If-modified-since: <date>
object
not
modified
HTTP response
HTTP/1.0
304 Not Modified
HTTP request msg
If-modified-since: <date>
object
modified
HTTP response
HTTP/ OK
<data>
Introduction to Communication Networks 2/2009

51. שכבת היישום עקרונות הפרוטוקולים של השכבה. אפליקציות P2P
הבנת המושגים Web, HTTP.
עקרון פעולת .FTP
עקרונות הפעולה של פרוטוקולי דוא"ל: SMTP, POP3, IMAP.
הבנת המושג DNS ועקרון פעילותו.
אפליקציות P2P
הבנת העיקרון TCP עם
Socket Programming
עקרונות של UDP עם Programming Socket
עקרון בניית שרת Web.
הרעיון של שכפול תוכן (Content distribution).
Introduction to Communication Networks 2/2009

52. FTP: the file transfer protocol
user
interface
client
file transfer
FTP
server
user
at host
remote file
system
local file
system
כדי להעביר קובץ מ/אל מחשב מארח מרוחק.
מודל שרת-לקוח
לקוח: הצד שיוזם את העברה (ל / אל המחשב המרחוק).
שרת: במחשב המרוחק.
ftp: RFC 959
ftp server: port 21
Introduction to Communication Networks 2/2009

53. FTP: שליטה נפרדת, וחיבור נתונים
לקוח FTP מתקשר לשרת ה-FTP ב-port 21, פרוטוקול ההובלה TCP הוא הפרוטוקול המפקח על התקשורת.
הדפדפן הלקוח מפקח ישירות באמצעות משלוח פקודות שליטה מעל החיבור.
כאשר השרת מקבל פקודה העברת קבצים, השרת פותח חיבור TCP שני (עבור קבצים) ללקוח (port 20).
לאחר העברת קובץ אחד, השרת סוגר חיבור נתונים.
FTP
client
server
TCP control connection
port 21
TCP data connection
port 20
שרת פותח חיבור נתונים TCP להעביר קובץ אחר.
בקרת החיבור: "מחוץ לפס" .
שרת FTP שומר על "מצב": ספריה נוכחית, ואימות מוקדם.
Introduction to Communication Networks 2/2009

54. FTP פקודות ותגובות קודים חוזרים: פקודות פשוטות:
ביטוי מצב קוד (כמו HTTP):
331 Username OK, password required
125 data connection already open; transfer starting
425 Can’t open data connection
452 Error writing file
פקודות פשוטות:
שולח טקסט ASCII מעל ערוץ הבקרה.
USER username
PASS password
LIST : חוזרת רשימה של קבצים בספריה הנוכחית.
RETR filename: מקבלים קובץ.
:STOR filenameהשמה של קובץ במחשב מארח מרוחק.
Introduction to Communication Networks 2/2009

55. שכבת היישום אפליקציות P2P הבנת העיקרון TCP עם Socket Programming
עקרונות של UDP עם Programming Socket
עקרון בניית שרת Web.
הרעיון של שכפול תוכן (Content distribution).
עקרונות הפרוטוקולים של השכבה.
הבנת המושגים Web, HTTP.
עקרון פעולת .FTP
עקרונות הפעולה של פרוטוקולי דוא"ל: SMTP, POP3, IMAP.
הבנת המושג DNS ועקרון פעילותו.
Introduction to Communication Networks 2/2009

56. דואר אלקטרוני (e-mail)
אפליקציית דואר אלקטרוני היא דוגמא טובה למימוש אפליקציית רשת. דוא"ל יכול לשמש אפליקציות שונות.
לאפליקציית דוא"ל יש 3 מרכיבים עיקריים:
תוכנת הלקוח – User agent – שדרכה הלקוח קורא וכותב את ההודעות (דוגמא outlook).
שרת הדוא"ל – mail server – דרכו נשלחות ההודעות. השרת מורכב מהרבה תיבות דואר של משתמשים שונים. הוא מחזיק תור של הודעות יוצאות שצריכות להשלח לשרתים אחרים.
פרוטוקול הדוא"ל – הפרוטוקול העיקרי בו משתמשים לשליחת דואר אלקטרוני.
user
agent
mail
server
user
agent
SMTP
mail
server
user
agent
SMTP
mail
server
SMTP
user
agent
user mailbox
outgoing
message queue
user
agent
user
agent
Introduction to Communication Networks 2/2009

57. דואר אלקטרוני – שרת הדואר
user
agent
שרת הדואר
תיבת הדואר - mailbox - מכילה הודעות נכנסות עבור המשתמש.
תור הודעות - message queue – תור ההודעות דואר שאמורות להישלח.
פרוטוקול SMTP בין שרתי הדואר לשליחת הודאות הדואר האלקטרוני.
לקוח: שולח דואר אלקטרוני לשרת.
שרת: מקבל דואר "שרתי".
mail
server
user
agent
SMTP
mail
server
user
agent
SMTP
mail
server
SMTP
user
agent
user
agent
user
agent
Introduction to Communication Networks 2/2009

58. SMTP [RFC 2821]
SMTP הוא הפרוטוקול העיקרי בו משתמשים לשליחת דואר אלקטרוני, משתמש ב- port מספר 25.
ה- SMTP משתמש בשיטת TCP, כלומר בתחילה הוא יוצר את הקשר על ידי handshaking, אחר כך הוא שולח הודעה ומקבל סטטוס האם היא התקבלה תקינה או לא ובסוף התהליך הוא סוגר את הקשר.
ה- SMTP משמש עבור שליחת ההודעות בין תוכנת הלקוח לשרת ובין שרת אחד לשני. כל ההודעות והתשובות בכל חלקי התהליך נשלחות בפורמט 7-bit ASCII שהוא פורמט קריא. היתרון בשימוש בפורמט זה הוא שהוא קל לבדיקה (debug) והוא ידידותי למפתחים. החסרון בו הוא ששליחת תווי ASCII תופסים מקום רב יותר ולכן נפח ההודעה גדול יותר מאשר אם היינו שולחים הודעה בינארית.
Introduction to Communication Networks 2/2009

59. דוגמא לתהליך שליחת הודעה:
alice
mail
server
mail
server
bob 1
user
agent
user
agent 2 3 6 4 5
משתמש א' כותב הודעה בתכנת הדואר האלקטרוני שלו וממען אותה לכתובת דוא"ל של משתמש ב'.
תכנת הדוא"ל שולחת את ההודעה לשרת הדוא"ל של משתמש א' שממקם אותה בסוף התור של ההודעות היוצאות.
שרת הדוא"ל של משתמש א' פותח קשר TCP מול שרת הדוא"ל של משתמש ב'.
שרת הדוא"ל של משתמש א' שולח את ההודעה בפרוטוקול SMTP לשרת הדוא"ל של משתמש ב'.
שרת הדוא"ל של משתמש ב' שם את ההודעה שהתקבלה בתיבת הדוא"ל של משתמש ב'.
משתמש ב' מפעיל את תכנת הדוא"ל שלו ומקבל מהשרת את ההודעה ששלח לו משתמש א'.
Introduction to Communication Networks 2/2009

60. פורמט הודעת דואר ההודעה מוגדרת ב- RFC 822
בתחילה ישנו ה- header המכיל את השדות To, From, Subjectוכו', לאחר מכן יש
שורה רווח ואז גוף ההודעה המכיל את התוכן עצמו.
message format:
header lines, e.g.,
To:
From:
Subject:
body
the “message”, ASCII characters only
header
blank
line
body
Introduction to Communication Networks 2/2009

61. פורמט הודעת דואר אלקטרוני- הרחבת מולטימדיה
פורמט הודעת דואר אלקטרוני- הרחבת מולטימדיה
הפורמט MIME (multimedia mail extension) נועד לפתור בעיות שליחת הקטעים, שלא מכילים קוד ASCII, דרך דוא"ל.
מקדד, ממפה את המידע לקוד ASCII.
שורה נוספת ב- header של ההודעה מכיל כותרת מזהה : מכילה גרסת MIME, קידוד, סוג הנתונים ותת-סוג.
סוגי הקבצים : audio, video, image, text, applications, multipart
From:
To:
Subject: Picture of yummy crepe.
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Type: image/jpeg
base64 encoded data .....
......base64 encoded data
MIME version
method used
to encode data
multimedia data
type, subtype,
parameter
declaration
encoded data

62. פרוטוקולי גישה לדואר אלקטרוני
שליחה: נעשית באמצעות פרוטוקול SMTP.
קבלה: נעשית על ידי שני סטנדרטים עיקריים: POP3 ו- IMAP, אך לעיתים משתמשים גם ב- HTTP. לא משתמשים ב-SMTP משום שהוא מיועד רק לשליחה ואין בו תמיכה בקבלה של אובייקטים.
sender’s mail
server
SMTP
SMTP
access
protocol
user
agent
user
agent
receiver’s mail
server
POP3 (Post Office Protocol) – הדבר העיקרי שיש בו זהו ה- authorization, כלומר זיהוי המשתמש על ידי שם משתמש וסיסמא. זיהוי המשתמש נעשה כבר בעת הגישה לתיבת הדואר שעל השרת.
IMAP (Internet Mail Access Protocol) – תומך בהרבה ספריות בשרת שהלקוח יכול לנהל. אופציה זו אינה קיימת ב- POP3.
HTTP – בדרך זו ניגשים לתיבת הדואר דרך הדפדפן ולא דרך תכנת דואר אלקטרוני. לדוגמא – Yahoo mail, hotmail וכו'.
Introduction to Communication Networks 2/2009

63. שכבת היישום אפליקציות P2P הבנת העיקרון TCP עם Socket Programming
עקרונות של UDP עם Programming Socket
עקרון בניית שרת Web.
הרעיון של שכפול תוכן (Content distribution).
עקרונות הפרוטוקולים של השכבה.
הבנת המושגים Web, HTTP.
עקרון פעולת .FTP
עקרונות הפעולה של פרוטוקולי דוא"ל: SMTP, POP3, IMAP.
הבנת המושג DNS ועקרון פעילותו.
Introduction to Communication Networks 2/2009

64. DNS: Domain Name System
המטרה של ה- DNS היא לאפשר זיהוי של כל המחשבים וה- routers שברשת.
ישנן שתי צורות של כתובות של מחשבים ברשת:
IP - כתובת מספרית בת 32 ביטים המזהה כל מחשב שמחובר כרגע לרשת האינטרנט. בכתובת זו משתמשים המחשבים וה- routers.
Name – זהו שם אלפבתי בו שנעשה בו שימוש על ידי המשתמשים האנושיים משום שקל יותר לזכור אותו מאשר 32 ביטים
Introduction to Communication Networks 2/2009

65. ) DNSהמשך)
מטרת שרת ה- DNS היא למפות בין שם השרת לבין ה- IP שלו. ישנם שרתי DNS רבים ברשת מכמה סיבות:
אם היה רק שרת אחד היה עליו עומס עצום משום שהיו ניגשים אליו מכל העולם.
אם השרת הזה היה נופל אזי כל התעבורה ברשת היתה נפסקת כמעט לחלוטין.
גישה למחשב זה ממקומות מרוחקים היתה לוקחת זמן רב.
מבחינת תחזוקה ובטיחות, הוספת מחשבים חדשים הרבה יותר קלה אם יש כמה שרתים שניתן "להודיע" להם על החיבור וכן אם יש רק שרת אחד, קל יותר לפרוץ אליו ולשבש את פעילות הרשת כולה.
מכל הסיבות הללו הוחלט להשתמש בהרבה שרתי DNS, כך שאין שרת אחד המחזיק את כל הכתובות אלא ישנה היררכיה של שרתים, הפונים אחד לשני לבקשת המידע.
Introduction to Communication Networks 2/2009

66. 13 root name servers worldwide
סוגי שרתי DNS
שרתים מקומיים – הינם שרתי ה- default במחשבי הקצה של המשתמשים ששם כתוב לאן ללכת על מנת לקבל את הכתובת.
שרתים סמכותיים – שרתים שיודעים למפות את כל הכתובות במרחב כתובות מסוים (למשל בתוך biu.ac.il). לכל מרחב שמות יש לפחות שני שרתי DNS שהכתובת ידועה להם. כל שינוי של כתובת מצריך שינוי בשני השרתים.
שרתי שמות (root) – לשרתים אלו פונים כאשר לא יודעים מאיפה להשיג את הכתובת. השרת שאמור לדעת את המיפוי לא יודע מהו המיפוי ולא יודע מיהו שרת הסמכות. ישנם 13 שרתים כאלו. הם אינם יודעים את המיפוי עצמו אלא הם יודעים מהו השרת הסמכותי עבור כל כתובת.
a Verisign, Dulles, VA
c Cogent, Herndon, VA (also LA)
d U Maryland College Park, MD
g US DoD Vienna, VA
h ARL Aberdeen, MD
j Verisign, ( 21 locations)
k RIPE London (also 16 other locations)
i Autonomica, Stockholm (plus other locations)
e NASA Mt View, CA
f Internet Software C. Palo Alto, CA (and 36 other locations)
m WIDE Tokyo (also Seoul, Paris, SF)
13 root name servers worldwide
b USC-ISI Marina del Rey, CA
l ICANN Los Angeles, CA

67. ביזור, היררכיה ומסדי נתונים
Root DNS Servers
com DNS servers
org DNS servers
edu DNS servers
poly.edu
DNS servers
umass.edu
yahoo.com
amazon.com
pbs.org
שרתי שמות (root)
שרתים סמכותיים
שרתים מקומיים
שרת שורש מקבל שאילתה מלקוח בצורה "מהי הכתובת של האתר המסוים ?".
אז הוא שואל שרת הרלוונטי שמכיל אתרים מקומיים ששייכים לתת קבוצה שלו וכו' עד שמגיעים לשרת המקומי שמחזיר כתובת IP לשרת השורש.
שרת השורש מעביר ללקוח תשובה סופית.
Introduction to Communication Networks 2/2009

68. authorititive name server
דוגמא
requesting host
surf.eurecom.fr
gaia.cs.umass.edu
root name server
authorititive name server
dns.umass.edu
local name server
dns.eurecom.fr 1 2 3 4 5 6
ה- host פונה לשרת המקומי. השרת המקומי לא יודע מהו המיפוי או מיהו בר הסמכא ולכן פונה לשרת ה- root. הוא יכול לפנות לשרת הסמכותי ולהחזיר את המיפוי.
לא תמיד ה- root יודע מיהו שרת הסמכות, ואז הוא משתמש בשרת ביניים, שכן יודע.
בעיה:
הפניה מתבצעת בצורה כזו שהשרתים צריכים לזכור שהם מחכים לתשובה, ולא הגיוני שכל 13 השרתים יזכרו שיש בקשות שמחכות להם.
הפתרון הוא ש-13 השרתים לא חייבים לפנות בעצמם לשרתי המשנה ולהחזיר את התשובה, אלא הם מפנים את המבקש לפנות בעצמו לשרתי המשנה. שיטה זו נקראת query איטרטיבי.
Introduction to Communication Networks 2/2009

69. authoritative name server
DNS: Iterated Queries
requesting host
surf.eurecom.fr
root name server
local name server
dns.eurecom.fr 1 2 3 4 5 6
authoritative name server
dns.cs.umass.edu 7 8
iterated query
שאילתה רקורסיבית :
כאן הלקוח מעביר בקשה לזיהוי תחנה לשרת DNS אשר פונה לשרת שמעליו עד שמגיע לזיהוי כתובת IP או שרת השורש. אז כתובת IP מועברת ללקוח חזרה בצורה רקורסיבית.
שאילתה איטרטיבית :
לקוח מעביר כתובת השרת מקומי שמכיל מיפוי המבוקש. שרת זה מעביר בקשה בסולם היררכי עד מציאת הכתובת IP.
Introduction to Communication Networks 2/2009

70. DNS caching and records
שרת ה- DNS שומר את הרשומות שלו (המיפויים) ב- cache. לכל רשומה יש שדה time to leave (ttl) שאומר עד מתי יש לשמור את הרשומה.
שדות נוספים הנשמרים ברשומות הם שם הרשומה, ערך, סוג הרשומה.
סוגי הרשומות:
A (address) – השם הוא שם המחשב והערך הוא כתובת ה- IP. זהו מיפוי רגיל בין שם לכתובת.
NS (NameServer) – השם הוא ה- domain והערך הוא ה- IP של שרת הסמכות. זהו מיפוי בין מרחב כתובות לשרת DNS האחראי על מרחב זה.
CNAME (canonical) – השם הוא שם של מחשב והערך הוא שם של מחשב שהוא קנוני עבורו. זהו מיפוי בין שני מחשבים לאותו שם domain של אתר מסוים. המיפוי הזה דרוש לשם web hosting. למשל, לחברה מסוימת יש מספר אתרים במקומות שונים ומתוך שיקולים גאוגרפיים כדאי להפנות למחשב באזור.
MX – הערך הוא שם שרת הדואר האלקטרוני הממופה לאתר החברה. זהו מיפוי לשרת דואר אלקטרוני.
Introduction to Communication Networks 2/2009

71. פרוטוקול DNS
פרוטוקול DNS הינו פרוטוקול מצורת שרת-לקוח המשתמש ב- UDP בדרך כלל משום שההודעות קצרות.
מנקודת מבטו של הלקוח, ה- DNS הוא קופסא שחורה, אליה הוא מזין את שם השרת ומקבל את כתובת ה- IP שלו.
גם לבקשה וגם לתשובה יש את אותו הפורמט, כמתואר בציור.
Introduction to Communication Networks 2/2009

72. פרוטוקול DNS (המשך) הסמנטיקה של ההודעות היא כדלהלן:
12 הבתים הראשונים מהווים את ה- header שמכיל כמה שדות:
השדה הראשון הוא מספר בן 16 ביטים המהווה מזהה של השאלה. בעזרת שדה זה ניתן להתאים בין השאלה לתשובה המתאימה לה, משום שבהודעת התשובה מופיע אותו המספר שהיה בהודעת השאלה.
השדה השני הינו שדה המורכב מכמה דגלים:
ביט המזהה האם זוהי שאלה (0) או תשובה (1).
ביט המזהה האם השרת הוא שרת מוסמך לשאלה.
ביט המזהה האם הלקוח מבקש ששרת השמות יבצע רקורסיה כאשר אין לו רשימה מתאימה.
4 שדות המייצגים כל אחד את מספר ההופעות של ארבעת הקטעים של המידע בגוף ההודעה.
חלק השאלה מכיל מידע לגבי השאלה עצמה. חלק זה מכיל:
את שם השרת המבוקש.
את סוג השדה המסמן את סוג השאלה (תזכורת: סוג השאלה יכול להיות A, NS, CNAME או MX).
בהודעת תשובה, חלק התשובה מכיל את מקור הרשומה עבור שם השרת המבוקש. יש לשים לב שהוא יכול להכיל מספר תשובות, משום שלשרת אחד יכולות להיות מספר כתובות.
חלק הauthority - מכיל מידע על שרתים מוסמכים נוספים.
החלק האחרון מכיל רשומות מועילות נוספות. לדוגמא, אם זוהי תשובה לשאלה מסוג MX אזי שדה התשובה יכיל את שם השרת של שרת הדוא"ל והחלק האחרון יכיל רשומה מסוג A שתכיל את כתובת ה- IP של השרת הקנוני לשרת הדוא"ל.
כיצד המידע מגיע לשרתי ה- DNS ?
עד לאחרונה, התוכן של כל שרת DNS היה מנוהל על ידי מנהל המערכת בצורה ידנית. כיום, התווספה פקודת עדכון לפרוטוקול ה- DNS, המאפשרת למידע להתווסף או להמחק ממסד הנתונים של שרת ה- DNS על ידי הודעת DNS. פקודה זו מתוארת ב- RFC 2136.

73. שכבת היישום אפליקציות P2P הבנת העיקרון TCP עם Socket Programming
עקרונות של UDP עם Programming Socket
עקרון בניית שרת Web.
הרעיון של שכפול תוכן (Content distribution).
עקרונות הפרוטוקולים של השכבה.
הבנת המושגים Web, HTTP.
עקרון פעולת .FTP
עקרונות הפעולה של פרוטוקולי דוא"ל: SMTP, POP3, IMAP.
הבנת המושג DNS ועקרון פעילותו.
Introduction to Communication Networks 2/2009

74. Introduction to Communication Networks 2/2009
P2P ארכיטקטורת
לא תמיד על השרת.
מערכות הקצה מתקשורת ישירות ביניהם.
עמיתים מחוברים לסירוגין ומשנים כתובות IP.
שלושה נושאים:
הפצת קבצים (File distribution).
חיפוש מידע.
מקרה לימודי: Skype.
peer-peer 74
Introduction to Communication Networks 2/2009

75. הפצת קבצים: שרת-לקוח כנגד P2P
שאלה: כמה זמן נדרש כדי להפיץ קובץ אחד בגודל F משרת אחד ל-N עמיתיהם?
:us רוחב פס בשרת ההעלאת/הורדת קבצים
Server
:ui רוחב פס להעלת קבצים של עמית i u1 d1 u2 d2 us
: di רוחב פס להורדת קבצים של עמית i
File, size F dN
Network (with
abundant bandwidth) uN
Introduction to Communication Networks 2/2009

76. השרת בסדרתיות שולח N עותקים בזמן:
הפצת קבצים: שרת-לקוח
Server
השרת בסדרתיות שולח N עותקים בזמן:
N*F/us time)
ללקוח i לוקח זמן של F/di להוריד את הקובץ. F u2 u1 d1 d2 us dN
רשת (עם רוחב פס רחב) uN
= dcs = max { NF/us, F/min(di) } i
הזמן שלוקח להפיץ קובץ בגודל F ל-N
לקוחות תוך שימוש בגישת שרת/לקוח
increases linearly in N (for large N)

77. dP2P = max { F/us, F/min(di) , NF/(us + Sui) }
השרת חייב לשלוח עותק אחד בזמן: F/us (time) .
זמן הורדת העותק של לקוח i : (time) F/di.
N*F ביטים חייבים להיות מורדים (במצטבר)
Server F u2 u1 d1 d2 us
Network (with
abundant bandwidth) dN uN
קצב העלאה המהיר ביותר האפשרי: us + Sui
dP2P = max { F/us, F/min(di) , NF/(us + Sui) } i

78. דוגמא שרת/לקוח כנגד P2P 78

79. (BitTorrent) הפצת קבצים: נחשול ביטים
הפצת קבצים ב- P2P
עקיבה (tracker ): ע"י מחשב שמנהל את הכל נבצע נבצע עקיבה אחר מסלולים של עמיתיהם שהשתתפו בנחשול
נחשול (torrent): קבוצה של עמיתים
שמחליפים חלקים של קבצים.
obtain list
of peers
trading
chunks
peer

80. נחשול ביטים (1) הקובץ מחולק לחלקים של 256KB. עמית שמצטרף לנחשול:
הוא ללא חלקי קובץ (chunks) אך יכול לצבור אותם לאורך זמן.
נרשם עם "עוקב" (tracker) כדי לקבל רשימה של עמיתים, מתחבר לתת קבוצה של עמיתים ( "שכנים").
בזמן הורדת קבצים, העמית מעלה חלקים לעמיתים אחרים.
עמית יכול לבוא וגם ללכת.
כל פעם שיש לעמית את כל הקבצים, הוא יכול לעזוב (אנוכי) או להישאר (מתוך אהבת הזולת).

81. נחשול ביטים (1) משיכת חלקים (Chunks)
שליחת חלקי קובץ: עין תחת עין
אליס שולחת חלקי קובץ (chunks) לארבעה שכנים, ובאותו זמן שולחת את חלקי הקובץ שלה בקצב הגבוה ביותר.
להעריך מחדש את top4 (4 שכנים שנותנים את הקצב הכי גבוה) כל 10 שניות.
בכל 30 שניות: באקראיות בוחר עמית אחר, ומתחיל לשלוח חלקי קובץ (chunks).
העמיד הנבחר החדש יכול להצטרף top 4.
"אופטימיות ללא חניקה (optimistically unchoke)" - מיועד למשתמשים שרק עכשיו התחילו להוריד ואין להם שום פיסת קובץ מההורדה. כאשר משתמש חדש מתחיל להוריד, אין לו שום פיסה להציע, לכן הוא נכנס לרשימת ה-optimistic unchoke ואז כשמגיע תורו ברשימה הוא יתחיל להוריד. ככה תהיה לו פיסה אחת שאותה יוכל להחליף עם כל המשתמשים כרגיל. כאשר אתה המשתמש החדש, תצטרך לחכות לתורך ברשימת ה-optimistic unchoke של שאר המשתמשים ואז תתחיל להוריד, בדר"כ תהליך זה לוקח זמן קצר מאוד.
משיכת חלקים (Chunks)
בכל זמן נתון, לעמית שונה יש תת-קבוצה שונה של חלקי קובץ.
מעת לעת, עמית (אליס) שואל כל שכן על רשימת חלקי הקובץ (chunks) שיש לו.
אליס שולחת בקשה עבור חלקי הקובץ החסרים שלה.

82. נחשול ביטים: עין תחת עין
(1) אליס "באופטימיות לא חונקת (optimistically unchoke)" את בוב
(2) אליס הופכת לאחת מארבע הספקים העליונים; בוב יגמול לה טובה.
(3) בוב הופך לאחד מארבע הספקים העליונים של אליס.
עם קצב העלאה גבוה ביותר, ניתן למצוא שותף טוב יותר ולקבל את הקובץ מהר יותר

83. Introduction to Communication Networks 2/2009
P2P: חיפוש מידע
אינדקס במערכת P2P : מיפוי המידע למיקום העמית (מיקום= כתובת IP & מספר port).
שיתוף קבצים (לדו' e-mule)
האינדקס עוקב באופן דינאמי על המיקום של הקובץ שהעמית משתף.
העמיתים נזקקים לאינדקס שיש להם.
העמיתים משתמשים באינדקס החיפוש על מנת לקבוע היכן הקובץ יכול להימצא.
מסרים מידיים (לדו' ICQ)
האינדקס ממפה את שם משתמש למיקום (IP).
כאשר העמית מתחיל להשתמש באפליקציה, הוא נדרש לדווח לאינדקס המידע על המיקום שלו.
אינדקס חיפוש של העמיתים משמש לקביעת כתובת IP של המשתמש.
Introduction to Communication Networks 2/2009

84. Introduction to Communication Networks 2/2009
:P2P אינדקס מרכזי
תיכנון “Napster” המקורי
1) כאשר עמית מתקשר הוא מדווח לשרת מרכזי:
כתובת IP
תוכן
2) אליס מעונינת
(queries) ב- “Hey Jude”
3) אליס מבקשת (requests) את הקובץ מבוב.
centralized
directory server
peers
Alice
Bob 1 2 3 84
Introduction to Communication Networks 2/2009

85. P2P: בעיות עם ספריה מרכזית
השענות על נקודה יחידה – אם היא נופלת הכל נופל.
נקודת צוואר בקבוק לביצועים.
קניין רוחני: מטרה לתביעות עקב זכויות יוצרים.
העברת הקבצים היא לא-
ריכוזית, אבל המידע על
מיקום הקבצים ותוכנם הוא מאוד ריכוזי
Introduction to Communication Networks 2/2009

86. (Query flooding)שיטפון שאילתות
כיסוי רשת: גרף
קצה בין עמית X ו-Y אם קיים חיבור TCP.
כל העמיתים הפעילים והקצוות יוצרים מעין כיסוי לרשת.
קצה: חיבור וירטואלי (לא פיסי).
נותן המחובר עם < 10 שכנים קרובים.
הפצה מלאה
אין שרת מרכזי
שימוש ע"י Gnutella : Gnutella הינה מערכת מבוזרת ופתוחה, אין לה כל חברה מרכזית המנהלת אותה, אין כל שרת מרכזי האחראי על תעבורת מידע ולא נקודת קישור מרכזית. Gnutella הינו פרוטוקול התומך ביישומים רבים ורשת Gnutella קיימת רק בזכות קיום תחנות קצה המתקשרות באמצעות פרוטוקול זה ומכאן אנו מבינים ש-Gnutella היא בעצם אחת מהתצורות הקיימות ליישום "רשת ארעית".
כל עמית לאינדקס הופך את כל הקבצים זמינים לשיתוף.
Introduction to Communication Networks 2/2009

87. Introduction to Communication Networks 2/2009
שיטפון שאילתות
Query
QueryHit
File transfer:
HTTP
הודעת שאילתה (Query message) נשלחת דרך חיבור TCP קיים.
עמית שולח קדימה את הודעת
השאילתה.
שאילתה חוזרת (QueryHit) חוזרת דרך הנתיב.
יכולת הרחבה: היקף השיטפון מוגבל
Introduction to Communication Networks 2/2009

88. צרוף עמיתים ל-Gnutella
אליס ברציפות מנסה לקיים חיבוריTCP עם מועמדים אחרים להיות עמיתים, עד לקיום חיבור עם בוב.
הצפה: אליס שולחת הודעת פינג לבוב; בוב מעביר את הודעת הפינג לשכנים שלו ברשת.
עמית שמקבל הודעת פינג חוזר לאליס עם הודעת פונג.
אליס מקבלת הרבה הודעות פונג, ואז יכולה להקיים קישורי TCP נוספים.
Introduction to Communication Networks 2/2009

89. Introduction to Communication Networks 2/2009
שכבות היררכיות
בין אינדקסים מרכזי, הגישה היא שיטפון שאילתות.
כל עמית הוא גם על-צומת או מוקצה להיות על-צומת.
קישור TCP בין העמית לבין העל-צומת שלו.
קישור TCP בין חלק מהעמיתים של העל-צמתים.
על-צמתים משתפים תכנים עם ילדיהם.
Introduction to Communication Networks 2/2009

90. Introduction to Communication Networks 2/2009
P2P מקרה לימוד : SKYPE
P2P מטבעו: זוגות של משתמשים מתקשרים.
פרוטוקול שכבת האפליקציה בעל קניין רוחני.
שכבות היררכיות עם Supernode (SN)
אינדקס ממפה שם משתמש לכתובת IP, מופץ מעל Supernode (SN).
Skype clients (SC)
Skype
login server
Supernode
(SN)
Introduction to Communication Networks 2/2009

91. שכבת היישום עקרונות הפרוטוקולים של השכבה. אפליקציות P2P
הבנת המושגים Web, HTTP.
עקרון פעולת .FTP
עקרונות הפעולה של פרוטוקולי דוא"ל: SMTP, POP3, IMAP.
הבנת המושג DNS ועקרון פעילותו.
אפליקציות P2P
הבנת העיקרון TCP עם
Socket Programming
עקרונות של UDP עם Programming Socket
עקרון בניית שרת Web.
הרעיון של שכפול תוכן (Content distribution).
Introduction to Communication Networks 2/2009

92. תיכנות ממשק (Socket programming)
מטרה: ללמוד כיצד לבנות יישומי שרת/לקוח שמתקשרים ע"י שימוש בממשקים (sockets).
יישום פנים תחנת קצה, המיוצר ומוקצה ע"י מערכת הפעלה ומשמש בתור "דלת". דרכו ניתן לשלוח ולקבל הודעות ובדרך זו לתקשר עם תהליך של יישום אחר.
socket
Socket API – מנגנון שמאפשר לאפליקציה לפתוח, לשלוח ולסגור connection. תומך ב- UDP וב- TCP.
Socket – חיבור בין שני מחשבים שונים (משתמשים בו גם ב- UDP וגם ב- TCP).
TCP service – שרות שמבטיח אמינות בשליחת בתים מתהליך אחד לתהליך אחר דרך האינטרנט.
controlled by
application
developer
controlled by
application
developer
process
TCP with
buffers,
variables
socket
process
TCP with
buffers,
variables
socket
internet
controlled by
operating
system
controlled by
operating
system
host or server
host or server

93. תיכנות ממשק (המשך)
כל אפליקציית רשת מורכבת משתי תוכנות – תוכנת השרת ותוכנת הלקוח.
כאשר מריצים את שתי התכניות הללו, נוצרים תהליכים עבור השרת ועבור הלקוח, ושני התהליכים הללו "מתקשרים ביניהם" על ידי קריאה וכתיבה של מידע ל- sockets.
כאשר תכניתן כותב אפליקציית רשת, הוא יכול לכתוב אותה כך שתתאים לפרוטוקול המוגדר על ידי RFC, כגון FTP ובצורה זו הוא יכול לכתוב רק את צד השרת למשל, ואילו תכניתן אחר, ללא קשר לראשון, יכול לכתוב אפליקצית לקוח משלו שתוכל לתקשר עם האפליקציה הראשונה ללא קושי.
ישנה אפשרות אחרת, לפיה התכניתן יכתוב אפליקציה שאינה משתמשת בפרוטוקול המוגדר על ידי RFC, ובמקרה זה אותו תכניתן חייב לכתוב גם את תכנת השרת וגם את תכנת הלקוח כי שתי התוכנות חייבות להתבסס על אותו הפרוטוקול. הוא גם חייב להזהר שלא להשתמש באחד מה- ports המוגדרים ב- RFC כי אז יכולה להיות התנגשות של מידע שיעבור דרך אותו ה- port לשתי תכנות שונות.
Introduction to Communication Networks 2/2009

94. Socket Programming דרך TCP
כאשר מתבצע חיבור ע"י הלקוח, שרת יוצר עכשיו ממשק חדש עבור תהליכי השרת לחיבור עם הלקוח
מאפשר לשרת לתקשר עם מספר לקוחות.
מספר ה-port המקורים משמשים לזהוי לקוחות.
הלקוח חייב לתקשר עם השרת
בראש ובראשונה חייב תהליך השרת חייב להיות פעיל
השרת חייב ליצור ממשק (דלת) שיקבל את פניית הלקוח.
הלקוח מתקשר עם השרת ע"י:
יוצר ממשק TCP מקומי בלקוח.
מספק את כתובת ה- IP וה- port של השרת.
כאשר הלקוח יוצר ממשק (socket): הלקוח קובע חיבור באמצעות פרוטוקול TCP לשרת.
TCP מספק שרות אמין, וסדר בהעברת ביתים (bytes) "הצינור" בין לקוחות ושרתים
application viewpoint
Introduction to Communication Networks 2/2009

95. Socket Programming דרך TCP (המשך)
Server (running on hostid)
Client
בשביל להשתמש ב- socket, הלקוח צריך לשלוח הודעה והשרת צריך להמתין לבקשות. מספר ה- port של השרת צריך להיות ידוע כדי שהלקוח יידע לאן לפנות.
הסבר לתרשים:
הלקוח פותח clientSocket ומספק את כתובת ה- IP וה- port של השרת ואז נוצר TCP connection לשרת.
השרת מצידו פותח welcome socket מול הלקוח ועוד connectionSocket שיהיה מיועד לתקשורת עם אותו לקוח.
ה- socket הראשון מיועד רק ליצירת הקשר מהלקוח והשני עבור התשובות שיחזיר השרת.
הלקוח שולח את המידע לשרת דרך ה- clientSocket, השרת קורא את הבקשה מה- clientSocket וכותב את התשובה חזרה ל- clientSocket, סוגר את ה- connectionSocket וחוזר לחכות לבקשה מהלקוח.
הלקוח מקבל את התשובות מהשרת דרך ה- clientSocket וסוגר אותו.
create socket,
port=x, for
incoming request:
welcomeSocket =
ServerSocket()
TCP
connection setup
close
connectionSocket
read reply from
clientSocket
create socket,
connect to hostid, port=x
clientSocket =
Socket()
wait for incoming
connection request
connectionSocket =
welcomeSocket.accept()
send request using
clientSocket
read request from
connectionSocket
write reply to
Introduction to Communication Networks 2/2009

96. שכבת היישום הבנת העיקרון TCP עם Socket Programming
עקרונות של UDP עם Programming Socket
עקרונות הפרוטוקולים של השכבה.
הבנת המושגים Web, HTTP.
עקרון פעולת .FTP
עקרונות הפעולה של פרוטוקולי דוא"ל: SMTP, POP3, IMAP.
הבנת המושג DNS ועקרון פעילותו.
Introduction to Communication Networks 2/2009

97. Socket Programming דרך UDP
ב-UDP אין קשר (connection) בין הלקוח והשרת
UDP אין handshaking, מה שמקצר את התהליך.
השולח שולח רק את ה- IP ומספר ה- port ולכן אין צורך בפתיחת socket נוסף, כי אין connection.
כל פניה לשרת תיבדק לגופה ב- socket האחד והיחיד שמוקצה על ידי השרת.
ב-UDP העברת המידע יכול להתקבל ללא סדר או לאבוד.
application viewpoint
UDP מספק העברת לא אמינה (ללא
סדר או עם אובדן) של קבוצות של
ביתים (bytes) בין לקוחות ושרתים.
Introduction to Communication Networks 2/2009

98. Client/server socket interaction: UDP
הסבר לתרשים:
הלקוח פותח clientSocket
ואז נוצר UDP connection
לשרת.
השרת מצידו פותח
Datagram socket מול
הלקוח ומחכה להודעה
מהשרת.
הלקוח שולח את המידע
לשרת דרך ה- clientSocket,
השרת קורא את הבקשה מה-
Datagram socket וכותב את
התשובה חזרה ל- Datagram
socket וחוזר לחכות לבקשה מהלקוח.
הלקוח מקבל את התשובות
מהשרת דרך ה- clientSocket
וסוגר אותו.
create socket,
clientSocket =
DatagramSocket()
Client
Create datagram with server IP and
port=x; send datagram via clientSocket
Server (running on hostid)
create socket,
port= x.
serverSocket =
DatagramSocket()
read datagram from
serverSocket
close
clientSocket
read datagram from
write reply to
serverSocket
specifying client address,
port number
Introduction to Communication Networks 2/2009

99. our study of network apps now complete!
סיכום
our study of network apps now complete!
application architectures
client-server
P2P
hybrid
application service requirements:
reliability, bandwidth, delay
Internet transport service model
connection-oriented, reliable: TCP
unreliable, datagrams: UDP
specific protocols:
HTTP
FTP
SMTP, POP, IMAP
DNS
P2P: BitTorrent, Skype
socket programming