it-swarm.asia

كيف تتحقق من استخدام وحدة الإرسال الكبرى في نظام التشغيل Windows XP

أعاني من مشكلة غريبة حقًا حيث تظهر لي بشكل عشوائي أخطاء "تمت إعادة تعيين الاتصال بالملقم" عند محاولة الوصول إلى صفحات الويب (خطأ HTTP 12031 وفقًا لأداة تشخيص شبكة Windows) - يحدث هذا بغض النظر عما إذا كانت صفحة الويب أحاول الوصول إلى الإنترنت الخارجي أو حتى إذا كان من مثيل Apache محلي يعمل على المضيف المحلي. إنه يؤثر على جميع أجهزة الكمبيوتر على شبكتنا المحلية (Ethernet ، وليس لاسلكية) ، وكلها تعمل بنظام Windows XP.

لقد اقترح لي أنه ربما يتعلق الأمر بوحدة الإرسال الكبرى المستخدمة في حركة مرور الشبكة. إذا قمت بإجراء اختبار Ping لاكتشاف أكبر حزمة يمكن أن تمر بدون تجزئة ، فيمكنني اختبار اتصال المضيف المحلي باستخدام حزمة من 1492 بايت (+28) بايت لرأس؟) وأستطيع تنفيذ الأمر ping لجهاز التوجيه الخاص بنا مع حزمة من 1462 بايت (وهو 1490 بايت عند تضمين رأس 28 بايت). إذا حاولت إجراء اختبار ping لشيء ما من الخارج مثل Google ، فلن أستطيع الحصول على أي شيء أكبر من 1430 (وهو الرقم 1458 بالرأس).

لقد جربت اتباع مجموعات مختلفة من الإرشادات لتحديث Windows XP Registry باستخدام إعداد MTU هذا ، وتحديث HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{AdapterID}\MTU. لقد جربت أي حد من القيم البديلة: يبدو أن القيمة الصحيحة الأكثر وضوحًا هي 1490 ، لكنني جربت أيضًا 1462 و 1458 و 1430 وما إلى ذلك ، إلخ. عندما أعيد تشغيل الكمبيوتر لجعل التغيير نافذ المفعول ، يبدو أن تعمل لبضع دقائق (يصعب تحديدها نظرًا لأنها دائمًا عشوائية بدلاً من كونها متسقة) ولكنها لا تدوم طويلًا.

في البداية ، عندما كنت أحاول استخدام الإصدار 1430 كقيمة ، وبعد بضع دقائق من العمل بشكل جيد ، ستنخفض نتائج اختبار Ping بمقدار 28 بايت - وفجأة وجدت أنه لا يمكنني الوصول إلا إلى حزمة من 1402 بايت إلى Google. إذا قمت بتحديث إعداد تسجيل MTU إلى 1402 ، عندما قمت بإعادة التشغيل وانتظرت لبضع دقائق ، فسيكون عند ذلك 1374 ، ثم 1346 ، وما إلى ذلك. من التسجيل من شأنه استعادة الأشياء إلى وضعها الطبيعي (وما زالت مكسورة).

الشيء الذي أجده أكثر صعوبة في تشخيص كل هذا هو أنه من الصعب للغاية معرفة ما إذا كنت ألعب حتى مع إعداد التسجيل الصحيح. لذلك في أبسط ما يكون ، سؤالي هو: كيف يمكنني معرفة إعدادات MTU التي يحاول Windows استخدامها؟

أيضًا ، إذا كان لدى أي شخص أي أفكار حول كيفية معرفة سبب استمرار MTU في الانخفاض بمقدار 28 ، فسيكون ذلك مفيدًا أيضًا (على سبيل المثال ، يوجد ملف سجل Windows في مكان ما حيث سيتم تسجيل شيء ما في النقطة التي تتغير فيها القيمة؟)

أخيرًا ، إذا كان بإمكان أي أحد أن يخبرني بشكل قاطع عن كيفية تحديد إعدادات MTU التي يجب أن أحاول استخدامها ، فسيكون ذلك رائعًا!

20
andygeers

بالنسبة لنظامي التشغيل Windows 7 و Windows Vista و Windows XP ، تتوفر وحدة MTU للعديد من الواجهات من Windows نفسه باستخدام netsh.

ويندوز 7 ، ويندوز فيستا

لإظهار الحالية {MTU على Windows 7 أو Windows Vista ، من موجه الأوامر:

C:\Users\Ian>netsh interface ipv6 show subinterfaces

       MTU  MediaSenseState   Bytes In  Bytes Out  Interface
----------  ---------------  ---------  ---------  -------------
      1280                1   24321220    6455865  Local Area Connection
4294967295                1          0    1060111  Loopback Pseudo-Interface 1
      1280                5          0          0  isatap.newland.com
      1280                5          0          0  6TO4 Adapter

وبالنسبة لواجهات IPv4:

C:\Users\Ian>netsh interface ipv4 show subinterfaces

       MTU  MediaSenseState   Bytes In  Bytes Out  Interface
----------  ---------------  ---------  ---------  -------------
      1500                1  146289608   29200474  Local Area Connection
4294967295                1          0      54933  Loopback Pseudo-Interface 1

ملاحظة: في هذا المثال ، تحتوي واجهة الاتصال المحلية IPv6 على وحدة MTU منخفضة (1280) منخفضة لأنني أستخدم خدمة نفق للحصول على اتصال IPv6 .

يمكنك أيضًاتغييرMTU الخاص بك (Windows 7 ، Windows Vista). منمرتفعةموجه الأوامر:

>netsh interface ipv4 set subinterface "Local Area Connection" mtu=1492 store=persistent
Ok.

تم اختباره مع Windows 7 Service Pack 1

ويندوز إكس بي

بناء جملة netsh لـ Windows XP مختلف قليلاً:

C:\Users\Ian>netsh interface ip show interface

Index:                                  1
User-friendly Name:                     Loopback
Type:                                   Loopback
MTU:                                    32767
Physical Address:                       

Index:                                  2
User-friendly Name:                     Local Area Connection
Type:                                   Etherenet
MTU:                                    1500
Physical Address:                       00-03-FF-D9-28-B7

يتطلب {ملاحظة: Windows XP أن تبدأ خدمة التوجيه والوصول عن بُعد قبل أن تتمكن من رؤية تفاصيل واجهة (بما في ذلك MTU):

C:\Users\Ian>net start remoteaccesss

لا يوفر Windows XP طريقة لتغيير إعداد MTU من داخل netsh. لذلك يمكنك:

تم اختباره مع Windows XP Service Pack 3

أنظر أيضا


مناقشة قصيرة حول ما هي وحدة الإرسال الكبرى ، حيث تأتي الـ 28 بايت.

يبلغ الحد الأقصى لحجم حزمة بطاقة الشبكة (Ethernet) 1,500 bytes:

+---------+
| 1500    |
| byte    |
| payload |
|         |
|         |
|         |
+---------+

يتطلب جزء IP من TCP/IP رأسًا 20 بايت (12 بايت من الأعلام و 4 بايت لعنوان IP المصدر و 4 بايت لعنوان IP الوجهة). هذا يترك مساحة أقل متوفرة في الحزمة:

+------------------------+
| 12 bytes control flags | \
| 4 byte from address    | |- IP header: 20 bytes
| 4 byte to address      | /
|------------------------|
| 1480 byte payload      |
|                        |
|                        |
|                        |
+------------------------+

الآن تحتوي حزمة ICMP (ping) على رأس 8 بايت (1 بايت type ، بايت واحد code ، 2 بايت checksum ، 4 بايت بيانات إضافية):

+------------------------+
| 12 bytes control flags | \
| 4 byte from address    | |
| 4 byte to address      | |- IP and ICMP header: 28 bytes
|------------------------| |
| 8 byte ICMP header     | /
|------------------------|
| 1472 byte payload      |
|                        |
|                        |
|                        |
+------------------------+

هذا هو المكان "المفقود" 28 بايت - هو حجم الرؤوس المطلوبة لإرسال حزمة ping.

عند إرسال حزمة ping ، يمكنك تحديد مقدار بيانات الحمولة الإضافية التي تريد تضمينها. في هذه الحالة ، إذا قمت بتضمين جميع وحدات البايت 1472:

>ping -l 1472 obsidian

ثمالإيثرنتالحزمة ستكون مليئة بالخياشيم. سيتم تعبئة كل بايت أخير من حزمة 1500 بايت:

+------------------------+
| 12 bytes control flags | \
| 4 byte from address    | |
| 4 byte to address      | |- IP and ICMP header: 28 bytes
|------------------------| |
| 8 byte ICMP header     | /
|------------------------|
|........................|
|........................|
|. 1472 bytes of junk....|
|........................|
|........................|
|........................|
|........................|
+------------------------+

إذا حاولت إرسالبايت واحد آخر

>ping -l 1473 obsidian

سيتعين على الشبكة تجزئة الحزمة 1501 بايت في حزم متعددة:

Packet 1 of 2
+------------------------+
| 20 bytes control flags | \
| 4 byte from address    | |
| 4 byte to address      | |- IP and ICMP header: 28 bytes
|------------------------| |
| 8 byte ICMP header     | /
|------------------------|
|........................|
|........................|
|..1472 bytes of payload.|
|........................|
|........................|
|........................|
|........................|
+------------------------+

Packet 2 of 2
+------------------------+
| 20 bytes control flags | \
| 4 byte from address    | |
| 4 byte to address      | |- IP and ICMP header: 28 bytes
|------------------------| |
| 8 byte ICMP header     | /
|------------------------|
|.                       |
| 1 byte of payload      |
|                        |
|                        |
|                        |
|                        |
|                        |
+------------------------+

سيحدث هذا التفتت وراء الكواليس ، من الناحية المثالية دون أن تعرف.

ولكن يمكنك أن تكون معنيًا ، وأخبر الشبكة أنه لا يُسمح بتجزئة الحزمة:

>ping -l 1473 -f obsidian

العلامة -f تعنيلا تجزئة. الآن عندما تحاول إرسال حزمة لا تتناسب مع الشبكة ، تحصل على الخطأ:

>ping -l 1473 -f obsidian  

Packet needs to be fragmented but DF set.

يجب أن تكون الحزمة مجزأة ، لكنلا تم تعيين Fragmentflag.

إذا كانت هناك حاجة في أي مكان على طول الخط إلى تجزئة الحزمة ، فإن الشبكة ترسل بالفعل حزمة ICMP تخبرك بحدوث تجزئة. يحصل جهازك على حزمة ICMP هذه ، ويتم إخباره بحجم أكبر ، ويفترض أن يتوقف عن إرسال الحزم الكبيرة جدًا. لسوء الحظ ، تقوم معظم جدران الحماية بحظر حزم ICMP "اكتشاف MTU" ، لذلك لا يدرك جهازك أبدًا أن الحزم مجزأة (أو أسوأ من ذلك: تم إسقاطها لأنه لا يمكن تجزئتها).

هذا ما يجعل خادم الويب لا يعمل. يمكنك الحصول على الاستجابات الأولية الصغيرة (<1280 بايت) ، لكن الحزم الأكبر لا يمكنها الوصول إليها. والجدران النارية لخادم الويب يتم تكوينها بشكل خاطئ ، مما يحظر حزم ICMP. لذا فإن خادم الويب لا يدرك أنك لم تحصل على الحزمة أبدًا.

تجزئة الحزم غير مسموح بها في IPv6 ، الكل هومطلوب((بشكل صحيح) يسمح بحزم اكتشاف ICMP mtu.

57
Ian Boyd

ian لست متأكدًا من أن netsh يعرض وحدة MTU المستخدمة حاليًا. على جهاز Windows XP Pro SP3 ، نفذت netsh interface ip show interface وأبلغت عن قيمة MTU للواجهة ذات الصلة كـ 1500. ثم أضفت مفاتيح التسجيل التالية:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnablePMTUDiscovery
    value: 0

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{ID}\MTU 
    value: various (e.g. 1200)

تقول Microsoft إن إعداد EnablePMTUDiscovery إلى 0 سيؤدي إلى تعيين MTU على 576.

يؤدي تعيين إدخال التسجيل MTU إلى تعيين MTU يدويًا. جربت عدة قيم لإدخال MTU (إعادة التشغيل في كل مرة).

في كلتا الحالتين - إضافة الإدخال الأول ، ثم الإدخال الثاني - netsh لا يزال يبلغ MTU عن 1500. أكد الاختبار باستخدام ping (أو على الأقل اقترح) أن قيمة MTU التي تم تكوينها في السجل كانت قيد الاستخدام بالفعل.

أيضًا ، عندما جربت ذلك لأول مرة على جهازي ، تم تعطيل خدمة التوجيه والوصول عن بُعد ، لذا لم أتمكن من تشغيلها باستخدام إرشاداتك. قمت بتمكينه من خلال الانتقال إلى لوحة التحكم> أدوات الإدارة> إدارة الكمبيوتر> الخدمات والتطبيقات> الخدمات. لقد غيرت "نوع بدء التشغيل" من معطل إلى يدوي. ثم بدأت الخدمة من مربع الحوار هذا أيضًا.

لست متأكدًا أيضًا أن KB283165 هي الإرشادات الصحيحة لتغيير وحدة الإرسال الكبرى. ألا تعتبر هذه التعليمات ذات صلة فقط عند تشغيل Windows PPPoE العميل؟ إذا كنت تتصل بالإنترنت من خلال جهاز توجيه حيث يكون جهاز التوجيه هو PPPoE العميل (كما في حالتي) ، فلن تكون هذه التعليمات مناسبة ، أليس كذلك؟

التعليمات التي اتبعتها ، والتي دفعتني لإجراء التغييرات المذكورة أعلاه على السجل ، كانت في KB900926: إعدادات TCP/IP الموصى بها من أجل WAN روابط بحجم MTU أقل من 576 (الطرق 2 و 3).


تحرير بواسطةian

يبدو أنك على حق. تكوين لـ 1200 ، لكن netsh تقارير 1500.

enter image description here

>ping -l 1173 -f obsidian

Packet needs to be fragmented but DF set.

لذا أعتقد أن إجابة السؤال الأصلي هي أنه في نظام التشغيل Windows XP يجب عليك استخدام الإصدار التجريبي والخطأ في علامة لا تجزئ علامة للعثور على أكبر حزمة يمكنك إرسالها هو. ثم لديك MTU الخاص بك.

8
JMM

يمكنك العثور على MTU باستخدام اختبار ping مع نهج التجربة والخطأ:

ping <address> -f -l nnnn

جان بينغ:

-f: تحديد إرسال رسائل طلب الارتداد مع علامة عدم تجزئة في رأس IP المعين إلى 1. لا يمكن تجزئة رسالة طلب الارتداد بواسطة أجهزة التوجيه في المسار إلى الوجهة. هذه المعلمة مفيدة لاستكشاف مشاكل مسار وحدة الإرسال القصوى (PMTU).

-l Size: يحدد الطول ، بالبايت ، لحقل البيانات في رسائل طلب الارتداد المرسلة. الافتراضي هو 32. الحد الأقصى للحجم هو 65،527.

ستحصل على "حزمة يحتاج إلى تجزئة ولكن _ DF مجموعة" رسائل عندما يكون الطول أكبر من اللازم.

2
T. Kaltnekar

Microsoft KB314496: أحجام MTU الافتراضية لمختلف طبولوجيا الشبكة .
يجب ألا تحاول اللعب مع تكوين MTU في إعدادات الشبكة العادية.

يوجد مرجع رمز VB هنا .
هناك أيضًا أداة تسمى DrTCP :

alt text


في التسجيل ،

  • انتقل إلى HKLM\Software\Microsoft\Windows NT\CurrentVersion\NetworkCards
  • افتح المحول الذي تهتم به
  • انسخ السلسلة ServiceName
  • البحث في هذه السلسلة في HKLM\System ؛ سوف تتطابق مع مفتاح NetCfgInstanceId
  • أعلى قليلاً من ذلك سيكون مفتاح MaxFrameSize (يظهر لي 1514)

هناك أيضًا طريقة لتغيير هذا باستخدام الأمر netsh.

أيضًا ، تحقق من تكوين مسار MTU Discovery .

1
nik

انظر AdapterWatch :

يعرض AdapterWatch معلومات مفيدة حول محولات الشبكة: عناوين IP وعنوان الجهاز وخوادم WINS وخوادم DNS وقيمة MTU وعدد البايتات المستلمة أو المرسلة وسرعة النقل الحالية والمزيد. بالإضافة إلى ذلك ، يعرض إحصائيات TCP/IP/UDP/ICMP العامة للكمبيوتر المحلي الخاص بك.

1
harrymc