יחידת הילוכים מרבית (MTU)
ברשת מחשבים, המונח יחידת שידור מקסימלית (MTU) מתייחס לגודל (בתים) של ה- PDU הגדול ביותר ששכבה נתונה של פרוטוקול תקשורת יכולה להעביר הלאה. בדרך כלל מופיעים פרמטרים של MTU בשילוב עם ממשק תקשורת (NIC, יציאה טורית וכו '). MTU עשוי להיות קבוע על פי תקנים (כמו במקרה של Ethernet) או הוחלט בזמן חיבור (כפי שקורה בדרך כלל עם קישורים טוריים מנקודה לנקודה). MTU גבוה יותר מביא ליעילות רבה יותר מכיוון שכל חבילה נושאת יותר נתוני משתמשים בעוד תקורות פרוטוקול, כגון כותרות או עיכובים בסיסיים למנה נשארות קבועות, ויעילות גבוהה יותר פירושה שיפור קל בתפוקת פרוטוקול בתפזורת. עם זאת, מנות גדולות יכולות לתפוס קישור איטי במשך זמן מה, ולגרום לעיכובים גדולים יותר במעקב אחר מנות ולהגדלת השהייה וההשהיה המינימלית. לדוגמה, חבילת 1500 בתים, הגדולה ביותר שמותר Ethernet בשכבת הרשת (ומכאן שרוב האינטרנט), תחבר מודם של 14.4k למשך כשנייה אחת.
גילוי שביל MTU
פרוטוקול האינטרנט מגדיר את "נתיב MTU" של נתיב שידור אינטרנט כ- MTU הקטן ביותר מבין כל כשות ה- IP של "הנתיב" בין מקור ליעד. במילים אחרות, הנתיב MTU הוא גודל המנות הגדול ביותר שחוצה את הנתיב הזה מבלי לסבול פיצול.
RFC 1191 מתאר את "גילוי MTU נתיב", טכניקה לקביעת הנתיב MTU בין שני מארחי IP. זה עובד על ידי הגדרת האפשרות DF (Don't Fragment) בכותרות ה- IP של מנות יוצאות. כל מכשיר לאורך הנתיב שה- MTU שלו קטן מהחבילה יוריד מנות כאלו וישלח בחזרה הודעת ICMP "Destination Unreachable (Datagram Large מדי)" המכילה את ה- MTU שלו, ומאפשרת למארח המקורות להקטין את הנתיב MTU הנחוץ שלו כראוי. התהליך חוזר עד שה- MTU קטן מספיק כדי לעבור את כל הנתיב ללא פיצול.
לרוע המזל, מספר גדל והולך של רשתות מוריד את תעבורת ICMP (למשל למניעת התקפות מניעת שירות), מה שמונע מגילוי נתיבי MTU לפעול. לעתים קרובות אתה מזהה חסימה כזו במקרים שבהם חיבור פועל עבור נתונים בעוצמה נמוכה אך נתקע ברגע שמארח שולח גוש נתונים גדול בכל פעם. לדוגמה, עם IRC לקוח מחבר עשוי לראות עד הודעת הפינג, אך לא יקבל תגובה לאחר מכן. הסיבה לכך היא שהמערכת הגדולה של הודעות קבלת הפנים נשלחת במנות גדולות יותר מה- MTU האמיתי. כמו כן, ברשת IP, הנתיב מכתובת המקור לכתובת היעד משתנה לעתים קרובות באופן דינאמי, בתגובה לאירועים שונים (איזון עומס, עומס, תפוקות וכו ')-הדבר עלול לגרום לשינוי הנתיב MTU (לפעמים חוזר) במהלך שידור, שעשוי להכניס טיפות מנות נוספות לפני שהמארח ימצא את ה- MTU הבטוח החדש.
רוב רשתות ה- Ethernet משתמשות ב- MTU של 1500 בתים (רשתות LAN מודרניות יכולות להשתמש במסגרות ג'מבו, המאפשרות MTU עד 9000 בתים), אולם פרוטוקולי גבול כמו PPPoE יפחיתו זאת. זה גורם לגלות MTU הנתיב להיכנס לתוקף עם התוצאה האפשרית של הפיכת חלק מהאתרים מאחורי חומות אש שהוגדרו לא טוב. אפשר לעקוף את זה, תלוי באיזה חלק של הרשת שולטת; למשל אפשר לשנות את MSS (גודל הפלח המקסימלי) במנה הראשונית שמקימה את חיבור ה- TCP בחומת האש של האדם.
בעיה זו עלתה בתדירות גבוהה יותר מאז הוצגה Windows Vista המציגה את 'הדור הבא של TCP/IP Stack'. זה מיישם את "כוונון אוטומטי של חלון קבלה הקובע ללא הרף את גודל חלון הקבלה האופטימלי על ידי מדידת המוצר של עיכוב רוחב הפס וקצב אחזור היישומים ומתאים את גודל חלון הקבלה המרבי בהתאם לשינוי תנאי הרשת." [2] נראה כי הדבר נכשל בשילוב עם נתבים וחומות אש ישנים יותר שנראו כשעובדים עם מערכות הפעלה אחרות. זה נראה לרוב בנתבי ADSL ולעתים קרובות ניתן לתקן אותו באמצעות עדכון קושחה.
עמוד שדרה של כספומט, דוגמא לכוונון MTU
לפעמים עדיף מבחינת יעילות להכריז באופן מלאכותי על MTU מופחת בתוכנה מתחת לאורך המקסימלי האמיתי האפשרי הנתמך. דוגמה אחת לכך היא המקרה שבו תעבורת IP מועברת על גבי רשת כספומט (מצב העברה אסינכרוני). חלק מהספקים, במיוחד אלה עם רקע טלפוניה, משתמשים בכספומט ברשת השדרה הפנימית שלהם.
שימוש בכספומט ביעילות מיטבית מושגת כאשר אורך החבילה הוא כפולה של 48 בתים. הסיבה לכך היא כי כספומט נשלח כזרם של מנות באורך קבוע (המכונה 'תאים'), שכל אחת מהן יכולה לשאת מטען של 48 בתים של נתוני משתמש עם 5 בתים תקורה בעלות כוללת של 53 בתים לכל תא. אז האורך הכולל של אורך הנתונים המועבר הוא 53 * בתים של תאים, כאשר ncells = מספר התאים הנדרשים של = INT ((payload_length+47)/48). אז במקרה הגרוע ביותר, שבו האורך הכולל = (48*n+1) בתים, יש צורך בתא אחד נוסף כדי להעביר את הבייט האחרון של המטען, התא הסופי בעלות נוספת של 53 בתים ששודרו 47 מתוכם ריפוד. מסיבה זו, הצהרה מלאכותית על MTU מופחתת בתוכנה ממקסמת את יעילות הפרוטוקול בשכבת הכספומט על ידי כך שאורך אורך המטען הכולל של ATM AAL5 יהיה מכפלה של 48 בתים במידת האפשר.
לדוגמה, 31 תאי כספומט מלאים נושאים מטען של 31*48 = 1488 בתים. אם ניקח נתון זה של 1488 ונגרע ממנו את כל התקורות שתרמו מכל הפרוטוקולים הגבוהים הרלוונטיים, נוכל להשיג ערך מוצע עבור MTU אופטימלי מופחת באופן מלאכותי. במקרה שבו המשתמש היה שולח בדרך כלל 1500 מנות בתים, שליחה בין 1489 ל -1536 בתים דורשת עלות קבועה נוספת של 53 בתים המועברים בצורה של תא כספומט אחד נוסף.
לדוגמא של חיבורי IP באמצעות DSL באמצעות PPPoA/VC-MUX, שבוחרים שוב למלא 31 תאי כספומט כמו קודם, אנו מקבלים נתון MTU מופחת באופן אופטימלי של 1478 = 31*48-10 בהתחשב בתקורה של 10 בתים המורכבים של תקורה של פרוטוקול נקודה לנקודה של 2 בתים ותקורה של AAL5 של 8 בתים. זה נותן עלות כוללת של 31*53 = 1643 בתים המועברים באמצעות כספומט ממנת 1478 בתים שהועברה ל- PPPoA. במקרה של IP שנשלח באמצעות ADSL באמצעות PPPoA הנתון של 1478 יהיה האורך הכולל של חבילת ה- IP כולל כותרות IP. אז בדוגמה זו שמירה על MTU מופחתת של 1478 לעומת שליחת מנות IP באורך כולל של 1500 חוסכת 53 בתים למנה בשכבת הכספומט בעלות של הפחתה של 22 בתים באורך מנות ה- IP.
MTU מקסימלי לחיבורי PPPoE/DSL הוא 1492, לפי RFC 2516: 6 בתים כותרת PPPoE, מה שמשאיר מספיק מקום למטען 1488 בתים, או 31 תאי כספומט מלאים.
סוף כל סוף: הערך הסטנדרטי של MTU יהיה 1492 .... ובמקרה של בעיות גלישה או בעיות קישוריות MSN יש להוריד אותו לערכים 1422 ו- 1420.
התייחסות: ויקיפדיה
ד 'ש
שלום, תודה על המאמר השימושי