1. ما هو MTU فعلياً، بدون لغة الكتب الدراسية

MTU اختصار لـ"وحدة الإرسال القصوى" (Maximum Transmission Unit)، وإليك النسخة المبسّطة: إنه أكبر قطعة بيانات واحدة يقبل اتصال شبكتك إرسالها دفعة واحدة قبل أن يضطر لتقسيمها. تخيّله كشاحنة توصيل لا يمكنها حمل صناديق أكبر من حجم معين. أي شيء أكبر من ذلك يجب تقسيمه أولاً لصناديق أصغر، وشحنها بشكل منفصل، ثم إعادة تجميعها في الطرف الآخر. ذلك الحد الأقصى للحجم - بالنسبة لمعظم اتصالات الإنترنت المنزلية - هو 1500 بايت. كان المعيار للإيثرنت منذ الأزل تقريباً، وهذا بالضبط سبب عدم وجود سبب لدى أي أحد تقريباً للتفكير فيه.

تظهر المشكلة عندما يملك شيء ما في المسار بينك وبين وجهة بياناتك شاحنة أصغر. VPN مثلاً. أو اتصال قائم على PPPoE، الذي لا يزال العديد من مزودي خدمة DSL والألياف الضوئية يستخدمونه. كلاهما يضيف قدراً من التغليف الإضافي حول بياناتك - رؤوس (headers)، وحمل تشفير إضافي، ومعلومات نفق - وهذا يأكل من حد الـ1500 بايت دون أن تطلب ذلك أو تراه يحدث.

2. لماذا تهم القيمة الصحيحة فعلياً

هنا يظهر التأثير الفعلي عليك. إذا استمر جهازك بإرسال حزم بحجم 1500 بايت، لكن الحد الفعلي في مكان ما على طول المسار انكمش فعلياً إلى، لنقل، 1400، يحدث أحد أمرين. إما أن الحزمة الزائدة الحجم تُجزَّأ - تُقسَّم إلى أجزاء، تُرسَل بشكل منفصل، تُعاد تجميعها في الوجهة، مما يضيف حملاً إضافياً ويبطئ الأمور - أو، إذا كان شيء في المسار قد منع التجزئة (وهذا يحدث أكثر مما تتوقع، خصوصاً مع حركة المرور بالوقت الفعلي)، تُسقَط الحزمة ببساطة وبصمت. ليست أبطأ. مُسقَطة. اختفت. وجهازك عادة لا يعرف السبب، لذا يعيد المحاولة فقط، وهذا يبدو لك كتأخير، أو تقطّع، أو اتصال ينقطع عشوائياً دون سبب ظاهر.

3. مثال الألعاب الذي يجعل الفكرة تتضح

إليك سيناريو حقيقي ومحدد، لأن هذا يتوقف عن كونه مجرداً بمجرد أن تختبره بنفسك. لنقل إنك متصل بـVPN - ربما من أجل الخصوصية، أو ربما لأن صديقاً يستضيف جلسة لعبة خاصة عبر واحد، أو ربما يتطلب عملك ذلك ونسيت قطع الاتصال قبل بدء مباراة. شبكات VPN تُغلّف حركة مرورك العادية داخل طبقة تشفير إضافية، وذلك التغليف يأخذ حيزاً. قد ينخفض MTU الفعلي لاتصالك من 1500 المعتاد إلى شيء مثل 1400 أو أقل، حسب بروتوكول الـVPN.

الألعاب أونلاين، خصوصاً السريعة منها، تعتمد بشكل كبير على حزم UDP صغيرة ومتكررة للحفاظ على مزامنة موقعك، وأفعالك، وحالة اللعبة في الوقت الفعلي. جزء كبير من تلك الحركة يُرسَل بعلم "عدم التجزئة" (don't fragment) مُفعّلاً، تحديداً لأن تجزئة بيانات الوقت الفعلي تضيف تأخيراً لا يريده أحد في مباراة تنافسية. اجمع ذلك العلم مع تعارض MTU، وإليك ما يحدث فعلياً: بدل أن تُجزَّأ حركة مرور لعبتك وتتباطأ، تُسقَط ببساطة كلياً من قبل أول جهاز شبكة يلاحظ أن الحزمة لا تناسب. من داخل اللعبة، هذا يبدو تماماً كأعراض اتصال سيء كلاسيكية: "تذبذب" (rubber-banding) حيث تنقفز شخصيتك للخلف، انقطاعات مفاجئة في منتصف المباراة، فشل حتى في الانضمام لغرفة انتظار من الأساس، أو اتصال ينتهي وقته تحديداً فقط أثناء تفعيل الـVPN ويعمل جيداً لحظة إيقافه.

خفّض MTU على محوّل الشبكة المتأثر ليطابق ما يستطيع نفق الـVPN حمله فعلياً، وفي نسبة كبيرة حقاً من هذه الحالات، تختفي نفس الأعراض بالضبط. لا شيء تغيّر في سرعة إنترنتك. الحزم فقط توقفت عن كونها كبيرة جداً على الطريق الذي كانت تسافر عليه.

4. فحص وتغيير MTU على ويندوز 11

ويندوز 11 يجعل هذا متاحاً بالكامل عبر سطر الأوامر، دون الحاجة لأي أدوات خارجية.

فحص MTU الحالي لديك

1. افتح موجه الأوامر (Command Prompt) كمسؤول - ابحث عن "cmd" في قائمة ابدأ، انقر بزر الماوس الأيمن، واختر تشغيل كمسؤول (Run as administrator).
2. اكتب netsh interface ipv4 show subinterfaces واضغط Enter.
3. ستظهر لك قائمة بواجهات الشبكة لديك (Wi-Fi، إيثرنت، وغيرها) مع قيمة MTU الحالية لكل واحدة - 1500 هو الافتراضي المعتاد.

تغييره، بمجرد معرفة القيمة الصحيحة

1. في نفس موجه الأوامر المرتفع الصلاحيات، اكتب: netsh interface ipv4 set subinterface "Ethernet" mtu=1400 store=persistent
2. استبدل "Ethernet" باسم الواجهة الدقيق الظاهر في الخطوة السابقة - قد يكون "Wi-Fi" بدلاً من ذلك، حسب طريقة اتصالك.
3. استبدل 1400 بقيمتك المستهدفة الفعلية بمجرد تحديدها باستخدام طريقة الاختبار أدناه.
4. أعد تشغيل محوّل الشبكة، أو أعد تشغيل الحاسوب، حتى يصبح التغيير سارياً بالكامل في كل مكان يحتاجه.

5. iOS، أندرويد، وراوتر منزلك

iOS (آيفون وآيباد)

يستحق الأمر التوضيح مباشرة هنا: نظام iOS القياسي لا يقدّم إعداد MTU عاماً وبسيطاً جالساً في تطبيق الإعدادات العادي بالطريقة التي يفعلها ويندوز. تُبقي آبل هذا مُدارَاً تلقائياً للاتصالات العادية عبر Wi-Fi والبيانات الخلوية. إذا احتجت فعلياً لتعديل MTU على آيفون، فهذا يتم عادة عبر إعدادات داخلية لتطبيق VPN محدد، بما أن بعض عملاء VPN يعرضون حقل MTU خاصاً بهم للنفق الذي ينشئونه، أو عبر ملف تعريف إعدادات يدفعه نظام إدارة أجهزة شركة. لا يوجد مسار أصلي بسيط "فقط اذهب هنا واكتب رقماً" للمستخدم العادي، وأي شرح يدّعي عكس ذلك على الأغلب يصف إصدار iOS قديماً أو إعداداً مُخترقاً (jailbroken).

أندرويد

أندرويد قصة مشابهة على معظم الأجهزة الأصلية - لا يوجد حقل MTU عام جالس في إعدادات Wi-Fi أو البيانات الخلوية القياسية. بعض هواتف أندرويد تعرض تعديل MTU تحديداً ضمن إعدادات اتصالات VPN الفردية التي قمت بضبطها، تحت الإعدادات > الشبكة والإنترنت > VPN، انقر على أيقونة الترس بجانب ملف تعريف VPN محفوظ محدد. عدا ذلك، تعديل MTU على مستوى النظام بأكمله في أندرويد يتطلب عموماً إما جهازاً بصلاحيات الروت (rooted) باستخدام تطبيق طرفية، أو الاعتماد على الراوتر ومزود الـVPN لديك لتوزيع MTU بالحجم الصحيح تلقائياً، وهذا فعلياً الإصلاح الأكثر شيوعاً وموثوقية للهواتف والأجهزة اللوحية على أي حال.

الراوتر المنزلي

هذا هو المكان الذي تُجرى فيه تعديلات MTU غالباً، خصوصاً للإصلاحات الشاملة لكل المنزل بدل تعديل كل جهاز على حدة.

1. سجّل الدخول إلى صفحة إدارة الراوتر، عادة عبر كتابة عنوان IP الخاص به (غالباً شيء مثل 192.168.1.1 أو 192.168.0.1) في متصفح.
2. ابحث عن قسم بعنوان إعداد WAN، أو إعدادات الإنترنت، أو أحياناً مخبأ تحت إعدادات متقدم (Advanced) - التسمية الدقيقة تختلف كثيراً حسب ماركة وموديل الراوتر.
3. إذا كان نوع اتصالك PPPoE، ستجد غالباً حقل MTU هناك تحديداً، وغالباً مضبوطاً مسبقاً على 1492 افتراضياً لمراعاة الحمل الإضافي لـPPPoE.
4. عدّل القيمة، احفظ، وأعد تشغيل الراوتر حتى يُطبَّق الإعداد الجديد على كل جهاز يتصل عبره.

6. إيجاد الرقم الصحيح الفعلي لاتصالك

تخمين رقم والتمني ليس التصرف الصحيح هنا - توجد طريقة موثوقة فعلياً لإيجاد MTU الصحيح بالضبط لديك، وتستغرق حوالي دقيقتين.

1. افتح موجه أوامر مرتفع الصلاحيات
   كما سابقاً - ابحث عن "cmd"، انقر بزر الماوس الأيمن، تشغيل كمسؤول.
2. شغّل اختبار ping بعلم "عدم التجزئة"
   اكتب: ping -f -l 1472 8.8.8.8 - هذا يرسل حزمة بحجم 1472 بايت ويرفض السماح لها بالتجزؤ على طول الطريق.
3. اقرأ النتيجة
   إذا نجحت بشكل نظيف، فاتصالك يتعامل مع 1472 بايت من الحمولة على الأقل. إذا رأيت بدلاً من ذلك رسالة حول الحاجة لتجزئة الحزمة، فمسارك لا يستطيع التعامل مع ذلك الحجم.
4. ضيّق النطاق إذا فشل
   خفّض الرقم في الأمر - جرّب 1400، ثم عدّل صعوداً أو نزولاً من هناك - حتى تجد أكبر حجم حمولة ينجح دون تحذير تجزئة.
5. أضف 28 بايت بالضبط إلى ذلك الرقم النهائي الناجح
   هذه هي الخطوة التي يخطئ فيها الناس غالباً، لذا يستحق الأمر توضيحها بدقة: قيمة -l في أمر الـping تقيس فقط حمولة ICMP - ولا تتضمن رؤوس الحزمة التي تُرافق كل حزمة بغض النظر عمّا ترسله. تلك الرؤوس هي 20 بايت لرأس IPv4 بالإضافة إلى 8 بايت لرأس ICMP، أي 28 بايت بالضبط، في كل مرة، على كل اتصال IPv4 قياسي. لذا إذا كانت أكبر حمولة ناجحة لديك 1472، فإن MTU الحقيقي الذي يجب ضبطه على المحوّل ليس 1472 - إنه 1472 + 28، أي 1500. إذا كانت أكبر حمولة ناجحة لديك 1400، فإن قيمة MTU الحقيقية لديك هي 1428، وليست 1400. تخطي هذه الإضافة هو السبب الأكثر شيوعاً الذي يجعل الناس ينتهون بضبط MTU أصغر بـ28 بايت مما يجب أن يكون فعلياً.

7. أتمتة الفحص باستخدام PowerShell

تشغيل أوامر netsh يدوياً يعمل جيداً لإصلاح لمرة واحدة، لكن إذا كنت تفحص MTU عبر عدة واجهات بانتظام، أو تستكشف أخطاء أسطول من الأجهزة، أو تريد فقط مخرجات أنظف من تحليل نص netsh الخام، فإن PowerShell يتعامل مع هذا بشكل أكثر مباشرة. كلا السكريبتين أدناه نص عادي - احفظ أيهما بامتداد .ps1 وشغّله محلياً.

السكريبت 1: عرض MTU الحالي لكل واجهة نشطة

# Get-CurrentMTU.ps1
# Lists the current MTU value for every active IPv4 network interface.
#
# HOW TO RUN:
#   powershell -ExecutionPolicy Bypass -File .\Get-CurrentMTU.ps1

Get-NetIPInterface -AddressFamily IPv4 |
    Where-Object { $_.ConnectionState -eq "Connected" } |
    Select-Object InterfaceAlias, InterfaceIndex, NlMtu, ConnectionState |
    Sort-Object InterfaceAlias |
    Format-Table -AutoSize

Write-Host ""
Write-Host "NlMtu is the current MTU in bytes for each listed interface." -ForegroundColor Cyan

تشغيل هذا يطبع جدولاً نظيفاً يعرض اسم كل واجهة متصلة وMTU الحالي لها تحت عمود NlMtu - نفس المعلومات التي يعطيك إياها netsh interface ipv4 show subinterfaces، لكن أسهل للقراءة وأسهل لتمريرها لسكريبتات أو سجلات أخرى إذا كنت تفحص عدة أجهزة.

السكريبت 2: إيجاد MTU الأمثل تلقائياً عبر اختبار Path MTU

هذا يذهب أبعد من اختبار ping يدوي - يستخدم فئة ping الأصلية في .NET مباشرة، مما يسمح بتحكم صريح بعلم "عدم التجزئة" بنفس طريقة أسلوب ping -f -l اليدوي، لكنه يؤتمت البحث الثنائي بأكمله ويطبّق تصحيح الـ28 بايت نيابة عنك في النهاية.

# Find-OptimalMTU.ps1
# Automatically determines the true optimal MTU to a target host
# using ICMP with the Don't Fragment flag set, then applies the
# standard 28-byte IPv4+ICMP header correction to the result.
#
# HOW TO RUN:
#   powershell -ExecutionPolicy Bypass -File .\Find-OptimalMTU.ps1 -TargetHost 8.8.8.8

param(
    [string]$TargetHost = "8.8.8.8",
    [int]$StartSize = 1472,
    [int]$MinSize = 500
)

$HeaderOverhead = 28
$Ping = New-Object System.Net.NetworkInformation.Ping
$Options = New-Object System.Net.NetworkInformation.PingOptions
$Options.DontFragment = $true

$Size = $StartSize
$LastSuccess = 0

Write-Host "Testing path to $TargetHost with Don't Fragment set..." -ForegroundColor Cyan

while ($Size -ge $MinSize) {
    $Buffer = New-Object byte[] $Size
    $Reply = $Ping.Send($TargetHost, 2000, $Buffer, $Options)

    if ($Reply.Status -eq "Success") {
        $LastSuccess = $Size
        Write-Host "  Payload $Size bytes: OK" -ForegroundColor Green
        break
    } else {
        Write-Host "  Payload $Size bytes: FAILED ($($Reply.Status))" -ForegroundColor DarkGray
        $Size = $Size - 20
    }
}

if ($LastSuccess -gt 0) {
    $TrueMTU = $LastSuccess + $HeaderOverhead
    Write-Host ""
    Write-Host "Largest successful payload: $LastSuccess bytes" -ForegroundColor Yellow
    Write-Host "Header overhead added:      $HeaderOverhead bytes (20 IPv4 + 8 ICMP)" -ForegroundColor Yellow
    Write-Host "Recommended MTU to set:     $TrueMTU bytes" -ForegroundColor Green
    Write-Host ""
    Write-Host "Apply it with:" -ForegroundColor Cyan
    Write-Host "  netsh interface ipv4 set subinterface `"Ethernet`" mtu=$TrueMTU store=persistent"
} else {
    Write-Host "No successful reply found down to $MinSize bytes. Check connectivity to $TargetHost." -ForegroundColor Red
}

هذا يبدأ بحمولة 1472 بايت وينزل بخطوات 20 بايت حتى يجد حجماً يقبله المسار دون الحاجة للتجزئة، ثم يطبع MTU الحقيقي المُصحَّح مع أمر netsh الدقيق لتطبيقه - دون حساب يدوي مطلوب، ودون تخمين إن كنت تذكرت إضافة الـ28 بايت.

8. MTU حسب البروتوكول: جدول مرجعي للعمل المتعمق

بالنسبة لأي شخص يستكشف هذا احترافياً بدل إصلاح اتصال منزلي واحد، فإن رقمي 1500/1492 المذكورين سابقاً هما فقط الحالتان الأكثر شيوعاً. طرق النفق والتغليف المختلفة يقتطع كل منها جزءه الخاص من الحمل الإضافي، ومعرفة النطاق النموذجي لكل منها توفر الكثير من البحث الثنائي اليدوي.

هذه نقاط انطلاق نموذجية، وليست ضمانات - الطريقة الوحيدة لمعرفة رقمك الفعلي لمسار معين هي اختبار الـping أو السكريبت المؤتمت أعلاه، بما أن القيم الواقعية تتغير حسب مزودك المحدد، وإعداد الـVPN، وكل ما بينهما. لأي شخص يوثّق هذا على مستوى البروتوكول، RFC 1191 يُعرّف آلية اكتشاف Path MTU المُشار إليها طوال هذه المقالة، وRFC 894 يُعرّف حجم إطار الإيثرنت القياسي البالغ 1500 بايت الذي يُقاس كل شيء آخر هنا مقارنة به.

MTU ليس إعداداً يحتاج ضبطاً مستمراً بمجرد أن يصبح صحيحاً - تضبطه مرة واحدة للظرف المحدد المسبب للمشكلة، سواء كان ذلك VPN، أو خط PPPoE، أو راوتراً كان مُعدّاً بشكل خاطئ بصمت منذ يوم تركيبه، ثم تتركه وشأنه.

كتابة خليل شريتح - باحث في الأمن السيبراني وخبير وسائل التواصل الاجتماعي. الموقع الرسمي: shreateh.net