مقدمة
جميعنا على دراية بمبدأ تصنيف بروتوكول الإنترنت (IP) ومبدأ عدم تصنيفه، وتطبيقاته في الاتصالات الشبكية. يُعدّ تجزئة وإعادة تجميع حزم IP آليةً أساسيةً في عملية نقل البيانات. فعندما يتجاوز حجم الحزمة الحد الأقصى لوحدة الإرسال (MTU) لوصلة الشبكة، يقوم بروتوكول IP بتقسيمها إلى أجزاء أصغر متعددة لنقلها. تُنقل هذه الأجزاء بشكل مستقل في الشبكة، وعند وصولها إلى الوجهة، يُعاد تجميعها في حزم كاملة بواسطة آلية إعادة تجميع IP. تضمن عملية التجزئة وإعادة التجميع هذه إمكانية نقل الحزم كبيرة الحجم في الشبكة مع الحفاظ على سلامة البيانات وموثوقيتها. في هذا القسم، سنتناول بمزيد من التفصيل كيفية عمل تجزئة وإعادة تجميع حزم IP.
تجزئة وإعادة تجميع الملكية الفكرية
تختلف وحدات الإرسال القصوى (MTU) باختلاف روابط البيانات؛ فعلى سبيل المثال، تبلغ وحدة الإرسال القصوى لرابط بيانات FDDI 4352 بايت، بينما تبلغ لرابط بيانات Ethernet 1500 بايت. ووحدة الإرسال القصوى (MTU) هي أقصى حجم للحزمة التي يمكن إرسالها عبر الشبكة.
FDDI (واجهة البيانات الموزعة عبر الألياف) هو معيار لشبكات المنطقة المحلية (LAN) عالية السرعة، يستخدم الألياف الضوئية كوسيط نقل. وحدة الإرسال القصوى (MTU) هي أقصى حجم حزمة بيانات يمكن نقله بواسطة بروتوكول طبقة ربط البيانات. في شبكات FDDI، يبلغ حجم MTU 4352 بايت. هذا يعني أن أقصى حجم حزمة بيانات يمكن نقله بواسطة بروتوكول طبقة ربط البيانات في شبكة FDDI هو 4352 بايت. إذا تجاوز حجم الحزمة المراد نقلها هذا الحد، فيجب تجزئتها إلى أجزاء متعددة تتناسب مع حجم MTU، ثم إعادة تجميعها عند جهاز الاستقبال.
في شبكة الإيثرنت، يبلغ حجم وحدة الإرسال القصوى (MTU) عادةً 1500 بايت. هذا يعني أن الإيثرنت قادر على إرسال حزم بيانات يصل حجمها إلى 1500 بايت. إذا تجاوز حجم الحزمة حد MTU، تُقسّم الحزمة إلى أجزاء أصغر للإرسال، ثم تُعاد تجميعها في الوجهة. لا يمكن إعادة تجميع حزمة بيانات IP المُجزأة إلا بواسطة المضيف الوجهة، ولن يقوم جهاز التوجيه (الراوتر) بعملية إعادة التجميع.
تحدثنا سابقًا عن قطاعات TCP، لكن MSS اختصار لـ Maximum Segment Size (حجم القطاع الأقصى)، وهو عنصر أساسي في بروتوكول TCP. يشير MSS إلى حجم أكبر قطاع بيانات مسموح بإرساله في اتصال TCP. وكما هو الحال مع MTU (وحدة النقل القصوى)، يُستخدم MSS لتقييد حجم الحزم، ولكن على مستوى طبقة النقل، أي طبقة بروتوكول TCP. ينقل بروتوكول TCP بيانات طبقة التطبيق بتقسيمها إلى قطاعات بيانات متعددة، ويُحدد حجم كل قطاع منها بواسطة MSS.
تختلف وحدة النقل القصوى (MTU) لكل وصلة بيانات لأن كل نوع من وصلات البيانات يُستخدم لأغراض مختلفة. وبناءً على الغرض من الاستخدام، يمكن استضافة وحدات نقل قصوى مختلفة.
لنفترض أن المرسل يرغب في إرسال حزمة بيانات كبيرة بحجم 4000 بايت عبر وصلة إيثرنت، لذا يجب تقسيم حزمة البيانات إلى ثلاث حزم أصغر. وذلك لأن حجم كل حزمة صغيرة لا يمكن أن يتجاوز حد وحدة الإرسال القصوى (MTU)، وهو 1500 بايت. بعد استلام الحزم الثلاث الصغيرة، يقوم المستقبل بإعادة تجميعها في حزمة البيانات الأصلية الكبيرة بحجم 4000 بايت بناءً على رقم التسلسل وموقع كل حزمة.
في الإرسال المجزأ، يؤدي فقدان جزء من البيانات إلى إبطال حزمة بيانات بروتوكول الإنترنت بأكملها. ولتجنب ذلك، قدم بروتوكول التحكم بالنقل (TCP) تقنية MSS، حيث تتم التجزئة على مستوى طبقة TCP بدلاً من طبقة IP. وتكمن ميزة هذا النهج في أن TCP يتمتع بتحكم أدق في حجم كل جزء، مما يجنب المشاكل المرتبطة بالتجزئة على مستوى طبقة IP.
في بروتوكول UDP، نحرص على عدم إرسال حزم بيانات تتجاوز حجم وحدة الإرسال القصوى (MTU). ذلك لأن UDP بروتوكول نقل غير موجه للاتصال، ولا يوفر آليات موثوقية أو إعادة إرسال مثل TCP. إذا أرسلنا حزمة بيانات UDP أكبر من MTU، فستقوم طبقة IP بتجزئتها قبل الإرسال. عند فقدان أحد الأجزاء، يتعذر على بروتوكول UDP إعادة الإرسال، مما يؤدي إلى فقدان البيانات. لذا، لضمان نقل بيانات موثوق، يجب التحكم في حجم حزم بيانات UDP ضمن نطاق MTU وتجنب تجزئة الإرسال.
وسيط حزم الشبكة Mylinking™يمكن تحديد أنواع مختلفة من بروتوكولات الأنفاق VxLAN/NVGRE/IPoverIP/MPLS/GRE، وما إلى ذلك، تلقائيًا، ويمكن تحديدها وفقًا لملف تعريف المستخدم وفقًا لتدفق النفق الناتج عن الخصائص الداخلية أو الخارجية.
○ يمكنه التعرف على حزم بيانات VLAN وQinQ وMPLS
○ يمكنه تحديد الشبكة المحلية الظاهرية الداخلية والخارجية
○ يمكن تحديد حزم IPv4/IPv6
○ يمكنه تحديد حزم أنفاق VxLAN وNVGRE وGRE وIPoverIP وGENEVE وMPLS
○ يمكن تحديد حزم IP المجزأة (يدعم تحديد تجزئة IP وإعادة تجميع تجزئة IP لتطبيق تصفية ميزات الطبقة الرابعة على جميع حزم IP المجزأة. تطبيق سياسة إخراج حركة المرور.)
لماذا يتم تجزئة بروتوكول الإنترنت (IP) وبروتوكول التحكم بالنقل (TCP)؟
بما أن طبقة بروتوكول الإنترنت (IP) تقوم بتجزئة حزم البيانات تلقائيًا أثناء نقلها عبر الشبكة، فحتى لو لم تقم طبقة بروتوكول التحكم بالنقل (TCP) بتجزئة البيانات، فإن طبقة بروتوكول الإنترنت ستجزئ حزمة البيانات تلقائيًا وتُرسل بشكل طبيعي. فلماذا يحتاج بروتوكول التحكم بالنقل (TCP) إلى التجزئة؟ أليس هذا مبالغة؟
لنفترض وجود حزمة بيانات كبيرة لم تُقسّم في طبقة TCP وفُقدت أثناء النقل؛ سيعيد TCP إرسالها، ولكن كحزمة كاملة فقط (مع أن طبقة IP تُقسّم البيانات إلى حزم أصغر، لكل منها طول MTU). والسبب في ذلك هو أن طبقة IP لا تُعنى بموثوقية نقل البيانات.
بمعنى آخر، عند نقل البيانات من جهاز إلى رابط الشبكة، إذا قامت طبقة النقل بتجزئة البيانات، فإن طبقة بروتوكول الإنترنت (IP) لا تقوم بذلك. أما إذا لم تتم التجزئة في طبقة النقل، فمن الممكن أن تتم التجزئة في طبقة بروتوكول الإنترنت (IP).
ببساطة، يقوم بروتوكول TCP بتقسيم البيانات بحيث لا تبقى طبقة IP مجزأة، وعند إعادة الإرسال، لا يُعاد إرسال سوى أجزاء صغيرة من البيانات التي كانت مجزأة. وبهذه الطريقة، يمكن تحسين كفاءة وموثوقية الإرسال.
إذا كان بروتوكول TCP مجزأً، فهل طبقة IP غير مجزأة؟
في المناقشة السابقة، ذكرنا أنه بعد تجزئة حزمة TCP عند المرسل، لا تحدث تجزئة على مستوى طبقة IP. مع ذلك، قد توجد أجهزة أخرى على مستوى طبقة الشبكة ضمن وصلة النقل، قد يكون الحد الأقصى لوحدة الإرسال (MTU) فيها أصغر من الحد الأقصى لوحدة الإرسال عند المرسل. لذا، على الرغم من تجزئة الحزمة عند المرسل، فإنها تُجزأ مرة أخرى أثناء مرورها عبر طبقة IP لهذه الأجهزة. وفي النهاية، تُجمع جميع الأجزاء عند المُستقبِل.
إذا تمكّنا من تحديد الحد الأدنى لوحدة النقل القصوى (MTU) عبر الرابط بأكمله وإرسال البيانات بهذا الطول، فلن يحدث أي تجزئة بغض النظر عن العقدة التي تُرسل إليها البيانات. يُطلق على الحد الأدنى لوحدة النقل القصوى عبر الرابط بأكمله اسم وحدة النقل القصوى للمسار (PMTU). عند وصول حزمة IP إلى جهاز التوجيه، إذا كانت وحدة النقل القصوى لجهاز التوجيه أقل من طول الحزمة، وكان مُعلّم DF (عدم التجزئة) مُعيّنًا على 1، فلن يتمكن جهاز التوجيه من تجزئة الحزمة، بل سيُسقطها فقط. في هذه الحالة، يُنشئ جهاز التوجيه رسالة خطأ ICMP (بروتوكول رسائل التحكم في الإنترنت) بعنوان "التجزئة مطلوبة ولكن تم تعيين DF". تُرسل رسالة خطأ ICMP هذه إلى عنوان المصدر مع قيمة وحدة النقل القصوى لجهاز التوجيه. عندما يستلم المُرسِل رسالة خطأ ICMP، يُمكنه تعديل حجم الحزمة بناءً على قيمة وحدة النقل القصوى لتجنب حدوث التجزئة المحظورة مرة أخرى.
يُعدّ تجزئة بروتوكول الإنترنت ضرورةً يجب تجنّبها على مستوى طبقة بروتوكول الإنترنت، لا سيما على الأجهزة الوسيطة في الرابط. لذا، في بروتوكول الإنترنت الإصدار السادس (IPv6)، مُنعت تجزئة حزم بروتوكول الإنترنت بواسطة الأجهزة الوسيطة، ولا يُسمح بالتجزئة إلا عند بداية ونهاية الرابط.
فهم أساسي لبروتوكول IPv6
بروتوكول الإنترنت الإصدار السادس (IPv6) هو الإصدار السادس من بروتوكول الإنترنت، وهو خليفة بروتوكول الإنترنت الإصدار الرابع (IPv4). يستخدم IPv6 عناوين بطول 128 بت، مما يوفر عددًا أكبر من عناوين IP مقارنةً بعناوين IPv4 التي يبلغ طولها 32 بت. ويعود ذلك إلى أن مساحة عناوين IPv4 تتناقص تدريجيًا، بينما مساحة عناوين IPv6 كبيرة جدًا وتلبي احتياجات الإنترنت المستقبلية.
عند الحديث عن IPv6، فإنه بالإضافة إلى مساحة عناوين أكبر، فإنه يوفر أيضًا أمانًا وقابلية توسع أفضل، مما يعني أن IPv6 يمكن أن يوفر تجربة شبكة أفضل مقارنة بـ IPv4.
على الرغم من أن بروتوكول IPv6 موجود منذ فترة طويلة، إلا أن انتشاره العالمي لا يزال بطيئًا نسبيًا. ويعود ذلك أساسًا إلى ضرورة توافق IPv6 مع شبكة IPv4 الحالية، الأمر الذي يتطلب عملية انتقال وترقية. ومع ذلك، ومع نفاد عناوين IPv4 وتزايد الطلب على IPv6، يتجه المزيد من مزودي خدمات الإنترنت والمؤسسات تدريجيًا إلى تبني IPv6، وتحقيق التشغيل المزدوج لبروتوكولي IPv6 وIPv4.
ملخص
في هذا الفصل، تعمّقنا في فهم آلية تجزئة وإعادة تجميع حزم بروتوكول الإنترنت (IP). تختلف وحدات الإرسال القصوى (MTU) باختلاف روابط البيانات. عندما يتجاوز حجم الحزمة حدّ MTU، تقوم تجزئة IP بتقسيمها إلى أجزاء أصغر متعددة للإرسال، ثم تُعاد تجميعها في حزمة كاملة بواسطة آلية إعادة تجميع IP بعد وصولها إلى الوجهة. يهدف تجزئة TCP إلى منع تجزئة طبقة IP، وإعادة إرسال البيانات الصغيرة المجزأة فقط عند حدوث إعادة الإرسال، وذلك لتحسين كفاءة وموثوقية الإرسال. مع ذلك، قد توجد أجهزة أخرى على مستوى طبقة الشبكة في رابط النقل، ذات وحدات MTU أصغر من وحدة المرسل، ما يؤدي إلى تجزئة الحزمة مرة أخرى على مستوى IP في هذه الأجهزة. لذا، ينبغي تجنب التجزئة على مستوى IP قدر الإمكان، خاصةً على الأجهزة الوسيطة في الرابط.
تاريخ النشر: 7 أغسطس 2025
