רשתות תקשורת מחשבים הרצאה 2: היישום מרצה עמית דביר חומר על RTSP וגם progressive download http://www.reelseo.com/progressive-download-vs-streamin/ http://ezinearticles.com/?The-Difference-Between-HTTP-Progressive-Download-and-True-Streaming&id=2419776 מצגות הקורס עושות שימוש בתרשימים של Kurose & Ross © ראו גם: http://www.aw.com/kurose-ross/ ומתבססות על שקפים של בעז בן משה אמיר הרצברג ואיציק קיטורסר ושי אולשר רשתות תקשורת מחשבים

בתכנית פרק 2 בספר FTP דואר אלקטרוני DNS הפצת תוכן - SMTP, POP, IMAP DNS הפצת תוכן - רשתות הפצת תוכן - שיתוף קבצים P2P פרק 2 בספר עקרונות פרוטוקולים של יישומים עם שכבות - לקוחות ושרתים - דרישות של יישומים - בחירת שירות תעבורה - תכנות sockets Web ו-HTTP - סקירה של HTTP - חיבורים: עקבי, pipline - בקשות / תגובות - אימות ו-cookies - Caching ו-Proxies רשתות תקשורת מחשבים 2

יישומי רשת ופרוטוקול שכבת היישום יישום רשת יישום המערב תהליכים ב-hosts שונים - לדוגמה: דואר אלקטרוני, רשת, FTP - פועל במערכות קצה - מתקשר תוך שימוש ב... פרוטוקול שכבת היישום - פרוטוקול תקשורת עבור יישומי רשת - משתמש בשירות תעבורה (TCP, UDP) - מגדיר הודעות ואת תהליך עיבודן (פעולות) - סטנדרטי, ציבורי או של בעלי זכות קניין application transport network data link physical רשתות תקשורת מחשבים 3

פרוטוקול שכבת היישום מגדיר - פרוטוקולים של שכבת היישום בדומיינים ציבוריים: מוגדרת ב-RFC’s מאפשרת שימוש במערכות אחרות דוגמאות: HTTP, SMTP פרוטוקולים של בעלי זכויות: לדוגמה KaZaA: - מבוסס על FastTrack (פרטי) - מאפשר לחסום לקוחות 'משוכפלים' חוקים לגבי מתי ואיך תהליכים מתקשרים סוג התקשורת, לדוגמה: בקשה ותגובה, הודעות פורמט ההודעות: אילו שדות, ואיך שדות מופרדים הגדרות סמנטיות של השדות, לדוגמה מה המשמעות של מידע בשדה מסויים רשתות תקשורת מחשבים 4

תהליכים ותקשורת תהליך לקוח: תהליך: תכנית שרצה על host תהליך שמתחיל את כל ההתקשרות תהליך שרת: תהליך שממתין ליצירת קשר חשוב: יישומים בארכיטקטורת P2P הם בעלי תהליכי לקוח ותהליכי שרת תהליך: תכנית שרצה על host באותו host, שני תהליכים יכולים לתקשר באמצעות תקשורת בין-תהליכית (interprocess communication) - לא במסגרת הקורס הזה תהליכים על hosts שונים באמצעות חילופי הודעות - על זה נלמד בקורס הזה רשתות תקשורת מחשבים 5

פנייה לתהליכים בשביל שתהליך יקבל הודעות, הוא חייב להיות לו מזהה בשביל שתהליך יקבל הודעות, הוא חייב להיות לו מזהה כל host הוא בעל כתובת IP ייחודית של 32 ביטים שאלה: האם כתובת ה-IP של ה-host עליו רץ התהליך מספיקה לזיהוי התהליך? המזהה כולל גם כתובת IP וגם מספר port אשר מקושר לתהליך על ה-host. דוגמאות לפורטים קבועים (של שרת): - HTTP - 80 - SMTP - 25 פורטים אחרים (של לקוחות) מוקצים בצורה דינמית. נדון בכך בהמשך. רשתות תקשורת מחשבים 6

שרותי שכבת התעבורה באינטרנט שרות UDP: datagram – אין setup תעבורה לא אמינה (אובדן) לא כוללת: - אמינות - שליטה בעומס/זרימה - הבטחת עיכוב או רוחב פס שאלה: האם מתישהוא נבחר ב-UDP? שרות TCP: נדרשת תקורת setup - setup TCP: סיבוב אחד תעבורה אמינה (אבל עם תקורה מסויימת) שליטה בזרימה: הזנה (שליחה) בקצב של המקבל שליטה בעומס: בלימת השולח כשהרשת עמוסה לא כוללת: עיכוב, הבטחת רוחב פס רשתות תקשורת מחשבים 7

בחירת שרות תעבורה... רוחב פס ועיכוב יישומים רבים הם "גמישים": משתמשים ברוחב הפס ובעיכוב שהם מקבלים - לדוגמה דוא"ל, web חלקם דורשים איכות מינימלית של שירות (רוחב פס, עיכוב) - לדוגמה שיחת וידאו, אודיו אמינות מידע (אובדן, סדר) הרבה יישומים דורשים מידע ללא אובדן - לדוגמה העברת קבצים או דואל - דורש העברה מחדש -> תקורה יש יישומים שמאפשרים אובדן עד רמה מסויימת - לדוגמה אודיו דיגיטלי תקורת setup ישנם יישומים דלילים - הודעה קטנה פעם בכמה זמן - תקורת הקמה משמעותית אבל רובם "מאריכי ימים"... - תקורת הקמה זניחה גודל וסיבוכיות גודל הקוד והסיבוכיות הם לעיתים קריטיים - לדוגמה מכונת-קפה-אינטרנטית רשתות תקשורת מחשבים 8

דרישות שירות תעבורה של יישומים נפוצים Application Data loss Bandwidth Time Sensitive File transfer No loss Elastic No Email Web Docs Real-time audio/video Loss tolerant Audio: 5kbps-1Mbps Video: 10kbps-5Mbps Yes, 100’s msec Stored audio/video Same as above Yes, few secs Interactive games Few kbps up Instant messaging Yes and no רשתות תקשורת מחשבים 9

Web ו-HTTP מונחים מקצועיים: דף web מורכב מאובייקטים אובייקט יכול להיות קובץ HTML, תמונת JPEG, ג'אווה applet, קובץ אודיו, ... דף web מורכב מקובץ HTML בסיסי אשר בדרך כלל מכיל הפניות למספר אובייקטים כל אובייקט ניתן לפנייה באמצעות URL/URI - Universal Resource Locator/ Identifier URL לדוגמה: http://www.cs.colman.ac.il/~olshers/index.html host name path name רשתות תקשורת מחשבים 10

סקירה של HTTP HTTP: hypertext transfer protocol שכבת יישום ה-web של הפרוטוקול מודל לקוח/שרת: - לקוח: דפדפן (מבקש, מקבל, "מציג" אובייקיט web) - שרת: שרת web שולח אובייקטים בתגובה לבקשות HTTP 1.0: RFC 1945 HTTP 1.1: RFC 2068 HTTP request Browser (e.g. IE) HTTP response HTTP request HTTP response Browser (e.g. Mozilla) רשתות תקשורת מחשבים 11

סקירה של HTTP(המשך) HTTP הוא "חסר מצב" (stateless) סקירה של HTTP(המשך) HTTP הוא "חסר מצב" (stateless) שרת אינו שומר מידע על בקשות קודמות של הלקוח שימוש ב-TCP: לקוח יוזם חיבור TCP (יוצר socket) לשרת, פורט 80. שרת מקבל חיבור TCP מלקוח. הודעות HTTP (בפרוטוקול שכבת היישום) מוחלפות בין דפדפן (לקוח HTTP) לשרת ה-web (שרת HTTP). חיבור TCP נסגר. דבר נוסף: פרוטוקולים ששומרים על "מצב" הם מסובכים! היסטוריה (מצב קודם) צריכה להישמר אם שרת/לקוח קורס, נק' ההסתכלות שלהם על ה-"מצב" יכולה להיות שונה - צריך להיפתר. רשתות תקשורת מחשבים 12

חיבורי HTTP חיבורים לא עקביים: לכל היותר אובייקט אחד נשלח על גבי חיבור TCP. HTTP 1.0 משתמש בחיבורים לא עקביים. חיבורים עקביים: אובייקטים רבים יכולים להשלח על גבי חיבור TCP יחיד. HTTP 1.1 משתמש בחיבורים עקביים (כברירת מחדל). רשתות תקשורת מחשבים 13

חיבורי HTTPלא עקביים (HTTP 1.0): URL: www.someSchool.edu/someDept/home.index 1a. HTTP client initiates TCP connection to Web server at www.someSchool.edu on port 80 1b. HTTP server “accepts” connection, notifies client 2. HTTP client sends HTTP request message (containing URL) via socket, for object someDept/home.index 2b. HTTP server receives request, sends response message containing HTML object 3. Client receives, displays object 4. Parsing html file, client finds referenced objects (e.g. .gif); repeat steps 1-3 for each time רשתות תקשורת מחשבים 14

מודל של זמן התגובה הגדרה של RTT (זמן הלוך-חזור): זמן שלוקח לשלוח חבילה קטנה מלקוח לשרת ובחזרה. זמן תגובה: RTT אחד ליצירת חיבור TCP RTT אחד לבקשת HTTP ולכמה בייטים של תגובת HTTP לחזור זמן שידור קובץ סך הכל: 2RTT + זמן שידור initiate TCP connection RTT request file time to transmit file RTT file received time time רשתות תקשורת מחשבים 15

חיבורי HTTPעקביים (HTTP 1.1): עקביים ללא pipelining: לקוח שולח בקשה חדשה רק כאשר תגובה לבקשה קודמת נתקבלה. RTT אחד לכל אובייקט אליו יש הפניה. עקביים עם pipelining: ברירת מחדל ב-HTTP 1.1. לקוח שולח בקשות ברגע שהוא נתקל באובייקט אליו יש הפנייה. יכול להגיע גם ל-RTT אחד לכל האובייקטים אליהם יש הפניות. חיבורי HTTP לא עקביים גורמים: אופציה יחידה ב-HTTP 1.0 דורשים 2 RTT לכל אובייקט תקורת מ"ה לכל חיבור TCP דפדפנים פותחים לעיתים קרובות חיבורי TCP מקבילים כדי להביא אובייקטים אליהם יש הפניות (ב-IE - רק 2 לכל שרת) חיבורי HTTP עקביים שרת משאיר חיבור פתוח אחרי שליחת תגובה הודעות HTTP עוקבות בין אותם לקוח/שרת נשלחות על גבי חיבור פתוח כדי לבדוק אם הם הבינו את הנושא צריך לעשות איתם תרגיל לדוגמא, suppose the HTML file indexes three very small objects on the same server. Neglecting transmission times, how much time elapses with (1) non-persistent HTML with no parallel TCP connections (2) non-persistent HTML with parallel TCP connections (3) persistent HTML with pipeline? רשתות תקשורת מחשבים 16

הודעת בקשה ב-HTTP: יש שני סוגים של הודעות HTTP: בקשה ותגובה ASCII (ניתן לקריאה): קל יותר לדבג, לדוגמה ניסוי באמצעות טלנט לדפדפן שורת בקשה (GET, POST פקודות HEAD) GET /somedir/page.html HTTP/1.1 Host: www.someschool.edu User-agent: Mozilla/4.0 Connection: close Accept-language:fr (extra carriage return, line feed) Optional body (e.g. uploaded file) שורות פתיח החזרת סמן, הזנת שורה מציינת סוף של הודעה / פתיח נכון לגרסה 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 - מבקש מהשרת לשלוח את הבקשה בדיוק כפי שקיבל אותה. הדבר שימושי לבדיקה של תחנות הביניים שנמצאות בין הלקוח לשרת ומעבדות את ההודעות העוברות דרכן. ישנה בעיה כאשר על שרת אחד ישנם מספר אתרים וכל פעם אני שולח רק את החלק היחסי של האתר, לכן בגירסה 1.1 הגדירו שדה מיוחד שרשום שם אזור הטיפול רשתות תקשורת מחשבים 17

הודעת בקשה ב-HTTP: מבנה כללי CR><LF> (that is, a carriage return followed by a line feed ) end of line and new line רשתות תקשורת מחשבים 18

העלאה של קלט מ-web form www.site.com/search?monkeys&banana שימוש בשיטת Post: הקלט מועלה לשרת בגוף הבקשה שימוש בשיטת Get: קלט מועלה לשרת בשורת ה-URL של הבקשה: www.site.com/search?monkeys&banana רשתות תקשורת מחשבים 19

הודעת תגובה ב-HTTP: שורת סטטוס (פרוטוקול, קוד סטטוס, וכינוי סטטוס) שורת סטטוס (פרוטוקול, קוד סטטוס, וכינוי סטטוס) HTTP/1.1 200 OK Connection close Date: Thu, 06 Aug 1998 12: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 data data ... שורות פתיח מידע (לדוגמה קובץ HTML שנדרש) רשתות תקשורת מחשבים 20

תגובות קוד סטטוס של HTTP בשורה הראשונה בהודעת התגובה של השרת ללקוח: 200 OK בקשה הצליחה, האובייקט המבוקש בהמשך הודעה זאת. 301 Moved Permanently האובייקט המבוקש עבר, מיקום חדש מפורט בהמשך הבקשה הזאת (Location:) 400 Bad Request הבקשה לא הובנה על ידי השרת. 404 Not Found האובייקט המבוקש לא נמצא על השרת. 505 HTTP Version Not Supported רשתות תקשורת מחשבים 21

Web Sessions? Goal: link requests of same user How? To authenticate only once (e.g. by password) To keep state: shopping cart, game, mail,… Required since HTTP is stateless How? Persistent connection? Identifier in URL (from hidden form field) http://gmail.com/send?auth=ajhwe83lkjs Cookies HTTP authentication

אינטראקציה בין משתמש לשרת - אישור אישור: שליטה בגישה לתוכן שעל שרת אישורים נדרשים: בדרך כלל שם, סיסמה חסר מצב (stateless): לקוח חייב אישור בכל בקשה - אישור: שורת פתיח בכל בקשה - אין אישור בפתיח, השרת מסרב לתת גישה, שולח: WWW authenticate כשורת פתיח בתגובה. שרת לקוח usual http request msg 401: authorization req. WWW authenticate: usual http request msg + Authorization: <cred> usual http response msg usual http request msg + Authorization: <cred> usual http response msg זמן רשתות תקשורת מחשבים 23

עוגיות (cookies): שמירת "מצב" אתרים מרכזיים רבים עושים שימוש בעוגיות ארבעה מרכיבים: שורת פתיח בהודעת HTTP של התגובה שורת פתיח בהודעת HTTP של הבקשה קובץ עוגיה נשמר על host של המשתמש ומנוהל על ידי הדפדפן של המשתמש מסד נתונים אחורי באתר האינטרנט דוגמה: - דנה ניגשת לאינטרנט תמיד מאותו המחשב. - היא מבקרת באתר של חנות מקוונת בפעם הראשונה. - כאשר בקשת ה-HTTP הראשונית מתקבלת באתר, האתר מחזיר תגובה עם עוגיה בעלת זיהוי ייחודי. - העוגיה מקושרת על ידי הדפדפן לשימוש בבקשות עתידיות מהאתר, על מנת לזהות את דנה. רשתות תקשורת מחשבים 24

usual http response msg עוגיות (cookies): שמירת "מצב" - המשך client Server (Amazon) usual http request msg usual http response + Set-cookie: 1678 cookie: 1678 usual http response msg cookie- specific action 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 רשתות תקשורת מחשבים 25

Cookie Parameters Example: Name (e.g. foo) Value (e.g. bar) Server x.y.com sends HTTP response header: Set-Cookie: foo=bar; path=/; expires … Browser echos in HTTP request header: Cookie: foo=bar Name (e.g. foo) Value (e.g. bar) Expiration date (default: till browser closes) Path (part of site to which cookie applies) Domain: to share with related domains (e.g.: .y.com) Secure: send only over secure (SSL) conncection HttpOnly: unavailable to scripts (even from domain)

עוגיות (cookies) - המשך עוגיות יכולות לספק: אישורים עגלת קניות המלצות התאמה אישית מצב session של משתמש (webmail) דבר נוסף: עוגיות, פרטיות ובטיחות: עוגיות מרשות לאתרים ללמוד עלינו. באפשרותם לחלוק מידע זה עם אתרים נוספים. אישורים מבוססים על עוגיות הם דבר בעייתי. לקראת סוף הקורס / קורס אבטחה. רשתות תקשורת מחשבים 27

If-modified-since: <date> If-modified-since: <date> Conditional GET – caching מצד הלקוח מטרה: אל תשלח אובייקט אם הלקוח בעל גרסה עדכנית שלו ב-cache. לקוח: פרט תאריך של אובייקט ב-cache בבקשת HTTP: If-modified-since: <date> (מועתק משדה last-modified) שרת: תגובה לא כוללת אובייקט אם העותק ב-cache עדכני: HTTP/1.0 304 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/1.0 200 OK <data> רשתות תקשורת מחשבים 28

Web Cache – בשרת הפרוקסי המטרה: לספק את בקשת הלקוח ללא עירוב של שרת המקור המשתמש מגדיר בדפדפן: גישה דרך cache דפדפן שולח את כל בקשות ה-HTTP ל-cache - האובייקט ב-cache: ה-cache מחזיר את האובייקט - אחרת ה-cache מבקש את האובייקט משרת המקור ואז מחזיר את האובייקט ללקוח origin server Proxy server HTTP request HTTP request client HTTP response HTTP response HTTP request HTTP response client origin server רשתות תקשורת מחשבים 29

עוד על caching למה Web Caching? הקטנת זמן תגובה לבקשות הלקוח cache מתנהג גם כמו לקוח וגם כמו שרת יכול לבדוק האם האובייקט עדכני באמצעות פתיח HTTP: "if-modified-since" בד"כ יותקן על ידי ספק האינטרנט (אוניברסיטה, ספק פרטי)  נכשל בדפים דינמיים  דורש דרישה לכל אובייקט שיפורים דרך script בדפדפן ו/או פרוקסי: - לדוגמה טעינה רק של עדכונים לגרסה שב-cache דורש שינוי הגדרות דפדפן - פרוטוקולים של "הגדרה עצמית" למה Web Caching? הקטנת זמן תגובה לבקשות הלקוח צמצום תעבורה על קו התקשורת של הארגון הורדת עומס על ספק התוכן, שדרת הרשת דוגמה... רשתות תקשורת מחשבים 30

DNS: Domain Name System אנשים: מאפיינים רבים: - שם, תז, דוא"ל נתבים, internet hosts: - כתובת IP (32 ביט) – משמשת לכיתוב datagrams, אחת לכל מתאם רשת (יכולות להיות 2) - שמות דומיין: colman.ac.il - Fully Qualified Domain Name (FQDN) או "שם", לדוגמה shai.cs.colman.ac.il - שמות: משמשים בני-אדם שאלה: מיפוי בין כתובות IP לשמות? Domain Name System: מסד נתונים מבוזר: ממומש בהררכיה של מספר רב של name servers פרוטוקול שכבת היישום: host, נתבים, שרתי שמות מתקשרים כדי לפענח שמות (כתובת/תרגום שם) - שימו לב: פונקציית אינטרנט פשוטהף ממומשת כפרוטוקול שכבת היישום - סיבוכיות ב"קצוות" הרשת - משמשת גם להפצת מידע אחר רשתות תקשורת מחשבים 31

DNS למה לא למרכז DNS? שרותי DNS נקודת כשל יחידה נפח תעבורה קירבה (קרוב ללקוח) אחזקה ובטחון -> אין קנה מידה! שרותי DNS תרגום hostname לכתובות IP כינויים ל-hosts - כינויים קבועים ומרובים כינויים לשרתי דואר הפצת עומס - שרתי web משוכפלים: סדרה של כתובות IP עבור שם ידוע אחד רשתות תקשורת מחשבים 32

TLD ושרתים מיהמנים שרתי Top Level Domain (TLD): שרתי DNS מיהמנים: אחראים על com,org,net,edu וכו' כמו גם על כל הדומיינים של המדינות: il, uk, fr, ca, jp - Network Solutions מתחזקת שרתי TLD של com - Educause עבור edu שרתי DNS מיהמנים: שרתי DNS של ארגונים, מספקים מיפוי מהימן של hostname ל-IP עבור מחשבי הארגון (לדוגמה web ודואר). - מתוחזקים על ידי הארגון או ספק שירות. Authoritative DNS servers רשתות תקשורת מחשבים 33

שרתי שמות בסיס (root) מקבלים פניות משרתי שמות מקומיים שלא יכולים לפענח שם. שרתי שמות בסיס: - אם מיפוי השם לא ידוע: קבל משרת השמות המהימן - החזר מיפוי לשרת השמות המקומי b USC-ISI Marina del Rey, CA l ICANN Marina del Rey, CA e NASA Mt View, CA f Internet Software C. Palo Alto, CA i NORDUnet Stockholm k RIPE London m WIDE Tokyo a NSI Herndon, VA c PSInet Herndon, VA d U Maryland College Park, MD g DISA Vienna, VA h ARL Aberdeen, MD j NSI (TBD) Herndon, VA 13 שרתי שמות בסיס (root) ברחבי העולם רשתות תקשורת מחשבים 34

מסד נתונים היררכי, מבוזר Root של DNS שרתי org של DNS שרתי edu של DNS שרתי comשל DNS שרתי של DNS שרתי poly.edu של DNS שרתי umass.edu של DNS שרתי pbs.org של DNS שרתי yahoo.com של DNS שרתי amazon.com SMTP : שליחת דואר משולח לשרת של המקבל - שאליתה לשרת הבסיס למציאת DNS של שרת com - שאליתה לשרת DNS של com (TLD) למציאת amazon.com - שאליתה לשרת ה-DNS של amazon.com למציאת כתובת IP של www.amazon.com רשתות תקשורת מחשבים 35

שרתי שמות מקומיים שאילתות מטופלות על ידי שרת שמות מקומי, לא על ידי לקוח DNS לא בהכרח שייכות להיררכיה (אין נוקשות). כל ISP (ללקוחות פרטיים, חברה, אוניברסיטה) בעל לפחות אחד. - נקרא גם "שרת שמות ברירת מחדל". כאשר host מבצע שאילתת DNS, השאליתה נשלחת לשרת ה-DNS המקומי. - משמש כמתווך (proxy), שולח קדימה בהיררכיה את השאילתה. רשתות תקשורת מחשבים 36

authoritative DNS server דוגמה: root DNS server host ב- cis.poly.edu מבקש כתובת IP של gaia.cs.umass.edu 2 3 TLD DNS server 4 5 local DNS server dns.poly.edu 7 6 1 8 authoritative DNS server dns.cs.umass.edu requesting host cis.poly.edu gaia.cs.umass.edu רשתות תקשורת מחשבים 37

Example: Typical, Iterative Resolution Client Local Server Root Server .com TLD Server 132.3.3.4 Authoritative bob.com Server 156.4.5.6 Resolve `A` www.bob.com Resolve `NS` com `NS` 132.3.3.4 Resolve `A` www.bob.com `NS` 156.4.5.6 Resolve `A` www.bob.com `A` 156.6.6.6 (IP of www.bob.com) Request to 156.6.6.6 (www.bob.com)

authoritative DNS server שאילתות רקורסיביות: requesting host cis.poly.edu gaia.cs.umass.edu root DNS server local DNS server dns.poly.edu 1 2 4 5 6 authoritative DNS server dns.cs.umass.edu 7 8 TLD DNS server 3 שאליתה רקורסיבית: מעמיסה את נטל פענוח השם על השרת אליו פונים עומס כבד? שאילתה איטרטיבית: השרת עימו נוצר קשר מחזיר שם של שרת ליצור איתו קשר. "אני לא יודע את השם הזה – אבל תשאלו את השרת הזה" רשתות תקשורת מחשבים 39

DNS: עדכון רשומות ו-caching מיפוי DNS שמורים ונשלחים ב-resource records (RR). שרתי DNS מבצעים caching של מיפויים (RRים). - זמן תפוגה (העלמות) של רשומות ב-cache אחרי ttl שניות. - ערך ttl מצוין בכל רשומת DNS. סוגים שונים של RR: - משמשים לפענוח שמות דומיין - ולמטרות אחרות... היכן שההפצה בין שרתי DNS היא שימושית לדוגמה הפצת רשימה שחורה של שרתי דואר מפיצי ספאם. דומיין עצמי (לדוגמה easy.10$.com), מריץ שרת DNS, מגדיר תת-עץ שרירותי תחתיו: policy.easy.10$.com... רשתות תקשורת מחשבים 40

RR format: (name, value, type, ttl) רשומות DNS DNS: מסד נתונים מבוזר המאחסן רשומות משאבים (RR) RR format: (name, value, type, ttl) סוג = CNAME - שם הוא "כינוי" לשם האמיתי. www.ibm.com הוא באמת: servereast.backup2.ibm.com סוג = MX - ערך הוא שם של שרת דואר המקושר לשם. סוגים אחרים... - בעיה: תמיכה על ידי שרתים. סוג = A - שם הוא hostname - ערך הוא כתובת IP סוג = NS - שם הוא הדומיין (למשל lala.com) - ערך הוא כתובת IP של שרת שמות מהימן לדומיין הזה. סוג = TXT - ערך הוא טקסט כלשהו : A (domainIP), NS (domainname server), ptr (IPdomain), cname (domaindomain), TXT (any text), MX (incoming mail server), A - רשומה זו היא כתובת IPv4‏ (Address) המשויכת לשם דומיין מסוים. AAAA - בדומה לטיפוס A, רשומה זו היא כתובת IPv6. NS - רשומה אשר מציינת שרת אשר משמש כאחראי למסירת מידע על הדומיין המבוקש. PTR - רשומה זו מכילה דומיין אשר משויכת לו כתובת IP מסוימת (על מנת ששרת ה-DNS יוכל לחפש דומיינים ע"פ כתובות IP). MX - מכילה את כתובתו של השרת המשמש את הדומיין לשליחה וקבלה של דואר אלקטרוני. CNAME‏ - "Canonical name", שם נוסף לאותו הדומיין. TXT - רשומה זו מאפשרת לצרף לכתובת ה-IP של הדומיין גם טקסט חופשי (משמשת למימוש שירותים שונים הקשורים בדומיין, כגון DomainKeys). SPF - סוג מיוחד של רשומת TXT המציינת את שמות הhosts מהם מותר למסור מייל בשם אותו דומיין. SOA - start of authurity - הרשומה אשר מצביעה על הימצאותו של ה- ZONE נותן אפשרות לתעל את השליחות לאותו אתר על מספר שרתים ועל ידי כך להוריד עומסים רשתות תקשורת מחשבים 41

DNS: פרוטוקול, הודעות פרוטוקול DNS: הודעות שאילתה ותשובה בעלות אותו פורמט של הודעה, עושות שימוש ב-UDP (למעט תשובות ארוכות) רכיבים: פתיח (header): - זיהוי: 16 ביטים (תאימות עם הודעת תגובה) למה זה נחוץ? - 4 דגלים: שאילתה/תגובה, רקורסיה רצויה, רקורסיה זמינה, תגובה מהימנה. - רשומות של מספר שאלות ותשובות. רשתות תקשורת מחשבים 42

הכנסת רשומות ל-DNS דוגמה: הרגע הוקמה חברת הזנק “Network Utopia”. נרשום את השם networkutopia.com אצל רשם (לדוגמה network solutions). - צריך לספק לרשם שמות וכתובות IP של שרת השמות המהימן (ראשי ומשני) - הרשם מכניס שני RR'ים לתוך שרת TLD של com: (networkutopia.com, dns1.networkutopia.com, NS) (dns1.networkutopia.com, 212.212.212.1, A) שים בתוך שרת השמות המהימן: רשומה מסוג A עבור www.networkutopia.com ורשומה מסוג MX עבור networkutopia.com איך אנשים מקבלים את כתובת ה-IP של האתר? כאשר אני שולח בקשה אני מקבל את כל התשובות בעיקר אם אני משרת לשרת 2) כאשר מתקינים שרת לרוב הוא מקבל רשימה של שרתי המקור 3) יש שלושה סוגים של שרתים, שורש, ראש ענף וסמכותי 4) זמנים לכל רשומה נקבע על ידי הסמכותי רשתות תקשורת מחשבים 43

DNS: Efficient (Reliable) Queries Goal: (reliable) scalability Minimize resources (storage) Load balancing, proximity (ask `closest` server) How? DNS uses UDP, not TCP (if possible) Reliability: identify (ID field, …), timeouts, … Less packets, RTT (no setup/teardown) No buffer allocation (esp. for recursive!) Multiple DNS servers for same IP Proximity Load balancing But: need to avoid IP fragmentation Use TCP if (and only if) packets are too long With separate connections for request, reply (why?) רשתות תקשורת מחשבים 44

בעיית הפצת התוכן הלקוחות מפוזרים ברחבי הרשת. שימוש בשרת מרכזי אחד זה רעיון גרוע... - שרת יחיד לא יכול לספק את כל הלקוחות. - העברת מידע לרוחב הרשת: תקורה, עומס. פתרונות: - הפצת מידע בצורת רשומות DNS (לדוגמה "רשימות שחורות" של ספאמרים). - שימוש ב-HTTP: מידע נשמר על ידי מתווכים (proxies). - איזון עומס: הרבה שרתים עם אותו IP (מתג חומרה בוחר שרת בצורה אקראית ושומר חיבורי TCP לאותו שרת). - DNS נותן כתובת IP מתוך מאגר או לפי מיקום (איזון עומסים וקירבה ללקוח). רשתות תקשורת מחשבים 46

רשתות הפצת תוכן (Content Distribution Networks – CDN) שכפול תוכן חברת CDN מתקינה מאות שרתי CDN ברחבי האינטרנט - בספקים ברמת נמוכות, קרוב ללקוחות. CDN משכפלת את התוכן של לקוחותיה בשרתי CDN. כאשר ספקים מעדכנים תוכן – CDN מעדכנת את השרתים. שרת מקור בצפון אמריקה CDN קודקוד הפצת של שרת CDN בדרום אמריקה שרת CDN באסיה שרת CDN באירופה רשתות תקשורת מחשבים 47

דוגמת CDN שרת מקור חברת CDN www.foo.com cdn.com מפיץ HTML HTTP request for www.foo.com/sports/sports.html DNS query for www.cdn.com www.cdn.com/www.foo.com/sports/ruth.gif 1 2 3 Origin server CDNs authoritative DNS server Nearby CDN server שרת מקור www.foo.com מפיץ HTML מחליף: http://www.foo.com/sports.ruth.gif ב-http://www.cdn.com/www.foo.com/sports/ruth.gif חברת CDN cdn.com מפיצה קבצי gif משתמשת בשרת DNS מהימן שלה לנתב בקשות שהופנו. - גם לטובת איזון עומס רשתות תקשורת מחשבים 48

Chapter 2: Application layer 2.1 Principles of network applications 2.2 Web and HTTP 2.3 FTP 2.4 Electronic Mail SMTP, POP3, IMAP 2.5 DNS 2.6 P2P file sharing 2.7 Socket programming with TCP 2.8 Socket programming with UDP 2.9 Building a Web server רשתות תקשורת מחשבים

FTP: the file transfer protocol user interface client file transfer FTP server user at host local file system remote file system transfer file to/from remote host client/server model client: side that initiates transfer (either to/from remote) server: remote host ftp: RFC 959 ftp server: port 21 רשתות תקשורת מחשבים

FTP: separate control, data connections client server TCP control connection port 21 TCP data connection port 20 FTP client contacts FTP server at port 21, specifying TCP as transport protocol Client obtains authorization over control connection Client browses remote directory by sending commands over control connection. When server receives file transfer command, server opens 2nd TCP connection (for file) to client After transferring one file, server closes data connection. Server opens another TCP data connection to transfer another file. Control connection: “out of band” FTP server maintains “state”: current directory, earlier authentication רשתות תקשורת מחשבים

FTP commands, responses Sample commands: sent as ASCII text over control channel USER username PASS password LIST return list of file in current directory RETR filename retrieves (gets) file STOR filename stores (puts) file onto remote host Sample return codes status code and phrase (as in HTTP) 331 Username OK, password required 125 data connection already open; transfer starting 425 Can’t open data connection 452 Error writing file רשתות תקשורת מחשבים

בתכנית פרק 2 בספר FTP דואר אלקטרוני DNS הפצת תוכן - SMTP, POP, IMAP DNS הפצת תוכן - רשתות הפצת תוכן - שיתוף קבצים P2P פרק 2 בספר עקרונות פרוטוקולים של יישומים עם שכבות - לקוחות ושרתים - דרישות של יישומים - בחירת שירות תעבורה - תכנות sockets Web ו-HTTP - סקירה של HTTP - חיבורים: עקבי, pipline - בקשות / תגובות - אימות ו-cookies - Caching ו-Proxies רשתות תקשורת מחשבים 53

דואר אלקטרוני שלושה מרכיבים מרכזיים: סוכני משתמש (לקוח דואר) POP3 user mailbox outgoing message queue user agent שלושה מרכיבים מרכזיים: סוכני משתמש (לקוח דואר) שרתי דואר (עם תיבות דואר) פרוטוקולים: SMTP (simple mail transfer protocol), POP ... סוכני משתמש (user agents): ידועים גם כ: "קורא / לקוח דואר" לדוגמה: outlook, eudora, webmail (הוטמייל, ג'ימייל) כתיבת דואר ושליחתו לשרת איסוף דואר (מתיבה על השרת) POP3 mail server SMTP user agent SMTP mail server user agent SMTP mail server SMTP user agent SMTP – Simple Mail Transfer Protocol POP3 – Post Office Protocol IMAP – Internet Message Access Protocol צריך להדגיש את ההבדל בין פרוטוקול של שליחת מיילים בין הלקוח השרת, בין השרתים לבין פרוטוקול לגישה אל המיילים מתוך אפליקצית הלקוח SMTP user agent user agent רשתות תקשורת מחשבים 54

פרוטוקולי איסוף דואר אלקטרוני Send: SMTP (or ____) Pick-up protocol SMTP Mail user agent Mail user agent Alice’s mail server B.com (Bob’s domain) A.com (Alice’s domain) Bob’s mail server Bob’s mail server פרוטוקול איסוף דואר (גישה) : איסוף משרת - POP: Post office protocol ver 3 (RFC 1939) אימות (שרת   סוכן) והורדה. - IMAP: Internet Mail Access Protocol (RFC 1730) יותר אפשרויות לדוגמה ניהול הודעות בתיקיות. יותר מסובך - פחות נפוץ - HTTP: הוטמייל, ג'ימייל, יאהו וכדומה. אימות בדרך כלל על ידי סיסמה, עוגיות. רשתות תקשורת מחשבים 55

דואר אלקטרוני – שרתי דואר תור הודעות של הודעות דואר יוצאות (צריכות להשלח) תיבות דואר של הודעות נכנסות שימוש ב-SMTP, פרוטוקול סטנדרטי לשליחת, קבלת הודעות דואר אלקטרוני - דגש על חיבוריות ושיתוף משאבים - מופעל על ידי שליחת דואר (סוכן לקוח או שרת דואר) “mail transfer client” - ליעד או לממסור “mail transfer server” - קיימים פרוטוקולים אחרים (פרטיים) לדוגמה exchange, notes קבלת דואר מסוכן לקוח: לעיתים קרובות דרך SMTP... user agent mail server user agent SMTP mail server user agent SMTP mail server SMTP user agent user agent user agent רשתות תקשורת מחשבים 56

שליחת דואר מסוכן לקוח SMTP Send: SMTP (or ____) Pick-up protocol B.com user agent user agent sender’s mail server B.com (Bob’s domain) A.com (Alice’s domain) receiver’s mail server SMTP : שליחת דואר משולח לשרת של המקבל - שרת הדואר של השולח בדרך כלל מוודא שהשולח הוא משתמש ידוע (כדי לא להעביר דואר זבל) - כל שרת דואר מוסיף לפתיח: recived: from … <time> מאפשר להתחקות אחר דואר מזוייף. זיהוי שרת המקור לפי כתובת IP אפשרי גם לפי שם דומיין מלא וקביל (mail.colman.ac.il) - זה לא מאומת – רק עותק של מה שהשרת השולח הוסיף. רשתות תקשורת מחשבים 57

תרחיש: אליס שולחת הודעה לבוב אליס משתמשת ב-UA על מנת לחבר את ההודעה ולהכניס שדה "אל": bob@school.edu ה-UA של אליס שולח את ההודעה לשרת הדואר שלה; ההודעה נכנסת לתור ההודעות. שרת הדואר של אליס (MTA) פותח חיבור TCP עם שרת הדואר של בוב (כלקוח SMTP) 4) שרת הדואר של אליס שולח את הודעתה של אליס על גבי חיבור ה-TCP תוך שימוש ב-SMTP. 5) שרת הדואר של בוב שם את ההודעה בתיבת הדואר של בוב. 6) בוב מזמן את סוכן המשתמש שלו כדי לאסוף את ההודעה מהשרת (תוך שימוש ב-SMTP, POP3, HTTP... mail server mail server 1 user agent user agent 2 3 6 4 5 רשתות תקשורת מחשבים 58

Simple Mail Transfer Protocol (SMTP) עושה שימוש ב-TCP כדי להעביר בצורה אמינה דואר אלקטרוני מלקוח העברת דואר לשרת העברת דואר (מחכה על פורט 25) - לקוח: סוכן משתמש או שרת דואר שולח העברה ישירה: שרת/לקוח שולח דואר לשרת דואר מקבל 0או דרך שער גישה/ ממסור) 3 שלבים להעברה - לחיצת יד (ברכות...) - העברת הודעות - סיום פקודות/תגובות אינטראקציה - פקודות: טקסט ASCII - תגובה: קוד סטטוס ותאור סטטוס רשתות תקשורת מחשבים 59

SMTP Phases Handshake (greeting) Transfer of one or more messages: TCP Connection Setup: SMTP-server rejects if overloaded Server hello: sends 220 B.com Server may delay hello (until ready) Client hello: sends HELO A.com Or EHLO (extended hello: supports options) Transfer of one or more messages: MAIL FROM: sender email (for error report) RCPT TO: recipient that Receiver-SMTP should deliver to Multiple recipient by multiple RCPT TO commands Data: RFC 822 message (with headers), then terminator Closure SMTP closure: C: QUIT, S: 221 TCP connection closure (initiated by SMTP-client) For efficiency, it is important to use a single SMTP connection for as many messages as possible; this is not just the overhead of opening and closing the connections, but more significantly, the impact of TCP slow start congestion control mechanism. We can add numerical example here. רשתות תקשורת מחשבים 60

SMTP Envelope SMTP delivers each message by the sequence: MAIL FROM: alice@a.com RCPT TO: bob@b.com Repeat for more recipients DATA Mail envelope: MAIL FROM:, RCPT TO: addresses SMTP uses these fields to route / reject messages Accept only mail to known users More on this later Distinct from “similar” Email message headers (RFC 822, 2822, 5322) RCPT TO: bob@b.com MAIL FROM: alice@a.com Mail Envelope: The data (addresses) defined in the SMTP `RCPT TO` and `MAIL FROM` commands for a particular email message, identifying the recipient and the sender (or more precisely, `bounce to`) addresses רשתות תקשורת מחשבים 61

דוגמה לחיבור SMTP (אינטראקציה) S: 220 B.com C: HELO A.com S: 250 Ok C: MAIL FROM: <alice@a.com> C: RCPT TO: <bob@b.com> C: DATA S: 354 Enter mail, end with "." on a line by itself C: <mail message – RFC 822 format> C: . C: QUIT S: 221 b.com closing connection דוגמא לתהליך העברת מייל בין שני שרתי מיילים אפשר לראות שיש תהליך פתיחת קשר, העברת מידע ותהליך סגירת קשר רשתות תקשורת מחשבים 62

מבנה הודעת דואר (RFC 822) header body SMTP: פרוטוקול המשמש להחלפת הודעות דואר אלקטרוני RFC 822: התקן למבנה הודעות טקסט: שורות פתיח, לדוגמה: - מאת (from) - אל (to) - נושא (subject) שונה מפקודות SMTP! גוף - ההודעה בפורמט ASCII ניתן להדפסה - איך שולחים לא ASCII? header blank line body רשתות תקשורת מחשבים 63

MIME: multimedia mail extension איך שולחים מידע שאינו ASCII (תמונה, תוכנה)? encode: ממפים בייטים של מידע לבייטים של ASCII הניתנים להדפסה - לדוגמה קוד HEX ; בד"כ משתמשים בבסיס 64 – יותר מכווץ. זיהוי בכותרת: גרסת MIME, Encoding, סוג מידע ותת-סוג. - סוגים: טקסט, תמונה, אודיו, וידאו, יישום, רב חלקים (multipart) From: alice@crepes.fr To: bob@hamburger.edu Subject: Picture of yummy crepe. MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Type: image/jpeg base64 encoded data ..... ......................... ......base64 encoded data MIME גרסת שיטה שבה משתמשים כדי לבצע encode למידע סוג מולטימדיה, תת-סוג והכרזה על פרמטרים encoded data Multipart: multiple parts (with separators defined in header) רשתות תקשורת מחשבים 64

Envelope, Message, Forwarding S: 220 B.com C: HELO acm.org S: 250 OK C: MAIL FROM: <alice@a.com> C: RCPT TO: bob@b.com C: DATA S: 354 Enter mail, end with "." on a line by itself C: from: alice@wonderland.com C: to: bob@acm.org, otis@o.net C: C: what a wonderful message C: . C: QUIT S: 221 b.com closing connection Server (S:) B.com (Bob’s current company) Sender (client) MTA: acm.org (forwarding srvc.) Inform of delivery error (`bounce`) RFC822/2822 Email Message Syntax We now highlight on a related pair of SMTP envelope field and RFC 822 email message field: the 822 `To:` field, vs. the `RCPT TO:` envelope field. We see here that the RFC 822 (message) To: field contains a name not in RCPT TO: envelope field. This is since this recipient, otis@o.net, is in a different domain (o.net, not b.com) and therefore mail to it is sent over separate connection. רשתות תקשורת מחשבים 65

Multiple recipients, BCC S: 220 sponge.com C: HELO A.com S: 250 OK C: MAIL FROM: <alice@a.com> C: RCPT TO: manager@sponge.com C: RCPT TO: bob@sponge.com C: DATA S: 354 Enter mail, end with "." on a line by itself C: from: alice@wonderland.com C: to: bob@sponge.com C: C: I _still_ did not receive the goods you promised C: . C: QUIT S: 221 b.com closing connection Notice also multiple RCPT TO (one per recipient, all in same domain) Another case of recipient enve diff from recipient in message: forwarding and mailing lists רשתות תקשורת מחשבים 66

SMTP Error Handling Reliability: Key goal of SMTP If agent cannot deliver before sending OK: Recipient not known, sender not allowed, queue full, etc. Signal to Sender-SMTP by error code Permanent (5xx) or transient (4xx) error codes On error in transfer to next mail server: Transient error (4xx): retransmit after reasonable delay May try alternate route (use secondary mail server) If agent cannot deliver (after sending OK): Send Delivery Status Notifications (DSN) to bounce (mail from) address DSN has empty MAIL FROM field bounce address : In servers: use SMTP MAIL FROM (envelope) field In receiving MUA: use Return-Path: header (if no Return-Path: header in received email, then the receiving MDA creates it with the MAIL FROM address, before delivering to the MUA) רשתות תקשורת מחשבים 69

פרוטוקול POP3 S: +OK POP3 server ready שלב האישור: C: user bob C: pass hungry S: +OK user successfully logged in C: list S: 1 498 S: 2 912 S: . C: retr 1 S: <message 1 contents> C: dele 1 C: retr 2 S: <message 2 contents> C: dele 2 C: quit S: +OK pop3 server signing off שלב האישור: פקודות משתמש: - user: הכרזה על שם המשתמש - pass: סיסמה תגובת שרת: - +OK - -ERR שלב ה'עסקה': list: רשימת מספרי הודעות retr: הבא הודעה (לפי מספר) dele: מחק quit תהליך מעבר מידע בין משתמש לשרת בעזרת פרוטוקול פופ 3 אפשר לראות פתיחת קשר על פי שם וססמא לאחר מכן הצהרה על מספר הודעות ומשקל כל הודעה, הורדת הודעות על פי בקשה ומחיקת על פי בקשה. סוף המצגת רשתות תקשורת מחשבים 70

POP3 (המשך) ו-IMAP פרק 2 בספר FTP דואר אלקטרוני DNS הפצת תוכן - SMTP, POP, IMAP DNS הפצת תוכן - רשתות הפצת תוכן - שיתוף קבצים P2P פרק 2 בספר עקרונות פרוטוקולים של יישומים עם שכבות - לקוחות ושרתים - דרישות של יישומים - בחירת שירות תעבורה - תכנות sockets Web ו-HTTP - סקירה של HTTP - חיבורים: עקבי, pipline - בקשות / תגובות - אימות ו-cookies - Caching ו-Proxies רשתות תקשורת מחשבים 71

מערכות 'אנטי ספאם' סטנדרטיות ספאם: - רב הנפח בלתי מוזמן - פרסומות / דואר בלתי רצוי רב הזמן - ללא כותרת ברורה בעיה משמעותית - 80% מהדואר... אין 'ממסור פתוח' - ממסור בתוך הרשת – בסדר חסימת פורט 25 - מונע מספאם ישירות ממחשב, יציאה רק דרך MSA\MTA אימות שולחים - במיוחד מבחוץ - מכסות Internet MTA A MTA B MSA Carl's MUA MDA MTA X Alice's MUA Bob's MUA Al Domain a.com Domain b.com © Gila Kaplan (with permission) - אז: האם ID של השולח מאומת? לא... רשתות תקשורת מחשבים 72

rDNS response sender.com E-mail & DNS rDNS response sender.com MX request b.com DNS Server rDNS request xx.xx.xx.xx MX response mail.b.com Sender MTA SRC IP=xx.xx.xx.xx Recipient MTA 220 Ok Helo sender.com  250 Ok MAIL FROM: alice@a.com   250 OK RCPT TO: bob@b.com   250 OK DATA   354 Enter mail ... Deliver mail Send mail Recipient Sender רשתות תקשורת מחשבים 73

יישומי peer-to-peer (P2P) אליס בוחרת את אחד ה-peers, בוב. הקובץ מועתק מהמחשב של בוב למחברת (notebook) של אליס, ב-HTTP. בזמן שאליס מורידה, משתמשים אחרים מעלים מאליס. ה-peer של אליס הוא גם לקוח web, ושרת ממסור web. של ה-peers הם שרתים = פשוט להגדלה! P2P זה לא לקוח-שרת! - דוגמה: שיתוף קבצים אליס מקבלת כתובת IP חדשה בכל פעם שהיא מתחברת לרשת. משתמשת ביישום לשיתוף קבצים. שאלות: - איך מוצאים מידע? - איך מקבלים מידע? - מוטיבציה לשיתוף? רשתות תקשורת מחשבים 74

השוואה בין ארכיטקטורת לקוח-שרת, P2P שאלה: כמה זמן לוקח להפיץ קובץ שנמצא על שרת אחד ל-N מחשבים אחרים? us – רוחב פס של משתמש להעלאה ui – רוחב פס של הלקוח/peer ה-i להעלאה di – רוחב פס של הלקוח/peer ה-i להורדה רשתות תקשורת מחשבים 75

זמן הפצת F ל-N לקוחות בגישת לקוח/שרת: Dcs=max{NF/us,F/min(di)} לקוח-שרת: זמן הפצת קובץ השרת שולח N עותקים בו-זמנית. - זמן: NF/us ללקוח i לוקח F/di להוריד את הקובץ. (גדל לינארית לפי N) זמן הפצת F ל-N לקוחות בגישת לקוח/שרת: Dcs=max{NF/us,F/min(di)} רשתות תקשורת מחשבים 76

P2P: זמן הפצת קובץ השרת שולח עותק אחד - זמן: F/us ללקוח i לוקח F/di להוריד את הקובץ. NF ביטים חייבים להיות מורדים (בסך הכל) - קצב העלאה הכי מהיר (בהנחה שכל הקודקודים שולחים חלקי קובץ לאותו peer): us+ ui זמן הפצת f ל-N לקוחות בגישת לקוח/שרת: Dp2p=max{F/us,F/min(di),NF/us + ui} רשתות תקשורת מחשבים 77

השוואה בין ארכיטקטורת לקוח-שרת, P2P רשתות תקשורת מחשבים 78

Query flooding: Gnutella fully distributed no central server public domain protocol many Gnutella clients implementing protocol overlay network: graph edge between peer X and Y if there’s a TCP connection all active peers and edges is overlay net Edge is not a physical link Given peer will typically be connected with < 10 overlay neighbors רשתות תקשורת מחשבים 79

Gnutella: protocol File transfer: HTTP Query message sent over existing TCP connections peers forward Query message QueryHit sent over reverse path Query QueryHit Scalability: limited scope flooding רשתות תקשורת מחשבים 80

Gnutella: Peer joining Joining peer X must find some other peer in Gnutella network: use list of candidate peers X sequentially attempts to make TCP with peers on list until connection setup with Y X sends Ping message to Y; Y forwards Ping message. All peers receiving Ping message respond with Pong message X receives many Pong messages. It can then setup additional TCP connections רשתות תקשורת מחשבים 81

Exploiting heterogeneity: KaZaA Each peer is either a group leader or assigned to a group leader. TCP connection between peer and its group leader. TCP connections between some pairs of group leaders. Group leader tracks the content in all its children. 2: Application Layer

KaZaA: Querying Each file has a hash and a descriptor Client sends keyword query to its group leader Group leader responds with matches: For each match: metadata, hash, IP address If group leader forwards query to other group leaders, they respond with matches Client then selects files for downloading HTTP requests using hash as identifier sent to peers holding desired file רשתות תקשורת מחשבים 83

KaZaA tricks Limitations on simultaneous uploads Request queuing Incentive priorities Parallel downloading For more info: J. Liang, R. Kumar, K. Ross, “Understanding KaZaA,” (available via cis.poly.edu/~ross) רשתות תקשורת מחשבים 84

File distribution: BitTorrent P2P file distribution tracker: tracks peers participating in torrent torrent: group of peers exchanging chunks of a file obtain list of peers trading chunks peer רשתות תקשורת מחשבים 85

BitTorrent (1) file divided into 256KB chunks. peer joining torrent: has no chunks, but will accumulate them over time registers with tracker to get list of peers, connects to subset of peers (“neighbors”) while downloading, peer uploads chunks to other peers. peers may come and go once peer has entire file, it may (selfishly) leave or (altruistically) remain רשתות תקשורת מחשבים 86

BitTorrent (2) Pulling Chunks Sending Chunks: tit-for-tat Alice sends chunks to four neighbors currently sending her chunks at the highest rate re-evaluate top 4 every 10 secs every 30 secs: randomly select another peer, starts sending chunks newly chosen peer may join top 4 “optimistically unchoke” Pulling Chunks at any given time, different peers have different subsets of file chunks periodically, a peer (Alice) asks each neighbor for list of chunks that they have. Alice sends requests for her missing chunks rarest first רשתות תקשורת מחשבים 87

BitTorrent: Tit-for-tat (1) Alice “optimistically unchokes” Bob (2) Alice becomes one of Bob’s top-four providers; Bob reciprocates (3) Bob becomes one of Alice’s top-four providers With higher upload rate, can find better trading partners & get file faster! רשתות תקשורת מחשבים 88

P2P: searching for information Index in P2P system: maps information to peer location (location = IP address & port number) . Instant messaging Index maps user names to locations. When user starts IM application, it needs to inform index of its location Peers search index to determine IP address of user. File sharing (eg e-mule) Index dynamically tracks the locations of files that peers share. Peers need to tell index what they have. Peers search index to determine where files can be found רשתות תקשורת מחשבים 89

ניתוח מקרה P2P: Skype P2P (מחשב-מחשב, מחשב-טלפון, טלפון-מחשב), יישום voice over IP (VoIP) - גם מסרים מיידים הפרוטוקול בשכבת היישום בבעלות פרטית (אינפרא אדום ב-reverse eng) - פרישה היררכית שרת לוגין של Skype קודקוד-על Supernode (SN) לקוחות Skype (SC) רשתות תקשורת מחשבים 90

Skype: ביצוע שיחה משתמש מפעיל Skype. SC נרשם ב-SN SC מבצע לוגין שרת לוגין של Skype קודקוד-על Supernode (SN) לקוחות Skype (SC) משתמש מפעיל Skype. SC נרשם ב-SN - רשימת אתחול של 'SNים SC מבצע לוגין שיחה: SC יוצר קשר עם SN ומוסר ID של היעד אליו רוצה לבצע שיחה. - SN יוצר קשר SN'ים אחרים (בפרוטוקול לא ידוע – אולי הצפה) בכדי למצוא כתובת של יעד השיחה: מחזיר כתובת ל-SC. SC מקשר ישירות ליעד, על גבי TCP (+ UDP). רשתות תקשורת מחשבים 91