حشو Ethernet في لمحة
لماذا قد تظهر رسالة قصيرة كإطار أطول؟
قد يضيف Ethernet حشوًا قبل FCS لتلبية الحد الأدنى لتنسيق إطار MAC. يقع الحشو خارج حزمة IPv4 ولا ينبغي أن يصبح بيانات تطبيق. قد تلاحظ برامج الالتقاط المعالجة قبل الحشو أو تتلقى سجلًا بدون FCS، لذا فإن الطول المعروض وحده لا يثبت إرسالًا أصغر من الحجم. تحقق من نقطة الملاحظة واصطلاح الطول.
بناء الإطار الخارجي
يلبي الحشو التنسيق الخارجي؛ ولا يضيف معنى للتطبيق.
تحديد موقع المراقب
قد ترى البرامج مرحلة مختلفة عن الوصلة الفيزيائية.
احترام الحد الداخلي
بالنسبة إلى IPv4، استخدم الطول الإجمالي IP بدلًا من معاملة الحشو كبيانات.
التحقق من العد
حدد أي الرؤوس والوسوم وبايتات FCS يتضمنها الطول.
التحقق من الالتقاط
سجّل الاتجاه وعمليات التفريغ والطول المحتفظ به وإعدادات FCS.
التحقق من المحلل
تأكد من أن طول الطبقة العليا يحدد محتوى التطبيق الصالح.
قائمة التحقق للاختيار والتحقق — توسيع
| الفحص | ما يجب تأكيده | كيفية التحقق |
|---|---|---|
| اصطلاح الإطار | الرؤوس والوسوم وFCS | وثّق بداية العد ونهايته بدقة. |
| نقطة الملاحظة | قبل NIC أو السلك أو المستقبل | حافظ على إعدادات الواجهة والجمع. |
| اكتمال الالتقاط | الطول الأصلي مقابل الطول المحتفظ به | تحقق من الاقتطاع وحدود الجمع. |
| حدود البروتوكول | طول IP الصالح أو طول بروتوكول آخر | افحص الطول المحدد وسلوك المحلل. |
| أدلة الأعطال | العدادات والاتجاه والوقت | اربط حركة المرور المعروفة عند الطرفين. |
أمثلة مفاهيمية، ليست بمقياس، وليست قياسات أو ادعاءات بشأن تنفيذ منتج معين.
يرسل PLC رسالة حالة قصيرة، ومع ذلك يكون المحتوى المرسل عبر Ethernet أطول. يُظهر الالتقاط 60 بايت، بينما تصف الوثائق إطارًا أدنى بحجم 64 بايت. لا تستنتج فورًا أن مبدّلًا حذف أربعة بايتات. رسالة التطبيق وتغليف Ethernet والتقاط البرنامج طبقات مختلفة من الملاحظة. وضع الحشو في المكان الصحيح يفسر التناقض الظاهري.
فصل الرسالة وحزمة IP وإطار Ethernet
يهتم التطبيق بحالة أو أمر أو قياس، لكن الإرسال يحتاج إلى معلومات يمكن لمعدات الشبكة التعرف عليها. فكّر في الرسالة كمذكرة، وحزمة IP كمظروفها، وإطار Ethernet كالتغليف الخارجي لهذه الوصلة. يوضح التشبيه الطبقات، لا ثلاث صناديق فيزيائية: يحمل السلك تسلسلًا متواصلًا من البتات.
في مثال Ethernet العادي غير الموسوم المستخدم هنا، يمتد إطار MAC من عنوان الوجهة عبر تسلسل فحص الإطار، أو FCS. يحدد عنوان MAC المرسل أو المستلم على الوصلة؛ ويساعد FCS المستقبل على التحقق من أخطاء الإرسال. تسبق الديباجة الإطار، والفجوة البينية هي وقت خامل بين عمليات الإرسال. لا يُعد أي منهما جزءًا من هذا العد البالغ 64 بايت.
ينطبق الحد الأدنى على إطار MAC الخارجي، لا على طول كل تعليمة PLC. عند قراءة الوثائق أو عمليات الالتقاط، حدد أولًا أين يبدأ العد وأين ينتهي. خلط بيانات التطبيق والرؤوس وFCS قد يجعل التغليف العادي يبدو كمحتوى تطبيق إضافي.
إلحاق الحشو قبل تكوين تسلسل فحص الإطار
إذا كان محتوى الطبقة العليا المقدم قصيرًا جدًا، تضيف معالجة الإرسال في Ethernet حشوًا بعد ذلك المحتوى وقبل FCS. وهو مثل التغليف الواقي: يشغل مساحة دون إضافة كلمات إلى المذكرة. تعتمد مسألة قيام البرنامج أو برنامج التشغيل أو العتاد بعملية معينة على واجهة الشبكة أو التنفيذ المدمج.
خذ مثالًا محدودًا عمدًا: رأس Ethernet غير موسوم بحجم 14 بايت يحمل حزمة IPv4 بحجم 28 بايت. يمكن أن تتكون حزمة IP تلك من رأس IPv4 عادي ورأس UDP، دون حمولة تطبيق UDP. إضافة 18 بايت من الحشو وFCS بأربعة بايتات ينتج إطار MAC بحجم 64 بايت. يوضح هذا البنية؛ وهو ليس قياسًا لجهاز FCTEL.
يُضمّن الحشو في المحتوى المحمي باختبار المجموع الاختباري لإيثرنت. ولا يمكن تغييره اعتباطًا بعد تكوين FCS. يتحقق المستقبل من الإطار المستلم، وليس من رسالة التطبيق فقط. ولا حاجة إلى حساب CRC لفهم التسلسل: كوّن محتوى الإطار المطلوب، ثم أنشئ قيمة التحقق المقابلة له.
ينبغي ألا يصبح الحشو بيانات تطبيق إضافية
بالنسبة إلى IPv4، يحدد حقل الطول الإجمالي في ترويسة IP طول حزمة IP، بما في ذلك ترويستها وبياناتها ولكن باستثناء حشو إيثرنت الخارجي. ويمرر المستقبل جزء IP إلى الأعلى لمزيد من التفسير. ويفصل RFC 894 صراحةً الحشو عن حزمة IP، ويحدد حشوًا من البايتات الصفرية عند الحاجة إليه للتغليف الذي يصفه.
يجب ألا يعامل محلل الطبقة العليا كل بايتات إيثرنت الملتقطة المتبقية كمحتوى تطبيق. بل ينبغي أن يتحقق من طول بروتوكوله وحدوده بدلًا من إلحاق التغليف الخارجي بأمر ما. ولا ينبغي له أيضًا أن يحذف ببساطة كل صفر لاحق: فقد يكون الصفر بيانات صالحة. فالبروتوكول، وليس المظهر المرئي للبايت، هو ما يحدد الحد.
تحتاج بروتوكولات الطبقة الثانية الأخرى إلى قواعد تغليف خاصة بها؛ فلا يمكن تطبيق الطول الإجمالي لـ IPv4 آليًا على كل بروتوكول. وينبغي ألا يحمل الحشو تعليمات تحكم خاصة أو ذاكرة غير مهيأة. والعادة العملية هي التحقق من حد الإطار الخارجي وحد الرسالة الداخلية كلٌّ على حدة.
لماذا قد تعرض البرمجيات 60 بايت أو حتى أقل
لا تتلقى برمجيات الالتقاط بالضرورة التمثيل الكامل على السلك. فكثير من الواجهات تتحقق من FCS الوارد دون تسليم تلك البايتات الأربع إلى نظام التشغيل. لذلك يمكن للبرمجيات أن تسجل 60 بايت تقابل إطار MAC كاملًا بحجم 64 بايت على السلك. وتبرز وثائق Wireshark هذا التمييز: فمجرد طول معروض قدره 60 لا يثبت وجود إرسال أصغر من الحجم الأدنى.
يمكن لالتقاط من جهة الإرسال أن يرصد نقطة أخرى، قبل أن تضيف العتاد الحشو وFCS. وقد يكون سجله أقصر من 60 بايت حتى وإن أنتج العتاد لاحقًا إطارًا مرسلًا صالحًا. فشاشة المرسل وشاشة المستقبل ومراقبة الوصلة الفيزيائية وجهات نظر مختلفة. ومقارنة طولين معروضين فقط لا يمكن أن تثبت أن المعدات بينهما أزالت محتوى.
وميّز أيضًا بين الطول الأصلي والطول الملتقط. فقد يحتفظ جامع ما ببداية كل إطار فقط، لذا ليس بالضرورة حفظ كل بايت أصلي. تحقق من إعدادات الالتقاط وتسليم FCS والاتجاه وسلوك التفريغ، ثم قارن الأدلة من الطرف المقابل. ويتطلب إثبات التمثيل الفيزيائي على السلك طريقة اختبار مناسبة بشروط اقتناء محددة.
لا تعني معالجة VLAN عددًا ثابتًا واحدًا للحشو
تنتمي بايتات حشو 18 إلى المثال السابق فقط. فتغيّر أطوال المحتوى ومعالجة الوسم والتغليف يغيّر المقدار المطلوب. ويشغل وسم VLAN جزءًا من منطقة الترويسة؛ فلا تحسبه مرتين عندما يكون مدرجًا بالفعل. كما أن الحد الأدنى لحجم الإطار ووحدة الإرسال القصوى، أو MTU، مفهومان مختلفان أيضًا.
يستقبل المبدّل الإطارات ويحدد وجهات التمرير ويكوّن الخرج المناسب على الوصلة التالية. ويجب على المعدات التي تضيف الوسوم أو تزيلها أن تحافظ على متطلبات الخرج. وتوضح وثيقة استكشاف الأخطاء وإصلاحها من Cisco المشار إليها حالة منصة محددة تتطلب فيها إزالة وسم إعادة الحشو. وهي تساعد في تفسير حد معالجة، لا في وصف تنفيذ داخلي عالمي لكل مبدّل.
الحشو الطبيعي لرسالة قصيرة كاملة ليس عيبًا. فالإطار الأصغر فعليًا من الحجم الأدنى، والإرسال غير الطبيعي الناتج عن وصلة تالفة، وسجل الالتقاط المختصر أثناء الجمع، تتطلب جميعها تحقيقًا مختلفًا. وتختلف أسماء عدادات المنافذ وشروطها حسب المعدات. وربط العدادات بأوقات الالتقاط واتجاهاته أنفع من استبدال مبدّل لمجرد أن سجلًا يبدو قصيرًا.
طبّق التمييز على توصيل مبدّل صناعي
تسرد صفحة مبدّل Fast Ethernet الصناعي المنشورة FCTEL بخمسة منافذ وتركيب mini DIN-rail خمسة منافذ إيثرنت كهربائية وتكييف 10/100M. وهذا يوفر أساسًا منتجيًا حقيقيًا لسيناريو توصيل PLC وHMI. ولا يثبت وجود إمكانات التقاط أو انعكاس منافذ أو تحكم خاص في الحشو أو حدود خطأ معينة. تحقق من التكوين المختار مقابل وثائقه الخاصة.
إذا أرسل طرف طرفي باستمرار رسائل حالة قصيرة بينما ينقل طرف آخر ملفًا أكبر، فإن أعداد بايتات التطبيق وحدها لا تصف حمل المنفذ. فكل إطار يستهلك أيضًا فرص تغليف وإرسال، بما في ذلك التباعد المطلوب. وقد تستهلك الرسائل الصغيرة الكثيرة موارد المعالجة والوصلة. ابدأ بملاحظات معدل الإطارات والحركة الفعلية ودورة التطبيق بدلًا من اشتراط صيغ معقدة.
إذا بدا أن تطبيقًا يُنقل بشفافية يكتسب بايتات لاحقة، فتحقق أولًا من حدود البروتوكول والمحلل. قارن ما يرصده المصدر وأي محوّل والوجهة كلٌّ على حدة. لا تعامل حشو إيثرنت تلقائيًا كجزء من رسالة تسلسلية، ولا تغيّر أوضاع المعدات لمجرد إزالة الحشو. حدد الطبقة المتأثرة أولًا.
استخدم ثلاثة أسئلة لتضييق تحقيق ميداني
أولًا، حدد نقطة الرصد: قبل إرسال المصدر، أو بعد استقبال الطرف المقابل، أو نسخة يوفرها مبدّل. ثانيًا، وثّق اصطلاح الطول: الترويسات المضمنة، وتوافر FCS، وما إذا كان قد تم الاحتفاظ بإطار كامل. ثالثًا، اربط أطوال البروتوكول والحمولة وعدادات الأخطاء لنفس حركة التطبيق. ولقطة شاشة واحدة تعرض 60 بايت غير كافية.
للمقارنة، استخدم رسالة قصيرة معروفة في بيئة اختبار معزولة أو نافذة صيانة معتمدة. احتفظ بعمليات الالتقاط الأصلية ومعاملات الاقتناء من الطرفين. تأكد من أن التطبيق يستخرج محتواه الصالح فقط وأن الاتصالات العادية تستمر. فمثل هذا الاختبار يتحقق من ذلك التكوين والمسار؛ وعرض أداة واحدة لا يحدد كل واجهة ومبدّل.
أخيرًا، لاحظ ما إذا كان الشذوذ يتبع منفذًا أو كبلًا أو طريقة التقاط. احتفظ بالأدلة الخام بدلًا من لقطات الشاشة المشروحة فقط. فالمبدأ بسيط: للإطار الخارجي حد أدنى للتنسيق، وللتطبيق الداخلي حد طول خاص به، وبرمجيات الالتقاط تسجل مرحلة واحدة من المعالجة. والحفاظ على هذه الثلاثة منفصلة يساعد في تحديد عطل حقيقي.
المصادر وأدلة المنتج
Wireshark: إيثرنت; IETF RFC 894، أبريل 1984; وثيقة استكشاف أخطاء الحشو وإصلاحها من Cisco، محدثة في يوليو 16، 2021. لا تنقل الآليات العامة أوامر خاصة بمنصة معينة أو استنتاجات عيوب إلى معدات أخرى. دليل المنتج: مبدّل FCTEL المصغّر خماسي المنافذ Fast Ethernet المثبّت على سكة DIN، صفحة باللغة الصينية. تحقق من الإصدار المختار. الرسوم التوضيحية مفاهيم عامة أُعدت بمساعدة الذكاء الاصطناعي.
مترجم من المقال التقني الصيني: اقرأ المقال الصيني الأصلي.
أسئلة عملية شائعة
هل الالتقاط بحجم 60 بايت إطار قصير غير صالح؟
ليس بالضرورة. فالعملية الالتقاط الشائعة تحذف FCS ذا البايتات الأربع. تحقق من نقطة الرصد والطول الأصلي والطول الملتقط.
هل يصبح الحشو أمر PLC جديدًا؟
لا ينبغي ذلك. يجب على المحلل استخدام طول بروتوكول الطبقة العليا بدلًا من معاملة الحشو الخارجي كبيانات تطبيق إضافية.
هل تحتاج كل رسالة قصيرة إلى بايتات حشو 18؟
لا. الثمانية عشر بايت تنطبق فقط على المثال غير الموسوم في هذه المقالة؛ فالمحتوى الأصلي والتغليف هما ما يحددان الحشو الفعلي.
النطاق وقراءات إضافية
مفاهيم عامة لحشو إيثرنت والالتقاط، وليست قياسات أو سلوكًا مضمونًا خاصًا بطراز معين.
دليل CRC وFCS ذو الصلة · دليل الديباجة وفجوة الإطار ذو الصلة
