האם MTU קטן יותר ב־VPN מהיר יותר? השוו את הראיות בפועל
MTU נמוך יותר יכול לעקוף מגבלה של נתיב ועדיין לעלות בתפוקה. השוו את המגבלה האמיתית, את תקורת הכותרות ואת העומס לפני שתשאירו את השינוי.
מנהרה מפילה העברות גדולות אך מעבירה פינג, ולכן העצה מגיעה מהר: הנמיכו את ה־MTU. התיקון עובד לפעמים, ואז הוא מוחל על כל פרופיל בכל רשת. בנקודה הזו תיקון ממוקד הופך למיס קבוע על הביצועים. ההשוואה שצריך לעשות היא בין המגבלה האמיתית של הנתיב לבין העלות של הקטנת כל מנה מתחתיה.
מה באמת מתכווץ כשמנמיכים את ה־MTU
כל מנה נושאת כותרות לפני שהיא נושאת את הנתונים שלכם. בנתיב אתרנט של 1500 בייט, IPv4 ו־TCP צורכים 40 בייט ומשאירים 1460 למטען; הכימוס מוסיף מעליהם כותרות חיצוניות של IP, UDP ומנהרה, ולכן תקציב המטען הפנימי יורד שוב. הנמכת ה־MTU של הממשק מקטינה את התקציב הזה בכוונה.
העלות פרופורציונלית למספר המנות, לא למספר הבייטים. אותו קובץ שמפוצל ליותר מנות דורש יותר פסיקות, יותר החלטות ניתוב ויותר עיבוד לכל מנה בכל התקן לאורך הנתיב. בנתב שכבר קרוב למגבלת המנות לשנייה שלו, זו האטה אמיתית ולא שגיאת עיגול. העלות מופיעה גם כשההעברה עצמה מצליחה.
לכן MTU קטן יותר הוא עקיפה של מגבלה, לא אופטימיזציה כללית. הוא קונה אמינות מול נתיב שאינו יכול לשאת את המסגרת הגדולה יותר, והוא גובה תקורה על כל מנה שלא היה צריך את ההקטנה.
מתי MTU קטן יותר הוא התיקון הנכון
התסמין הקלאסי ספציפי: לחיצת היד של TCP מושלמת, תגובות קטנות מגיעות, והורדה גדולה נתקעת או מתאפסת. פינג עם סיבית אל־תפצל ב־1472 בייט נכשל בעוד פינג של 1400 בייט מצליח, מה שמצביע על נתיב שאינו יכול לשאת מנה בגודל מלא ואינו מוסר את הודעת ה־ICMP שהייתה אומרת לשולח להקטין.
גילוי ה־MTU של הנתיב תלוי באותן הודעות ICMP על צורך בפיצול. כשחומת אש מפילה אותן, השולח ממשיך לנסות שוב את המנה הגדולה והחיבור נראה תלוי. הנמכת ה־MTU בצד המנהרה מונעת את הניסיון החוזר, וזה תיקון לגיטימי לאותה רשת.
גם טכנולוגיות גישה מציבות מגבלות משלהן: PPPoE בדרך כלל מוגבל ל־1492, חלק מנתיבי הסלולר וה־DSL נמוכים יותר, ומנהרות מקוננות מחסירות את התקורה פעמיים. מדדו את הנתיב בפועל במקום להעתיק מספר ממדריך, וזכרו ש־IPv6 דורש לפחות 1280 בייט של MTU בכל קישור שנושא אותו, כפי שקובע RFC 8200.
השוו את שלושת הבקרים לפני שתשנו אחד
MTU, MSS ופיצול הם בקרים שונים בשכבות שונות, ושינוי הבקר הלא נכון משאיר את התסמין במקומו.
| Control | Layer | What it changes | Where it misleads |
|---|---|---|---|
| Interface MTU | IP link | Largest frame the interface will send | Penalizes every protocol, not just the one that failed |
| TCP MSS clamp | TCP | Segment size advertised in the handshake | Leaves UDP and QUIC untouched |
| DF and fragmentation | IP | Whether a router may split a packet | Can break path MTU discovery and security assumptions |
| Tunnel overhead | Encapsulation | Inner MTU after outer headers | Mismatch shows up only for large inner packets |
הגבלת MSS היא לעתים קרובות התיקון הפחות פולשני כי היא משפיעה רק על TCP ומשאירה את הממשק פנוי לתעבורה אחרת. MTU ממשק נמוך יותר רחב יותר וקל יותר לנימוק, ולכן הוא נפוץ בנתבים ביתיים, אבל הוא גובה מכל פרוטוקול את הבעיה של פרוטוקול אחד.
ביטול התנהגות אל־תפצל מסתיר את התסמין בכך שהוא מאפשר פיצול, והוא בדרך כלל מחמיר את ההשהיה תוך שבירת המשוב שהיה מוצא את הגודל הנכון. הימנעו ממנו כתיקון קבוע.
מדדו את הפשרה ולא מספר אחד
מצאו את מגבלת הנתיב עם בדיקת אל־תפצל, התחילו גבוה ורדו עד שהתשובה מגיעה:
ping -M do -s 1472 203.0.113.10
ping -M do -s 1400 203.0.113.10
tracepath 203.0.113.10לאחר מכן השוו את המשימה האמיתית בשתי ההגדרות: אותה העברת קובץ, אותו נקודת קצה ואותה רשת. תעדו את זמן ההשלמה ואת השידורים החוזרים, למשל עם nstat -az TcpRetransSegs, ועקבו אחר המעבד של ההתקן אם המנהרה מסתיימת בנתב קטן. בדיקת תפוקה סינתטית קצרה עלולה להחמיץ את התקיעה שמופיעה רק לאחר כמה מגה־בייט.
מונה המנות יעלה לאחר הקטנה כי אותה העברה משתמשת כעת ביותר מנות. זה צפוי וזה אינו הוכחה לתפוקה גבוהה יותר. השוו נתוני יישום שהושלמו, מספר השידורים החוזרים ואת ההיענות, ולא רק את קצב המנות.
הכניסו את השינוי בהדרגה ושמרו אותו מוגבל
תעדו את הערך המקורי, שנו בקר אחד, וחזרו על המדידה לפני שתהפכו אותה לקבועה. אם הראיות אינן מראות תועלת, החזירו את הערך הקודם עם אותה פקודת ממשק שבה השתמשתם כדי לקבוע אותו:
ip link set dev wg0 mtu 1420
ip link set dev wg0 mtu 1500הגבילו את התוצאה לרשת שהייתה זקוקה לה. פרופיל שחייב לעבוד ב־Wi-Fi של מלון, בנקודת גישה סלולרית וב־LAN של משרד לא צריך לרשת את הערך הנמוך ביותר שאחד מהם דורש, אלא אם הלקוח אינו יכול לגלות את הנתיב.
הערך הנכון הוא ה־MTU הגדול ביותר ששורד את הנתיב, לא הקטן ביותר שמעלים את התסמין. תעדו את הנתיב, את תוצאת הבדיקה ואת החזרה לאחור, וחזרו לבחון את ההגדרה כשהרשת הגישה משתנה.