סיכום רשתות תקשורת 2016 PDF

‫סיכום רשתות תקשורת – ‪2016‬‬ ‫נכתב על ידי – יוגב בוקובזה ‪ ,‬סיוון כהן ‪ ,‬לילך היימן ‪ ,‬מירית לסרי ‪ ,‬מיכל חג'ג ויאיר שלומי‪.‬‬ ‫בהצלחה‪‬‬...

‫סיכום רשתות תקשורת – ‪2016‬‬ ‫נכתב על ידי – יוגב בוקובזה ‪ ,‬סיוון כהן ‪ ,‬לילך היימן ‪ ,‬מירית לסרי ‪ ,‬מיכל חג'ג ויאיר שלומי‪.‬‬ ‫בהצלחה‪‬‬ ‫מבוא‬ ‫ספק שירות )‪ – (ISP‬תפקידו לקשר בין הלקוחות שלו לשאר האינטרנט‪.‬קיימות מספר דרגות )‪(tiers‬‬ ‫של ספקי שירות כאשר הלקוחות של ספקים בדרגות הנמוכות הם משתמשים ביתיים (למשל) והספקים‬ ‫בדרגות הגבוהות מקשרים בין ספקים בדרגות נמוכות לבין מרכז הרשת )‪.(core‬דוגמא‪ :‬בזק‪ ,‬הוט‪.‬‬ ‫פרוטוקול ‪" -‬שפה משותפת" בשביל מכונות על רשת האינטרנט‪.‬משתמשים בהם בכל מעברים‬ ‫ברשת ‪ (pc, router, switch...).‬מעבירים ביטים\פאקטים‪.‬מגדירים ‪ 3‬דברים עיקריים‪ :‬פורמט‬ ‫ההודעה‪ ,‬סדר ההודעות‪ ,‬הפעולות כששולחים\מקבלים‪.‬פרוטוקולים מיושמים בתוכנה או בחומרה‪.‬‬ ‫סיבות שמשתמשים בפרוטוקול‪.1 :‬מבנה אחיד של הודעות ‪.2‬התנהגות אחידה‪.3.‬שיתוף בין חומרות‬ ‫שונות‪ ,‬תוכנות שונות ושפות דיבור שונות‪-‬הפרוטוקול הוא שפה אחידה‪.4.‬הכנסת שינויים ועדכוני גרסא‬ ‫באופן סטנדרטי‪ -‬ע"י גרסאות ‪ RFC‬חדשות ומעודכנות יותר‪.‬דוגמאות‪ :‬שכבת האפליקציה‪( HTTP -‬נועד‬ ‫להעברת דפי ‪ HTML‬ואובייקטים שהם מכילים) שכב התעבורה‪( TCP -‬מבטיח העברה אמינה של‬ ‫נתונים בין ‪ 2‬תחנות ברשת מחשבים באמצעות לחיצת יד‪ ,‬יצירת קישור ושליחת נתונים על גבי קישור‪,‬‬ ‫מוודא שכל הנתונים הגיעו בצורה תקינה ובסדר הנכון) שכבת הרשת ‪(IP‬הפרוטוקול המרכזי בשכבת‬ ‫הרשת מהווה בסיס לרשת האינטרנט‪.‬העברת נתונים בין תחנות ברשת כולל כתובות‪,‬ניתוב) שכבת‬ ‫הקו ‪( Ethernet‬אחראי על העברת נתונים ברשת לוקאלית בעלת חיבורים פיזיים‪.‬משתמש בכתובות‬ ‫‪( MAC‬בנות ‪ 48‬ביטים) – צרובות פיזית בכרטיס הרשת‪ ).‬שכבה פיזית‪(DSL -‬טכנולוגיות להעברת‬ ‫אותות דיגיטליים ממחשב לאותות הנשלחים על קו הטלפון בתדרים שונים מתדרי הדיבור כך שכמעט‬ ‫ולא נוצרת הפרעה לשיחות)‬ ‫‪- LAN‬רשת אינטרנט מקומית שמחברת מספר תחנות קצה‪(.‬למשל ‪ wifi‬בבית)‪.‬יכולות להיות מכל מיני‬ ‫סוגים‪. cable modem, wireless -.‬‬ ‫‪ - Service‬אפליקציות מבוזרות שיש בהן מספר תחנות קצה שמתקשרות‪.‬לדוגמה מייל‪ ,‬ווב‪file ,‬‬ ‫‪ ,sharing‬משחק רשת‪.‬‬ ‫‪ -hosts‬נקודות קצה(מחשב‪,‬פלאפון)‬ ‫‪ -Accsess Network‬רשתות גישה‪ ,‬המהירה ביותר היא רשת ‪Etherne t‬‬ ‫תחנת קצה ‪ - End System‬מחשב אישי‪ ,‬לפטופ‪ ,‬טאבלט‪ ,‬סמארטפון‪ ,‬שרת לכולם יש את אותם‬ ‫פרוטוקולי תקשורת‪.‬‬ ‫‪ - Client & Server‬גם השרת וגם הלקוח רצים על תחנות קצה; השרת נותן שירות )‪ (service‬כלשהו‬ ‫ויש לו כתובת ‪ IP‬קבועה‪.‬הלקוח מבקש שירות מהשרת‪.‬‬ ‫מתאר קשר בין שני תוכניות מחשב כאשר אחת היא הלקוח שעושה פעולות של בקשות שירות‪,‬‬ ‫מתוכנית אחרת שהיא השרת שתפקידו למלא אחר הבקשות‪.‬‬ ‫‪- Peer to Peer‬כל תחנת קצה היא גם שרת וגם לקוח‪.‬כל תחנות הקצה מתקשרות עם כולן‪P2P.‬‬ ‫מאפשר לקבוצת מחשבים של משתמשים שהם בעלי אותה‬ ‫תוכנת תקשורת להתקשר אחד עם השני ולגשת ישירות לקבצים שעל הדיסק הקשיח ‪ ,‬מרבית‬ ‫התוכנות עוסקות בהעברת קבצים בין משתמשים כמו‪. eMule.‬‬ ‫חסרונות‪ :‬מסובך לניהול ואין מישהו אחד שמנהל ומרכז את הכל‬ ‫יתרונות‪ :‬המידע נמצא בכמה מקומות ואם לקוח אחד נופל לא אבד לנו מידע‪.‬‬  ‫ב‪ client&server‬ההוסט של הלקוח שולח בקשות לשרת ומקבל תגובה ממנו לעומת ‪ p2p‬שם יש‬ ‫שימוש מינימאלי ואפילו אפסי בשרתים‪.‬‬ ‫‪ -DSL‬נעשה שימוש בתדרים קיימים של הטלפון המידע על ה ‪ dsl‬מועבר לאינטרנט והקול של ה‪dsl‬‬ ‫מועבר דרך הטלפון‪.‬כל כמה מיל שניות שולחים הודעת אינטרנט וטלפון ויש רכיב שיודע לקבל את‬ ‫ההודעות ולפצל ל ‪ 2‬מידע דרך הטלפון ומידע דרך האינטרנט‪.‬‬ ‫‪ -Ethernet‬סוג של רשת גדולה יותר מרשת ביתית מתאימה יותר לחברות וכו'‪.‬‬ ‫‪ 2‬גישות להעברת מידע‪:‬‬ ‫‪( -packet switching‬מיתוג מנות) החבילות עוברות בנתיבים שונים (לא אקראי ולא בשליטה שלנו)‪.‬‬ ‫המשאבים לא נשמרים‪ ,‬המשאבים מתחלקים פר הודעה ולא לקוח (לפעמים יש המתנה בתור)‪.‬שלבים‪:‬‬ ‫‪.1‬מקבל דאטה לשליחה‪.2‬מפרק את הדאטה שיתאימו לחבילה ‪.3‬החבילות נשלחות‪.‬חסרון‪ -:‬אם‬ ‫קישור אחד עמוס אז נוצר עומס‪.‬יתרון‪ :‬מגיע לניצולת מלאה‪.‬אין בזבוז משאבים‪.‬תומך ביותר‬ ‫משתמשים‬ ‫‪-N‬לינקים בין הוסטים ‪-R‬קצב שליחה של ביטים ברוחב הפס ‪-L‬מס' ביטים שצריך להעביר‪link = L/R.‬‬ ‫)‪total = N*(L/R‬‬ ‫דוגמא‪Calculate time for sending packets: N*L/R :‬‬ ‫‪L(File size) = 1MB=1000KB=8000kbits‬‬ ‫‪R(Rate) = 10,000 bps‬‬ ‫‪N(Number of links) = 10,000 bps‬‬ ‫כמה זמן יקח לשלוח‪10 * 8000/10,000 = 8seconds (for 1 Mbyte) :‬‬ ‫‪( -circuit switching‬מיתוג מעגלים) נבחר נתיב בין מספר ראוטרים וכל החבילות עוברות במסלול זה‪.‬‬ ‫שלבים‪.1 :‬יצירת תקשורת ‪.2‬שמירה על קשר יעודי‪,‬קצב השידור קבוע ומאובטח‪.3‬סיום שיחה ע"י כל‬ ‫אחד מהצדדים‪.‬משתמשים בעיקר בעולם הטלפוניה‪.‬ברגע שנתפוס את הקו מישהו אחר לא יכול‬ ‫לתפוס אותו והמעגל נשמר לאורך זמן השיחה‪.‬חסרון‪ :‬שלוקח זמן ליצור אותו‪.‬בזבוז משאבים‪ ,‬מישהו‬ ‫אחד טופס את הקו ולא משתמש בו כל הזמן‪.‬קשה למימוש‪.‬קשה לתחזק‪.‬יתרון‪ :‬קצב שידור קבוע‬ ‫מובטח‪.‬טוב למערכות זמן אמת‪.‬שיטות שידור‪ -‬איך ניקח קו אחד ונלביש עליו כמה שיחות בו זמנית ‪2‬‬ ‫גישות‪(FDM.1 :‬לפי תדרים) התדר מחולק למספר המשתמשים וכל אחד מקבל חתיכה שעובדת כל‬ ‫הזמן עד שהתקשורת מסתיימת‪(TDM.2.‬לפי זמנים) הזמן בו מחולק למסגרות בעלות משך זמן קבוע‬ ‫וכל מסגרת מחולקת למס' קבוע של חריצי זמן יש הגבלה עד ‪ 4‬מעגלים(משתמשים)‬ ‫‪ =bitrate‬קצב השידור‬ ‫(כמה ביטים מקבל כל סלוט) ‪(frame rate * bits_per_frame‬סה"כ סלוטים)‬ ‫דוגמא‪Want to send 640,000bits / 640kbits :‬‬ ‫‪Using circuit‬‬ ‫‪24slots‬‬ ‫‪link total bitrate = 1.536 Mbps‬‬ ‫‪500 ms to create circuit‬‬ ‫כמה זמן יקח לשלוח‬ ‫נמצא כמה ניתן לשלוח בכל ‪1.536/24=64kbps SLO‬‬ ‫נחשב כמה פעמים נצטרך לשלוח(כל שליחה היא בשניה אחרת) ‪640/64= 10sec‬‬ ‫נוסיף לזמן שמצאנו א זמן יצירת המעגל ‪10+0.5 = 10.5 sec‬‬ ‫‪packet vs circuit‬‬  ‫ב ‪ circuit‬מאבדים פחות מידע והמהירות היא מקסימלית ההקצאה נשמרת על הסשן‪.‬לעומת ‪packet‬‬ ‫שם אין הקצאת משאבים לאורך המסלול הכל לפי דרישה‪ ,‬המשאבים לא נשמרים‪ packet.‬יותר טוב‬ ‫הוא יכול להכיל יותר משתמשים וזמן שליחה קצר יותר‪.‬‬ ‫נתב‪ -‬אחראי על העברת מידע בין תחנות ברשת‪ ,‬והנחיה של התעבורה מהמקור ליעד בדרך היעילה‬ ‫ביותר‪.‬מממש את שכבות ‪1-3‬‬ ‫לינק‪(-‬קישור) תווך בו עובר מידע‪.‬למשל חיבור ‪ ,Ethernet‬כאבל אופטי‪ ,‬חיבור לוויני ועוד‪.‬מטרתו היא‬ ‫הובלת הביטים בין הנקודות אותן הוא מחבר‬ ‫אבני בניין של האינטרנט‪ ISP, :‬נתב לינק‪ ,‬פרוטוקול‬ ‫‪ 3‬שירותים שמספקת האינטרנט כתשתית שירות‪.1 :‬קישור בין נקודות מרוחקות ע"י מציאת נתיב‬ ‫והעברת מידע ‪.2‬אבטחת אמינות המידע העובר ברשת ‪.3‬קישור ביו תחנות הנמצאות ברשת לוקאלית‬ ‫ע"‪ H‬אמצעי תקשורת‪.‬‬ ‫סוגי עיכוב של חבילה‪.1 :‬בזמן עיבוד של הראוטר‪ -‬הראוטר פאקט והוא צריך לדעת לאן הוא הולך‬ ‫ובאיזה יציאה לנתב אותו ולבדוק שגיאות ‪.2 checksum‬עיכוב בתורים‪ -‬אם יש עוד פאקט צריך לחכות‪-‬‬ ‫במיוחד כשיש הרבה משתמשים ודאטה תלוי ברמת העומס והוא הכי מורכב כי העיכוב שונה לכל אחת‬ ‫מהחבילות ותלוי במספר החבילות הממתינות לפניה בתור‪.3.‬הגידול בעיכוב אינו לינארי תלוי בעומס‪.‬‬ ‫הוא מורכב גם מבחינת גודלו –יכול להיות אינסופי‪.‬‬ ‫‪a=average packet arrival rate‬‬ ‫)‪R=link bandwidth (bps‬‬ ‫)‪L=packet length (bits‬‬ ‫‪important: traffic intensity = La/R‬‬ ‫‪Growth is not linear -‬‬ ‫‪Little traffic –small increase will add little delay‬‬ ‫‪Much traffic –small increase will add much delay‬‬ ‫כאשר ‪:1 La/R‬עיכוב תלוי בדפוס הגעה ‪Transmittionrate > arrival rate‬‬ ‫‪During burst queue length increases‬‬ ‫‪1st packet: time=0‬‬ ‫‪2nd packet: time=L/R‬‬ ‫‪N th packet: time=(n-1) * L/R‬‬ ‫‪.3.‬עיכוב בשידור כמה ביטים אפשר לשלוח בשניה ‪ L/R‬העיכוב המשמעותי ביותר‪ -‬אם רוצים לשדר‬ ‫קובץ גדול העיכוב יכול להגיע אף למספר דקות ‪.4‬עיכוב בפעפוע – הזמן שלוקח מהרגע שהחלק‬ ‫הראשון של הפאקט נשלח ועד הרגע שהוא הגיע‪ ,.‬מרחק‪/‬מהירות העברת נתונים = עיכוב הפעפוע‪.‬‬ ‫עוד סיבות לאיבוד חבילות שלא קשורות למה שציינו‪ :‬סיבות קשורות לתוכנה‪ :‬יירוש הפאקט ע"‪H‬‬ ‫תוכנה מזיקה‪ ,‬תקלת תוכנה בראוטר(תהליך תקוע או באג במימוש הפרוטוקול)חסימה ע"י חומת אש‪.‬‬ ‫סיבות קשורות לחומרה‪ :‬אבדן חשמל רגעי בזמן השידור או כאבל פגום‪ ,‬עומס יתר בקו‪.‬‬ ‫‪ -Throughput‬תפוקה‪ ,‬קצב ההורדה‪Rate = F/T bps )F bits, T seconds(.‬‬ ‫במערכת שיש לנו כמה לינקים קצב השידור יהיה זהה לקצב המינימלי מבין כולם(כלומר ה‪ links‬בעל‬ ‫הרוחב פס הקטן ביותר הוא זה שחקבע את קצב השידור) דוגמא‪ :‬יש ‪ 10‬משתמשים שרוצים להשתמש‬  ‫באותו לינק‪ ,‬התפוקה של כל נקודה תהיה המינימום מבין הלינקים‪.‬‬ ‫מודל השכבות‪ -‬הוא מודל המציג את הפעולות השונות הנדרשות על‪-‬מנת להעביר נתונים ברשת‬ ‫תקשורת ‪,‬ואת הסדר בין הפעולות השונות‪.‬המודל מתייחס לחומרה ‪,‬לתוכנה ולשידור וקליטת הנתונים‪,‬‬ ‫ובין השאר‪ ,‬מספק הסבר כללי על מרכיביה השונים של הרשת ועל תפקידי המרכיבים‪.‬יתרון‪ :‬במודל‬ ‫השכבות‪ ,‬לכל שלב זה לא משנה מה קורה בשלב אחר‪.‬השלבים הם (כמעט) עצמאיים‪.‬חסרון‪:‬חזרה על‬ ‫אותן פעולות בשכבות שונות‪ ,‬למשל מציאת שגיאות הפרה של עקרון ההפרדה ‪ -‬לפעמים יש‬ ‫פונקציונליות משותפת בין השכבות‬ ‫שכבת האפליקציה‪ -‬זו השכבה העליונה במודל היא ממונה על אספקת שירותי הרשת לתוכנות בהן‬ ‫משתמש הקצה שכבת היישום קובעת את סוג התקשורת בין מחשבים‬ ‫שכבת התעבורה‪-‬שכבה זו מספקת העברה של מידע מנקודת המוצא לנקודת היעד ברשת כלומר‬ ‫תקשורת בין נקודת קצה‪.‬אחראית על ניהול תקשורת‪ ,‬אמינות החיבור ואמינות הנתונים‪.‬כל אפליקציה‬ ‫מהשכבה שמעל בוחרת את פרוטוקול התעבורה המתאים לה‪.‬‬ ‫שכבת הרשת‪ -‬אחראית על מיפוי לוגי של הרשת והעברת נתונים על פי מיפוי זה‪.‬‬ ‫שכבת קו‪-‬שכבת הקו אחראית על מעבר הסיביות בין שתי תחנות של הרשת‪.‬שכבת הקו אחראית על‬ ‫העברת המידע למרות רעשים או תקלות או התנגשויות שיש בקו‪.‬חבילות נתונים בשכבת הקו מכונות‬ ‫ולתוספות הפרוטוקולים של השכבות הגבוהות‬ ‫"מסגרות )‪" (frames‬ומכילות‪ ,‬בנוסף למידע‬ ‫יותר‪ ,‬את כתובות ה ‪-MAC‬של תחנו המוצא והיעד‪.‬שכבה פיזית‪-‬התיווך הפיזי עליו עוברת התקשורת‪,‬‬ ‫לשים ביטים על הקו‬ ‫‪ -Encapsulation‬הכתובת שתירשם על הפאקט תשתנה בכל שלב הגעה לראוטר מסוים כלומר‬ ‫הכתובת תישמר שלב אחד אחורה‪.‬‬ ‫אבטחת אינטרנט ‪ :‬וירוס הוא קוד זדוני בדמות תוכנת מחשב החודרת למחשב ללא ידיעת המשתמש‪,‬‬ ‫וגורמת על פי רוב לפעילות לא רצויה העלולה לפגוע בתפקודו של המחשב או הרשת ותולעת היא‬ ‫תוכנית מחשב או מקטע מתוכנית מחשב אשר מאופיינת ביכולת הפצה עצמית (התפשטות) אל עבר‬ ‫מחשבים אחרים‪.‬תולעי מחשב לרוב נושאות "מטען" זדוני בדמות וירוס‪.‬בוטנט – רשת של מחשבים‬ ‫הנגועים ב ‪malure‬ומאפשרים ביצוע של תקיפות מסונכרנות למשל על אתרים אותם רוצים להפיל‪.‬כדי‬ ‫ליצור את הרשת יש צורך להדביק תחנות ברשת האינטרנט ע" תולעים או וירוסים או הפניה לאתרים‬ ‫זדוניים‪.‬‬ ‫‪ -DOS‬היא משפחת תקיפות שנועדה להשבית מערכת מחשב על ידי יצירת עומס חריג על משאביה‪.‬‬ ‫מתקפה כזו יכולה למנוע מקבוצת משתמשים גישה למשאב מחשב מסוים על ידי העמסת אותו‬ ‫המשאב כך שלמשתמשים הלגיטימיים לא יישארו משאבים‪.‬‬  ‫מושגים לשכבת האפליקציה‪:‬‬ ‫‪ :Client-Server.1‬מבנה‪ :‬השרת‪ -‬תמיד פעיל ומארח ‪ ,‬כתובת ‪ IP‬קבועה ‪ Scaling ,‬מאוד קשה‪.‬לקוח‪-‬‬ ‫מתקשר עם השרת ‪,‬מחובר לסירוגין‪ ,‬כתובת ‪ IP‬דינאמית ‪ ,‬לא מתקשר מול לקוח אחר ישירות‪:P2P.2.‬‬ ‫השרת לא תמיד פעיל ‪ ,‬תקשורת בין תחנות הקצה ‪ ,‬העמיתים משנים כתובות ‪.IP‬יתרונות – כמעט ולא‬ ‫דורש הקמת תשתית ‪ ,‬יכולת הרחבה כמו הוספת עמדת קצה‪ ,‬זול מבחינה כלכלית‪.‬חסרונות – קשה‬ ‫לנהל‪ ,‬בעיות אבטחה כי יש המון משתמשים ‪ ,‬לא ידידותי ‪,ISP‬דורש הרבה קצה העלאה‪ ,‬לרוב לא‬ ‫‪,open-source‬אם אבד מידע קשה לשחזר בגלל הפיזור‪ :Hybrid Client/Server and P2P.3.‬הכלאה‬ ‫של שרת לקוח ו‪.P2P‬שימוש של שרת לקוח‪ -‬יש שרת מרכזי ‪ ,‬עוזר למצוא כתובות של לקוחות‪–P2P.‬‬ ‫החיבור בין לקוח ללקוח הוא ישיר (לא דרך שרת)‪.‬דוגמאות‪( SKYPE :‬שרת מרכזי‪-‬מציאת כתובת של צד‬ ‫מרוחק ‪ -P2P ,‬חיבור ישיר בין הלקוחות)‪.4.instant messaging,‬תהליך (‪ :)Process‬תוכנית הרצה‬ ‫בתוך מחשב מארח‪.‬בתוך אותו המארח‪ ,‬שני תהליכים מתקשרים משתמשים בתקשורת בין תהליכים‬ ‫(שמוגדרת על ידי מערכת ההפעלה)‪.‬תהליכים במחשבים מארחים שונים מתקשרים ע"י החלפת‬ ‫הודעות‪.5.‬תהליך לקוח‪ :‬תהליך שמאתחל את התקשורת‪.6.‬תהליך שרת‪ :‬תהליך שממתין ‪ /‬מחכה‬ ‫להיות בקשר‪ :Socket.7.‬ממשק כלשהו בין האפליקציה לרמה התחתונה ‪ ,‬הנותנת את השירות‪.‬ב‪TCP‬‬ ‫הסוקט מזוהה ע"י ‪ 4‬שדות‪ :‬כתובת ‪ IP‬יעד ‪ ,‬מס' ‪ port‬יעד‪ ,‬כתובת ‪ IP‬מקור ‪ ,‬מס' ‪ port‬מקור‪.‬תהליך‬ ‫שולח‪/‬מקבל הודעות מ‪/‬אל הממשק‪.‬הממשק מקביל לדלת‪.‬ב‪ UDP-‬ה‪ Socket-‬מכיל רק כתובת ‪IP‬‬ ‫ומספר ‪ port‬בצד השרת (או בצד הלקוח)‪.‬הפניה היא תמיד לאותו ‪ port‬באותו ‪ IP‬ולא נוצר ‪socket‬‬ ‫חדש בכל פניה‪.‬ב ‪ tcp‬יווצר סוקט נפרד לכל אפליקציה שפונה לשרת וב‪ UDP‬כל האפליקציות ישלחו‬ ‫לאותו סוקט ‪,‬רק סוקט אחד יהיה פעיל בשרת ‪ :Socket API.8‬כדי לקבל מידע האפליקציה מתקשרת‬ ‫לפרוטוקול בעזרת ממשק ‪.Socket API‬הממשק הזה קובע‪ )1:‬בחירה של סוג שירות התעבורה‪-‬‬ ‫‪ )2 , TCP/UDP‬האם השירות קשור ב‪(connection‬ואז צריך לפתוח‪ ,‬להעביר הודעה‪ ,‬לקבל הודעה‬ ‫ולסגור) ‪ )3 ,‬זיהוי היעד – היעד הוא האפליקציה שאיתה רוצים לדבר במחשב יעד‪.‬ב‪ TCP-‬יווצר ‪socket‬‬ ‫נפרד לכל אפליקציה הפונה לשרת ב‪ UDP-‬כל האפליקציות ישלחו לאותו ‪ – socket‬רק ‪ socket‬אחד‬ ‫פעיל בשרת‪ ,‬והוא לא נוצר בעת פניית האפליקציה אלא בעת עליית השרת‪ :IP.9‬לכל תהליך במחשב‬ ‫צריך להיות מזהה‪.‬המזהה הינו ‪ ,IP Address‬שהינו כתובת של ‪ 32‬ביט‪.‬אך כתובת המחשב אינה‬ ‫מספיקה כי על אותו מחשב יכולים לרוץ מספר תהליכים ומספר אפליקציות‪ ,‬ויש צורך לזהות לאיזה‬ ‫מהם נשלחת הודעה מסוימת‪.‬לכן נצטרך גם ‪ :Port.10.PORT‬הוא השער שמזהה את האפליקציה‬ ‫באופן ייחודי על אותו המחשב‪.‬פורטים מוכרים‪.Telnet-23 , SMTP-25 , HTTP-80 :‬מה קורה אם מספר‬ ‫אפליקציות מנסות לקרוא מאותו ה‪ – ?port -‬זהו מצב אסור וגורם לשגיאות‪.‬על מנת להתגבר על כך‬ ‫יש כמה מנגנונים ‪ -‬יש מנגנון שבוחר ‪ port‬לכל אפליקציה וכן יש מנגנון שמקצה ‪ Port‬בצורה דינמית‪.‬‬ ‫‪ :Reliability.11‬יש צורך באמינות של התעבורה‪ ,‬כלומר שהמידע יגיע תקין ובשלמותו‪.‬שירות ‪TCP‬‬ ‫למשל‪ ,‬מבטיח אמינות גבוהה‪.‬בשירות זה כאשר מגיע‬ ‫מידע שגוי הדבר יזוהה ויישלח מחדש‪.‬הסיבה שלא כל היישומים משתמשים בשירות זה הוא בגלל‬ ‫התקורה (‪ )overhead‬הגבוהה‪ :Throughput.12.‬יש אפליקציות שרוחב הפס אינו קריטי עבורן‪.‬‬ ‫לדוגמא – דואר אלקטרוני‪ ,‬גלישה לאתרים‪.‬ולעומת זאת ישנן הרבה אפליקציות אחרות שבהן רוחב‬ ‫הפס הוא גורם מהותי לתפקודן‪ ,‬כגון ‪.video conference, streaming audio‬באפליקציות מהסוג‬ ‫האחרון‪ ,‬אם לא יהיה רוחב פס מינימלי אזי אין טעם לשרות‪ :Timing.13.‬יש אפליקציות שיכולות‬ ‫לעבוד עם השהיה מקסימלית מסוימת ויותר ממנה הן אינן יכולות לעבוד‪ :Security.14.‬לפעמים יש‬  ‫דרישות לאבטחה מהאפליקציה למשל שתהיה מוצפנת כשנשלחים סיסמאות‪.15.‬‬ ‫‪ :)Transmission control protocol(TCP‬שירות ‪.connection oriented‬בתחילת השידור יש‬ ‫‪ handshaking‬על מנת לקבוע את צורת הקשר‪.‬אמינות – מבטיח כי כל החבילות יגיעו ובאותו הסדר‬ ‫שנשלחו‪.‬בקרת זרימה – השולח לא ישלח יותר ממה שהיעד יכול לקבל ולטפל‪.‬על מנת להבטיח‬ ‫זאת יש שימוש בחוצצים אם מגיעות יותר מדי הודעות‪.‬בקרת עומס – אם הרשת איטית מדי‪,‬‬ ‫אפליקציית השולח מקבלת הודעה על כך על מנת שתתאים את הקצב שלה לקצב הרשת‪.‬‬ ‫התעבורה זורמת דרך נתבים‪ ,‬אך שירות התעבורה נמצא רק בשרת ובלקוח‪ TCP.‬לא מבטיח לשים‬ ‫חסם על ההשהיה או השהיה מקסימלית‪ ,‬וכן הוא אינו מבטיח רוחב פס‪.‬הוא אף לא מבטיח אבטחה‪.‬‬ ‫‪ :UDP.16‬אין תהליך של ‪ ,handshaking‬אין הקמת קשר ואין תהליך של סגירת קשר בצורה‬ ‫מסודרת‪.‬אין אמינות‪ ,‬המידע פשוט נשלח‪ ,‬ואין שום אינדיקציה האם הוא הגיע ליעד או לא‪.‬אין‬ ‫בקרת זרימה‪.‬אין בקרת עומס‪.‬טוב לתוכנות זמן אמת כי לא אכפת לנו איבוד מידע ‪ ,‬לפעמים חומת‬ ‫האש חוסמת אותו‪ :Secure Socket Layer\Transport Layer Security.17.‬הרחבת ‪ TCP‬על ידי‬ ‫הוספת אבטחה (הצפנה שמירה על יושר המידע ‪,‬בדיקת נקודת קצה)‪ ,‬זה לא עוד תוכנה אלא שכבה‬ ‫נוספת‪ ,‬מוסיף עוד סוקט(מקבל טקסט רגיל ומחזיר מוצפן) ‪ ,‬מצריך מימוש כלקוח וכשרת‪.18.‬‬ ‫‪ :HTTP‬פרוטוקול תקשורת שפועל בשכבת היישום ונועד להעברת דפי ‪ WEB‬המורכבים מאובייקטים‬ ‫כמו קבצי ‪ ,HTML‬תמונות‪ ,‬קבצי קול‪ ,‬סרטוני פלאש‪.‬התקשורת בין השרת ללקוח ב‪ HTTP-‬נעשית‬ ‫באמצעות בקשות ששולח הלקוח ותשובות שמחזיר השרת‪.‬לקוח ‪ -‬דפדפן (מבקש‪ ,‬מקבל‪" ,‬מציג"‬ ‫אובייקט ‪.)web‬שרת ‪ -‬שרת ‪( web‬שולח אובייקטים בתגובה לבקשות)‪".19.‬חסר מצב"‬ ‫(‪ :)Stateless‬השרת לא שומר מידע על בקשות של הלקוח‪ ,‬יענה אותו דבר בכל בקשה‪ ,‬יכול לטפל‬ ‫בהרבה לקוחות בו זמנית‪".20.‬תלוי מצב" (‪ :)Stateful‬השרת שומר מידע על בקשות של הלקוח‬ ‫ומתנהג בהתאם‪.‬פרוטוקול שומר מצב הוא מורכב‪ :)Uniform Resource Locator(URL.21.‬לכל‬ ‫אובייקט יש כתובת ‪ URL‬המורכב מ‪ host name‬ומ‪.path name‬לעיתים מכיל גם ‪ user name‬ופורט‪.‬‬ ‫‪.22‬חיבורים לא עקביים (‪ :)non-persistant‬לכל היותר אובייקט אחד נשלח על גבי חיבור ‪TCP‬‬ ‫יחיד‪.‬דפדפנים פותחים לעיתים קרובות חיבורי ‪ TCP‬מקבילים כדי להביא בו זמנית מספר אובייקטים‬ ‫אליהם יש הפניות‪.23.‬חיבורים עקביים (‪ :)persistant‬אובייקטים רבים יכולים להישלח על גבי‬ ‫חיבור ‪ TCP‬יחיד‪.‬השרת משאיר את החיבור פתוח אחרי שליחת תגובה‪.24.‬עקביים ללא‬ ‫‪ :pipelining‬לקוח שולח בקשה חדשה רק כאשר תגובה לבקשה קודמת נתקבלה‪.‬הודעות ‪HTTP‬‬ ‫עוקבות בין אותם לקוח‪/‬שרת נשלחות על גבי חיבור פתוח ‪ RTT‬אחד לכל אובייקט אליו יש הפניה‪.‬‬ ‫‪.25‬עקביים עם ‪ :pipelining‬לקוח שולח בקשות ברגע שהוא נתקל באובייקט אליו יש הפנייה‪.‬יכול‬ ‫להגיע גם ל‪ RTT-‬אחד לכל האובייקטים אליהם יש הפניות‪( RTT.26.‬זמן הלוך‪-‬חזור)‪ :‬הזמן שלוקח‬ ‫לשלוח חבילה קטנה מלקוח לשרת ובחזרה‪.‬זהו זמן פעפוע הלוך‪-‬חזור‪.‬זמן תגובה עבור חיבור לא‬ ‫עקבי‪ RTT :‬אחד ליצירת חיבור ‪ RTT , TCP‬אחד לבקשת ‪ + HTTP‬חזרה של בייטים של תגובת ‪HTTP‬‬ ‫זמן שידור קובץ ‪ ,‬סך הכל‪ + 2RTT :‬זמן שידור = זמן תגובה‪ RTT= 2*Tprop.‬עבור כל אובייקט‪.‬זמן‬ ‫תגובה עבור חיבור עקבי‪ RTT :‬ליצירת קשר ורק ‪ RTT‬אחד עבור כל אובייקט(שיטה חסכונית)‪.‬זמן‬ ‫תגובה עבור חיבור עקבי ללא ‪ RTT :pipelining‬ליצירת קשר ורק ‪ RTT‬אחד עבור כל אובייקט‪.‬זמן‬ ‫תגובה עבור חיבור עקבי עם ‪ RTT :pipelining‬אחד עבור כל הבקשות הנשלחות במקביל‪.27.‬‬ ‫עוגיות(‪ :)Cookies‬מנגנון זה מאפשר לשרת לשמור מידע מסוים אצל לקוח‪.‬זה עוזר לתקשורת‬ ‫וזיהוי בין שרת ללקוח‪.‬מבנה ה‪ Cookies -‬מכיל ‪ 4‬רכיבים‪ :‬שדה כותרת בהודעה מכיל תגובה של‬ ‫‪ , HTTP‬שורת הכותרת מכילה בקשה של ‪ ,HTTP‬קובץ שנשמר במחשב הלקוח‪ ,‬פרטים שנשמרים‬  ‫בבסיס נתונים של השרת‪.‬מה ‪ Cookie‬יכול להביא לשרת ‪ :‬זיהוי משתמש‪ ,‬כרטיסי קניה‪ ,‬הודעות‪,‬‬ ‫מידע על פעילות המשתמש אינטרנט‪ ,‬סכנה‪-‬פריצת אבטחה וחשיפת פרטיות במחשבי קצה‪.28.‬‬ ‫‪ :)Proxy server(Web Caching‬המטרה לספק את בקשת הלקוח ללא מעורבות של השרת‬ ‫המקורי‪.‬המשתמש מגדיר דפדפן‪ :‬כניסות לאינטרנט דרך המטמון ‪ ,‬הדפדפן שולח את כל בקשות‬ ‫ה‪ HTTP‬למטמון – המטמון מחזיר אובייקט אם יש‪ ,‬אחרת מבקש מהשרת המקורי ואז מחזיר את‬ ‫האובייקט ללקוח‪.‬המטמון פועל גם בלקוח וגם בשרת‪.‬המטמון מותקן בדרך כלל על ידי ‪.ISP‬‬ ‫יתרונות‪ :‬עוזר לצמצם את זמן התגובה לבקשת הלקוח ‪ ,‬להקטין את התנועה על מוסד הגישה של‬ ‫הקישור(הקטנת התנועה ברשת) ‪ ,‬מאפשרת לספק תוכן "עני" ביעילות‪:Conditional GET.29.‬‬ ‫מטרת ה‪ conditional GET -‬היא לצמצם את זמן הגישה והיא עושה זאת על ידי כך שאם תאריך‬ ‫העדכון האחרון של הדף על השרת זהה לתאריך העדכון של הדף שכבר קיים ב‪ cache -‬של‬ ‫המשתמש‪ ,‬הוא לא יישלח שנית אלא הדף הקיים יוצג‪.‬השימוש בשיטה זו נעשה על ידי הוספת‬ ‫שדה ב‪ ,header-‬המבקש לשלוח את הדף רק אם הוא עודכן אחרי תאריך מסוים‪:FTP.30.‬‬ ‫פרוטוקול תקשורת מבוסס ‪TCP‬להעברת קבצים בין מחשבים‪.‬באמצעות פרוטוקול זה‪ ,‬תוכנת לקוח‬ ‫‪FTP‬מתקשרת עם תוכנת שרת ‪, FTP‬לשם לקיחת קובץ מהשרת או הוספת קובץ אליו‪.‬דורש אימות‬ ‫(משתמש וסיסמא)‪ :EMAIL.31.‬יישום רשת‪ ,‬המאפשר לשלוח לנמענים ברחבי העולם חומר כתוב‬ ‫המלווה בתמונות‪ ,‬גרפיקה‪ ,‬קטעי קול ועוד‪.‬פועל על פי מודל של שרת‪-‬לקוח‪.‬תיבת דוא"ל‪ :‬כדי שאדם‬ ‫יוכל לקבל דוא"ל הוא צריך שתהיה לו תיבת דוא"ל (‪.)mailbox‬תיבת הדוא"ל היא קובץ בשרת‬ ‫דוא"ל בו נשמרות כל ההודעות של הנמען‪.‬השרת מאפשר גישה רק לבעל התיבה ע"י תהליך זיהוי‪.‬‬ ‫כתובת דוא"ל‪ :‬לכל תיבת דוא"ל יש כתובת דוא"ל (‪ )email address‬ייחודית‪ :User Agent.32.‬דרכו‬ ‫הלקוח קורא וכותב את ההודעות (דוגמא ‪ :Mail Server.33.)outlook‬דרכו נשלחות ההודעות‪.‬‬ ‫השרת מורכב מהרבה תיבות דואר של משתמשים שונים‪.‬הוא מחזיק תור של הודעות יוצאות‬ ‫שצריכות להישלח לשרתים אחרים‪.‬משתמש ב‪Simple Mail Transfer (SMTP.34.SMTP‬‬ ‫‪ :)Protocol‬הפרוטוקול העיקרי בו משתמשים לשליחת דוא"ל‪.‬משמש למשלוח דוא"ל בין שרתים‬ ‫שונים‪ ,‬עד שיגיע לשרת היעד‪ ,‬אך אינו מאפשר למשתמש לשלוף את הודעות הדואר המיועדות אליו‬ ‫מן השרת‪ SMTP.‬עובר מעל ‪ TCP‬ומשתמש בדרך כלל בפורט ‪.25‬מכיל מנגנון ‪ handshake‬ברמת‬ ‫האפליקציה‪.‬ישן ומאלץ לשלוח הודעות באסקי של ‪ 7‬סיביות ‪:(Post Office Protocol) POP3.35‬‬ ‫פרוטוקול לשליפה של הודעות דואר אלקטרוני משרת דואר מרוחק‪.‬זהו פרוטוקול שרת‪-‬לקוח‪.‬צד‬ ‫הלקוח מתחבר אל השרת‪ ,‬מוריד ממנו את ההודעות במלואן בסדר שבו התקבלו‪ ,‬ושומר אותן על‬ ‫מחשב הלקוח‪.‬לאחר מכן ההודעות נמחקות מהשרת‪.‬אחת מחולשותיו של ‪ POP3‬המקורי היא‬ ‫שהוא לא מאפשר אימות מוצפן מול השרת‪ ,‬וכל ההזדהות של הלקוח בוצעה בטקסט גלוי‪.‬כיום‬ ‫קיימות מספר הרחבות לפרוטוקול‪ ,‬המאפשרות שיטות שונות של הצפנת הקשר בין הלקוח והשרת‪.‬‬ ‫חסרון נוסף – אם קרא הודעות ומחק לא יראה את ההודעות מעמדה אחת ולא יראה שינויים שנעשו‬ ‫בהודעה‪ :(Internet Message Access Protocol) IMAP.36.‬הוא פרוטוקול אינטרנט לגישה לדואר‬ ‫אלקטרוני שנמצא על שרת מרוחק ממחשב מקומי‪.‬מהווה אלטרנטיבה מתקדמת לפרוטוקול‬ ‫‪.POP3‬יתרונות ‪ -‬פרוטוקול ‪ IMAP‬מאפשר עבודה עם מספר תיבות דואר‪ IMAP ,‬מאפשר אימות‬ ‫מוצפן ‪ ,‬ההודעות מאוחסנות בשרת ונגישות מכל מחשב ‪ ,‬ההודעות מגובות וניתן לשחזור‪.‬חסרונות‬ ‫– ההודעות נטענות איטי יותר(במיוחד בפעם הראשונה כשהם נקראות)‪ ,‬קשה לעבוד איתו ולכן‬ ‫הרבה מהשרתים והלקוחות מממשים אותו בצורה חלקית‪.‬מסיבה זו ‪ IMAP‬לא הפך פופולארי כמו‬ ‫‪ :(Domain Name System) DNS.37.POP3‬מערכת לתרגום שמות לכתובות ‪ IP‬ורוכבת על גבי‬  ‫פרוטוקול ‪(UDP‬כדי שיהיה מהיר)‪.‬המערכת בנויה משרתים המחזיקים מאגרי מידע בצורה מבוזרת‬ ‫לפי היררכיות בכדי להתמודד בעיקר עם הבעיות הבאות‪ :‬נקודת כשל יחידה‪ ,‬עומס תעבורה‪ ,‬מרחק‬ ‫פיזי מתחנות היעד‪ ,‬תחזוקה שוטפת‪.‬ע"י ה ‪-DNS‬ניתן להציע שירותים מבוססי שם נוספים‪ ,‬כגון‬ ‫רישום של שרתי דואר‪.‬מכילה פרוטוקול בשכבת האפליקציה על מנת לתרגם שמות לכתובות וזה‬ ‫מוסיף סיבוכיות בקצה הרשת‪.‬הסיבוכיות ב"קצה"‪ :Root DNS Servers.38.‬מחזיקים את הכתובות‬ ‫של שרתי ‪ )Top Level Domain( TLD‬וממירים בין הסיומת של ה‪ domain-‬לבין כתובת ה ‪ IP‬של שרת‬ ‫ה ‪ TLD‬הרלוונטי‪.‬לשרתים אלו פונים כאשר לא יודעים מאיפה להשיג את הכתובת‪.‬השרת שאמור‬ ‫לדעת את המיפוי לא יודע מהו המיפוי ולא יודע מיהו שרת הסמכות‪.‬ישנם ‪ 13‬שרתים כאלו‪.‬הם‬ ‫אינם יודעים את המיפוי עצמו אלא הם יודעים מהו השרת הסמכותי עבור כל כתובת‪Top.39.‬‬ ‫‪ :Level Domain‬שרתים אלו אחראיים על הסיומות‪ ,‬כגון‪.com, org, il, gov, etc. :‬שרתים שיודעים‬ ‫למפות את כל הכתובות במרחב כתובות מסוים (למשל בתוך ‪.)biu.ac.il‬לכל מרחב שמות יש‬ ‫לפחות שני שרתי ‪ DNS‬שהכתובת ידועה להם‪.‬כל שינוי של כתובת מצריך שינוי בשני השרתים‪.40.‬‬ ‫‪ :Authoritative DNS Servers‬כל ארגון‪ ,‬או חברה שרוצה לאפשר למשתמשים להתחבר אליה‪,‬‬ ‫צריכה להחזיק שרת הממיר בין שם ה‪ domain-‬שלה לבין כתובות ה ‪ IP‬של השרתים שלה (או‬ ‫לחילופין לשכור מקום בחברת אחסון אתרים)‪.‬לרוב‪ ,‬חברות וארגונים גדולים (כגון אוני'‪ ,‬גוגל‪ ,‬וכו')‬ ‫יחזיקו שרתים שלהם‪ ,‬לעומת אנשים פרטיים או חברות קטנות שישתמשו בשירותים של חברות‬ ‫אחסון‪.‬הינם שרתי ה‪ default -‬במחשבי הקצה של המשתמשים ששם כתוב לאן ללכת על מנת‬ ‫לקבל את הכתובת‪.‬כלומר הם נותנים לבסוף את התשובה‪.‬‬ ‫‪ :LOCAL DNS.41‬אינו חלק מההיררכיה של ה‪ ,DNS‬עם זאת הוא ממלא תפקיד חשוב‬ ‫בארכיטקטורה של ה ‪.DNS‬כל ‪( ISP‬לדוגמא אוני'‪ ,‬חברה גדולה‪ ,‬נטויז'ן‪ ,‬וכו') מתחזקת שרת מקומי‪.‬‬ ‫כאשר משתמש שולח שאילתת ‪ ,DNS‬ה‪ ISP‬מפנה אותו ראשית לשרת המקומי ומשם השרת‬ ‫המקומי מפנה את השאילתא לתוך היררכיית ה‪.DNS‬שרת מקומי לרוב יהיה באותו ‪ LAN‬של‬ ‫המשתמש או במרחק של ראוטר או שניים ממנו‪.‬מתנהג כמו פרוקסי‪ :A (address).42.‬השם הוא‬ ‫שם המחשב והערך הוא כתובת ה‪.IP -‬זהו מיפוי רגיל בין שם לכתובת‪:NS (NameServer).43.‬‬ ‫השם הוא ה‪ domain -‬והערך הוא ה‪ IP -‬של שרת הסמכות‪.‬זהו מיפוי בין מרחב כתובות לשרת ‪DNS‬‬ ‫האחראי על מרחב זה‪ :CNAME (canonical).44.‬השם הוא שם של מחשב והערך הוא שם של‬ ‫מחשב שהוא קנוני עבורו‪.‬זהו מיפוי בין שני מחשבים לאותו שם ‪ domain‬של אתר מסוים‪.‬המיפוי‬ ‫הזה דרוש לשם ‪.web hosting‬למשל‪ ,‬לחברה מסוימת יש מספר אתרים במקומות שונים ומתוך‬ ‫שיקולים גאוגרפיים כדאי להפנות למחשב באזור‪ :MX.45.‬הערך הוא שם שרת הדואר האלקטרוני‬ ‫הממופה לאתר החברה‪.‬זהו מיפוי לשרת דואר אלקטרוני‪ :Hit Rate.46.‬הסיכוי בו נמצא את מה‬ ‫שמחפשים בשרת ה‪.47.proxy‬שאילתה איטרטיבית‪ :‬כל פעם מפנים את השרת הלוקאלי בכיוון‬ ‫של השרת שהוא צריך‪.‬המשתמש פונה לשרת המקומי‪ ,‬השרת המקומי פונה ל‪ ,ROOT‬ה‪ROOT‬‬ ‫מפנה אותו לשרת ‪ DNS‬מתאים (למשל ‪ ,)COM :‬ואז אותו השרת מפנה את השרת הלוקאלי לשרת‬ ‫‪ DNS‬אחר (למשל‪ )yahoo.com :‬וכך הלאה עד שמגיעים לשרת הנכון‪.48.‬שאילתה רקורסיבית‪:‬‬ ‫אני פונה לשרת והוא ממשיך להפנות‪.‬משתמש שולח בקשה לשרת הלוקאלי‪ ,‬השרת הלוקאלי‬ ‫שולח בקשה ל‪ ,ROOT‬ה‪ ROOT‬שולח בקשה לשרת המתאים‪ ,‬ששלוח את הבקשה לשרת המתאים‬ ‫עד שמגיעים לשרת שצריך ואז השרת שצריך מחזיר את התשובה באותו המסלול‪(.‬עשוי להיות‬ ‫בעייתי‪ ,‬השאילתה תאבד בדרך)‪.‬‬  ‫שכבת האפליקציה‪:‬‬ ‫ממונה על אספקת שירותי הרשת לתוכנות בהן משתמש הקצה שכבת היישום קובעת את סוג‬ ‫התקשורת בין מחשבים‪.‬פרוטוקולים בשכבת האפליקציה‪HTTP, SMTP, FTP, IRC, DNS, :‬‬ ‫‪.POP3, IMAP‬אפליקציות רשת‪3.multi-user network games , p2p file sharing ,web ,email :‬‬ ‫מבני תוכנות מרכזיים‪Hybrid Client/Server and )3 ,2 Peer to Peer )2 , 1 Client-Server )1 :‬‬ ‫‪.3P2P‬תקשורת בין תהליכים (‪ )4‬מערב ‪ 2‬דברים‪ :‬תהליך לקוח ‪ 5‬ותהליך שרת ‪.6‬יכולים להיות על‬ ‫אותו מחשב(דוגמא‪ -P2P :‬לקוח ושרת על אותו מחשב‪,‬לקוח כשמבקש משהו כמו הורדה ושרת‬ ‫כשצריך להגיב למישהו כמו העלאה)‪.‬ממשק בין תהליכים‪ API ,7 Socket :‬בין תוכנית לבין הרשת‬ ‫‪.8‬עושים שימוש בפורטים ‪.10‬תוכניות שולטות בתעבורה?‪ :‬שליטה מבוקרת – בחירת פרוטוקול‬ ‫תעבורה ובחירת כמה פרמטרים כמו גודל הבאפר‪ ,‬גודל הסיגמנט‪ ,‬ו‪.timeouts‬איך פונים‬ ‫לתהליך?‪ :‬לצורך הגדרת נמען‪/‬שולח‪ ,‬יש להגדיר במדויק את הכתובת של תחנת קצה‪.‬כתובת‬ ‫מלאה של התחנה מכילה ‪ 9 IP‬ומספר ה‪ port-‬שאליו פונה אפליקציה מסוימת‪.‬לחלק של‬ ‫האפליקציות קיימים ‪ port‬קבועים וידועים כמו כן יש גם אפליקציות שמשתמשות ב‪ port-‬דינאמיים ‪4‬‬ ‫מימדים של שירותי תחבורה של המידע‪ )1 :‬אמינות ‪ )2 , 11‬תפוקה ‪ )3 , 12‬תזמון ‪ )4 ,13‬אבטחה‬ ‫‪ 2.14‬סוגי תחבורה של המידע‪.16 UDP )2 ,15 TCP )1 :‬אבטחת ‪.17 TLP\SSL :TCP‬פרוטוקולים‬ ‫של שכבת האפליקציה מגדירים‪ :‬סוג ההודעה(‪,)request/response‬סינטקס הודעה‪ ,‬שדות‬ ‫אינפורמציה על ההודעה‪ ,‬איך לעבד הודעות(‪ :Public-domain Protocols.)FSM‬מוגדרים ב‪, RFCs‬‬ ‫דוגמא ‪ :Proprietary Protocols.18 HTTP‬למשל סקייפ ו‪ p2p‬אחרים‪ :Apps vs Protocols.‬הם לא‬ ‫אותו דבר ‪ ,‬אפליקציות מממשות פרוטוקולים(אולי יותר מ‪-Web App.)1‬למשל דפדפן ‪ ,‬שרת ‪web‬‬ ‫כמו ‪ Apache‬משתמש בפרוטוקול ‪ -Email App.HTTP/HTTPS PROTOCOL‬לקוח מייל ‪ ,‬שרת מייל‪,‬‬ ‫משתמש בפרוטוקולי העברה‪ HTTP.SMTP,POP3,IMAP:‬הוא חסר מצב‪.19 :‬בניגוד ל‪ FTP‬שהוא‬ ‫תלוי מצב‪.20 :‬לכל אתר יש ‪.21 :URL‬איך ‪ HTTP‬עובד‪ )1 :‬הלקוח מבקש דף ‪ )2 ,‬הדפדפן שולח‬ ‫‪ HTTP-Request‬לשרת ‪ )3 ,‬השרת מקבל את הבקשה ‪ )4 ,‬השרת שולח ‪)5 , HTTP-Response‬‬ ‫הדפדפן מקבל את התגובה ‪ )6 ,‬הדפדפן מציג את הדף‪ HTTP.‬משתמש ב‪ :TCP‬חיבור ‪ TCP‬בין‬ ‫הלקוח לשרת ‪ ,‬מדברים דרך ‪ , TCP Socket‬יתרונות של השכבות‪ -‬המאמץ של ‪ TCP‬שקוף‪HTTP.‬‬ ‫מקבל אמינות‪ :Persistent vs. non-Persistent connections.‬לא עקבי ‪ -22‬חיבור חדש עבור כל‬ ‫אובייקט ‪ ,‬לא חייב להיות סידרתי ‪ ,‬אפשר לשלוח כמה במקביל‪.‬עקבי ‪ – )25 ,24( 23‬יתרון‪ :‬אין חיבור‬ ‫חדש עבור כל אובייקט‪ ,‬אפשרות לשלוח במקביל‪.‬ברירת המחדל של ‪Presistent with :HTTP‬‬ ‫‪.25pipelining‬סוגי ‪.Delete , Put , Get , Head , Post :HTTP REQUESTS‬קיים לחבילה זמן הלוך‬ ‫חזור ‪.26 :RTT‬הדרך של ‪ HTTP‬להיות תלוי מצב‪.28 :Web Caching.27 Cookies :‬יש את הסיכוי‬ ‫שנמצא מה שאנו מחפשים ב‪. 46 :PROXY‬משולב עם ‪File Transfer.29 :Conditional GET‬‬ ‫‪ 30 :Protocol‬יש לו ‪ 2‬ערוצי תקשורת‪(Control :‬פורט ‪ )21‬לפקודות וכו'‪(Data ,‬פורט ‪ )20‬העברת‬ ‫קובץ‪ FTP.‬הוא ‪ – Stateful‬זוכר אם אומת ומצב שליחה נוכחי‪.‬עקרונות ‪ 3.31 :EMAIL‬מרכיבים‬ ‫עיקריים ל‪ 3.34 SMTP )3 ,33 Mail Server )2 ,32 User Agent )1 :EMAIL‬פרוטוקולי ‪)1 :EMAIL‬‬ ‫‪ – User Agent :Web Based Email.36 IMAP ,35 POP3 ,34 SMTP‬דפדפן ‪,‬התקשורת ‪ HTTP‬יחד‬ ‫עם ‪ SMTP‬בין השרתים‪.‬‬  ‫לפי הסדר‪ ,UDP – DNS :‬עבור מציאת כתובת שרת אינטרנט‪ ,TCP – HTTP.‬לגישה לשרת הדואר‬ ‫וכתיבת הדואר‪ ,UDP – DNS.‬עבור מציאת כתובת שרת הדואר אליו נשלח הדואר‪,TCP – SMTP.‬‬ ‫עבור שליחת הדואר לשרת הנכון‪.‬תרגום ‪ IP‬לשם ‪. 37 :DNS‬‬ ‫איך ה ‪ DNS‬עובד?‪ )1 :‬מחשב לקוח מריץ תוכנת ‪ )2 ,DNS‬הדפדפן מחלץ את הכתובת מתוך ה ‪URL‬‬ ‫ומעביר ללקוח ‪ )3 ,DNS‬הלקוח ‪ DNS‬מתשאל את השרת ‪ DNS‬לגבי שם ה‪ )4 ,host‬מחזיר תשובה ‪IP‬‬ ‫של ה‪ host‬ללקוח ‪ )5 ,DNS‬מעביר את ה‪ IP‬לדפדפן ‪,‬‬ ‫‪ )6‬הדפדפן יוצר תקשורת ‪ TCP‬על סמך ה‪.IP‬שירותים נוספים של ‪-host aliasing )1 :DNS‬‬ ‫כמה ‪ URLS‬לאותו ‪ -Mail Server aliasing )2 ,HOST‬אותו דבר רק ל‪– load distribution )3 ,email‬‬ ‫מגדיר כמה ‪ IP‬לאותו ‪ ,hostname‬בוחר כל פעם ‪ IP‬מתוך הרשימה על מנת להחזיר תשובה – עוזר‬ ‫להוריד עומס על שרת מסוים‪ :Single Server Model.‬שרת אחד מרכזי‪ ,‬גורם לבעיות‪ )1 :‬שרת יחיד‬ ‫אם הוא נופל זה בעיה (לא נוכל לגשת ל‪ IP‬של אתרים) ‪ )2 ,‬יהיה בו מדי תנועה ‪ )3 ,‬יקח זמן לשאול‬ ‫אותו שאלות (למשל לגבי כתובת מסוימת)‪ )4 ,‬קשה לתחזק‪-‬קשה לגדול‪.‬שרת יחיד לא מתאים‬ ‫ולכן משתמשים בשרתי ‪ DNS‬בצורה היררכית‪ 3.‬סוגי שרתים בהיררכיה‪Top-)2 ,38 Root )1 :‬‬ ‫‪.40 Authoritative )3 ,39level domain‬בנוסף קיים עוד סוג שלא חלק מההיררכיה‪. 41 :‬שרת‬ ‫ה‪ DNS -‬שומר את הרשומות שלו (המיפויים) ב‪.cache -‬לכל רשומה יש שדה ‪)ttl(time to leave‬‬ ‫שאומר עד מתי יש לשמור את הרשומה‪.‬שדות נוספים הנשמרים ברשומות הם שם הרשומה‪,‬‬ ‫ערך‪ ,‬סוג הרשומה‪.‬‬ ‫סוגי רשומות‪ 2.45 MX )4 ,44 CNAME )3 ,43 NS )2 ,42 A )1 :‬מודלים לשאילתת ‪)1 :DNS‬‬ ‫איטרטיבי ‪ )2 , 47‬רקורסיבי ‪ : Socket programming.48‬סוקט הוא נקודת קצה )‪ (endpoint‬עבור‬ ‫זרם נתונים בתקשורת בין תהליכים על גבי רשת מחשבים‪.‬אם ה‪ IP‬הוא הכתובת‪ ,‬הפורט מספר‬ ‫הבית והתוכנית היא הבית עצמו‪ ,‬הסוקט הוא הדלת‪.‬ישנם הבדלים קטנים בסוקטים של ‪ TCP‬ו ‪,UDP‬‬ ‫אך בשני המקרים השרת חייב לפתוח סוקט לפני הלקוח‪ ,‬אחרת התקשורת אינה אפשרית‪:UDP.‬‬ ‫השרת פותח ‪( serverSocket‬סוקט "מאזין") ומצמיד אותו לפורט מסוים‪.‬החל מרגע זה ‪ -‬השרת‬ ‫מוכן לקבל פאקטות מהלקוח‪.‬כל עוד תוכנית השרת רצה‪ ,‬ה‪ serverSocket‬לא ייסגר בכלל‪ ,‬ויתרה‬ ‫מכך יישאר בהאזנה אינסופית לבקשות מהלקוח‪.‬כל חבילה שמגיעה מהלקוח מכילה את הכתובת‬ ‫שלו (של הלקוח) ואת ההודעה עצמה (ועוד כמה דברים ששייכים לשכבת התעבורה)‪.‬השרת מעבד‬ ‫את המידע ומחזיר תשובה ללקוח דרך ה‪.serverSocket‬הלקוח פותח ‪ clientSocket‬ומצמיד אליו‬ ‫את הפורט וכתובת ה‪ IP‬של השרת‪ ,‬שולח באמצעותו את ההודעה בצירוף הכתובת והפורט‪ ,‬ומקבל‬ ‫דרכו את תשובת השרת‪.‬לאחר מכן‪ ,‬הלקוח סוגר את ה‪ :TCP.clientSocket‬כמו ב‪ ,UDP‬גם ב‪TCP‬‬ ‫תוכנית השרת צריכה לרוץ לפני תוכנית הלקוח והשרת חייב לפתוח סוקט לפני הלקוח‪.‬השרת‬ ‫פותח ‪ ,serverSocket‬מצמיד אליו את מספר הפורט שלו ונכנס למצב האזנה‪.‬כאשר השרת מזהה‬ ‫בקשה מלקוח‪ ,‬הוא פותח ‪ connectionSocket‬ייחודי ל‪ session‬הנוכחי‪ ,‬ומשאיר את ה"דלת" פתוחה‬ ‫עד לסיום הקשר (שליחת כל המידע ללקוח)‪.‬לאחר מכאן השרת מקבל את ההודעה עצמה‬ ‫באמצעות ה‪ ,connectionSocket‬מעבד אותה‪ ,‬ושולח דרכו את התשובה ללקוח‪.‬לאחר סיום החזרת‬ ‫התשובה ללקוח‪ ,‬השרת סוגר את ה‪ connectionSocket‬של ה‪ session‬הנוכחי‪ ,‬אך לא את ה‬ ‫‪serverSocket‬ה"מאזין"‪.‬הלקוח פותח ‪ clientSocket‬ומצמיד אליו את כתובת השרת ומספר הפורט‬ ‫של השרת‪.‬לאחר יצירת קשר ראשונית עם השרת באמצעות ה‪ ,clientSocket‬הלקוח שולח לשרת‬  ‫את ההודעה ללא כתובת ומספר פורט (מפני שמדובר בחיבור "קבוע")‪ ,‬מקבל את התשובה דרכו‬ ‫ולאחר מכן סוגר את ‪.clientSocket‬‬ ‫שכבת האפליקציה (חלק שלישי שלה)‬ ‫‪:Socket programming‬‬ ‫סוקט הוא נקודת קצה )‪ (endpoint‬עבור זרם נתונים בתקשורת בין תהליכים על גבי רשת מחשבים‪.‬אם‬ ‫ה‪ IP‬הוא הכתובת‪ ,‬הפורט מספר הבית והתוכנית היא הבית עצמו‪ ,‬הסוקט הוא הדלת‪.‬ישנם הבדלים‬ ‫קטנים בסוקטים של ‪ TCP‬ו ‪ ,UDP‬אך בשני המקרים השרת חייב לפתוח סוקט לפני הלקוח‪ ,‬אחרת‬ ‫התקשורת אינה אפשרית‪.‬‬ ‫‪ :UDP‬השרת פותח ‪( serverSocket‬סוקט "מאזין") ומצמיד אותו לפורט מסוים‪.‬החל מרגע זה ‪ -‬השרת‬ ‫מוכן לקבל פאקטות מהלקוח‪.‬כל עוד תוכנית השרת רצה‪ ,‬ה‪ serverSocket‬לא ייסגר בכלל‪ ,‬ויתרה מכך‬ ‫יישאר בהאזנה אינסופית לבקשות מהלקוח‪.‬כל חבילה שמגיעה מהלקוח מכילה את הכתובת שלו (של‬ ‫הלקוח) ואת ההודעה עצמה (ועוד כמה דברים ששייכים לשכבת התעבורה)‪.‬השרת מעבד את המידע‬ ‫ומחזיר תשובה ללקוח דרך ה‪.serverSocket‬‬ ‫הלקוח פותח ‪ clientSocket‬ומצמיד אליו את הפורט וכתובת ה‪ IP‬של השרת‪ ,‬שולח באמצעותו את‬ ‫ההודעה בצירוף הכתובת והפורט‪ ,‬ומקבל דרכו את תשובת השרת‪.‬לאחר מכן‪ ,‬הלקוח סוגר את ה‬ ‫‪.clientSocket‬‬ ‫קוד לקוח וקוד שרת (‪:)UDP‬‬  ‫‪ :TCP‬כמו ב‪ ,UDP‬גם ב‪ TCP‬תוכנית השרת צריכה לרוץ לפני תוכנית הלקוח והשרת חייב לפתוח סוקט‬ ‫לפני הלקוח‪.‬‬ ‫השרת פותח ‪ ,serverSocket‬מצמיד אליו את מספר הפורט שלו ונכנס למצב האזנה‪.‬כאשר השרת‬ ‫מזהה בקשה מלקוח‪ ,‬הוא פותח ‪ connectionSocket‬ייחודי ל‪ session‬הנוכחי‪ ,‬ומשאיר את ה"דלת"‬ ‫פתוחה עד לסיום הקשר (שליחת כל המידע ללקוח)‪.‬לאחר מכאן השרת מקבל את ההודעה עצמה‬ ‫באמצעות ה‪ ,connectionSocket‬מעבד אותה‪ ,‬ושולח דרכו את התשובה ללקוח‪.‬לאחר סיום החזרת‬ ‫התשובה ללקוח‪ ,‬השרת סוגר את ה‪ connectionSocket‬של ה‪ session‬הנוכחי‪ ,‬אך לא את ה‬ ‫‪serverSocket‬ה"מאזין"‪.‬‬ ‫הלקוח פותח ‪ clientSocket‬ומצמיד אליו את כתובת השרת ומספר הפורט של השרת‪.‬לאחר יצירת‬ ‫קשר ראשונית עם השרת באמצעות ה‪ ,clientSocket‬הלקוח שולח לשרת את ההודעה ללא כתובת‬ ‫ומספר פורט (מפני שמדובר בחיבור "קבוע")‪ ,‬מקבל את התשובה דרכו ולאחר מכן סוגר את‬ ‫‪.clientSocket‬‬ ‫שכבת התעבורה‬ ‫שכבת התעבורה נמצאת בין שכבת האפליקציה לשכבת הרשת‪.‬התפקיד החשוב ביותר שלה הוא‬ ‫לספק שירותי תקשורת ישירות לתהליכי שכבת האפליקציה הרצים בין ‪– host‬ים שונים‪.‬בשכבה זו יש‬ ‫‪ 2‬פרוטוקולים עיקריים‪.UDP,TCP:‬שכבת התעבורה אחראית על העברה אמינה של נתונים בין שני‬ ‫תהליכים ויותר‪.‬במידה ויש איבוד מידע או שיבוש במידע שכבת התעבורה צריכה לדעת להתמודד עם‬ ‫זה‪.‬‬ ‫‪ 3.1‬מבוא לשירותי שכבת התעבורה‪:‬‬ ‫שכבת התעבורה מספקת ‪ logical communication‬בין תהליכים בשכבת האפליקציה הרצים בין ‪host‬‬ ‫–ים שונים‪ logical communication.‬משמעו שמנקודת המבט של האפליקציה‪ ,‬זה כאילו שה‪ host-‬ים‬ ‫שמריצים את התהליך מקושרים באופן ישיר אחד לשני‪.‬במציאות כל אחד ממהוסטים יכול להיות‬ ‫בקצה אחר של העולם ומחוברים דרך כמות גדולה של נתבים וסוגי לינקים‪.‬‬ ‫תהליכי שכבת האפליקציה משתמשים ב‪ logical communication-‬המסופקת ע"י שכבת התעבורה על‬ ‫מנת לשלוח הודעות אחד לשני מבלי לדאוג להרכב הרשת הפיזית אשר שולחת את ההודעות בפועל‪.‬‬ ‫פרוטוקולי שכבת התעבורה ממומשים ביחידות הקצה ולא בנתבים‪.‬‬ ‫תהליך כללי של תקשורת בין ‪ 2‬יחידות קצה בשכבת התעבורה‪ :‬בצד השולח (‪ ,)sender‬שכבת‬ ‫התעבורה ממירה את ההודעות שקבלה משכבת האפליקציה ליחידות הנקראות ‪ packets‬הידועות גם‬ ‫כ‪.segments-‬שכבת התעבורה שוברת את ההודעות ליחידות קטנות יותר של מידע‪ segment-‬ואז היא‬ ‫מעבירה את הסיגמנטים לשכבת הרשת‪.‬שכבת הרשת עוטפת את הסיגמנטים ושולחת אותן ביחידות‬ ‫מידע הנקראות ‪ datagram‬ליעד‪.‬בצד המקבל (‪ ,)rsv‬שכבת הרשת מוציאה הסיגמנטים של שכבת‬ ‫התעבורה מ‪ datagrams-‬ומעבירה אותן לשכבת בתעבורה‪.‬שכבת בתעבורה מעבדת את הסגמנטים‬ ‫ומעבירה אותם לשכבת האפליקציה‪.‬‬ ‫‪ 3.1.1‬הקשר בין שכבת התעבורה לבין שכבת הרשת‪:‬‬ ‫בעוד שכבת התעבורה מספקת תקשורת לוגית בין ‪ 2‬תהליכים הרצים ב‪ 2‬יחידות קצה שונות‪,‬שכבת‬ ‫הרשת תפקידה לספק קשר לוגי בין ‪ 2‬יחידות הקצה‪.‬שכבת התעבורה לא מתערבת בכיצד יש לשלוח‬ ‫את ההודעות ברחבי הרשת‪ ,‬זהו תפקידה של שכבת הרשת‪.‬‬ ‫לעיתים השירותים ששכבת התעבורה מספקת מוגבלים ע"י המודל הפרוטוקול של שכבת הרשת‪.‬אם‬ ‫פרוטוקול שכבת הרשת לא יכולה לספק ביטחון בעיכובים וברוחב פס עבור סיגמנטי שכבת התעבורה‬ ‫הנשלחים בין ההוסטים‪ ,‬אז פרוטוקול שכבת התעבורה לא יכול לספק ביטחון עבור עיכובים או רוחב‬ ‫פס עבור הודעות האפליקציה הנשלחות בין התהליכים‪.‬‬ ‫יתרה מכך‪ ,‬פרוטוקול שכבת התעבורה מציא חלק מסוים של שירותים גם אם פרוטוקול שכבת הרשת‬ ‫לא יכול להציע שירותים מתאימים בשכבת הרשת‪.‬שכבת התעבורה יכולה להבטיח שירותי העברת‬ ‫מידע בצורה אמינה לאפליקציות גם אם פרוטוקול הרשת לא אמין וגם אם חלק מן המידע הולך‬ ‫לאיבוד‪,‬נפגם או משתכפל‪.‬‬ ‫‪ 3.1.2‬ראיה כללית על שכבת התעבורה ברשת‪:‬‬ ‫שכבת התעבורה מכילה בתוכה ‪ 2‬פרוטוקולים עיקריים‪UDP -‬ו‪.TCP-‬‬ ‫‪ : user datagram protocol -UDP‬מספק שירות לא אמין ו‪ connection less-‬לאפליקציות‪.‬‬ ‫‪ : transmission conteol protocol-TCP‬מספק שירות אמין‪ connection-oriented,‬לאפליקציות‪.‬‬ ‫ב‪UDP -‬אנו מתייחסים ליחידות המידע כ‪ datagram-‬שבתוכם יש ‪ segment‬וב‪TCP -‬אנו מתייחסים‬ ‫ליחידות במידע כ‪.segment‬‬ ‫שכבת הרשת משתמש בניווט אותם יחידות מידע בין ההוסטים ע"י שימוש בכתובות ‪.ip‬שימוש‬ ‫בכתובת ‪IP‬בלבד נחשב שירות לא אמין‪.‬‬ ‫האחריות העיקרית של שני הפרוטוקולים היא להרחיב את השימוש בשירות ה‪ IP -‬על מנת להעביר‬ ‫מידע בין שני יחידות קצה להעברת מידע בין שני תהליכים הרצים ביחידות הקצה‪.‬הרחבת השירות‬ ‫הזה נקרא‪.transport layer multiplexing and demultiplexing-‬‬ ‫שני הפרוטוקולים גם מספקים "בדיקת אמינות" ע"י הוספת שדות של זיהוי שגיאות ב‪ header‬של‬ ‫הסיגמנט‪.‬שני השירותים הללו ‪ process-to-process :‬ו‪-‬בדיקת אמינות(‪ )integrity check‬הם‬ ‫השירותים היחידים שמספק הפרוטוקול ‪UDP.UDP‬לא מבטיח כי הסגמנטים יגיעו ליעדן‪.‬‬  ‫מצד שני‪,‬פרוטוקול ‪ TCP‬מספק שירות אמין של העברת מידע ע"י שימוש ב‪sequence , flow control-‬‬ ‫‪ acknowledgments,number‬וטיימרים ומבטיח כי החבילות יגיעו בסדר הנכון‪TCP.‬הופך את השירות‬ ‫הלא אמין של ה‪ IP -‬בין ‪ 2‬יח' קצה לאמין בין ‪ 2‬תהליכים‪TCP.‬מספק גם ‪.congestion control‬שירות‬ ‫זה מסופק לא רק לשכבת האפליקציה אלה לכל הרשת כולה‪.‬שירות זה של ה‪ TCP-‬מונע מכל חיבור‬ ‫‪TCP‬להציף את החיבורים והנתבים בין שני יח' הקצה במקרה של עומס בלתי רגיל של מידע‪TCP.‬שואף‬ ‫לתת לכל חיבור החוצה לינק עמוס‪ ,‬רוחב פס זהה‪.‬זה נעשה ע"י הסדרת הקצב שבו הצדדים השולחים‬ ‫יכולים לשלוח מידע ברשת‪.‬ב‪ UDP -‬אין את ההסדרה הזו וכל אחד יכול לשלוח בכל קצב שהוא רוצה‬ ‫וכמה זמן שהוא רוצה‪.‬פרוטוקול ‪ TCP‬הוא פרוטוקול מאוד מסובך‪.‬‬ ‫‪: Multiplexing and Demultiplexing 3.2‬‬ ‫פעולת הריבוב היא פעולה שמטרתה להרחיב את שירות היחידת קצה‪-‬ליחידת קצה לשירות תהליך‪-‬‬ ‫לתהליך‪.‬תהליך הריבוב\אי‪-‬ריבוב מתקיים לא רק בשכבת בתעבורה אלא בכל הרשת‪.‬במחשב‬ ‫היעד‪,‬שכבת התעבורה מקבלת סיגמנטים משכבת הרשת הנמצאת מתחתייה‪.‬לשכבת התעבורה יש‬ ‫את האחריות להעביר את המידע לאפליקציה הנכונה שרצה ביחידת הקצה‪.‬לתהליך יכול להיות יותר‬ ‫מכמה ‪-socket‬ים שדרכם הוא מקבל ושולח את המידע‪.‬שכבת התעבורה בצד המקבל לא מעבירה את‬ ‫המידע ישירות לתהליך אלא היא מעבירה אותו דרך סוקט מתווך‪.‬זאת בגלל שבכל זמן נתון לכל תהליך‬ ‫יכולים להיות כמה סוקטים לקבלת מידע ולכל אחד מהם יש מזהה ייחודי‪.‬המזהה תלוי באיזה פרוטוקול‬ ‫אנחנו‪ TCP -‬או ‪.UDP‬‬ ‫אז כיצד יחידת קצה מנווטת את ההסיגמנטים לייעדם? כל סיגמנט מכיל סט שדות עבור מטרה‬ ‫זו‪.‬ביחידה המקבלת‪ ,‬שכבת התעבורה בוחנת את השדות הללו על מנת לזהות את הסוקטים שצריכים‬ ‫לקבל את המידע ואז להכווין אותן אל הסוקט הייעודי‪.‬עבודה זו של שליחת המידע משכבת התעבורה‬ ‫אל הסוקטים הייעודיים נקרא ‪. demultiplexing‬עבודה של קיבוץ כל ערוצי המידע בצד השולח מכמה‬ ‫סוקטים נקרא ‪.multiplexing‬‬ ‫כיצד הפעולות הללו מבוצעות בפועל אצל יחידות הקצה?אנו יודעים כי שכבת התעבורה מבצעת ריבוב‬ ‫של צינורות המידע ‪,‬שלכל סוקט יש מזהה יחודי‪ ID-‬ושלכל סיגמנט יש שדות מיוחדים אשר מאפשרים‬ ‫לזהות לאיזה סוקט הסיגמנט מיועד‪.‬השדות המיוחדים בסגמנט נקראים ‪source port number field‬‬ ‫ו‪.destination port number field-‬כל פורט מכיל מספר בגודל ‪ 16‬ביטים בטווח של ‪( 0-65535‬סה"כ‬ ‫‪ 32‬ביטים)‪.‬מספר הפורטים הנעים בין ‪ 0‬ל‪ 1023-‬הם פורטים מוכרים ומוגבלים‪-‬משמע שהם שמורים רק‬ ‫לשימוש ידוע של פרוטוקוליי שכבת היישום כגון ‪( HTTP‬פורט ‪ )80‬ו‪( FTP-‬פורט ‪.)21‬יישום התהליך‬ ‫מתקיים בצורה הבאה‪ -‬כל סוקט ביחדת הקצה מגדיר את מספר הפורט שלו וכשאר סיגמנטים מגיעים‬ ‫לשכבת התעבודה היא בוחנת את מספר פורט היעד שכתוב בה ושולחת את הסיגמנט לפורט‬ ‫הנחוץ‪.‬אח"כ המידע בסיגמנט מועבר לתהליך היעד בשכבת היישום‪.‬‬ ‫‪)UDP( :Connectionless Multiplexing and Demoltiplexing‬‬ ‫כאשר סוקט של ‪ UDP‬נוצר אוטומטית שכבת התעבורה מקצה לסוקט פורט‪.‬בנוסף אנו יכולים לבקש‬ ‫להקצות לסוקט פורט ספציפי‪.‬‬  ‫תהליך הריבוב ב‪:UDP-‬‬ ‫‪ )1‬אפליקציה בצד השולח רוצה לשלוח מידע לאפליקציה בצד המקבל‪.‬‬ ‫‪ )2‬שכבת בתעבורה יוצרת סיגמנט המכיל את ה‪, data-‬פורט המקור‪,‬פורט היעד וכתובת ‪ IP‬של היעד‪.‬‬ ‫‪)3‬שכבת התעבורה מעבירה את הסיגמנט לשכבת הרשת על מנת לשלוח אותה ברחבי הרשת‪.‬‬ ‫תהליך האי‪-‬ריבוב ב‪: UDP-‬‬ ‫‪ )4‬אם החבילה מגיעה ליעד‪,‬שכבת התעבורה בוחנת את הפורט היעד ומעבירה את הסיגמנט לפורט‬ ‫הייעודי‪.‬‬ ‫*לכל תהליך שרץ ביחידת הקצה יש את הסוקט והפורט הייחודים משלו‪.‬‬ ‫*אנו שמים את פורט המקור על מנת שיהווה מעין "כתובת חזרה" ( כמובן בשילוב עם כתובת ה‪IP -‬של‬ ‫המקור)‪.‬‬ ‫* ‪ 2‬סיגמנטים המגיעים ליעד עם כתובת ‪( IP‬מקור) שונה ופורטים שונים (מקור) אך כתובת ‪( IP‬יעד)‬ ‫ופורט היעד זהים? ‪ 2‬הסיגמנטים ייועדו לאותו תהליך‪.‬‬ ‫‪)TCP( : Connection-Oriented Multiplexing and Demultiplexing‬‬ ‫השוני העיקרי בין בוקט של ‪ UDP‬לבין סוקט של ‪ TCP‬הוא שסוקט של ‪ TCP‬מאובחן ע"י ‪ 4‬שדות‪:‬‬ ‫‪ -‬פורט מקור‬ ‫‪-‬כתובת ‪ IP‬מקור‬ ‫‪-‬פורט יעד‬ ‫‪-‬כתובת ‪ IP‬יעד‬ ‫כל השדות האלו משמשים אותנו בתהליך האי‪-‬ריבוב ב‪ TCP-‬שכאשר מגיעה חבילה ליעדה שכבת‬ ‫התעבורה משתמשת בכל ‪ 4‬השדות על מנת לנווט את החבילה לתהליך הרלוונטי לה‪.‬‬ ‫בשונה מ‪ UDP-‬אם יש ‪ 2‬סיגמנטים המגיעים ליעדן עם כתובות ‪( IP‬מקור) שונות או פורטיי (מקור) שונים‬ ‫אז הן ייועדו לתהליכים שונים‪.‬‬ ‫בצד השרת‪ ,‬כאשר הלקוח מבקש להתחבר אליו דרך הפורט הראשי‪ ,‬הוא מקבל סיגמנט "בקשת‬ ‫שיחה" ומחלץ את ‪ 4‬הערכים בהודעת הסיגמנט‪.‬בהתאם לערכים אלו הוא יוצר סוקט חדש אשר‬ ‫מתאים לפורט המקור כתובת המקור‪,‬פורט היעד וכתובת היעד ‪.‬כל הסיגמנטים שישלחו עם ‪ 4‬הערכים‬ ‫הספציפים האלו יגיעו לסוקט הספציפי הזה‪.‬‬ ‫השרת צריך לדעת לתמוך בכמות גדולה של משתמשים באותה הצורה‪.‬‬ ‫איך זה עובד בשרתי אינטרנט? הרי לכולם יש את אותו הפורט יעד (‪.)80‬השרת מקבל את כולם דרך‬ ‫אותו הסוקט ולאחר מכן יוצר לכל לקוח סוקט משלו‪.‬אם השרת משתמש ב‪ persistent HTTP -‬אז‬ ‫השרת יתקשר עם הלקוח דרך אותו הסוקט עד לסיום השיחה‪.‬אם הוא משתמש ב‪non-persistent -‬‬ ‫‪ HTTP‬אז קישור ‪ TCP‬נוצר עבור כל בקשה\תגובה‪.‬התנהגות זו מקשה על השרת לנהל מספר רב של‬ ‫לקוחות עם מספר רב של תגובות\בקשות‪.‬‬ ‫‪:Connectionless transport UDP 3.3‬‬ ‫פרוטוקול זה לא מוסיף יותר מידי לשכבת לפרוטוקול העברת מידע (רק ריבוב\אי ריבוב ובדיקת‬ ‫שגיאות פשוטה)‪ UDP.‬לוקח את המידע שקיבל משכבת האפליקציה מוסיף לה פורט מקור ופורט יעד‬  ‫(לשירותי הריבוב\אי ריבוב) ‪,‬מוסיף עוד שניים שלושה שדות ומעביר את הסיגמנט הלאה לשכבת‬ ‫הרשת‪.‬שכבת הרשת עוטפת את הסיגמנט לחבילת מידע בשם ‪ datagram‬ומשתמשת בשיטת "‪best-‬‬ ‫‪ "effort‬על מנת לשלוח את החבילה ליעדה‪.‬פרוטוקול זה "כמעט" מדבר ישירות עם ה‪.IP-‬‬ ‫ב‪ UDP-‬אין ‪ handshaking‬בין השולח והמקבל לפני שהשולח שולח את החבילה ולכן הוא נקרא‬ ‫‪.connectionless‬‬ ‫* ב‪ UDP-‬כל סיגמנט מטופל ומנוהל בנפרד‪.‬‬ ‫* דוגמא לפרוטוקול המשתמש ב‪.DNS =UDP-‬‬ ‫יתרונות ה‪:UDP-‬‬ ‫‪ )1‬מאפשר שליטה טובה יותר ברמת האפליקציה על המידע שנשלח ומתי‪.‬אפליקציות לעיתים צריכות‬ ‫זמן המתנה לשליחת הודעה‪ -‬קצר ביותר וכן לעומת ‪ TCP‬אין פה ‪(congestion control‬אין בקרת‬ ‫דחיסה ועומס – גורם להעמסת הרשת ואפשרות לניצולת מקסימלית) שמעקב את תהליך שליחת‬ ‫ההודעה‪(.‬יכול להוות גם חיסרון)‪.‬‬ ‫‪ )2‬אין צורך ביצירת ‪.connection‬שליחה מיידית של המידע ללא המתנה‪.‬‬ ‫‪ )3‬אין צורך בשמירת ‪.connection state‬כך הפרוטוקול מאפשר תמיכה ביותר משתמשים‪.‬‬ ‫‪-header )4‬ים קטנים ‪.‬משמע הודעות קצרות יותר ופחות עמוסות‪.‬‬ ‫‪ )5‬שמיש עבור שליחת הודעות ב‪.DNS-‬הודעות קטנות שאין חשיבות לסדר שלהן‪.‬‬ ‫‪ )6‬משמש ליישומי מולטימדיה‪ ,‬בהם אפשרי לאבד חבילות ובהם חשוב קצב מהיר של העברה‪ ,‬יש‬ ‫עדיפות למהירות על פני אמינות‪.‬‬ ‫‪ 3.3.1‬מבנה הסיגמנט של ‪:UDP‬‬ ‫* גודל הסיגמנט של ‪ 32 = UDP‬ביטים (כולל ה‪.)header-‬‬ ‫‪:UDP checksum 3.3.2‬‬ ‫מטרה‪ :‬משמש לאיתור שגיאות במידע‪.‬‬  ‫בצד השולח‪ UDP :‬מתייחס לכל המידע בסגמנט (כולל ה‪ )header-‬כשני מחרוזות ארוכות באורך ‪16‬‬ ‫ביטים כל אחת‪.‬הוא סוכם אותן ואם יש נשא הוא מחבר אותו גם ושם אותה בשדה ‪ checksum‬בתוך‬ ‫הסיגמנט ‪.‬‬ ‫(הוספת הנשא הופכת את כל ה‪ 1‬ל‪.)0-‬‬ ‫בצד המקבל‪ :‬עושה את פעולת החיבור בין המחרוזת שקיבל ב‪ checksum-‬עם המחרוזת של ה‪16‬‬ ‫ביטים‪.‬במידה ויש נשא הוא מחבר אותו גם‪.‬הוא משווה אותו למה שקיבל ורואה אם יש טעויות‪.‬‬ ‫מדוע נשתמש ב‪?checksum-‬‬ ‫‪-‬שכבת הערוץ (שכבה שנייה) עושה שימוש ב‪ checksum -‬גם‪.‬‬ ‫‪-‬ההנחה היא כי לא כל הערוצים והחיבורים ברשת מבצעים בדיקה לגילוי שגיאות‪.‬‬ ‫‪ -‬יתכן והכי השגיאה בסגמנט התרחשה כאשר היא נשמרה בזיכרון של הנתב‪.‬‬ ‫‪ :End-to-end principle‬עקרון לפיו שפונקציונאליות מסויימת אנו נתיר ליחידות הקצה של הרשת‬ ‫לבצע‪.‬נרצה לבצע אותם בשכבות הנמוכות של הרשת כי המימוש שלהן בשכבות העליונות יותר קשה‬ ‫יותר‪.‬‬ ‫‪ UDP‬לא מבצע דבר על מנת להתאושש מכך שחבילות הלכו לאיבוד‪.‬הוא יכול אך לעשות את הדברים‬ ‫הבאים‪:‬‬ ‫‪ -‬לזרוק את הסיגמנט הפגום‬ ‫‪-‬להעביר את הסגמנט הפגום לשכבת היישום ולההיר אותה על כך‬ ‫‪ -‬להתעלם מהבעיה‪.‬‬ ‫‪ 3.4‬עקרונות העברת מידע בצורה אמינה‪:‬‬ ‫נושא זה עקרוני ביותר לשכבת התעבורה ‪,‬שכבת היישום ושכבת הערוץ‪.‬‬  ‫בערוץ תקשורת אמין‪,‬שתי אפליקציות המתקשרות יכולות להיות בטוחות כי שום מידע לא השתבש וכי‬ ‫כל החבילות מגיעות ליעדן‪.‬זהו בדיוק השירות שמציע פרוטוקול ‪ TCP‬ליישומים בשכבת האפליקציה‪.‬אך‬ ‫לעיתים הפרוטוקול משתמש בערוצים שהם לא אמינים על מנת להעביר מידע‪.‬‬ ‫הצד השולח‪:‬‬ ‫)(‪: Rdt_send‬מקבל קריאה מהשכבה מעלה‪.‬היישום רוצה לעביר מידע לשכבת יישום בצד המקבל‪.‬‬ ‫)(‪ :Udt_send‬נקרא ע"י ה‪ rtd-‬להעביר מידע דרך ערות לא אמין‪.‬‬ ‫הצד המקבל‪:‬‬ ‫‪ :Rdt_rcv‬נקרא כאשר מגיעה חבילה לצד המקבל של התקשורת‪.‬‬ ‫)(‪ :Deliver_data‬נקרא כאשר פרוטוקול ה‪ rdt-‬בצד המקבל רוצה להעביר את המידע לאפליקציה בצד‬ ‫המקבל‪.‬‬ ‫‪:Building a Reliable Data Transfer Protocol 3.4.1‬‬ ‫כל השיטות התפתחו בצורה אינקרמנטלית כך שככל שמספרן גדל כך הן מורכבות יותר אך מספקות‬ ‫שירות העברת מידע בצורה אמינה טוב יותר‪.‬‬ ‫* נניח כי העברת המיגע מתבצעת לכיוון אחד אך העברת מידע הנועד לבקרה מתבצע בשני הכיוונים!!‬ ‫* נשתמש באוטומט מצבים המתאר באיזה מצב אנו נמצאים ומה מעורר מעבר למצב אחר‪.‬‬ ‫צורה כללית‪:‬‬  ‫‪:Reliable Data Transfer over a Perfectly Reliable Channel: rdt1.0‬‬ ‫‪ -‬בשיטה זו אנו יוצאים מנקודת הנחה כי מדובר בערוץ אמין כלומר אין בעיות במידה (ביטים מתחלפים)‬ ‫ואין חבילות שהולכות לאיבוד‪.‬כל החבילות מגיעות באותו הסדר‪.‬‬ ‫‪ -‬אנו מבצעים הפרדה בין האוטומט של המקבל לבין האוטומט של‬ ‫השולח‪.‬‬ ‫‪-‬בצד השולח והמקבל יש לנו רק מצב אחד ולכן אנו תמיד חוזרים‬ ‫אל אותו המצב‪.‬‬ ‫‪-‬צד שולח‪ :‬החץ המקווקו מציין כי יש אירוע שגרם למצב זה‪Rdt.‬‬ ‫מקבל מידע מהשכבה למעלה דרך הפונ' )‪.rdt_send(data‬‬ ‫כתדובה הוא יוצר פאקט חדש שיכיל את ה‪ data‬ושולח אותו דרך‬ ‫הפונ' )‪ udt_send(packet‬בערוץ הלא אמין‪.‬‬ ‫‪-‬צד מקבל‪ :‬האירוע שגורם למצב הוא קבלת פאקט מצד המקבל‪.‬‬ ‫הוא מקבל את הפאקט ע"י הפונ' )‪ rdt_rcv(packet‬ובתגובה מחלץ‬ ‫את המידע שהיה בפאקט ע"י הפונ' )‪ extract(packet.data‬ומעביר את המידע לאפליקציה ע"י הפונ'‬ ‫)‪.deliver_data(data‬‬ ‫‪:Reliable Data Transfer over a Channel with Bit Errors: rdt2.0‬‬ ‫‪ -‬נצא מנקודת הנחה כי בערוץ זה אנו עלולים לקבל פאקטים שהביטים התחלפו‪.‬‬ ‫‪ -‬נצא מנקודת הנחה כי עדיין החבילות מגיעות באותו הסדר שהן נשלחו‪.‬‬ ‫‪ -‬לכל חבילה שהגיעה ליעדה נשלח אישור ‪ack‬‬ ‫‪ -‬לכל חבילה שהגיעה משובשת נשלח ‪nak‬‬ ‫‪-‬בגרסא זו (לעומת ‪ ) rdt1.0‬יש לנו ‪ 3‬תוספות‪:‬‬ ‫‪ )1‬מנגנון איתור שגיאות ע"י שימוש ב‪.checksum-‬‬ ‫‪ )2‬קבלת פידבק מהצד המקבל ע"י אישור ‪ ack‬קבלת הודעה תקינה ושליחת ‪ nak‬על הודעה שגויה‪.‬‬ ‫‪ )3‬שליחה חוזרת‪.‬פאקט שהגיעה עם שגיאות תשלח מחדש לצד המקבל‪.‬‬  ‫‪ -‬הצד‬ ‫השולח‪:‬‬ ‫מצב ‪:1‬‬ ‫‪ 1.1‬הצד‬ ‫השולח‬ ‫מחכה‬ ‫לקבל‬ ‫מידע‬ ‫מהשכבה‬ ‫מעלה‪.‬‬ ‫‪1.2‬‬ ‫כאשר‬ ‫הוא‬ ‫מקבל‬ ‫את‬ ‫המידע‬ ‫הוא יוצר‬ ‫פאקט‬ ‫חדש‬ ‫המכיל‪:‬‬ ‫את ה‪ data-‬ופאקט של ‪.checksum‬‬ ‫‪ 1.3‬הוא מעביר את הפאקט החדש לייעדו ועובר למצב השני‪.‬‬ ‫מצב ‪:2‬‬ ‫‪ 2.1‬הצד השולח מחכה לקבלת ‪ ack‬או ‪ nak‬על הפאקט שנשלחה‪.‬‬ ‫‪ 2.2‬אם הצד השולח מקבל את החבילה האחרונה ששלח יחד עם הודעת ‪ nak‬הוא מבין כי ההודעה‬ ‫השתבשה‪.‬לכן הוא שולח בחזרה שוב את ההודעה האחרונה ששלח‪.‬ונשאר באותו המצב‪.‬‬ ‫‪ 2.3‬אם הצד השולח מקבל את החבילה האחרונה ששלח יחד עם הודעת ‪ ack‬משמע שההודעה‬ ‫התקבלה בצורה תקינה ואז הוא עובר חזרה למצב ההתחלתי שבו הוא מחכה ל‪ data‬מהשכבה‬ ‫העליונה‪.‬‬ ‫* בזמן השצד השולח נמצא במצב שהוא מחכה להודעת אישור מהצד המקבל‪,‬הוא איננו יכול לקבל עוד‬ ‫מידע מהשכבה העליונה‪.‬לכן ‪ rdt2.0‬מוכר כפרוטוקול ‪.stop-and-wait‬‬ ‫‪-‬הצד המקבל‪:‬‬ ‫מצב ‪: 1‬‬ ‫‪ 1.1‬הצד המקבל מחכה לקבלת המידע מהשכבה מטה‪.‬‬  ‫‪ 1.2‬הוא בודק אם המידע שהגיע בפאקט הנוכחית "מושחתת"‪.‬במידה וכן הוא יוצר פאקט חדש עם‬ ‫ההודעה ‪ nak‬ושולח אותה לצד השולח‪.‬ונשאר באותו המצב‪.‬‬ ‫‪ 1.3‬אם ההודעה לא מושחתת הצד המקבל מחלץ את המידע‪ ,‬מעביר אותה לשכבה מעלה‪,‬יותר פאקט‬ ‫חדש עם ההודעה ‪ ack‬ושולח אותה לצד השולח‪.‬‬ ‫לפרוטוקול ‪ rdt2.0‬יש ‪.fatal flow‬לא לקחנו בחבון שהודעות ה‪ nak -‬וה‪ ack-‬יכולות להשתבש גם‪.‬ישנם‬ ‫כמה פתרונות‪( :‬לא ממש יעילים)‬ ‫‪ -‬לשלוח מחדש‪.‬‬ ‫‪-‬הוספת ביטים ל‪ checksum‬גם עבור הודעות ה‪ ack-‬וה‪.nak-‬‬ ‫‪-‬שליחת הפאקט שוב במידה וקיבלנו עליה הודעת ‪ ack‬או ‪ nak‬משובש‪-‬יוצר פאקטים כפולים‪.‬‬ ‫פיתרון יעיל יותר‪ :‬הוספת ‪ seq number‬לתוך הפאקט‪.‬כך השולח יכול לקבוע האם החבילה שקיבל‬ ‫היא שידור חוזר‪.‬נצטרך במקרה זה רק ביט אחד כדי לדעת האם החבילה היא שידור חוזר‪.‬נשתמש‬ ‫בביטים ‪ 0‬ו‪.1-‬אנו לא מוסיפים את ה‪ seq-‬להודעות ‪ ack‬ו‪ nak-‬מכיוון ואין לנו עדיין חבילות שהלכו לאיבוד‬ ‫ולכן הצד השולח ידע שהאישור\אי אישור מתייחס להודעה האחרונה שהוא שלח‪.‬‬ ‫לכן הגרסא המתוקנן ל‪ rdt2.0-‬זה ‪.rdt2.1‬‬ ‫‪ -‬צד השולח ‪)rdt2.1( :‬‬ ‫מצב ‪:1‬‬ ‫‪ 1.1‬מחכה לקבל הודעת ‪ 0‬מהשכבה‬ ‫העליונה‪.‬‬ ‫‪ 1.2‬ברגע שהוא מקבל ‪ data‬הוא יוצר‬ ‫פאקט חדש המכיל‪ data,seq=0-‬ו‪-‬‬ ‫‪.checksum‬‬ ‫‪ 1.3‬מעביר את הפאקט החדש ליעדו‬ ‫ועובר למצב שני‪.‬‬ ‫מצב ‪:2‬‬ ‫‪ 2.1‬מצב בו הוא מחכה ל‪ ack‬או ‪nak‬‬ ‫על ‪.seq=0‬‬ ‫‪ 2.2‬אם הפאקט שהתקבל "מושחת"‬ ‫וההודעה היא ‪ nak‬השולח שולח חזרה‬ ‫את הפאקט האחרון ששלח‪.‬נשאר‬ ‫באותו המצב‪.‬‬ ‫‪ 2.3‬אם הפאקט ששלח לא "מושחת" וההודעה היא ‪ ack‬הוא עובר למצב ‪.3‬‬ ‫מצב ‪: 3‬‬ ‫‪ 3.1‬מחכה לקבל הודעת ‪ 1‬מהשכבה מעלה‪.‬‬ ‫‪ 3.2‬ברגע שהוא מקבל הודעה ‪ 1‬הוא יוצר פאקט חדש עם ‪ data,seq=1‬ו‪ checksum-‬ומעביר את המידע‬ ‫ליעד‪.‬עובר למצב ‪.4‬‬  ‫מצב ‪:4‬‬ ‫‪ 4.1‬מצב בו הוא מחכה לקבלת ‪ ack‬או ‪ nak‬על ‪.seq=1‬‬ ‫‪ 4.2‬אם הפאקט שהתקבל "מושחת" ויש לו הודעת ‪ nak‬הוא שולח מחדש את הפ?