‫מבוא לרשתות תקשורת‬

‫האינטרנט הינה רשת מחשבים המחברת מיליארדים של מכשירים מגוונים אחד עם השני‪.‬‬
‫בעבר היינו מתייחסים למכשירים האלו כמחשבים בלבד‪ .‬אך זה כלל לא המצב בעידן של היום‪.‬‬

‫המכשירים האלה מסווגים כ ‪ hosts‬או כ ‪end systems‬‬

‫מערכות קצה‪ ,‬מחוברות על ידי רשת הנקראת ‪ communication links‬שלה יש מגוון רחב של סוגים‬
‫שכל סוג יכול להעביר מידע בתדירות שונה (‪.)transmission rate‬‬

‫כשמערכת קצה שולחת מידע למערכת אחרת‪ ,‬היא מבצעת חלוקה (‪ )segmentation‬של המידע ומוסיפה‬
‫‪ headers‬לכל חלק‪ .‬התוצאה הסופית של זה נקראת פקטה (‪.)packet‬‬
‫בהגעה אל היעד הפקטה ״מתפרקת״ ומתקבל המידע הרצוי‪.‬‬

‫‪ packet switch‬הוא אמצעי שלוקח פקטה מחיבור תקשורת נכנס ומעבירה אותה לחיבור תקשורת יוצא‪ .‬שני‬
‫הסוגים המוכרים של ״ממתגי מנה״ הם ‪ link layer switch‬ו ‪ . router‬הראשון יותר נפוץ ב ‪Access‬‬
‫‪ Network‬והשני יותר נפוץ ב ‪Core Network‬‬
 ‫כל מערכת קצה ניגשת לאינטרנט באמצעות ‪ ISP‬שכל אחד כזה מהווה רשת של ‪ packet switches‬ו‬
‫‪.communication links‬‬

‫האופן שבו המידע עובר ברשת נקבע באמצעות פרוטוקולים שהחשובים שבהם הם ‪ TCP/IP‬והם מהוות‬
‫מעין מוסכמה שבאמצעותה מחלקים את המידע העובר בתווך כלשהו ואילו ‪ headers‬מוסיפים‪.‬‬

‫הרשת כ ‪service description‬‬

‫אפשר להסתכל על הרשת מזווית של מתכנת כ תשתית שמספקת שירות לאפליקציות‪.‬‬
‫הכוונה היא שבעידן של היום‪ ,‬שבו כמעט כל אפליקציה כיום מורכבת ממספר מערכות קצה שמחליפות‬
‫בינהם מידע (לדוגמה ‪ )client & server‬יש צורך בממשק שמאפשר לאפליקציות לבקש שירותי אינטרנט‬
‫מתשתית הרשת של המכשיר עליה התוכנה רצה‪.‬‬

‫ממשק זה נקרא ‪ Sockets‬והוא מהווה אוסף חוקרים שתוכנה שולחת חייבת ללכת לפיה כדי שתוכל לשלוח‬
‫מידע באמצעות האינטרנט‪ .‬כל תוכנה שמשתמשת ברשת חייבת לעבוד עם ממשק ה ‪ sockets‬ובהתאם‬
‫למכשיר עליו התוכנה יושבת‪ ,‬הממשק יכול לבקש דברים שונים‪.‬‬

‫פרוטוקול‬
‫נסתכל על הדיאגרמה הבאה כדי להבין מהו פרוטוקול‬
 ‫כשבן אדם א׳ מבקש מבן אדם ב׳ את השעה זוהי מוסכמה שקודם כל צריכה להיות מעין ״ברכת איחול״‬
‫קודם לכן ולאחר מכן שאלה ותשובה‪ .‬התגובה של בן אדם א׳ תלויה בחינוך ובתרבות שהוא חי בה‪ .‬אם כן ‪,‬‬
‫פרוטוקול הוא בעצם מוסכמה ששני הצדדים צריכים להסכים עליה כדי שתוכל להתבצע ה״שיחה״‪ .‬דוגמה‬
‫נוספת יכולה להיות מורה שעוצר את השיעור בכתה תחת האמרה ״יש שאלות?״ ותלמיד יכול לשאול שאלה‬
‫על ידי הרמה של היד ואישור המורה לאחר שזיהה את התלמיד ולאפשר לו לשאול את השאלה‪ ,‬תלמיד‬
‫שלא היה מרים את היד לא היה מקבל אישור מהמורה לשאול שאלה‪ ,‬גם אם בכוונתו לשאול‪.‬‬

‫פרוטוקול תקשורת דומה במהותו לדוגמאות הנ״ל רק שהתקשורת נעשית בין רכיבי תוכנה או חומרה של‬
‫מכשירים כלשהם‪.‬‬

‫ארכיטקטורת שכבות‬
‫המורכבות של האינטרנט מחייבת אותנו לבנות ארכיטקטורת שכבות כך שכל שכבה אחראית על תפקיד‬
‫מסוים ומידע מסוים‪.‬‬

‫באנלוגיה לחיים האזרחיים‪ ,‬נסתכל על מערכת שכבות שמתארת את העלייה שלנו לטיסה‬
 ‫בדומה‪ ,‬בעולם הרשתות‪ ,‬פקטה יוצאת ממחשב מקור למחשב יעד‪ .‬כמו כן נשים לב לסימטריה שבמערכת‬
‫העלייה לטיסה‪( ,‬על כל קנייה של כרטיס יש זיכוי ‪ ,‬על כל העלאה של מזוודה יש משיכה של המזוודה‬
‫בסוף)‪ .‬וניתן לחלק את זה לשכבות כפי שנראה בתמונה השנייה‪ .‬כל שכבה נותנת סוג כלשהו של שירות‬
‫לשכבה הבאה‪.‬‬

‫אם כן‪ ,‬ארכיטקטורת שכבות מאפשרת לנו לחלק מערכות מורכבות לפי שכבות פשוטות יותר ובכך לתת‬
‫מעין מודולריות וגמישות לכל חלק ‪ ,‬כל עוד כל שכבה מבצעת את הפעולה שהיא צריכה אין זה משנה איך‬
‫היא מבצעת אותו‪.‬‬

‫‪Protocol layering‬‬
‫נחבר אם כן את המונחים של פרוטוקול ושל ארכיטקטורת שכבות עליהם דיברנו קודם‪.‬‬
‫המימושים של הפרוטוקולי תקשורת מסודרים בשכבות‪ .‬כל פרוטוקול שייך לאחת השכבות כמו שכל פעולה‬
‫במערכת הטיסה הנ״ל שייכת לשכבה‪.‬‬
‫כל שכבה נותנת ‪ services‬לשכבה שמעליה באמצעות פעולות מסוימות שהיא עושה בעצמה ובאמצעות‬
‫המידע שהיא קיבלה מהשכבות שקדמו לה‪.‬‬

‫פרוטוקול בשכבה כלשהי יכול להיות ממומש בתוכנה ‪ ,‬בחומרה או בשילוב של השניים‪ .‬למשל פרוטוקולים‬
‫של שכבת האפליקצייה כמו ‪ HTTP‬או ‪ SMTP‬ממומשות ברובן בשכבה האפליקצייה במערכות הקצה וכך‬
‫גם פרוטוקולים של שכבת התעבורה‪ .‬בשכבה הפיזית לעומת זאת‪ ,‬יש מימוש חומרתי ברמת הכרטיס רשת‪.‬‬
 ‫ישנם מספר ארכיטקטורות שכבות לאינטרנט שהראשית בינהם היא מודל ‪ 5‬השכבות הנ״ל‪.‬‬

‫‪Note‬‬

‫לארכיטקטורת שכבות יש יתרונות רבים אך היא אינה מושלמת בעצמה‪ ,‬למשל ישנם מצבים שבהם‬
‫יש כפילויות של מימושים בין השכבות כלומר אותה פונקציונליות מסוימת נמצאת בשתי שכבות‬
‫סמוכות‪ .‬כמו כן ההפרדה מעולם לא תהיה מלאה לחלוטין שכן כל שכבה צריכה מידע משכבה‬
‫ספציפית‬

‫‪Application Layer‬‬
‫שכבת האפליצייה היא המקום שבו שוכנים יישומי רשת והפרוטוקולים של שכבת היישומים שלהם‪ .‬שכבת‬
‫היישום של האינטרנט כוללת פרוטוקולים רבים‪ ,‬כמו פרוטוקול ‪( HTTP‬המספק בקשה והעברה של מסמכי‬
‫אינטרנט)‪( SMTP ,‬המספק העברת הודעות דואר אלקטרוני) ו‪( FTP-‬המספק העברת קבצים בין שניים‬
‫מערכות קצה)‪ .‬פונקציות רשת מסוימות‪ ,‬כמו תרגום של שמות ידידותיים לאדם עבור מערכות קצה אינטרנט‬
‫כמו ‪ www.ietf.org‬לכתובת רשת של ‪ 32‬סיביות‪ ,‬נעשות גם הן בעזרת פרוטוקול של שכבת האפליקצייה‪,‬‬
‫כלומר‪ ,‬מערכת שמות הדומיין (‪.)DNS‬‬

‫פרוטוקול זה מופץ על פני מספר מערכות קצה‪ ,‬כאשר האפליקציה במערכת קצה אחת משתמשת‬
‫בפרוטוקול כדי להחליף חבילות מידע עם האפליקציה במערכת קצה אחרת‪ .‬נתייחס לחבילת המידע הזו‬
‫בשכבת היישום כ ‪.message/data‬‬

‫‪Transport Layer‬‬
‫שכבת התעבורה של האינטרנט מעבירה הודעות שכבת אפליקציה בין נקודות קצה של יישומים‪ .‬באינטרנט‪,‬‬
‫ישנם שני פרוטוקולי תעבורה‪ TCP ,‬ו‪ ,UDP-‬שכל אחד מהם יכול להעביר הודעות שכבת יישומים‪TCP .‬‬
‫מספקת שירות מונחה חיבור ליישומים שלה‪ .‬שירות זה כולל אספקה​​מובטחת של הודעות משכבת‬
‫האפליקצייה ליעד ובקרת זרימה (כלומר‪ ,‬התאמת מהירות שולח‪/‬מקבל)‪ TCP .‬גם מפרק הודעות ארוכות‬
‫למקטעים קצרים יותר ומספק מנגנון בקרת גודש‪ ,‬כך שמקור מצער את קצב השידור שלו כאשר הרשת‬
‫עמוסה‪ .‬פרוטוקול ‪ UDP‬מספק שירות ‪ connectionless‬ליישומים שלו‪ .‬זהו שירות ללא סלסולים שאינו‬
‫מספק אמינות‪ ,‬ללא בקרת זרימה וללא בקרת גודש‪ .‬המידע העובר בשכבה הזו הוא ‪segment‬‬
 ‫‪Network Layer‬‬
‫שכבת הרשת של האינטרנט אחראית להעברת מנות שכבת רשת הידועות כ‪ Datagrams-‬ממארח​​אחד‬
‫למשנהו‪ .‬פרוטוקול שכבת התעבורה באינטרנט (‪ TCP‬או ‪ )UDP‬במארח מקור מעביר קטע שכבת תחבורה‬
‫וכתובת יעד לשכבת הרשת‪ ,‬בדיוק כפי שהיית נותן לשירות הדואר מכתב עם כתובת יעד‪ .‬שכבת הרשת‬
‫מספקת לאחר מכן את השירות של מסירת הקטע לשכבת התחבורה במארח היעד‪.‬‬
‫שכבת הרשת של האינטרנט כוללת את פרוטוקול ה‪ IP-‬המהולל‪ ,‬המגדיר את השדות ב‪ Datagram-‬וכן‬
‫כיצד פועלות מערכות הקצה והנתבים בשדות אלו‪ .‬יש רק פרוטוקול ‪ IP‬אחד‪ ,‬וכל רכיבי האינטרנט שיש להם‬
‫שכבת רשת חייבים להפעיל את פרוטוקול ה‪ .IP-‬שכבת הרשת של האינטרנט מכילה גם פרוטוקולי ניתוב‬
‫הקובעים את המסלולים ש‪ datagrams‬עוברות בין מקורות ויעדים‪ .‬לאינטרנט יש פרוטוקולי ניתוב רבים‪.‬‬
‫האינטרנט הוא רשת של רשתות‪ ,‬ובתוך רשת‪ ,‬מנהל הרשת יכול להפעיל כל פרוטוקול ניתוב רצוי‪ .‬למרות‬
‫ששכבת הרשת מכילה גם את פרוטוקול ה‪ IP-‬וגם פרוטוקולי ניתוב רבים‪ ,‬היא מכונה לעתים קרובות פשוט‬
‫שכבת ה‪ ,IP-‬המשקפת את העובדה ש‪ IP-‬הוא הדבק שמחבר את האינטרנט יחד‪.‬‬

‫‪Link Layer‬‬
‫שכבת הרשת של האינטרנט מנתבת ‪ datagrams‬דרך סדרה של ראוטרים בין המקור ליעד‪ .‬כדי להעביר‬
‫פקטה מצומת אחד (‪ host‬או ראוטר) לצומת הבא במסלול‪ ,‬שכבת הרשת מסתמכת על שירותי שכבת‬
‫הקישור‪ .‬בפרט‪ ,‬בכל צומת‪ ,‬שכבת הרשת מעבירה את ה‪ Datagram-‬למטה אל שכבת הקישור‪ ,‬אשר‬
‫מעבירה את ה‪ Datagram-‬לצומת הבא לאורך המסלול‪ .‬בצומת הבא זה‪ ,‬שכבת הקישור מעבירה את‬
‫הנתונים גרמה למעלה לשכבת הרשת‪.‬‬
‫השירותים שמספקת שכבת הקישור תלויים בפרוטוקול הקישור הספציפי המופעל על הקישור‪ .‬לדוגמה‪ ,‬כמה‬
‫פרוטוקולים של שכבת קישור מספקים מסירה אמינה‪ ,‬מצומת שידור‪ ,‬דרך קישור אחד‪ ,‬ועד לצומת קבלה‪.‬‬
‫שימו לב ששירות משלוחים אמין זה שונה משירות המשלוחים האמין של ‪ ,TCP‬המספק משלוח אמין‬
‫ממערכת קצה אחת לאחרת‪ .‬דוגמאות לפרוטוקולים של שכבת קישור כוללות ‪ Ethernet, WiFi‬ופרוטוקול‬
‫‪ DOCSIS‬של רשת הגישה לכבלים‪ .‬מכיוון שגרמות נתונים בדרך כלל צריכות לעבור מספר קישורים כדי‬
‫לנסוע ממקור ליעד‪ ,‬ייתכן ש‪ Datagram-‬יטופל על ידי פרוטוקולים שונים של שכבת קישור בקישורים שונים‬
‫לאורך המסלול שלה‪ .‬לדוגמה‪ ,‬דאטהגרם עשוי להיות מטופל על ידי ‪ Ethernet‬בקישור אחד ועל ידי ‪PPP‬‬
‫בקישור הבא‪ .‬שכבת הרשת תקבל שירות שונה מכל אחד מהפרוטוקולים השונים של שכבת הקישור‪.‬‬
‫נתייחס למנות שכבת הקישור כאל ‪.frames‬‬

‫‪Physical Layer‬‬
‫בעוד שהתפקיד של שכבת הקישור הוא להעביר פריימים שלמים מאלמנט רשת אחד לאלמנט רשת סמוך‪,‬‬
‫תפקידה של השכבה הפיזית הוא להעביר את הביטים בתוך ה‪ frame‬מצומת אחד למשנהו‪ .‬הפרוטוקולים‬
‫בשכבה זו שוב תלויים בקישור ועוד יותר תלויים באמצעי השידור בפועל של הקישור (לדוגמה‪ ,‬חוט נחושת‬
‫מעוות זוג‪ ,‬סיבים אופטיים במצב יחיד)‪ .‬לדוגמה‪ ,‬ל‪ Ethernet -‬יש הרבה פרוטוקולים של שכבה פיזית‪ :‬אחד‬
‫עבור חוטי נחושת מעוותים‪ ,‬אחר עבור כבל קואקסיאלי‪ ,‬אחר עבור סיבים‪ ,‬וכן הלאה‪ .‬בכל מקרה‪ ,‬קצת‬
‫מועבר על פני הקישור בדרך אחרת‪.‬‬

‫‪Encapsulation‬‬
 ‫‪M‬‬ ‫התמונה ממחישה את הרעיון החשוב של אנקפסולציה ברשת‪ .‬במארח השולח‪ ,‬הודעת שכבת יישום‬
‫מועברת לשכבת התחבורה‪ .‬במקרה הפשוט ביותר‪ ,‬שכבת התעבורה לוקחת את ההודעה ומצרפת מידע‬
‫נוסף ‪ H t‬שישמש את שכבת התעבורה בצד המקלט‪ .‬הודעת שכבת היישום ומידע הכותרת של שכבת‬
‫התעבורה מהווים יחד את מקטע שכבת התעבורה‪ .‬קטע שכבת ההובלה מכסה אפוא את הודעת שכבת‬
‫היישום‪ .‬המידע הנוסף עשוי לכלול מידע המאפשר לשכבת התחבורה בצד המקלט להעביר את ההודעה עד‬
‫ליישום המתאים‪ ,‬וביטים לזיהוי שגיאות המאפשרים למקלט לקבוע אם סיביות בהודעה שונו במסלול‪ .‬לאחר‬
‫מכן‪ ,‬שכבת התחבורה מעבירה את הקטע לשכבת הרשת‪ ,‬אשר מוסיפה מידע על כותרת רשת (‪ Hn‬באיור‬
‫‪ )1.24‬כגון כתובות מקור וכתובות קצה של מערכת היעד‪ ,‬ויוצרת נתונים גרמה של שכבת רשת‪ .‬לאחר מכן‪,‬‬
‫הדאטהגרם מועבר לשכבת הקישור‪ ,‬אשר תוסיף מידע כותרת של שכבת קישור משלה ותיצור מסגרת של‬
‫שכבת קישור‪ .‬לפיכך‪ ,‬אנו רואים שבכל שכבה‪ ,‬לחבילה יש שני סוגים של שדות‪ :‬שדות כותרת ושדה‬
‫‪ .payload‬ה‪ payload‬הוא בדרך כלל חבילה מהשכבה שלמעלה‪.‬‬

‫המסקנה היא בעצם שפקטה שעוברת באינטרנט בעצם נראת מהצורה‬

 ‫רכיבי תקשורת‬
‫‪Hub‬‬
‫‪ Hub‬משמש בדרך כלל לחיבור מקטעים של ‪( LAN‬רשת מקומית)‪ .‬הוא מכיל מספר ‪ .Ports‬כאשר פקטה‬
‫מגיעה ליציאה אחת‪ ,‬היא מועתקת לפורטים האחרים כך שכל מקטעי ה‪ LAN-‬יכולים לראות את כל‬
‫החבילות‪ Hub .‬פועל כנקודת חיבור משותפת למכשירים ברשת‪ .‬המשמעות היא שבאחריות כל מכשיר‬
‫המחובר ב ‪ Hub‬לבדוק האם הפקטה מיועדת אליו או לא‪.‬‬

‫‪Switch‬‬
‫‪ switch‬פועל בשכבת הלינק (שכבה ‪ )2‬ולעיתים בשכבת הרשת (שכבה ‪ )3‬של ‪ OSI‬ולכן תומך בכל‬
‫פרוטוקול פקטות‪ .‬רשתות ‪ LAN‬שמשתמשות ‪ Switch‬כדי להצטרף למקטעים נקראות ‪.Switched LAN‬‬
‫רכיב זה הוא רכיב שמנתב את הפקטות בין מקטעי ה ‪ LAN‬רק ליעד המתאים‪.‬‬

‫ה ‪ Switch‬עושה זאת באמצעות ‪ Switch table‬שבו מוצמד לכל פורט כתובת ‪MAC‬של המכשיר שמחובר‬
‫אליה‪.‬‬

‫הבחנה‬

‫‪ Hub‬ו ‪ Switches‬מאפשרים להעביר מידע בטווח של ‪ .LAN‬הם לא מאפשרים להוציא מידע מחוץ‬
‫לרשת המקומית‪ ,‬כיוון שאין להם את היכולת לקרוא כתובות ‪IP‬‬

‫‪Switch Table‬‬
 ‫כאשר ה‪ Switch‬מקבל ‪ , Frame‬ה‪ Frame‬מכיל ב‪ Headers‬שלו את ה‪ Source MAC‬ואת ה ‪.Dest Mac‬‬
‫ראשית הוא יודע לשייך את ה‪ Source MAC‬לפורט שממנו הגיע ה ‪ ,Frame‬הוא מיד שומר זאת בטבלה‬
‫(הטבלה משמשת ב‪ Cache‬ולכן המידע לא נשמר באופן תמידי)‪ .‬כעת מצב הטבלה הוא‬

‫‪INTERFACE NUMBER‬‬ ‫‪MAC‬‬

‫‪1‬‬ ‫‪A‬‬

‫כאשר ה‪ Switch‬לא יודע מיהו ה‪( Dest Mac‬אם הוא יודע כלומר זה שמור לו בטבלה הוא מיד מעביר את‬
‫ה‪ frame‬ליעד)‪ ,‬הוא שולח את ה ‪ frame‬לכל הנקודות חיבור חוץ מ ‪ IN=1‬שזה הפורט של מי ששלח את‬
‫ה‪ ,Frame‬בשיטה שנקראת ‪ .Broadcasting‬רק המחשב שאמור לקבל את ההודעה מגיב בחזרה ב‪Frame‬‬
‫תגובה‪ .‬כאשר מתקבל ה‪ Frame‬הזה ב ‪ ,Switch‬הוא בודק את ה ‪ Source MAC‬שוב פעם ומעדכן שוב את‬
‫הטבלה‪ .‬כעת הטבלה נראת ככה‪:‬‬

‫‪IN‬‬ ‫‪MAC‬‬
‫‪1‬‬ ‫‪A‬‬
‫‪2‬‬ ‫‪B‬‬

‫‪Router‬‬
‫ראוטר הוא מחובר לפחות לשתי רשתות‪ ,‬או שתי ‪ LANs‬או )‪ .WANs (Wide Area Network‬או ‪ LAN‬אל‬
‫מול ה )‪. ISP (Internet Service Provider‬‬
‫הראוטר מנתב את מידע מרשת אחת לאחרת בהתאם לכתובת ה‪ IP‬שלהם‪.‬‬

‫הראוטר מקבל מפקטה את כתובת ה‪ IP‬והוא קובע האם זה מיועד לרשת שלו או שזה מיועד לרשת אחרת‪.‬‬
‫בעצם הראוטר מהווה ‪ Gateway‬של הרשת המקומית‪.‬‬

‫ההבדלים‬
 ‫‪MAC‬‬
‫כתובת ‪ MAC‬היא כתובת המורכבת משישה צירופים של זוגות אותיות (‪ )A-F‬ומספרים‪ ,‬המופרדים בינהם‪.‬‬
‫את ההפרדה אפשר לייצג במגוון דרכים‪ ,‬לדוגמה‪:‬‬

‫כתות ‪ MAC‬מחולקת לשני חלקים‪:‬‬

‫למה צריך גם כתובת ‪ MAC‬וגם כתובת ‪?IP‬‬

‫לכל פקטה שנשלחת בין ‪ 2‬מכשירים סמוכים מוצמדות שתי כתובות יעד‪ ,‬ה ‪ IP‬של מחשב היעד ו‪ MAC‬של‬
‫הראוטר הבא בדרך אל היעד הסופי‪ .‬כל ראוטר שמקבל פקטה משנה את כתובת ה‪ MAC‬לזו של הראוטר‬
‫הבא אחריה‪ ,‬אך הוא לא נוגע בכתובת ה ‪ IP‬של היעד הסופי‪ .‬זה ממשיך עד שהפקטה מגיעה לכתובת‬
‫‪ MAC‬של כרטיס הרשת שמגלה כי כתובת ה ‪ IP‬של היעד שייכת לו‪.‬‬
 ‫‪ARP‬‬
‫זה פרוטוקול של ה‪ Link Layer‬שמאפשר לכל מחשב לגבש טבלה של כל כרטיסי הרשת שהוא מחובר‬
‫אליהם ישירות ברשת מקומית‪ .‬אם נרצה לדבר עם מחשב שנמצא איתי באותה הרשת עליי לדעת את‬
‫כתובת ה‪ IP‬של המחשב‪ ,‬ואת כתובת ה‪ MAC‬שלו‪ .‬הראוטר יודע לאיזה האם כתובת ה‪ MAC‬שייכת לאחד‬
‫המכשירים שמחוברים אליו ברשת מקומית או שעליו להעביר את הפקטה לכתובת ‪ MAC‬של הראוטר הבא‬
‫במסלול ליעד (דרך שכבת הקו)‪ .‬לכן יש חשיבות לקשר בין ‪ MAC‬לבין ‪.IP‬‬

‫פרוטוקול ‪ ARP‬רלוונטי רק ב שכבת הקו ‪ ,‬כלומר רק ברשת המקומית‪ .‬לכן יש צורך של המחשב לדעת מי‬
‫נמצא איתו ברשת המקומית‪ .‬הזיהוי הזה מתבצע באמצעות הצמדה של כתובת ‪ MAC‬לכתובת ‪ IP‬של‬
‫המחשבים שנמצאים איתו באותה רשת‪.‬‬

‫הפרוטוקול עובד באופן הבא‪:‬‬

‫א) מחשב ‪ A‬שולח ‪ ARP Query‬לכל הישויות ברשת המקומית‪ -‬השאילתה היא מהצורה למי יש את‬
‫כתובת ה‪ MAC‬המתאימה ל‪ Dest IP‬ששמור אצלי ב‪ . ?Frame‬הוא עושה זאת על ידי שליחת‬
‫השאילתה לכתובת ה‪ MAC‬מהצורה ‪ 255:255:255:255:255:255‬שהיא כתובת ‪ Broadcast‬כלומר זה‬
‫ישלח את ההודעה לכל המחשבים השמורים ברשת המקומית‪ .‬בדומה ל‪ , Switch Table‬רק המחשב‬
‫שמזהה את כתובת ה ‪ IP‬שלו יגיב‪.‬‬

‫ב) לאחר התגובה של מחשב ‪ A‬ממחשב ‪ , B‬הוא שומר את המידע ב ‪ ARP table‬שנמצא אצלו (לכל‬
‫מחשב ברשת המקומית יש טבלה משלו) שמכיל את העמודות ‪ . IP,MAC,Port‬פעם הבאה הוא יוודא‬
‫בטבלה האם כתובת ה‪ MAC‬שמורה בהינתן ה‪ Dest IP‬וככה יוותר על תהליך ה‪.Broadcast‬‬
 ‫פקטת ‪ARP‬‬
‫כאשר בקשת ‪ ARP‬נשלחת לכל הישויות ברשת המקומית‪ ,‬במטרה למפות בין כתובת לוגית לכתובת פיזית‪,‬‬
‫בתגובה‪ ,‬המחשב שכתובת ה ‪ IP‬בבקשה שייכת לו‪ ,‬מחזירת את כתובת ה‪ MAC‬שלו‪ .‬בגלל שפקטת ‪ARP‬‬
‫עוברת רק בשכבת הקו‪ ,‬אז גם הבקשות וגם התגובות של פקטות כאלה נעטפות רק ב ‪ header‬אחד‬

‫שליחת מידע מחוץ לרשת המקומית‬

‫כשמחשב רוצה לשלוח מידע למחשב אחר ברשת הוא קודם כל שואל את עצמו‪ ,‬״האם אני צריך‬
‫לשלוח את המידע למחשב ברשת המקומית שלי‪ ,‬הוא עושה זאת באמצעות השוואת הקידומת של‬
‫כתובת ה‪ IP‬שלו לכתובת ה‪ IP‬של היעד‪ ,‬ככה הוא יודע האם היעד שייך לרשת המקומית (למחשבים‬
‫ברשת מקומית יש את אותה הקידומת)‪ .‬אם הוא מבין שהוא צריך להעביר את המידע ברשת‬
‫המקומית הוא משתמש ב ‪ ARP‬כדי לקבל מידע על ‪ MAC‬היעד‪ .‬אם היעד נמצא מחוץ לרשת יש‬
‫צורך בשכבת הערוץ כדי לעבור בין התחנות ולשם כך יש צורך להעביר את המידע בין הראוטרים‬
‫הסמוכים ולכן המחשב גם יכול להשתמש ב ‪ ARP‬כדי להשיג את הכתובת ‪ MAC‬של הראוטר‬
‫ולהעביר את המידע אליה (במקרה הפשוט יש ראוטר אחד ברשת מקומית ולכן אפשר גם להעביר את‬
‫המידע ל‪.)default gateway‬‬
 ‫שכבת התעבורה‬
‫שכבת התעבורה אחראית להעביר מידע מ‪ Process‬ל ‪ Process‬מרוחק‪ .‬כחלק מכך‪ ,‬יש לה שתי מטרות‬
‫עיקריות‪:‬‬

‫א) ריבוב מספר אפליקציות על אותה ה‪ .end system‬כלומר היכולת להשתמש בכמה שירותים של אותה‬
‫מערכת קצה (כלומר עבודה מול כתובת ‪ IP‬בודדת) ולהשתמש בכמה שירותים שונים של הישות‪ ,‬כך שהיא‬
‫תדע להבדיל איזה זרם שייך לאיזה שירות שהיא מספקת‪.‬‬

‫ב) העברה אמינה של מידע (אופציונלי)‪.‬‬

‫אנחנו כבר יודעים איך שכבת התעבורה מאפשרת עבודה מול כמה שירותים של אותה מערכת ‪.Ports‬‬
‫‪ Port‬הוא מספר בטווח ]‪ . [0, 65535‬על מנת שתוכנה אחת תוכל להתחבר לתוכנה מרוחקת‪ ,‬עליה לדעת‬
‫על איזה ‪ Port‬התוכנית מאזינה‪ .‬לכן ישנם מספר פורטים מוכרים‪ .‬אלו הם הפורטים ]‪ [0, 1023‬וכמוסכמה‬
‫הם אמורים להיות תפוסים ‪ ,‬למשל פורט ‪ 80‬שייך לפרוטוקול ‪. http‬‬

‫פרוטוקולים מבוססי קישור ולא מבוססי קישור‬

‫בשכבת התעבורה פרוטוקולים יכולים להיות ‪ Connection Oriented‬או ‪Connection Less‬‬

‫‪Connection Oriented‬‬
‫על מנת לתקשר עם מישהו בפרוטוקול מסוג זה‪ ,‬ראשית יש להקים את הקישור (ב‪ Sockets‬עושים את זה‬
‫באמצעות ‪ ) accept‬לפני שמקבלים מידע‪ .‬אפשר להקביל את זה לטלפון שבו צריך להתקשר למישהו‬
‫ספציפי ואי אפשר לדבר לטלפון ושמישהו יענה‪ .‬פרוטוקולים כאלה מבטיחים אמינות בשליחת המידע כלומר‪,‬‬
‫שכל המידע שנשלח יגיע אל המקבל בסדר שבו הוא נשלח ‪.‬‬

‫‪Connection Less‬‬
‫בפרוטוקול זה אין הבטחה שחבילה שנשלחת תגיע ליעדה והיא לא מכירה את החבילות האחרות שנשלחות‬
‫בקשורות לאותו ה‪ .data‬לכן גם אין הבטחה שהחבילות יגיעו בסדר הנכון‪ .‬המסקנה מכך היא שאין צורך‬
‫להרים ולסגור חיבור כל שצריך לעשות הוא לשלוח את החבילה‪.‬‬

‫למה צריך ‪?Connection Less‬‬

‫על פניו נראה שאין שום יתרון להשתמש ב ‪ Connection Less‬אבל‪ ,‬יש יתרון פשוט‪ .‬מהירות נוכל‬
‫לממש התנהגות שלנו שתאבטח את ‪ UDP‬בשכבת האפליקצייה ולקבל חלק מההתנהגות הדרושה‬
‫וכך גם לצמצם את התקורה כי אנחנו מתאימים את הפרוטוקול למוצר הספציפי שלנו‪ .‬זהו עקרון שדי‬
‫חוזר על עצמו בתכנות שככל שמכלילים יותר התנהגות מסוימת ככה התקורה עבורה גבוהה יותר‬

‫‪UDP VS TCP‬‬
‫הפרוטוקולים הכי נפוצים בשכבת התעבורה הם ‪ UDP‬ו ‪ TCP‬וכל מהם הוא סוג אחר של חיבור עם‬
‫יתרונות וחסרונות משלו‪ .‬לפני שנדבר על כל אחד בנפרד נשווה בינהם עם הפרמטרים החשובים‪:‬‬

‫‪UDP‬‬
‫פרוטוקול שאינו מבוסס קישור‪ .‬לכן הוא אינו מבטיח הגעה של המידע כלל והגעה בסדר הנכון בפרט‪.‬‬
‫ב ‪ header‬של פקטת ‪ UDP‬יש בסך הכל את השדות הבאים‪:‬‬

‫א‪Source Port .‬‬

‫ב‪Destination Port .‬‬
‫ג‪ - Length .‬גודל ה ‪ header‬והמידע יחד בפקטה‬
 ‫ניתן לראות בעצם שגודל ה‪ header‬הוא ‪ 8‬בתים וגודל כל הפקטה הוא ‪ 32‬בתים השדה של ‪ Length‬מציין‬
‫את הגודל ‪ .40‬הסיבה שהשתמשתי כאן ב ‪ DNS‬הוא כי זה פרוטוקול של שכבת האפליקציה שממומש‬
‫באמצעות ‪.UDP‬‬

‫ד‪ -Checksum .‬ציינו שבעיות ברשת יכולות לגרום לחבילות לא להגיע בכלל‪ ,‬או לרצף של חבילות להגיע‬
‫ברצף הלא נכון‪ .‬בעיות ברשת יכולות לגרום גם לשגיאות בחבילה עצמה ‪ -‬כלומר שהחבילה תגיע עם תוכן‬
‫שונה ממה שהיא נשלחה‪ .‬במצב שכזה נרצה שהשרת ידע שארעה שגיאה ולא יתייחס לפקטה התקולה‪.‬‬

‫‪Checksum‬‬
‫טכניקה שמאפשרת לקבוע את אמינות המידע המתקבל ומאפשר לזהות האם קרתה שגיאה (לא מזהה‬
‫את השגיאה עצמה)‪.‬‬

‫השולח משתמש באלגוריתם כדי לחשב את ה‪ Checksum‬של המידע‪ .‬כאשר המקבל תופס את המידע‪ ,‬הוא‬
‫מחשב את ה‪ checksum‬בעצמו באותו האלגוריתם ומשווה עם ה‪ checksum‬שעבר‪ .‬אם יש התאמה אז אין‬
‫שגיאות‬
‫במקרה של ‪ UDP‬המידע מחולק לחתיכות של ‪ 16‬ביט‪ .‬החתיכות האלה מחוברות יחדיו‪ ,‬אם יש ‪carry‬‬
‫מוסיפים אותו ל ‪ .sum‬לאחר מכן מפעילים ‪ one's complement‬על הסכום (‪ not‬על הביטים) וזה ה‬
‫‪.checksum‬‬

‫למשל נסתכל על ה‪ data‬הבא‪:‬‬

‫‪0110011001100000‬‬

‫‪0101010101010101‬‬

‫‪1000111100001100‬‬

‫נסכום את השניים הראשונים נקבל ‪:‬‬

‫‪0110011001100000‬‬

‫‪+‬‬

‫‪0101010101010101‬‬

‫‪− − − − − − − − −−‬‬

‫‪1011101110110101‬‬

‫לתוצאה נוסיף את ‪ 16‬הביטים הנותרים ‪:‬‬

 ‫‪1011101110110101‬‬

‫‪+‬‬

‫‪1000111100001100‬‬

‫‪− − − − − − − − −−‬‬

‫‪0100101011000001‬‬

‫נוצר לנו ‪ carry‬ולכן יש להוסיף אותו לסכום (‪ )wraparound‬ונקבל‬

‫‪0100101011000001 + 1 = 0100101011000010‬‬

‫‪checksum = 1011010100111101‬‬ ‫לבסוף נבצע ‪ not‬על התוצאה ונקבל‪:‬‬

‫בצד המקבל נעשה את אותו חישוב של הסכימה‪ ,‬לבסוף נסכום עם ה‪ checksum‬שהעברנו ואם הסכום יוצא‬
‫שכל הביטים הם ‪ 1‬סימן שהמידע אמין‪ .‬אם אחד הביטים הוא ‪ 0‬סימן שישנו שיבוש במידע‪.‬‬

‫‪Warning‬‬

‫ברגע שהשגיאה היא יותר מ‪ bit‬אחד יש מצב שה‪ checksum‬יצא אותו דבר למרות שהייתה שגיאה‪.‬‬
‫כמו כן יכול להיות שגיאה ב‪ checksum‬עצמו‪..‬‬

‫‪TCP‬‬
‫פרוטוקול שכבת התעבורה הנפוץ ביותר לחיבורים מבוססי קישור‪.‬‬
‫כאשר בשכבת האפליקציה נרצה להעביר מידע באמצעות ‪ ,tcp‬אנחנו לא יכולים פשוט לשלוח חבילה אל‬
‫תוכנה מרוחקת‪ .‬ראשית עלינו ליצור קישור עם התוכנה המרוחקת ועתה כל חבילה שנשלח תהיה חלק‬
‫מאותו קישור‪.‬‬

‫‪ TCP‬תוכנן ועוצב לרוץ מעל שכבת רשת שאינה אמינה‪ .‬כלומר‪ ,‬הנחת הבסיס היא שבשכבת הרשת‬
‫חבילות יכולות ללכת לאיבוד או להגיע בסדר לא נכון‪.‬‬

‫כיצד ניתן לוודא שהמידע מגיע אל היעד? וכיצד ניתן לוודא שהוא מגיע‬
‫בסדר הנכון?‬
‫על מנת לעשות זאת‪ TCP ,‬מנצל את העובדה שהוא פרוטוקול מבוסס קישור‪ .‬מכיוון שכל החבילות‬
‫(בשכבת התעבורה ‪ )segment‬הן חלק מקישור‪ ,‬אנו יכולים לבצוע דברים רבים‪.‬‬
 ‫ראשית‪ ,‬אנו יכולים לתת מספר סידורים לחבילות שלנו‪ .‬נאמר שבשכבת האפליקציה רצינו לשלוח את‬
‫המידע "‪ "Hello Cool Network‬והחלוקה לחבילות הוא חבילה פר מילה‪.‬‬

‫נוכל לשלוח את החבילות כשלצידן יש מספר סידורי‬

‫בצד שרת חבילות יכולות ליפות ונניח שחבילה ‪ 2‬נפלה בדרך‪ .‬בשיטה שלנו השרת יבין שחסרה לו חתיכה‬
‫מספר ‪.2‬‬

‫ניתן להשתמש במספרי החבילות כדי לוודא שחבילה אכן הגיעה ליעדה‪ .‬כך למשל‪ ,‬ניתן להחליט שעל כל‬
‫חבילה שהגיעה‪ ,‬השרת שולח אישור ללקוח‪ .‬חבילה כזו נקראת בדרך כלל ‪ ACK‬ומשמעותה ״קיבלתי את‬
‫החבילה״‪ .‬הלקוח יצפה לקבל ‪ ACK‬על כל חבילה אותה הוא שולח‪.‬‬
‫בצד לקוח‪ ,‬אם לא התקבלה חבילת ‪ ACK‬מהשרת לאחר זמן מסוים‪ ,‬כנראה שהחבילה שהוא שלח ״נפלה״‬
‫ובמקרה כזה היא תשלח שוב‬

‫באופן הזה הצלחנו להבטיח שהחבילות אכן הגיעו ליעדן‪ .‬השימוש במספר סידורי לכל חבילה מאפשר לנו‬
‫להתמודד עם הבעיה של סדר הגעת החבילות‪.‬‬
 ‫המימוש ב ‪TCP‬‬
‫ה ‪ headers‬ב ‪ TCP‬מכיל את אותם השדות של ‪ UDP‬ושדות נוספים‪ ,‬ההבדל הוא שבמקום ‪ length‬יש‬
‫‪ head-length‬שמייצג רק את הגודל של ה‪.header‬‬

‫באמצעות ה‪ checksum‬אפשר לגלות שגיאות‪ ,‬אך אם נגלה שגיאה ב ‪ UDP‬הוא פשוט יזניח את הפקטה‪,‬‬
‫כאן צריך להשתמש במנגנון ה ‪ ACK‬כדי לאשר שאכן המידע הגיע תקין או ‪ NAK‬כדי להודיע שהמידע‬
‫הגיע לא תקין‪ .‬בגלל שגם ‪ ACK/NAK‬יכול להשתבש בגלל שגיאות אנחנו נכניס אותו כ ‪header TCP‬‬
‫מלא בתשובה ונניח שה‪ checksum‬יכול לתפוס את זה‪( .‬זה במקום לשלוח פשוט ‪.)ACK bit‬‬

‫הפרוטוקול ‪ TCP‬לא נותן מספר סידורי לכל חבילה‪ ,‬אלא לכל ‪ .byte‬כזכור‪ ,‬אנחנו מעבירים מצד לצד רצף‬
‫של בתים‪ .‬לכל אחד מהבתים ברצף יש מספר סידורי משלו‪ .‬בכל חבילה שנשלח‪ ,‬יהיה המספר הסידורי‬
‫שמציין את הבית הנוכחי בחבילה‪.‬‬

‫כאשר התו האחרון הוא הרווח‬ ‫‪100, 101, 102, 103, 104, 105‬‬ ‫המחרוזת ‪ H ello‬תוקבל למספרים הסידוריים‬
‫שכן המחרוזת הנ״ל היא חלק ממשפט שלם‪.‬‬

‫החבילה השנייה התחילה עם המספר הסידורי ‪ .106‬המשמעות של כך היא שהבית הראשון שבה כלומר‬
‫התו ‪ c‬הוא בעל המספר הסידורי ‪ .106‬כלומר המשך התקשורת ייראה כך ‪:‬‬

‫נשים לב שמדובר בתקשורת בין הלקוח לשרת בדוגמה‪ ,‬אך באותו אופן זה יכול להיות בין שרת‬
‫ללקוח‪.‬‬
 ‫נסתכל על דוגמה שבה ה‪ client‬רוצה לשלוח שתי הודעות מופרדות הראשונה היא ‪ Hello‬והשנייה היא‬
‫‪.World‬‬

‫ה ‪ client‬שולח את ההודעה הראשונה לשרת ומחכה ל‪ . ack‬רק אחרי שהוא מקבל את ה‪ ack‬הוא יעביר את‬
‫ההודעה הבאה‪.‬‬

‫המנגנון הזה נקרא ‪ Stop & Wait‬כלומר אם התקבל ‪ nak‬נשלח שוב את הפקטה שעבורה התקבל ‪.nak‬‬
‫נשים לב שהשרת שולח כ‪ response‬את ה ‪ tcp header‬בלי ‪.data‬‬

‫מכיוון שהמספרים הסידוריים של ‪ TCP‬מתייחסים לבתים ברצף המידע כך גם מספרי ה ‪ .ACK‬מספר ה‬

‫‪ ACK‬ב ‪ TCP‬מציין את המספר הסידורי של הבית הבא שמצופה לקבל‪ .‬כך למשל עבור הדוגמה הקודמת‬
 ‫נקבל‬

‫בצורה זו קל מאוד לבצע מעקב אחרי התקשורת‪ .‬מכיוון שה ‪ ACK‬מכיל את המספר הסידורי הבא‪ ,‬הרי‬
‫שזה יהיה המספר הסידורי שיישלח בחבילת המידע הבאה‪ .‬כך בדוגמה זו‪ ,‬רצף החבילות יראה כך‪:‬‬

‫בנוסף‪ ,‬כאשר נשלח ‪ ACK‬ב ‪ ,TCP‬הכוונה היא שכל המידע שהגיע עד לבית שמצוין ב ‪ ACK‬הגיע באופן‬
‫תקין‪ .‬כך לדוגמה‪ ,‬במקרה לעיל השרת יכול היה לא לשלוח ‪ ACK‬עבור החבילה שכללה את המידע ‪Hello‬‬
‫אלא רק לאחר קבלת החבילה שכללה את המידע ‪ .cool‬במקרה זה‪ ,‬ערך ה ‪ ACK‬צריך להיות המספר‬
‫הסידורי הבא ‪.110 -‬‬
 ‫לאחר שליחת החבילות שלו‪ ,‬הלקוח מחכה לזמן מסוים לקבלת ה‪ .ACK‬אם ה ‪ ACK‬לא הגיע עד לתום‬
‫הזמן ‪ .‬הוא שולח אותן מחדש‪.‬‬

‫‪TCP Segmentation‬‬

‫כפי שהסברנו‪ TCP ,‬מחלק את המידע לפי ‪ .bytes‬בפועל הוא מבצע סגמנצייה שגודל של כל סגמנט הוא‬
‫‪ .MSS‬זה הגודל המקסימלי של מידע עבור שכבת האפליקציה שיכול להיות בתוך פקטה‪ ,‬כך ש כאשר‬
‫מוסיפים את כל ה‪ headers‬הדרושים האורך הכולל הוא לכל היותר ‪ MTU‬שזה אומר ‪maximum-‬‬
‫‪ ,transmission unit‬בערך ‪ 1500‬בתים‪.‬‬

‫בדוגמה אפשר לראות ששלחנו בשכבת האפליקציה ‪ 7000‬בתים של מידע‪ .‬כמובן שלשכבת האפליקציה לא‬
‫אכפת מגודל המידע‪ .‬בשכבת התעבורה ‪ tcp‬מחלק את המידע ל‪ 7‬חתיכות של ‪ 1000‬בתים‪ .‬נשים לב ש‬
‫‪ UDP‬היה מאציל את הדרישה הזאת לחלוקה עבור שכבת הרשת‪ .‬אם כן‪ TCP ,‬מחזיר באפר ששומר את‬
‫המידע ומחלק אותו ל‪ segments‬שאת כל אלה עוטף ב ‪ headers‬ומעביר לשכבת הרשת‪.‬‬
 ‫כאשר שכבת האפליקציה שולחת ‪ 3‬פעמים ‪ , data‬הפרוטוקול ‪ , TCP‬משתמש באותו הבאפר כדי לחלק‬
‫את ה‪ data‬בבאפר הזה‪ ,‬יכול להיות מצב ש‪ segment‬אחד מקבל חלקים משני סוגי ‪ data‬אחרים‬
‫שנשלחו‪.‬‬

‫הרציונל הוא שהמידע נשמר ב‪ buffer‬עד שמתקבל בחזרה ‪ ACK‬ואז אפשר לשחרר את הזכרון ולהשתמש‬
‫בו למשהו אחר‪.‬‬

‫לשם כך‪ ,‬משתמשים ב‪ headers‬שהסברנו עליהם למעלה‪.seq num, ack num .‬‬

‫נתבונן על דוגמה מפורטת יותר מההסבר הנ״ל על ‪ echo tcp server‬ונסביר אותה‬
 ‫ראשית נשים לב שבפועל כל אפליקצייה שמתקשרת באמצעות ‪ TCP‬מחזירה ‪ Send buffer‬ו ‪Receive‬‬
‫‪ .buffer‬הראשון הוא המידע שנשלח ואיזה מידע קיבל כבר ‪ .ACK‬השני הוא עבור מידע שהתקבל ואיזה‬
‫מהם דווח עליו ‪.ACK‬‬

‫‪B‬‬ ‫כאשר ‪ A‬שולח את התו ‪ C‬הוא מדווח גם את המספרים ‪ seq=42‬וגם ‪ .ack=79‬הוא בעצם אומר ל‬
‫שהוא עכשיו מדווח על הבית עם המספר הסידורי ‪ 42‬וגם הוא מדווח ל‪ B‬שהוא כבר דיווח ‪ ack‬עד הבית‬
‫ה‪.79‬‬

‫ברגע ש ‪ B‬מקבל את התו‪ ,‬הוא שומר אותו ‪ receive buffer‬וכעת מדווח ‪ ack‬על הביט ה ‪ 43‬כמו כן הוא‬
‫שולח לו בחזרה את התו כי זה שרת אקו ומוסיף אותו ב ‪ send buffer‬אבל המספר הסידורי של ‪ C‬ב באפר‬
‫הזה הוא ‪ 79‬ולכן ‪ ,seq = 79‬כלומר הוא מדווח שהוא שולח את הבית עם המספר הסידורי ‪.79‬‬

‫ניתן בעצם להבין את הסנכרון שיש פה בין ‪ ACK‬לבין ‪ , seq‬הם בעצם נועדו לתת דיווח מהצורה‬
‫״מהו המזהה הבא של הבית הראשון שאני אמור לקבל ממך״ ‪.‬‬

‫‪Info‬‬

‫נשים לב שבסוף נשלח רק מידע של שכבת התעבורה בלי ‪ data‬כי אין עוד ‪ data‬לשלוח‪.‬‬

‫‪Packet timeout‬‬

‫כפי שאמרנו יכול להיות מצב שחבילה הלכה לאיבוד‪ .‬כדי לזהות מצב כזה יש צורך במנגנון מבוסס ‪timer‬‬
‫כדי לקבוע שאם פקטה לא הגיעה בזמן הזה יש לשלוח אותה שוב‪.‬‬

‫לשם כך ‪ tcp‬רוצה לקבוע זמן שגבוה מ )‪ RTT(Round Trip Time‬אבל זה זמן שמשתנה מפקטה‬
‫לפקטה‪.‬‬
 ‫כצירי זמן של כל אחד מהמכשירים‪.‬‬ ‫‪A, B‬‬ ‫נסתכל על‬

‫‪ RT T‬מורכב מכמה חלקים‪:‬‬

‫א‪ .‬השהיית שידור‪ ,‬כלומר הזמן שלוקח לשדר את הביט הראשון עד הביט האחרון בשליחת ‪ .segment‬יש‬
‫אותו גם ב ‪ B‬וגם ב ‪ A‬בגלל שגם ‪ B‬משדר ‪ ACK‬בחזרה‪ .‬זאת פונקציה של כמה ביטים יש לשדר ביחס‬
‫לקצב השידור‪.‬‬

‫ב‪ .‬השהיית התפשטות‪ ,‬כמה זמן לכל לביט בודד להתפשט על גבי הערוץ‪ ,‬לעבור את המרחק ממחשב א׳‬
‫למחשב ב׳‪ .‬אפשר להסתכל על ביט בודד בגלל שההתפשטות נעשת בצורה מקבילית‪ .‬החישוב של זה‬
‫יעשה בעקבות כך‪ ,‬לפי זמן ההתפשטות של הביט האחרון‪ .‬כלומר פשוט נמדוד כמה זמן לקח לביט האחרון‬
‫להיקלט במחשב השני‪.‬‬

‫‪dt‬‬ ‫את שני אלו ביחד נסמן‬

‫ג‪ .‬השהיית השידור של ה‪( ACK‬בשרטוט זה בנקודה קטנה בגלל שזה זמן יחסית קטן ביחד לביטי המידע)‬

‫ד‪ .‬השהיית ההתפשטות של הביט האחרון של ה ‪ACK‬‬

‫‪.‬‬ ‫‪dp‬‬ ‫את שני אלו ביחד נסמן‬

‫סה״כ‪:‬‬

‫‪RT T = dt + dp‬‬

‫‪:Store and forward‬‬

‫ההסבר הנ״ל התעסק בשני מכשירים באותה הרשת‪ .‬כאשר הם ברשת אחרת המצב שונה כיוון שהמידע‬
‫צריך לעבור דרך הראוטר‪ .‬זאת שיטה אחת שבה עובדים רכיבי תקשורות והיא פשוטה‪.‬‬
‫עד שלא מגיע הביט האחרון של החבילה‪ ,‬הוא לא מעביר אותה הלאה ‪ ,‬כלומר נוצר פה רובד נוסף‬
‫שמוסיף ל ‪ , RDT‬אם כי הנוסחה לא משתנה‪ .‬באופן די אינטואיטיבי המשמעות היא שככל שיש יותר רכיבי‬
‫תקשורת בדרך ליעד ככה יעלה זמן ה‪.RTT‬‬
 ‫שערוך ‪RTT‬‬

‫יש צורך לבצע שערוך של ה‪ RTT‬כדי לדעת לאמוד את זמן ה ‪ .timeout‬שכן על כל פקטה צריך לבצע‬
‫שערוך ל ‪ RTT‬הנ״ל לפני שהמידע על ה‪ RTT‬התקבל בפועל‪ .‬נסמן ‪ SampleRT T‬כ ‪ RT T‬האחרון‬
‫שנדגמה‪ .‬נרצה לבצע ממוצע של מספר דגימות כאלה ולבצע שערוך‪.‬‬

‫נגדיר ‪:‬‬

‫‪EstimatedRT T = (1 − α) ⋅ EstimatedRT T + α ⋅ SampleRT T‬‬

‫בעצם מדובר פה במעין ממוצע משוקלל‪ ,‬שככל ש‪ α‬יותר נמוך ככה נותנים יותר משקל להערכות הקודמות‪.‬‬
‫בדרך כלל ‪ . α = 0.125‬כמובן ש ‪ (1 − α) ⋅ EstimatedRT T‬מייצג את ההערכה הקודמת כפול המשקל‬
‫שנותנים לה‪.‬‬

‫ֿ‬

‫ההשפעה של ‪ SampleRTT‬יורדת מדגימה לדגימה‪ ,‬כלומר הנוסחה הזאת לאט לאט משפרת באופן‬
‫אקספוננציאלי את ה ‪ .EstimatedRTT‬הרשת היא תנודתית מאוד ולכן ה ‪ smoothing‬הזה הוא מאוד‬
‫חשוב‪ .‬בגרף ניתן לראות שאין תנודתיות כזאת ב ‪ EstimatedRTT‬וזה טוב לנו כי זה אומר שאנחנו‬
‫שומרים על הממוצע המשוקלל בערך מדגימה לדגימה‪.‬‬

‫בגלל שהסטיות האלה גדולות מאוד נרצה לצמצם את ההפרשים האלה באמצעות חישוב הסטייה‪/‬שונות של‬
‫הממוצע שלנו‪ .‬הנוסחה תייצג את הסטייה בין המדידה להערכה בכל פעם‪.‬‬

‫| ‪DevRT T = (1 − β) ⋅ DevRT T + β ⋅ |SampleRT T − EstimatedRT T‬‬

‫ההפרש מייצג את ההפרש הנוכחי והסטייה בנוסחה היא הסטייה הקודמת שנמדדה‪ .‬ככל שהרשת יציבה‬
‫יותר ככה הסטייה נמוכה יותר ואם הרשת אינה יציבה אז נשתמש בסטייה כדי לתקן את ה‪ timeout‬כפי‬
‫שתיכף נראה‪ .‬בד״כ ‪. β = 0.25‬‬

‫סך הכל נגדיר ש‬

 ‫‪T imout = EstimatedRT T + 4 ⋅ DevRT T‬‬

‫‪Store and forward Efficiency‬‬

‫בשיטת ‪ Store and forward‬יש מצב של חוסר יעילות בגלל ‪.under utilization‬‬
‫הפתרון של זה הוא להשתמש ‪ pipelining‬שמאפשר לנו לשלוח מספר חבילות במקביל‪ .‬זאת שיטה מאוד‬
‫נפוצה שנפוצה מאוד במבנה מחשב ובאופטימיזציה שאילות במסדי נתונים ‪ .‬השיטה מאפשרת באמצעות‬
‫חלוקה של החבילה מראש לחבילות קטנות יותר‪ ,‬לחסוך זמן רב כי הראוטר לא יצטרך לחכות לכל החבילה‬
‫הגדולה אלא רק לחלק קטן שלה‪ .‬מה שיאפשר לשלוח את החבילה ב״מקביל״‪.‬‬

‫חשוב לשים לב שהראוטרים עצמם עדיין עובדים בשיטת ‪ ,Store and Forward‬אבל העובדה‬
‫שאנחנו מחלקים את הפקטות לפקטות קטנות יותר היא זאת שמאפשר את המקביליות‬

‫‪Pipeline‬‬

‫לאחר שהחבילה הראשונה הגיעה אל הראוטר‪ ,‬חבילות אחרות נשלחות בשני הערוצים במקביל‪.‬‬
‫המשמעות היא שלא צריך לספור את הזמן ההתפשטות והשידור בין השרת לראוטר ובין הראוטר לשרת‬
‫בנפרד שכן ‪ ,‬אלו מתרחשים במקביל בשיטת ‪.pipeline‬‬
 ‫בתמונה הנ״ל‪ ,‬זמן השידור של חבילה ‪ 2‬בין השרת לנתב מתרחש במקביל לזמן ההתפשטות של חבילה ‪1‬‬
‫בין בשרת לנתב‪ .‬זמן השידור של חבילה ‪ 1‬בין הנתב ללקוח מתרחש במקביל לשידור של חבילות בערוץ בין‬
‫השרת לנתב וכו׳‪ .‬זאת בניגוד לשיטה של ‪ store and forward‬שבה היינו חייבים להמתין לביט האחרון‬
‫שיגיע לראוטר ‪.‬‬

‫המימוש‪:‬‬
‫נגדיר ‪ window‬להיות מספר החבילות שאפשר לשלוח לפני שמקבלים ‪ ACK‬על אחת מהן‪.‬‬

‫ברגע שמקבלים ‪ ACK‬על החבילה הראשונה אפשר לשלוח את החבילה הראשונה בשלישייה הבאה‪.‬‬

‫‪Warning‬‬

‫הפתרון הזה מייצר לנו בעיה חדשה‪ ,‬כעת אם חבילה נופלת ולא מגיעה‪ ,‬יש צורך גם לעדכן איזה‬
‫חבילה נפלה בדרך (בניגוד ל ‪ hold and wait‬שתמיד ידענו איזה חבילה הלכה לאיבוד בגלל שתמיד‬
‫יש אחת בתנועה ויש עליה ‪.)timeout‬‬

‫ננסה לפתור את הבעיה אך ראשית נבין קצת יותר טוב את מנגנון ה ‪:Slide Window‬‬

‫על כל פקטה בבאפר (בין אם זה ה ‪ send buffer‬ובין אם זה ה ‪ )receive buffer‬נשמור את אחד מה‪states‬‬
‫הבאים‬
‫א‪ .‬האם היא ‪ACKed‬‬
‫ב‪ .‬האם היא נשלחה ועדיין לא קיבלה ‪.ACK‬‬
 ‫ג‪ .‬האם היא ניתנת לשליחה‬
‫ד‪ .‬לא ניתנת לשליחה כרגע‪.‬‬

‫הפרמטרים הללו נקבעים לפי ה ‪ window size‬והבאפרים עליהם דיברנו מקודם‪ .‬ברגע שפקטה אחת מגיעה‬
‫ומדווח עליה ‪ ACK‬החלון יזוז ימינה‪:‬‬

‫‪GBN‬‬

‫אחת השיטות לטיפול בבעיה‪ ,‬היא שיטת ‪ .Go Back N‬בשיטה זאת אנחנו עובדים כפי שתיארנו למעלה‪.‬‬
‫בשיטה זאת נניח שהחלון הוא בגודל ‪ N‬אם אחת הפקטות הלכה לאיבוד ‪ ,‬נניח הפקטה ה‪ , i‬אז כשהפקטה‬
‫ה‪ i + 1‬תתקבל בצד המקבל‪ ,‬הוא יזניח אותה וישלח ‪ ACK‬על הפקטה האחרונה שאנחנו יודעים שהגיעה‬
‫לפי הסדר‪ .‬במצב זה מקבלים ‪ duplicate ACK‬וה‪ window‬לא יזוז‪..‬‬

‫המשמעות של זה היא שעד שה‪ timeout‬על החבילה ה‪ i‬יתקבל נצטרך להזניח את כל החבילות הבאות‬
‫בחלון כלומר ‪ N‬חבילות ורק אחרי שה‪ timeout‬יקרה נשלח את הפקטה ‪ i‬שוב ונתחיל את הרצף מהתחלה‪.‬‬
 ‫‪Selective Repeat‬‬

‫שיטה נוספת לטיפול בבעיה שתיארנו‪.‬‬

‫כאשר הפקטה ה‪ i‬נאבד ומגיעה הפקטה ה‪ i + 1‬אנחנו לא מזניחים אותו‪ .‬אלא שומרים אותו ב‪ Array‬ונשלח‬
‫עליו ‪ .ACK‬באותו אופן על הבאים בתור אחרי ‪ ,i + 1‬נשמור אותם במערך ונדווח עליהם ‪.ACK‬‬
‫ברגע שהפקטה ה‪ i‬קיבלה ‪ timeout‬נשלח אותה שוב‪ ,‬וכשנקבל עליה ‪ ACK‬החלון יזוז לפי גודל המערך‬
‫כלומר לפי כמות הפקטות ששמרנו בצד עד שהתקבל ה‪ .timeout‬כמובן שברגע ש‪ ACK‬מגיע לפקטה ה‪i‬‬

‫מרוקנים את המערך‪.‬‬

‫‪Warning‬‬

‫חשוב לשמור על יחס של קטן ממש בין ה ‪ window size‬ל ‪ seq numbers‬שכן‪ ,‬כיוון שה ‪ seq‬הוא‬
‫מספר סופי וחסום בגודל של ‪ 32‬בתים‪ ,‬אם ה‪ data‬שאנחנו נרצה לשלוח גדול מזה‪ ,‬יהיה ‪wrap‬‬
‫‪ around‬של ה ‪ .seq number‬למשל‪ ,‬אם ]‪ seq = [0, 3‬וה‪ data‬הוא בגודל ‪ 6‬בתים‪ ,‬אז הסדר של‬
‫המזהים של הבתים יהיה מהצורה ‪ . 0, 1, 2, 3, 0, 1, 2‬במצב זה‪ ,‬אם ה‪ window‬גדול מדי יכול להווצר‬
‫מצב שבו המידע התקבל בצד המקבל אבל ה ‪ ACK‬לא הגיע לשולח ובמצב זה הוא ישלח בית‬
‫שהתקבל עם אותו ‪ seq number‬כמו הבית החדש שהצד המקבל ממתין לו‪ .‬הפתרון של זה הוא‬
‫לשמור על ‪size(window) ≤ max(seqN umbers)/2‬‬
 ‫‪TCP Headers‬‬

‫‪TCP 3-way Handshake‬‬

‫אמרנו שבפרוטוקולים מבוססי קישור‪ ,‬יש צורך להקים את הקישור בין הצדדים לפני שלב העברת המידע‬
‫בינהם‪ .‬באמצעות הקמת הקישור‪ ,‬אנו מודיעים לצד השני שאנו מתחילים מולו בתקשורת ושעליו להיות מוכן‬
‫לכך‪ .‬בנוסף‪ ,‬לעיתים יש לתאם פרמטרים בין שני הצדדים בכדי שהקישור יעבוד בצורה יעילה יותר‪.‬‬

‫באופן כללי‪ ,‬הקמת קישור ב ‪ TCP‬נקראת ‪ Three Way Handshake‬ונראת כך ‪:‬‬

‫כפי שניתן לראות‪ ,‬במהלך הרמת הקישור נשלחות שלוש חבילות‪ ,‬בכל אחת מהן גם יש שימוש ב ‪ ack‬ו‬
‫‪.seq‬‬

‫‪SYN‬‬

‫בשלב הראשון‪ ,‬הלקוח שולח לשרת חבילה שמטרתה להתחיל את הקמת הקישור‪ .‬על ידי הדלקת ה‪header‬‬
‫‪ : SYN‬הלקוח מעיד על כוונתו לפתוח קישור‪ .‬ה ‪ seq‬המצורף נקרא ‪ ISN- initial sequence number‬והוא‬
‫נבחר באופן רנדומלי כדי למנוע התנגשויות של חיבורים‪ ,‬אם כל החיבורים היו מתחילים אם מזהה ‪ 0‬למשל‪,‬‬
‫אז אם חיבור כלשהו ייפול תוך כדי שפקטה עם מספר סידורי כלשהו תהיה בדרך היא עלולה להגיע לחיבור‬
‫אחר שיוקם תוך כדי וגם הוא יהיה עם המזהה ‪ .0‬כדי למנוע מקרים כאלו מתקבל מספר רנדומלי כ‪.ISN‬‬

‫כמו כן נשים לב ש ‪ ACK‬כבוי כי לא ניתן ‪ ACK‬על אף חבילה קודמת (זאת הראשונה)‪.‬‬

‫‪SYN+ACK‬‬

‫בשלב זה‪ ,‬אם השרת הסכים לקישור הראשוני הוא עונה בחבילה בה דלוקים שני הדגלים ‪ SYN :‬ו ‪.ACK‬‬
‫הדגל ‪ SYN‬דלוק כי זאת חבילה שמובילה על הקמת הקישור‪ .‬הדגל ‪ ACK‬דלוק מכיוון שהשרת מודיע‬
‫ללקוח שהוא קיבל את החבילה הקודמת שהוא שלח‪ ,‬שהיא חבילת ה ‪.SYN‬‬

‫ה‪ seq‬של החבילה של השרת יהיה ‪ ISN‬של התקשורת בינו לבין הלקוח וגם הוא ייבחר באופן אקראי‪ .‬זאת‬
‫כמובן שתקשורת היא דו כיוונית ונעשת בשני ‪ Streams‬של מידע ‪ ,‬רצף בתים ללקוח ורצף בתים לשרת‪.‬‬

‫לסיום על השרת לציין את מספר ה ‪ ACK‬כדי להודיע ללקוח שהוא קיבל את החבילה שלו‪ ,‬כפי שהוא עושה‬
‫גם במצב רגיל‪ .‬כלומר הערך של ה ‪ ACK‬יהיה לפי הבית הבא שהשרת מצפה לקבל מהלקוח שבמקרה‬
‫הזה הוא ‪( 1‬כי זה מה שהתקבל מהדגל ‪ )SYN‬בתוספת הערך הראשוני של ‪ seq‬נסמנו ‪ x‬ולכן‬
‫‪. ACK = x + 1‬‬

‫‪ACK‬‬

‫על מנת שהחיבור יוקם בהצלחה הלקוח צריך לדווח לשרת שהחבילה ‪ SYN+ACK‬התקבלה בהצלחה‬
‫וששני הצדדים מסונכרנים על המספרים הסידוריים הראשוניים אחד של השני‪.‬‬

‫כדי לבצע זאת‪ ,‬הלקוח שולח חבילה כשדגל ה ‪ ACK‬דולק‪ ,‬ומספר ה ‪ ACK‬מציין את הבית הבא שהוא‬
‫מצפה לקבל מהשרת‪ .‬כלומר המספר הסידורי ‪( 1 +‬בידיוק כמו מקודם)‪ .‬הפעם הדגל ‪ SYN‬כבוי‪ ,‬שכן זו‬
‫כבר לא החבילה הראשונה שנשלחת מהלקוח לשרת בקישור הנוכחי‪ .‬כמו כן ה‪ seq‬של החבילה הנשלחת‬
‫יהיה הערך שהיה ב ‪ ack‬בחבילה שהתקבלה מהשרת‪..‬‬
 ‫סך הכל אם נתאר את כל התהליך מהתחלה עד לסיום זה יראה כמו בדיאגרמה הבאה‪:‬‬

‫‪TCP Connection Termination‬‬

‫ישלח דלוק עם ‪seq number‬‬ ‫‪F IN‬‬ ‫כאשר נרצה לסגור את החיבור באמצעות ‪ socket.close‬הדגל‬
‫רלוונטי לפי הפעולות שהתבצעו קודם לכן‪.‬‬

‫הצד שמאשר את הסגירה של החיבור שולח כמובן ‪ ACK‬ו ‪. ACKnum‬‬

‫דלוק‪.‬‬ ‫‪F IN‬‬ ‫צד זה עדיין יכול להמשיך לשלוח מידע וברגע שהוא יסיים הוא ישלח בעצמו את הדגל‬

‫‪TCP Retransmission‬‬
‫ישנם כל מיני מקרי קצה ש ‪ TCP‬צריך להתמודד איתם כדי שיתאפשר לשלוח את המידע לפי הסדר‪ .‬כך‬
‫למשל יכול להיות מצב שהמידע ממחשב א׳ יגיע למחשב ב׳ אבל ה ‪ ACK‬עבור המידע זה יפול בדרך ונקבל‬
 ‫‪ .Timeout‬במצב זה אנחנו יודעים שמחשב א׳ שולח שוב את המידע בציפייה לקבל את ה‪ ACK‬למרות‬
‫שמחשב ב׳ כבר קיבל אותו ודיווח (כאן נכנס לתמונה ה ‪ SEQ‬שמאפשר לצד המקבל לדעת שהוא לא קיבל‬
‫מידע חדש)‪.‬‬

‫נשים לב שאם נפל ה ‪ ACK‬ולפני שהתקבל ‪ TIMEOUT‬על החבילה כבר נשלח ‪ ACK‬על החבילה הבאה‬
‫(כי עובדים בשיטת ‪ )Pipeline‬אז בגלל שה ‪ ACK‬הוא מצטבר המחשב השולח ידע שהוא לא צריך לשלוח‬
‫את החבילה שוב ויכול לשלוח את החבילה הבאה‪.‬‬
‫תרחיש נוסף שיכול לקרות הוא שהשערוך ‪ Timeout‬היה נמוך מדי ולכן יתקבל ‪ timeout‬על חבילה לפני‬
‫שה‪ ACK‬עליה נשלח‪ .‬במצב זה שוב פעם נשלח את החבילה פעם נוספת‪ ,‬אבל ‪ ,‬בגלל ש‪ ACK‬כפי‬
‫שאמרנו הוא ערך מצטבר ולא פר חבילה אנחנו פשוט נשלח את ה‪ ACK‬עם הערך הרלוונטי שוב‪.‬‬
 ‫נשים לב שהצד השולח שומר את ה ‪ ACK‬שהוא קיבל עד לרגע הנוכחי במשתנה ‪.SendBase‬‬

‫‪ACK Events‬‬
‫‪ TCP‬שואף לשלוח כמה שיותר חבילות מידע ולצמצם את חבילות ה ‪ . ACK‬במצב זה ‪ TCP‬משתמש‬
‫בכמה מנגנונים לפי המאורעות השונים שנמצאים בצד המקבל של המידע‪.‬‬

‫למשל‪:‬‬
‫א) אם המידע מגיע כמו שצריך לצד השולח ‪ TCP‬משתמש במנגנון של ‪ delay‬על ‪ .ACK‬כלומר הוא מחכה‬
‫ורק אם במהלך הדיליי לא התקבל שום חבילה חדשה הוא שולח את אותו ‪.ACK‬‬

‫ב) במידה והגיעה חבילה חדשה בזמן הזה הוא מגיע לאירוע ‪ 2‬בטבלה למטה ושולח את ה ‪ ACK‬המצטבר‬
‫עבור שניהם‪.‬‬

‫ג) אם יש מצב שבו מגיע מידע עם ‪ seq‬שלא תואם את המספר ‪ seq‬שהצד המקבל מצפה לו הוא ישלח‬
‫‪ ACK‬נוסף (לא מצטבר) עבור הפקטה הרלוונטית האחרונה שנשלחה לפי הסדר‪.‬‬

‫ד) המאורע האחרון שמצוין בטבלה הוא כאשר מגיעה חבילה שסוגרת איזשהו חור שנוצר בין ה‪ seq‬של‬
‫החבילות השונות שהתקבלו‪ .‬במצב זה שולחים ‪ ACK‬על המספר הכי נמוך שממנו יש חור ואם אין כזה‬
‫שולחים ‪ ACK‬על מספר הבתים שהתקבלו עד כה‪.‬‬
 ‫‪TCP Fast Retransmit‬‬
‫זה מנגנון שנועד להעריך שחבילה הלכה לאיבוד לפני שהתקבל עליה ‪ .Timeout‬המנגנון משתמש בטכניקת‬
‫ה ‪ duplicate ACK‬שציינו מקודם‪ .‬במצב שבו מגיעות יותר מ‪ 3‬חבילות שהן ‪ out of order‬בגלל חבילה‬
‫ספציפית אז ‪ TCP‬מיד ישלח אותה שוב ולא יחכה ל ‪ .timeout‬כפי שאמרנו אנחנו שולחים ‪ ack‬כפול‬
‫ומצפים לקבל את החבילה אבל חבילות אחרות מתקבלות והיא עדיין לא מגיעה‪.‬‬
 ‫‪TCP Flow Control‬‬
‫עד כה התייחסנו ל ‪ window‬כגודל סטטי שלא יכול להשתנות‪.‬‬
‫החלונות השונים ש ‪ TCP‬מנהל‪ ,‬בפועל הם דינמיים וגודלם משתנה בהתאם לתקשורת‪.‬‬

‫החלון הראשון הוא חלון בקרת הזרימה‪:‬‬

 ‫חלון זה שומר את ה ‪ data‬ב ‪ buffer‬ומחכה ששכבת האפליקצייה תשלוף אותו‪ .‬כאשר אין מקום בבאפר‬
‫הצד המקבל צריך לתאם את זה עם הצד השולח כדי שלא יגרום ל ‪ overflow‬ולנפילת חבילות בעקבות כך‪.‬‬

‫‪ TCP‬עושה את זה באמצעות ה‪ header‬שנקרא ‪. received window‬‬

 ‫‪ TCP‬ישלח את ‪ rwnd‬שזה הגודל הפנוי בבאפר לצד השולח וכך הוא ידע האם אפשר להמשיך להזרים‬
‫עוד מידע או לא‪.‬‬

‫הניהול של זה ברמת ‪ TCP‬הוא יחסית פשוט‪.‬‬

‫כפי שאמרנו אם יש מידע בגודל מסויים ‪ TCP‬מחלק אותו לפקטות לפי ה ‪ MSS‬ומתחיל תהליך של ‪three‬‬
‫‪.way handshake‬‬
‫במהלך התהליך הזה הצד השולח יקבל את הגודל של ה‪ rwnd‬וישמור אותו בפרמטר שנקרא ‪send‬‬
‫‪ .window‬נחזיק שני מצביעים ‪ LBA‬ו ‪ LBS‬שזה ה ‪ last byte ack‬ו ‪ last byte sent‬שכן אמרנו שה ‪ seq‬וה‬
‫‪ ack‬מתקבלים ונשלחים ברמת הבתים‪.‬‬
‫קל להבין למה הנוסחה )‪ data we can send = send window - (LBS-LBA‬מתאימה לנו שכן אנחנו יכולים‬
‫לשלוח חבילות בהתאם למגבלת החלון וגם בהתאם לכמה בתים לא קיבלנו עליהם ‪ .ack‬אם ההפרש הוא ‪0‬‬

‫זה אומר שההפרש בין המצביעים הוא בידיוק כגודל הפנוי של הבאפר‪.‬‬

‫‪Congestion Control‬‬
‫חלון בקרת הרשת נועד לטפל במצבים שבהם יש עומס על הרשת בכמות המידע ובמהירות שבו הוא נשלח‪.‬‬
‫מצב כזה שלא יטופל עלול לגרום לנפילת פקטות ולזמני שהייה ארוכים כדי לצאת מהתור של הראוטר‬

‫לחלון בקרת הרשת יש כמה מטרות‬

‫א) יעילות‪ -‬להעביר הכי הרבה מידע שהוא יכול‬
‫ב) לא לשלוח יותר מדי מידע וליצור עומס‬
‫ג) הקצאת משאבים באופן שווה בין המקורות השונים‪.‬‬
‫ד) דינמי‬
‫ה) מנגנון טיפול במצב של עומס‬

‫כדי להבין את ‪ TCP‬מטפל בזה צריך להגדיר מספר מצבים‬

‫‪slow start‬‬
 ‫כאשר החיבור מתחיל‪ ,‬נגדיר באופן מעריכי את קצב שליחת הפקטות עד שנקבל מאורע של איבוד מידע‪.‬‬

‫ומגדילים את ‪ cwnd‬ב ‪ 1‬כל ‪ ACK‬שמתקבל‪.‬‬ ‫‪cwnd = 1M SS‬‬ ‫מתחילים מזה ש ה‬

‫‪AIMD‬‬

‫‪ Additive Increase Multiplicative Decrease‬הוא מנגנון למניעת עומס כאשר עובדים בשיטה הקודמת‪.‬‬

‫השיטה הזאת עובדת בהגדלה ליניארית של ב ‪ .cwnd‬כלומר במקום להגדיל ב ‪ 1‬את החלון כל ‪ACK‬‬
‫שמתקבל מה שיגרום לכך שבכל ‪ RTT‬נגדיר את החלון בגודל אקספוננציאלי ביחס להגדלה הקודמת‪.‬‬
‫הפעם מגדילים ב ‪ 1‬לכל ‪ RTT‬בלבד‪ .‬למשל אם ה ‪ RTT‬הוא ‪ 1ms‬אז כל פרק זמן זה נגדיל את החלון ב‪1‬‬

‫‪ ,‬זה גורם לכל שב ‪ RTT‬ה‪ i‬נשלח ‪ i‬פקטות במקום ‪ 2‬פקטות‪.‬‬

‫‪i‬‬

‫את המנגנון הזה עושים עד שמזהים איבוד מידע‪ .‬ברגע שמזהים אבדה מקטינים בחצי את ה ‪.cwnd‬‬
 ‫המעבר בין ‪ slow start‬ל ‪ AIMD‬נעשה באמצעות פרמטר שנקרא‪:‬‬
‫‪ .SST- Slow Start Threshold‬כאשר כמות הפקטות שאפשר לשלוח ברגע נתון מגיעה לערך של ה‪SST‬‬
‫נעבור ל ‪.AIMD‬‬

‫בכל פעם שמתקבל ‪ lost‬יש שני דרכים לטפל‪:‬‬

‫א) מקטינים את ‪ cwnd‬להיות ‪ 1‬ומקטינים את ה ‪ SST‬להיות חצי מ‪ cwnd‬לפני ההקטנה‪ .‬עובדים בשיטת‬
‫‪ slow start‬עד שמגיעים שוב ל ‪ .ssthresh‬ככה זה עובד ב ‪( TCP Tahoe‬גרסה מסויימת של הפרוטוקול)‪.‬‬
‫בגרסה זאת ההתנהגות הזאת נכונה לכל סוגי האובדנים‪ .‬החסרון פה הוא שמצב של ‪ ACK‬כפול (כפי‬
‫שאמרנו ‪ 3‬פעמים ‪ ACK‬כפול גורם לשליחה מידית של החבילה פעם נוספת)‬
‫מעיד על כך שהרשת לא בהכרח כזאת עמוסה שצריך להוריד את ה‪ cwnd‬ל ‪ 1‬שוב‪.‬‬

‫ב) אם האובדן הוא כתוצאה מ ‪ Timeout‬ההתנהגות היה כמו בסעיף א‪ .‬אם האובדן הוא במצב של ‪ACK‬‬
‫כפול אז נקטין גם את ה ‪ cwnd‬וגם את ה ‪ sst‬להיות חצי מ ‪ .cwnd‬וממשיכים לעבור ב ‪ .AIMD‬בגדרת‬
‫‪ TCP Reno‬עובדים בשיטה הזו‪.‬‬

‫‪Fast Recovery‬‬

‫המנגנון הזה נועד למנוע מצב שאין חבילות באוויר כי מחכים ליותר מדי ‪ ACK‬כפולים‪.‬‬
 ‫מצב זה יכול לקרות אם החבילה הראשונה מבין כל החבילות שיכלנו לשלוח בהתאם ל‪ cwnd‬הלכה לאיבוד‪.‬‬
‫זה אומר שעל כל החבילות הבאות אנחנו אמורים לקבל ‪ ACK‬כפול על החבילה הזאת‪ .‬כפי שאמרנו‬
‫בחבילה השלישית אנחנו מקטינים את החלון בחצי וכעת צריך לחכות ל ‪ ACK‬המצטבר על כל החבילות כדי‬
‫להמשיך לשלוח חבילות חדשות ‪ Fast Recovery .‬מונע את זה בשיטה פשוטה‪ :‬על כל ‪ ACK‬כפול הוא‬
‫מגדיל את ה ‪ cwnd‬באחד‪ .‬כלומר אם התקבלו ‪ ACK 3‬כפולים אנחנו נקטין את החלון בחצי כפי שאמרנו‬
‫ונוסיף לו ‪ .3‬על כל ‪ ACK‬כפול נוסף נגדיר ב‪ 1‬את החלון‪ .‬הרעיון פה הוא שאנחנו כבר יודעים שנקבל ‪ACK‬‬
‫כפולים למרות ששלחנו כבר את החבילה ברגע שהגיעו רק ‪ 3‬ושאין צורך לחכות לכולם כדי להמשיך לשלוח‬
‫סגמנטים חדשים‪.‬‬

‫דוגמאות‬

‫תחת ההנחה שאין ‪ fast recovery‬נרצה למצוא את פרקי הזמן שבהם ‪ TCP‬נמצא ב ‪ slow start‬וב‬
‫‪congestion avoidance‬‬
‫נשים לב שיש שני צירי ‪ x‬שאחד מהם זה הסיבובי שליחה והשני זה ה‪( cwnd size‬מציג בצורה מדויקת את‬
‫ציר ה ‪)y‬‬

‫קל לראות זאת פשוט מחפשים היכן הגידול הוא מעריכי והיכן הגידול הוא ליניארי‪ .‬לפי ציר הזמן זה בעצם‬
‫מ ‪ 1 − 6‬ומ ‪ 23 − 26‬מדובר ב‪ ss‬וב ‪ 6 − 16‬וגם ‪ 17 − 22‬מדובר ב ‪ .ca‬כמו כן אפשר לראות שהאובדן‬
‫בסיבוב ‪ 16‬מתרחש בגלל ‪ ack 3‬כפולים והאובדן בסיבוב ‪ 23‬קרה בגלל ‪.timeout‬‬
‫נתונים נוספים שאפשר להוציא מהגרף הוא שערך ה ‪ tts‬ההתחלתי הוא ‪ , 32‬בסיבוב מספר ‪ 18‬ערכו הוא‬
‫‪ 21‬והחל מסיבוב ‪ 23‬ערכו הוא ‪.13‬‬

‫השהיות‬
‫אחת הדרכים להשוות בין פרוטוקולים של שכבת התעבורה היא מדידה של זמנים כאשר מריצים את אותם‬
‫התרחישים בשני הפרוטוקולים ומדידת הזמן שעבר בכל פרוטוקול‪.‬‬

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

‫נעזר בהגדרות שהשתמשנו בהם קודם ‪:‬‬

‫קצב שידור‪ :‬כמה ביטים בשניה ניתן לשדר? (‪)bps‬‬

‫קצת התפשטות‪ :‬כמה מטרים בשניה מצליח לעבור האות (‪)mps‬‬
 ‫נגדיר‬

‫‪dE2E = dtran + dprop + dq + dproc‬‬

‫מתקיים‪:‬‬
‫‪ d‬כאשר ‪ L‬זה כמות הביטים ו ‪ R‬זה קצב השידור בשנייה‪.‬‬ ‫=‬ ‫‪ )a‬השהיית השידור היא‬
‫‪tran‬‬
‫‪L‬‬

‫‪R‬‬

‫‪d‬‬ ‫=‬ ‫‪ )b‬השהיית ההתפשטות היא‬

‫‪prop‬‬
‫‪d‬‬

‫‪s‬‬

‫‪ -‬כמה זמן לוקח לביט בודד לעבור מרחק של ‪ d‬מטרים בקצב התפשטות של ‪ s‬מטרים בשנייה‪.‬‬
‫‪ d )c‬היא השהיית התור‬ ‫‪q‬‬

‫‪ -‬כמה זמן חבילה ממתינה בתור לפני שהיא משודרת הלאה‪ .‬נשים לב שהשהייה זו היא פונקציה של קצב‬
‫השידור של הנתב אל הערוץ וכמות החבילות בתור‪.‬‬
‫‪ d‬היא השהיית העיבוד‬ ‫‪)d‬‬ ‫‪proc‬‬

‫‪ -‬כמה זמן לוקח לטפל בחבילה ולהעביר אותה אל התור המתאים‪.‬‬

‫תזכורת‬

‫‪1B = 8b‬‬

‫‪3‬‬
‫‪1KB = 10 B‬‬

‫‪6‬‬
‫‪1M B = 10 B‬‬

‫‪9‬‬
‫‪1GB = 10 B‬‬

‫שאלה ‪1‬‬

‫לקוח הממוקם בניו יורק ניגש לשרת הממוקם בלונדון כדי להוריד קובץ‪ .‬נתון שהמרחק מהלקוח לשרת הוא‬
‫‪ , 2500KM‬קצב ההתפשטות הוא ‪ , 250, 000km/s‬קצב השידור הוא ‪ 8M bps‬וגודל הקובץ הוא ‪.1M B‬‬

‫כמה זמן יקח להעביר את הקובץ מהשרת ללקוח‪ ,‬בהנחה שאין עוד תעבורה ורשת ואין השהיית עיבוד‬
‫‪.d‬‬ ‫כלומר ‪= d = 0‬‬ ‫‪proc‬‬ ‫‪q‬‬

‫‪ ,‬עם הנתונים שחישבנו נוכל לקבל אותם ‪:‬‬ ‫‪dE2E = dt + dp‬‬ ‫אם כן ‪ ,‬מתקיים ש‬
‫‪6‬‬

‫= ‪dp‬‬
‫‪d‬‬

‫‪s‬‬
‫=‬
‫‪2500‬‬

‫‪250,000‬‬
‫‪= 0.01sec‬‬ ‫כמו כן מתקיים ש‬ ‫= ‪dt‬‬
‫‪L‬‬

‫‪R‬‬
‫=‬
‫‪1M B‬‬

‫‪8M bs‬‬
‫=‬
‫‪8⋅10 b‬‬
‫‪6‬‬
‫‪8⋅10 b‬‬
‫‪= 1sec‬‬
 ‫‪ .d‬נשים לב שחשוב להמיר את היחידות מידה כפי שעשינו‪ ,‬כי‬ ‫סך הכל נקבל ‪= 0.01 + 1 = 1.01s‬‬
‫‪E2E‬‬

‫בדוגמה שלנו מדובר ב ‪ byte per second‬אל מול ‪.bits per seconds‬‬

‫שאלה ‪ - 2‬השהיות בשיטת ‪store and forward‬‬

‫נניח כי הראוטר עובד בשיטת ‪ store and forward‬כלומר רק כאשר הביט האחרון מגיע לראוטר הוא שולח‬
‫אותו ללקוח‪.‬‬

‫אם כן מתקיים ‪:‬‬

‫‪dE2E = dtransS→R + dpropS→R + dtransR→C + dpropR→C‬‬

‫ברגע שמבינים כיצד הנוסחה השתנתה העבודה היא בידיוק כמו בשאלה הקודמת‪ ,‬הצבה בנוסחה וחישוב‬

‫‪L‬‬ ‫‪1M B‬‬

‫= ‪dtransS→R‬‬ ‫=‬ ‫‪= 1‬‬
‫‪R‬‬ ‫‪8M bs‬‬

‫‪d‬‬ ‫‪5000km‬‬
‫= ‪dpropS→R‬‬ ‫=‬ ‫‪= 0.02sec‬‬
‫‪km‬‬
‫‪s‬‬ ‫‪250, 000‬‬
‫‪s‬‬

‫‪6‬‬
‫‪L‬‬ ‫‪1M B‬‬ ‫‪8 ⋅ 10 b‬‬
‫= ‪dtransR→C‬‬ ‫=‬ ‫=‬ ‫‪= 10sec‬‬
‫‪kb‬‬ ‫‪3 b‬‬
‫‪R‬‬ ‫‪800‬‬ ‫‪800 ⋅ 10‬‬
‫‪s‬‬ ‫‪s‬‬

‫‪d‬‬ ‫‪250km‬‬ ‫‪−3‬‬

‫= ‪dpropR→C‬‬ ‫=‬ ‫‪= 10‬‬ ‫‪sec‬‬
‫‪km‬‬
‫‪s‬‬ ‫‪250, 000‬‬
‫‪s‬‬

‫‪.‬‬ ‫‪dE2E = 1 + 0.02 + 10 + 10‬‬

‫‪−3‬‬
‫‪= 11.021sec‬‬ ‫מציבים ומקבלים‬
 ‫השהיות בשיטת ‪Pipeline‬‬

‫‪ . d‬כאשר‪:‬‬‫‪E2E‬‬
‫במצב זה מתקיים ‪= d + d + d‬‬
‫‪1‬‬ ‫‪2‬‬ ‫‪3‬‬

‫‪ d )a‬סך כל ההשהיות שלוקח לחבילה הראשונה עד שהיא מגיעה לערוץ האיטי ביותר‪.‬‬ ‫‪1‬‬

‫‪ d )b‬סך כל ההשהיות בערוץ האיטי ביותר‬

‫‪2‬‬

‫‪ d )c‬היא סך כל ההשהיות שלוקח לחבילה האחרונה עד שהיא מגיעה ליעד‬ ‫‪3‬‬

‫נסתכל על הדוגמה למעלה שבה רוצים להעביר פקטה בשיטת ‪ pipeline‬שמחלקת את הפקטות ל‪ 4‬פקטות‬
‫קטנות‪.‬‬

‫להגיע לראוטר בשידור‬ ‫‪0.5sec‬‬‫בשלב הראשון אפשר לראות שאנחנו שולחים את הפקטות ולכל אחת לוקח‬
‫ובהתפשטות של ‪ 1sec‬כלומר הביט האחרון של פקטה יוצא אחרי שניה אחת‪.‬‬

‫נשים לב שבשידור השלישי יהיה לנו צוואר בקבוק שכן‪ ,‬זמן השידור שם איטי יותר ולכן פקטות אחרות‬
‫יצטרכו לחכות ברגע שהן מגיעות עד שהן יוכלו לצאת‪.‬‬
 ‫נשים לב שהיכן שהשהיית השידור איטית ביותר‪ ,‬הזמן של כל השידורים האחרים נכלל בתוכו‬

‫בשלב האחרון אפשר לראות שלמרות שהרמה שם מהירה יותר מהקודמת עדיין קצת השידור הוא כמו של‬
‫קצב השידור האיטי ביותר‪ .‬לכן ברמה האחרונה הדבר היחיד שקובע זה הזמן שלקח לפקטה האחרונה‬
‫להגיע‪.‬‬
 ‫שאלה ‪3‬‬

‫הבחנה‪ :‬הקובץ מגיע מהשרת ולכן המסלול הוא שרת‪>-‬נתב‪>-‬לקוח‬

‫‪6‬‬

‫‪.1M B = 8 ⋅ 10‬‬ ‫‪6‬‬

‫→ ‪b‬‬
‫‪8⋅10 b‬‬
‫‪4‬‬
‫‪8⋅10 b‬‬
‫חישוב זריז יראה שאנחנו שולחים‬
‫‪= 100packets‬‬

‫כעת‪ ,‬נמצא את הערוץ הכי איטי‬

‫‪.‬‬ ‫‪800kbps‬‬ ‫‪ -‬הערוץ בין הלקוח לראוטר הוא הערוץ עם קצב השידור האיטי ביותר‬

‫לכן צריך לחשב‪:‬‬

‫‪ .1‬כמה זמן לוקח עד שהחבילה הראשונה מגיעה לנתב‬
‫‪ .2‬כמה זמן לוקח עד שהמידע עובר בערוץ בין הנתב ללקוח‬

‫נחשב כמה זמן לקח לחבילה הראשונה עד שהגיעה לערוץ האיטי ביותר‪,‬‬
‫נקבל ש‬
‫‪4‬‬ ‫‪6‬‬
‫‪8⋅10‬‬ ‫‪5⋅10‬‬ ‫‪−2‬‬
‫= ‪dt + dp‬‬ ‫‪6‬‬
‫‪+‬‬ ‫‪8‬‬
‫‪= 3 ⋅ 10‬‬ ‫‪sec‬‬
‫‪8⋅10‬‬ ‫‪2.5⋅10‬‬
‫‪4‬‬

‫‪.‬‬ ‫⋅ ‪dt = 100‬‬

‫‪8⋅10‬‬

‫‪8⋅10‬‬
‫‪5‬‬
‫‪= 10sec‬‬ ‫כעת‪ ,‬נחשב כמה זמן לוקח לשדר את כל החבילות בערוץ הכי איטי‬
‫לסיום‪ ,‬נחשב את ההתפשטות של חבילה בודדת בערוץ האיטי‬
‫‪5‬‬
‫‪2.5⋅10‬‬ ‫‪−3‬‬
‫= ‪dp‬‬ ‫‪8‬‬
‫‪= 10‬‬ ‫‪sec‬‬
‫‪2.5⋅10‬‬

‫‪10sec‬‬ ‫‪ .‬נשים לב שלא חסכנו הרבה זמן בגלל הערוץ האיטי שהוסיף לנו‬ ‫‪10.031‬‬ ‫נסכום ונקבל‬

‫‪Info‬‬

‫לכאורה כדאי פשוט לשלוח את המידע בחבילות בגודל של ביט בודד כי אנחנו נדרשים לחכות פחות‬
‫עבור הפקטה הראשונה‪ ,‬כלומר ככל שיש יותר פקטות קטנות נראה כי הקנס על התעבורה עד לטווח‬
‫האיטי קטנה משמעותית‬
 ‫אבל זה לא באמת המצב ‪ ,‬מהסיבה השפוטה שלכל פקטה ששולחים מתווספים ‪ headers‬והמחיר של‬
‫זה יכול להיות כבד בהתאם לגודל ה ‪ .header‬למשל אם חילקנו ל ‪ 100‬חבילות בפועל אנחנו מחשבים‬
‫את זמן השידור של ‪ 101‬חבילות כי מסתכלים על זמן השידור של החבילה הראשונה עד שהיא מגיעה‬
‫לערוץ האיטי ביותר ואז מסתכלים על כל החבילות בערוץ האיטי ביותר‪ .‬אם נגדיר שלכל חבילה כזאת‬
‫יש גם ‪ header‬בגודל ‪ 40B‬נקבל שכאשר נוסיף את זמן השידור של התחיליות עצמן בנוסף למה‬
‫⋅ ‪ 1‬אם מוסיפים את ה‪ 40‬מילישניות האלה‬ ‫שחישבנו נקבל ‪= 40.04ms :‬‬
‫‪40B‬‬ ‫‪40B‬‬
‫⋅ ‪+ 100‬‬ ‫‪6‬‬ ‫‪5‬‬
‫‪8⋅10 bps‬‬ ‫‪8⋅10 bps‬‬

‫‪10000‬‬ ‫נקבל ‪ 10.07104‬זמן שלא משנה בצורה חסרת תקדים את הזמן הקודם‪ .‬אבל אם נחלק ל‬
‫חבילות נקבל שהתקורה על העברת התחיליות הוא ‪ 4.00004s‬שזה זמן משמעותי מאוד ונקבל זמן‬
‫גדול בהרבה (באזור ‪.)14‬‬

‫השהיית תור‬

‫נתבונן בדוגמה הבאה‪:‬‬

‫מחשבים ‪ A, B‬שולחים חבילות למחשב ‪ D‬דרך נתב ‪ . R‬כאשר חבילה מ ‪ A‬מגיעה ל ‪ R‬יש כבר ‪ 3‬חבילות‬
‫מ ‪ B‬שממתינות בבאפר ועוד חצי חבילה שמשודרת ל ‪.D‬‬
‫נוסיף גם שהתור בנתב עובד בצורת ‪ FIFO‬וכל החבילות הן בגודל ‪ 1000B‬עם קצב שידור של ‪. 1M bps‬‬

‫נרצה לחשב את השהיית התור עבור החבילה של ‪.A‬‬

‫צריכה לחכות שכל החבילות שלפניה ישודרו כלומר‪:‬‬ ‫‪A‬‬ ‫החבילה שהגיעה מ‬
‫‪3‬‬
‫‪3.5 ⋅ 10 B‬‬
‫= ‪dq‬‬ ‫‪= 0.028sec‬‬
‫‪6‬‬
‫‪10 bps‬‬

‫כלומר אנחנו יודעים בקלות לחשב השהיית תור לפקטה מסוימת ‪ ,‬רק צריך לחשב את זמן השידור של‬
‫הפקטות שנמצאות לפניה בתור‪.‬‬

‫נסתכל על עוד דוגמה‪:‬‬

‫אם ‪ A, B‬שולחים כל אחד ל ‪ D‬קובץ ‪ 10M b‬דרך נתב ‪.C‬‬
‫‪1KB‬‬ ‫נתון שקצב השידור הוא ‪ 10M bps‬ו ‪ . d = 1ms = 10 sec‬כמו כן‪ ,‬גודל החבילה המקסימלית הוא‬
‫‪p‬‬
‫‪−3‬‬

‫ושניתן להתעלם מתחיליות‪.‬‬

‫נרצה להבין כמה זמן לוקח עד ששני הקבצים מגיעים וגם מהו גודל התור המינימלי כדי שלא יאבדו חבילות‪.‬‬

‫‪10M b‬‬
‫‪10KB‬‬
‫ראשית נבין מהו המספר המינימלי של חבילות שיש לשלוח‪:‬‬
‫‪= 1250‬‬

‫נשים לב שמשך הזמן הכולל הוא החל מתחילת שידור החבילה הראשונה (שני המחשבים מתחילים באותו‬
‫זמן) ועד שהחבילה האחרונה מגיעה ל ‪ .D‬הזמן שלוקח לשדר חבילה אחת ‪:‬‬
 ‫‪3‬‬
‫‪L‬‬ ‫‪1KB‬‬ ‫‪8⋅10 b‬‬
‫= ‪dt‬‬ ‫=‬ ‫=‬ ‫‪7‬‬
‫‪= 0.0008sec‬‬
‫‪R‬‬ ‫‪10M bps‬‬ ‫‪10 bps‬‬

‫סך הכל אנחנו נשדר מ ‪ C‬ל ‪ D‬בידיוק ‪ 2501‬חבילות כי יש את התקורה של החבילה הראשונה שאמורה‬
‫להגיע לנתב לפני שהוא מתחיל לשדר‪ .‬כמו כן יש לקחת בחשבון את ‪ 2‬השהיות ההתפשטות גם של‬
‫החבילה הראשונה עד שהיא מגיע לנתב וגם של החבילה האחרונה עד שהיא מגיע ל ‪ .D‬סך הכל‬
‫‪−3‬‬
‫‪dE2E = 2501dt + 2dp = 2501 ⋅ 0.0008 + 2 ⋅ 10‬‬ ‫‪= 2.0028s‬‬

‫כעת כדי לקבוע מהו גודל הבאפר המינימלי‪:‬‬

‫כיוון שקצב השידור בכל הערוצים שווה‪ ,‬בזמן ש ‪ C‬מספיק לשדר חבילה אחת הוא קיבל שתי חבילות‬
‫חדשות‪ .‬לכן‪ ,‬אם הוא קיבל ‪ 20M b‬אזי הוא מספיק בזמן הזה להעביר חצי מזה והשאר מחכה בבאפר‪,‬‬
‫כלומר גודל הבאפר צריך להיות ‪.10M b‬‬

‫‪Packet Fragmentation‬‬
‫כאשר חבילה מגיעה לרכיב תקשורת והיא גדולה מדי עבור הערוץ שאנחנו צריכים להעביר אותו אליה‪,‬‬
‫אנחנו מבצעים פרגמנטציה‪ .‬כלומר‪ ,‬מחלקים את החבילה לתתי חבילות בכדי שיוכלו לעבור בערוץ הצר‬
‫יותר‪ .‬נשים לב‪ ,‬פרגמנטציה יכולה להתבצע הרבה פעמים לאורך המסלול אבל הרכבה מתבצעת אך ורק‬
‫אצל הצד המקבל‪.‬‬
‫‪ TCP‬מנסה להמנע מפרגמנטציה על ידי סגמנטציה‪ .‬עם זאת‪ UDP ,‬למשל‪ ,‬חשוף לפרגמנטציה‪.‬‬

‫יש לנו ‪ datagram‬בשכבת הרשת בגודל ‪ 4000‬בתים‪ ,‬אם נוריד את ה‪ header‬זה יוצא ‪ 3980‬בתים‪ .‬ה‬
‫‪ MTU‬הוא ‪ 1500‬בתים ואם נוריד את ה‪ ip header‬זה אומר שבפרגמנטצייה נוכל להעביר כל פעם מידע‬
‫בגודל ‪.1480‬‬

‫ההרכבה של הפרגמנטים נעשים לפי ה‪ offset‬בשכבת הרשת במכשיר היעד הסופי‪ ,‬רק אם כולם הגיעו זה‬
‫זה בונה את המידע ומעביר את זה לשכבת התעבורה‪.‬‬

‫נסביר את הדגלים‪:‬‬
‫‪ - fragFlag‬דגל שקובע שיש עוד פרגמנטים אחריי לפי סדר החלוקה ולא סדר ההגעה‪.‬‬

‫‪ -ID‬מזהה שמאפשר לדעת שכל הפרגמנטים קשורים לאותו ‪data‬‬

 ‫‪ -offset‬השדה ‪ 13( Fragment Offset‬בתים) משמש לציון מיקום ההתחלה של הנתונים בפרגמנט ביחס‬
‫לתחילת הנתונים בחבילה המקורית‪ .‬מידע זה משמש להרכבה מחדש של הנתונים מכל הפרגמנטים (בין‬
‫אם הם מגיעים בסדר ובין אם לא)‪ .‬בפרגמנט הראשון ההיסט הוא ‪ 0‬שכן הנתונים בחבילה זו מתחילים‬
‫באותו מקום כמו הנתונים בחבילה המקורית (בהתחלה)‪ .‬בפרגמנטים הבאים‪ ,‬הערך הוא ההיסט של‬
‫הנתונים שהפרגמנט מכיל מתחילת הנתונים בפרגמנט הראשון (היסט ‪ ,)0‬ב‪ 8-‬בתים 'בלוקים'‪ .‬אם מנה‬
‫המכילה ‪ 800‬בתים של נתונים מפוצלת לשני מקטעים שווים הנושאים ‪ 400‬בתים של נתונים‪ ,‬היסט‬
‫הפרגמנט של הפרגמנט הראשון הוא ‪ ,0‬של הפרגמנט השני ‪ .)400/8( 50‬ערך ההיסט חייב להיות המספר‬
‫של בלוקים של ‪ 8‬בתים של נתונים‪ ,‬כלומר הנתונים בפרגמנט הקודם חייבים להיות כפולה של ‪ 8‬בתים‪.‬‬
‫הקטע האחרון יכול לשאת נתונים שאינם כפולה של ‪ 8‬בתים מכיוון שלא יהיה קטע נוסף עם היסט שחייב‬
‫לעמוד ב'כלל' זה‪.‬‬

‫הפעולה הזאת מבוצעת ב‪ ,Network Layer‬הפרגמנטציה נעשית בעקבות ‪ datagram size‬שגדול יותר מה‬
‫‪ MTU‬של הערוץ שבו המידע אמור לעבור‪ .‬שכבת התעבורה מנסה לטפל בזה (לפחות אם משתמשים ב‬
‫‪ ,)TCP‬לכן חשוב להכיר את התהליך הזה כבר בשכבה הזו‪.‬‬

‫ניתן לראות בתמונה שבעצם מתבצע שכפול של כלל ה ‪ headers‬לתתי הפקטת‪ .‬כמו כן ניתן לראות שיש‬
‫‪ payload‬שמתווסף ל‪ headers‬כתוצאה מהחלוקה הזאת‪ .‬למשל ‪ offset‬של המידע ‪ fragflag‬שקובע האם יש‬
‫עוד פרגמנטים בדרך‪.‬‬

‫‪Path MTU Discovery‬‬

‫לקוחות יודעים את ה ‪ MTU‬של הערוץ שלהם‪ .‬לקוחות שאיתם יש תקשורת יודעים לדווח על ה ‪ MTU‬של‬
‫הערוץ שלהם‪ .‬אבל‪ ,‬המסלול מורכב מערוצים נוספים שם ה ‪ MTU‬יכול להיות שונה‪.‬‬

‫‪ TCP‬מנסה להמנע מפרגמנטציה לאורך המסלול באמצעות ‪ Path MTU Discovery‬שעובד בצורה הבאה‪:‬‬
‫א) שולחים חבילה‪ ,‬ע״פ מגבלות הגודל הידועות‪ ,‬כאשר הדגל ‪ Dont fragment‬דולק‪.‬‬
‫ב) כאשר החבילה תגיע לערוץ בו ה ‪ MTU‬קטן מהחבילה‪ ,‬במקום פרגמנטציה‪ ,‬תשלח בחזרה הודעת‬
‫הודעת שגיאה בעזרת הפרוטוקול ‪ ICMP‬שאומרת שהחבילה גדולה מדי‪ ,‬ומה צריך להיות גודל החבילה‬
‫המקס׳‪.‬‬
‫ג) השולח יעדכן בהתאם את גודל ה ‪ MSS‬וה ‪ MTU‬וישלח בהתאם‪.‬‬
‫ד) במידה וגודל זה עדיין גדול מדי לערוצים אחרים במסלול‪ ,‬חוזרים חלילה‪.‬‬

‫דוגמה‪:‬‬
 ‫הערוץ האיטי הוא בין שני הנתבים ולכן ערוץ זה הוא זה שמכתיב את הקצב בו החבילות יתקבלו אצל‬
‫המקבל‪.‬‬

‫בגלל שהביט ‪ do not frag‬כבוי אז המידע יעבור פרגמנטייה בערוץ בין שני הנתבים‪ .‬הראוטר האמצעי‬
‫מקבל ‪ 1530B‬אבל ה ‪ MTU‬שלו הוא ‪.530B‬‬

‫לכן הוא לוקח את את ה‪ 1530‬מחסיר מהם ‪ 20‬של ‪ header IP‬וקיבלנו ‪ .1510‬בגלל שה ‪ MTU‬הוא ‪530‬‬
‫נגדיר פרגמנט בגודל ‪ 510‬ונוסיף לו ‪ 20‬בתים של תחילית ‪ IP‬כדי לקבל את הפרגמנט הראשון‪ .‬גם את‬
‫הפרגמנט הבא נעשה באותה צורה וכעת עבור הפרגמנט האחרון נשאר לנו ‪ 490‬בתים של מידע ‪20 +‬‬
‫בתים של תחילים שכבת הרשת (‪ )ip‬נקבל ‪ 510‬בתים‪.‬‬
 ‫כעת לשאלה השנייה‪ ,‬נניח שההסתברות לכך שהנתב השני זורק כל חבילה שמגיעה היא ‪.p‬‬

‫ההסתברות שהדגימה הראשונה תגיע בהצלחה ליישום של בוב היא ההסתברות שכל שלושת הפרגמנטים‬
‫יגיעו לבוב ויורכבו בהצלחה בשכבת האפליקציה‪ .‬כלומר אסור לאף פרגמנט ליפול בדרך ולכן ההסתברות‬
‫)‪. (1 − p‬‬ ‫‪3‬‬

‫היחס בין גודל החלון וקצב השידור‬

‫(הנוסחה‬ ‫‪W ⋅L‬‬

‫‪R‬‬
‫‪? RT T‬‬ ‫נרצה להבין את היחס בין גודל החלון שמשדרים וקצב השידור לבין ‪ RTT‬כלומר‪:‬‬
‫הזאת בעצם מהווה את זמן השידור של חלון אחד)‪.‬‬

‫אז סיימנו לשדר לפני שהגיע ‪ ack‬ולכן אנחנו מחכים ולא משדרים עד שיגיע‬ ‫‪W ⋅L‬‬

‫‪R‬‬
‫‪< RT T‬‬ ‫‪ )a‬אם מתקיים‬
‫ה ‪. ack‬‬

‫ניתן לראות שכאשר מצב זה מתקיים ישנו זמן מת (המשולש באדום) עד שניתן לשלוח את החלון הבא‪.‬‬

‫אזי ה ‪ ack‬על החבילה הראשונה מגיע תוך כדי שידור החלון‪ ,‬ולכן כאשר‬ ‫‪ )b‬אם מתקיים ‪> RT T‬‬
‫‪W ⋅L‬‬

‫‪R‬‬

‫אנחנו מסיימים לשדר את החלון הראשון ניתן מיד להתחיל לשדר את החלון השני באופן רצוף ללא בזבוז‬
‫זמן מת‪.‬‬
 ‫כאשר היחס גדול יותר ניתן לראות שמתקבל ‪ ack‬על החבילה הראשונה לפני שסיימנו לשדר‪.‬‬

‫מה קורה במספר ערוצים?‬

‫כאשר יש יותר מערוץ אחד הקצב האמיתי נקבע על ידי הערוץ האיטי ביותר‪ ,‬אי אפשר לשדר יותר ממהר‬
‫ממנו כי אם כן היינו עושים זאת אנחנו נגרום לחבילות בנתב שלו לחכות בתור ‪ ,‬מה שיגרום ל ‪ RTT‬שלהם‬
‫לגדול ולגדול‪.‬‬

‫כלומר‪ ,‬החל מאיזה חלון ה ‪ RTT‬כבר לא גדול יותר מזמן השידור של החלון‪ .‬עם זאת‪ ,‬מכיוון שה‪ RTT‬מכין‬
‫בתוכו את זמן השידור של החבילה הראשונה‪ ,‬אם חיבור ה‪ TCP‬מתחיל מחלון בגודל חבילה אחת‪ ,‬בחלון‬
‫הראשון תמיד ה ‪ RTT‬יהיה גדול יותר מזמן השידור של החלון‪.‬‬

‫החל מאיזה חלון ה‪ RTT‬כבר לא גדול יותר מזמן השידור של החלון?‬

‫חבילות‪ .‬למשל בחלון ה‬ ‫‪2‬‬

‫‪i−1‬‬
‫נשים לב שכשאשר אנחנו ב ‪ Slow start‬אנחנו משדרים בחלון ה ‪ i‬כמות של‬
‫‪ 1‬משדרים חבילה אחת ובחלון ה ‪ 3‬משדרים ‪ 4‬חבילות וכן הלאה‪.‬‬

‫נרצה אם למצוא את ה‪ i‬שיקיים‬

‫‪i−1‬‬
‫‪2‬‬ ‫‪⋅ dtran ≥ RT T‬‬

‫כאשר באי שיוויון זה הנעלם היחיד הוא ‪ i‬כי ניתן יהיה לחשב את השהיית השידור ואת ה ‪ .RTT‬עד החלון‬
‫‪.‬‬ ‫‪WL‬‬

‫‪R‬‬
‫והחל מהחלון ה ‪ i‬משדרים לפי ‪> RT T‬‬ ‫ה ‪ i‬אנחנו משדרים לפי ‪< RT T‬‬
‫‪WL‬‬

‫‪R‬‬

‫דוגמה‪:‬‬
‫חבילות‪ ,‬כאשר החבילה האחרונה אינה מלאה והיא בגודל ‪. 820B‬‬ ‫נרצה לשלוח ‪= 83.56 ∼ 84‬‬
‫‪122000‬‬

‫‪1500−40‬‬

‫משך הזמן שלוקח לשלוח חבילה אחת‬

‫‪1460B + 40B‬‬
‫= ‪dt + dp‬‬ ‫‪+ 12ms = 13ms‬‬
‫‪12M bps‬‬

‫משך הזמן שלוקח לשלוח את החבילה האחרונה הוא‬

‫‪820B + 40B‬‬
‫= ‪dt + dp‬‬ ‫‪+ 12ms = 12.573ms‬‬
‫‪12M bps‬‬

‫משך הזמן שלוקח לשלוח ‪: ack‬‬

‫‪40B‬‬
‫= ‪dt + dp‬‬ ‫‪+ 12ms = 12.027ms‬‬
‫‪12M bps‬‬

‫סך הכל קיבלנו‬

‫‪RT T = 13ms + 12.027ms = 25.027ms‬‬

‫‪RT Tlast = 12.573ms + 12.027ms = 24.6ms‬‬

‫ב ‪ stop and wait‬ייקח לנו‬

‫‪83 ⋅ 25.027ms + 24.6ms = 2.101841 sec‬‬

‫כי שולחים את החבילה הבאה רק כאשר ה ‪ ack‬מגיע על החבילה‬ ‫‪WL‬‬

‫‪R‬‬
‫‪< RT T‬‬ ‫נשים לב שכאן ברור ש‬
‫הקודמת‪.‬‬

‫במצב זה כבר יש לבדוק את היחס בין שידור החלון לבין ה‪RTT‬‬

‫‪WL‬‬ ‫‪8 ⋅ 1500B‬‬

‫=‬ ‫‪= 8ms‬‬
‫‪R‬‬ ‫‪12M bps‬‬

‫לכן‪:‬‬ ‫‪WL‬‬

‫‪R‬‬
‫‪< RT T‬‬ ‫מתקיים ש‬
 ‫‪1460B + 40B‬‬ ‫‪820B + 40B‬‬
‫⋅ ‪11 ⋅ RT T + 2‬‬ ‫‪+‬‬ ‫‪= 0.2779‬‬
‫‪12M bps‬‬ ‫‪12M bps‬‬

‫הסיבה ששמנו ‪ 11‬היא בגלל שהיחס הנ״ל הוא > אז מתקיים שנשלח ‪ 10‬סיבובים מלאים של ‪ 8‬חבילות‬
‫בנפרד ועוד סיבוב אחד של ‪ 4‬חבילות (לא משפיע על ה ‪ RTT‬שנמדד לפי החבילה הראשונה)‪ .‬לאחר‬
‫החישוב הזה מוסיפים את זמן השידור של כל החבילות בחלון האחרון חוץ מהחבילה הראשונה שנספרה‬
‫ב‪ RTT‬ה ‪ . 11‬החבילה האחרונה נזכיר היא קטנה יותר משאר החבילות‪.‬‬

‫‪Silly Window Syndrome‬‬

‫האפליקציה עלולה לקרוא בקצב איטי ביחס לקצב שבו המידע מגיע למחשב (אם כי‪ ,‬חלון בקרת הזרימה‬
‫תוודא שלא ישלחו יותר מידע מגודל הזכרון בכדי שלא יזרק)‪.‬‬

‫הבעיה כאן היא שעלולה להיווצר תופעה בה כמות המידע ששולחים בכל חבילה הולכת וקטנה והולכת‬
‫וקטנה מה שגורם לכך שאנחנו שולחים הרבה מאוד תחיליות‪.‬‬

‫בעיה דומה יכולה להתרחש בכיוון ההפוך‪ ,‬כאשר האפליקציה בצד השולח‪ ,‬שולחת הרבה מידע אבל‬
‫בחתיכות קטנות (אם ‪ TCP‬יחכה הוא יוכל לחבר חתיכות קטנות לחבילה אחת במקום חבילות נפרדות)‪.‬‬

‫הדרכים למניעת התרחיש הן‪:‬‬

‫המקבל לא יפרסם חלון קטן מדי‪ .‬למשל‪ ,‬גודל החלון שהוא מפרסם יהיה לפחות ‪ MSS‬אחד‪.‬‬
‫‪ -‬אם גודל החלון קטן מכך‪ ,‬המקבל יפרסם חלון בגודל ‪.0‬‬
‫‪ -‬השולח יקבל את החלון בגודל ‪ 0‬מה שימנע שליחה של חבילות קטנות מדי‪.‬‬
‫‪ -‬כאשר המקבל יפנה מקום בבאפר הוא ישלח ‪ ack‬עם גודל חלון עדכני מה שיאפשר לשולח להמשיך‬
‫לשלוח‪.‬‬
‫‪ -‬אפשר לבצע ‪ probing‬בצד השליחה‪ ,‬כלומר בצד השולח ניזום שליחה של מידע קטן אם עבר זמן מאז‬
‫שקיבלנו גודל חלון עדכני ( קורה אחרי הרבה זמן שגודל החלון היה ‪.)0‬‬

‫בצד השולח‪ ,‬נשתמש באלגוריתם ‪Nagle‬‬

‫‪ -‬אם אין מידע שמחכים ל ‪ ack‬עליו‪ ,‬שלח את המידע שהאפליקצייה ביקשה‪.‬‬
‫‪ -‬אם יש מידע שמחכים ל‪ ack‬עליו נעכב בקשות שליחה של האפליקציה אם הן קטנות מדי עד שנקבל את‬
‫ה ‪ ack‬או עד שיצטבר מספיק מידע‪ ,‬כלומר בגודל של לפחות ‪. MSS‬‬
‫נשים לב שהאלגוריתם הזה לא עובד טוב עם ‪.delayed ack algorithm‬‬

‫דוגמה‪:‬‬
‫במקרה הכללי ‪ ,‬אם הקצב שבו מגיע המידע הוא ‪ R‬והקצב שבו קוראת האפליקציה מהבאפר הוא ‪ O‬וגודל‬
‫‪.‬‬‫‪W‬‬

‫‪1−‬‬
‫הבאפר בפועל הוא ‪ W‬אזי הנוסחה עבור גודל החלון ה אגרסיבי אותו ניתן לפרסם היא‬
‫‪O‬‬

‫‪R‬‬

‫נשים לב שהעיקר פה הוא השהיית ההתפשטות ולכן גם אן נתעלם משאר ההשהיות נקבל שאם השולח‬
‫ישלח מידע בגודל הבאפר וימתין עד לקבלת תשובה‪ ,‬נקבל שקצב העברת המידע הוא‬
‫‪.‬‬ ‫=‬
‫‪200000B‬‬
‫‪= 500KBps‬‬
‫‪RT T‬‬
‫‪200000B‬‬

‫‪0.4s‬‬

‫‪ .1‬המקבל יכול לפרסם חלון גדול יותר מהגודל הבאפר שיש לו בפועל‪ .‬פרסום שכזה יאפשר למידע‬
‫להגיע מהר יותר‪ ,‬למרות שאין גודל בפאר לכאורה מתאים‪ ,‬האפליקציה מרוקנת כל הזמן את הבאפר‬
‫ומפנה מקום‪ .‬למשל‪ ,‬אם המקבל יפרסם חלון בגודל ‪ 400000‬אז הקצב יגדל ל ‪.1MBps‬‬
‫‪.‬‬ ‫‪ .‬גודל חלון כזה יתן לנו קצב של‬ ‫‪ .2‬נציב בנוסחה‬
‫‪6‬‬
‫‪10‬‬ ‫‪200000B‬‬ ‫‪6‬‬
‫‪= 2.5M Bps‬‬ ‫‪8M bps‬‬
‫‪= 10 B‬‬
‫‪0.4‬‬
‫‪1−‬‬
‫‪10M bps‬‬
 ‫שכבת האפליקציה‬
‫שכבת היישום (באנגלית‪ )Application :‬נקראת גם‪ :‬שכבת התוכנה או שכבת האפליקציה‪ .‬היא השכבה‬
‫השביעית והעליונה של מודל ה‪ OSI-‬והחמישית במודל ‪ .TCP/IP‬היא ממונה על אספקת שירותי הרשת‬
‫לתוכנות בהן משתמש משתמש הקצה‪ .‬שכבת היישום משתמשת בשירותיה של שכבת הייצוג של מודל ה‪-‬‬
‫‪ OSI‬ואינה מספקת שירותים לאף שכבה אחרת במודל ה‪.OSI-‬‬

‫שכבת היישום היא זו הקובעת את סוג התקשורת בין מחשבים‪ .‬למשל‪ ,‬היא קובעת האם מדובר בתקשורת‬
‫"שרת–לקוח" (‪ )client-server‬שבה מחשב אחד (השרת) מספק נתונים לאחר (הלקוח) ‪ -‬כמו בגלישה‬
‫באינטרנט‪ ,‬או שמדובר בתקשורת "קצה לקצה" (‪ ,)peer to peer‬שבה כל אחד מהמחשבים הוא גם שרת‬
‫וגם לקוח ‪ -‬כמו ברשתות שיתוף קבצים‪.‬‬

‫‪DHCP‬‬
‫)‪ Dynamic Host Configuration Protocol (DHCP‬הוא פרוטוקול ‪ client/server‬שמספק באופן‬
‫אוטומטי ודינמי‪ ,‬את הכתובת ‪ IP‬של ‪ host‬כאשר הוא מתחבר לרשת בפעם הראשונה‪.‬‬

‫באופן כללי הפרוטוקול עובד באופן הבא‪:‬‬

‫א) שליחת ‪ broadcast‬מסוג ‪DHCP discover‬‬
‫ב) שרת ה ‪ DHCP‬מגיב עם ‪DHCP offer‬‬
‫ג) ה‪ host‬מבקש כתוב ‪ IP‬עם ‪DHCP request‬‬
‫ד) השרת שולח את הכתובת ו ‪DHCP ack‬‬

‫שרת ה ‪ DHCP‬מביא מידע קונפיגורטיבי נוסף חוץ מה ‪ IP‬שמוקצה לרשת החדשה‪.‬‬

‫א‪ .‬הכתובת של הראוטר הראשון שקופצים אליו מחוץ לרשת המקומית במידה וצריך‪.‬‬
‫ב‪ .‬שם וכתובת של שרת ה‪DNS‬‬
‫ג‪ network mask .‬שגם עליה נדבר בהמשך‪.‬‬
 ‫‪ DHCP‬עובד בפרוטוקול ‪ UDP‬ולכן הוא ‪ connectionless‬לכן צריך להצמיד מזהה להודעה כדי שמי‬
‫שמקבל את ההודעה ידע שהיא רלוונטית אליו בשכבת האפליקצייה‪.‬‬

‫כי הוא לא מוקצה‪.‬‬ ‫‪0.0.0.0‬‬ ‫ניתן לראות שבשליחת ברשה ראשונית ה ‪ source IP‬הוא עדיין‬

‫השרת שולח תגובת ‪ Offer‬ב ‪ Broadcast‬עם המזהה הספציפי שדיברנו עליו מקודם והכתובת ‪ IP‬המוקצת‪.‬‬

‫ברגע שה‪ host‬מחליט להסכים לקבל את ה ‪ IP‬הוא מבקש גם מידע נוסף‬

 ‫הבחנה‬

‫ההודעת ‪ Offer‬בדוגמה למעלה הייתה ב ‪ broadcast‬אבל היא גם יכולה להשלח בבקשת ‪. Unicast‬‬
‫במצב זה השרת שולח בקשה ל ‪ IP‬שהוא עוד לא הקצה למחשב החדש שהתחבר‬

‫הבחנה‬

‫אם קיימים שרתי ‪ DHCP‬ברשת המקומית בעלי כתובת פנויה לחלוקה‪ ,‬הלקוח יקבל חבילת ‪ offer‬עם‬
‫כתובת ‪ IP‬מכל אחד מהם (בהנחה שאין חסימה של מעבר חבילות ‪ DHCP‬בין השרת ללקוח‪ ,‬למשל‬
‫על ידי חומת אש)‪.‬‬

‫‪DNS‬‬
‫מחשבים מתקשרים זה עם זה באמצעות ‪ IP‬אך רוב הגולשים לא מודעים לקיומן בכלל‪.‬‬
‫כדי להפוך את הגלישה לנוחה‪ ,‬לכל אתר מוצמד שם דומיין שהוא שם מילולי ומייצג את הכתובת‪ .‬לשם כך‬
‫הוגדר הפרוטוקול ‪ DNS‬שרץ על ‪ .UDP‬הפרוטוקול מהווה מעין ״ספר טלפונים״‪ .‬הדפדפן מאחורי הקלעים‬
 ‫על כל דומיין פונה לשרת ה ‪ DNS‬כדי לקבל את הכתובת ה ‪.IP‬‬

‫מבנה של שמות דומיין מזכיר עץ ‪ ,‬הסיומות בשם הדומיין מייצגות את סדר הפניה לשרתי ‪ DNS‬מהסוף‬
‫להתחלה‪ .‬נדגים על ‪: cyber.org.il‬‬
‫א) בגזע של שמות ה‪ domain‬נמצא שרת ‪ DNS‬בשם ‪ -Root‬הוא שומר את כתובת ה ‪ IP‬המשמשים רק ב‬
‫‪ top level domains‬למשל סיומות של מדינות ‪ il, uk‬וסיומות כמו ‪.com‬‬
‫ב) בשלב הבא מתבצעת הפנייה אל שרת ה ‪ DNS‬האחראי על סיומות ‪ il‬ממנו מתפצלים ענפים נוספים כמו‬
‫‪org. il‬‬

‫ומבקש את הכתובת של‬ ‫‪org. il‬‬ ‫ג) בשלב האחרון מתבצעת פנייה לשרת ‪ DNS‬שהשורש שלו הוא‬
‫‪. cyber.org.il‬‬
 ‫שרתי ה ‪:Root‬‬
‫יש כ ‪ 13‬שרתי ‪ root‬לוגיים (של חברות רשת מסויימות שהשרתי ‪ root‬הפיזיים שלהם מפוזרים בכל מיני‬
‫מקומות)‪.‬‬

‫שינוי בהגדרות שרת ‪DNS‬‬

‫בהגדרות הרשת של המחשב מוגדר לנו לאיזה שרת ‪ DNS‬לפנות כאשר אנחנו רוצים לקבל כתובת‬
‫של דומיין מסוים‪ .‬אלו הגדרות שמוזנות באופן אוטומטי דרך הראוטר אבל נתנות לשינוי או להגדיר‬
‫באופן ידני את כתובת ה ‪ IP‬של השרת ‪ DNS‬שנרצה לפנות אליו‬

‫‪DNS Resolver‬‬
‫ה‪ resolver‬היא התוכנה שפותרת שאילתות ‪.DNS‬‬
‫מההסבר שהבאנו למעלה‪ ,‬אפשר להניח שמשיכת כתובת ‪ IP‬היא תהליך ארוך שיכול לעבור בכמה וכמה‬
‫שרתים‪ .‬כדי לייעל את התהליך הזה ישנם שני פתרונות‬

‫א‪ .‬שימוש ב ‪ Cache‬כדי להכיל מיפוי לכתובות שכבר חיפשנו כדי לא לחפש אותם שוב‪.‬‬
‫ב‪ .‬פרוטוקול ‪ DHCP‬יביא כתובת לשרת ‪ DNS‬של הרשת המקומית (לרוב זה יהיה הראוטר) והמטמון ישב‬
‫שם‪ .‬היתרון בזה הוא שהמטמון משותף בין כל ה‪ hosts‬ברשת המקומית ויש שיתופיות של כתובות ‪,‬‬
‫‪ resolver‬אחד ישתף המון לקוחות‪.‬‬

‫ה ‪ Resolver‬עובד בצורה חצי איטרטיבית וחצי רקורסיבית‪ ,‬הבקשה עולה לשרת ה ‪ DNS‬המתאים ומשם‬
‫הולכים לפי העץ‪ ,‬תחילה פונים ל ‪ root‬שמחזיר את הכתובת הבאה של השרת שעלינו לשאול אותו (במקום‬
‫שהוא יעשה זאת וככה יורד ממנו עומס) השרת ‪ DNS‬המקומי שלנו מכאן ממשיך לשאול בתורות את‬
‫השרתים שחוזרים עד שמתקבלת תשובה כפי שמתואר בתרשים הבא‬
 ‫הריקורסיה באה לידי ביטוי בכך שיכול להיות שגם השרתים עצמם יצטרכו לעבור תהליך דומה‪.‬‬

‫בעצם הבעיה שחסכנו בשיטה זאת היא ‪ heavy load‬על השרתי ‪ root‬כפי שהיה קורה אם היינו עובדים‬
‫בשיטה ריקורסיבית מלאה ‪:‬‬
 ‫שדות ‪DNS‬‬

‫כפי שאמרנו ניתן לראות שהחבילה נשלחת בשכבת האפליקציה מעל ‪.UDP‬‬
‫א) בצהוב ניתן לראות את ה ‪ Transaction ID‬שאמרנו שהוא נפוץ מעל ‪UDP‬‬
‫ב) השדה בכחול הוא ‪ flags‬ששדה זה מורכב משמונה דגלים בעלי משמעויות שונות‪ ,‬הדגל הנ״ל מציים‬
‫שמדובר בשאילתה סטנדרטיץ‬
‫ג) ‪ RR- Resource Records‬בירוק זה מידע שמתאר כמה רשומות מכילה חבילת ה ‪.DNS‬‬
‫ד) השאלתה עצמה בסוף של הבקשה מכילות ‪ Name,Type‬ו ‪ Class‬כאשר האחרון מתאר את סוג הרשת‬
‫בד״כ יהיה רשום ‪.IN‬‬
 ‫ב‪ Response‬אפשר לראות שגם התווסף תשובת ‪ Answers‬וב ‪ RR‬אפשר לראות שעבור שאלה אחת יש‬
‫חמש רשומות תשובה‪ .‬הסיבה לכך היא שלפעמים כתובת דומיין אחת מצביעה לכמה כתובות ‪ IP‬וכך אם‬
‫שרת אחד נפל יש שכפולים‪.‬‬

‫ברשומה של שאילתה יש את השדרות הטריוויאלים אבל נשים לב שיש גם ‪ ttl‬ששדה זה קובע כמה זמן יש‬
‫לשמור את הרשומה ב‪.Cache‬‬

‫כאשר מידע נוסף מועיל‬ ‫)‪RR = (name, type, ttl, addr‬‬ ‫באופן כללי רשומת ‪ DNS‬היא רביעייה מהצורה‬
‫אבל לא הכרחי‪.‬‬

‫ה ‪ type‬מתחלק ל‪: 4‬‬

 ‫הרשמת ‪ Domain‬חדש‬
‫כאשר אנחנו מרימים ‪ domain‬חדש צריך לרשום אותו ב ‪.DNS registrar‬‬
‫כאשר רושמים אותו מייצרים לו גם ‪ Name Server‬רלוונטי שיודע להחזיר את ה ‪ IP‬הרלוונטי ל ‪. domain‬‬
‫בעצם ה‪ registrar‬מייצר שני ‪ RRs‬חדשים ל ‪ Top Level Domain Server‬של ‪. com‬‬

‫הראשון הוא המיפוי בין ה‪ domain‬ל ‪ NS‬הרלוונטי‪ ,‬השני הוא הכתובת ‪ IP‬של ה‪NS‬‬

‫כל רשומה כזאת נשמרת ב‪ cache‬ל‪ TTL‬זמן כפי שאמרנו‪.‬‬

‫‪DNS Redirection‬‬
‫טכניקה שנועדה לפזר עומס על שרתים‪ .‬בהינתן ‪ Domain‬מסויים‪ ,‬יהיו מספר העתקים שלנו כאשר לכל‬
‫אחד יש ‪ IP‬שונה‪ .‬שרת ה ‪ DNS‬מחזיר כתובת ‪ IP‬שונה לצורך פיזור העומס‪ ,‬באמצעות אלגוריתם ‪Round‬‬
‫‪.Robin‬‬
 ‫‪HTTP‬‬
‫‪ .Hyper-Text Transfer Protocol‬פרוטוקול זה מאפשר לאפליקציות לגשת ולעשות שימוש במשאבי‬
‫האינטרנט (תמונות‪ ,‬קבצים וכו׳)‪ .‬בפרוטוקול זה כתובת ה ‪ URL‬היא מרכיב הכרחי כדי לקבוע מהו המשאב‬
‫הרלוונטי שאנחנו רוצים למשוך‬

‫‪ HTTP‬עובד בעקרון של בקשה ותגובה כלומר הלקוח שולח בקשה לשרת וכאשר היא מתקבלת‪ ,‬השרת‬
‫ישלח תגובה‪ .‬בתקשורת ‪ HTTP‬השרת לא יוזם שיח עם הלקוח‪.‬‬
 ‫כמו כן חשוב לציין ש ‪ HTTP‬רץ על ‪. TCP‬‬

‫גרסאות ‪HTTP‬‬
‫ישנם מספר גרסאות ל ‪ HTTP‬שחשוב להכיר‪:‬‬

‫‪:Non-persistent‬‬
‫על גבי חיבור ‪ TCP‬בודד ניתן לקבל משאב אחד ואז החיבור נסגר‪.‬‬

‫‪:Persistent‬‬
‫כמה וכמה בקשות ניתנו לביצוע פר חיבור ‪ TCP‬בודד‪.‬‬

‫‪:Pipelining‬‬
‫ניתן לשלוח מספר בקשות ‪ HTTP‬לפני שמתקבלת עליהן תשובה על אותו החיבור ‪.‬‬

‫‪Format‬‬
‫יש שני סוגי הודעות ל ‪ :Http‬הודעת ‪ request‬והודעת ‪. response‬‬
‫שני הבקשות עוברות בקידוד ‪. ASCII‬‬
 ‫בקשת ‪ request‬נראת המצורה‪:‬‬

‫בסוף הם אינדיקצייה לכך שהסתיימו ה‪ headers‬בבקשת ‪.http‬‬ ‫‪/r/n‬‬ ‫נשים לב שה‬

‫ה‪ response‬נראה מהצורה‪:‬‬

 ‫‪Http Request‬‬
‫‪Start line‬‬

‫בקשות ‪ HTTP‬הן הודעות שנשלחות על ידי הלקוח כדי ליזום פעולה בשרת‪ .‬קו ההתחלה שלהם מכיל‬
‫שלושה אלמנטים‪:‬‬
‫‪HTTP method‬‬
‫מתאר איזה פעולה הבקשה רוצה לעשות‪:‬‬
‫‪ - GET‬מבקשת לקבל משאב מסויים‪.‬‬
‫‪ - HEAD‬מבקשת את אותה תגובה כמו בקשת ה ‪ GET‬רק בלי ה ‪.body‬‬
‫‪ - POST‬שליחה של יישות עבור משאב מסויים במערכת‪ ,‬לעתים זאת משנה את ה ‪ state‬שלו או משפיעה‬
‫על השרת‪.‬‬
‫‪ - DELETE‬מחיקה של משאב מסויים‪.‬‬
‫‪- PUT‬החלפה של משאב מסויים בתוכן הבקשה‪.‬‬
‫‪ - PATCH‬ביצוע מודיפיקציה של משאב בשרת‪.‬‬

‫‪Request target‬‬
‫בדרך כלל זה ‪ URL‬או נתיב אבסולוטי שמכיל בתוכו ‪ ,queries‬פורט וכו׳‪.‬‬
‫בעצם זה יכול להיות כל נתיב שהוא בעצם מורכב מהמבנה המלא של ‪URL‬‬

‫‪HTTP version‬‬
‫הגרסה קובעת את המבנה של שאר ההודעה וגם כדי לדעת כיצד לבנות את התגובה‪.‬‬

‫‪Headers‬‬
 ‫כותרות ‪ HTTP‬מייצרות בקשה תחת אותו מבנה בסיסי של ‪ :Header HTTP‬מחרוזת לא תלוית רישיות‬
‫ואחריה נקודתיים ('‪ )':‬וערך שהמבנה שלו תלוי ב‪ .Header‬הכותרת כולה‪ ,‬כולל הערך‪ ,‬מורכבת משורה‬
‫אחת בודדת‪ ,‬שיכולה להיות ארוכה למדי‪.‬‬

‫זה סוג של ‪ metadata‬על הבקשה‪.‬‬

‫‪Body‬‬

‫החלק האחרון של הבקשה הוא הגוף שלה‪ .‬לא לכל הבקשות יש אחת‪ :‬בקשות שמביאות משאבים‪ ,‬כמו‬
‫‪ GET, HEAD, DELETE‬או ‪ ,OPTIONS‬בדרך כלל אינן זקוקות למשאבים כאלה‪ .‬חלק מהבקשות‬
‫שולחות נתונים לשרת על מנת לעדכן אותם‪ :‬כפי שקורה לעתים קרובות בבקשות ‪( POST‬המכילות נתוני‬
‫טופס ‪.)HTML‬‬

‫‪HTTP Response‬‬
‫כפי שאמרנו המבנה הוא דומה ל‪.Request‬‬

‫‪Status line‬‬
‫שורת ההתחלה של תגובת ‪ ,HTTP‬הנקראת שורת המצב‪ ,‬מכילה את המידע הבא‪:‬‬

‫‪ .1‬גרסה של הפרוטוקול‪ ,‬בד״כ ‪HTTP/1.1‬‬

‫‪ .2‬סטטוס קוד שמעיד על הצלחה או כשלון‪ .‬ישנן קונבנציות הקשורות לקודים האלה למשל‪:‬‬
‫‪ 200 − 299‬מייצג הצלחה‬
‫‪ 400 − 499‬מייצג שגיאה הקשורה בצד ‪.client‬‬
‫‪ 500 − 599‬זה שגיאה בצד שרת‪ 505( .‬למשל זה גרסה שונה של ‪)Http‬‬
‫‪ - 301‬האובייקט שחיפשנו זז בצד שרת למיקום אחר שיפורט בהמשך ב‪ header‬ה ‪.location‬‬

‫‪Headers‬‬
‫מבנה זהה לחלוטין של ‪ headers‬בבקשת ‪ .http‬ההבדל היחיד הוא בקונטקסט שיש ל‪ headers‬האלה כלומר‬
‫מה המשמעות שלהם‪.‬‬
 ‫‪Body‬‬
‫באופן דומה ל ‪ .HTTP Request‬מכילות מידע החוזר מבקשה‪ .‬הרבה פעמים אנחנו נראה את זה בבקשות‬
‫מסוג ‪.GET‬‬

‫‪Coockies‬‬
‫באינטרנט‪ ,‬עוגייה היא מחרוזת אותיות או מספרים‪ ,‬המשמשת לאימות‪ ,‬למעקב ולאגירת מידע על אודות‬
‫גולש באתר אינטרנט‪ ,‬כגון שמירת העדפות המשתמש‪ .‬העוגייה מייצגת מצב מסוים של גלישה באתר או‬
‫שימוש באפליקציה‪ .‬לעיתים‪ ,‬גם אתרים שאינם האתר שיצר את העוגייה יכולים להשתמש בה‪.‬‬

‫העוגייה נוצרת על ידי השרת שמעביר אותה לדפדפן ששומר אותה בזיכרון המחשב‪ .‬המחרוזת מוחזרת‬
‫חזרה לשרת בכל פעם שהדפדפן יוצר קשר עם השרת וכך למעשה יכול השרת לזהות את המשתמש‬
‫ולאחזר מידע שנשמר בין שיחות שונות‪.‬‬
 ‫הדפדפן שומר את העוגיות בקובץ ‪ key-value‬כאשר ה ‪ key‬הוא ה‪ domain‬וה‪ values‬הם ה‪coockies‬‬
‫ששמרת עבור אותו ‪.domain‬‬

‫‪Http cache‬‬
‫ל ‪ Http‬יש מנגנון ‪ Cache‬בצד הלקוח שמאפשר לדעת האם יש צורך להביא משאבים כבדים מהשרת או‬
‫לטעון אותם ישירות מה‪ cache‬למשל על ידי שימור בפרמטר ה ‪.last modified‬‬

‫ניתן לראות שהשרת יחזיר ‪ 304‬שזה אומר שהמידע לא השתנה אם שלחנו בקשה עבור משאב שנמצא‬
‫במטמון בפרק זמן קצר מדי‪.‬‬

‫היתרון המשמעותי של זה הוא שניתן לחסוך זמן יקר בטעינת משאבים באתר על ידי שימוש במטמון‬
‫שנמצא קרוב יותר למחשב הלקוח מאשר השרת המקומי‪.‬‬

‫כמו כן‪ -‬גם אם המטמון של ה‪ response‬שמור בצד שרת עדיין השרת לא צריך לבצע עיבוד לבקשה‪.‬‬

‫באמצעות הפרמטר ‪ Cache-Control‬נוכל להגביל את זמן השמירה של מידע במטמון וגם לקבוע האם יש‬
‫צורך בשימוש במטמון בכלל‪.‬‬
 ‫סוגי ‪Cache‬‬

‫ישנם שני סוגים עיקריים של ‪: cache‬‬

‫‪ :private‬שמשויך ללקוח לספציפי (מטמון של דפדפן)‪ .‬מטמון כזה יכול לשמור בתוכו ‪ response‬שמיועד‬
‫ללקוח ספציפי‪.‬‬

‫אם נרצה לשמור מידע במטמון פרטי נוכל לציין זאת באמצעות הוספת ה‪header‬‬

‫‪Cache-Control: private‬‬

‫‪ :shared‬מטמון שממוקם בין הלקוח לשרת ויכול לשמור ‪ responses‬שיכולים להיות משותפים בין מספר‬
‫משתמשים‪ .‬אפשר לחלק אותו לשניים‪ Proxy cache ,‬או ‪. managed cache‬‬

‫‪Proxy‬‬
‫המטרה של ‪ Proxy Server‬היא לספק בקשות לקוח מבלי לערב את השרת המקורי‪ .‬במילים אחרות‪ ,‬שרת‬
‫שתפקידו העיקרי לספק גישה מהירה למשאבים חיצוניים ברשת מחשבים‪.‬‬

‫הסוואת כתובת ה‪ IP-‬מתאפשרת על ידי חיבור לשרת פרוקסי שדרכו כל חיבורי האינטרנט עוברים (הנתונים‬
‫נשלחים אליו וממנו אל השרת ומן השרת אליו ועד למשתמש) כפי שניתן לראות בתמונה‪.‬‬

‫תפקידו העיקרי של שרת הפרוקסי מתאפשר באמצעות תוכנה השומרת בזיכרון המטמון שלו עותקים של‬
‫דפי אינטרנט ומאפשרת גישה מהירה אליהם מהמחשבים המחוברים לפרוקסי‪ .‬בחלק מהמקרים משמש‬
‫הפרוקסי כנקודת הפרדה וביקורת בין רשת המחשבים הפנימית של הארגון אליו הוא שייך לבין העולם‬
‫החיצוני‪.‬‬

‫הוא מאפשר מעקב‪ ,‬חסימה או שינוי לדפי ‪ HTML‬על פי מדיניות הארגון בענייני אבטחת מידע ותכני מידע‬
‫קבילים (אפשר‪ ,‬למשל‪ ,‬לחסום אתרים פורנוגרפיים)‪ .‬יש מקרים שהוא משמש למימוש ‪( SSO‬מסיר את‬
‫הצורך בהכנסת שם לכל אפליקציה שונה) ולהוספת הגנות לדפי הארגון על פי הרשאת המשתמש‪.‬‬

‫סוגי ‪:Proxy‬‬
‫‪Regular Proxy )1‬‬
‫‪ - Transparent Proxy )2‬הלקוח לא מכיר את ה ‪ Proxy‬הזה‪ ,‬הוא מפענח פקטות ומשתמש בהן בהתאם‪.‬‬
‫‪ -Reverse proxy )3‬מיועד לצד השרת ‪ ,‬מסתיר את השרת והטכנולוגיה של השרת‪ ,‬מבצע בעיקר ‪ cache‬ו‬
‫‪ load balancing‬בשביל ‪.Scaleability‬‬

‫‪HTTP calculations‬‬
‫בחלק זה נראה מספר שאלות חישוב שניתן לעשות מעל ‪.HTTP‬‬

‫שאלה ‪:1‬‬

‫מכיוון שאליס עובדת ב‪ http1.0‬אזי מדובר על חיבור שהוא ברירת מחדל לא ‪.persistent‬‬

‫נשים לב‪ :‬תמיד דגל ה ‪ ACK‬דולק בכל החבילות (למעט הראשונה של ה ‪ ,SYN‬ובהתאם ערך ה ‪ACK‬‬
‫‪ number‬יהיה הכי עדכני)‪ .‬לא תמיד נקפיד על הצגה של זה בתרשימים הבאים‪.‬‬

‫נשים לב שהדפדפן של אליס מעולם לא ניגש לאתר של בוב אבל שרת ה ‪ DNS‬המקומי כן ניגש‪ .‬כלומר‬
‫כשנשלח אליו בקשת ‪ DNS‬הוא לא יצטרך ללכת להירכייה ומיד יוכל להחזיר תשובה‪.‬‬

‫נשים לב ש‪ DNS‬הוא מעל ‪ UDP‬כפי שאמרנו‪.‬‬

‫כעת יתחיל חיבור ‪ TCP‬בין אליס ובוב כיוון ש ‪ HTTP‬הוא פרוטוקול מעל ‪ TCP‬ואליס שולחת בקשת‬
‫‪ GET‬כדי לקבל את עמוד האינטרנט‪ .‬כמו כן כיוון שנתון שבקשה בודדת הייתה קטנה מ ‪ MSS‬כל תהליך ה‬
‫‪ request‬ו ‪ response‬יהיה בסגמנט אחד בלבד לכל שלב‪.‬‬
‫לבסוף נוכל לסגור את חיבור ה‪ TCP‬לאחר שהבקשה הושלמה‪.‬‬
‫לא סיימנו‪ ,‬כיוון שאתר האינטרנט מכיל גם תמונה אחת הדפדפן צריך להוריד את ה‪ asset‬בבקשת ‪GET‬‬
‫נוספת ולכן יפתח חיבור ‪ TCP‬חדש‪.‬‬

‫שאלה ‪:2‬‬
 ‫נתון שהשהיית ההתפשטות מה‪ client‬ל ‪ server‬היא ‪.10‬‬
‫‪−3‬‬

‫כיוון שניתן להתעלם מהשהיית ההתפשטות של תחיליות ושל הבקשה בפרט‪ .‬לכן אין צורך לחשב את‬
‫השהיית השידור מהלקוח לראוטר ומשם לשרת‪ .‬אפשר לחשב ישירות את ההשהייה מהלקוח לשרת‬
‫שניות‪.‬‬ ‫‪3 ⋅ 10‬‬
‫‪−3‬‬
‫ניתן לראות ששלב ה‪ handshake‬ושליחת הבקשה לוקח ‪ 3‬השהיות כלומר‬

‫כעת נשים לב שה ‪ MSS=1KB‬אבל ה‪ response‬הוא קובץ בגודל ‪.3KB‬‬

 ‫‪10‬‬ ‫נשים לב שלפי נתוני ההתפשטות של כל ערוץ‪ .‬להעביר ‪ MSS‬אחד בתווך בין השרת לראוטר ייקח‬
‫‪−3‬‬

‫שניות‪ .‬ולהעביר ‪ MSS‬אחד בערוץ בין הראוטר ללקוח זה פי ‪ 4‬מזה ולכן זה יהיה ‪ 4 ⋅ 10‬שניות‪ .‬לכן‬
‫‪−3‬‬

‫להעביר ‪ MSS‬אחד מהשרת ללקוח הוא תהליך שלוקח ‪ 5 ⋅ 10‬שניות‪ .‬אפשר להוסיף עוד אלפית שניה‬
‫‪−3‬‬

‫בשביל לדווח ‪ ack‬לשרת ולכן כל התהליך יהיה ‪ 6 ⋅ 10‬שניות‪.‬‬

‫‪−3‬‬

‫התהליך הזה חוזר על עצמו ‪ 3‬פעמים אחד אחרי השני (בגלל שאנחנו ב‪ )store and forward‬וסך הכל‬
‫התהליך יסתיים לאחר ‪ 21‬אלפית השנייה‪.‬‬

‫שאלה ‪:3‬‬

‫נשים לב שכעת פרוטוקול ‪ DNS‬הולך ״לעבוד קשה״ בגלל שה‪ cache‬ריק‪ .‬הלקוח ברשת ‪ A‬ניגש לשרת‬
‫הפרוקסי ולאחר מכן ניגש ל‪ local resolver‬שמשם יבצע את שרשרת ה ‪ DNS‬הרלוונטית למשיכת ה‪.ip‬‬

‫כעת הפרוקסי יבצע פנייה ל ‪ local resolver‬בכוונה למצוא את ה‪ domain‬וכן הלאה נמשיך בשרשרת פניות‬
‫ל ‪ ns servers‬כדי למצוא את ה ‪ .ip‬נזכיר ש ‪ DNS‬לא עובד רקורסיבי אלא סדרתי ולכן השרת ‪ com‬יחזיר‬
‫תשובה ל ‪ B.com‬ל‪ resolver‬וכן הלאה‪ .‬לבסוף ה‪ resolver‬יחזיר את התשובה ל ‪.proxy‬‬
‫לאחר שכל זה קרה‪ ,‬יתבצע חיבור ‪ TCP‬נוסף בין ה ‪ proxy‬לבין ה ‪ web server‬לקבלת הדף ושמירה ב‬
‫‪.cache‬‬
 ‫שאלה ‪3.2‬‬

‫יש ‪ 10‬חבילות שנשלחות באינטרנט ועוד ‪ 6‬חבילות באותה הרשת ולכן‬

‫‪6 ⋅ 50ms + 10 ⋅ 500ms = 5300ms‬‬

‫שאלה ‪:4‬‬
‫יש ‪ N‬שרתי ‪ DNS‬שהיה צריך לפנות אליהם וזה לקחת ‪ . RT T + ⋯ + RT T‬כעת חיבור ה‪, tcp‬‬
‫‪1‬‬ ‫‪n‬‬

‫שליחת ‪ Syn‬וקבלת ‪ Ack‬עליו לוקחת ‪ RT T‬ושליחת ‪ Ack‬וקבלת התשובה לוקח עוד ‪ RT T‬ולכן‬
‫‪0‬‬ ‫‪0‬‬

‫‪N‬‬

‫‪2RT T 0 + ∑ RT T i‬‬

‫‪i=1‬‬

‫שאלה ‪:5‬‬

‫השהיית ההתפשטות נתונה לנו לכן צריך לחשב רק את השהיית השידור ונקבל‬
 20Kb
d t S→R = = 0.2ms
2
100M bps

20Kb
d tR →R
= = 0.8ms
2 1
25M bps

20Kb
d tR →C
= = 0.02ms
1
1Gbps

d E2E = 250ms + 1.02ms = 251.02ms

. 25Mbps ‫כגודל הערוץ המינימלי‬

: ‫נחשב ממוצע משוקלל‬

0.6 ∗ 1Gbps + 0.4 ∗ 25M bps = 610M bps

:6 ‫שאלה‬
 ‫‪CDN‬‬
‫‪ Content Delivery Network‬היא רשת של שרתים שמאפשר העלאה מהירה יותר של דפי אינטרנט‬
‫כאשר הן עושות שימוש בהמון ‪.data‬‬

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

‫חברות רבות שמציעות שירותי ‪ CDN‬מציעות אלטרנטיבה לרכישה של שרתים מסביב לעולם כדי לתקן את‬
‫הבעיות האלה‪.‬‬
‫החברות הנ״ל שמו בכל מיני אזורים שרת שנקרא ‪ .Edge server‬הלקוחות פונים לאחד מהשרתים הקרובים‬
‫אליהם באמצעות קח שהן מתלבשות על חוות שרתים של ספקי האינטרנט באזורים השונים‪.‬‬
‫השרתים האלה מהווים מנגנון של ‪ Cache‬עבור השרת שלנו‪.‬‬
 SMTP
‫ רכיבים עיקריים‬3 ‫ הוא פרוטוקול שכבת האפליקצייה המכיל‬Simple Mail Transfer Protocol

user agents .1
mail servers .2
simple mail transfer protocol .3

User Agent
 ‫עונה גם לשם ‪mail reader‬‬
‫מיועד לעריכה קריאה ושליחה של הודעות מייל‪.‬‬
‫תוכנות רבות מהוות ‪ user agent‬לפרוטוקול למשל אפליקציית ‪ Outlook, Gmail‬וכו׳‬
‫הודעות יוצאות ונכנסות מאוחסנות בשרת‪.‬‬

‫כדי לדחוף מיילים מה‪ user agent‬לשרת נשתמש ב ‪.SMTP‬‬

‫הייחודיות בפרוטוקול ‪ SMTP‬היא היכולת להעביר מיילים גם בין "‪ "domains‬שונים‪ ,‬כלומר שאינם קשורים‬
‫לאותו שרת‪.‬‬

‫נשים לב‪ SMTP :‬משמש למשלוח דואר אלקטרוני מ‪ user agent‬ובין שרתים שונים‪ ,‬עד שיגיע לשרת היעד‪,‬‬
‫אך אינו מאפשר למשתמש לשלוף את הודעות הדואר המיועדות אליו מן השרת‪ .‬קיימים פרוטוקולים אחרים‬
‫המיועדים לשליפה של הודעות דואר‪ ,‬כגון ‪ POP3‬ו‪.IMAP-‬‬

‫‪ SMTP‬עובר מעל ‪ TCP‬ומשתמש בדרך כלל בפורט ‪ .25‬פורט לקבלת נתונים הוא פורט ‪.587‬‬

‫‪Flow‬‬
‫‪ .1‬אליס משתמשת ב ‪ user agent‬כדי לנסח הודעה עבור ‪.bob@someschool.edu‬‬
‫‪ .2‬אליס שולחת הודעה לשרת המייל שלה ‪ ,‬שם הוא נמצא ב ‪.message queue‬‬
‫‪ .3‬״צד הלקוח״ של שרת ה‪ SMTP‬הנ״ל פותח חיבור ‪ TCP‬לשרת המייל של בוב‪.‬‬
‫‪ SMTP client .4‬שולח את ההודעה של אליס על גבי ‪.TCP‬‬
‫‪ .5‬שרת המייל של בוב ממקם את ההודעה של בוב ב ‪.mailbox‬‬
‫‪ .6‬בוב מושך מהשרת את ההודעות שלו (בעזרת פרוטוקול אחר או בעזרת ה ‪.)web-based mail‬‬

‫נשים לב שאם אליס ובוב היו באותו שרת ‪ web‬שלבים ‪ 5 4‬ו‪ 6‬לא היו רלוונטים אלא שהשרת היה מיד שם‬
‫את ההודעה בתיבה של בוב והוא היה מושך את זה‪.‬‬

‫נסתכל על ‪ Flow‬של תקשורת ‪ SMTP‬לדוגמה‪-‬‬

 ‫כאן ניתן לראות את התקשורת רק ברמת האפליקציה (בלי ‪ .)TCP‬ניתן לראות שהשרת שולח הודעה‬
‫ראשונה ללקוח עם קוד ‪ 220‬ו״מציג את עצמו״‪ .‬לאחר שהלקוח גם מציג את עצמו עם הודעת ‪ HELO‬ואת‬
‫ה״דומיין״ שלו‪ .‬ניתן לראות שהשרת שוב מגיב ללקוח עם קוד ‪ 250‬והודעת ‪ .Hello‬נשים לב שההודעה‬
‫השנייה‪ HELO ,‬נראת כאילו היא עם מעין שגיאת כתיב אך זה הקונבנציה לשלב שבו השרת השולח מציג‬
‫את עצמו לשרת המקבל‪ .‬השרת המקבל יסכים לכל שם שישלח במסגרת הודעה זאת‪ .‬לעתים ניתן להתקל‬
‫גם בהודעה ‪ EHLO‬שזה הרחבה של ‪ .HELO‬אם הפקודה הזאת נשלחת מהלקוח השרת צריך להגיב עם‬
‫מידע נוסף שהוא תומך בו‪.‬‬

‫לאחר מכן הלקוח שולח לשרת הודעת ‪ .MAIL FROM‬השרת מגיב ב ‪( 250‬כמו מקודם) ומאשר את המייל‬
‫של השולח‪.‬‬

‫כעת הלקוח שולח לשרת את שם הנמען עם הודעה ‪ .RCPT TO‬השרת מגיב ללקוח עם ‪ 250‬ומאשר את‬
‫הנמען (אם היו כמה נמענים השורות האלה היו חוזרות על עצמן כמספר הנמענים)‪.‬‬

‫כעת הלקוח שולח לשרת הודעת ‪ DATA‬כדי להכין את השרת לקבלת מידע (נגמר מידע ה״מעטפה״)‪.‬‬
‫השרת מגיב בהודעת ‪ 354‬ומבקש לסיים את המייל עם הודעת ״‪.‬״ בסוף בשורה נפרדת‪.‬‬

‫הלקוח לאחר מכן שולח את ה‪ data‬עם נקודה בסוף כמבוקש‪ .‬השרת מדווח ‪ 250‬שהוא קיבל את ההודעה‬
‫וכיוון שהלקוח סיים הוא שולח ‪ QUIT‬והשרת מגיב בהודעת ‪ 221‬וסוגר את החיבור‪.‬‬

‫נסתכל על דוגמה נוספת‪:‬‬

 ‫ניתן לראות את שלב ה ‪ handshake‬בשני השכבות גם בתעבורה וגם באפליקצייה‪.‬‬
‫השלב הבא הוא שלב ה ‪.envelope‬נשים לב שהמייל המוצמד בהודעת ‪ MAIL FROM‬בשלב המעטפה‬
‫הוא המייל שאליו השרת ידווח שגיאה במקרה ולא ניתן להעביר את ההודעה‪.‬‬

‫כאן בשלב ה ‪ message‬הלקוח שולח שתי הודעות דיווח נוספות של ‪ from‬ו ‪ to‬וכאן יש שני נמענים ורק‬
‫לאחר מכן נשלח ה‪ data‬הנוסף‪ .‬הפורמט הזה הוא הפורמט הרשמי של ‪ .RFC822‬ניתן לראות שאומנם יש‬
‫כאן עוד נמען אך השרת הנ״ל מתעסק ב ‪ b.com‬ולכן הוא לא מתעסק בזה‪.‬‬

‫כאן ניתן לראות דוגמה שבה המידע הנוסף (המידע ב ‪ )Cc‬כן היה רלוונטי עבור השרת הנ״ל ולכן הוא גם‬
‫קיבלת הודעת ‪ RCPT‬נוספת עבור מייל זה (בשניהם הדומיין הוא ‪.)example.com‬‬
‫כאן גם יש שני נמענים רק שהפעם אחד הנמענים הוא נסתר ולכן לא נמצא כחלק מה‪ .Data‬כמו כן בסיום‬
‫ההודעה לא נסגר החיבור אלא נשלח הודעה חדשה אל נמען אחר ב ‪.sponge.com‬‬

‫‪POP3‬‬
‫פרוטוקול משיכת המיילים בצד הלקוח‪.‬‬
 ‫השלב הראשון ב‪ flow‬התקשורת בפרוטוקול זה הוא שלח ה ‪ .authorization‬בשלב זה הלקוח שולח את‬
‫המשתמש ( ‪ ) user bob‬ולאחר מכן את הסיסמה (‪ )pass hungry‬והשרת מגיב בהודעת ‪ +OK‬או ב‬
‫‪. −ERR‬‬

‫השלב השני נקרא שלב ה‪ ,transaction‬בשלב זה הלקוח מבקש לקבל רשימת הודעות חדשות באמצעות‬
‫הפקודה ‪ .list‬השרת יגיב רשימה של ‪ tuple‬של מספר הודעה עם הגודל שלה ויסיים כאשר ישלח את התו‬
‫״‪.‬״ בשורה ריקה‪.‬‬

‫לאחר מכן הלקוח יכול להחליט להשתמש בפקודות מסוימות על הודעות מהרשימה למשל ‪ dele 1‬תמחק‬
‫את הודעה ‪ 1‬מהרשימה ו ‪ retr 2‬תשלוף את המידע מההודעה לפי המספר הודעה‪.‬‬

‫פרוטוקול ‪ POP3‬וקודמיו תוכננו במטרה לאפשר למשתמשים שאין להם חיבור‪-‬קבוע לשרת הדואר‪ ,‬דוגמת‬
‫משתמשי מודם חיוג או ‪ ,ADSL‬גישה לדואר האלקטרוני שלהם‪ .‬במרבית המקרים‪ ,‬צד הלקוח מתחבר אל‬
‫השרת‪ ,‬מוריד ממנו את ההודעות במלואן בסדר שבו התקבלו‪ ,‬ושומר אותן על מחשבו‪ .‬לאחר מכן ההודעות‬
‫נמחקות מהשרת‪ .‬הפרוטוקול תומך באפשרות (אם כי השימוש בה הוא לא‪-‬נפוץ) להשאיר עותק מן ההודעה‬
‫המקורית על השרת‪ .‬בצורה זו יכול המשתמש לקרוא את הדואר שלו מכמה מקומות וגם מכמה תוכנות‬
‫לקוח שונות‪ .‬לכן ‪ POP3‬הוא ‪ stateless‬לאורך ה‪ ,session‬הוא לא שומר את המידע בשרת‪.‬‬

‫פרוטוקול נוסף להעברת דואר הוא פרוטוקול ‪ .IMAP‬זהו פרוטוקול חדש יותר ובעל מגוון פונקציות‬
‫נוספות‪ ,‬כגון אימות מוצפן‪ ,‬הפרדת הדואר לתיקיות‪-‬משנה‪ ,‬הפרדה בין כותרי ההודעה לגוף‪ ,‬ועוד‪ .‬מאחר‬
‫שזהו פרוטוקול מורכב הרבה יותר‪ ,‬הוא נפוץ פחות ורוב ספקיות האינטרנט אינן מאפשרות גישת ‪IMAP‬‬
‫ללקוחותיהן‪.‬‬

‫בעוד שליחה של דואר אלקטרוני או העברת דואר בין שרתים מתבצעת באמצעות פרוטוקול ‪SMTP‬‬
‫והרחבותיו‪ ,‬קריאת דואר על ידי הלקוח תתבצע באמצעות פרוטוקול ‪ POP3‬או ‪.IMAP‬‬

‫‪SMTP calculations‬‬
 ‫קודם כל צריך לדעת מיהו שרת השמות של ‪ . israblof.com‬לשם כך השולח ירצה לשאול את שרת ה‬
‫‪ DNS‬המקומי של הרשת שלו‪ .‬כיוון שאפשר להניח שיש במטמון את רשומות ה‪ NS‬של ‪ COM‬אז השרת‬
‫‪ dns‬המקומי יעבור את השאילתה ״מיהו שרת ה ‪ MX‬של ‪?israblof.com‬״ אל שרת ה ‪ NS‬של ‪ com‬מבלי‬
‫לחפש אותו‪ .‬שרת זה מחזיר את ה‪ ip‬של שרת ה‪ NS‬של ‪ israblof.com‬אל שרת הדומיין המקומי והוא ילך‬
‫לשאול את שרת זה את הכתובת של שרת ה ‪ MX‬המתאים‪.‬‬

‫כפי שציינו שרתי ‪ DNS‬יודעים לעבור עם ‪ priorities‬ל דומיין וכדי להוריד את העומס השרת‬
‫‪ ns.israblof.com‬יחזיר קודם כל העדיפות גבוהה את הכתובת של שרת ה ‪. MX : mail.MXrUS.com‬‬
‫ולכן כשה‪ domain‬הזה יחזור לשרת ה‪ local DNS‬הוא יחזיר את ה‪ domain‬שאותו יש לחפש (מבלי לצרף‬
‫הת ה‪ IP‬כמו במקרה של ‪ )ns.com‬ל ‪ . sender.com‬מיד תשלח בקשה נוספת כדי לחפש את הדומיים של‬
‫שרת ה‪ MX‬והתהליך יעבור שוב דרך ‪ ns.com‬ויוחזר ‪ 5.5.6.6‬שזה כתובת שרתי ה ‪ dns‬של ‪.MXrUS‬‬
‫לאחר פנייה אליו‪ ,‬הוא יחזיר את כתובת ה ‪ ip‬של של המיילים שלהם שתומך בשרת של ‪ .israblof‬כעת‬
‫אפשר להתחיל לבצע חיבור ‪ SMTP‬לשרת המיילים הזה‬
‫כדי לבדוק את אמינות המידע שרת המיילים שולח בקשת ‪ DNS‬עם ה ‪ ip‬של השולח כדי לוודא שהדומיין‬
‫הוא אכן שרת מיילים תקין‪.‬‬

‫מתבצע כעת חיבור ‪ SMTP‬בין שרת המיילים של ‪ MXrUS‬אל ‪ mail.israblof‬וגם הוא מבצע את אותה‬
‫בדיקת אמינות‪ .‬והמידע מגיע ליעד‪.‬‬
 ‫שכבת הרשת‬
‫תפקיד שכבת הרשת הוא לשנע ‪ segment‬מהרכיב השולח לרכיב המקבל‪.‬‬

‫השולח ‪ -‬מייצר ‪ datagram‬מה ‪ segment‬ומעביר ל ‪.link layer‬‬

‫המקבל ‪ -‬מעביר את ה‪ segment‬ל‪. Transport Layer‬‬

‫התפקיד של שכבת הרשת הוא לא בידיוק להעביר למחשב המקבל אלא לרשת שבה נמצא המחשב המקבל‬
‫‪ Link Layer ,‬אחרי להעביר את המידע למחשב המתאים ברשת המקומית‪.‬‬

‫לראוטר יש תפקיד מרכזי בשכבה זו‪:‬‬

‫הוא בודק את כל שדות ה ‪ headers‬בכל ה ‪.IP datagrams‬‬
‫משנע ‪ datagrams‬מ ‪ input ports‬ל ‪ output ports‬כדי שיוכל להעביר אותם את כל הדרך עד לרשת‬
‫המתאימה‬

‫ישנן שתי פונקציות עיקריות של שכבת הרשת‬

‫‪ -forwarding‬שינוע פקטות מראוטר אחד לראוטר הבא בתור‪.‬‬
‫‪ - routing‬קביעת המסלול מהשולח ליעד‪.‬‬
 ‫על שכבת הרשת נסתכל בשני מישורים עיקריים‬
‫‪ - Data plane‬כאשר הראוטר מקבל חבילה הוא קובע כיצד ה ‪ datagram‬המתקבל מ‪ input‬כלשהו יעבור‬
‫ל ‪ output port‬של הראוטר הבא‪.‬‬

‫‪ - Control plane‬קובע כיצד ‪ datagram‬מנותב בין ראוטרים מקצה לקצה עד הגעה ליעד‪ .‬כלומר איך‬
‫הראוטרים מחליטים בינהם לאן הפקטה תלך‬

‫לכל ראוטר יהיה רכיב שמהווה את אלגוריתם הניתוב והוא מתממשק עם מישור הבקרה‪.‬‬

‫‪ Service model‬של שכבת הרשת‪:‬‬

‫עובד בשיטת ‪ best effort‬כלומר לא מבטיח הגעה של ה‪ datagram‬ותזמון בסדר ההגעה‪.‬‬

‫פקטה של שכבת הרשת נראת מהצורה‪:‬‬

 ‫‪IP‬‬
‫כתובת ‪ IP‬מהווה אמצעי זיהוי של כל שרת באינטרנט ושל כל ציוד קצה שמחובר לאינטרנט‪.‬‬
‫כתובת ‪ IP‬היא ייחודית ומוקצית בד״כ באופן אוטומי‪ .‬בכל בקשה שנשלח לשרת‪ ,‬כתובת ה ‪ IP‬מוצמדת לכל‬
‫בקשה שתשלח כדי שהשרת ידע לאן להחזיר תשובה‪ .‬באופן דומה הדפדפן במחשב זקוק לכתובת ה ‪IP‬‬
‫של השרת כדי לדעת לאן לשלוח את הבקשה‪.‬‬

‫מבנה כתובת ה ‪IP‬‬

‫כל כתובת ‪ , IP‬מורכבת מרצף של ארבעה מספרים ובינהם נקודות‪ .‬כל מספר נמצא בטווח ]‪,[0, 255‬‬
‫לדוגמה ‪ . 183.79.248.252‬עבור כל מספר בכתובת קיימות ‪ 256‬אפשרויות לכן לפי עקרונות קומבינטוריקה‬
‫בסיסיים נבין שיש בסה״כ ‪ 2‬כתובות ‪ .ip‬כיוון שכיום המספר הזה לא גדול במיוחד ישנו מבנה חדש של‬
‫‪32‬‬

‫הכתובת שמאפשר לייצג ‪ 2‬כתובות‪ .‬למבנה הזה קוראים ‪ IPv6‬לעומת ‪ IPv4‬שזאת הגרסה הנ״ל‪ .‬כיום‬
‫‪128‬‬

‫משתמשים בשני הגרסאות‪.‬‬

‫איתור כתובת גיאוגרפית באמצעות כתובת ‪IP‬‬

‫אנשים רגילים לא יכולים לדעת איפה אנחנו גרים על סמך כתובת ה‪ IP‬שלנו‪ ,‬אך בחוזה ההתקשרות‬
‫שאנו חתומים עם ספק האינטרנט‪ ,‬רשומה כתובת הבית שלנו וזאת מקושרת לכתובת ה ‪ IP‬של‬
‫המחשב שלנו‪.‬‬

‫הפקודה ‪PING‬‬
 ‫‪ ping IP‬היא פקודה שמאפשרת לנו לבדוק אם שני מחשבים מקושרים זה לזה‪ .‬הפקודה שולחת‬
‫הודעות אל כתובת ה ‪ IP‬של היעד שאנחנו בוחרים‪ .‬אם ההודעות מגיעות ליעד ואם היעד מוכן לענות‬
‫לנו‪ ,‬נקבל על כל הודעה תשובה ובה משך הזמן שלקח להודעה לעבור בין שני המחשבים‪.‬‬

‫נשים לב שהפרוטוקול ש‪ ping‬משתמש בו הוא ‪ ICMP‬שזה פרוטוקול שמיועד לשליחת הודעות‬

‫שגיאה או ‪ metadata‬כאשר מעבירים מידע‬

‫מזהה רשת‪ ,‬מזהה יישות‬

‫בכתובות ‪ IP‬מסתתר מידע נוסף שחשוב לפעילות של שכבת הרשת‪.‬‬
‫כל כתובת ‪ IP‬מכילה את המידע הבא‪:‬‬
‫א) מזהה רשת‪ :Network ID -‬לאיזו תת רשת שייכת כתובת ה ‪?IP‬‬
‫ב) מזהה ישות ‪ :Entity ID -‬לאיזה כרטיס רשת‪ ,‬חומרת המחשב המאפשרת למכשיר להתחבר לרשת‬
‫מחשבים או לרשת האינטרנט (‪ )NIC- Network Interface Controller‬שייכת הכתובת?‬

‫‪Class Based Addressing in IP‬‬

‫ב ‪ IP‬הזכרנו ש‪ 32‬הביטים שמרכיבים ‪ IP/4‬מורכבים ממזהה רשת ומזהה יישות‪ .‬נשאלת השאלה כיצד‬
‫מחלקים את הביטים האלה בין מזהה הרשת למזהה היישות בתוך הרשת‪ .‬אחת הדרכים היא ב ‪.CBA‬‬
 ‫אם ה ‪ MSB‬הוא ‪ 0‬אז ה‪ class‬של ה ‪ IP‬הוא ‪ , A‬במצב זה ‪ 8‬הביטים השמאליים הם מייצגים את מזהה‬
‫‪2‬‬
‫‪7‬‬
‫הרשת‪ .‬אם הביט הוא ‪ 1‬אז היא שייכת לאחת המחלקות האחרות‪ .‬במצב שבו השייכות היא ל ‪ A‬יש‬
‫כתובות רשת אפשריות (כי ה‪ MSB‬תפוס)‬

‫ככל שעולים ב ‪ Class‬ככה מתווספים עוד ‪ 8‬ביטים לרשתות אבל גם מאבדים עוד ‪ MSB‬במספר המחלקה‪.‬‬

‫היתרון של שיטה זאת הוא בכתובת ‪ ip‬אני יכול לקבל במחיר די קטן את החלוקה של הכתובת ל מזהה‬
‫רשת ויישות‪.‬‬
‫החסרון של שיטה זאת הוא שמעבר בין מחלקות מקפיץ את כמות הכתובות מעריכית ולכן יש לזה עלות‬
‫״כלכלית״ גבוהה‪.‬‬

‫כפי שאמרנו לכתובת ‪ IPv4‬יש ‪ 2‬כתובות אפשריות‪ .‬מרחב הכתובות הזה נוצל מזמן ואומנם יש כבר‬
‫‪32‬‬

‫גרסאות עם יותר כתובות כמו ‪ IPv6‬אבל זה לא כזה פשוט להמיר את כל הכתובות הקיימות לכתובות‬
‫מגרסא חדשה‪ .‬לכן נרצה שיטה פחות בזבזנית מה ‪ class addressing‬כדי להבדיל בין בין מזהה הרשת‬
‫למזהה היישות‪.‬‬

‫‪Classless Inter-Domain Routing and Subnetting‬‬

‫לכל כתובת ‪ IP‬נצמיד ‪ subnet mask‬שזה כמות הביטים משמאל שמזהים את הרשת‪ .‬שאר הביטים יזהו‬
‫את המחשב בתוך הרשת‪ .‬הפורמט הוא ‪ a.b.c.d/x‬כאשר ‪ x‬הוא ה‪.sm‬‬

‫השיטה הזו פחות בזבזנית כי היא מאפשרת קפיצות ברמת ביט בודד ולא בית כמו בשיטה המחלקות‪.‬‬
‫כלומר אומנם אנחנו עדיין מוגבלים ברמת הקפיצות בין כמות המחשבים שאפשר לייצג באותה רשת ברמת‬
‫הקפיצות בין ביט לביט אבל כעת אלו יותר קטנות‪.‬‬
 ‫ה‪ subnet mask‬הוא בעצם מספר בינארי באורך ‪ 32‬ביטים שכל ביט אצלו מייצג האם הביט ב‪ ip‬שייך‬
‫למזהה רשת או מזהה היישות (ביט דולק משמעותו שייך למזהה היישות אחרת למזהה הרשת)‪ .‬לאחר מכן‬
‫נתן לחלץ את המידע מה‪ mask‬על ידי ביצוע ‪. & bitwise‬‬

‫כתובות ‪ IP‬שמורות‬
‫שומרים בדרך כלל את הכתובת הראשונה עבור הרשת עצמה והכתובת האחרונה היא עבור ‪ broadcast‬של‬
‫הרשת‪.‬‬

‫יש גם מספר טווחים שהוקצו ל‪ private networks‬כלומר כתובות של רשתות פנימיות‪.‬‬

‫יש גם כתובות מיוחדות כמו ‪ 127.0.0.1‬שאנחנו מכירים כ ‪.loopback‬‬

‫‪Destination-base forwarding‬‬
‫בהינתן פקטה‪ ,‬נרצה לדעת כיצד הראוטר מחליט לאיזה ממשק להעביר את הפקטה כדי שתמשיך להתקדם‬
‫עד להגיעה ליעד‪.‬‬

‫לשם כך הראוטר יחזיק בתוכו ‪ forwarding table‬עם שתי עמודות‪ .‬הראשונה תהיה ה ‪Link Interface‬‬
‫והשנייה תהיה ‪ Destination Address Range‬שתכיל בתוכו את טווח הכתובות ה ‪ IP‬שמיועדות לעבור‬
‫לממשק שבעמודה הראשונה‪ .‬נזכיר שפקטה של שכבת הרשת מכילה כתובת ‪ IP‬של ה‪ source‬וכתובת ‪IP‬‬
‫של ה‪ destination‬ב תחיליות שלה‪.‬‬

‫נשים לב שייצוג של טווח בטבלה הוא על ידי סימון ב * את הביטים שברצוננו לאפשר להיות להיות במצב‬
‫״חופשי״ כלומר גם כבויים וגם דלוקים‪ .‬טווח בשורה מסוימת יכול להיות ״ספציפי״ יותר מאחר או להכיל‬
‫טווח בשורה אחרת‪ .‬כאשר הראוטר רוצה לקבוע לאן פקטה צריכה ללכת הוא מחפש את האחד שטווח‬
‫הכתובות המכיל אותו הוא הקטן ביותר (יכול להיות כמה אבל בהכרח יהיה טווח קטן יותר מהשני)‬
 ‫‪.‬‬ ‫‪11001000 00010111 00010110 10100001‬‬ ‫נסתכל על ה ‪ ip‬הבא‬

‫בעצם מחפשים את ה‪ prefix‬הארוך ביותר שמתאים לשורה כלשהי בטבלה‪ .‬אם נסתכל על הכתובת‬
‫הדוגמה‪ ,‬נראה שעבור שלושת השורות‪ ,‬הבית הראשון מתאים וגם הבית השני‪ .‬לעומת זאת‪ ,‬הבית השלישי‬
‫מתאים רק לשורה הראשונה בטבלה כי הוא היחיד שהבית ה‪ 5‬משמאל הוא ‪ 0‬ולכן השורה הראשונה מכילה‬
‫את ה‪ prefix‬הארוך ביותר‪.‬‬

‫באמצעות הטבלה הזאת ספקי אינטרנט יכולים להשתמש בראוטרים שלהם כדי להעביר מידע לפי הארגונים‬
‫שנמצאים תחתם ברשת‪ .‬הקונספט הזה נקרא ‪ hierarchical addressing‬והוא בעצם מאפשר להקצות עוד‬
‫ביטים למזהה רשת דרך ה ‪ mask‬ואלו יהוו מזהים לארגונים‪.‬‬

‫״האינטרנט״ בתמונה למעלה מהווה ראוטרים אחרים שמקבלים מידע מספקי אינטרנט על טווחי הכתובות‬
‫שהם מעוניינים שאותם ראוטרים יעבירו אליהם את המידע‪ .‬לפי הממשק שממנו באה הבקשה הראוטרים‬
‫יודעים לבנות את ה‪ forward table‬שלהם‪.‬‬

‫‪IP Datagram Format‬‬

 ‫נשים לב שבשכבה זאת נשמר ה ‪ offset‬של הפרגמנטצייה שפרוטוקול ‪ TCP‬מנסה להמנע ממנו‪.‬‬
‫פרמטר חשוב נוסף הוא ‪ ttl‬שזה נועד למנוע מצב של תנודה אינסופית של פקטה בין הראוטרים‪.‬‬

‫‪IP Calculations‬‬
‫שאלה ‪1‬‬

‫מכיוון שלא ניתן ‪ subnet mask‬אזי מדובר בשיטה המבוססת מחלקות‪.‬‬

‫‪138 10 ≡ 10001010 2‬‬

‫הביט השמאלי הוא ‪ 1‬ומימינו מכובה ולכן הכתובת שייכת למחלקה ‪ .B‬לכן המזהה רשת הוא ‪. 138.64‬‬

‫שאלה ‪2‬‬

‫ה ‪ subnet mask‬הוא ‪( 23‬כמות הביטים הדלוקים היא ‪ 23‬מתוך ‪ .)32‬נבצע & בין כתובת ה ‪ IP‬ל ‪subnet‬‬
‫‪ mask‬בבינארית ונקבל‬

‫שאלה ‪3‬‬
 ‫ראשית נזהה כמה כתובות יש ברשת הזאת לכל היותר‬
‫מכיוון שה ‪ subnet mask‬הוא ‪ 26‬יש ‪ 6‬ביטים שמייצגים מחשבים בתוך הרשת ולכן יש ‪ 2 = 64‬כתובות‬
‫‪6‬‬

‫אפשריות ברשת‪ .‬נשים לב שמפרישים שתי כתובות לשימושים מיוחדים (הראשונה והאחרונה) ולכן יש ‪62‬‬
‫כתובות אפשריות‪ .‬לכן במקרה שלנו כל כתובת בטווח‬
‫‪ 101.101.101.126 - 101.101.101.65‬מתאימה לנו‪.‬‬

‫שאלה ‪4‬‬

‫ברשת שלנו יש ‪ 64‬כתובות אפשריות‪ .‬נשים לב‪ ,‬שהספק מעוניין לדעת לכל כתובת לאיזה לקוח היא שייכת‪.‬‬
‫מכיוון שיש ‪ 4‬לקוחות‪ ,‬הספק מקריב את ‪ 2‬הביטים הכי שמאליים מהחלק של הכתובת ולא מהחלק של‬
‫מזהה הרשת‪ ,‬בכדי לזהות את הלקוח‪ .‬הסיבה ל ‪ 2‬ביטים היא שאפשר בעזרתם לייצג ‪ 4‬לקוחות‪ .‬בלוקי‬
‫הכתובות ייראו מהצורה‬

‫‪101.101.101.64/28 .1‬‬
‫‪101.101.101.80/28 .2‬‬
‫‪101.101.101.96/28 .3‬‬
‫‪101.101.101.101.112/28 .4‬‬

‫נשים לב‪ ,‬שכאשר ספק האינטרנט מפרסם לעולם את הכתובות שהוא מעוניין שישלחו אליו‪ ,‬הוא מפרסם רק‬
‫את הכתובת הראשונה‪ .‬כאשר חבילה המיועדת לכתובת ‪ ip‬כלשהי בטווח הזה תגיע לראוטר של ספק‬
‫האינטרנט‪ ,‬הראוטר יסתכל על ‪ 2‬הביטים הבאים ולפי זה ידע לאיזה לקוח יש להעביר את החבילה‪.‬‬
‫התהליך שבו ״איחדנו״ מספר תתי רשתות תחת רשת אחת נקרא ‪.route aggregation‬‬

‫שאלה ‪5‬‬
 ‫בשלב הראשון ספק האינטרנט יעביר שכל הפקטות עם ה‪ dst ip‬כפי שמצויין בתמונה‪ ,‬יש להעביר את‬
‫הכתובות האלה אליו‪.‬‬

‫נשים לב שזה ממשק אחד מבין ה‪ 4‬כי הנתב חייב להתחבר לאינטרנט‪ .‬נשארנו עם ‪ 3‬ממשקים‪.‬‬

‫אם כן נוכל להקדיש ‪ 2‬ביטים עבור ניתוב לכל אחד מ‪ 3‬הממשקים כאשר הממשק השלישי (עם ביט שמאלי‬
‫מבין ה‪ 2‬שערכו יהיה ‪ )1‬יקבל פי ‪ 2‬יותר כתובות פנימיות‪ ,‬את החצי השני של מרחב הכתובות הפנימיות‪.‬‬

‫כעת נתחיל להתאים לקוחות לנתבים‪:‬‬

‫בגלל שיש לנו לקוחות שרוצים פחות מ ‪ 100‬כתובות נוכל להשתמש בנתב האמצעי (התכלת) ולחבר אותו‬
‫לנתב נוסף שיהיו לו ‪ 3‬ממשקים פנויים ולכל אחד מהממשקים נצמיד לקוח‬

‫באותו אופן גם לראוטר עם ‪ 2048‬כתובות‬

‫וסה״כ‬
‫נשים לב שמכיוון שכל כתובת היא מבוססת בינארית צריך לבדוק כמה ביטים צריך עבור לפחות ‪ 50‬כתובות‪.‬‬

‫כתובות כלומר ב ‪ 6‬ביטים‪.‬‬ ‫‪2‬‬

‫‪6‬‬
‫‪= 64‬‬ ‫במקרה שלנו מדובר ב‬
‫לא ניתן פחות‪ ,‬כי הקפיצות הן בינאריות‬
‫לכן‪ ,‬נוכל לחלק את הכתובות ל ‪ 4‬תתי רשתות‪.‬‬

‫‪ICMP‬‬
‫פרוטוקול של שכבת הרשת שמאפשר להעביר ‪ errors, pings‬ו ‪ .network diagnostics‬הודעות ‪ICMP‬‬
‫נבנות בשכבת ה־‪ ,IP‬בדרך כלל מחבילת ‪ IP‬רגילה‪ ,‬אשר יצרה תגובת ‪ICMP‬‏‪ IP .‬עוטף את הודעת ה‬
‫‪ ICMP‬המתאימה בכותרת ‪ IP‬חדשה‪ ,‬כדי לשולחה חזרה למכונה ששלחה את ההודעה המקורית‪ ,‬ולהעביר‬
‫את החבילה הנוצרת באופן הרגיל‪.‬‬

‫‪Traceroute‬‬
 ‫באמצעות הפקודה הזאת ניתן לאתר את הנתבים שהמידע עובר בהם כדי להגיע ליעד‪.‬‬

‫הרעיון הוא כל פעם לשלוח פקטת ‪ UDP‬עם ‪ ttl‬שערכו הוא ‪ i‬כאשר ‪ i‬מייצג את מספר הפקטה ששלחנו‪.‬‬

‫הפקטה הראשונה תקבל ‪ ttl=1‬השנייה ‪ ttl=2‬וכן הלאה‪ ttl .‬הוא פרמטר שמתעדכן בכל פעם שהפקטה‬
‫מגיעה לראוטר‪ .‬הראוטר מוריד ערך זה ב ‪ , 1‬אם הערך הוא ‪ 0‬הוא זורק את הפקטה ומחזיר הודעת שגיאה‬
‫עם פרוטוקול ‪ .ICMP‬לכן עבור הפקטה ה‪ i‬הראוטר ה ‪ i‬יחזיר שגיאה מסוג ‪ 11‬עם קוד ‪)ttl expired( 0‬‬

‫הודעות השגיאה הללו מכילות את שם הראוטר וה ‪ ip‬שלו‪.‬‬

‫תנאי העצירה הוא הגעה ליעל אבל בגלל שאין ‪ port‬מוגדר שוב יוחזר שגיאת ‪ ICMP‬מסוג ‪port‬‬
‫)‪ unreachable (type 3, code 3‬והפקודה תפסיק לרוץ‪.‬‬

‫בטרמינל של ‪: windows‬‬
 ‫בטרמינל של לינוקס ‪:‬‬

‫נשים לב שהפקודה גם שומרת את ה ‪.RTT‬‬

‫כמו כן‪ ,‬בלינוקס השגיאה מחזירה גם את מספר הלינק שממנו הגענו (לכן גם בתמונה לכל ראוטר יש ‪2‬‬
‫כתובות לפי הלינק)‪.‬‬

‫‪NAT‬‬
‫‪ - network address translation‬בפועל יש הרבה יותר מחשבים מכתובות ‪ ipv4‬וגם הטכנולוגייה לא‬
‫תומכת בהעברה מידית ומלאה ל ‪ .ipv6‬לשם כך‪ ,‬משתמשים ב ‪ ,NAT‬טכניקת ניתוב שמאפשרת למספר‬
‫מכשירים ברשת מקומית לחלוק רק כתובת ‪ IP‬אחת ברחבי האינטרנט‪.‬‬
 ‫דיברנו על כך ש ‪ DHCP‬הוא פרוטוקול שמספק כתובת ‪ IP‬ל‪ host‬שמתחבר לרשת פעם ראשונה‪.‬‬
‫חשוב להבחין שפרוטוקול זה מספק את כתובות הרשת הפנימיות (מצד ימין בתמונה) בעוד‬
‫שבאינטרנט הכתובת של כל הרשת הזאת הוא הכתובת ‪( 138.76.29.7‬וזה החלק ששכבת הרשת‬
‫ביחד עם ‪ NAT‬אחראית עליו)‪.‬‬
‫כאשר ‪ datagram‬עוזבים את ה‪ , local network‬כתובת ה ‪ ip‬שנמצאת ב ‪ header‬היא הכתובת‬
‫‪ .138.76.29.7‬אבל כאשר ה‪ datagram‬נשארות ברשת המקומית הכתובות ‪ ip‬שלהם ב ‪header‬‬
‫רשומות לפי הכתובת הפנימית שלהם‪.‬‬

‫איך תהליך התרגום עובד?‬

‫‪ .1‬נניח שאפליקצייה במחשב עם ‪ source ip‬של ‪ 10.0.0.1‬רצה על ‪ port‬של ‪ 3345‬ורוצה לשלות‬

‫‪ datagram‬לכתובת ‪ 128.119.40.186‬על גבי פורט ‪.80‬‬
‫‪ .2‬ב‪ headers‬של שכבת הרשת רשום ב ‪ source‬ו ‪ destination‬את הכתובות הנ״ל‪.‬‬
‫‪ .3‬באמצעות ‪( subnet mask‬השוואת ‪ 24‬הביטים של הכתובת שלו עם הכתובת של היעד) המחשב‬
‫הגיע למסקנה שהרשת ‪ destination‬היא לא ברשת המקומית ולכן הוא מעביר את הבקשה ל‪default‬‬
‫‪ ,gateway‬הוא מגלה את ה‪ MAC‬של ה ‪ default gateway‬עם ‪ ARP‬ומעביר את הבקשה לראוטר‬
‫בכתובת ‪.10.0.0.4‬‬
‫‪ .4‬הראוטר‪ ,‬שכבר יודע דרך איזה ממשק להוציא את החבילה באמצעות ‪ forward table‬הולך ל ‪NAT‬‬
‫‪ ,translation table‬וממפה בין הכתובת ‪ ip‬והפורט הפנימיים של הרשת המקומית וממפה את זה‬
‫לכתובת ה‪ ip‬הגלובלית שהרשת מכירה ול‪ port‬שבה הראוטר עצמו מאזין לבקשה‪ .‬נניח שהכתובת‬
‫היא ‪ 138.76.29.7‬על פורט ‪ ,5001‬משנה את ה‪ header‬ושולחת את הבקשה‪.‬‬
‫‪ .5‬כאשר מתקבלת תשובה עבור הבקשה זו הראוטר חוזר לטבלה רואה מי הכתובת המקומית שצריכה‬
‫לקבל את הבקשה ומעביר אליה‪.‬‬

‫התהליך הזה שקוף לחלוטין לאפליקציה במחשב ששלח את הבקשה‬

 ‫בעיתיות ה ‪NAT‬‬

‫‪ NAT‬הוא לא פרוטוקול של שכבת הרשת! הוא מעין ‪ hack‬שמאפשר לפתור את הבעיה של מחסור‬
‫כתובת מסוג ‪( IPv4‬שאמורה להפתר עם מעבר ל ‪ IPv6‬אבל הטכנולוגיה לא מאפשרת מעבר שכזה)‬
‫ולכן שיטה זאת קצת שנויה במחלוקת שכן היא משנה ‪ headers‬של שכבת הרשת ונותנת לראוטר‬
‫אחריות נוספת‪ .‬כמו כן בגלל ההכמסה של ‪ NAT‬נפגעת היכולת לעשות חיבור ישיר (‪ )end to end‬בין‬
‫מחשב אחד לאחר ברשת החיצונית כמו ב‪ , TCP‬על ה ‪ NAT router‬לפתור בעיות אלו בעצמו מה‬
‫שגם מערבב בין השכבות‪.‬‬

‫‪NAT Variations‬‬
‫כפי שניתן לראות ב ‪ RFC 38489‬ישנם מספר סוגים של ‪:NAT routers‬‬

‫(מסמכי בקשה להערות הם סדרה של מזכרים בתחום טכנולוגיות אינטרנט שונות‪ .‬לרוב‪ ,‬המזכרים‬
‫מתארים מחקר חדש‪ ,‬חדשנות טכנולוגית או מתודולוגיה המרחיבים באופן כלשהו את טכנולוגיות האינטרנט‬
‫הקיימות)‪.‬‬

‫‪ - Full Cone .1‬המיפוי הוא קבוע‪ ,‬כל בקשה שתשלח מה‪ ip‬והפורט הפנימיים ימופו לאותו כתובת ‪ ip‬ו‬
‫פורט חיצוניים‪ .‬כמו כן כל מחשב אחר ששולח פקטה ל ‪ ip‬והפורט החיצוני שממופים לכתובת פנימיות‬
‫יגיעו לכתובות האלו (גם אם המחשב ברשת הפנימית לא שלח בקשה)‪.‬‬
‫‪ - Restricted Cone .2‬כמו ה ‪ ,Full‬המיפוי קבוע אבל מחשב חיצוני עם כתובת ‪ X‬כלשהי יכול לשלוח‬
‫פקטה למחשב פנימי רק אם המחשב הפנימי שלח בעבר פקטה למחשב החיצוני בכתובת ‪ .X‬כלומר‬
‫מניחים שהמחשבים שנמצאים תחת ‪ NAT‬הם מחשבי ‪ Clients‬שלא אמורים לקבל פקטות בלי לבקש‬
‫זאת מראש‪ .‬נשים לב שההגבלה היא רק על כתובת ‪ IP‬ולא פורט‪.‬‬
‫‪ - Port Restricted .3‬כמו ‪ Restricted‬רק שההגבלה ספציפית יותר גם למספרי פורט‪ .‬כלומר רק אם‬
‫המחשב הפנימי שלח בקשה לכתובת ‪ X‬בפורט ‪ P‬אז כתובת זאת והפורט הזה יכולים לשלוח בחזרה‬
‫פקטות‪ .‬ישנה בעיה שעולה מידית‪ ,‬מה קורה כששני מחשבים נמצאים מאחורי ‪ NAT‬מסוג ‪Port‬‬
‫‪ , Restricted‬איך הם יתקשרו אחד עם השני? שכן‪ ,‬הפורטים שאנחנו נשלח אליהם יהיו שונים בגלל‬
‫המיפוי‪.‬‬
 ‫‪ - Symmetric .4‬כל הבקשות מאותו ‪ ip‬ו פורט פנימיים ליעד כלשהו ימופו לאותו ‪ ip‬ופורט חיצוניים‪ .‬אם‬
‫המחשב הפנימי י שלח לכתובת אחרת המיפוי יהיה אחר‪ .‬כמו כן‪ ,‬רק מחשבים חיצוניים שקיבלו פקטה‬
‫יכולים לשלוח פקטת ‪ UDP‬בחזרה ל ‪.internal host‬‬

‫(לא אעמיק כאן בחשיבות של זה‪ ,‬אבל בגדול זה קשור לנושאים כמו ‪ firewall‬ואבטחה‪ ,‬איך אפשר לדעת‬
‫שחבילת ‪ UDP‬נשלחת במסגרת חיבור שבוצע בעבר)‪.‬‬

‫‪Architectures‬‬
‫השיטות ‪ NAT‬הנ״ל יכולות להעלות מספר סימני שאלה כאשר מבינים שברשת יש מספר ארכיטקטורות‬

‫‪ - Client/Server .1‬השיטה הקלאסית שאנחנו מכירים‪ ,‬שרת תמיד ער עם ‪ IP‬קבוע בעוד שהלקוחות‬
‫משתנים‪.‬‬
‫‪ - Peer 2 Peer .2‬כל מחשב בתקשורת זאת הוא גם שרת וגם לקוח כאשר המערכות קצה הן‬
‫שרירותיות וה ‪ IP‬של כולם הוא דינמי‪.‬‬
‫‪ - Hybrid .3‬הלקוח משתף שרת בתוכן שלו והשרת מאפשר ללקוח להתחבר ללקוחות אחרים‪.‬‬

‫הבעייתיות מתחילה כאשר חלק מהמכשירים מדברים אחד עם השני מבלי שפנו אליהם קודם אבל הם‬
‫יושבים מאחורי ‪ .NAT‬במצבים מסוימים בקשות שיגיעו פשוט יחסמו בגלל המגבלות של שיטה זאת‪.‬‬

‫‪NAT Traversal Problem‬‬

‫איך פותרים את הבעיות שעולות מהארכיטקטורות הנ״ל? למשל נסתכל על לקוח שרוצה לדבר עם הכתובת‬
‫‪ 10.0.0.1‬שממופת לכתובת חיצונית ‪ .138.76.29.7‬ב ‪ Full Cone‬היינו מצליחים אבל בכל שיטה אחרת‬
‫נחסם‪.‬‬

‫פתרון ‪ - 1‬השרת שנמצאת מאחורי ה‪ NAT‬יוסיף רשומה סטטית לטבלת ה ‪ NAT‬שבאופן אוטומטי‬
‫מעבירה בקשות מפורט וכתובת מסויימת למחשב מקומי שנרצה‪.‬‬

‫פתרון ‪ - 2‬שימוש בשרת מתווך‪ .‬מחשבים שמשתמשים באפליקציה מסוימת שולחים בקשה לשרת מה‬
‫שיגרום למיפוי ב‪ nat table‬ולקוחות שרוצים לדבר עם המחשבים הנ״ל ישלחו בקשות לשרת המתווך והוא‬
‫יעביר אותם למחשבים וככה לא יחסם‪.‬‬
 ‫נשים לב שכדי שזה יעבוד השרת עצמו לא צריך לשבת מאחורי ‪ .NAT‬כמובן גם שיש חסרון של איטיות‬
‫ופרטיות‪ ,‬השרת המתווך לא יכול להבטיח הצפנה של המידע וכו׳‪.‬‬

‫פתרון ‪Hole Punching -3‬‬

‫איך מחשבים שלא רוצים תקשורת דרך שרת אבל עדיין יושבים מאחורי ‪ NAT‬יוכלו לדבר אחד עם השני?‬

‫אליס ובוב רוצים לתקשר אחד עם השני ללא מתווך‪ ,‬בהתחלה נחזיק שרת ‪ Dir‬שהמטרה שלו היא לייצר‬
‫חורים ב ‪ NAT‬וגם להחזיק מיפוי בין לקוחות שרוצים לדבר אחד עם השני‪.‬‬

‫אליס יעביר את הפרטים שלו ל ‪ Dir‬וככה יווצר 'חור' ב ‪( NAT‬רשומה בטבלה) שלא חוסמת בקשות מ‪.Dir‬‬
‫אליס מאוחר יותר תרצה להקים חיבור עם בוב ותבקש משרת ה ‪ Dir‬את הפרטים של המחשב של בוב‬
‫וככה נוצר 'חור' גם בטבלה של המחשב שלה‪.‬‬

‫ה‪ Dir‬יעשה ״היכרות״ בין אליס ובוב על ידי כך שישלח בקשה לשניהם עם הפרטים של השני‪ .‬כעת אליס‬
‫יכולה לפנות לבוב‪ ,‬תשמור רשומה שלו בטבלה שלה‪ ,‬אבל החבילה תזרק אצל בוב‪ ,‬למרות זאת במקביל‪,‬‬
‫בוב שולח בקשה לאליס שומר את הרשומה אצלו בטבלה אבל החבילה תגיע הפעם לאליס כי היא שמרה‬
‫את בוב בטבלה‪ ,‬כעת הם יכולים לתקשר בינהם‪.‬‬

‫הטכניקה הנ״ל נקראת ‪.hole punching‬‬

‫בעיית הניתוב‬
‫כיצד ראוטר שרוצה להעביר בקשה למחשב יעד יודע מה המסלול הכי טוב על גבי הרשת שפקטה צריכה‬
‫לעבור? זאת אחת הבעיות ששכבת הרשת פותרת‪ .‬שכבת הרשת ממדלת את הבעיה הזאת באמצעות גרף‪.‬‬
‫הקודקוד הם ראוטרים והקשתות הם חיבורים בין ראוטרים קרובים (לפי ה‪.)forward table‬‬
 ‫‪OSPF routing‬‬
‫‪ -Open Shortest Path First‬פרוטוקול ניתוב שמשתמש באלגוריתם ‪ Shortest Path First‬ונמצא תחת‬
‫קטגוריית אלגוריתמים מסוג ‪ ,link-state‬כלומר כל כל ראוטר צריך להציף את מצב הערוצים לכל הראוטרים‬
‫ששייכים לאותו ‪ .AS‬ברגע שיש את המידע הזה ניתן לקבוע את העלות לפי מספר פרמטרים כמו‬
‫‪ bandwidth‬ו ‪ delay‬אבל החלק המרכזי כאן הוא שניתן לבצע דייקסטרה בגלל שלכל מחשב יש את כל‬
‫טופולוגיית הרשת שלו ובאמצעות דייקסטרה אפשר לבנות את ה ‪.forward table‬‬

‫הסיבוכיות של אלגוריתמים כאלה לעתים לא מאפשרת לנו להריץ אותם כל פעם בכל ראוטר כי זה כמו‬
‫גדולה של זכרון וזמן‪ ,‬כמו כן הקשרים בין ראוטרים הם מאוד דינמיים‪ .‬לכן מחלקים את האינטרנט‬
‫ל‪ ,Autonomous System‬אזור אוטונומי‪ ,‬ובכל אזור ניתן לקבוע באיזה אלגוריתם ניתוב להשתמש‪ .‬כאשר‬
‫רוצים לדבר עם נתב מחוץ לאזור האוטונומי שלך צריך להשתמש בפרוטוקול ‪ BGP‬עליו נדבר בהמשך‪.‬‬

‫‪Dijkstra's link-state routing algorithms‬‬

‫דייקסטרה הוא אלגוריתם שפותר את בעית המסלולים הקצרים ביותר על גרף ממושקל ופרוטוקול ‪OSPF‬‬
‫מבוסס עליו‪.‬‬
‫נסתכל על דוגמה‪-‬‬

‫‪ .1‬מתחילים מקודקוד מקור‪ u ,‬ובודקים את השכנים שלו והעלות להגיע אליהן‪ ,‬מעדכנים בטבלה אם‬
‫העלות להגיע אליהן כעת קטנה ממה שחישבנו קודם לכן(בשלב הראשון הכל ∞) ולוקחים את‬
‫המינימלי מבינהם‪ ,‬במקרה הזה העלות של ‪ 3‬לקודקוד ‪.w‬‬
‫‪ .2‬מבצעים כיווץ קודקודים של ‪ u‬ו ‪ w‬וכעת בודקים את השכנים של שניהם‪ .‬ניתן לראות שהעלות להגיע‬
‫ל‪ x‬יקרה יותר ולכן אם עושים זאת דרך ‪ w‬ולכן לא מעדכנים אבל להגיע ל ‪ v‬כן קצר יותר כי העלות‬
‫היא ‪ 6‬ולכן מעדכנים בטבלה‪.‬‬
‫‪ .3‬ממשיכים כך עד שמכסים את כל הקודקודים‪.‬‬
‫‪ .4‬נשים לב שגם שומרים בטבלה מי הקודקוד שממנו הגענו כדי שנוכל לבנות מסלול‪.‬‬

‫נסתכל על דוגמה נוספת‪-‬‬

 ‫ביצענו את האלגוריתם וקיבלנו את המסלולים הנ״ל‪ ,‬אם נפשט את זה נקבל‬

‫כעת עם הגרף הזה ניתן לבנות את ה‪ .forward table‬בהתאם ליעד‪ ,‬נוסיף את הממשק (השכן) שהכי קצר‬
‫להגיע ממנו ליעד הסופי‪ .‬למשל עבור הגרף הנ״ל הטבלה תיראה ככה‬

‫‪ .1‬ל ‪ - v‬הכי קצר להגיע דרכו ישירות‪.‬‬

‫‪ .2‬ל ‪ - x,y,w,z‬הכי קצר להגיע דרך ‪ x‬ולכן הם ימופו לאותו הלינק‪.‬‬

‫מה שהראנו עד כה זה לא הפרוטוקול ניתוב אלא רק חלק ממנו שמשתמש בדיקסטרה‪ .‬נשים לב שכל נתב‬
‫צריך להריץ דייקסטרה בעצמו וגם בעיות נוספת שעולות‪:‬‬

‫איך ראוטר יודע איזה ראוטרים הם שכנים שלו בכלל?‬

‫העלות יכולה להשתנות לפי ‪ ,traffic volume‬כלומר אם המשקלים תלוים בעלות התעבורה שעברה‬
‫בערוץ בזמן הרצת דייקסטרה‪ .‬המצב הזה יכול לגרום לכך שכל הפקטות עוברות באותו מסלול מה‬
‫שגורם בכל ריצה לכיוון של המסלול להתחלף‬

‫‪Routing Information protocol‬‬

‫‪ RIP‬הוא פרוטוקול שמשתמש באלגוריתמים שמבוססים על וקטורי מידע (במקרה הזה ‪distance vector‬‬
‫כפי שמיד נראה) כדי לחשב את המסלול בין הראוטרים‪.‬‬

‫‪Distance vector algorithm‬‬

‫משתמש במשוואת בלמן פורד ולא מצריך את כל מצב הערוצים בגרף אלא כל ראוטר יעביר לשכניו את‬
‫וקטור המרחקים שלו‪ .‬וקטור המרחקים הוא וקטור שמראה לאן הם יודעים להגיע ובאיזה עלות‪ .‬נזכיר‬
‫שמשוואת בלמן פורד אומרת‬

‫} )‪D x (y) = min{c x,v + D v(y‬‬

‫‪v‬‬

‫כלומר העלות המינימלית מ ‪ x‬ל ‪ y‬היא המינימום מבין העלות של ‪ x‬להגיע לשכן שלו ‪ + v‬עלות ההגעה מ‬
‫‪ v‬ל ‪.y‬‬

‫נסתכל על דוגמה שבה כל הקודקוד ‪ x,v,w‬מדווחיםל ‪ u‬את העלות המינימלית שלהם ל‪z‬‬

‫מתקיים‬

‫‪D u (z) = min(c u,v + D y (z), c u,x + D x (z), c u,w + D w (z)) = 4‬‬

‫‪ .1‬נשים לב שבשיטה הזאת נוכל להגיע למצב של מעגלים כי אין לנו מידע על כל הגרף‪.‬‬
‫‪ .2‬כמו כן‪ ,‬גם כאן אם המידע משתנה קודקודים צריכים לעדכן את שכניהם בוקטור המעודכן אבל זה‬
‫דורש פחות עדכונים מאשר להריץ דייקסטרה מחדש‪.‬‬

‫נסתכל על דוגמה נוספת‪-‬‬

 ‫‪ .1‬ניתן לראות שוקטור המרחקים של ‪ x, y, z‬מכיל רק את המרחקים לשכנים שלהם בהתחלה ובכל‬
‫האחרים שם ∞ ‪.‬‬
‫‪ .2‬בשלב הראשונים כל אחד מדווח את וקטור המרחקים שלו לשני שכניו‪ .‬הם מריצים את משוואת בלמן‬
‫פורד וניתן לראות שכתוצאה מהרצת המשוואה וקטור המרחקים של ‪ x‬השתנה וגם של ‪.z‬‬
‫‪ .3‬כתוצאה מהעדכון שניהם שולחים את וקטור השכנים המעודכן לשכנים שלהם (‪ x, y‬עבור ‪ z‬ו ‪z, y‬‬
‫עבור ‪ y , )x‬לא שולח מחדש כי הוא לא עדכן‪.‬‬
‫‪ .4‬כעת כל מי שקיבל את וקטור המשתנים המעודכן‪ ,‬מריץ בדיקה ורואה ששום דבר לא השתנה‬
‫והאלגוריתם נעצר‪.‬‬

‫‪:link cost changes‬‬

‫כפי שאמרנו קודקודים שעלותם משתנה מעדכנים את השכנים שלהם והם צריכים לחשב את הוקטור שלהם‬
‫מחדש‪ .‬נשים לב לתופעה מעניינת ״חדשות טובות מתפשטות מהר״‪ .‬נדגים למשל עם הגרף הבא‪:‬‬

‫‪ .1‬בהתחלה ‪ y‬מזהה את השינוי ומעדכן את הוקטור שלו‪.‬‬

‫‪ .2‬לאחר מכן ‪ y ,‬מתריע על כך ל ‪ z‬שמשנה גם הוא את העלות שלו ל ‪ x‬ושולח הודעה לשכנים‪.‬‬
‫‪ y .3‬מקבל את המידע והעלות שלא לא משתנה אז הוא מפסיק להפיץ‪.‬‬

‫אבל כמו שחדשות טובות מתפשטות מהר ככה גם ״חדשות רעות מתפשטות לאט״‪:‬‬

‫‪ y .1‬רואה את השינוי אבל רואה ש‪ z‬מגיע ל ‪ x‬בעלות ‪ .5‬מסיבה זאת ‪ y‬מודיע ל‪ z‬שהעלות החדשה שלו‬
‫ל‪ x‬תהיה ‪ 6‬דרך ‪.z‬‬
‫‪ z .2‬מזהה שהעלות ל‪ x‬דרך ‪ y‬עולה ‪ 6‬אז ‪ z‬מחשב מחדש שהעלות שלו היא ‪ 1‬ל‪ + y‬העלות מ ‪ y‬ל ‪x‬‬
‫שזה ‪ 6‬כלומר סך הכל ‪.7‬‬
‫‪ y .3‬מזהה את העלות החדשה מ ‪ z‬ל ‪ x‬כלומר ‪ 7‬ומחשב מחדש עלות של ‪.8‬‬
‫‪ .4‬התהליך הזה חוזר שוב ושוב עד שהעלות עולה על ‪ , 50‬רק בשלב הזה ‪ z‬ו ‪ y‬יבינו שהמסלול בכלל ל‬
‫‪ x‬הוא מצד השני‪.‬‬

‫התופעה הזאת נקראת ‪count to infinity‬‬

‫אז איך ‪ RIP‬משתמש באלגוריתם הזה?‬

‫‪ .1‬המשקלים בין הקשתות הם תמיד ‪.1‬‬

‫‪ .2‬כל ‪ 30‬שניות שולחים לשכנים את וקטור המרחקים גם אם הוא לא השתנה‪.‬‬
 ‫‪ .3‬אם אחרי ‪ 180‬לא התקבל עדכון משכן‪ ,‬מבחינת אותו ראוטר הקשת כבר לא קיימת ומעדכנים את‬
‫הטבלה כאילו הוא לא קיים‪.‬‬
‫‪ .4‬כדי להמנע ממצב של ‪ count to infinity‬משתמשים בשיטה שנקראת ‪ ,poison reverse‬בשיטה זאת‬
‫מגדירים שהמרחק הכי רחוק למסלול הוא ‪ .16‬כלומר מגבילים את אורך המסלול הארוך ביותר להיות‬
‫‪ 16‬וככה גם יודעים שזה ה‪ count to infinity‬הארוך ביותר האפשרי‪.‬‬

‫חישובים בבעיות הניתוב‬

‫נסתכל על הגרף הבא‪-‬‬

‫הגרף מכיל את הנתונים הבאים‪:‬‬

‫‪ A .1‬רוצה להוריד קובץ בגודל ‪ 5KB‬מ ‪ G‬ב ‪ .HTTP1.1‬מה הנתיב שיעברו בין החבילות בעזרת ‪?RIP‬‬
‫‪ A .2‬רוצה להוריד ‪ 2‬קבצים מ ‪ G‬בגודל ‪ 3KB‬כל אחד באזרת ‪ OSPF‬ב ‪.HTTP1.1‬‬
‫‪ .3‬אותו הדבר אבל הפעם ‪ D‬הוא פרוקסי‪.‬‬

‫נבין כיצד ניגשים לבעיה הזאת‪ .‬ראשית‪ ,‬מכיוון ש ‪ RIP‬הוא פרוטוקול מסוג )‪ Distance Vector (DV‬אזי כל‬
‫נתב לומד את המרחקים לכל היעדים דרך שכניו‪ .‬ב‪ RIP‬אנחנו מעדיפים את המסלול הקצר ביותר מבחינת‬
‫מספר הקפיצות‪ .‬לאחרמ ספר סיבובים תחנה ‪ A‬תלמד מתחנה ‪ D‬שהיא יכולה להגיע דרכה ל ‪ G‬במסלול‬
‫הקצר ביותר‪.‬‬

‫נזכיר שבמהלך השידוך היחס בין גודל החלון וקצב השידור מתהפכים בהתאם לנוסחה‬
‫‪i−1‬‬
‫‪2‬‬ ‫‪⋅ d tran ≥ RT T‬‬

‫אם נציב לפי הנתונים שקיבלנו יתקיים‬

 ‫‪3‬‬ ‫‪3‬‬ ‫‪4‬‬ ‫‪5‬‬
‫‪10 B‬‬ ‫‪(10‬‬ ‫‪+ 40)B‬‬ ‫‪2 ⋅ 10 m‬‬ ‫‪2 ⋅ 10 m‬‬
‫‪i−1‬‬
‫‪2‬‬ ‫⋅‬ ‫⋅ ‪≥ 2‬‬ ‫⋅ ‪+ 2‬‬ ‫⋅ ‪+ 2‬‬
‫‪6‬‬ ‫‪6‬‬ ‫‪8‬‬ ‫‪8‬‬
‫‪10 Bps‬‬ ‫‪10 Bps‬‬ ‫‪2 ⋅ 10 mps‬‬ ‫‪2 ⋅ 10 mps‬‬

‫‪i−1‬‬ ‫‪−3‬‬
‫‪2‬‬ ‫‪⋅ 10‬‬ ‫‪≥ 4.28ms → i > 3‬‬

‫המכפלות פי ‪ 2‬זה בגלל שעוברים שתי ראוטרים עד שמגיעים ליעד ובחזרה‪ A .‬ל ‪ G‬דרך ‪ D‬ובחזרה‪.‬‬
‫כלומר‪ ,‬כאשר גודל החלון גדול יותר מ‪ 4‬חבילות‪ .‬אבל‪ ,‬יש לנו סך הכל ‪ 5‬חבילות לשדר (כי הקובץ‬
‫הוא ‪ 5‬וה ‪ mss‬הוא ‪ )1‬כך שלא נגיע לזה‪.‬‬
‫סך הכל שידרנו ‪ 3‬חלונות ולכן הזמן כולו היה‬
‫‪−5‬‬
‫‪3RT T + 10‬‬ ‫‪+ connection establishment‬‬

‫כעת לסעיף השני‪ ,‬משתמשים כעת ב ‪ OSPF‬כלומר צריך לחשב את משקלי הקשתות‪ ,‬השהיית‬
‫ההתפשטות לכל קשת‪ .‬נקבל‪:‬‬

‫כעת המסלול הקצר ביותר הוא ‪ .A → B → F → G‬נשים לב שמכיוון שמדובר בחיבור ‪ persistent‬אזי נוכל‬
‫לבקש את שני המשאבים באותו חיבור‪ ,‬לא נצטרך שני חיבורים נפרדים‪ .‬אם מדובר בחיבור ‪ pipelining‬אז‬
‫נוכל לשלוח את שתי הבקשות אחת אחרי השנייה בלי לחכות‪ .‬אם מדובר בחיבור ללא ‪ ,pipelining‬אזי‬
‫נבקש משאב‪ ,‬נוריד אותו ואז נבקש את המשאב הבא על גבי אותו חיבור וננצל את גודל החלון‪ .‬אם היינו‬
‫צריכים לפתוח חיבור נפרד‪ ,‬גודל החלון היה מתאפס בחיבור החדש‪.‬‬

‫נשים לב‪ ,‬שהורדת המשאב הראשון תהיה בעזרת החלון החילון והשני בחיבור ואילו הורדת המשאב‬
‫השלישי תהיה בעזרת החלון השלישי בלבד‪.‬‬

‫לגבי הסעיף האחרון‪ ,‬כעת יש פרוקסי‪ ,‬אזי ‪ A‬יפתח חיבור ‪ TCP‬מול הפרוקסי ויבקש את המשאב ממנו‪D .‬‬
‫יפתח חיבור נפרד מול ‪ G‬ויבקש את המשאב‪ .‬יוריד את המשאב ואז יעביר אותו ל ‪.A‬‬