מאַקסימום טראַנסמיסיע יוניט (מטו)

מאַקסימום טראַנסמיסיע אַפּאַראַט (MTU)

אין קאָמפּיוטער נעטוואָרקינג, דער טערמין מאַקסימום טראַנסמיסיע יוניט (מטו) רעפערס צו די גרייס (אין ביטעס) פון דעם גרעסטן פּדו אַז אַ געגעבן שיכטע פון אַ קאָמוניקאַציע פּראָטאָקאָל קענען פאָרן אַנווערדז. MTU פּאַראַמעטערס יוזשאַוואַלי דערשייַנען אין פאַרבאַנד מיט אַ קאָמוניקאַציע צובינד (ניק, סיריאַל פּאָרט, עטק.). די MTU קען זיין פאַרפעסטיקט דורך סטאַנדאַרדס (ווי איז דער פאַל מיט עטהערנעט) אָדער באשטימט אין פאַרבינדן צייט (ווי איז יוזשאַוואַלי דער פאַל מיט סיריאַל פֿאַרבינדונגען פונט צו פונט). א העכער MTU ברענגט אַ גרעסערע עפעקטיווקייט ווייַל יעדער פּאַקאַט קאַריז מער באַניצער דאַטן בשעת פּראָטאָקאָל אָוווערכעדז, אַזאַ ווי כעדערז אָדער אַנדערלייינג פּער-פּאַקאַט דילייז בלייבן פאַרפעסטיקט, און העכער עפעקטיווקייַט מיטל אַ קליין פֿאַרבעסערונג אין פאַרנעם פּראָטאָקאָל טרופּוט. אָבער, גרויס פּאַקיץ קענען נעמען אַ פּאַמעלעך פֿאַרבינדונג פֿאַר עטלעכע מאָל, קאָזינג גרעסער דילייז צו די פאלגענדע פּאַקיץ און ינקריסינג אָפּשטיי און מינימום לייטאַנסי. צום ביישפּיל, אַ 1500 בייט פּאַקאַט, די גרעסטע ערלויבט דורך עטהערנעט אין די נעץ שיכטע (און דעריבער רובֿ פון די אינטערנעט), וואָלט בינדן אַ 14.4 ק מאָדעם פֿאַר וועגן איין סעקונדע.

דרך MTU ופדעקונג
דער אינטערנעץ פּראָטאָקאָל דיפיינז די "דרך מטו" פון אַן אינטערנעץ טראַנסמיסיע דרך ווי דער קלענסטער מטו פון קיין פון די IP כאַפּס פון די "דרך" צווישן אַ מקור און דעסטיניישאַן. אין אן אנדער וועג, MTU דרך איז די גרעסטע פּאַקאַט גרייס וואָס גייט דורך דעם דרך אָן ליידן פראַגמאַנטיישאַן.

RFC 1191 באשרייבט "Path MTU discovery", אַ טעכניק פֿאַר דיטערמאַנינג די דרך MTU צווישן צוויי IP מחנות. עס אַרבעט דורך באַשטעטיקן די DF (דו זאלסט נישט פראַגמענט) אָפּציע אין די IP כעדערז פון אַוטגאָוינג פּאַקיץ. קיין מיטל אויף דעם דרך וועמענס MTU איז קלענערער ווי די פּאַקאַט, וועט פאַלן אַזאַ פּאַקיץ און שיקן אַן ICMP אָנזאָג "דעסטינאַטיאָן ונרעאַטשאַבלע (דאַטאַגראַם צו גרויס)" מיט זיין MTU, וואָס אַלאַוז די מקור באַלעבאָס צו רעדוצירן די נויטיק MTU דרך. דער פּראָצעס ריפּיץ ביז די MTU איז קליין גענוג צו דורכגיין די גאנצע דרך אָן פראַגמאַנטיישאַן.

איר קען אויך זיין אינטערעסירט צו זען: 2 WIRE ראָוטער קאַנפיגיעריישאַן

צום באַדויערן, ינקריסינג נומער פון נעטוואָרקס קאַפּ ICMP פאַרקער (למשל צו פאַרמיידן אָפּלייקענונג פון סערוויס אנפאלן), וואָס פּריווענץ די וועג MTU ופדעקונג פון ארבעטן. מען אָפט דיטעקץ אַזאַ בלאַקינג אין די קאַסעס ווען אַ קשר אַרבעט פֿאַר נידעריק-באַנד דאַטן אָבער כאַנגז ווי באַלד ווי אַ באַלעבאָס סענדז אַ גרויס בלאָק פון דאַטן אין אַ צייט. צום ביישפּיל, מיט IRC, אַ קאַנעקטינג קליענט קען זען די פּינג אָנזאָג, אָבער נאָך קיין ענטפער. דאָס איז ווייַל די גרויס גאַנג פון באַגריסונג אַרטיקלען זענען געשיקט אין פּאַקידזשיז גרעסער ווי די פאַקטיש MTU. אין אַן IP נעץ, דער דרך פֿון די מקור אַדרעס צו די דעסטיניישאַן אַדרעס איז אָפט דינאַמיקאַללי מאַדאַפייד אין ענטפער צו פאַרשידן געשעענישן (מאַסע-באַלאַנסינג, קאַנדזשעסטשאַן, אַוטפּוץ, עטק.) ריפּיטיד) בעשאַס אַ טראַנסמיסיע, וואָס קען פאָרשטעלן ווייַטער פּאַקאַט טראפנס איידער דער באַלעבאָס געפינט די נייַע זיכער MTU.

רובֿ עטהערנעט לאַנס נוצן אַ MTU פון 1500 ביטעס (מאָדערן לאַנס קענען נוצן דזשאַמבאָו ראָמען, וואָס אַלאַוז MTU אַרויף צו 9000 ביטעס), אָבער גרענעץ פּראָטאָקאָלס ווי PPPoE וועט רעדוצירן דעם. דער פאַקט אַז MTU ופדעקונג קומט אין ווירקונג מיט די מעגלעך רעזולטאַט פון מאכן עטלעכע זייטלעך הינטער באַדלי קאַנפיגיערד פירעוואַללס אַנריטשאַבאַל. דאָס איז מעגלעך, דיפּענדינג אויף וואָס טייל פון די נעץ איר קאָנטראָל; צום ביישפּיל, איר קענט טוישן די MSS (מאַקסימום אָפּשניט גרייס) אין די ערשט פּאַקאַט וואָס שטעלן די TCP פֿאַרבינדונג ביי די פיירוואַל.

דער פּראָבלעם איז אָפט סערפיסט זינט די הקדמה פון Windows Vista וואָס ינטראַדוסיז די 'קומענדיקע דור TCP/IP סטאַק'. דאָס ימפּלאַמאַנץ "באַקומען אַוטאָ-טונינג פֿענצטער פֿענצטער וואָס קאַנטיניולי באַשטימט די אָפּטימאַל גרייס פון די באַקומען פֿענצטער דורך מעסטן די באַנדווידט-פאַרהאַלטן פּראָדוקט און די אַפּגרייד קורס און אַדזשאַסץ די מאַקסימום באַקומען פֿענצטער גרייס באזירט אויף טשאַנגינג נעץ טנאָים." [2] דאָס איז קאַנדזשאַנגקשאַן מיט עלטערע ראָוטערס און פירעוואַללס וואָס האָבן אַפּערייטאַד מיט אנדערע אָפּערייטינג סיסטעמען. דאָס איז אָפט געפֿונען אין ADSL ראָוטערס און קען אָפט זיין רעקטאַפייד דורך אַ פירמוואַרע דערהייַנטיקן.

איר קען אויך זיין אינטערעסירט צו זען: מעדאַסאַנז גענומען אין אפגעזונדערטקייט האָספּיטאַלס

אַטם באַקבאָונז, אַ ביישפּיל פון MTU טונינג
טייל מאָל עס איז בילכער פֿון עפעקטיווקייט צו אַרטיפיסיאַללי דערקלערן אַ רידוסט MTU אין ווייכווארג אונטער די אמת מאַקסימום מעגלעך לענג. איין ביישפּיל פון דעם איז דער פאַל ווען IP פאַרקער איז טראַנספערד איבער אַ אַטם (אַסינטשראָנאָוס טראַנספער מאָדע) נעץ. עטלעכע פּראַוויידערז, דער הויפּט יענע מיט אַ טעלעפאָן הינטערגרונט, נוצן אַטם אויף זייער ינערלעך באַקבאָון נעץ.

אַטם מיט אָפּטימום עפעקטיווקייַט איז אַטשיווד ווען פּאַקאַט לענג איז אַ קייפל פון 48 ביטעס. דאָס איז ווייַל אַטם איז געשיקט ווי אַ טייַך פון פּאַקיץ מיט פאַרפעסטיקט לענג (באַוווסט ווי 'סעלז'), וואָס יעדער פון זיי קענען טראָגן אַ נוץ פון 48 ביטעס פון באַניצער דאַטן מיט 5 ביטעס אָוווערכעד פֿאַר אַ גאַנץ פּרייַז פון 53 ביטעס פּער צעל. די גאַנץ לענג פון די טראַנסמיטטעד דאַטן לענג איז 53 * נאָסעללס ביטעס, ווו נעללס = די נומער פון פארלאנגט סעלז = INT ((פּיילאָוד_לענגטה+47)/48). אין די ערגסט פאַל, ווען די גאַנץ לענג = (48*ן+1) ביטעס, איר דאַרפֿן איין נאָך צעל צו אַריבערפירן די לעצטע בייט פון פּיילאָוד, די לעצטע צעל קאָס אַן עקסטרע 53 טראַנסמיטטעד ביטעס, 47 פון וואָס זענען וואַטן. צוליב דעם, אַרטיפיסיאַללי דערקלערן אַ רידוסט MTU אין ווייכווארג מאַקסאַמייזיז פּראָטאָקאָל עפעקטיווקייַט ביי די אַטם שיכטע דורך מאכן די אַטם אַאַל 5 גאַנץ פּיילאָוד לענג אַ קייפל פון 48 ביטעס ווען מעגלעך.

צום ביישפּיל, 31 גאָר אָנגעפילט אַטם סעלז האָבן אַ נוץ פון 31*48 = 1488 ביטעס. אויב מיר נעמען דעם ציפער פון 1488 און אַראָפּרעכענען פֿון עס אַלע אָוווערכעדז קאַנטריביוטיד דורך אַלע באַטייַטיק העכער פּראָטאָקאָלס, מיר קענען באַקומען אַ סאַגדזשעסטיד ווערט פֿאַר אַ קינסטלעך רידוסט אָפּטימאַל MTU. אויב דער באַניצער וואָלט נאָרמאַלי שיקן 1500 בייט פּאַקיץ, שיקט צווישן 1489 און 1536 ביטעס ריקווייערז אַן נאָך פאַרפעסטיקט קאָס פון 53 ביטעס טראַנסמיטטעד אין די פאָרעם פון אַן עקסטרע אַטם צעל.

איר קען אויך זיין אינטערעסירט צו זען: ווי צו לייגן MTU אין zxhn h108n

צום ביישפּיל פון 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 כעדערז. אין דעם ביישפּיל, זיך-ימפּאָוזד רידוסט מטו פון 1478, קעגן שיקט IP פּאַקיץ מיט אַ גאַנץ לענג פון 1500 סאַוועס 53 ביטעס פּער פּאַקאַט ביי די אַטם שיכטע אין אַ פּרייַז פון אַ 22 בייט רעדוקציע פון די לענג פון IP פּאַקיץ.

א מאַקסימום MTU פֿאַר PPPoE/DSL קאַנעקשאַנז איז 1492 פּער RFC 2516: 6 ביטעס זייַנען PPPoE כעדער, וואָס לאָזן גענוג פּלאַץ פֿאַר אַ 1488 בייט פּיילאָוד אָדער 31 פול אַטם סעלז.

צום סוף: דער נאָרמאַל ווערט פון MTU איז 1492 .... און אין פאַל פון בראַוזינג פּראָבלעמס אָדער MSN קאַנעקטיוויטי פּראָבלעמס, עס זאָל זיין רידוסט צו די וואַלועס 1422 און 1420.

רעפערענץ: וויקיפעדיע

בעסטער גרוס