היי חברים, שאלה קצרה לי אליכם בעניין מודל שבע השכבות.

יש לי בעיה בהבנה של שתי שכבות מסויימות וההבדל ביניהן.

הבעיה שלי היא עם שכבות 2 (Data Link) ו-3 (Network).

אני יודע ששכבת ה-NETWORK עובדת ברמה הלוגית (IP כדוג') ומעבירה את ה-DATA בפאקטים (Packets). כמו כן, שכבת ה-DATA LINK עובדת ברמה הפיזית (MAC Address) ומעבירה את ה-DATA בפריימים (Frames).

השאלה שלי היא, מה בעצם ההבדל בין הפאקטים לפריימים? האם, אחרי ששכבת ה-NETWORK לוקחת את המידע ומחלקת אותו לפאקטים, שכבת ה-DATA LINK לוקחת את הפאקטים עצמם ומפרקת אותם לפריימים (ומוסיפה Headers של CRC ומקור ויעד)?

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

תודה מראש יקיריי

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

כל שכבה מכמסת (encapsulates) את השכבות שמעליה. כדי שהפאקטים של ה IP שלך יעברו הלאה בין מחשבים (ו/או ראוטרים), הם עוברים על תווך כלשהוא - ה Data Link. בהתאם לסוג ה Data Link (למשל ב Ethernet זה פריימים כמו שאמרת), כל הפאקט נעטף במידע הנחוץ להעברה ב Data Link (למשל Source MAC / Destination MAC / Ethernet Version) - ואז נשלח על גבי הכבל הפיזי. זה לא פירוק אלא "עטיפה"...

אולי התרשים הזה יעזור: http://cs.uccs.edu/~cs522/msgformat/hw1_ht1.gif

נמאס לכם לזכור סיסמאות? לחצו כאן!

אז האם התיאור הבא הוא נכון?

שכבת ה-NETWORK מקבל את המידע מהשכבה שמעליה, והיא כן מחלקת את המידע הזה לפאקטים (במידה ומדובר על Connection-Oriented). ולאחר מכן שכבת ה-DATA LINK מקבל כל פאקט ועוטפת אותו ב-Header שלה (Source, Dest. MAC Address + CRC), ובכך כל פאקט הופך לפריים וכן הלאה (הפריימים עוברים לשכבה הראשונה ולאחר מכן מגיעים למחשב השני ועושים את אותו התהליך בצורה הפוכה)?

ועוד שאלה, מדוע מתבצעת החלוקה לפאקטים ולא כל המידע נשלח בפעם אחת? זה בכדי ליצור נ"צ כך שאם במקרה נכשלת העברת המידע אז לא יהיה צורך להתחיל מההתחלה?
או שאולי זה מפני שהפאקטים לא נשלחים באותו סדר? ואם זו התשובה, אז מדוע הם לא נשלחים באותו הסדר?

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

המידע מתחלק לפאקטים מהסיבה הפשוטה שהשכבה שמתחת למידע הזה, מוגבלת בעצמה בגודל מסויים (יש באפרים בחומרה שאליהם המידע נקלט, מאוחסן, ומועבר הלאה...) - וגם מהסיבה שציינת - אם מידע נופל בדרך (מה שיכול לקרות משלל סיבות...) - אפשר לשדר רק את חלקו מחדש (TCP Retransmission) - ולא את הכל.

שכבת ה IP מחלקת את ה stream של המידע של ה"חיבור" (במרכאות כי לא באמת מחובר צד אחד לצד השני בצורה פיזית, זה בדיוק ההבדל בין רשת circuit-switched לרשת packet-switched) כך שיתאים להעברה על כל התווך בין מכונת המקור למכונת היעד. ראוטרים בהמשך הדרך יכולים אף לבצע חלוקה נוספת של הפאקטים, אם לא ניתן להעבירם בגודלם המקורי מסיבות שונות (להלן: IP Fragmentation). אכן נעשה תהליך הפוך בצד השני.

פאקטים לא חייבים להגיע בסדר שנשלחו. בכל פעם שפאקט מגיע לנתב, הוא בוחר את הנתיב שנראה לו הטוב ביותר להעברה. בהחלט ייתכן ששני פאקטים של אותו חיבור, יעברו מסלול שונה לחלוטין, ולא מן הנמנע שפאקט ב' שנשלח אחרי פאקט א', יגיע פאקט ב' לפני פאקט א'. זה נקרא Packet re-ordering ול TCP, במנגנון יצירת ה Stream מחדש בצד השני, יש את היכולת לטפל בכך ולהפוך את המידע כך שיוצג לאפלקיציה בדיוק כפי שנשלח מהמקור. כשעובדים ב UDP (או בכל פרוטוקול שאינו TCP, בעצם), האפליקציה צריכה להניח לבד שאף אחד לא "יפצה" אותה על אובדן פאקטים או על Reordering - והיא צריכה (זאת אומרת - המתכנת צריך ) לממש את הטיפול בכך בעצמה.

נמאס לכם לזכור סיסמאות? לחצו כאן!

עוד לא התחלתי ללמוד את פרוטוקול ה-TCP/IP כך שאני מניח שאחרי שאלמד אותו ואראה איך הוא מתלבש על המודל - התגובה שלך תהיה לי יותר ברורה.

תודה

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

פעם ראיתי סימולציה ב-3D של כל המודל ואין לי את המקור אבל מצאתי עכשיו משהו דומה



לצפייה במקור באתר YouTube, לחצו כאן.

לצפייה במקור באתר YouTube, לחצו כאן.

ובעברית חחח


לצפייה במקור באתר YouTube, לחצו כאן.

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

נמאס לכם לזכור סיסמאות? לחצו כאן!