تصوير نموذج OSI المرجعي بوضوح ── تشريح طلب HTTP واحد إلى سبع طبقات

نموذج OSI المرجعي أول ما يظهر حتماً في أي كتاب تمهيدي عن الشبكات، ومع ذلك نسمع كثيراً: «أستطيع تعداد أسماء الطبقات السبع، لكن بصراحة لا يتكوّن لدي تصوّر». يحفظ المرء الطبقة الفيزيائية وطبقة ارتباط البيانات وطبقة الشبكة، ثم يبقى عاجزاً عن ربط ذلك المخطط ذي السبع درجات بشيفرة C# التي يكتبها، أو بعطل الاتصال القائم أمامه.

هذا المقال موجَّه إلى مطوّري تطبيقات Windows ومبتدئي الشبكات. تظهر فيه قصاصات C# وأوامر Windows (ping / tracert / arp وغيرها)، لكن لا حاجة لمعرفة مسبقة بالحزم أو البروتوكولات. البنية تسمح بالمتابعة بالقراءة وحدها. وإذا أردت التحقق بيدك، فبيئة يعمل فيها .NET SDK (أمر dotnet) وWireshark تكفي لإعادة إنتاج محتوى المقال على شاشتك كما هو.

نشرنا في هذه المدونة مقالات تناولت سلوك L4 (طبقة النقل)، مثل المفهوم الخاطئ بأنّ الاستقبال يتطابق مع وحدة الإرسال في TCP وحين تتوقّف حركة TCP للكاميرا الصناعيّة لعدّة ثوانٍ، لكن لم يكن هناك مقال يجمع فكرة «الطبقة» نفسها التي تشكّل أساس ذلك كله.

نهج هذا المقال بسيط. سننشئ فعلاً إطار Ethernet واحداً يحمل طلب HTTP GET واحداً، ثم نشرّحه من الخارج بالترتيب. الطبقات السبع ليست حديثاً داخل مخطط تصوري فقط، بل توجد متداخلة فيزيائياً داخل 171 بايتاً تجري في الشبكة. متى رأيت ذلك بعينك في تفريغ ست عشري وفي Wireshark، لم يعد نموذج OSI المرجعي مادة للحفظ.

الشيفرة الواردة في هذا المقال منشورة على GitHub كعيّنة كاملة يمكن بناؤها وتشغيلها (مكتبة تجميع الإطار وتشريحه، وتصدير pcap يفتحه Wireshark، واختبارات وحدة).

osi-model-packet-anatomy - komurasoft-blog-samples (GitHub)

1. الخلاصة أولاً

• نموذج OSI المرجعي «مفردات» لا «تنفيذ». ما يعمل على الإنترنت الحقيقي هو مجموعة بروتوكولات TCP/IP (أربع طبقات فعلياً).¹ بروتوكولات OSI ذات الطبقات السبع نفسها خسرت سباق الانتشار وانتهت شبه غير مستخدَمة.² ما بقي هو النموذج كلغة مشتركة من نوع «نعزل عند L2» أو «هذه مشكلة L7».
• الطبقات السبع متداخلة فيزيائياً كسلسلة بايتات. في إطار يحمل HTTP GET، أول 14 بايتاً ترويسة Ethernet (L2)، والتالية 20 بايتاً ترويسة IPv4 (L3)، والتالية 20 بايتاً ترويسة TCP (L4)، والباقي نص HTTP (L7). بدء ترويسة كل طبقة مباشرة بعد الطبقة السابقة يمكن تأكيده كما هو في التفريغ الست عشري وفي Wireshark في المتن.
• ما تكتبه شيفرة C# لديك مباشرة هو بايتات L7 فقط. ما تُمرَّره إلى Socket.Send بيانات تطبيق فحسب. ترويسات TCP وIP يضعها مكدس بروتوكولات نظام التشغيل، وترويسة Ethernet والإشارة الكهربائية يضعها جانب NIC. لذلك اختيار HttpClient أو SslStream أو Socket هو اختيار «من أي طبقة فما دون تترك الأمر لنظام التشغيل».³
• L5 (طبقة الجلسة) وL6 (طبقة العرض) لا توجدان كطبقتين مستقلتين في المكدس الحقيقي. TLS وترميز الأحرف يضطلعان بجزء من ذلك الدور، لكن في نموذج TCP/IP تُجمعان في طبقة التطبيق. «لا أفهم ما هي L6» ليس تقصيراً منك، بل موضع ينزاح فيه النموذج عن الواقع.¹
• ما ينفع فيه نموذج OSI حقاً في العمل هو عزل الأعطال والحوار. تضييق من نوع «ping ينجح وHTTP يفشل، إذن L3 فما دون حيّ، فالشبهة من L4 فما فوق» بمفردات الطبقات لغة مشتركة تصل بين الشبكات والبنية التحتية ومطوّري التطبيقات.

في المخطّط، يشير الخطّ المتّصل إلى علاقة قائمة دائماً، ويشير الخطّ المتقطّع إلى علاقة مشروطة (شروط قيامها مذكورة في شرح كلّ علاقة في الصفحة التفصيليّة). القائمة الكاملة للعلاقات (المجموع 20، مع الأدلّة ودرجة اليقين) وتعريفات المفاهيم الرئيسة مجمّعة في صفحة تفاصيل خريطة المعرفة (باليابانية). البيانات: JSON-LD / Turtle

2. لماذا ينتهي نموذج OSI المرجعي عند الحفظ

كثير من الشروح يبدأ بجدول كهذا.

الجدول صحيح، لكن كل صف مكتوب بكلمات مجرّدة، فلا يتكوّن للقارئ تصوّر. من يسمع «تحوّل شكل تمثيل البيانات» ويعرف أي سطر في شيفرته يُقصد؟

وهناك واقعة تاريخية ينبغي كتابتها بصراحة. نموذج OSI المرجعي معيار وضعته ISO (المنظمة الدولية للتقييس) وITU-T (ISO/IEC 7498-1، ITU-T X.200)، وكان في الأصل تصوّراً واسعاً مقترناً بمجموعة بروتوكولات OSI تقابل كل طبقة من السبع.² لكن في سباق الانتشار في تسعينيات القرن الماضي صار TCP/IP، الذي كان يعمل أصلاً، المعيار الفعلي، وانتهت بروتوكولات OSI نفسها شبه غير مستخدَمة. RFC 1122 الذي وضع أسس الإنترنت يشرح العالم بأربع طبقات فعلياً: طبقة الارتباط، وطبقة الإنترنت (IP)، وطبقة النقل، وطبقة التطبيق، ولا طبقة مستقلة تعادل L5 وL6.¹

أي أن معنى تعلّم نموذج OSI المرجعي اليوم ليس «لأنه منفَّذ على هذا النحو»، بل لاكتساب أداة «التفكير بالطبقات» ومفردات مشتركة لعزل الأعطال. إذا وقفت على هذه الفرضية، لم تعد بحاجة إلى القلق لأنك «لا تجد عيّنة L5 وL6»، واتضح الأفق دفعة واحدة.

3. الموضوع: تشريح طلب HTTP واحد

كفى تمهيداً، ننظر إلى العيّنة. التفريغ الست عشري التالي إطار Ethernet (171 بايتاً كلها) يحمل طلب HTTP واحداً هو GET /index.html HTTP/1.1. جمعته شيفرة العيّنة المذكورة في المقدمة، ومجموع تحقق ترويسة IPv4 ومجموع تحقق TCP محسوبان صحيحاً، فإذا أُعطي لـ Wireshark عُرض كحزمة سليمة.

0000  02 00 00 00 00 01 02 00  00 00 00 02 08 00 45 00  ..............E.
0010  00 9d 12 34 40 00 40 06  3b 99 c0 00 02 0a c6 33  ...4@.@.;......3
0020  64 50 cb 84 00 50 00 00  03 e8 00 00 07 d0 50 18  dP...P........P.
0030  ff ff a3 05 00 00 47 45  54 20 2f 69 6e 64 65 78  ......GET /index
0040  2e 68 74 6d 6c 20 48 54  54 50 2f 31 2e 31 0d 0a  .html HTTP/1.1..
0050  48 6f 73 74 3a 20 65 78  61 6d 70 6c 65 2e 63 6f  Host: example.co
0060  6d 0d 0a 55 73 65 72 2d  41 67 65 6e 74 3a 20 4b  m..User-Agent: K
0070  6f 6d 75 72 61 53 6f 66  74 44 65 6d 6f 2f 31 2e  omuraSoftDemo/1.
0080  30 0d 0a 41 63 63 65 70  74 3a 20 74 65 78 74 2f  0..Accept: text/
0090  68 74 6d 6c 0d 0a 43 6f  6e 6e 65 63 74 69 6f 6e  html..Connection
00a0  3a 20 63 6c 6f 73 65 0d  0a 0d 0a                 : close....

في عرض ASCII على اليمين يتضح أن نصاً يقرأه الإنسان يبدأ في المنتصف (الإزاحة 0x36): GET /index.html HTTP/1.1. فما الـ 54 بايتاً التي قبل ذلك؟ إذا أُطعمت لمشرّح العيّنة، يبلّغ كالتالي.

[ L2 Ethernet II | offset   0 |  14 bytes | dst=02:00:00:00:00:01 src=02:00:00:00:00:02 type=0x0800 (IPv4)
  [ L3 IPv4        | offset  14 |  20 bytes | 192.0.2.10 -> 198.51.100.80 TTL=64 proto=6 (TCP) checksum=OK
    [ L4 TCP         | offset  34 |  20 bytes | 52100 -> 80 [Psh, Ack] seq=1000 win=65535
      [ L7 HTTP        | offset  54 | 117 bytes | GET /index.html HTTP/1.1

هذا الشكل هو ما نريدك أن تراه أكثر من غيره في المقال. النقاط ثلاث.

1. كل طبقة تبدأ «مباشرة بعد الطبقة السابقة». ترويسة Ethernet البايتات 0 إلى 13، وترويسة IPv4 14 إلى 33، وترويسة TCP 34 إلى 53، وHTTP من البايت 54. الطبقات ليست تصنيفاً تصورياً، بل نطاق بايتات من رأس الإطار يمكن الإشارة إليه.
2. الطبقة الداخلية «حمولة» الطبقة الخارجية. من منظور Ethernet، ما بعد IPv4 حمولة فحسب، ولا يعنيها إن كان المحتوى TCP. من منظور IP، ما بعد TCP حمولة، ومن منظور TCP فإن HTTP حمولة. كل طبقة تقرأ ترويستها فقط وتمرّر الحمولة إلى الأعلى دون أن تمسّها. بنية «عدم الاكتراث» هذه هي التغليف (encapsulation).
3. L1 (الطبقة الفيزيائية) وL5 وL6 لا تظهر في هذا الشكل. عمل L1 تحويل سلسلة البايتات هذه إلى إشارة كهربائية أو ضوء أو موجات، فلا تظهر في التفريغ. وL5 وL6، كما في الفصل السابق، لا كيان مستقل لهما في HTTP/1.1 الصريح. «من الطبقات السبع تظهر أربع في التفريغ» ── هذا وجه الواقع.

ونكرر: الأمر ليس خاصاً بـ HTTP. اتصال قاعدة بيانات، أو gRPC، أو GigE Vision لكاميرا صناعية: أي اتصال TCP/IP على Ethernet كل حزمة فيه بالبنية المتداخلة نفسها. ما يتغيّر هو محتوى حمولة L7 فقط.

4. L2 طبقة ارتباط البيانات ── الإيصال إلى «الجار»

ننظر إلى نتيجة التشريح من الخارج بالترتيب. أول 14 بايتاً ترويسة Ethernet II.

02 00 00 00 00 01   عنوان MAC الوجهة (6 بايتات)
02 00 00 00 00 02   عنوان MAC المصدر (6 بايتات)
08 00               EtherType = 0x0800 (الحمولة IPv4)

عمل L2 هو «الإيصال إلى العقدة المجاورة داخل قطعة الشبكة نفسها». تعيين الوجهة يستخدم عنوان MAC. عنوان MAC معرّف مخصَّص لـ NIC، ولا يصل من حيث المبدأ إلى الطرف الآخر عبر موجّه. عنوان MAC الوجهة في إطار يُرسل من جهاز في المكتب إلى خادم ويب ليس عنوان خادم الويب، بل عنوان MAC للبوابة الافتراضية (الموجّه).

هنا يتساءل كثيرون مرة: «إذا وُجد عنوان IP، فلماذا يلزم عنوان MAC؟». الجواب في توزيع الأدوار بين الطبقات. عنوان IP عنوان يشير إلى «الوجهة النهائية»، وعنوان MAC اسم يشير إلى «من سيحمل القطعة التالية من المسار». بمثال التوصيل: عنوان IP عنوان التسليم على بوليصة الشحن، وعنوان MAC اسم «مركز الترحيل التالي». البوليصة (L3) لا تتغيّر حتى النهاية، أما الاسم (L2) فيُستبدل في كل قطعة. ما يبحث عن عنوان MAC لعقدة مجاورة انطلاقاً من عنوان IP هو ARP، ويمكن الاطلاع على جدول التطابق الذي يحفظه الجهاز بأمر arp -a.

من جهة الأجهزة، ما ينظر إلى L2 ويمرّر هو المبدّل (محور التبديل). يختار المبدّل المنفذ بالنظر إلى عنوان MAC الوجهة فقط، ولا ينظر إلى عنوان IP في الحمولة.

5. L3 طبقة الشبكة ── الإيصال إلى أقصى العالم

العشرون بايتاً التالية ترويسة IPv4. ننتقي الحقول الرئيسة.

45          الإصدار=4، طول الترويسة=5 كلمات (20 بايتاً)
00 9d       الطول الكلي 157 بايتاً (ترويسة IP+TCP+HTTP. لا يشمل 14 بايت Ethernet)
40 06       TTL=64، البروتوكول=6 (الحمولة TCP)
3b 99       مجموع تحقق الترويسة
c0 00 02 0a عنوان IP المصدر   192.0.2.10
c6 33 64 50 عنوان IP الوجهة     198.51.100.80

عمل L3 هو «الإيصال إلى المضيف الوجهة النهائية، ولو عبر أي عدد من الموجّهات». L2 لا يحمل إلا قطعة واحدة (قفزة واحدة)، أما عنوان IP الوجهة في L3 فلا يتغيّر من أول الاتصال إلى آخره. ينظر الموجّه إلى عنوان IP الوجهة في الحزمة التي استلمها، ويقرّر «إلى أي موجّه أسلّم التالي»، ويستبدل ترويسة L2 ثم يرسل.

حركة «L2 وحدها تُستبدل» إذا رُسمت صارت كالتالي. ما يتغيّر في كل قطعة هو عنوانا MAC الوجهة والمصدر (L2) فقط، وعنوان IP الوجهة (L3) القيمة نفسها في القطع الثلاث.

flowchart LR
    accTitle: استبدال عنوان L2 عند عبور الموجّه
    accDescr: يتبدّل اسم الوجهة في L2 في كل قطعة، أما عنوان IP الوجهة في L3 فلا يتغيّر حتى النهاية. ينقص TTL واحداً كلما عُبر موجّه.
    PC["جهاز الإرسال<br/>192.0.2.10"]
    R1["الموجّه 1"]
    R2["الموجّه 2"]
    SV["خادم الويب<br/>198.51.100.80"]
    PC -->|"MAC الوجهة: الموجّه 1<br/>IP الوجهة: 198.51.100.80"| R1
    R1 -->|"MAC الوجهة: الموجّه 2<br/>IP الوجهة: 198.51.100.80"| R2
    R2 -->|"MAC الوجهة: خادم الويب<br/>IP الوجهة: 198.51.100.80"| SV

الشكل 1: اسم الوجهة في L2 يُستبدل في كل قطعة، وعنوان IP الوجهة في L3 لا يتغيّر حتى النهاية. ينقص TTL واحداً كلما عُبر موجّه.

TTL (Time To Live) حقل يُظهر حركة «عبور الموجّه» للعين. ينقص واحداً كلما عُبر موجّه، والحزمة التي تصير إلى 0 تُتلف ويُعاد خطأ إلى المرسل. tracert (أمر تتبّع المسار في Windows) يرسل عامداً بـ TTL = 1 ثم 2 ثم 3… فيكشف الموجّهات في الطريق واحداً واحداً. أي أن كل سطر في مخرجات tracert عيّنة حقيقية لـ «قفزة L3».

6. L4 طبقة النقل ── إلى أي عملية يُسلَّم

العشرون بايتاً التالية ترويسة TCP.

cb 84       منفذ المصدر 52100
00 50       منفذ الوجهة 80
00 00 03 e8 رقم التسلسل
00 00 07 d0 رقم التأكيد
50 18       طول الترويسة=5 كلمات، الأعلام [PSH, ACK]
ff ff       حجم النافذة
a3 05       مجموع التحقق

حتى L3 وصلت الحزمة إلى «المضيف (الجهاز)» الوجهة. لكن على ذلك الجهاز يتصل في الوقت نفسه خادم ويب وقاعدة بيانات وكثير من العمليات الأخرى. أحد أعمال L4 هو التوزيع برقم المنفذ على «أي عملية (مقبسها) تُسلَّم إليها البيانات». المنفذ الوجهة 80 عرف بأن «هذا الرقم الذي ينتظر عليه خادم HTTP»، فينظر نظام التشغيل إلى هذا الرقم ويضع البيانات في مخزن استقبال العملية المعنية.

العمل الكبير الآخر لـ TCP هو تقديم «تدفق بايتات موثوق» عبر رقم التسلسل والتأكيد وإعادة الإرسال والتحكم بالتدفق.⁴ سلوك هذا الجانب وكيفية التعامل معه عمق يكفي لمقال مستقل لكل منهما، فنحيله إلى حديث حدود الرسالة في TCP وحديث إعادة إرسال TCP. هنا اكتفِ بالإحساس أن «من L4 فما فوق لم يعد على هيئة شبكة، بل يبدو أنبوباً يصل عملية بعملية».

وثمة واقعة طريفة تُظهر انزياح المثال الأعلى للنموذج عن الواقع. مجموع تحقق TCP معرَّف بأنه يُحسب لا على مقطع TCP وحده، بل بعد إلحاق «ترويسة وهمية» في الصدر تضم معلومات L3 (عنوانا IP المصدر والوجهة).⁴ لو كانت الطبقات مستقلة نظيفاً، لما اختلط عنوان L3 في حساب L4. مثال جيّد على أن نموذج OSI المرجعي خريطة للتنظيم، أما البروتوكولات الحقيقية فتعبر الطبقات عند الحاجة.

7. L5 وL6 ── حيث ينزاح النموذج عن الواقع

لم يكن في شكل التشريح L5 (طبقة الجلسة) ولا L6 (طبقة العرض). هنا أكبر سبب للشعور بأن «OSI غير مفهوم»، فنكتبه بوضوح.

L5 وL6 لا توجدان كطبقتين مستقلتين في مكدس TCP/IP الحقيقي. في نموذج الإنترنت في RFC 1122، كل ما فوق TCP «طبقة تطبيق».¹ الأدوار التي تصوّرها نموذج OSI تبعثرت وامْتُصت في الواقع كالتالي.

في HTTPS مثلاً، يُقحم TLS فوق TCP (L4)، ويجري HTTP داخله. «إلى أي طبقة ينتمي TLS؟» سؤال يغري بأن يصير سؤال اختبار، لكن لا قيمة عملية لتحديد إجابة واحدة. فوق L4 وتحت L7، ويجمع إدارة الجلسة (دور من نوع L5) والتشفير (دور من نوع L6) ── أن تستطيع شرح ذلك أهم من أن تجيب فوراً «إنها L6».

في شيفرة .NET يظهر هذا التقابل كما هو في طريقة رصّ الأصناف. إذا غلّفت تدفق L4 الحاصل من TcpClient.GetStream() بـ SslStream، فإن النص الصريح الذي تكتبه في Write يُشفَّر في سجل TLS ثم يُمرَّر إلى TCP.⁵

using var client = new TcpClient("example.com", 443);
// L4のバイトストリームを、TLS(L5/L6相当)でラップする
using var ssl = new SslStream(client.GetStream());
await ssl.AuthenticateAsClientAsync("example.com");
// ここに書くのはL7(HTTP)の平文。暗号化はSslStreamの仕事
await ssl.WriteAsync(Encoding.ASCII.GetBytes("GET / HTTP/1.1\r\n..."));

تغليف تدفق بتدفق هو النسخة البرمجية من التغليف. إذا نظرت في Wireshark إلى اتصال المنفذ 443، لم تعد حمولة TCP سوى كتلة معتِمة اسمها Application Data، فتؤكد من الاتجاه المعاكس أن «L7 دخلت غلافاً يعادل L6».

8. أي طبقة تلمسها شيفرة C# لديك

نقابل ما سبق بأدوات مطوّر تطبيقات Windows.

من هذا الجدول يُقرأ أمران.

أولاً، اختيار الواجهة اختيار «من أي طبقة فما دون تترك الأمر». بـ HttpClient تُترَك حتى تجميع L7، وبـ Socket تكتب L7 كله بنفسك. وبالعكس، نادراً ما يشغّل تطبيق Windows عادي L3 فما دون مباشرة (المقبس الخام يصاحبه امتياز مدير وقيود قوية).

ثانياً، ما تُمرَّره إلى Socket.Send هو بايتات L7 «فقط». الجزء 2 من العيّنة عرض يرسل طلب HTTP فعلاً عبر الحلقة الراجعة، وما يجهّزه التطبيق 60 بايتاً من نص HTTP فقط، ومجموعة الترويسات البالغة 54 بايتاً التي رأيناها في الفصل 3 يضعها نظام التشغيل وNIC. شيفرة الشبكة في تطبيقك في الواقع لا تصنع سوى الحمولة الأعمق بين الطبقات السبع ── هذا هو الموضع الدقيق لنموذج OSI من شيفرتك.

using var socket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
await socket.ConnectAsync(IPAddress.Loopback, port);

byte[] request = Encoding.ASCII.GetBytes(
    $"GET / HTTP/1.1\r\nHost: localhost:{port}\r\nConnection: close\r\n\r\n");

// 渡すのはL7のバイト列だけ。TCP/IP/Ethernetのヘッダーは
// この呼び出しの向こう側(OSとNIC)で付けられる
int sent = await socket.SendAsync(request);

9. التطبيق العملي ── تجميع إطار وفتحه في Wireshark

لتحويل «فهمت بالقراءة» إلى «فهمت بالرؤية»، نعرض طريقة تشغيل شيفرة العيّنة.

مركز العيّنة هو SampleFrameBuilder الذي يجمع إطار الفصل 3 بالترتيب نفسه الذي تُغلَّف فيه الطبقات من L7 إلى L2. ما يحدث في كل طبقة عند الإرسال هو ترتيب الدوال نفسه.

public static byte[] BuildHttpGetFrame()
{
    // L7: アプリケーションが Send に渡すのはこのバイト列「だけ」
    byte[] http = Encoding.ASCII.GetBytes(HttpRequest);

    // L4: OS のプロトコルスタックが TCP ヘッダーを前置する
    byte[] tcp = WrapInTcp(http);

    // L3: さらに IPv4 ヘッダーを前置する
    byte[] ip = WrapInIpv4(tcp);

    // L2: NIC ドライバーの手前で Ethernet ヘッダーを前置する
    return WrapInEthernet(ip);
}

عند تشغيل العرض يُطبع التفريغ الست عشري والعرض المتداخل، ويُصدَّر هذا الإطار أيضاً كملف pcap.

dotnet run --project samples/Demo

افتح sample-http-get.pcap الناتج في Wireshark.⁶ في اللوحة الوسطى (لوحة تفاصيل الحزمة) تصطف عمودياً أربعة أسطر: Ethernet II / Internet Protocol Version 4 / Transmission Control Protocol / Hypertext Transfer Protocol. إذا نقرت أحدها، يُبرَز نطاق البايتات المعني فقط في اللوحة السفلى (لوحة سلسلة البايتات). هذا التقابل إذا رُسم صار كالتالي، وهو العرض المتداخل نفسه في الفصل 3، تعرضه أداة معيارية في الصناعة.

flowchart LR
    accTitle: تقابل لوحة التفاصيل ولوحة البايتات في Wireshark
    accDescr: اختيار سطر في لوحة التفاصيل يعكس في الأسفل نطاق البايتات الذي تشغله ترويسة تلك الطبقة فقط.
    subgraph DETAIL["لوحة تفاصيل الحزمة ── أربعة أسطر من الأعلى"]
        E["Ethernet II"]
        I["Internet Protocol Version 4"]
        T["Transmission Control Protocol"]
        H["Hypertext Transfer Protocol"]
    end
    subgraph BYTES["لوحة سلسلة البايتات ── النطاق المبرَز"]
        BE["البايتات 0 إلى 13"]
        BI["البايتات 14 إلى 33"]
        BT["البايتات 34 إلى 53"]
        BH["البايتات 54 إلى 170"]
    end
    E -->|"نقرة"| BE
    I -->|"نقرة"| BI
    T -->|"نقرة"| BT
    H -->|"نقرة"| BH

الشكل 2: تقابل أسطر لوحة التفاصيل ولوحة البايتات. اختيار سطر يعكس في الأسفل نطاق البايتات الذي تشغله ترويسة تلك الطبقة فقط.

إذا تأكد ذلك، فالخطوة التالية حركة حقيقية. ابدأ التقاطاً في Wireshark، وضع في المرشّح شيئاً مثل tcp.port == 443، وافتح موقعاً في المتصفح، فتؤكد أن الاتصال الحقيقي كله مصنوع من هذا التداخل.

وفي تنفيذ المشرّح (PacketDissector) أيضاً مواضع تعلّم عملية. مثلاً عند اقتطاع حمولة IPv4 يجب الاقتطاع بالثقة في حقل TotalLength في الترويسة، لا ببقية مخزن الاستقبال كلها. لـ Ethernet طول إطار أدنى (60 بايتاً)، فتُلحق بالحزم القصيرة حشوة بلا معنى في الذيل. «إزالة مقتضيات الطبقة الخارجية (الحشوة) بمعلومة طول الطبقة الداخلية» ── مثال آخر يظهر فيه توزيع أدوار الطبقات في التنفيذ، ونتحقق منه باختبارات الوحدة.

10. استخدام نموذج OSI في العمل ── العزل بمفردات الطبقات

كتبنا في المقدمة أن «OSI بقي كمفردات». نذكر موضعين ينفع فيهما هذا المعجم فعلاً.

عزل الأعطال. بلاغ «لا أستطيع الاتصال بالخادم» إذا تُرجم إلى مفردات الطبقات أمكن تضييقه منهجياً. القاعدة التحقق من الأسفل بالترتيب.

مثلاً إذا نجح ping وفشل Test-NetConnection، فإن L3 فما دون سليم، وتضيق الشبهة إلى شيء يسد المنفذ عند L4 (توقف خدمة، جدار حماية، خطأ في رقم المنفذ). وإذا أمكن اتصال TCP وأعاد HTTP 400، فالمشكلة ليست الشبكة بل L7 (محتوى الطلب). بدل نزع الكابل وإعادته عشوائياً، تثبيت أي طبقة حيّة درجة درجة ── هذا استخدام نموذج OSI في العمل.

لغة مشتركة للحوار. حوار من نوع «يبدو أنها مشكلة L2 فانظر إلى منفذ المبدّل» أو «هذا حديث L7 فإلى فريق التطبيق» يصل بدقة بين مسؤول الشبكة ومسؤول البنية التحتية ومطوّر التطبيق. رقم الطبقة إحداثيات مشتركة في الصناعة لاختصار نقطة المسؤولية.

11. تصحيح مفاهيم خاطئة شائعة

أخيراً نصحّح مفاهيم خاطئة شائعة حول نموذج OSI المرجعي.

• «الإنترنت يعمل بطبقات OSI السبع» ── لا يعمل. المنفَّذ هو TCP/IP (أربع طبقات فعلياً)، وOSI نموذج مرجعي للشرح والحوار.¹
• «طبقات TCP/IP الأربع تقابل طبقات OSI السبع نظيفاً» ── تقابل L5 إلى L7 غامض في جوهره. كثيراً ما يُرى جدول «طبقة تطبيق TCP/IP = L5+L6+L7 في OSI»، لكن كما في الفصل 7 أدوار L5 وL6 تبعثرت في الواقع في TLS وصيغ التسلسل.
• «TLS بروتوكول الطبقة السادسة (أو الخامسة)» ── لا معنى لتحديد طبقة واحدة. فوق L4 وتحت L7، ويجمع أدواراً تعادل L5 وL6، هذا هو الشرح الدقيق.
• «برقم المنفذ تُعرف البروتوكول» ── المنفذ 80 لا يعني حتماً HTTP. رقم المنفذ عرف، وما يجري فعلاً لا يُعرف حتى النظر إلى الحمولة. لهذا يحكم مشرّح العيّنة على HTTP بسلسلة البداية في المحتوى لا برقم المنفذ.
• «المبدّل جهاز L2 والموجّه جهاز L3» ── صحيح كنقطة انطلاق، لكن في الواقع شائعة أجهزة تعبر عدة طبقات: مبدّل L3، وموازن حمل يوزّع عند L4، وWAF يفحص L7. الأدق أن تمسك الجهاز بـ «حتى أي طبقة يقرأ».

12. الخلاصة

• نموذج OSI المرجعي ليس تنفيذاً، بل مفردات للتفكير بالطبقات. ما يعمل فعلاً هو TCP/IP (أربع طبقات فعلياً)
• الطبقات السبع ليست مخططاً تصورياً، بل متداخلة فيزيائياً داخل سلسلة بايتات إطار واحد (L2: 0 إلى 13، L3: 14 إلى 33، L4: 34 إلى 53، L7: من 54)
• كل طبقة تقرأ ترويستها فقط ولا تعنيها الحمولة (الطبقة الداخلية) ── هذا هو التغليف
• L5 وL6 لا توجدان مستقلتين في المكدس الحقيقي، وTLS والترميز امتصا الدور
• ما تكتبه شيفرة C# لديك بايتات L7 فقط. ترويسات TCP/IP يضعها نظام التشغيل، وEthernet يضعها NIC
• الاستخدام في العمل عزل الأعطال بالتحقق من بقاء كل طبقة حيّة من الأسفل درجة درجة، ولغة مشتركة بين الفرق
• اجمع إطاراً بشيفرة العيّنة وافتحه في Wireshark، فيمكن تأكيد محتوى هذا المقال كله بعينك

مقالات ذات صلة

• المفهوم الخاطئ بأنّ الاستقبال يتطابق مع وحدة الإرسال في TCP ── تصميم الاستقبال بالتعامل مع TCP كتدفّق بايتات
• حين تتوقّف حركة TCP للكاميرا الصناعيّة لعدّة ثوانٍ
• أفضل الممارسات لـ C# async/await - جدول قرار لـ Task.Run و ConfigureAwait

مجالات استشارية ذات صلة

تتعامل شركة كومورا سوفت ذ.م.م. مع تصميم وتنفيذ تطبيقات Windows التي تتصل عبر TCP/IP، والتحقيق في أعطال الاتصال من نوع «ينقطع أحياناً أو يبطئ» مع الأجهزة الصناعية، ودعم عزل الأعطال بالتقاط الحزم.

• تطوير تطبيقات Windows
• التحقيق في الأعطال وتحليل الأسباب
• الاستشارات التقنية ومراجعة التصميم
• تواصل معنا

روابط مرجعية

مقالات ذات صلة

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

أين يتصل هذا الموضوع

ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.

الأسئلة الشائعة

أسئلة شائعة حول موضوع هذه المقالة.

هل تُستخدم الطبقات السبع لنموذج OSI المرجعي فعلياً على الإنترنت؟

لا تُستخدم. ما يعمل على الإنترنت الحقيقي هو مجموعة بروتوكولات TCP/IP (أربع طبقات فعلياً). بروتوكولات OSI ذات الطبقات السبع نفسها خسرت سباق الانتشار في تسعينيات القرن الماضي وانتهت شبه غير مستخدَمة. RFC 1122 الذي وضع أسس الإنترنت يشرح العالم بأربع طبقات: طبقة الارتباط، وطبقة IP، وطبقة النقل، وطبقة التطبيق. ما بقي هو النموذج كمفردات مشتركة لعزل الأعطال والحوار، مثل «نعزل عند L2» أو «هذه مشكلة L7».

أين يوجد فعلياً طبقة الجلسة (L5) وطبقة العرض (L6)؟

لا توجدان كطبقتين مستقلتين في مكدس TCP/IP الحقيقي. الأدوار التي تصوّرها نموذج OSI تبعثرت وامْتُصت في مواضع أخرى: L5 (إنشاء الحوار وإدارته) يقابله مصافحة TLS أو ملفات تعريف الارتباط والرموز في HTTP، وL6 (تحويل تمثيل البيانات والتشفير) يقابله تشفير TLS وترميز الأحرف وصيغ التسلسل مثل JSON. لا قيمة عملية لتحديد طبقة واحدة ينتمي إليها TLS. الأهم أن تستطيع شرح أنه فوق L4 وتحت L7، ويجمع أدواراً تعادل L5 وL6.

إذا وُجد عنوان IP، فلماذا يلزم عنوان MAC أيضاً؟

لأن توزيع الأدوار بين الطبقات مختلف. عنوان IP (L3) عنوان يشير إلى الوجهة النهائية، ولا يتغيّر من أول الاتصال إلى آخره. عنوان MAC (L2) اسم يشير إلى «من سيحمل القطعة التالية من المسار»، ويُستبدل كلما عُبر موجّه. الإطار المرسل من جهاز في المكتب إلى خادم ويب يكون عنوان MAC الوجهة فيه هو عنوان البوابة الافتراضية (الموجّه) لا عنوان خادم الويب. ما يبحث عن عنوان MAC لعقدة مجاورة انطلاقاً من عنوان IP هو ARP، ويمكن الاطلاع على جدول التطابق بأمر arp -a.

ما الفائدة العملية الحقيقية لنموذج OSI المرجعي؟

عزل الأعطال والحوار بين الفرق. بلاغاً مثل «لا أستطيع الاتصال بالخادم» يمكن تضييقه منهجياً بالتحقق من بقاء كل طبقة حيّة من الأسفل: الفحص البصري لمصباح الارتباط (L1 إلى L2)، وping إلى البوابة (L3)، وتأكيد اتصال TCP بمنفذ الوجهة (L4)، وإرسال طلب HTTP (L7). مثلاً إذا نجح ping وفشل اتصال TCP، تضيق الشبهة إلى شيء يسد المنفذ عند L4، كخدمة متوقفة أو جدار حماية. كذلك يعمل النموذج كإحداثيات مشتركة في الصناعة للتعبير باختصار عن نقطة المسؤولية، كما في «يبدو أنها مشكلة L2، هل تنظر إلى المبدّل؟».

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

يركّز على تطوير برامج ويندوز، والاستشارات التقنية، والتحقيق في الأخطاء، ويتميّز في المشاريع التي تبقى فيها الأصول القديمة ناشطة، وفي تشخيص الأعطال التي يصعب تحديد سببها.