تقطيع (شبكات): الفرق بين النسختين

تصفح التاريخ تفاعلياً

[نسخة منشورة]

→ التعديل السابق

تم حذف المحتوى تمت إضافة المحتوى

مرئينص الويكي

مضمن

النسخة الحالية 14:56، 14 أبريل 2024

في بعض من طبقات نموذج الربط البيني للأنظمة المفتوحة لشبكات البيانات، التقطيع^[1] (بالإنجليزية: Fragmentation)‏ أو (بالإنجليزية: Segmentation)‏^[2] هو تقسيم الحمولة في وحدة بيانات بروتوكول إلى قسمين أو أكثر بأطوال أصغر من طول الحمولة الأصلية. يحصل التقطيع عندما يتجاوز طول حمولة وحدة بيانات البروتوكول عتبة مُحددة يحددها بروتوكول الطبقة.

التقطيع هو وظيفة أساسية لبروتوكولات طبقة الشبكة،^[3]^[4] ولكنه قد يحصل في طبقة النقل أو في طبقة ربط البيانات أو في الطبقة المادية.^[5] يهدف التقطيع بشكل الأساسي إلى توليد وحدات بيانات بروتوكول بأطوال أقل، لكنّه قد يُستخدم كجزء من آلية التقطيع والتوزيع في طبقة الربط (LFI)،^[6] أو لتحسين الوصول إلى الوسط المادي في الطبقة المادية.^[7]

نظرة عامة

بحسب نموذج الاتصال المعياري، تتكون وحدة بيانات البروتوكول في كل طبقة من حمولة وترويسة،^[8] والتقطيع هو تقسيم الحمولة في بعض طبقات النموذج، إلى قطعتين أو أكثر بحيث تُشكّل كل قطعة حمولة لوحدة بيانات بروتوكول أصغر من وحدة البيانات الأصلية التي تمّ تقطيعُها.^[9] يحصل التقطيع في الطبقات الرابعة والثالثة والثانية والأولى من النموذج، وتحدد البروتوكولات التي تعمل في هذه الطبقات قيمًا مُميزة لكل طبقة، تُستخدم كعتبة لتحديد متى يحصل التقطيع، فإذا كان طول وحدة بيانات البروتوكول أكبر من قيمة العتبة كان التقطيع إلزاميًّا.^[10]

إذا كان بروتوكول النقل المستعمل يدعم التقطيع، فإنّ التقطيع في طبقة النقل لا يحصل إلا في المُضيف المصدر فقط، وهو يهدف إلى إنشاء وحدات بيانات بروتوكول ذات طول أقصر من طول الوحدة الأصلية. لإنجاز التقطيع في هذه الطبقة، يتمّ اعتبار كل ما ورد من الطبقة الأعلى حمولة، ويجري تقسيمها إلى قطع، ثُم تُغلّف القطع بترويسة البروتوكول لتُنتج وحدات بيانات بروتوكول طبقة النقل.^[5] يدعم بروتوكول التحكم بالنقل عملية التقطيع، وتسمى وحدة بيانات البروتوكول الناتجة عن تغليف أقسام الحمولة السابقة بترويسات البروتوكول قطعة (بالإنجليزية: Segment)‏، أمّا بروتوكول حزم بيانات المستخدم فهو لا يدعم التقطيع، ويُغلّف الحمولة بإضافة ترويسته لها كما وردت، دون تقطيعها، وتسمى وحدة بيانات البروتوكول الناتجة حزمة البيانات (بالإنجليزية: Datagram)‏. وفي الحالتين يتم تمرير وحدات بيانات البروتوكول الناتجة إلى طبقة الشبكة.^[11]

التقطيع هو وظيفة أساسية لبروتوكولات الشبكة، وهو يحصل بعد اتخاذ قرار التوجيه لوحدة بيانات البروتوكول، والتي تُسمى رزمة بيانات في هذه الطبقة، وقد يكون في المُضيف المصدر الذي ولد الرزمة أو في أحد المُوجّهات على المسار، أو في كليهما. تتحدد عملية تقطيع رزمة البيانات بمقارنة طول الرزمة مع وحدة التقل العظمى لطبقة الشبكة، يحصل التقطيع إذا كان طول الرزمة أكبر من قيمة وحدة النقل العظمى، وهو يهدف إلى إنشاء رزم بيانات ذات طول أصغر من الرزمة الأصلية. يُمكن أن يحصل التقطيع أكثر من مرة على طول المسار لحين وصول الرزمة إلى وجهتها، ويُسمّى حينها بالتقطيع المُتعدد. لا يتمّ تجميع قطع الرزمة إلا في المُضيف الوجهة، والسبب في ذلك أن القطع قد لا تسلك نفس المسار، وبالتالي لن تمر عبر نفس المُوجّهات في طريقها للمضيف الوجهة.^[12] تمرر طبقة الشبكة رزم البيانات إلى طبقة ربط البيانات.

يُمكن أن يحصل التقطيع في طبقة ربط البيانات، إما لإنتاج أطر بيانات ذات طول أصغر، أو كجزء من آلية التقطيع والتوزيع في طبقة الربط (بالإنجليزية: Link Fragmentation and Interleaving اختصاراً LFI)‏. يحصل التقطيع إذا كانت طول وحدة بيانات البروتوكول في طبقة ربط البيانات، ويسمى إطار البيانات، أكبر من قيمة وحدة النقل العظمى للطبقة. بعض بروتوكولات الربط لا يقوم بالتقطيع في هذه الطبقة، مثل الإيثرنت، ولكنه يحدد قيمة لوحدة النقل العظمى، ويجب على بروتوكول الشبكة أن يلتزم بها. تفرض بعض بروتوكولات الربط قيمة أعظمية محدودة بشكلٍ مُفرط لوحدة النقل العظمى، مثل بروتوكول الشبكات الشخصية اللاسلكية منخفضة المُعدّل ^{[الإنجليزية]} الذي يُحدد طول إطار البيانات الأعظمي ليكون 127 بايت فقط.^[13] وقد يحصل التقطيع في الطبقة المادية، ولا يكون الهدف منه تقسيم وحدة بيانات البروتوكول إلى قطع أصغر، بل تحسين الوصول إلى وسط الاتصال المادي.^[14]

برتبط التقطيع بعملية التغليف بشكلٍ وثيق، ويُسبب التقطيع زيادة في الطول الإجمالي للبيانات،^[15] والسبب في هذه الزيادة هو الترويسات المُضافة للقطع أثناء تغليفها،^[16] فإذا كانت وحدة بيانات البروتوكول الأصليّة ذات طول ما مثلًا ( ${{\text{X}}_{}}$ ) بايت، ناتج عن حمولة بطول ( ${{\text{Y}}_{}}$ ) بايت وترويسة بطول ( ${{\text{Z}}_{}}$ ) بايت حيث ( ${{\text{X=Y+Z}}_{}}$ )، فإنّ تقطيع قسم الحمولة إلى ثلاث قطع أطوالها ( ${{\text{Y1,Y2,Y3}}_{}}$ ) بايت بالترتيب، وإضافة ترويسة الطبقة بطول ( ${{\text{Z}}_{}}$ ) بايت لكل قطعة، سيسبب زيادة في الطول الإجمالي للبيانات، لتبيان هذه الزيادة، يُمكن التعبير عن وحدات بيانات البروتوكول الناتجة عن التقطيع بالثلاثيات ( ${{\text{X1,Y1,Z}}_{}}$ ) و ( ${{\text{X2,Y2,Z}}_{}}$ ) و ( ${{\text{X3,Y3,Z}}_{}}$ ) على الترتيب. ويكون مجموع أطوال الحمولة في القطع مُساويًا لطول الحمولة في القطعة الأصلية، أي:

{{\text{Y=Y1+Y2+Y3}}_{}}

أمّا الطول الإجمالي، أي مجموع أطوال كل الترويسات والحمولات، فهو يزداد بمقدار ترويستين أي ( ${{\text{2Z}}_{}}$ ) بايت في هذه الحالة،^[15] ويُمكن التعبير عن هذه الزيادة بشكلٍ عام بالطريقة التالية:

{{\text{X+(n-1)Z=X1+X2+..+Xn}}_{}}

حيث (

{{\text{n}}_{}}

) هي عدد القطع الناتجة عن عملية التقطيع.

بالنسبة للبروتوكول الذي يقوم بالتقطيع كإحدى وظائف الطبقة، هناك نمطين للتقطيع، بحسب توافر إمكانية تجميع الرزمة الأصلية، الأول هو التقطيع المرئي أو الملحوظ بالنسبة للبروتوكول (بالإنجليزية: Transparent Fragmentation)‏، وفيه يدرك البروتوكول عملية حصول التقطيع في أي نقطة في الشبكة، ونتيجة لذلك، يكون بإمكانه إعادة تجميع القطع ثم بناء حمولة الوحدة الأصلية، والثاني هو التقطيع غير المرئي أو غير الملحوظ بالنسبة للبروتوكول (بالإنجليزية: Non-Transparent Fragmentation)‏ وفيه لا يمكن للبروتوكول أن يعيد تجميع القطع إلا في وجهتها النهائية.^[17]

عند استخدام بروتوكول التحكم بالنقل كبروتوكول نقل في الشبكة، فإن فقدان قطعة واحدة من مجموعة القطع التي نتجت عن تقطيع رزمة البيانات الأصليّة سيسبب إعادة إرسال كل القطع مرة أخرى، والسبب في ذلك أن المُضيف الوجهة لا يكون قادرًا على تجميع الرزمة ما لم تصل كُل قطعها، وبالتالي لن يقوم بإرسال إشعار لتأكيد الاستلام. نتيجة لذلك، في مصدر الرزمة الأصليّة، سيسبب غياب إشعار الاستلام إعادة إرسال نسخة من الرزمة الأصلية كاملة، وستمر النسخة بنفس المراحل التي مرت فيها الرزمة الأصلية، أي سيتم تقطيعها وإرسال كل القطع عبر الشبكة مرة أخرى، على الرغم من أن ما فقد هو قطعة واحدة فقط وليس كامل الرزمة.^[18]

في بعض الحالات، قد يسبب استقبال حركة بيانات مكونة من عدد كبير من القطع من رزم بيانات مختلفة لا يمكن تجميعها امتلاء الذاكرة المخصصة لحفظ القطع، وقد يكون ذلك وسيلة لبدء هجوم ينتمي لعائلة من الهجمات التي تعتمد على حصول التقطيع في الشبكة، وقد تهدف إلى محاولة تجاوز نظام كشف التسلل مثلًا.^[19] فالتقطيع في طبقة الشبكة يسبب ثغرة أمنية، لأن ترويسة بروتوكول طبقة النقل التي تحتوي أرقام المنافذ لن تُوجد إلا في القطعة الأولى فقط،^[20] ويمكن أن يعتمد المهاجمون على غياب ترويسة بروتوكول النقل في باقي القطع لإطلاق هجوم يُعرف باسم بهجوم القطعة الصغيرة (بالإنجليزية: Tiny Segment Attack)‏ ^[21] أو قد يكون الهجوم شكلًا من أشكال هجوم حجب الخدمة، من خلال محاولة ملء الذاكرة المخصصة لعملية التجميع أو استهلاك حدة المعالجة المركزية بشكلٍ مُفرط.^[22]

يسبب الاعتماد على التقطيع العديد من المشاكل في الشبكة،^[23] فمثلًا يجب تجميع كل أجزاء الرزمة الأصلية قبل التمكن من استعادتها، ويسبب هذا إرهاقًا لموارد المُضيف الوجهة، بالإضافة لمشكلة القطعة الأخيرة التي قد تكون ذات حجم صغير، ويسبب إرسالها عبر الشبكة استهلاكًا غير مرغوب لمورد الشبكة.^[24] وأخيرًا، في حال تقطيع رزم أو أطر البيانات فإنّ معلومات تخص بروتوكول الطبقات العليا، مثل أرقام المنافذ في طبقة النقل مثلًا لن تتواجد إلا في قطعة واحدة فقط، ما يعني أن جداران الحماية لا تستطيع أن تفحص هذه الرزم، ما يخلق بدوره ثغرة أمنية.^[18]

آلية العمل

مفهوم الإزاحة

إزاحة القطعة (بالإنجليزية: Fragment Offset)‏ هي قيمة تنتج أثناء عملية تقطيع حمولة وحدة بيانات بروتوكول، تحدد هذه القيمة الموقع النسبي لقطعة محددة بالنسبة لبقية القطع ضمن الحمولة الأصلية.^[25] إنّ قيمة الإزاحة ضرورية لإنجاز عملية إعادة التجميع وبدونها لا يمكن إعادة تجميع القطع بالترتيب الصحيح لإعادة إنتاج وحدة بيانات البروتوكول الأصلية التي تمّ تقطيعها.

تكون إزاحة القطعة الأولى مساوية للصفر دومًا.^[26] في حال حصول تقطيع متعدد، فإن قيمة الإزاحة تشير دائمًا إلى موقع القطعة الجديدة بالنسبة إلى الرزمة الأصلية في مرحلة التقطيع الأولى.

إعادة التجميع

إعادة التجميع (بالإنجليزية: Reassembly)‏ أو (بالإنجليزية: Defragmentation)‏ هي آلية لإعادة إنشاء وحدة بيانات البروتوكول الأصلية انطلاقًا من القطع، وتتطلب عملية إعادة التجميع استقبال جميع القطع أولًا، والتي قد تصل بترتيب مختلف لترتيبها ضمن الوحدة الأصلية، ثُمّ يجب تحديد موقع القطع النسبي ضمن وحدة بيانات البروتوكول الأصلية، وأخيرًا، يتم استخلاص حمولة القطع والتخلص من الترويسات، ثم يجري رصف القطع مع بعضها البعض بالترتيب الصحيح لإعادة إنشاء وحدة بيانات البروتوكول الأصلية.^[9]

تحصل عملية إعادة تجميع الأطر محليًّا في الوجهة التالية مباشرة في مسار حركة البيانات، ولا تغادر قطع الإطار الشبكة المحلية، أمّا رزم البيانات فيجري تجميعها في الوجهة النهائية لحركة البيانات، لأن رزم بيانات مختلفة ناتجة عن تقطيع رزمة بيانات واحدة قد تسلك مسارات مختلفة لتصل إلى وجهتها، واختلاف المسارات يعني عدم إمكانية التجميع إلا في الوجهة النهائية،^[27] على الرغم من إمكانيّة التقطيع المتعدد في أي نقطة على مسار الرزم.

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

وصفت خوارزميات إعادة تجميع رزم بيانات الإصدار الرابع من بروتوكول الإنترنت في وثيقة طلب التعليقات RFC 815.^[29]

التقطيع المتعدد

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

في كل مرة يتم فيها التقطيع يجب تحديد إزاحة القطع الجديدة، أي موقعها، بالنسبة لرزمة البيانات الأصلية في المصدر، وليس بالنسبة لرزمة البيانات التي جرى تقطيعها في هذه المرحلة،^[31] ونتيجة لذلك، وبما أن إعادة تجميع الرزم لا تحصل إلا في الوجهة النهائيّة، فإن تلك الوجهة قد تستقبل قطعًا مُختلفة الطول. فإنّ سلكت الرزم مسارًا مُختلفًا بين المصدر والوجهة، فقد يتمّ تقطيعها بشكلٍ مُتعدد بحسب مسارها، وبالتالي فإن عدد القطع الناتجة يتعلق بالمسار المسلوك، أمّا قيمة إزاحة القطع لإعادة بناء الرزمة الأصلية فيجب أن تدل على موقع القطعة في الرزمة الأصلية بغض النظر عن المسار التي سلكته.

لتجنب التقطيع المتعدد، هناك ميزة إضافية للإصدار الرابع من بروتوكول الإنترنت هي ميزة اكتشاف وحدة النقل العظمى للمسار، وهي تعتمد على بروتوكول رسائل التحكم في الإنترنت، وموصوفة في وثيقة طلب التعليقات RFC 1191.^[32] أمّا في العُقد التي تُشغّل الإصدار السادس من بروتوكول الإنترنت، فإنّها غالبًا ما تدعم هذه التقنية بشكلٍ افتراضي، وقد أُشير إليها في معيار البروتوكول الأصلي، ووصفت بشكل مفصل في وثيقة طلب التعليقات RFC 8201.^[33]

اكتشاف وحدة النقل العظمى للمسار

اكتشاف وحدة النقل العظمى للمسار (بالإنجليزية: Path Maximum Transmission Unit Discovery اختصاراً PMTUD)‏ هي آليّة تستخدم في المُضيف المصدر، لتحديد أدنى قيمة لوحدة النقل العظمى على طول مسار ما، وبالتالي توليد رزم بيانات بأطوال متوافقة معها، بحيث لا يعود هناك حاجة لتقطيع الرزم أثناء حركتها على المسار من المصدر إلى الوجهة.^[34] قد لا يتمكن المصدر من تحديد حجم النقل الأعظمي الأدنى بدقة، ولكن استعمال هذه الآليّة يساعده على توليد رزم بيانات ذات أطوال أقل أو تساوي أدنى قيمة لحجم النقل الأعظمي على طول المسار.^[23]

إذا استُخدم الإصدار الرابع من بروتوكول الإنترنت كبروتوكول شبكة، فإنّ آليّة الاكتشاف الخاصّة به هي توسيعة إضافية تعتمد على بروتوكول رسائل التحكم في الإنترنت،⁽¹⁾ وعلى علم عدم التقطيع في ترويسة البروتوكول.^[35] تعتمد الآليّة على قيام المصدر بتوليد رزم بيانات بأطوال متغيرة مع رفع علم عدم التقطيع فيها، فإنّ لم يكن بالإمكان نقل الرزمة عبر شبكة ما بسبب حجمها يجري التخلص منها، ثُمّ إعلام المصدر بذلك عن طريق رسالة مُناسبة من رسائل بروتوكول التحكم في شبكة الإنترنت.^[32]

إذا استخدم الإصدار السادس من بروتوكول الإنترنت كبروتوكول شبكة، فإنّ آليّة الاكتشاف الخاصة به هي جزء مُدمج منه، ولابد من استعمالها قبل إرسال أي رزمة حتى لو كان المضيف المصدر يعتقد أن الوجهة موجودة في نفس الشبكة المحلية. تعتمد هذه الآلية على بروتوكول رسائل التحكم للإصدار السادس من بروتوكول الإنترنت،⁽²⁾ وبالتحديد رسالة «رزمة كبيرة جدًّا» والتي تُرسلها عقدة ما على المسار، وتكون وجهة الرسالة هي مصدر رزمة بيانات لم تتمكن العقدة من إرسالها نحو الخطوة التالية على المسار، وذلك بسبب طولها، يجب على المصدر عندها أن يُعيد ضبط أطوال الرزم التي يُرسلها اعتمادًا على هذه ما جاء في هذه الرسالة.^[33]

التقطيع في طبقة النقل

إنّ التقطيع ليس وظيفة إلزامية لبروتوكولات طبقة النقل، ولكن يساعد إنجاز عملية تقطيع مناسبة في هذه الطبقة في المضيف المصدر على تجنب أي عمليات تقطيع لاحقة سواءً في الطبقات الدنيا من نموذج الشبكة المستعمل في المضيف المصدر، أو في عقد الشبكات على طول المسار، ويؤثر ذلك بشكل مباشر على الأداء.^[36] يدعم بروتوكول التحكم بالنقل آلية لتقطيع حمولة وحدة البيانات، وتسمى الوحدات الجديدة الناتجة عن التقطيع والتغليف قطعًا (بالإنجليزية: Segment)‏،^[37] في حين لا يقوم بروتوكول حزم بيانات المستخدم بعملية التقطيع، وعند استخدامه يجب أن تقوم التطبيقات بتوليد البيانات بشكل متقطع بطريقة يمكن من خلالها لطبقة الشبكة أن تقوم بتوليد رزم البيانات بناء على هذه القطع.^[38]

التقطيع في بروتوكول التحكم بالنقل

في بروتوكول التحكم بالنقل هناك مفهوم خاص مُرتبط بالتقطيع هو مقاس القطعة الأعظمي (بالإنجليزية: Maximum Segment Size اختصاراً MSS)‏ وهو يحدد الحمولة أو حجم البيانات التي يمكن لمُضيف ما أن يستقبله ضمن قطعة واحدة، يجب الانتباه إلى أن ترويسة بروتوكول التحكم بالنقل غير مُشمولة ضمن مقاس القطعة الأعظمي، على عكس ووحدة النقل العظمى الخاصة بطبقة الشبكة، التي تشمل ترويسة بروتوكول الشبكة بالإضافة للحمولة في وحدة بيانات بروتوكول تلك الطبقة.^[39]^[40]

إنّ اختيار مقاس القطعة الأعظمي الخاص ببروتوكول التحكم بالنقل يُؤثّر بشكل مباشر على عملية تقطيع رزم البيانات في طبقة الشبكة، فإذا كانت القيمة كبيرة جدًّا، كان التقطيع في طبقة الشبكة إلزاميًّا، أمّا إذا كانت صغيرة جدًّا، فلا يحصل تقطيع أبدًا، ولكن الكلفة غير المباشرة لذلك ستكون باهظة ومُؤثّرة على فعاليّة الإرسال، بسبب وجود حمل إضافي كبير هو مجموع أطوال الترويسات المُضافة إلى الرزم الصغيرة.^[21] يتم التحكّم بمقاس القطعة الأعظمي في بروتوكول التحكم بالنقل بشكل آليّ لتكون مُتوافقة مع قيمة النافذة المنزلقة الخاصة بالاتصال الذي قام البروتوكول بإنشائه.^[41]

إنّ القيمة الافتراضية لمقاس القطعة الأعظمي هي (536) بايت،^[42] وهي تضبط بشكل مستقل لكل طرف، ويمكن التفاوض على قيمتها في الاتجاهين بين الطرفين عند إنشاء الاتصال، ولكن لا يمكن تغييرها بعد ذلك.^[43]

التقطيع في طبقة الشبكة

قيم وحدة النقل العظمى لبروتوكولات التشبيك.⁽³⁾
اسم البروتوكول	اختصار	حجم وحدة النقل العظمى الأعظمي (بايت)	حجم وحدة النقل العظمى الأدنى (بايت)	المرجع
الإصدار الرابع من بروتوكول الإنترنت	IPv4	65536	68	^[44]
الإصدار السادس من بروتوكول الإنترنت	IPv6	65576 ^[a]	1280	^[45]

مُلاحظات

^ لم يرد ذكر الرقم بشكل صريح في معيار البروتوكول، ولكن يُمكن حسابه من مجموع الطول الأعظمي المسموح للحمولة وهو (65536) بايت، مع طول الترويسة (40) بايت.

إنّ تقطيع رزم البيانات وإعادة تجميعها هو وظيفة رئيسية لبروتوكولات الشبكة.^[3]^[4] يدعم الإصداران الرابع^[44] والسادس^[45] من بروتوكول الإنترنت تقطيع حمولة رزم البيانات التي يتجاوز طولها قيمة محددة، إلى قطع تُستعمل لإنشاء رزم بيانات ذات أطوال أصغر من الرزمة الأصلية. تمرر الرزم المُقطعة إلى طبقة ربط البيانات ليصار إلى تغليفها وإنشاء أطر البيانات.

التقطيع في الإصدار الرابع من بروتوكول الإنترنت

يكون تقطيع رزمة بيانات الإصدار الرابع من بروتوكول الإنترنت (بالإنجليزية: IP Fragmentation)‏ ضروريًّا عندما يتم توليدها في شبكة محلية أُولى تسمح بحجم كبير لوحدة النقل العظمى الخاصة بطقبة الشبكة، لكنّ مسار الرزمة يقطع شبكة ثانية يكون حجم وحدة النقل العظمى فيها أصغر بالقيمة، وعندها لابد من تقطيع الرزمة في عقدة ما على المسار من أجل أن تصل إلى وجهتها. نتيجة لذلك، يتم توليد رزم بيانات بأطوال أصغر من طول الرزمة الأصلية.^[46]

يمكن أن تحصل عملية تقطيع الرزم في المُضيف المصدر الذي يُولّدها، أو في أي عقدة على مسارها نحو وجهتها، ويدعم البروتوكول أيضًا مفهوم التقطيع المتعدد، أي يمكن أن يتم تقطيع رزمة البيانات أكثر من مرة عبر مسارها، ولكن لا يمكن إعادة تجميع الرزمة الأصلية إلا في الوجهة النهائية.^[27]

ترويسة البروتوكول

تتكون ترويسة الإصدار الرابع من بروتوكول الإنترنت من 14 حقلًا،^[44] لا ترتبط جميعها بعملية التقطيع. الحقول المُرتبطة بعملية التقطيع هي حقل مُعرّف القطعة، وحقل الأعلام وحقل الإزاحة، كما تتأثر قيمة حقلي الطول الإجمالي والتحقق الجمعي بعملية التقطيع وتختلف قيمتها في القطع عن قيمتها في الرزمة الأصلية،^[47] بعض الخيارات تُنسخ لكل قطعة، وبعضها لا يُنسخ إلا للقطعة الأولى، ويتحدد ذلك بعلم خاص هو علم النسخ (بالإنجليزية: Copied flag)‏ الذي يوجد في بداية كل خيار.^[48]

يمكن للمضيف المصدر أن يُؤشّر الرزم التي لا يريدها أن تُقطّع برفع علم عدم التقطيع، في هذه الحالة لا يتم تقطيع الرزمة أبدًا، وفي حال تعذّر إيصال الرزمة بدون تقطيعها، فسيتم التخلص منها.^[26] إذا تمّ تقطيع رزمة البيانات في المصدر أو في أي عقدة على المسار فلابد من إعادة تجميع القطع الناتجة في المُضيف الوجهة، ولا يتمّ تجميع قطع الرزمة في أي عقدة على المسار. يُستخدم حقل المُعرّف لتمييز رزمة البيانات الأصلية وجميع القطع الناتجة عن عملية التقطيع، ويقوم المُضيف الوجهة باستعمال هذا الحقل للتمييز بين مجموعات القطع الناتجة عن تقطيع رزم بيانات مختلفة بغرض إعادة تجميعها.^[49]

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

حقول ترويسة البروتوكول المُستخدمة في عملية التقطيع:^[44]

حقل مُعرّف القطعة، طوله 16 بت ويحتوي على قيمة فريدة تُعرف رزمة البيانات الأصلية وجميع القطع الناتجة عن تقطيعها، وهو يستخدم في عملية إعادة التجميع لتمييز قطع الرزم الأصلية عن قطع بقية الرزمة.^[49]
حقل الأعلام، طوله 3 بت مقسم بالشكل التالي:
- البت 0، محجوز، لا يُستخدم، قيمته دائمًا هي 0.
- البت 1، علم عدم التقطيع (بالإنجليزية: Do not Fragment Flag اختصاراً DF)‏، يستخدم من قبل مصدر الرزمة للإشارة إلى ضرورة عدم تقطيع الرزمة،^[50] تقوم الموجهات على كامل مسار الرزمة بالالتزام بذلك، وإذا كانت قيمة هذا البت مساوية للواحد، فلن يتم تقطيع الرزمة أبدًا حتى لو أدى ذلك إلى التخلص منها لعدم إمكانية توجيهها.^[26]
- البت 2، علم المزيد من القطع (بالإنجليزية: More Fragment Flag اختصاراً MF)‏ يستخدم لتمييز القطعة الأخيرة، إذا كانت قيمته 1 فهذا يعني أن هناك قطع أخرى نتجت بعد هذه القطعة من عملية تقطيع الرزمة الأصلية، أما إذا كانت قيمته 0، فهذا يعني أن هذه القطعة هي آخر قطعة نتجت عن عملية تقطيع الرزمة.
حقل إزاحة القطعة، طوله 13 بت، ويحتوي على قيمة تدل على موقع القطعة النسبي بالنسبة لبقية القطع في الرزمة الأصلية، تكون قيمة الإزاحة مقسومة على ثمانية، أي إذا احتوى الحقل القيمة 1 فإن قيمة الإزاحة الحقيقية هي 8 بايت، وإذا احتوى 2 فإن قيمة الإزاحة الحقيقية هي 16، وأكبر قيمة ممكن للإزاحة في هذا الحقل هي: 2¹³=8192، وتقابل 65536 بايت.^[51]

يجب عدم الخلط بين حقلي المُعرّف وإزاحة القطعة في ترويسة بروتوكول الإنترنت، فحقل المُعرّف هو قيمة مميزة تُعرّف بشكلٍ فريد رزمة البيانات الأصلية وكل القطع الناتجة عن عملية التقطيع سواء تم كمرحلة واحدة أو كان متعددًا، أما حقل الإزاحة فهو يمثل الموقع النسبي للقطعة الناتجة بالنسبة لبقية القطع ضكن رزمة البيانات الأصلية.^[52]

خوارزمية التقطيع

وصفت خوارزمية التقطيع في محددات البروتوكول، وهي تتبع المراحل التالية:^[44]

تحديد طول الرزمة ومقارنته مع وحدة النقل العظمى الخاصّة بالشبكة التي سيتم توجيه الرزمة إليها:
1. إذا كان طول الرزمة أكبر من وحدة النقل العظمى، يجب أن يتم تقطيع الرزمة.
2. إذا كان طول الرزمة أصغر أو يساوي وحدة النقل العظمى يتم إرسال الرزمة كما هي إلى المرحلة التالية من التغليف.
إذا كان علم عدم التقطيع في الرزمة مرفوعًا، يتمّ التخلّص من الرزمة.
يجري تحديد حجم حمولة القطعة بحسب وحدة النقل العظمى وطول ترويسة بروتوكول الإنترنت.
يتم اقتطاع حمولة القطعة من حمولة الرزمة الأصلية.
يتم بناء ترويسة القطعة، ويشمل ذلك:
1. حساب طول ترويسة القطعة وإضافته إلى الحقل المخصص.
2. حساب طول القطعة الإجمالي وإضافته إلى الحقل المخصص.
3. تحديد زمن حياة القطعة.
4. ضبط قيمة مُعرّف القطعة إلى قيمة مُعرّف الرزمة الأصلية.
5. تحديد قيمة الإزاحة، وإضافتها إلى الحقل المخصص.
6. تحديد قيمة العلمين. وإضافتهما إلى الحقل المخصص.
7. حساب قيمة حقل التحقق الجمعي.
توليد الرزمة الجديدة من خلال تغليف قطعة البيانات بالترويسة.
تحديد فيما إذا كانت الرزمة الناتجة هي الرزمة الأخيرة بقراءة قيمة علم المزيد من القطع:
1. إذا كانت الرزمة الناتجة هي الرزمة الأخيرة، يتم إرسالها إلى المرحلة التالية من التغليف.
2. إذا لم تكن الرزمة الناتجة هي الرزمة الأخيرة، يتم إعادة تنفيذ الخوارزمية بدءًا من الخطوة الثالثة، مع اعتبار أن حجم حمولة الرزمة الأصلية هو الحجم المتبقي من عملية الاقتطاع السابقة.

أما عملية إعادة التجميع، فهي تجري بشكل معاكس، وهناك عدة خوارزميات لإنجازها، جرى مناقشتها في وثيقة طلب التعليقات RFC 815.^[53]

قضايا أمنية

طوّر المهاجمون عدد من الهجمات التي تعتمد على التقطيع أو ثغرة أمنية قد تنتج عن استخدامه، من هذه الهجمات:

هجوم القطعة الصغيرة (بالإنجليزية: Tiny Fragment Attack)‏^[54] يعتمد هذا الهجوم على حقيقة أن أصغر رزمة بيانات يمكن لأي وحدة تدعم الإصدار الرابع من بروتوكول الإنترنت التعامل معها هي بطول 68 بايت، حيث تكون ترويسة بروتوكول الإنترنت بأقصى طول أعظمي مسموح لها، وهو 60 بايت، في حين تكون الحمولة بطول 8 بايت فقط،^[44] لا يكفي هذا الطول لإدراج ترويسة بروتوكول النقل ضمن الرزمة، وقد يحاول المُهاجم تمرير قطعة خبيثة من جدار الحماية، الذي يتفحص عادة أرقام المنافذ في طبقة النقل، على أساس أنها قطعة صغيرة من رزمة بيانات أكبر جرى تقطيعها.
هجوم القطع المتراكبة (بالإنجليزية: Overlapping Fragment Attack)‏^[55] يعتمد هذا الهجوم على خوارزمية إعادة التجميع المُتبعة لإعادة تشكيل الرزمة الأصلية، حيث يمكن لأي قطعة تالية أن تتراكب مع قطعة أخرى سابقة، وتحل محلها جزئيًّا أو كليًّا، ويعني ذلك وجود ثغرة أمنية، حيث بالإمكان تمرير القطعة الأولى، التي تحتوي ترويسة بروتوكول الإنترنت من جدار الحماية بشكل شرعي، ثُمّ التلاعب بقيمتها عن طريقة التراكب مع قطعة تالية.^[56] على الرغم من التحسينات التي طرأت على خوارزمية إعادة التجميع، إلا أن الوثائق المعيارية للخوارزمية لم تتناول هذا الهجوم.^[57]

نُوقشت هذه الهجمات وطريقة التصدي لكل منها بالتفصيل في وثيقة طلب التعليقات RFC 1858.^[21]

أمثلة

في هذا المثال، يُفترض أن طول ترويسة الإصدار الرابع من بروتوكول الإنترنت هي 20 بايت، أي لا يوجد أي خيارات إضافية. إنّ قيمة وحدة النقل العظمى الخاصة بطبقة الشبكة هو 1500 بايت، ويجري التقطيع على مرحلة واحدة فقط لرزمة بيانات طولها الإجمالي هو 5140 بايت، أي أنها مكونة من حمولة هي 5120 وترويسة هي 20 بايت وقيمة المُعرّف في ترويسة بروتوكول الإنترنت فيها هو 345.^[16]

إنّ حجم الحمولة الأكثر مُلائمة لحجم وحدة النقل العظمى هو 1480 بايت، وهو يسمح بتشكيل رزمة بيانات ذات طول مُطابق تمامًا لحجم وحدة النقل العظمى من خلال تغليف الحمولة 1480 بترويسة البروتوكول 20، ليكون طول الرزمة الأولى الإجمالي هو 1500 بايت، وإزاحتها هي 0 لأنّها تحتوي على القطعة الأولى،^[26] ويجب أن يضبط علم المزيد من القطع إلى القيمة 1 لأن عملية التقطيع مستمرة، وقيمة المعرف إلى القيمة 345، وهي معرف الرزمة الأصلية نفسه، وعلم عدم التقطيع إلى القيمة 0 لأن المطلوب هو أن يكون التقطيع على مرحلة واحدة فقط. إنّ حجم الحمولة المُتبقية بعد اقتطاع القطعة الأولى هو (3640=1480-5120) بايت.

بشكلٍ مُشابه لإنتاج الرزمة الأولى، يتم اقتطاع 1480 بايت من الحمولة المُتبقية، ويتمّ تغليفها بترويسة البروتوكول المناسبة التي تكون قيم حقولها الخاصة بالتقطيع مُشابهة لحقول ترويسة الرزمة الأولى باستثناء قيمة حقل الإزاحة الذي يتمّ ضبطه إلى القيمة (185=1480/8). وتكون الحمولة المُتبقية بعد إنشاء القطعة اقتطاع الثانية هي (2160=1480-3640). ثُمّ، وبشكلٍ مُشابه يتم اقتطاع القطعة الثالثة، ويجري تغليفها بترويسة البروتوكول المُناسبة التي تكون قيم حقولها الخاصّة بالتقطيع مُشابهة لحقول ترويسة الرزمة الأولى باستثناء قيمة حقل الإزاحة الذي يتم ضبطه إلى القيمة (370=8/(1480+1480)) وتكون الحمولة المتبقية بعد إنشاء القطعة اقتطاع الثالثة هي (680=1480-2160) بايت.

تُشكّل الحمولة المُتبقية القطعة الأخيرة، وتُغلّف بترويسة بروتوكول الإنترنت ليصبح الطول الإجمالي للرزمة الناتجة 700 بايت، ويجب أن يتم ضبط علم المزيد من القطع إلى القيمة 0 لأنّها القطعة الأخيرة، وحقل الإزاحة إلى القيمة (555=8/(1480+1480+1480))، بينما تكون قيم بقية الحقول الخاصة بالتقطيع في الترويسة مُطابقة للقيم في ترويسات الرزم السابقة.

جدول بقيم حقول الترويسات في الرزمة الأصلية قبل التقطيع وفي الرزم الناتجة عن التقطيع.
بعض حقول ترويسة الرزمة الأصلية قبل التقطيع
-	حقل مُعرف القطعة	حقل الطول الإجمالي (بايت)	علم عدم التقطيع	علم المزيد من القطع	حقل الإزاحة
-	345	5140	0	0	0
بعض حقول ترويسات الرزم الناتجة عن التقطيع
رقم القطعة	حقل مُعرف القطعة	حقل الطول الإجمالي (بايت)	علم عدم التقطيع	علم المزيد من القطع	حقل الإزاحة
1	345	1500	1	1	0
2	345	1500	1	1	185
3	345	1500	1	1	370
4	345	700	1	0	555

إنّ مجموع أطوال الرزم الناتجة عن عملية التقطيع هو 5200 بايت، وهو أكبر من طول الرزمة الأصلية بمقدار 60 بايتًا أو 1.15%، وهي حمولة إضافية تنتج عن إضافة الترويسات للقطع الناجمة عن عملية التقطيع.

التقطيع في الإصدار السادس من بروتوكول الإنترنت

إن تقطيع رزم البيانات التي يتجاوز طولها قيمة محددة بوحدة النقل العظمى لطبقة الشبكة هي وظيفة أساسيّة للإصدار السادس من بروتوكول الإنترنت.^[45] بشكلٍ مشابه للإصدار الرابع من بروتوكول الإنترنت، يقوم الإصدار السادس بتقطيع حمولة رزمة بيانات لإنقاص طولها، وينتج عن ذلك مجموعة من القطع التي تستعمل لتنتج رزم بيانات جديدة، أطوالها أقل أو تساوي قيمة وحدة النقل الأعظيمة. ولكن على عكس الإصدار الرابع من بروتوكول الإنترنت، في الإصدار السادس، لا يحدث التقطيع إلا في المُضيف المصدر فقط، ولا تقوم المُوجّهات بتقطيع رزمة بيانات الإصدار السادس تحت أي ظرف،^[58] لذلك فإن معرفة وحدة النقل العظمى للمسار هي عملية ذات أهمية خاصة في البروتوكول، وإذا لم يتمكن البروتوكول من تحديدها فإنّه يعتمد أدنى طول مسموح لرزمة البيانات وهو 1260 بايت.^[59]

ترويسة القطعة

ترويسة القطعة الخاصة بالإصدار السادس من بروتوكول الإنترنت.

بنية رزمة بيانات الإصدار السادس من بروتوكول الإنترنت الناتجة عن إعادة تجميع القطع في المضيف الوجهة.

لا تحتوي ترويسة البروتوكول الأساسية على حقول خاصة بعملية التقطيع، ولكن هناك ترويسة أخرى خاصة بالتقطيع تسمى ترويسة القطعة (بالإنجليزية: Fragment Header)‏ يقوم البروتوكول بإضافتها في حال تقطيع الرزمة، إذا أضيفت هذه الترويسة بعد الترويسة الأساسية، يحب أن تكون قيمة حقل «الترويسة التالية» في ترويسة البروتوكول الأصلية مضبوطة إلى القيمة 44.^[60]

يبلغ طول ترويسة القطعة 8 بايت، وتتألف من 6 حقول، هي بحسب ترتيب وردوها:^[45]

حقل الترويسة التالية 8 بت، ويضبط بشكل مشابه لحقل الترويسة التالية في ترويسة البروتوكول الأصلية.
حقل محجوز 8 بت، يضبط إلى القيمة 0 عند الإرسال.
حقل إزاحة القطعة 13 بت، يحتوي على موقع حمولة القطعة النسبي ضمن حمولة الرزمة الأصلية، وتعبر قيمة الرقم الموجود عن الإزاحة بواحدة هي 8 بايت، فإذا كانت قيمة هذا الحقل مثلًا هي 2، فإن إزاحة القطعة الحقيقية هي 16 بايت.
حقل محجوز 2 بت، يُضبط إلى القيمة 0 عند الإرسال.
علم المزيد من القطع 1 بت، ويستخدم للدلالة على القطعة الأخيرة، إذا كانت قيمته 1، فهذا يعني أن هناك قطع لاحقة نتجت عن عملية التقطيع، أما إذا كانت قيمته 0 فذلك يعني بأن هذه القطعة هي القطعة الأخيرة.
حقل مُعرّف القطعة 32 بت، وهي يحتوي قيمة فريدة تميّز الرزمة الأصلية وجميع القطع التي نتجت عن تقطيعها. هناك عدة خوارزميات لاختيار قيمة المعرّف بحيث يكون فريدًا وآمنًا، وهي موصوفة في وثيقة طلب التعليقات RFC 7739.^[61]

خوارزمية التقطيع

تتألف رزمة بيانات الإصدار السادس من بروتوكول الإنترنت من ترويسة البروتوكول الأساسية، ومجموعة من التوسيعات التي تشمل خيارات إضافية أو ترويسات مُحددة لابد من معالجتها في كل عقدة على المسار، بالإضافة إلى قسم الحمولة الذي يضمّ ترويسات الطبقات العليا، ويكون التقطيع إلزاميًا عندما يتجاوز طول الرزمة قيمة وحدة النقل العظمى، والتي غالبًا ما تكون وحدة النقل العظمى الدنيا للمسار الذي ستسلكه رزمة البيانات، بخلاف ذلك، تُضبط القيمة بشكلٍ آلي القيمة الدنيا المدعومة لوحدة النقل العظمى في أسوء الحالات وهي 1280 بايت.^[62] وُصفت خوارزمية التقطيع في وثيقة طلب التعليقات الخاصة بالبروتوكول.^[45]

تتم عملية التقطيع بتقسيم حمولة الرزمة الأصلية إلى عدد من القطع، بحيث لا يزيد طول الرزمة الناتجة عن إضافة ترويسة القطعة وترويسة البروتوكول والتوسيعات إلى أي من القطع عن وحدة النقل العظمى. تكون أطوال القطع الناتجة من مرتبة 8 بايت، أي أن أصغر حمولة قطعة يكون طولها 8 بايت، وثاني أصغر قطعة تكون بطول 16 بايت وهكذا، وتلتزم كل القطع بذلك فيما عدا القطعة الأخيرة.

بشكلٍ عام تنتج عن عملية التقطيع ثلاث حالات مختلفة:^[63]

الرزمة الأولى: وتضم ترويسة البروتوكول والتوسيعات والترويسات الإضافية بالإضافة لترويسة القطعة، والقطعة الأولى من الحمولة، والتي تضم ترويسات الطبقات العليا،^[64] ويكون الطول الكليّ مُطابقًا أو قريبًا من طول وحدة النقل العظمى. يكون مُعرّف هذه الرزمة مُطابقًا لمعرف الرزمة الأصلية، ويُرفع فيها علم المزيد من القطع وتكون إزاحتها مساوية للصفر.^[26]
رزم وسطيّة: تظهر الرزم الوسطية إذا كان عدد القطع التانجة أكثر من اثنين، تضم الرزمة الوسطية ترويسة البروتوكول والتوسيعات وترويسة القطعة، وقطعة من الحمولة، ويكون الطول الكلي مُطابقًا أو قريبًا من طول وحدة النقل الأعظميّة. يكون مُعرّف هذه الرزمة مطابقًا لمعرف الرزمة الأصلية، ويُرفع فيها علم المزيد من القطع وتختلف قيمة الإزاحة فيها بحسب الموقع النسبي لقطعة الحمولة في الرزمة الأصلية.
الرزمة الأخيرة: وتضمّ ترويسة البروتوكول والتوسيعات وترويسة القطعة، وآحر قطعة من الحمولة، ويكون مُعرّف هذه الرزمة مُطابقًا لمعرف الرزمة الأصلية، ولا يُرفع فيها علم المزيد من القطع،^[65] وتضبط قيمة الإزاحة فيها بحسب الموقع النسبي لقطعة الحمولة في الرزمة الأصلية. وليس بالضرورة أن يكون طول الرزمة الأخيرة الكلي مُطابقًا أو قريبًا من طول وحدة النقل العظمى، وغالبًا ما تكون ذات حجم صغير غير مناسب.^[24]

قضايا أمنية

ينتج عن استخدام التقطيع في الإصدار السادس من بروتوكول الإنترنت عدد من الثغرات أمنيّة التي قد تستخدم لشن هجمات مثل هجوم القطعة الصغيرة أو هجوم القطع المتراكبة، وتختلف إمكانية شن الهجمات بحسب نظام التشغيل الذي يستعمل البروتوكول.^[66] بشكلٍ مُشابه للإصدار الرابع من بروتوكول الإنترنت، لم تمنع مُحددات الإصدار السادس إنشاء قطع متراكبة عند التقطيع، أي من الممكن أن يتكرار نفس المقطع من الحمولة في أكثر من قطعة، على أن يُعتمد المقطع الوارد في آخر قطعة تمّ استقبالها عند التجميع، يسبب ذلك ثغرة أمنية، ويسمح بتنفيذ هجوم القطع المتراكبة، لاحقًا تمّ التأكيد بوضوح على منع تراكب القطع عند التقطيع في وثيقة طلب التعليقات RFC 5722.^[67]

يقبل مُضيف الإصدار السادس من بروتوكول الإنترنت أن تحتوي رزمة البيانات على ترويسة القطعة بدون تكون القطعة ناتجة عن عملية تقطيع، وتسمى هذه القطع بالقطع الذرية (بالإنجليزية: Atomic Fragment)‏ وهي تنتج في حالات خاصة ناقشها المعيار الأصلي للبروتوكول،^[45] على الرغم من أن هذه القطع تكون وحداناً، أي لا يجب أن يتم تجميعها مع أي قطع أخرى، فإنّ المُضيف الوجهة يعاملها مُعاملة القطع التي تنتظر التجميع، ما يُسبب ثغرة أمنية، فقد يقوم المهاجم بإرسال قطعة خبيثة مع قيم مُناسبة في ترويسة القطعة، بحيث تكون قطعة ذرية تقبل التجميع مع قطع أخرى خبيثة تُرسل لاحقًا، ناقشت الوثيقة RFC 6946 كيفية معالجة القطع الذرية لتلافي هذا النوع من الهجمات.^[68]

التقطيع في طبقة ربط البيانات

قيم وحدة النقل العظمى لبعض بروتوكولات طبقة ربط البيانات.
اسم البروتوكول	اختصار	حجم وحدة النقل العظمى الأدنى (بايت)	حجم وحدة النقل العظمى الأقصى (بايت)	المرجع
الإيثرنت	IEEE 802.3	64	1518 ⁽⁵⁾	^[69]
بروتوكول حلقة الرمز	IEEE 802.5	لا يوجد حد أدنى	17794	^[70]^[71]
بروتوكول الشبكات المحلية اللاسلكية	IEEE 802.11	غير مُحدد	2304 ⁽⁶⁾	^[72]
بروتوكول الشبكات الشخصية اللاسلكية منخفضة المعدل	IEEE 802.15.4	غير مُحدد	127	^[13]

في طبقة ربط البيانات، التقطيع هو تقسيم حمولة إطار البيانات إلى قطعتين أو أكثر، لينتج بعد عملية التغليف إطاري بيانات أو أكثر ذوو أطوال أقصر من إطار البيانات الأصلي الذي تمّ تقطيعه. يُحدد كل بروتوكول ربط وحدة نقل أعظمية كعتبة لا يتجاوزها طول أطر البيانات التي يولّدها. التقطيع ليس وظيفة إلزامية لبروتوكولات الربط، وإذا لم يدعم بروتوكول الربط عملية التقطيع، فيجب على بروتوكول الشبكة أن يُولّد رزم بيانات تتناسب مع وحدة النقل لأعظمية لبروتوكول الربط المستعمل.

يُمكن أن يستخدم التقطيع في طبقة الربط في الحالات التي يكون فيها التطبيق حساسًا للتأخير الزمني، حيث يسبب طول إطار بيانات ما تأخيرًا غير مُستحب لأُطر بيانات أخرى، ويكون الحل بتقطيع الإطار الطويل إلى قطع أصغر وإرسالها عبر وسط الاتصال، وبذلك يقل زمن التأخير وتقلقل الإرسال، وتسمى هذه الآلية التقطيع والتوزيع في طبقة الربط (بالإنجليزية: Link Fragmentation and Interleaving اختصاراً LFI)‏.^[6]^[73]

تحدد الشركات المُصنعة لعتاد الشبكة قيم وحدة النقل العظمى الافتراضية والعُظمى الخاصة ببروتوكولات الربط العاملة على منافذ تجهيزاتها، وترتبط عملية التقطيع في طبقة ربط البيانات بهذه القيم بشكلٍ مباشر.^[74]^[75]

التقطيع في بروتوكول الشبكات المحلية اللاسلكية

يُعرف معيار بروتوكول الشبكات المحلية اللاسلكية (بالإنجليزية: IEEE 802.11)‏ عملية التقطيع بأنها تجزيء وحدات بيانات البروتوكول الخاصة بطبقة التحكم بالوصول للوسط إلى أجزاء أصغر، بهدف زيادة الوثوقية، من خلال زيادة احتمال نجاح عملية نقل الإطار عبر قنوات الاتصال التي تبدي خواصها وثوقية محدودة لاستقبال الأطر ذات الأطوال الكبيرة.⁽⁴⁾ تسمى العملية المعاكسة للتقطيع بإعادة التجميع (بالإنجليزية: Defragmentation)‏ ويجب أن تحصل في الوجهة التالية للقطع الناتجة، سواء كانت وجهة نهائية أو وسيطية على المسار.^[72]

يتم التحكم بعملية التقطيع بواسطة مُحدد خاص اسمه عتبة التقطيع (بالإنجليزية: dot11FragmentThreshold)‏، وتسمح تطبيقات البروتوكول لمشرفي الشبكة بضبط هذه القيمة، وأي إطار بيانات يتجاوز طوله قيمة العتبة يجب تقطيعه، ولكن لا يوجد خوارزمية محددة للتقطيع ويترك أمر تحديد الطريقة لمن يقوم بتنفيذ البروتوكول.^[76]

وجدت دراسة لاحقة بأن عملية التقطيع تحسّن من أداء بروتوكول الشبكات المحلية اللاسلكية عند في حال التداخل الراديوي، فعند إنقاص قيمة عتبة التقطيع يتناقص معدل خطأ البت المحلي الخاص بالمستقبل الراديوي لنقطة الوصول ويتناقص العدد الكلي لمحاولات إعادة الإرسال وتزداد إنتاجية المستقبل الراديوي. أمّا عند زيادة قيمة عتبة التقطيع فيتناقص التأخير الكلي للوصول إلى الوسط، وأيضًا تقلقل الإرسال الكلي.^[77]

التقطيع في شبكات تبديل الأطر

إن الهدف الأساسي من التقطيع في شبكة تبديل الأطر هو دعم حركة البيانات الحساسة للتأخير عند حركتها عبر الشبكة، بحيث يتم تقطيع أطر البيانات ذات الأطوال الكبيرة إلى قطع صغيرة بحيث لا يسبب إرسالها تأخيرًا كبيرًا لبقية الأطر. تسمح هذه التقنية للأطر الحساسة وغير للتأخير الزمني بتشارك نفس القناة الافتراضية عبر نفس المنفذ.^[78] وُصفت محددات التقطيع بمعيار خاص تحت الاسم الرمزي (FRF.12).^[79]

يستخدم التقطيع في شبكة تبديل الأطر كجزء من آلية التقطيع والتوزيع في طبقة الربط (LFI).^[6] لا يوجد طول مُحدد مُلزم لوحدة النقل الأعظمي، ولكن من الأفضل أن يكون الطول المُختار متناسبًا مع معدل الساعة للقناة الفيزيائية ومعدل التقل عبر القنوات الافتراضية.^[80] تُستخدم خوارزمية التقطيع الخاصّة ببروتوكول الربط بين نقطتين مُتعدد الوصلات.^[81]

أنماط التقطيع

يُعرّف معيار التقطيع في شبكات تبديل الأطر ثلاث أنماط من التقطيع:^[79]

التقطيع بين المُستخدم والشبكة (بالإنجليزية: UNI Fragmentation)‏: ويحصل بين جهاز اتصال بيانات (DCE) وجهاز بيانات طرفي (DTE) بهدف السماح لأطر البيانات الحساسة وغير الحساسة للتأخير بتشارك نفس المنفذ الذي يصل بين المستخدم والشبكة، والذي غالبًا ما يكون ذو معدل نقل منخفض. في هذا النمط، يتم تجميع الإطار مجددًا قبل دخوله شبكة تبديل الإطار، ويُرسل كاملًا عبرها.
التقطيع داخل الشبكة (بالإنجليزية: NNI Fragmentation)‏: ويكون هذا التقطيع غير مرئي بالنسبة للطرفيات حيث تحصل عمليتي التقطيع والتجميع داخل شبكة تبديل الأطر، وهو يهدف للسماح لأطر البيانات الحساسة وغير الحساسة للتأخير بتشارك نفس القناة الافتراضية. إن عمليتي التقطيع بين المستخدم والشبكة، والتقطيع داخل الشبكة متطابقتين من حيث الينية والخوارزمية المستعملة، وتُستخدمان في القنوات الافتراضية الدائمة SVC والمبدلة SVC.
التقطيع بين الطرفيات (بالإنجليزية: End-to-End Fragmentation)‏: ويحصل هذا التقطيع بين الطرفيات، وتحديدًا بين جهازي بيانات طرفيين، ويكون غير مرئي بالنسبة لشبكة تبديل الأطر، ولا يُستخدم إلا في القنوات الافتراضية الدائمة.

ترويسة القطعة

يجري تقطيع حمولة الإطار الأصلي إلى قطعتين أو أكثر، وتضاف ترويسة بروتوكول تبديل الأطر إلى كل القطع، وهي بطول 2 بايت، وأيضًا ترويسة التقطيع، وهي بطول 2 بايت أيضًا، وفي حالة التقطيع بين الطرفيات يضاف مُعرف بروتوكول طبقة الشبكة (بالإنجليزية: Network Layer Protocol ID اختصاراً NLPID)‏ وهو بطول 1 بايت، ويضبط إلى القيمة ₁₆(1B) في حالة التقطيع.^[82] أما ترتيب الإضافة عند التغليف فيكون بالشكل التالي:^[79]

في التقطيع بين المستخدم والشبكة، وفي التقطيع داخل الشبكة، تضاف ترويسة البروتوكول أولًا، ثم تضاف ترويسة التقطيع.
في التقطيع بين الطرفيات، تضاف ترويسة التقطيع أولًا، ثُمّ مُعرف بروتوكول طبقة الشبكة، ثم بايت محجوز يضبط إلى القيمة ₁₆(03)، وأخيرًا ترويسة بروتوكول تبديل الأطر.

يضاف مُلحق بطول 2 بايت لكل القطع، يحتوي على ناتج تطبيق خوارزمية خوارزمية تتابع فحص الإطار ^{[الإنجليزية]}.^[83]

يبلغ طول ترويسة القطعة 2 بايت، وهي تتكون من الحقول التالية بحسب ترتيب ورودها:^[79]

بت قطعة البداية (بالإنجليزية: Beginning fragment bit)‏: وهو علم يشير إلى القطعة الأولى الناتجة عن التقطيع، يتم ضبطه إلى القيمة 1 في القطعة الأولى وإلى 0 في باقي القطع.
بت قطعة النهاية (بالإنجليزية: Ending fragment bit)‏: وهو علم يشير إلى القطعة الأخيرة، يتم ضبطه إلى القيمة 1 في القطعة الأخيرة وإلى 0 في باقي القطع.
بت التحكم (بالإنجليزية: Control bit)‏: محجوز لاستخدامات مستقبلية، يُضبط دائمًا إلى القيمة 0.
الجزء العلوي من حقل التتابع: طوله 4 بت، ويضم الجزء العلوي من حقل التتابع، وتزداد قيمة حقل التتابع بمقدار 1 مع كل قطعة جديدة يتم توليدها، بمعزل عن انتهاء إطار ما والبدء بتقطيع إطار جديد، أي إذا كانت قيمة الحقل N في آخر قطعة نتجت عن تقطيع إطار ما، فإن قيمة التتابع في القطعة الأولى التي ستنتج عن الإطار التالي الذي يتم تقطيع ستكون N+1. تضبط قيمة حقل التتابع بشكل اختياري لكل قناة افتراضية إلى قيمة ما، ثم تزداد بعد ذلك بقيمة واحد مع كل قطعة جديدة يتم تغليفها، يساعد هذا الحقل في إنجاز عملية التجميع من خلال تحديد الرزم القطع التي تنتمي لنفس الإطار الأصلي، وتحديد إزاحتها عن بدايته.
بت محجوز: قيمته دومًا هي 1.
الجزء السفلي من حقل التتابع طوله 8 بت، ويضم الجزء السغلي من حقل التتابع.

التقطيع في بروتوكول الربط بين نقطتين متعدد الوصلات

يُعرّف مُحدد بروتوكول الربط بين نقطتين (PPP) البرتوكول بأنه بروتوكول ربط يصل بين نقطتين هما طرفا الاتصال، ويمكن أن يقوم بتغليف رزم بيانات لبروتوكولات شبكة مختلفة.^[84] لاحقًا أضيفت توسيعة لهذا البروتوكول تسمح بتجميع أكثر من خط نقل فيزيائي يمثل كل منها قناة اتصال مستقلة ضمن خط نقل افتراضي واحد يجمع هذه القنوات، وسميت هذه التوسيعة ببروتوكول النقل متعدد الوصلات بين نقطتين، ووصفت في وثيقة طلب التعليقات (RFC 1990).^[81] كما قد يُستخدم التقطيع كجزء من آلية التقطيع والتوزيع في طبقة الربط (LFI).^[85]

تُعرّف التوسيعة طبقة فرعية في نموذج الاتصال المعياري، تشغل الجزء العلوي من طبقة ربط البيانات، وتعمل فيها وحدة توسيعة البروتوكول، فترتبط مع وحدة بروتوكول طبقة الشبكة من جهة، ومع وحدتين أو أكثر من وحدات بروتوكول الربط بين نقطتين من جهة أخرى، التي تشغل طبقة فرعية أخرى تُشكل الجزء الأدنى من طبقة ربط البيانات.^[86]

من أجل توزيع الحمل بين خطوط التقل التي تشكل الوسط الفيزيائي، تقوم توسيعة البروتوكول بتقطيع رزمة البيانات الواردة من طبقة الشبكة إلى عدد من القطع، ثم تضيف ترويسة خاصة تُسمى ترويسة القطعة لكل قطعة ناتجة، وتمرر القطع وفق سياسة توزيع محددة إلى وحدات بروتوكول الربط بين نقطتين، التي تقوم كل منها بدورها بإضافة ترويسة وملحق خاصين ببروتوكول الربط بين نقطتين، ويجري تغليف القطعة بهما، ثم يُمرر الناتج إلى الطبقة المادية، وتعاد هذه المراحل بترتيب معكوس في المستقبل، من أجل إعادة توليد رزمة البيانات الأصلية.^[87]

تضاف ترويسة التوسيعة لكل قطعة ناتجة، ثم تُضاف ترويسة البروتوكول التقليدية والمُلحق بعملية التغليف. يكون طول ترويسة التوسيعة إمّا (2) أو (4) بايت، وفي كلا الحالتين تتألف الترويسة من 4 حقول هي:^[81]^[88]

بت قطعة البداية (Beginning fragment bit): وهو علم يشير إلى القطعة الأولى، يتم ضبطه إلى القيمة (1) في أول قطعة تنتج عن عملية التقطيع، و (0) في بقية القطع.
بت قطعة النهاية (Ending fragment bit): وهو علم يشير إلى القطعة الأخيرة، يتم ضبطه إلى القيمة (1) في آخر قطعة تنتج عن عملية التقطيع، و (0) في بقية القطع.
حقل رقم التتابع (Sequence number): ويدل على ترتيب القطعة بالنسبة لبقية القطع، يضبط في البداية إلى قيمة ابتدائية، ثُم تجري زيادتها بمقدار (1) في كل قطعة جديدة يتم تغليفها، قد يكون الحقل بطول (12) بت، ويُسمّى عندها التتابع القصير (بالإنجليزية: Short Sequence)‏ أو بطول (24) بت، ويُسمّى عندها التتابع الطويل (بالإنجليزية: Long Sequence)‏.^[89]
بتات محجوزة: تُوجد بين العلمين ورقم التتابع، تُضبط إلى القيمة (0)، وعددها (2) إذا استخدم التتابع القصير أو (6) إذا استخدم التتابع الطويل.

التقطيع في الطبقة المادية

التقطيع في بروتوكول الإيثرنت

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

يدعم بروتوكول الإيثرنت شكلًا خاصًّا من أشكال التقطيع في الطبقة المادية، وهو لا يهدف إلى إنقاص حجم وحدة بيانات البروتوكول، ولكنّ إلى إتاحة استخدام وسط الاتصال المادي الذي ينتج عن استخدام تقنية التجميع في الطبقة المادية (بالإنجليزية: Aggregation at physical layer اختصاراً APL)‏ بصورة مثاليّة، تسمح هذه التقنية بتجميع خطوط نقل ذات معدلات نقل مُعتدلة مثل 1 و2 و4 و10 جيجا بت في الثانية، لبلوغ معدلات نقل عالية مثل 40 أو 100 جيجا بت في الثانية. يحدد البروتوكول طولًا أصغريًّا للقطعة هو 64 بايت، وأعظميًّا هو 512 بايت، ولا يمكن تجاوز هذه العتبات عند اختيار طول القطعة.^[69]

يتم تقطيع إطار البيانات كاملًا في طرف الإرسال إلى عدد من القطع، ثُمّ يجري إضافة ترويسة بطول 32 بت وملحق بطول 16 بت لكل قطعة، ويلي ذلك توزيع القطع على خطوط النقل. تُرسل القطع الناتجة عبر خطوط النقل التي تشكل وسط الاتصال في نفس الوقت، ويجري تجميعها في طرف الإستقبال اعتمادًا على الترويسة المُضافة، والتي تحتوي على حقل بطول بت، يسمى رقم التتابع، وهي يساعد المستقبل على إيجاد الترتيب الصحيح للقطع لإعادة تجميعها وإنشاء إطار البيانات الأصلي مجددًا في الطرف الذي استقبلها.^[7]

انظر أيضًا

هوامش

1. الرسالة هي رسالة «لا يمكن بلوغ الوجهة» (بالإنجليزية: Destination unreachable Message)‏، لذلك يضبط حقل النوع في ترويسة البروتوكول إلى القيمة (3) وحقل الترميز إلى القيمة (4)، والتي تعني هناك حاجة للتقطيع ولكن علم عدم التقطيع مرفوع.^[90]

2. الرسالة هي رسالة «الرزمة كبيرة جدًّا» (بالإنجليزية: Packet Too big)‏ لذلك يضبط حقل النوع في ترويسة البروتوكول إلى القيمة (2) وحقل الترميز إلى القيمة (0).^[91]

3. يجب التمييز بين بروتوكول طبقة الشبكة وبروتوكول التشبيك،^[92] والذي يسمى أيضًا البروتوكول المُوجّه، فالأول تصنيف للبروتوكولات بحسب طبقة نموذج الاتصال المعياري، أما الثاني فهو تصنيف للبروتوكولات بحسب الوظيفة، وبروتوكولات الشبكة هي البروتوكولات التي تقوم بوظائف طبقة الشبكة. إن كل بروتوكول شبكة هو بروتوكول طبقة شبكة، مثل الإصدار الرابع لبروتوكول الإنترنت، ولكن العكس غير صحيح، فبروتوكول رسائل التحكم في الإنترنت هو بروتوكول طبقة شبكة، ولكنه ليس بروتوكول شبكة.

4. التعريف كما ورد في المعيار الأصلي هو: (بالإنجليزية: The process of partitioning an MSDU or an MMPDU into smaller MAC level" frames, MPDUs, is called fragmentation. Fragmentation creates MPDUs smaller than the original MSDU or MMPDU length to increase reliability, by increasing the probability of successful transmission of the MSDU or MMPDU when channel characteristics limit reception reliability for longer frames")‏.

5. هناك استثناءات كثيرة لهذا الرقم، أولها عملية الوسم الخاصة بالشبكات المحلية الافتراضية (VLAN) والموصوفة بالمعيار (IEEE 802.1q)، والتي تضيف (4) بايت للترويسة ليصبح الطول الإجمالي (1522) بايت،^[93] وثانيها الجسر المٌزوّد الموصوف بالمعيار (IEEE 802.1.ad)^[94] الذي يضيف (8) بايت بوسمة خاصة إلى الطول الأصلي فيصبح الطول الإجمالي (1526) بايت، وثالثها أطر الإيثرنت العملاقة (بالإنجليزية: Jumbo frame)‏ التي تُعرّف بأنها أي إطار إيثرنت يزيد طول حمولته عن (1500) بايت،^[95] وغيرها.

6. يسبب استخدام تقنيات أمنية مثل الخصوصية المكافئة للشبكات السلكية (WEP) أو أشكال مختلفة من الوصول الآمن للشبكة اللاسلكية (WPA) لتشفير إطار البيانات زيادة في الحجم الأعظمي قد تصل حتى (20) بايت، ليصبح حجم وحدة النقل الأعظمي الأقصى هو (2324) بايت.^[96]^[97]

مراجع

^ نزار الحافظ (2007)، مسرد مصطلحات المعلوماتية (بالعربية والإنجليزية)، الجمعية العلمية السورية للمعلوماتية، ص. 72، QID:Q108442159
^ "Differentiate between transparent and nontransparent fragmentation?". Blogspot (بالإنجليزية). 20 Sep 2013. Archived from the original on 2017-04-25. Retrieved 2018-07-14.
^ ^ا ^ب "Fragmentation at Network Layer". geeksforgeeks (بالإنجليزية). Archived from the original on 2017-06-26. Retrieved 2018-07-30. {{استشهاد ويب}}: |archive-date= / |archive-url= timestamp mismatch (help)
^ ^ا ^ب Charles M. Kozierok. (5 Sep 2005). "Network Layer (Layer 3)". The TCP/IP Guide (بالإنجليزية). Archived from the original on 2017-07-30. Retrieved 2018-07-22.
^ ^ا ^ب "How the TCP/IP Protocols Handle Data Communications". Oracle (بالإنجليزية). 6 Apr 2014. Archived from the original on 2018-07-03. Retrieved 2018-07-23.
^ ^ا ^ب ^ج "Configuring Link Fragmentation and Interleaving (LFI) With Campus ATM Switches". Cisco Systems, Inc. (بالإنجليزية). Archived from the original on 2017-05-13. Retrieved 2018-07-20.
^ ^ا ^ب Howard Frazier (23 Jan 2008). "Aggregation at the Physical Layer" (PDF). IEEE (بالإنجليزية). Archived from the original (PDF) on 2016-09-13. Retrieved 2018-07-24.
^ Charles M. Kozierok (5 Sep 2015). "Data Encapsulation, Protocol Data Units (PDUs) and Service Data Units (SDUs)". TCP/IP guide (بالإنجليزية). Archived from the original on 2017-07-30. Retrieved 2018-07-23. {{استشهاد ويب}}: |archive-date= / |archive-url= timestamp mismatch (help)
^ ^ا ^ب "Segmentation, Fragmentation and Reassembly". InetDaemon Enterprises (بالإنجليزية). 6 Apr 2014. Archived from the original on 2017-01-01. Retrieved 2018-07-23. {{استشهاد ويب}}: |archive-date= / |archive-url= timestamp mismatch (help)
^ "MTU Definition". Linux Information Project (بالإنجليزية). 9 أوكتوبر 2005. Archived from the original on 23 فبراير 2018. Retrieved 25 يوليو 2018. {{استشهاد ويب}}: تحقق من التاريخ في: |تاريخ= (help)
^ "Segmentation vs fragmentation". Cisco systems, Inc. (بالإنجليزية). 24 Mar 2008. Archived from the original on 2018-07-13. Retrieved 2018-07-23.
^ uzair syed naveed (25 أوكتوبر 2009). "IP reassembly at destination host". Cisco Systems, Inc. (بالإنجليزية). Archived from the original on 17 مايو 20172020-05-09. Retrieved 28 يونيو 2018. {{استشهاد ويب}}: تحقق من التاريخ في: |تاريخ= and |تاريخ أرشيف= (help)
^ ^ا ^ب "802.15.4-2015 - IEEE Standard for Low-Rate Wireless Networks". IEEE STANDARD. IEEE. أبريل 2016. DOI:10.1109/IEEESTD.2016.7460875. ISBN:978-1-5044-0845-5.
^ M. Frazier، Howard (مارس 2008). "Aggregation at the physical layer". IEEE Communications Magazine. IEEE. ج. 46 ع. 2: 512. DOI:10.1109/MCOM.2008.4476164. مؤرشف من الأصل في 2020-03-13.
^ ^ا ^ب ^ج Charles M. Kozierok (20 Sep 2005). "IP Message Fragmentation Process". The TCP/IP Guide (بالإنجليزية). Archived from the original on 2017-07-03. Retrieved 2018-07-13.
^ ^ا ^ب "Resolve IP Fragmentation, MTU, MSS, and PMTUD Issues with GRE and IPSEC". Cisco Systems, Inc. (بالإنجليزية). Archived from the original on 2018-05-21. Retrieved 2018-06-27.
^ Joel Haefner. "Internetworking Concepts". Illinois Wesleyan University (بالإنجليزية). Archived from the original on 2020-03-13. Retrieved 2018-07-15.
^ ^ا ^ب A. Kent، Christopher؛ C. Mogul، Jeffrey (يناير 1995). "Fragmentation considered harmful" (PDF). ACM SIGCOMM Computer Communication Review - Special twenty-fifth anniversary issue. Highlights from 25 years of the Computer Communication Review. ACM. ج. 17 ع. 5: 75-87. DOI:10.1145/205447.205456. مؤرشف من الأصل في 2020-03-25. اطلع عليه بتاريخ 2018-07-30.{{استشهاد بدورية محكمة}}: صيانة الاستشهاد: BOT: original URL status unknown (link)
^ "IP Fragmentation Buffer". Cisco Systems (بالإنجليزية). Archived from the original on 2018-06-27. Retrieved 2018-06-27.
^ "Packet Fragmentation". De Nayer Instituut (بالإنجليزية). Sep 2002. Archived from the original on 2018-07-11. Retrieved 2018-07-11.
^ ^ا ^ب ^ج Ziemba, G.; Reed, D.; Traina, P. (أوكتوبر 1995). "RFC 1858, Security Considerations for IP Fragment Filtering". The Internet Society (بالإنجليزية). Archived from the original on 2020-05-09. Retrieved 1 يوليو 2018. {{استشهاد ويب}}: تحقق من التاريخ في: |تاريخ= (help)
^ "Rose Frag Attack Explained". Digintal.net (بالإنجليزية). Archived from the original on 2017-08-28. Retrieved 2018-06-27.
^ ^ا ^ب Ivan Pepelnjak (2008). The Never Ending Story of IP Fragmentation (PDF) (بالإنجليزية). NIL Learning. Archived from the original on 2020-03-25. Retrieved 2018-07-30.{{استشهاد بكتاب}}: صيانة الاستشهاد: BOT: original URL status unknown (link)
^ ^ا ^ب Marek Majkowski (18 Aug 2017). "Broken packets: IP fragmentation is flawed". Cloudflare (بالإنجليزية). Archived from the original on 2018-06-30. Retrieved 2018-07-22.
^ "Glossary of Security Terms, F". SANS™ Institute (بالإنجليزية). Archived from the original on 2018-06-23. Retrieved 2018-06-29.
^ ^ا ^ب ^ج ^د ^ه Geoff Huston (29 Jan 2016). "Evaluating IPv4 and IPv6 Packet Fragmentation". Réseaux IP Européens Network Coordination Centre RIPE NCC (بالإنجليزية). Archived from the original on 2018-04-25. Retrieved 2018-07-22.
^ ^ا ^ب Charles M. Kozierok (20 Sep 2005). "IP Message Reassembly Process". The TCP/IP Guide (بالإنجليزية). Archived from the original on 2017-06-15. Retrieved 2018-07-11.
^ Mark Baggett (13 Jun 2012). "IP Fragment Reassembly with Scapy". SANS Institute (بالإنجليزية). Archived from the original on 2018-07-22. Retrieved 2018-07-22.
^ D. Clark, David (Jul 1982). "RFC 815, IP DATAGRAM REASSEMBLY ALGORITHMS". The Internet Society (بالإنجليزية). Archived from the original on 2016-03-09. Retrieved 2018-07-11.
^ Christoph Meinel; Harald Sack (2013). Internetworking: Technological Foundations and Applications (بالإنجليزية). Springer Science & Business Media. p. 469. ISBN:9783642353918.
^ Charles M. Kozierok (20 Sep 2005). "IP Message Fragmentation Process". The TCP/IP Guide (بالإنجليزية). Archived from the original on 2017-12-15. Retrieved 2018-07-13.
^ ^ا ^ب Mogul, J.; Deering, S. (Nov 1990). "RFC 1191, Path MTU Discovery". The Internet Society (بالإنجليزية). Archived from the original on 2019-06-20. Retrieved 2018-07-13.
^ ^ا ^ب McCann, J.; Deering, S.; Mogul, J.; Hinden, Ed., R. (Jul 2017). "RFC 8201, Path MTU Discovery for IP version 6". The Internet Society (بالإنجليزية). Archived from the original on 2019-03-21. Retrieved 2018-07-13.
^ "Resolve IP Fragmentation, MTU, MSS, and PMTUD issues with GRE and IPSEC" (PDF). Cisco Systems, Inc. (بالإنجليزية). Archived from the original (PDF) on 2014-08-02. Retrieved 2018-07-15.
^ West, M.; McCann, S. (Mar 2006). "RFC 4413, TCP/IP Field Behavior". The Internet Society (بالإنجليزية). p. 22. Archived from the original on 2012-08-11. Retrieved 2018-07-22.
^ Genkov، Delian؛ Ilarionov، Raycho (يناير 2006). "Avoiding IP Fragmentation at the Transport Layer of the OSI Reference Model". International Conference on Computer Systems and Technologies - CompSysTech’06. مؤرشف من الأصل في 2020-03-25.
^ Postal, J. (Sep 1981). "RFC 793, Transmission control protocol, DARPA internet program,protocol specification". The Internet Society (بالإنجليزية). Archived from the original on 2019-05-05. Retrieved 2017-07-22.
^ James Curtis (17 Jan 2000). "UDP vs TCP". Wand (بالإنجليزية). Archived from the original on 2017-05-06. Retrieved 2018-06-29.
^ Postel, J. (Nov 1983). "RFC 879, The TCP Maximum Segment Size and Related Topics". The Internet Society (بالإنجليزية). p. 2. Archived from the original on 2016-03-08. Retrieved 2018-07-28.
^ Nurul Islam Roman (15 Dec 2014). "TCP Maximum Segment Size (MSS) and Relationship to IP Datagram Size". APNIC (بالإنجليزية). Archived from the original on 2017-05-17. Retrieved 2018-06-28.
^ Charles M. Kozierok (20 Sep 2005). "TCP Maximum Segment Size (MSS) and Relationship to IP Datagram Size". TCP/IP Guide (بالإنجليزية). Archived from the original on 2017-01-11. Retrieved 2018-06-28.
^ Postel, J. (Nov 1983). "RFC 879, The TCP Maximum Segment Size and Related Topics". The Internet Society (بالإنجليزية). p. 1. Archived from the original on 2016-03-08. Retrieved 2018-07-28.
^ Postal, J. (Sep 1981). "RFC 793, Transmission control protocol, DARPA internet program,protocol specification". The Internet Society (بالإنجليزية). p. 19. Archived from the original on 2019-05-05. Retrieved 2018-06-28.
^ ^ا ^ب ^ج ^د ^ه ^و Postel, J. (Sep 1981). "RFC 791, Internet Protocol, DARPA Internet Program Protocol Specification". The Internet Society (بالإنجليزية). Archived from the original on 2019-09-18. Retrieved 2018-07-01.
^ ^ا ^ب ^ج ^د ^ه ^و Deering, S.; Hinden, R. (Jul 2017). "RFC 8200, Internet Protocol, Version 6 (IPv6) Specification". The Internet Society (بالإنجليزية). Archived from the original on 2019-06-26. Retrieved 2018-07-13.
^ Shivendra Panwar, Shivendra S. Panwar, Shiwen Mao, Jeong-dong Ryoo, Yihan Li (2014). TCP/IP Essentials: A Lab-Based Approach (بالإنجليزية). Cambridge University Press. p. 101. ISBN:0521841445.{{استشهاد بكتاب}}: صيانة الاستشهاد: أسماء متعددة: قائمة المؤلفين (link)
^ Joshua Johnson (17 May 2014). "Describe the IP Packet Header and each field in a Traffic Capture". Cisco Systems, Inc. (بالإنجليزية). Archived from the original on 2017-07-30. Retrieved 2018-07-30. {{استشهاد ويب}}: |archive-date= / |archive-url= timestamp mismatch (help)
^ "The IP Datagram". Rhys Haden (بالإنجليزية). Archived from the original on 2017-02-16. Retrieved 2018-07-30.
^ ^ا ^ب Touch, J. (Feb 2013). "RFC 6864, Updated Specification of the IPv4 ID Field". The Internet Society (بالإنجليزية). p. 22. ISSN:2070-1721. Archived from the original on 2020-05-09. Retrieved 2018-07-22.
^ Sean Wilkins (29 Feb 2012). "Anatomy of an IPv4 Packet". Pearson Education, Pearson IT Certification (بالإنجليزية). Archived from the original on 2017-03-27. Retrieved 2018-07-22.
^ Toni Janevski (2015). Internet Technologies for Fixed and Mobile Networks (بالإنجليزية) (الأولى ed.). Artech House. p. 33. ISBN:9781608079216.
^ "Identification vs Fragment Offset". Cisco Systems, Inc. (بالإنجليزية). 27 Jan 2018. Archived from the original on 2018-07-01. Retrieved 2018-07-01.
^ D. Clark, David (Jul 1982). "RFC 815, IP DATAGRAM REASSEMBLY ALGORITHMS". The Internet Society (بالإنجليزية). DOI:10.17487/RFC0815. Archived from the original on 2020-05-07. Retrieved 2019-06-09.
^ Miller, I. (Jun 2001). "RFC 3128, Protection Against a Variant of the Tiny Fragment Attack". The Internet Society (بالإنجليزية). p. 22. Archived from the original on 2012-08-11. Retrieved 2018-07-22.
^ "Explore new firmware that's helping organizations see attacks as they happen". Datacom (بالإنجليزية). 3 Nov 2015. Archived from the original on 2017-02-11. Retrieved 2018-07-22.
^ H. Ptacek، Thomas؛ N. Newsham، Timothy (يناير 1998). "Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection" (PDF). Computer Systems Management and Standards. DEFENSE TECHNICAL INFORMATION CENTER: 46-52. مؤرشف من الأصل (PDF) في 2017-08-12.
^ D. Clark, David (Jul 1982). "RFC 815, IP DATAGRAM REASSEMBLY ALGORITHMS". The Internet Society (بالإنجليزية). Archived from the original on 2019-03-28. Retrieved 2018-07-01.
^ Matt Conran (16 أوكتوبر 2018). "IPV6 FRAGMENTATION". Technology Focused Hub PS Delivery ltd (بالإنجليزية). Archived from the original on 2 يناير 2018. Retrieved 20 يوليو 2018. {{استشهاد ويب}}: تحقق من التاريخ في: |تاريخ= (help)
^ Phillip Remaker (21 Mar 2011). "IPv6 MTU Gotchas and other ICMP issues". Cisco Systems, Inc (بالإنجليزية). Archived from the original on 2016-09-19. Retrieved 2018-07-17.
^ "Protocol Numbers". IANA (بالإنجليزية). Archived from the original on 2018-01-04. Retrieved 2018-07-18.
^ Gont, F. (Feb 2016). "RFC 7739, Security Implications of Predictable Fragment Identification Values". The Internet Society (بالإنجليزية). ISSN:2070-1721. Archived from the original on 2020-05-09. Retrieved 2018-07-17.
^ Geoff Huston (19 May 2016). "Fragmenting IPv6". Réseaux IP Européens Network Coordination Centre RIPE NCC (بالإنجليزية). Archived from the original on 2017-05-05. Retrieved 2018-07-18.
^ Charles M. Kozierok (20 Sep 2005). "IPv6 Datagram Size, Maximum Transmission Unit (MTU), Fragmentation and Reassembly". The TCP/IP Guide (بالإنجليزية). Archived from the original on 2017-09-10. Retrieved 2018-07-18.
^ Bill Cerveny (25 Jul 2011). "IPv6 Fragmentation". ARBOR NETWORKS, INC. (بالإنجليزية). Archived from the original on 2018-06-26. Retrieved 2018-07-18.
^ Charles M. Kozierok. (5 Sep 2005). "IPV6 FRAGMENTATION". The TCP/IP Guide (بالإنجليزية). Archived from the original on 2017-07-11. Retrieved 2018-07-20. {{استشهاد ويب}}: |archive-date= / |archive-url= timestamp mismatch (help)
^ Atlasis، Antonios (2002). "Attacking IPv6 Implementation Using Fragmentation" (PDF). Black-Hat Europe. مؤرشف من الأصل (PDF) في 2020-03-25.
^ Krishnan, S. (Feb 2016). "RFC 5722, Handling of Overlapping IPv6 Fragments". The Internet Society (بالإنجليزية). Archived from the original on 2020-05-09. Retrieved 2018-07-21.
^ Gont, F. (May 2013). "RFC 6946, Processing of IPv6 "Atomic" Fragments". The Internet Society (بالإنجليزية). ISSN:2070-1721. Archived from the original on 2020-05-09. Retrieved 2018-07-21.
^ ^ا ^ب "802.3-2015 - IEEE Standard for Ethernet". IEEE Standard. IEEE: 2690-2699. مارس 2016. DOI:10.1109/IEEESTD.2016.7428776. ISBN:978-1-5044-0078-7. مؤرشف من الأصل في 2019-12-14.
^ Brent Baccala (Apr 1997). "IEEE 802.5 Details". Connected: An Internet Encyclopedia (بالإنجليزية). Archived from the original on 2016-06-05. Retrieved 2018-07-29.
^ "Token-Ring IEEE 802.5". IBM Corporation (بالإنجليزية). Archived from the original on 2018-07-29. Retrieved 2018-07-29.
^ ^ا ^ب "802.11-2016 - IEEE Standard for Information technology--Telecommunications and information exchange between systems Local and metropolitan area networks--Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications". IEEE. ديسمبر 2016: 1301. DOI:10.1109/IEEESTD.2016.7786995. ISBN:978-1-5044-3645-8. {{استشهاد بدورية محكمة}}: الاستشهاد بدورية محكمة يطلب |دورية محكمة= (مساعدة)
^ "Understanding Link Fragmentation and Interleaving Configuration". Juniper Networks, Inc (بالإنجليزية). Archived from the original on 2018-07-20. Retrieved 2018-07-20.
^ "Media MTU Sizes by Interface Type". Juniper Networks, Inc. (بالإنجليزية). Archived from the original on 2017-09-20. Retrieved 2018-07-29.
^ "MTU Behavior on Cisco IOS XR and Cisco IOS Routers". Cisco Systems, Inc. (بالإنجليزية). Archived from the original on 2017-06-30. Retrieved 2018-07-29.
^ Gast, Matthew (2002). 802.11 Wireless Networks: The Definitive Guide (بالإنجليزية) (الأولى ed.). O'Reilly Media. p. 46. ISBN:0596001835.
^ Diaconu، Felix (يوليو 2011). "IEEE 802.11 MAC frame fragmentation performances in jammed environments" (PDF). Bul. Inst. Politehnic, Iaşi, s. Electrot., Energ., Electron. ج. 58 ع. 2: 81-88. مؤرشف من الأصل (PDF) في 2015-11-22.
^ Jeff T. Buckwalter (1999). Frame Relay: Technology and Practice (بالإنجليزية) (الأولى ed.). Addison-Wesley Professional. p. 215. ISBN:0201485249.
^ ^ا ^ب ^ج ^د Andrew G. Malis (Dec 1997). "Frame Relay Fragmentation Implementation Agreement FRF.12" (PDF). Broadband Forum (بالإنجليزية). Archived from the original (PDF) on 2016-04-26. Retrieved 2018-07-28.
^ Andrew G. Malis. "Frame Relay, section: Frame Relay Fragmentation". Rhys Haden (بالإنجليزية). Archived from the original on 2017-06-12. Retrieved 2018-07-28.
^ ^ا ^ب ^ج Sklower, K.; Lloyd, B.; McGregor, G.; D. Carr, W.; Coradetti, T. (Aug 1996). "RFC 1990, The PPP Multilink Protocol (MP)". The Internet Society (بالإنجليزية). Archived from the original on 2020-05-09. Retrieved 2018-07-25.
^ Brown, C.; Malis, A. (Sep 1998). "RFC 2427, Multiprotocol Interconnect over Frame Relay". The Internet Society (بالإنجليزية). p. 27. Archived from the original on 2020-05-09. Retrieved 2018-07-29.
^ "Frame Relay Glossary" (PDF). Cisco systems, Inc (بالإنجليزية). p. 3. Archived from the original (PDF) on 2016-05-12. Retrieved 2018-07-29.
^ Simpson, W. (Jul 1994). "RFC 1661, The Point-to-Point Protocol (PPP)". The Internet Society (بالإنجليزية). Archived from the original on 2005-05-08. Retrieved 2018-07-25.
^ "Understanding Link Fragmentation and Interleaving Configuration". Juniper Networks, Inc. (بالإنجليزية). 24 Oct 2017. Archived from the original on 2018-07-20. Retrieved 2018-07-29.
^ Charles M. Kozierok (20 Sep 2005). "PPP Multilink Protocol (MP/MLP/MLPPP)". The TCP/IP Guide (بالإنجليزية). Archived from the original on 2017-01-23. Retrieved 2018-07-25.
^ Charles M. Kozierok (20 Sep 2005). "PPP Multilink Protocol (MP/MLP/MLPPP)". The TCP/IP Guide (بالإنجليزية). Archived from the original on 2017-12-22. Retrieved 2018-07-25.
^ "Configuring Link Fragmentation and Interleaving (LFI) With Campus ATM Switches". Cisco Systems, Inc. (بالإنجليزية). Archived from the original on 2017-05-13. Retrieved 2018-07-25.
^ Charles M. Kozierok (20 Sep 2005). "PPP Multilink Protocol (MP) Frame Format". The TCP/IP Guide (بالإنجليزية). Archived from the original on 2018-01-21. Retrieved 2018-07-29.
^ Postal, J. (Aug 1981). "RFC 792, Internet Control Message protocol, DARPA internet program,protocol specification". The Internet Society (بالإنجليزية). Archived from the original on 2019-04-20. Retrieved 2018-07-14.
^ Gupta, M. (Mar 2006). "RFC 4443, Internet Control Message Protocol (ICMPv6),for the Internet Protocol Version 6 (IPv6) Specification". The Internet Society (بالإنجليزية). Archived from the original on 2019-04-02. Retrieved 2018-07-15.
^ POSTEL، JONATHAN B. (أبريل 1980). "Internetwork Protocol Approaches". IEEE TRANSACTIONS ON COMMUNICATIONS. IEEE. ج. 28 ع. 4: 604 - 611. DOI:10.1109/TCOM.1980.1094705. ISSN:0090-6778. مؤرشف من الأصل في 2018-08-10.
^ "Inter-Switch Link and IEEE 802.1Q Frame Format". Cisco systems, Inc, (بالإنجليزية). Archived from the original on 2017-06-10. Retrieved 2018-07-29.{{استشهاد ويب}}: صيانة الاستشهاد: علامات ترقيم زائدة (link)
^ "802.1Q-2014 - IEEE Standard for Local and metropolitan area networks--Bridges and Bridged Networks". IEEE Standards. IEEE. ديسمبر 2014. DOI:10.1109/IEEESTD.2014.6991462. ISBN:978-0-7381-9433-2.
^ "Ethernet Jumbo Frames" (PDF). IEEE Communications Magazine. ethernet alliance. نوفمبر 2009. مؤرشف من الأصل في 2020-03-25. اطلع عليه بتاريخ 2018-07-30.{{استشهاد بدورية محكمة}}: صيانة الاستشهاد: BOT: original URL status unknown (link)
^ Ross، David Andrew (يونيو 2010). "Securing IEEE 802.11 Wireless LANs" (PDF). Queensland University of Technology: 119. مؤرشف من الأصل (PDF) في 2017-08-12. {{استشهاد بدورية محكمة}}: الاستشهاد بدورية محكمة يطلب |دورية محكمة= (مساعدة)
^ "802.11 Packet Size". Certified Wireless Network Professionals. (بالإنجليزية). 5 أغسطس 2005. Archived from the original on 23 فبراير2017. Retrieved 29 يوليو 2018. {{استشهاد ويب}}: تحقق من التاريخ في: |تاريخ أرشيف= (help)

وصلات خارجية

التقطيع في طبقة الشبكة، مقالة عن التقطيع في الإصدار الرابع من بروتوكول الإنترنت.
تقييم تقطيع رزم البيانات في الإصدارين الرابع والسادس من بروتوكول الإنترنت مقالة بقلم جيف هوستن.

[45] لم يرد ذكر الرقم بشكل صريح في معيار البروتوكول، ولكن يُمكن حسابه من مجموع الطول الأعظمي المسموح للحمولة وهو (65536) بايت، مع طول الترويسة (40) بايت.

[almaany2-1] نزار الحافظ (2007)، مسرد مصطلحات المعلوماتية (بالعربية والإنجليزية)، الجمعية العلمية السورية للمعلوماتية، ص. 72، QID:Q108442159

[Web-17-2] "Differentiate between transparent and nontransparent fragmentation?". Blogspot (بالإنجليزية). 20 Sep 2013. Archived from the original on 2017-04-25. Retrieved 2018-07-14.

[Web-64-3] ا ^ب "Fragmentation at Network Layer". geeksforgeeks (بالإنجليزية). Archived from the original on 2017-06-26. Retrieved 2018-07-30. {{استشهاد ويب}}: |archive-date= / |archive-url= timestamp mismatch (help)

[Web-31-4] ا ^ب Charles M. Kozierok. (5 Sep 2005). "Network Layer (Layer 3)". The TCP/IP Guide (بالإنجليزية). Archived from the original on 2017-07-30. Retrieved 2018-07-22.

[Web-42-5] ا ^ب "How the TCP/IP Protocols Handle Data Communications". Oracle (بالإنجليزية). 6 Apr 2014. Archived from the original on 2018-07-03. Retrieved 2018-07-23.

[Web-26-6] ا ^ب ^ج "Configuring Link Fragmentation and Interleaving (LFI) With Campus ATM Switches". Cisco Systems, Inc. (بالإنجليزية). Archived from the original on 2017-05-13. Retrieved 2018-07-20.

[Web-44-7] ا ^ب Howard Frazier (23 Jan 2008). "Aggregation at the Physical Layer" (PDF). IEEE (بالإنجليزية). Archived from the original (PDF) on 2016-09-13. Retrieved 2018-07-24.

[Web-40-8] Charles M. Kozierok (5 Sep 2015). "Data Encapsulation, Protocol Data Units (PDUs) and Service Data Units (SDUs)". TCP/IP guide (بالإنجليزية). Archived from the original on 2017-07-30. Retrieved 2018-07-23. {{استشهاد ويب}}: |archive-date= / |archive-url= timestamp mismatch (help)

[Web-41-9] ا ^ب "Segmentation, Fragmentation and Reassembly". InetDaemon Enterprises (بالإنجليزية). 6 Apr 2014. Archived from the original on 2017-01-01. Retrieved 2018-07-23. {{استشهاد ويب}}: |archive-date= / |archive-url= timestamp mismatch (help)

[Web-50-10] "MTU Definition". Linux Information Project (بالإنجليزية). 9 أوكتوبر 2005. Archived from the original on 23 فبراير 2018. Retrieved 25 يوليو 2018. {{استشهاد ويب}}: تحقق من التاريخ في: |تاريخ= (help)

[Web-43-11] "Segmentation vs fragmentation". Cisco systems, Inc. (بالإنجليزية). 24 Mar 2008. Archived from the original on 2018-07-13. Retrieved 2018-07-23.

[Web-6-12] uzair syed naveed (25 أوكتوبر 2009). "IP reassembly at destination host". Cisco Systems, Inc. (بالإنجليزية). Archived from the original on 17 مايو 20172020-05-09. Retrieved 28 يونيو 2018. {{استشهاد ويب}}: تحقق من التاريخ في: |تاريخ= and |تاريخ أرشيف= (help)

[JOU-10-13] ا ^ب "802.15.4-2015 - IEEE Standard for Low-Rate Wireless Networks". IEEE STANDARD. IEEE. أبريل 2016. DOI:10.1109/IEEESTD.2016.7460875. ISBN:978-1-5044-0845-5.

[JOU-11-14] M. Frazier، Howard (مارس 2008). "Aggregation at the physical layer". IEEE Communications Magazine. IEEE. ج. 46 ع. 2: 512. DOI:10.1109/MCOM.2008.4476164. مؤرشف من الأصل في 2020-03-13.

[Web-15-15] ا ^ب ^ج Charles M. Kozierok (20 Sep 2005). "IP Message Fragmentation Process". The TCP/IP Guide (بالإنجليزية). Archived from the original on 2017-07-03. Retrieved 2018-07-13.

[Web-3-16] ا ^ب "Resolve IP Fragmentation, MTU, MSS, and PMTUD Issues with GRE and IPSEC". Cisco Systems, Inc. (بالإنجليزية). Archived from the original on 2018-05-21. Retrieved 2018-06-27.

[Web-19-17] Joel Haefner. "Internetworking Concepts". Illinois Wesleyan University (بالإنجليزية). Archived from the original on 2020-03-13. Retrieved 2018-07-15.

[JOU-2-18] ا ^ب A. Kent، Christopher؛ C. Mogul، Jeffrey (يناير 1995). "Fragmentation considered harmful" (PDF). ACM SIGCOMM Computer Communication Review - Special twenty-fifth anniversary issue. Highlights from 25 years of the Computer Communication Review. ACM. ج. 17 ع. 5: 75-87. DOI:10.1145/205447.205456. مؤرشف من الأصل في 2020-03-25. اطلع عليه بتاريخ 2018-07-30.{{استشهاد بدورية محكمة}}: صيانة الاستشهاد: BOT: original URL status unknown (link)

[Web-1-19] "IP Fragmentation Buffer". Cisco Systems (بالإنجليزية). Archived from the original on 2018-06-27. Retrieved 2018-06-27.

[Web-12-20] "Packet Fragmentation". De Nayer Instituut (بالإنجليزية). Sep 2002. Archived from the original on 2018-07-11. Retrieved 2018-07-11.

[ietf-4-21] ا ^ب ^ج Ziemba, G.; Reed, D.; Traina, P. (أوكتوبر 1995). "RFC 1858, Security Considerations for IP Fragment Filtering". The Internet Society (بالإنجليزية). Archived from the original on 2020-05-09. Retrieved 1 يوليو 2018. {{استشهاد ويب}}: تحقق من التاريخ في: |تاريخ= (help)

[Web-2-22] "Rose Frag Attack Explained". Digintal.net (بالإنجليزية). Archived from the original on 2017-08-28. Retrieved 2018-06-27.

[Book-4-23] ا ^ب Ivan Pepelnjak (2008). The Never Ending Story of IP Fragmentation (PDF) (بالإنجليزية). NIL Learning. Archived from the original on 2020-03-25. Retrieved 2018-07-30.{{استشهاد بكتاب}}: صيانة الاستشهاد: BOT: original URL status unknown (link)

[Web-37-24] ا ^ب Marek Majkowski (18 Aug 2017). "Broken packets: IP fragmentation is flawed". Cloudflare (بالإنجليزية). Archived from the original on 2018-06-30. Retrieved 2018-07-22.

[Web-10-25] "Glossary of Security Terms, F". SANS™ Institute (بالإنجليزية). Archived from the original on 2018-06-23. Retrieved 2018-06-29.

[Web-36-26] ا ^ب ^ج ^د ^ه Geoff Huston (29 Jan 2016). "Evaluating IPv4 and IPv6 Packet Fragmentation". Réseaux IP Européens Network Coordination Centre RIPE NCC (بالإنجليزية). Archived from the original on 2018-04-25. Retrieved 2018-07-22.

[Web-13-27] ا ^ب Charles M. Kozierok (20 Sep 2005). "IP Message Reassembly Process". The TCP/IP Guide (بالإنجليزية). Archived from the original on 2017-06-15. Retrieved 2018-07-11.

[Web-32-28] Mark Baggett (13 Jun 2012). "IP Fragment Reassembly with Scapy". SANS Institute (بالإنجليزية). Archived from the original on 2018-07-22. Retrieved 2018-07-22.

[ietf-7-29] D. Clark, David (Jul 1982). "RFC 815, IP DATAGRAM REASSEMBLY ALGORITHMS". The Internet Society (بالإنجليزية). Archived from the original on 2016-03-09. Retrieved 2018-07-11.

[Book-2-30] Christoph Meinel; Harald Sack (2013). Internetworking: Technological Foundations and Applications (بالإنجليزية). Springer Science & Business Media. p. 469. ISBN:9783642353918.

[Web-16-31] Charles M. Kozierok (20 Sep 2005). "IP Message Fragmentation Process". The TCP/IP Guide (بالإنجليزية). Archived from the original on 2017-12-15. Retrieved 2018-07-13.

[ietf-11-32] ا ^ب Mogul, J.; Deering, S. (Nov 1990). "RFC 1191, Path MTU Discovery". The Internet Society (بالإنجليزية). Archived from the original on 2019-06-20. Retrieved 2018-07-13.

[ietf-12-33] ا ^ب McCann, J.; Deering, S.; Mogul, J.; Hinden, Ed., R. (Jul 2017). "RFC 8201, Path MTU Discovery for IP version 6". The Internet Society (بالإنجليزية). Archived from the original on 2019-03-21. Retrieved 2018-07-13.

[Web-18-34] "Resolve IP Fragmentation, MTU, MSS, and PMTUD issues with GRE and IPSEC" (PDF). Cisco Systems, Inc. (بالإنجليزية). Archived from the original (PDF) on 2014-08-02. Retrieved 2018-07-15.

[ietf-22-35] West, M.; McCann, S. (Mar 2006). "RFC 4413, TCP/IP Field Behavior". The Internet Society (بالإنجليزية). p. 22. Archived from the original on 2012-08-11. Retrieved 2018-07-22.

[JOU-6-36] Genkov، Delian؛ Ilarionov، Raycho (يناير 2006). "Avoiding IP Fragmentation at the Transport Layer of the OSI Reference Model". International Conference on Computer Systems and Technologies - CompSysTech’06. مؤرشف من الأصل في 2020-03-25.

[ietf-21-37] Postal, J. (Sep 1981). "RFC 793, Transmission control protocol, DARPA internet program,protocol specification". The Internet Society (بالإنجليزية). Archived from the original on 2019-05-05. Retrieved 2017-07-22.

[Web-8-38] James Curtis (17 Jan 2000). "UDP vs TCP". Wand (بالإنجليزية). Archived from the original on 2017-05-06. Retrieved 2018-06-29.

[ietf-1-39] Postel, J. (Nov 1983). "RFC 879, The TCP Maximum Segment Size and Related Topics". The Internet Society (بالإنجليزية). p. 2. Archived from the original on 2016-03-08. Retrieved 2018-07-28.

[Web-9-40] Nurul Islam Roman (15 Dec 2014). "TCP Maximum Segment Size (MSS) and Relationship to IP Datagram Size". APNIC (بالإنجليزية). Archived from the original on 2017-05-17. Retrieved 2018-06-28.

[Web-5-41] Charles M. Kozierok (20 Sep 2005). "TCP Maximum Segment Size (MSS) and Relationship to IP Datagram Size". TCP/IP Guide (بالإنجليزية). Archived from the original on 2017-01-11. Retrieved 2018-06-28.

[ietf-2-42] Postel, J. (Nov 1983). "RFC 879, The TCP Maximum Segment Size and Related Topics". The Internet Society (بالإنجليزية). p. 1. Archived from the original on 2016-03-08. Retrieved 2018-07-28.

[ietf-3-43] Postal, J. (Sep 1981). "RFC 793, Transmission control protocol, DARPA internet program,protocol specification". The Internet Society (بالإنجليزية). p. 19. Archived from the original on 2019-05-05. Retrieved 2018-06-28.

[ietf-5-44] ا ^ب ^ج ^د ^ه ^و Postel, J. (Sep 1981). "RFC 791, Internet Protocol, DARPA Internet Program Protocol Specification". The Internet Society (بالإنجليزية). Archived from the original on 2019-09-18. Retrieved 2018-07-01.

[ietf-9-46] ا ^ب ^ج ^د ^ه ^و Deering, S.; Hinden, R. (Jul 2017). "RFC 8200, Internet Protocol, Version 6 (IPv6) Specification". The Internet Society (بالإنجليزية). Archived from the original on 2019-06-26. Retrieved 2018-07-13.

[Book-6-47] Shivendra Panwar, Shivendra S. Panwar, Shiwen Mao, Jeong-dong Ryoo, Yihan Li (2014). TCP/IP Essentials: A Lab-Based Approach (بالإنجليزية). Cambridge University Press. p. 101. ISBN:0521841445.{{استشهاد بكتاب}}: صيانة الاستشهاد: أسماء متعددة: قائمة المؤلفين (link)

[Web-63-48] Joshua Johnson (17 May 2014). "Describe the IP Packet Header and each field in a Traffic Capture". Cisco Systems, Inc. (بالإنجليزية). Archived from the original on 2017-07-30. Retrieved 2018-07-30. {{استشهاد ويب}}: |archive-date= / |archive-url= timestamp mismatch (help)

[Web-62-49] "The IP Datagram". Rhys Haden (بالإنجليزية). Archived from the original on 2017-02-16. Retrieved 2018-07-30.

[ietf-24-50] ا ^ب Touch, J. (Feb 2013). "RFC 6864, Updated Specification of the IPv4 ID Field". The Internet Society (بالإنجليزية). p. 22. ISSN:2070-1721. Archived from the original on 2020-05-09. Retrieved 2018-07-22.

[Web-33-51] Sean Wilkins (29 Feb 2012). "Anatomy of an IPv4 Packet". Pearson Education, Pearson IT Certification (بالإنجليزية). Archived from the original on 2017-03-27. Retrieved 2018-07-22.

[Book-5-52] Toni Janevski (2015). Internet Technologies for Fixed and Mobile Networks (بالإنجليزية) (الأولى ed.). Artech House. p. 33. ISBN:9781608079216.

[Web-11-53] "Identification vs Fragment Offset". Cisco Systems, Inc. (بالإنجليزية). 27 Jan 2018. Archived from the original on 2018-07-01. Retrieved 2018-07-01.

[ietf-105-54] D. Clark, David (Jul 1982). "RFC 815, IP DATAGRAM REASSEMBLY ALGORITHMS". The Internet Society (بالإنجليزية). DOI:10.17487/RFC0815. Archived from the original on 2020-05-07. Retrieved 2019-06-09.

[ietf-25-55] Miller, I. (Jun 2001). "RFC 3128, Protection Against a Variant of the Tiny Fragment Attack". The Internet Society (بالإنجليزية). p. 22. Archived from the original on 2012-08-11. Retrieved 2018-07-22.

[Web-38-56] "Explore new firmware that's helping organizations see attacks as they happen". Datacom (بالإنجليزية). 3 Nov 2015. Archived from the original on 2017-02-11. Retrieved 2018-07-22.

[JOU-8-57] H. Ptacek، Thomas؛ N. Newsham، Timothy (يناير 1998). "Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection" (PDF). Computer Systems Management and Standards. DEFENSE TECHNICAL INFORMATION CENTER: 46-52. مؤرشف من الأصل (PDF) في 2017-08-12.

[ietf-6-58] D. Clark, David (Jul 1982). "RFC 815, IP DATAGRAM REASSEMBLY ALGORITHMS". The Internet Society (بالإنجليزية). Archived from the original on 2019-03-28. Retrieved 2018-07-01.

[Web-27-59] Matt Conran (16 أوكتوبر 2018). "IPV6 FRAGMENTATION". Technology Focused Hub PS Delivery ltd (بالإنجليزية). Archived from the original on 2 يناير 2018. Retrieved 20 يوليو 2018. {{استشهاد ويب}}: تحقق من التاريخ في: |تاريخ= (help)

[Web-20-60] Phillip Remaker (21 Mar 2011). "IPv6 MTU Gotchas and other ICMP issues". Cisco Systems, Inc (بالإنجليزية). Archived from the original on 2016-09-19. Retrieved 2018-07-17.

[Web-21-61] "Protocol Numbers". IANA (بالإنجليزية). Archived from the original on 2018-01-04. Retrieved 2018-07-18.

[ietf-17-62] Gont, F. (Feb 2016). "RFC 7739, Security Implications of Predictable Fragment Identification Values". The Internet Society (بالإنجليزية). ISSN:2070-1721. Archived from the original on 2020-05-09. Retrieved 2018-07-17.

[Web-24-63] Geoff Huston (19 May 2016). "Fragmenting IPv6". Réseaux IP Européens Network Coordination Centre RIPE NCC (بالإنجليزية). Archived from the original on 2017-05-05. Retrieved 2018-07-18.

[Web-23-64] Charles M. Kozierok (20 Sep 2005). "IPv6 Datagram Size, Maximum Transmission Unit (MTU), Fragmentation and Reassembly". The TCP/IP Guide (بالإنجليزية). Archived from the original on 2017-09-10. Retrieved 2018-07-18.

[Web-22-65] Bill Cerveny (25 Jul 2011). "IPv6 Fragmentation". ARBOR NETWORKS, INC. (بالإنجليزية). Archived from the original on 2018-06-26. Retrieved 2018-07-18.

[Web-30-66] Charles M. Kozierok. (5 Sep 2005). "IPV6 FRAGMENTATION". The TCP/IP Guide (بالإنجليزية). Archived from the original on 2017-07-11. Retrieved 2018-07-20. {{استشهاد ويب}}: |archive-date= / |archive-url= timestamp mismatch (help)

[JOU-9-67] Atlasis، Antonios (2002). "Attacking IPv6 Implementation Using Fragmentation" (PDF). Black-Hat Europe. مؤرشف من الأصل (PDF) في 2020-03-25.

[ietf-19-68] Krishnan, S. (Feb 2016). "RFC 5722, Handling of Overlapping IPv6 Fragments". The Internet Society (بالإنجليزية). Archived from the original on 2020-05-09. Retrieved 2018-07-21.

[ietf-20-69] Gont, F. (May 2013). "RFC 6946, Processing of IPv6 "Atomic" Fragments". The Internet Society (بالإنجليزية). ISSN:2070-1721. Archived from the original on 2020-05-09. Retrieved 2018-07-21.

[JOU-5-70] ا ^ب "802.3-2015 - IEEE Standard for Ethernet". IEEE Standard. IEEE: 2690-2699. مارس 2016. DOI:10.1109/IEEESTD.2016.7428776. ISBN:978-1-5044-0078-7. مؤرشف من الأصل في 2019-12-14.

[Web-55-71] Brent Baccala (Apr 1997). "IEEE 802.5 Details". Connected: An Internet Encyclopedia (بالإنجليزية). Archived from the original on 2016-06-05. Retrieved 2018-07-29.

[Web-56-72] "Token-Ring IEEE 802.5". IBM Corporation (بالإنجليزية). Archived from the original on 2018-07-29. Retrieved 2018-07-29.

[JOU-7-73] ا ^ب "802.11-2016 - IEEE Standard for Information technology--Telecommunications and information exchange between systems Local and metropolitan area networks--Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications". IEEE. ديسمبر 2016: 1301. DOI:10.1109/IEEESTD.2016.7786995. ISBN:978-1-5044-3645-8. {{استشهاد بدورية محكمة}}: الاستشهاد بدورية محكمة يطلب |دورية محكمة= (مساعدة)

[Web-25-74] "Understanding Link Fragmentation and Interleaving Configuration". Juniper Networks, Inc (بالإنجليزية). Archived from the original on 2018-07-20. Retrieved 2018-07-20.

[Web-58-75] "Media MTU Sizes by Interface Type". Juniper Networks, Inc. (بالإنجليزية). Archived from the original on 2017-09-20. Retrieved 2018-07-29.

[Web-59-76] "MTU Behavior on Cisco IOS XR and Cisco IOS Routers". Cisco Systems, Inc. (بالإنجليزية). Archived from the original on 2017-06-30. Retrieved 2018-07-29.

[Book-3-77] Gast, Matthew (2002). 802.11 Wireless Networks: The Definitive Guide (بالإنجليزية) (الأولى ed.). O'Reilly Media. p. 46. ISBN:0596001835.

[JOU-3-78] Diaconu، Felix (يوليو 2011). "IEEE 802.11 MAC frame fragmentation performances in jammed environments" (PDF). Bul. Inst. Politehnic, Iaşi, s. Electrot., Energ., Electron. ج. 58 ع. 2: 81-88. مؤرشف من الأصل (PDF) في 2015-11-22.

[Book-7-79] Jeff T. Buckwalter (1999). Frame Relay: Technology and Practice (بالإنجليزية) (الأولى ed.). Addison-Wesley Professional. p. 215. ISBN:0201485249.

[Web-51-80] ا ^ب ^ج ^د Andrew G. Malis (Dec 1997). "Frame Relay Fragmentation Implementation Agreement FRF.12" (PDF). Broadband Forum (بالإنجليزية). Archived from the original (PDF) on 2016-04-26. Retrieved 2018-07-28.

[Web-52-81] Andrew G. Malis. "Frame Relay, section: Frame Relay Fragmentation". Rhys Haden (بالإنجليزية). Archived from the original on 2017-06-12. Retrieved 2018-07-28.

[ietf-27-82] ا ^ب ^ج Sklower, K.; Lloyd, B.; McGregor, G.; D. Carr, W.; Coradetti, T. (Aug 1996). "RFC 1990, The PPP Multilink Protocol (MP)". The Internet Society (بالإنجليزية). Archived from the original on 2020-05-09. Retrieved 2018-07-25.

[ietf-28-83] Brown, C.; Malis, A. (Sep 1998). "RFC 2427, Multiprotocol Interconnect over Frame Relay". The Internet Society (بالإنجليزية). p. 27. Archived from the original on 2020-05-09. Retrieved 2018-07-29.

[Web-53-84] "Frame Relay Glossary" (PDF). Cisco systems, Inc (بالإنجليزية). p. 3. Archived from the original (PDF) on 2016-05-12. Retrieved 2018-07-29.

[ietf-26-85] Simpson, W. (Jul 1994). "RFC 1661, The Point-to-Point Protocol (PPP)". The Internet Society (بالإنجليزية). Archived from the original on 2005-05-08. Retrieved 2018-07-25.

[Web-60-86] "Understanding Link Fragmentation and Interleaving Configuration". Juniper Networks, Inc. (بالإنجليزية). 24 Oct 2017. Archived from the original on 2018-07-20. Retrieved 2018-07-29.

[Web-46-87] Charles M. Kozierok (20 Sep 2005). "PPP Multilink Protocol (MP/MLP/MLPPP)". The TCP/IP Guide (بالإنجليزية). Archived from the original on 2017-01-23. Retrieved 2018-07-25.

[Web-47-88] Charles M. Kozierok (20 Sep 2005). "PPP Multilink Protocol (MP/MLP/MLPPP)". The TCP/IP Guide (بالإنجليزية). Archived from the original on 2017-12-22. Retrieved 2018-07-25.

[Web-48-89] "Configuring Link Fragmentation and Interleaving (LFI) With Campus ATM Switches". Cisco Systems, Inc. (بالإنجليزية). Archived from the original on 2017-05-13. Retrieved 2018-07-25.

[Web-61-90] Charles M. Kozierok (20 Sep 2005). "PPP Multilink Protocol (MP) Frame Format". The TCP/IP Guide (بالإنجليزية). Archived from the original on 2018-01-21. Retrieved 2018-07-29.

[ietf-14-91] Postal, J. (Aug 1981). "RFC 792, Internet Control Message protocol, DARPA internet program,protocol specification". The Internet Society (بالإنجليزية). Archived from the original on 2019-04-20. Retrieved 2018-07-14.

[ietf-15-92] Gupta, M. (Mar 2006). "RFC 4443, Internet Control Message Protocol (ICMPv6),for the Internet Protocol Version 6 (IPv6) Specification". The Internet Society (بالإنجليزية). Archived from the original on 2019-04-02. Retrieved 2018-07-15.

[JOU-AD1-93] POSTEL، JONATHAN B. (أبريل 1980). "Internetwork Protocol Approaches". IEEE TRANSACTIONS ON COMMUNICATIONS. IEEE. ج. 28 ع. 4: 604 - 611. DOI:10.1109/TCOM.1980.1094705. ISSN:0090-6778. مؤرشف من الأصل في 2018-08-10.

[Web-54-94] "Inter-Switch Link and IEEE 802.1Q Frame Format". Cisco systems, Inc, (بالإنجليزية). Archived from the original on 2017-06-10. Retrieved 2018-07-29.{{استشهاد ويب}}: صيانة الاستشهاد: علامات ترقيم زائدة (link)

[JOU-12-95] "802.1Q-2014 - IEEE Standard for Local and metropolitan area networks--Bridges and Bridged Networks". IEEE Standards. IEEE. ديسمبر 2014. DOI:10.1109/IEEESTD.2014.6991462. ISBN:978-0-7381-9433-2.

[JOU-13-96] "Ethernet Jumbo Frames" (PDF). IEEE Communications Magazine. ethernet alliance. نوفمبر 2009. مؤرشف من الأصل في 2020-03-25. اطلع عليه بتاريخ 2018-07-30.{{استشهاد بدورية محكمة}}: صيانة الاستشهاد: BOT: original URL status unknown (link)

[JOU-14-97] Ross، David Andrew (يونيو 2010). "Securing IEEE 802.11 Wireless LANs" (PDF). Queensland University of Technology: 119. مؤرشف من الأصل (PDF) في 2017-08-12. {{استشهاد بدورية محكمة}}: الاستشهاد بدورية محكمة يطلب |دورية محكمة= (مساعدة)

[Web-57-98] "802.11 Packet Size". Certified Wireless Network Professionals. (بالإنجليزية). 5 أغسطس 2005. Archived from the original on 23 فبراير2017. Retrieved 29 يوليو 2018. {{استشهاد ويب}}: تحقق من التاريخ في: |تاريخ أرشيف= (help)

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[25]

[26]

[27]

[28]

[29]

[30]

[31]

[32]

[33]

[34]

[35]

[36]

[37]

[38]

[39]

[40]

[41]

[42]

[43]

[44]

[a]

[45]

[46]

[47]

[48]

[49]

[50]

[51]

[52]

[53]

[54]

[55]

[56]

[57]

[58]

[59]

[60]

[61]

[62]

[63]

[64]

[65]

[66]

[67]

[68]

[69]

[70]

[71]

[72]

[73]

[74]

[75]

[76]

[77]

[78]

[79]

[80]

[81]

[82]

[83]

[84]

[85]

[86]

[87]

[88]

[89]

[90]

[91]

[92]

[93]

[94]

[95]

[96]

[97]