zeroTOzero
./عضو جديد
بسم الله الرحمن الرحيم
اللهم صل و سلم على نبينا محمد و على آله وصحبه و سلم تسليما
بإذن الله سأشارككم في هذا المنشور معارفي حول بروتوكول Ethernet II
قبل الشروع في الموضوع أقترح عليكم الموضوع التالي لفهم فكرة البروتوكولات و ماهيتها : بروتوكولات الحواسيب ومُحاكاتها لبروتوكولات البشر
كما اقترح عليكم قراءة هذا الموضوع أيضا لفهم أسلوب التغليف الذي تتبعه الشبكات لنقل البيانات : التغليف (Encapsulation): السر وراء التواصل الشبكي الفعّال
و لا أنسى ضرورة المعرفة بأساسيات الشبكات و أساسيات Wireshark
اللهم صل و سلم على نبينا محمد و على آله وصحبه و سلم تسليما
بإذن الله سأشارككم في هذا المنشور معارفي حول بروتوكول Ethernet II
قبل الشروع في الموضوع أقترح عليكم الموضوع التالي لفهم فكرة البروتوكولات و ماهيتها : بروتوكولات الحواسيب ومُحاكاتها لبروتوكولات البشر
كما اقترح عليكم قراءة هذا الموضوع أيضا لفهم أسلوب التغليف الذي تتبعه الشبكات لنقل البيانات : التغليف (Encapsulation): السر وراء التواصل الشبكي الفعّال
و لا أنسى ضرورة المعرفة بأساسيات الشبكات و أساسيات Wireshark
I - تعريف البروتوكول
بروتوكول Ethernet هو أشهر بروتوكول مستعمل في الشبكات السلكية و هو بروتوكول يعمل في الطبقة الثانية من نموذج OSI .
هذا البروتوكول يعتبر الوسيط الذي يربط بين الطبقات العليا و بين الطبقة الفزيائية. لذا سنجده دائما كطبقة أم تغلف كل الطبقات.
للبروتوكول نسختان مشهورتان:
* نسخة Ethernet II : هي نسخة شائعة جدا و غالبا أنت حاليا تستعملها لو كنت متصل بكابل من نوع Ethernet
هذه النسخة تسمى كذلك DIX Ethernet و كلمة DIX تجمع أول حرف من الشركات الثلاثة التي طورت هذا البروتوكول: Digital Equipment Corporation و Intel و Xerox.
* نسخة IEEE 802.3 : و قد طورتها منظمة Institute of Electrical and Electronics Engineers.
كلا النسختين مستخدمتين لكن لو قارنا بينهما سنجد Ethernet II هو الأكثر إستخداما.
سأتطرق لكلا النسختين, لكن في هذا المنشور سأشرح فقط نسخة Ethernet II و بشكل أدق سنتطرق لرأس هذا البروتوكول.
II - رأس بروتوكول Ethernet II
الصورة أعلاه تمثل رأس بروتوكول Ethernet
لدينا عدة حقول, كل حقل يتم تمثيله في عدد بايتات محددة.
III - حقول Ethernet II
1. حقل الـ Preamble :
اولا لدينا حقل Preamble يمثل في 8 byte:
في الواقع هذا الحقل لا ينتمي لرأس البروتوكول بل هو منفصل عنه تماما, إلا أن له دور مهم في عملية التزامن بين المرسل والمستقبل.
حدوث مزامنة بين المرسل و المستقبل أمر مهم لضمان قراءة البيانات بشكل صحيح.
يتم ذلك عن طريق إرسال 8 bytes من البيانات أي 64 bits على شكل سلسلة متتابعة من 1 و 0 بهذا الشكل :
10101010.....10101010
السبب وراء ضرورة المزامنة هو أن جهاز المستقبل يحتاج إلى بداية واضحة ليعرف متى تبدأ البيانات الفعلية.
يمكنك إعتبار الـ Preamble كـ وكزة لجهاز المستقبل فهو بمثابة إشارة تنبيه له ليعرف أنه يجب عليه أن يبدأ في الاستعداد لاستقبال البيانات القادمة.
بدون الـ Preamble إذا أرسل جهاز ما إطار بيانات بدون أن يسبق ذلك Preamble، قد يكون الجهاز المستقبل في حالة ركود أو غير مستعد تمامًا لاستقبال البيانات مما قد يتسبب في خسارة بعض البتات و بالتالي قراءة غير صحيحة للبيانات.
2. حقل Destination MAC Address :
من إسمه و حجمه تتضح فكرته بأكملها.
هذا الحقل يخزن قيمة بحجم 6 bytes أي 48 bit و هذه القيمة هي العنوان الفزيائي الخاصة بالمستقبل.
لمذا تسبق قيمة Destination MAC Address قيمة Source MAC Address؟
سبب ذلك ببساطة أن المستقبل عندما يتوصل بهذا الإطار, يقوم بقراءة أول 6 byte منه أي Destination MAC Address إذا تطابقة مع خاصته سيستمر في معالجة الإطار لكن إذا لم يتطابق معه سيقوم بتجاهل الإطار و حسب.
3. حقل Source MAC Address :
هذا الحقل يخزن قيمة العنوان الفزيائي للمرسل و أيضا حجمه 6 bytes أي 48 bits.
هذا الحقل مهم لانه يسمح للمستقبل بمعرفة مصدر البيانات, و يساعد بشكل مباشرة في إرسال الردود إذا لزم الأمر (مثلا في حالة إرسال حزم ICMP).
4. حقل type :
يمثل هذا الحقل في 2 بايت أي 16 بت، ويستخدم للإشارة إلى نوع البروتوكول الذي يحتويه هذا الإطار.
تخيل أن بروتوكول Ethernet يقوم بتغليف بروتوكول IPv4، في هذه الحالة ستكون قيمة حقل Type هي القيمة التي تشير إلى بروتوكول IPv4.
كل بروتوكول لديه قيمة فريدة يتم تمثيلها بهذا الحقل:
البروتوكول | قيمته بــ : Hexadecimal | قيمةته بــ : Decimal |
IPv4 | 0x0800 | 2048 |
IPv6 | 0x86DD | 34525 |
ARP | 0x0806 | 2054 |
RARP | 0x8035 | 32821 |
Dot1Q | 0x8100 | 33024 |
هذه بعض القيم و هناك قيم أخرى.
سؤال : لماذا نحتاج إلى حقل Type؟
للإجابة على السؤال سنستعمل المثال التالي :
هذه الصورة عبارة عن سلسلة من البتات تخص استعلام DNS لعنوان IPv4 الخاص بالمنتدى.
كما نرى في الصورة تم تقسيم سلسلة البتات لمجموعات كل مجموعة بلون مختلف.
- اللون الأصفر يمثل رأس Ethernet.
- اللون الأخضر يمثل الطبقة التالية، والتي في هذا المثال هي رأس IPv4.
- اللون الأزرق هو رأس UDP.
- اللون الأحمر يمثل رأس بروتوكول DNS.
تخيل لو لم أخبرك أن الجزء الأخضر هو رأس IPv4، كيف كنت ستتعرف عليه؟ وكيف كنت ستتمكن من معالجة هذه الطبقة بطريقة صحيحة تسمح لك بفهم البيانات كما ينبغي؟ ففي نهاية الأمر، كل ما تملكه هو سلسلة من البتات لا تعرف ماذا تعني أو كيف تتعامل معها.
هنا يأتي دور حقل Type. عندما نرجع إلى آخر 16 بت في رأس Ethernet (اللون الأصفر) و قمنا بتحويلها للنظام العشري سنجد أنها تساوي 2048، وهي القيمة التي تدل على أن البروتوكول التالي هو IPv4.
ملاحظة : نفس الفكرة لا تقتصر على Ethernet فقط. كل طبقة في نموذج OSI يجب أن تمتلك آلية تشير إلى البروتوكول الموجود في الطبقة الموالية لضمان إمكانية التعامل معه.
لهذا نلاحظ أن الألوان الأخرى (مثل الأخضر والأزرق) أيضًا تحتوي على بتات مسطرة تستخدم للإشارة إلى البروتوكول التالي، باستثناء اللون الأحمر (DNS) لأنه يمثل الطبقة الأخيرة، وبالتالي لا حاجة للإشارة إلى أي طبقة تالية.
من المهم أن نعرف أن حقل Type لا يشير إلى بروتوكولات تعمل في الطبقات العليا مثل TCP، UDP، DNS، DHCP، أو FTP. بل يحدد فقط البروتوكولات التي تعمل في الطبقة الثانية مثل ARP، أو في الطبقة الثالثة مثل IPv4 و IPv6.
السبب بسيط: لا يمكن لطبقة في نموذج OSI أن تتواصل مباشرة مع طبقة لا تسبقها أو لا تليها. بمعنى آخر الطبقة الثانية لا يمكن أن تتواصل مباشرة مع الطبقة السابعة أو الرابعة.
سؤال : هل يمكن لبروتوكول أن يغلف بروتوكولًا آخر يعمل في نفس الطبقة؟
نعم، ويمكن رؤية ذلك في مثال تغليف Ethernet لبروتوكول ARP. كلاهما يعمل في الطبقة الثانية، ولكن ARP يحتاج إلى وسيط فيزيائي لنقل بياناته، وهو ما يوفره له Ethernet.
في سخة Ethernet II قيمة حقل type تكون أكبر من أو تساوي 1536 و سنعرف سبب ذلك مع نسخة Ethernet 802.3
5. حقل User Data :
هذا الحقل حجمه متغير لأنه يحوي بيانات الطبقات العليا لكن من الضروري أن لا يتجاوز 1500 bytes و لا يقل عن 46 bytes.
سؤال : لمذا لا يجب أن يتجاوز 1500 Bytes ؟
لأنه في الماضي البعيد كانت تكلفة الذاكرة العشوائية (RAM)باهظة الثمن وصغيرة الحجم مقارنة بالوقت الحالي. لذا تم تحديد هذا الحجم ليتناسب مع قدرة الأجهزة على معالجة الإطارات دون مشاكل في الذاكرة أو الأداء.
حسنا هذا في الماضي. لكن الآن أحجام الذاكرة أصبحت أكبر و الأثمنة أصبحة أقل مقارنة بالماضي. فلم لازال من الضروري احترام حدود ال 1500 bytes ؟
السبب في ذلك راجع لأن البروتوكولات بمجرد أن يتم إعتمادها يكون من الصعب إستبدالها أو التعديل فيها. (سوف نتطرق لسبب ذلك في مواضيع أخرى إن شاء الله)
سؤال : لمذا لا يجب أن يكون حجم هذا الحقل أقل من 46 bytes ؟
الجواب بشكل مختصر هو لمنع وقوع تصادمات بينن الإطارات.
كيف ذلك؟
بروتوكول ال ethernet يستعمل تقنية تدعى CSMA/CD و هي اختصار ل: Carrier Sense Multiple Access/Collision Detection
بالنسبة ل CSMA فهذه التقنية تقتضي أن المرسل قبل أن يرسل الإطار يقوم أولا بالإستماع للكابل, اذا كان الكابل مشغولا أي أنه توجد بيانات قيد الإرسال فيه فهنا الجهاز ينتظر. بمجرد أن يصبح الكابل فارغا يشرع المرسل في الإرسال. لكن هذه الآلية لوحدها غير كافية، لأنه من الممكن أن يبدأ جهازان أو أكثر بالإرسال في نفس اللحظة، مما سيؤدي إلى تصادم بين الإطارات. وهنا يأتي دور الجزء الثاني من التقنية: CD (Collision Detection).
بالنسبة ل CD فهذه التقنية تقتضي أن المرسل عندما يشرع في إرسال البيانات يقوم في نفس الوقت بالإستماع للكابل بحيث يقارن بين البيانات التي يريد إرسالها و بين ما يتم سماعه من الكابل. إذا كان ما يسمعه من الكابل مشابه لما يرسله فهنا لا يوجد أي تصادم . لكن لو لاحظ أن ما يسمعه مختلف عن ما يفترض أن يرسله فسوف يتوقف عن الإرسال و يقوم بإرسال إشارة تدعى JAM signal لإبلاغ الأجهزة الأخرى بأن التصادم قد حدث. بعد ذلك، يتوقف الجميع عن إرسال البيانات، ويعيد كل جهاز المحاولة بعد فترة عشوائية.
سؤال : ما علاقة هذا بضرورة أن يكون حقل User Data أكبر من 46 Bytes؟
هذا مرتبط مباشرة بتقنية Collision Detection (CD).
الفكرة هي أنه لو كان الإطار قصيرا جدا، فقد ينتهي المرسل من إرسال آخر بت قبل أن تصل إليه إشارة التصادم التي ربما حدثت في مكان بعيد على الكابل.
صحيح أن المرسل أنهى الإرسال، لكن الإشارات لا تنتقل لحظيًا، بل تحتاج وقتًا للسفر عبر الكابل. وإذا حدث التصادم بعد انتهاء الإرسال، فلن يستطيع المرسل اكتشافه، لأنه قد توقف عن الاستماع للكابل بمجرد إنهاء الإرسال. وهنا تكمن الخطورة! قد يكون هناك تصادم فعلي، لكن المرسل لا يعلم بذلك ويظن أن الإطار أرسل بنجاح.
لذلك، تم فرض حد أدنى لحجم الإطار بحيث لا يقل حقل User Data عن 46 بايت. هذا يضمن أن الإطار يستغرق وقتا كافيا أثناء الإرسال مما يبقي المرسل في وضع الاستماع طوال المدة اللازمة لاكتشاف أي تصادم محتمل.
في حال كانت لديك بيانات أقل من 46 bytes (و هذا أمر نادر) و تريد إرسالها فلديك حل و هو الحشو Padding. إضافة الحشو هو عملية إضافة أصفار لحقل User Data بحيث يصل حجمه ل 46 bytes. هذا الحشو لا يحمل أي معنى وظيفي، بل هدفه فقط استيفاء شرط الطول الأدنى للإطار.
لكن البيانات هنا ستتغير!
لا، الحشو لا يغير البيانات الفعلية التي تريد إرسالها. لأنه ببساطة، يتكون من أصفار لا تحمل أي قيمة.
عندما يستقبل المستقبل الإطار، سيقوم بقراءة حقل User Data و يتجاهل الحشو. و بعبارة أدق البروتوكولات في الطبقات العليا هي من ستقوم بتجاهل الحشو.
6. حقل FCS :
حقل FCS (Frame Check Sequence) هو حقل مكون من 4 byte، ويهدف إلى اكتشاف الأخطاء التي قد تحدث أثناء إرسال الإطار، مثل الأخطاء الناتجة عن التشويش.
يتم تطبيق خوارزمية CRC-32 على البيانات الموجودة في الإطار، بدءا من Destination MAC Address وصولا إلى آخر بت من User Data. يتم بعد ذلك إدراج القيمة الناتجة من الخوارزمية في حقل FCS.
من المهم ملاحظة أن CRC-32 دائمًا تعيد قيمة بحجم 4 بايت أي 32 بت.
أيضا من المهم معرفة أن حقل FCS لا يستخدم لمعالجة الأخطاء، بل هو مجرد أداة لاكتشاف الأخطاء.
عندما يستقبل المستقبل الإطار، يقوم بتطبيق CRC-32 على البيانات بدءا من Destination MAC Address وصولا إلى آخر بت من User Data. إذا تساوى الناتج مع قيمة FCS الموجودة في الإطار المستلم فهنا كل شيء سليم. أما إذا كان هناك اختلاف بين القيمتين، فهذا يعني أن هناك خطأ قد حدث أثناء النقل.
ملحوظة :
قلنا سابقا أن أقل حجم للبيانات هو 46 bytes و اقصى حجم هو 1500 bytes لكن دون احتساب باقي حقول الرأس.
يعني مع احتساب باقي حقول الرأس يصبح الطول الأدنى :
6 + 6 + 2 + 4 + 46 = 64 bytes
و الحد الأقصى سيكون :6 + 6 + 2 + 4 + 46 = 1518 Bytes
IV - تطبيق عملي بسيط :
تحليل إطار Ethernet باستخدام Wireshark :
الصورة أعلاه تظهر حزمة Echo Request (ICMP) مرسلة من جهاز، يتبعها Echo Reply كاستجابة من الطرف الآخر.
لنحلل رأس Ethernet لأول حزمة :
عند تحديد أول حزمة، ستظهر لنا بياناتها كما يلي :
نلاحظ أن Wireshark يعرض البيانات بطريقتين:
- القسم الأول (اليسار): يعرض البيانات بشكل مقروء ومفهوم لنا.
- القسم الثاني (اليمين): يعرض نفس المعلومات بشكلها الخام (RAW).
الآن لنبدأ في استخراج حقول رأس إطار الــ Ethernet :
كما نلاحظ في الصورة، يشير السهم الأحمر إلى قيمة عنوان MAC الخاص بالوجهة (Destination MAC Address). في القسم الأيسر من العرض، نلاحظ أن عنوان MAC للوجهة هو: 52:54:00:12:35:00.
أما في القسم الأيمن، تظهر أول 6 بايتات بشكلها الخام، و التي وفق بروتوكولEthernet فإنها تعني Destination MAC Address.
نفس الشيء ينطبق على السهم الأخضر، ولكن هنا يتم تحديد عنوان MAC المصدر (Source MAC Address).
بالنسبة للسهم الأسود، فإنه يشير إلى قيمة حقل Type. في مثالنا هذا، نجد أن الحقل يحمل القيمة 0x0800 بنظام Hexadecimal، وهو ما يعادل 2048 بالنظام العشري. كما ذكرنا سابقًا، يتم استخدام هذا الحقل لتحديد البروتوكول الموالي الذي تم تغليفه بواسطة بروتوكول Ethernet.
القيمة 2048 تدل على أن البروتوكول المغلف هو IPv4. ويمكننا تأكيد ذلك من خلال ملاحظة رأس الطبقة التالية في الصورة، والتي تُظهر بوضوح بروتوكول IPv4.
بالنسبة لـ حقل User Data، كما قيل سابقا، هو حقل متغير الحجم. في مثالنا هذا، كما هو موضح في الصورة أسفله، يحتوي هذا الحقل على بيانات الطبقات العليا, رأس IPv4، يليه رأس ICMP.
مهلا يوجد شيء ناقص أليس كذلك ؟ أين حقل FCS ؟
في الواقع، Wireshark لا يعرض حقل FCS لأن هذه القيمة يتم حسابها ومعالجتها على مستوى كرت الشبكة NIC نفسه قبل أن يتم إرسال الإطار إلى Wireshark أو أي تطبيق آخر يلتقط البيانات من الشبكة.
هل يمكن جعل Wireshark يعرض هذه القيمة؟ بصراحة أنا لا أعلم.
كما نلاحظ في الصورة، يشير السهم الأحمر إلى قيمة عنوان MAC الخاص بالوجهة (Destination MAC Address). في القسم الأيسر من العرض، نلاحظ أن عنوان MAC للوجهة هو: 52:54:00:12:35:00.
أما في القسم الأيمن، تظهر أول 6 بايتات بشكلها الخام، و التي وفق بروتوكولEthernet فإنها تعني Destination MAC Address.
نفس الشيء ينطبق على السهم الأخضر، ولكن هنا يتم تحديد عنوان MAC المصدر (Source MAC Address).
بالنسبة للسهم الأسود، فإنه يشير إلى قيمة حقل Type. في مثالنا هذا، نجد أن الحقل يحمل القيمة 0x0800 بنظام Hexadecimal، وهو ما يعادل 2048 بالنظام العشري. كما ذكرنا سابقًا، يتم استخدام هذا الحقل لتحديد البروتوكول الموالي الذي تم تغليفه بواسطة بروتوكول Ethernet.
القيمة 2048 تدل على أن البروتوكول المغلف هو IPv4. ويمكننا تأكيد ذلك من خلال ملاحظة رأس الطبقة التالية في الصورة، والتي تُظهر بوضوح بروتوكول IPv4.
بالنسبة لـ حقل User Data، كما قيل سابقا، هو حقل متغير الحجم. في مثالنا هذا، كما هو موضح في الصورة أسفله، يحتوي هذا الحقل على بيانات الطبقات العليا, رأس IPv4، يليه رأس ICMP.
مهلا يوجد شيء ناقص أليس كذلك ؟ أين حقل FCS ؟
في الواقع، Wireshark لا يعرض حقل FCS لأن هذه القيمة يتم حسابها ومعالجتها على مستوى كرت الشبكة NIC نفسه قبل أن يتم إرسال الإطار إلى Wireshark أو أي تطبيق آخر يلتقط البيانات من الشبكة.
هل يمكن جعل Wireshark يعرض هذه القيمة؟ بصراحة أنا لا أعلم.
إن أحسنت فمن الله، وإن أسأت فمن نفسي والشيطان
وفقكم الله و إياي
المرفقات
التعديل الأخير بواسطة المشرف:
