عرض مصدر تقطيع (شبكات)

{{عن|3=تقطيع (توضيح)}}
[[ملف:PDU Fragmentation-ar.png|تصغير|300بك|مثال عن تقطيع قسم حمولة [[وحدة بيانات بروتوكول|وحدة بيانات البروتوكول]] لينتج عنها قطع ذات طول أصغر من طول الحمولة الأصلية.]]
في بعض من طبقات [[نموذج الربط البيني للأنظمة المفتوحة]] [[شبكة بيانات|لشبكات البيانات]]، '''التقطيع'''<ref name="almaany2">{{استشهاد بويكي بيانات|Q108442159|ص=72}}</ref> {{إنج|Fragmentation}} أو {{إنج|Segmentation}}<ref name="Web-17">{{استشهاد بويب
| مسار أرشيف = https://web.archive.org/web/20170425053540/http://productdevelop.blogspot.com/2013/09/differentiate-between-transparent-and.html
| تاريخ أرشيف = 25 أبريل 2017
| تاريخ = 20 سبتمبر 2013
| مسار= http://productdevelop.blogspot.com/2013/09/differentiate-between-transparent-and.html
| عنوان= Differentiate between transparent and nontransparent fragmentation?
| موقع= Blogspot
| لغة= en
| تاريخ الوصول= 14 يوليو 2018}}</ref> هو تقسيم [[حمولة (حوسبة)|الحمولة]] في [[وحدة بيانات بروتوكول]] إلى قسمين أو أكثر بأطوال أصغر من طول الحمولة الأصلية. يحصل التقطيع عندما يتجاوز طول حمولة وحدة بيانات البروتوكول عتبة مُحددة يحددها بروتوكول الطبقة.

التقطيع هو وظيفة أساسية لبروتوكولات [[طبقة الشبكة]]،<ref name="Web-64">{{استشهاد بويب
| مسار أرشيف = https://web.archive.org/web/20180626203534/https://www.cdn.geeksforgeeks.org/fragmentation-network-layer/
| تاريخ أرشيف = 26 يونيو 2017
| مسار= https://www.geeksforgeeks.org/fragmentation-network-layer/
| عنوان= Fragmentation at Network Layer
| موقع= geeksforgeeks
| لغة= en
| تاريخ الوصول= 30 يوليو 2018}}</ref><ref name="Web-31"/> ولكنه قد يحصل في [[طبقة النقل]] أو في [[طبقة ربط البيانات]] أو في [[طبقة مادية|الطبقة المادية]].<ref name="Web-42"/> يهدف التقطيع بشكل الأساسي إلى توليد وحدات بيانات بروتوكول بأطوال أقل، لكنّه قد يُستخدم كجزء من آلية التقطيع والتوزيع في طبقة الربط (LFI)،<ref name="Web-26"/> أو لتحسين الوصول إلى الوسط المادي في الطبقة المادية.<ref name="Web-44"/>

== نظرة عامة ==
[[ملف:TCP-IP fragmentation - ar.png|تصغير|300بك|التقطيع بحسب [[حزمة بروتوكولات الإنترنت]] (TCP/IP) إذا حصل التقطيع في كل طبقة بدءًا من طبقة النقل، ولكن هذه ليست حالة إلزامية، فذلك مرتبط بالحجم الأقصى لوحدة بيانات البروتوكول المسموح به في كل طبقة.]]

[[ملف:Types of Fragmentation - ar.png|300بك|تصغير|أنماط التقطيع: (أ) التقطيع المرئي بالنسبة للبروتوكول، وفيه يمكن للبروتوكول إعادة تجميع القطع وبناء الحمولة الأصلية في عقدة ما على المسار بين المصدر والوجهة. (ب) التقطيع غير المرئي بالنسبة للبروتوكول، وفيه لا يمكن للبروتوكول إعادة تجميع القطع إلا في الوجهة النهائية.]]

[[ملف:TCP header location when fragmenting an IP packet - ar.png|تصغير|300بك|موقع [[ترويسة (حوسبة)|ترويسة]] [[بروتوكول التحكم بالنقل]] عند تقطيع [[رزمة بيانات]] لبروتوكول الإنترنت، توجد الترويسة في القطعة الأولى فقط، ويسبب ذلك [[ثغرة أمنية (حوسبة)|ثغرة أمنية]] يمكن استخدامها لإطلاق هجوم التقطيع عبر بروتوكول الإنترنت.]]

بحسب [[نموذج الربط البيني للأنظمة المفتوحة|نموذج الاتصال المعياري]]، تتكون [[وحدة بيانات بروتوكول|وحدة بيانات البروتوكول]] في كل طبقة من [[حمولة (حوسبة)|حمولة]] و[[ترويسة (حوسبة)|ترويسة]]،<ref name="Web-40">{{استشهاد بويب
| مؤلف = Charles M. Kozierok
| مسار أرشيف = https://web.archive.org/web/20170630085207/http://www.tcpipguide.com/free/t_DataEncapsulationProtocolDataUnitsPDUsandServiceDa.htm
| تاريخ أرشيف =30 يوليو 2017
| تاريخ = 5 سبتمبر 2015
| مسار= http://www.tcpipguide.com/free/t_DataEncapsulationProtocolDataUnitsPDUsandServiceDa.htm
| عنوان= Data Encapsulation, Protocol Data Units (PDUs) and Service Data Units (SDUs)
| موقع= TCP/IP guide
| لغة= en
| تاريخ الوصول= 23 يوليو 2018}}</ref> والتقطيع هو تقسيم الحمولة في بعض طبقات النموذج، إلى قطعتين أو أكثر بحيث تُشكّل كل قطعة حمولة لوحدة بيانات بروتوكول أصغر من وحدة البيانات الأصلية التي تمّ تقطيعُها.<ref name="Web-41">{{استشهاد بويب
| مسار أرشيف = https://web.archive.org/web/20180101021202/http://www.inetdaemon.com:80/tutorials/basic_concepts/communication/segmentation_and_reassembly.shtml
| تاريخ أرشيف =1 يناير 2017
| تاريخ = 6 أبريل 2014
| مسار= https://www.inetdaemon.com/tutorials/basic_concepts/communication/segmentation_and_reassembly.shtml
| عنوان= Segmentation, Fragmentation and Reassembly
| موقع= InetDaemon Enterprises
| لغة= en
| تاريخ الوصول= 23 يوليو 2018}}</ref> يحصل التقطيع في الطبقات الرابعة والثالثة والثانية والأولى من النموذج، وتحدد [[بروتوكول (اتصالات)|البروتوكولات]] التي تعمل في هذه الطبقات قيمًا مُميزة لكل طبقة، تُستخدم كعتبة لتحديد متى يحصل التقطيع، فإذا كان طول وحدة بيانات البروتوكول أكبر من قيمة العتبة كان التقطيع إلزاميًّا.<ref name="Web-50">{{استشهاد بويب
| مسار أرشيف = https://web.archive.org/web/20180223153949/http://www.linfo.org/mtu.html
| تاريخ أرشيف = 23 فبراير 2018
| تاريخ = 9 أوكتوبر 2005
| مسار= http://www.linfo.org/mtu.html
| عنوان= MTU Definition

| موقع=  Linux Information Project
| لغة= en
| تاريخ الوصول= 25 يوليو 2018}}</ref>

إذا كان بروتوكول النقل المستعمل يدعم التقطيع، فإنّ التقطيع في [[طبقة النقل]] لا يحصل إلا في المُضيف المصدر فقط، وهو يهدف إلى إنشاء وحدات بيانات بروتوكول ذات طول أقصر من طول الوحدة الأصلية. لإنجاز التقطيع في هذه الطبقة، يتمّ اعتبار كل ما ورد من الطبقة الأعلى حمولة، ويجري تقسيمها إلى قطع، ثُم [[تغليف (شبكات)|تُغلّف]] القطع بترويسة البروتوكول لتُنتج وحدات بيانات بروتوكول طبقة النقل.<ref name="Web-42">{{استشهاد بويب
| مسار أرشيف = https://web.archive.org/web/20180703080025/https://docs.oracle.com/cd/E26505_01/html/E27061/ipov-29.html
| تاريخ أرشيف =3 يوليو 2018
| تاريخ = 6 أبريل 2014
| مسار= https://docs.oracle.com/cd/E26505_01/html/E27061/ipov-29.html
| عنوان= How the TCP/IP Protocols Handle Data Communications
| موقع= Oracle
| لغة= en
| تاريخ الوصول= 23 يوليو 2018}}</ref> يدعم [[بروتوكول التحكم بالنقل]] عملية التقطيع، وتسمى وحدة بيانات البروتوكول الناتجة عن تغليف أقسام الحمولة السابقة بترويسات البروتوكول قطعة {{إنج|Segment}}، أمّا [[بروتوكول حزم بيانات المستخدم]] فهو لا يدعم التقطيع، ويُغلّف الحمولة بإضافة ترويسته لها كما وردت، دون تقطيعها، وتسمى وحدة بيانات البروتوكول الناتجة حزمة البيانات {{إنج|Datagram}}. وفي الحالتين يتم تمرير وحدات بيانات البروتوكول الناتجة إلى [[طبقة الشبكة]].<ref name="Web-43">{{استشهاد بويب
| مسار أرشيف = https://webcache.googleusercontent.com/search?q=cache:Q3ol0hxgbVkJ:https://supportforums.cisco.com/t5/lan-switching-and-routing/segmentation-vs-fragmentation/td-p/1010431+&cd=6&hl=en&ct=clnk&gl=fr
| تاريخ أرشيف =13 يوليو 2018
| تاريخ = 24 مارس 2008
| مسار= https://community.cisco.com/t5/lan-switching-and-routing/segmentation-vs-fragmentation/td-p/1010431+&cd=6&hl=en&ct=clnk&gl=fr
| عنوان= Segmentation vs fragmentation

| موقع= Cisco systems, Inc.
| لغة= en
| تاريخ الوصول= 23 يوليو 2018|url-status=dead}}</ref>

التقطيع هو وظيفة أساسية لبروتوكولات الشبكة، وهو يحصل بعد اتخاذ قرار [[توجيه (شبكات)|التوجيه]] لوحدة بيانات البروتوكول، والتي تُسمى [[رزمة بيانات]] في هذه الطبقة، وقد يكون في [[مضيف (حوسبة)|المُضيف]] المصدر الذي ولد الرزمة أو في أحد [[موجه (شبكات)|المُوجّهات]] على المسار، أو في كليهما. تتحدد عملية تقطيع رزمة البيانات بمقارنة طول الرزمة مع وحدة التقل العظمى لطبقة الشبكة، يحصل التقطيع إذا كان طول الرزمة أكبر من قيمة وحدة النقل العظمى، وهو يهدف إلى إنشاء رزم بيانات ذات طول أصغر من الرزمة الأصلية. يُمكن أن يحصل التقطيع أكثر من مرة على طول المسار لحين وصول الرزمة إلى وجهتها، ويُسمّى حينها بالتقطيع المُتعدد. لا يتمّ تجميع قطع الرزمة إلا في المُضيف الوجهة، والسبب في ذلك أن القطع قد لا تسلك نفس المسار، وبالتالي لن تمر عبر نفس المُوجّهات في طريقها للمضيف الوجهة.<ref name="Web-6">{{استشهاد بويب
| مؤلف = uzair syed naveed 
| مسار أرشيف = https://web.archive.org/web/20200509163435/https://supportforums.cisco.com/t5/lan-switching-and-routing/ip-reassembly-at-destination-host/td-p/1300609
| تاريخ أرشيف = 17 مايو 20172020-05-09
| تاريخ = 25 أوكتوبر 2009
| مسار= https://community.cisco.com/t5/switching/ip-reassembly-at-destination-host/td-p/1300609
| عنوان= IP reassembly at destination host
| موقع= Cisco Systems, Inc.
| لغة= en
| تاريخ الوصول= 28 يونيو 2018}}</ref> تمرر طبقة الشبكة رزم البيانات إلى [[طبقة ربط البيانات]].

يُمكن أن يحصل التقطيع في طبقة ربط البيانات، إما لإنتاج أطر بيانات ذات طول أصغر، أو كجزء من آلية التقطيع والتوزيع في طبقة الربط {{إنج|Link Fragmentation and Interleaving اختصاراً LFI}}. يحصل التقطيع إذا كانت طول وحدة بيانات البروتوكول في طبقة ربط البيانات، ويسمى [[إطار البيانات]]، أكبر من قيمة وحدة النقل العظمى للطبقة. بعض بروتوكولات الربط لا يقوم بالتقطيع في هذه الطبقة، مثل الإيثرنت، ولكنه يحدد قيمة لوحدة النقل العظمى، ويجب على بروتوكول الشبكة أن يلتزم بها. تفرض بعض بروتوكولات الربط قيمة أعظمية محدودة بشكلٍ مُفرط لوحدة النقل العظمى، مثل {{وإو|أي تربل أي 802.15.4|IEEE 802.15.4|en|بروتوكول الشبكات الشخصية اللاسلكية منخفضة المُعدّل}} الذي يُحدد طول إطار البيانات الأعظمي ليكون 127 [[بايت]] فقط.<ref name = "JOU-10">{{استشهاد بدورية محكمة
|صحيفة = IEEE STANDARD
|عنوان= 802.15.4-2015 - IEEE Standard for Low-Rate Wireless Networks
| تاريخ = أبريل 2016
| ناشر= IEEE
| doi = 10.1109/IEEESTD.2016.7460875
| isbn = 978-1-5044-0845-5
}}</ref> وقد يحصل التقطيع في [[طبقة مادية|الطبقة المادية]]، ولا يكون الهدف منه تقسيم وحدة بيانات البروتوكول إلى قطع أصغر، بل تحسين الوصول إلى وسط الاتصال المادي.<ref name = "JOU-11">{{استشهاد بدورية محكمة
|الأخير= M. Frazier
|الأول= Howard
|صحيفة = IEEE Communications Magazine
|عنوان= Aggregation at the physical layer
|المجلد=  46
|العدد = 2
| تاريخ = مارس 2008
|صفحة= 512
| ناشر= IEEE
| doi = 10.1109/MCOM.2008.4476164
| مسار = https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=4476164
| مسار أرشيف = https://web.archive.org/web/20200313095847/https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=4476164 | تاريخ أرشيف = 13 مارس 2020 }}</ref>

برتبط التقطيع بعملية [[تغليف (شبكات)|التغليف]] بشكلٍ وثيق، ويُسبب التقطيع زيادة في الطول الإجمالي للبيانات،<ref name="Web-15">{{استشهاد بويب
| مؤلف = Charles M. Kozierok
| مسار أرشيف = https://web.archive.org/web/20170703132525/http://www.tcpipguide.com/free/t_IPMessageFragmentationProcess-2.htm
| تاريخ أرشيف = 3 يوليو 2017
| تاريخ = 20 سبتمبر 2005
| مسار= http://www.tcpipguide.com/free/t_IPMessageFragmentationProcess-2.htma7717861.html
| عنوان= IP Message Fragmentation Process
| موقع= The TCP/IP Guide
| لغة= en
| تاريخ الوصول= 13 يوليو 2018|url-status=dead}}</ref> والسبب في هذه الزيادة هو الترويسات المُضافة للقطع أثناء تغليفها،<ref name="Web-3">{{استشهاد بويب
| مسار أرشيف = https://web.archive.org/web/20180521023828/https://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag.html
| تاريخ أرشيف = 21 مايو 2018
| مسار= https://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag.html
| عنوان= Resolve IP Fragmentation, MTU, MSS, and PMTUD Issues with GRE and IPSEC
| موقع= Cisco Systems, Inc.
| لغة= en
| تاريخ الوصول= 27 يونيو 2018}}</ref> فإذا كانت وحدة بيانات البروتوكول الأصليّة ذات طول ما مثلًا (<math>{\text{X}_{}}</math>) [[بايت]]، ناتج عن حمولة بطول (<math>{\text{Y}_{}}</math>) بايت وترويسة بطول (<math>{\text{Z}_{}}</math>) بايت حيث (<math>{\text{X=Y+Z}_{}}</math>)، فإنّ تقطيع قسم الحمولة إلى ثلاث قطع أطوالها (<math>{\text{Y1,Y2,Y3}_{}}</math>) بايت بالترتيب، وإضافة ترويسة الطبقة بطول (<math>{\text{Z}_{}}</math>) بايت لكل قطعة، سيسبب زيادة في الطول الإجمالي للبيانات، لتبيان هذه الزيادة، يُمكن التعبير عن وحدات بيانات البروتوكول الناتجة عن التقطيع بالثلاثيات (<math>{\text{X1,Y1,Z}_{}}</math>) و (<math>{\text{X2,Y2,Z}_{}}</math>) و (<math>{\text{X3,Y3,Z}_{}}</math>) على الترتيب. ويكون مجموع أطوال الحمولة في القطع مُساويًا لطول الحمولة في القطعة الأصلية، أي:

{{وسط|<math>{\text{Y=Y1+Y2+Y3}_{}}</math>}}

أمّا الطول الإجمالي، أي مجموع أطوال كل الترويسات والحمولات، فهو يزداد بمقدار ترويستين أي (<math>{\text{2Z}_{}}</math>) بايت في هذه الحالة،<ref name="Web-15"/> ويُمكن التعبير عن هذه الزيادة بشكلٍ عام بالطريقة التالية:

{{وسط|<math>{\text{X+(n-1)Z=X1+X2+..+Xn}_{}}</math>}}
: حيث (<math>{\text{n}_{}}</math>) هي عدد القطع الناتجة عن عملية التقطيع.

بالنسبة للبروتوكول الذي يقوم بالتقطيع كإحدى وظائف الطبقة، هناك نمطين للتقطيع، بحسب توافر إمكانية تجميع الرزمة الأصلية، الأول هو التقطيع المرئي أو الملحوظ بالنسبة للبروتوكول {{إنج|Transparent Fragmentation}}، وفيه يدرك البروتوكول عملية حصول التقطيع في أي نقطة في الشبكة، ونتيجة لذلك، يكون بإمكانه إعادة تجميع القطع ثم بناء حمولة الوحدة الأصلية، والثاني هو التقطيع غير المرئي أو غير الملحوظ بالنسبة للبروتوكول {{إنج|Non-Transparent Fragmentation}} وفيه لا يمكن للبروتوكول أن يعيد تجميع القطع إلا في وجهتها النهائية.<ref name="Web-19">{{استشهاد بويب
| مؤلف = Joel Haefner
| مسار= https://sun.iwu.edu/~jhaefner/CS390/Lecture13/lec13.htm
| عنوان= Internetworking Concepts
| موقع= Illinois Wesleyan University
| لغة= en
| تاريخ الوصول= 15 يوليو 2018| مسار أرشيف = https://web.archive.org/web/20200313100123/https://sun.iwu.edu/~jhaefner/CS390/Lecture13/lec13.htm | تاريخ أرشيف = 13 مارس 2020 }}</ref>

عند استخدام [[بروتوكول التحكم بالنقل]] كبروتوكول [[طبقة النقل|نقل]] في الشبكة، فإن فقدان قطعة واحدة من مجموعة القطع التي نتجت عن تقطيع رزمة البيانات الأصليّة سيسبب إعادة إرسال كل القطع مرة أخرى، والسبب في ذلك أن المُضيف الوجهة لا يكون قادرًا على تجميع الرزمة ما لم تصل كُل قطعها، وبالتالي لن يقوم بإرسال [[إشعار تأكيد|إشعار لتأكيد الاستلام]]. نتيجة لذلك، في مصدر الرزمة الأصليّة، سيسبب غياب إشعار الاستلام إعادة إرسال نسخة من الرزمة الأصلية كاملة، وستمر النسخة بنفس المراحل التي مرت فيها الرزمة الأصلية، أي سيتم تقطيعها وإرسال كل القطع عبر الشبكة مرة أخرى، على الرغم من أن ما فقد هو قطعة واحدة فقط وليس كامل الرزمة.<ref name="JOU-2"/>

في بعض الحالات، قد يسبب استقبال حركة بيانات مكونة من عدد كبير من القطع من رزم بيانات مختلفة لا يمكن تجميعها امتلاء الذاكرة المخصصة لحفظ القطع، وقد يكون ذلك وسيلة لبدء هجوم ينتمي لعائلة من الهجمات التي تعتمد على حصول التقطيع في الشبكة، وقد تهدف إلى محاولة تجاوز [[نظام كشف التسلل]] مثلًا.<ref name="Web-1">{{استشهاد بويب
| مسار أرشيف = https://web.archive.org/web/20180627204301/https://tools.cisco.com/security/center/viewIpsSignature.x?signatureId=1200&signatureSubId=0&soft_1
| تاريخ أرشيف = 27 يونيو 2018
| مسار= https://tools.cisco.com/security/center/viewIpsSignature.x?signatureId=1200&signatureSubId=0&soft_1version-government-no-public-authors-contributions-communist-party-line-a7717861.html
| عنوان= IP Fragmentation Buffer
| موقع= Cisco Systems
| لغة= en
| تاريخ الوصول= 27 يونيو 2018}}</ref> فالتقطيع في طبقة الشبكة يسبب ثغرة أمنية، لأن ترويسة بروتوكول طبقة النقل التي تحتوي أرقام المنافذ لن تُوجد إلا في القطعة الأولى فقط،<ref name="Web-12">{{استشهاد بويب
| مسار أرشيف = https://web.archive.org/web/20180711172154/http://telescript.denayer.wenk.be/~hcr/cn/idoceo/udp_fragmentation.html
| تاريخ أرشيف = 11 يوليو 2018
| تاريخ = سبتمبر 2002
| مسار= http://telescript.denayer.wenk.be/~hcr/cn/idoceo/udp_fragmentation.html
| عنوان= Packet Fragmentation
| موقع= De Nayer Instituut
| لغة= en
| تاريخ الوصول= 11 يوليو 2018}}</ref> ويمكن أن يعتمد المهاجمون على غياب ترويسة بروتوكول النقل في باقي القطع لإطلاق هجوم يُعرف باسم بهجوم القطعة الصغيرة {{إنج|Tiny Segment Attack}} <ref name="ietf-4"/> أو قد يكون الهجوم شكلًا من أشكال [[هجمات الحرمان من الخدمات|هجوم حجب الخدمة]]، من خلال محاولة ملء الذاكرة المخصصة لعملية التجميع أو استهلاك [[وحدة معالجة مركزية|حدة المعالجة المركزية]] بشكلٍ مُفرط.<ref name="Web-2">{{استشهاد بويب
| مسار أرشيف = https://web.archive.org/web/20170828001014/http://www.digital.net:80/~gandalf/Rose_Frag_Attack_Explained.htm
| تاريخ أرشيف = 28 أغسطس 2017
| مسار= http://www.digital.net:80/~gandalf/Rose_Frag_Attack_Explained.htm
| عنوان= Rose Frag Attack Explained
| موقع= Digintal.net
| لغة= en
| تاريخ الوصول= 27 يونيو 2018|url-status=dead}}</ref>

يسبب الاعتماد على التقطيع العديد من المشاكل في الشبكة،<ref name = "Book-4">{{استشهاد بكتاب
 |مؤلف1               = Ivan Pepelnjak
 |عنوان              = The Never Ending Story of IP Fragmentation
 |سنة                  = 2008
 |ناشر                = NIL Learning
 |لغة                  = en
 |صيغة              = PDF
 |مسار                = https://learning.nil.com/assets/Tips-/The-Never-Ending-Story-of-IP-Fragmentation.pdf
 |مسار أرشيف     = https://web.archive.org/web/20200325133054/https://web.archive.org/web/20170517063056/https://learning.nil.com/assets/Tips-/The-Never-Ending-Story-of-IP-Fragmentation.pdf
 |تاريخ أرشيف   = 25 مارس 2020
 |تاريخ الوصول = 30 يوليو 2018
 |حالة المسار              = bot: unknown
}}</ref> فمثلًا يجب تجميع كل أجزاء الرزمة الأصلية قبل التمكن من استعادتها، ويسبب هذا إرهاقًا لموارد المُضيف الوجهة، بالإضافة لمشكلة القطعة الأخيرة التي قد تكون ذات حجم صغير، ويسبب إرسالها عبر الشبكة استهلاكًا غير مرغوب لمورد الشبكة.<ref name="Web-37">{{استشهاد بويب
| مؤلف = Marek Majkowski
| مسار أرشيف = https://web.archive.org/web/20180630205042/https://blog.cloudflare.com/ip-fragmentation-is-broken/
| تاريخ أرشيف =30 يونيو 2018
| تاريخ = 18 أغسطس 2017
| مسار= https://blog.cloudflare.com/ip-fragmentation-is-broken/fragmentation/
| عنوان= Broken packets: IP fragmentation is flawed

| موقع= Cloudflare
| لغة= en
| تاريخ الوصول= 22 يوليو 2018|url-status=dead}}</ref> وأخيرًا، في حال تقطيع رزم أو أطر البيانات فإنّ معلومات تخص بروتوكول الطبقات العليا، مثل [[منفذ (شبكات)|أرقام المنافذ]] في طبقة النقل مثلًا لن تتواجد إلا في قطعة واحدة فقط، ما يعني أن [[جدار حماية (حوسبة)|جداران الحماية]] لا تستطيع أن تفحص هذه الرزم، ما يخلق بدوره [[ثغرة أمنية (حوسبة)|ثغرة أمنية]].<ref name = "JOU-2">{{استشهاد بدورية محكمة
|الأخير= A. Kent
|الأول= Christopher
|مؤلف2-الأخير= C. Mogul
|مؤلف2-الأول= Jeffrey
|صحيفة= ACM SIGCOMM Computer Communication Review - Special twenty-fifth anniversary issue. Highlights from 25 years of the Computer Communication Review
|عنوان= Fragmentation considered harmful
|المجلد= 17
|العدد= 5
|تاريخ= يناير 1995
|صفحة= 75-87
|ناشر= ACM
|doi= 10.1145/205447.205456
|مسار= http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-87-3.pdf
|مسار أرشيف= https://web.archive.org/web/20200325133110/https://web.archive.org/web/20161111105505/http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-87-3.pdf
|تاريخ أرشيف= 25 مارس 2020
|تاريخ الوصول= 30 يوليو 2018
|حالة المسار= bot: unknown
}}</ref>
== آلية العمل ==
=== مفهوم الإزاحة ===
[[ملف:Offset in Fragmentation - ar.png|تصغير|300بك|مفهوم الإزاحة عند تقطيع وحدة بيانات بروتوكول.]]

إزاحة القطعة {{إنج|Fragment Offset}} هي قيمة تنتج أثناء عملية تقطيع [[حمولة (حوسبة)|حمولة]] [[وحدة بيانات بروتوكول]]، تحدد هذه القيمة الموقع النسبي لقطعة محددة بالنسبة لبقية القطع ضمن الحمولة الأصلية.<ref name="Web-10">{{استشهاد بويب
| مسار أرشيف = https://web.archive.org/web/20180623105322/https://www.sans.org/security-resources/glossary-of-terms/
| تاريخ أرشيف = 23 يونيو 2018
| مسار= https://www.sans.org/security-resources/glossary-of-terms/
| عنوان= Glossary of Security Terms, F
| موقع= SANS™ Institute
| لغة= en
| تاريخ الوصول= 29 يونيو 2018}}</ref> إنّ قيمة الإزاحة ضرورية لإنجاز عملية إعادة التجميع وبدونها لا يمكن إعادة تجميع القطع بالترتيب الصحيح لإعادة إنتاج وحدة بيانات البروتوكول الأصلية التي تمّ تقطيعها.

تكون إزاحة القطعة الأولى مساوية للصفر دومًا.<ref name="Web-36"/> في حال حصول تقطيع متعدد، فإن قيمة الإزاحة تشير دائمًا إلى موقع القطعة الجديدة بالنسبة إلى الرزمة الأصلية في مرحلة التقطيع الأولى.

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

[[ملف:Time-based overlapped-fragment reassembly algorithms - ar.png|تصغير|300بك|خورازميات تجميع القطع المتراكبة بحسب تسلسل ورودها الزمني، إما باعتماد ما يرد أولًا عند التجميع أو ما يرد أخيرًا.]]

إعادة التجميع {{إنج|Reassembly}} أو {{إنج|Defragmentation}} هي آلية لإعادة إنشاء [[وحدة بيانات بروتوكول|وحدة بيانات البروتوكول]] الأصلية انطلاقًا من القطع، وتتطلب عملية إعادة التجميع استقبال جميع القطع أولًا، والتي قد تصل بترتيب مختلف لترتيبها ضمن الوحدة الأصلية، ثُمّ يجب تحديد موقع القطع النسبي ضمن وحدة بيانات البروتوكول الأصلية، وأخيرًا، يتم استخلاص [[حمولة (حوسبة)|حمولة]] القطع والتخلص من [[ترويسة (حوسبة)|الترويسات]]، ثم يجري رصف القطع مع بعضها البعض بالترتيب الصحيح لإعادة إنشاء وحدة بيانات البروتوكول الأصلية.<ref name="Web-41"/>

تحصل عملية إعادة تجميع الأطر محليًّا في الوجهة التالية مباشرة في مسار حركة البيانات، ولا تغادر قطع الإطار [[شبكة محلية|الشبكة المحلية]]، أمّا [[رزمة بيانات|رزم البيانات]] فيجري تجميعها في الوجهة النهائية لحركة البيانات، لأن رزم بيانات مختلفة ناتجة عن تقطيع رزمة بيانات واحدة قد تسلك مسارات مختلفة لتصل إلى وجهتها، واختلاف المسارات يعني عدم إمكانية التجميع إلا في الوجهة النهائية،<ref name="Web-13">{{استشهاد بويب
| مؤلف = Charles M. Kozierok
| مسار أرشيف = https://web.archive.org/web/20170615204930/http://www.tcpipguide.com/free/t_IPMessageReassemblyProcess.htm
| تاريخ أرشيف = 15  يونيو 2017
| تاريخ = 20 سبتمبر 2005
| مسار= http://www.tcpipguide.com/free/t_IPMessageReassemblyProcess.htm
| عنوان= IP Message Reassembly Process
| موقع= The TCP/IP Guide
| لغة= en
| تاريخ الوصول= 11 يوليو 2018}}</ref> على الرغم من إمكانيّة التقطيع المتعدد في أي نقطة على مسار الرزم.

قد تسمح [[خوارزمية]] التقطيع بإنشاء قطع مُتراكبة، أي أن أجزاء من الحمولة من توجد في أكثر من قطعة، ويسبب ذلك تنوعًا في خوارزميات إعادة التجميع، فبعض الخوارزميات تعتمد الأجزاء التي وردت أولًا، وتهمل أجزاء القطع المكررة التي ترد لاحقًا، وهناك خوازميات أخرى تقوم بالعكس، فهي تعتمد الأجزاء الأحدث وصولًا عند إعادة التجميع، وتهمل أجزاء القطع المكررة التي وردت سابقًا، وهناك خوارزميات أخرى تأخد أيضًا إزاحة القطعة بالحسبان.<ref name="Web-32">{{استشهاد بويب
| مؤلف = Mark Baggett
| مسار أرشيف = https://web.archive.org/web/20180722113213/https://www.sans.org/reading-room/whitepapers/tools/ip-fragment-reassembly-scapy-33969
| تاريخ أرشيف = 22 يوليو 2018
| تاريخ = 13 يونيو 2012
| مسار= https://www.sans.org/reading-room/whitepapers/tools/ip-fragment-reassembly-scapy-33969
| عنوان= IP Fragment Reassembly with Scapy
| موقع= SANS Institute
| لغة= en
| تاريخ الوصول= 22 يوليو 2018}}</ref>

وصفت خوارزميات إعادة تجميع رزم بيانات [[بروتوكول الإنترنت (الإصدار الرابع)|الإصدار الرابع من بروتوكول الإنترنت]] في وثيقة [[طلب تعليقات|طلب التعليقات]] RFC 815.<ref name="ietf-7">{{استشهاد بويب
| الأخير= D. Clark
| الأول= David
| تاريخ= يوليو 1982
| مسار أرشيف = https://web.archive.org/web/20160309181557/http://www.ietf.org/rfc/rfc815| مسار= https://www.ietf.org/rfc/rfc815
| عنوان=  RFC 815, IP DATAGRAM REASSEMBLY ALGORITHMS
| موقع= The Internet Society
| لغة= en
| تاريخ الوصول= 11 يوليو 2018| تاريخ أرشيف = 9 مارس 2016 }}</ref>

=== التقطيع المتعدد ===
[[ملف:Packet Fragmentation Example - ar.png|300بك|تصغير|مثال عن عملية تقطيع مُتعدد [[رزمة بيانات|لرزمة بيانات]] في [[شبكة حاسوب]]، يجري [[توجيه (شبكات)|توجيه]] [[رزمة بيانات|الرزمة]] من المصدر إلى الوجهة، ويتمّ تقطيعها مرتين، ثُمّ تسلك القطع مسارات مُختلفة ليصار إلى إعادة تجميعها في الوجهة.<ref name = "Book-2">{{استشهاد بكتاب
|مؤلف1= Christoph Meinel
|مؤلف2= Harald Sack
|عنوان= Internetworking: Technological Foundations and Applications
|صفحة= 469
|سنة=2013
|ناشر= Springer Science & Business Media
|ردمك= 9783642353918
|لغة= en
}}</ref>]]

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

في كل مرة يتم فيها التقطيع يجب تحديد إزاحة القطع الجديدة، أي موقعها، بالنسبة لرزمة البيانات الأصلية في المصدر، وليس بالنسبة لرزمة البيانات التي جرى تقطيعها في هذه المرحلة،<ref name="Web-16">{{استشهاد بويب
| مؤلف = Charles M. Kozierok
| مسار أرشيف = https://web.archive.org/web/20171215235603/http://www.tcpipguide.com:80/free/t_IPMessageFragmentationProcess-3.htm
| تاريخ أرشيف = 15 ديسمبر 2017
| تاريخ = 20 سبتمبر 2005
| مسار= http://www.tcpipguide.com/free/t_IPMessageFragmentationProcess-3.htm
| عنوان= IP Message Fragmentation Process
| موقع= The TCP/IP Guide
| لغة= en
| تاريخ الوصول= 13 يوليو 2018}}</ref> ونتيجة لذلك، وبما أن إعادة تجميع الرزم لا تحصل إلا في الوجهة النهائيّة، فإن تلك الوجهة قد تستقبل قطعًا مُختلفة الطول. فإنّ سلكت الرزم مسارًا مُختلفًا بين المصدر والوجهة، فقد يتمّ تقطيعها بشكلٍ مُتعدد بحسب مسارها، وبالتالي فإن عدد القطع الناتجة يتعلق بالمسار المسلوك، أمّا قيمة إزاحة القطع لإعادة بناء الرزمة الأصلية فيجب أن تدل على موقع القطعة في الرزمة الأصلية بغض النظر عن المسار التي سلكته.

لتجنب التقطيع المتعدد، هناك ميزة إضافية للإصدار الرابع من بروتوكول الإنترنت هي ميزة اكتشاف وحدة النقل العظمى للمسار، وهي تعتمد على [[بروتوكول رسائل التحكم في الإنترنت]]، وموصوفة في [[طلب تعليقات|وثيقة طلب التعليقات]] RFC 1191.<ref name="ietf-11">{{استشهاد بويب
| الأخير=  Mogul
| الأول= J.
| مؤلف2-الأخير= Deering
| مؤلف2-الأول= S.
| تاريخ= نوفمبر 1990
| مسار أرشيف = https://web.archive.org/web/20190620121637/https://tools.ietf.org/html/rfc1191| مسار= https://tools.ietf.org/html/rfc1191
| عنوان= RFC 1191, Path MTU Discovery
| موقع= The Internet Society
| لغة= en
| تاريخ الوصول= 13 يوليو 2018| تاريخ أرشيف = 20 يونيو 2019 }}</ref> أمّا في العُقد التي تُشغّل [[بروتوكول الإنترنت (الإصدار السادس)|الإصدار السادس من بروتوكول الإنترنت]]، فإنّها غالبًا ما تدعم هذه التقنية بشكلٍ افتراضي، وقد أُشير إليها في معيار البروتوكول الأصلي، ووصفت بشكل مفصل في وثيقة طلب التعليقات RFC 8201.<ref name="ietf-12">{{استشهاد بويب
| الأخير= McCann
| الأول= J.
| مؤلف2-الأخير= Deering
| مؤلف2-الأول= S.
| مؤلف3-الأخير= Mogul
| مؤلف3-الأول= J. 
| مؤلف4-الأخير= Hinden, Ed.
| مؤلف4-الأول= R. 
| تاريخ= يوليو 2017
| مسار أرشيف = https://web.archive.org/web/20190321014214/https://tools.ietf.org/html/rfc8201| مسار= https://tools.ietf.org/html/rfc8201
| عنوان= RFC 8201, Path MTU Discovery for IP version 6
| موقع= The Internet Society
| لغة= en
| تاريخ الوصول= 13 يوليو 2018| تاريخ أرشيف = 21 مارس 2019 }}</ref>

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

اكتشاف وحدة النقل العظمى للمسار {{إنج|Path Maximum Transmission Unit Discovery اختصاراً PMTUD}} هي آليّة تستخدم في [[مضيف (حوسبة)|المُضيف]] المصدر، لتحديد أدنى قيمة [[وحدة النقل العظمى|لوحدة النقل العظمى]] على طول مسار ما، وبالتالي توليد [[رزمة بيانات|رزم بيانات]] بأطوال متوافقة معها، بحيث لا يعود هناك حاجة لتقطيع الرزم أثناء حركتها على المسار من المصدر إلى الوجهة.<ref name="Web-18">{{استشهاد بويب
| مسار أرشيف = https://web.archive.org/web/20140802071141/https://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag.pdf
| تاريخ أرشيف = 2 أغسطس 2014
| مسار= https://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag.pdf
| عنوان= Resolve IP Fragmentation, MTU, MSS, and PMTUD issues with GRE and IPSEC
| موقع= Cisco Systems, Inc.
| لغة= en
| تاريخ الوصول= 15 يوليو 2018}}</ref> قد لا يتمكن المصدر من تحديد حجم النقل الأعظمي الأدنى بدقة، ولكن استعمال هذه الآليّة يساعده على توليد رزم بيانات ذات أطوال أقل أو تساوي أدنى قيمة لحجم النقل الأعظمي على طول المسار.<ref name="Book-4"/>

إذا استُخدم [[بروتوكول الإنترنت (الإصدار الرابع)|الإصدار الرابع من بروتوكول الإنترنت]] كبروتوكول [[طبقة الشبكة|شبكة]]، فإنّ آليّة الاكتشاف الخاصّة به هي [[برنامج مساعد (حوسبة)|توسيعة إضافية]] تعتمد على [[بروتوكول رسائل التحكم في الإنترنت]]،{{للهامش|1}} وعلى علم عدم التقطيع في [[ترويسة (حوسبة)|ترويسة]] البروتوكول.<ref name="ietf-22">{{استشهاد بويب
| الأخير= West
| الأول= M. 
| مؤلف2-الأخير= McCann
| مؤلف2-الأول= S.  
| تاريخ= مارس 2006
| مسار أرشيف = https://web.archive.org/web/20120811041843/http://www.ietf.org/rfc/rfc4413| مسار= https://www.ietf.org/rfc/rfc4413
| عنوان=  RFC 4413,  TCP/IP Field Behavior
| موقع= The Internet Society
| صفحة = 22
| لغة= en
| تاريخ الوصول= 22 يوليو 2018| تاريخ أرشيف = 11 أغسطس 2012 }}</ref> تعتمد الآليّة على قيام المصدر بتوليد رزم بيانات بأطوال متغيرة مع رفع علم عدم التقطيع فيها، فإنّ لم يكن بالإمكان نقل الرزمة عبر شبكة ما بسبب حجمها يجري التخلص منها، ثُمّ إعلام المصدر بذلك عن طريق رسالة مُناسبة من رسائل بروتوكول التحكم في شبكة الإنترنت.<ref name="ietf-11"/>

إذا استخدم [[بروتوكول الإنترنت (الإصدار السادس)|الإصدار السادس من بروتوكول الإنترنت]] كبروتوكول شبكة، فإنّ آليّة الاكتشاف الخاصة به هي جزء مُدمج منه، ولابد من استعمالها قبل إرسال أي رزمة حتى لو كان المضيف المصدر يعتقد أن الوجهة موجودة في نفس [[شبكة محلية|الشبكة المحلية]]. تعتمد هذه الآلية على بروتوكول رسائل التحكم للإصدار السادس من بروتوكول الإنترنت،{{للهامش|2}} وبالتحديد رسالة «رزمة كبيرة جدًّا» والتي تُرسلها [[عقدة (شبكات)|عقدة]] ما على المسار، وتكون وجهة الرسالة هي مصدر رزمة بيانات لم تتمكن العقدة من إرسالها نحو الخطوة التالية على المسار، وذلك بسبب طولها، يجب على المصدر عندها أن يُعيد ضبط أطوال الرزم التي يُرسلها اعتمادًا على هذه ما جاء في هذه الرسالة.<ref name="ietf-12"/>
== التقطيع في طبقة النقل ==
إنّ التقطيع ليس وظيفة إلزامية لبروتوكولات [[طبقة النقل]]، ولكن يساعد إنجاز عملية تقطيع مناسبة في هذه الطبقة في المضيف المصدر على تجنب أي عمليات تقطيع لاحقة سواءً في الطبقات الدنيا من نموذج الشبكة المستعمل في المضيف المصدر، أو في عقد الشبكات على طول المسار، ويؤثر ذلك بشكل مباشر على الأداء.<ref name = "JOU-6">{{استشهاد بدورية محكمة
|الأخير= Genkov
|الأول= Delian
|مؤلف2-الأخير= Ilarionov
|مؤلف2-الأول= Raycho
|صحيفة = International Conference on Computer Systems and Technologies - CompSysTech’06
|عنوان= Avoiding IP Fragmentation at the Transport Layer of the OSI Reference Model
| تاريخ = يناير 2006
| مسار = http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.87.3395&rep=rep1&type=pdf
| مسار أرشيف = https://web.archive.org/web/20200325133118/http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.87.3395&rep=rep1&type=pdf | تاريخ أرشيف = 25 مارس 2020 }}</ref> يدعم [[بروتوكول التحكم بالنقل]] آلية لتقطيع حمولة وحدة البيانات، وتسمى الوحدات الجديدة الناتجة عن التقطيع و[[تغليف (شبكات)|التغليف]] قطعًا {{إنج|Segment}}،<ref name="ietf-21">{{استشهاد بويب
| الأخير= Postal
| الأول= J.
| تاريخ= سبتمبر 1981
| مسار= https://tools.ietf.org/html/rfc793
| عنوان= RFC 793, Transmission control protocol, DARPA internet program,protocol specification.
| موقع= The Internet Society
| لغة= en
| تاريخ الوصول= 22 يوليو 2017| مسار أرشيف = https://web.archive.org/web/20190505045142/https://tools.ietf.org/html/rfc793 | تاريخ أرشيف = 5 مايو 2019 }}</ref> في حين لا يقوم [[بروتوكول حزم بيانات المستخدم]] بعملية التقطيع، وعند استخدامه يجب أن تقوم التطبيقات بتوليد البيانات بشكل متقطع بطريقة يمكن من خلالها [[طبقة الشبكة|لطبقة الشبكة]] أن تقوم بتوليد رزم البيانات بناء على هذه القطع.<ref name="Web-8">{{استشهاد بويب
| مؤلف = James Curtis
| مسار أرشيف = https://web.archive.org/web/20170506212612/https://wand.net.nz/pubs/19/html/node6.html
| تاريخ أرشيف = 6 مايو 2017
| تاريخ = 17 يناير 2000
| مسار= https://wand.net.nz/pubs/19/html/node6.html
| عنوان= UDP vs TCP
| موقع= Wand
| لغة= en
| تاريخ الوصول= 29 يونيو 2018}}</ref>
=== التقطيع في بروتوكول التحكم بالنقل ===

في [[بروتوكول التحكم بالنقل]] هناك مفهوم خاص مُرتبط بالتقطيع هو مقاس القطعة الأعظمي {{إنج| Maximum Segment Size اختصاراً MSS}} وهو يحدد [[حمولة (حوسبة)|الحمولة]] أو حجم البيانات التي يمكن [[مضيف (حوسبة)|لمُضيف]] ما أن يستقبله ضمن قطعة واحدة، يجب الانتباه إلى أن [[ترويسة (حوسبة)|ترويسة]] بروتوكول التحكم بالنقل غير مُشمولة ضمن مقاس القطعة الأعظمي، على عكس و[[وحدة النقل العظمى]] الخاصة ب[[طبقة الشبكة]]، التي تشمل ترويسة بروتوكول الشبكة بالإضافة للحمولة في وحدة بيانات بروتوكول تلك الطبقة.<ref name="ietf-1">{{استشهاد بويب
| الأخير= Postel
| الأول= J.
| تاريخ= نوفمبر 1983
| مسار أرشيف = https://web.archive.org/web/20160308070820/http://www.ietf.org/rfc/rfc879| مسار= https://www.ietf.org/rfc/rfc879
| عنوان=  RFC 879, The TCP Maximum Segment Size and Related Topics
| صفحة = 2
| موقع= The Internet Society
| لغة= en
| تاريخ الوصول= 28 يوليو 2018| تاريخ أرشيف = 8 مارس 2016 }}</ref><ref name="Web-9">{{استشهاد بويب
| مؤلف =  Nurul Islam Roman
| مسار أرشيف = https://web.archive.org/web/20170517051329/https://blog.apnic.net/2014/12/15/ip-mtu-and-tcp-mss-missmatch-an-evil-for-network-performance/
| تاريخ أرشيف = 17 مايو 2017
| تاريخ = 15 ديسمبر 2014
| مسار= https://blog.apnic.net/2014/12/15/ip-mtu-and-tcp-mss-missmatch-an-evil-for-network-performance/
| عنوان= TCP Maximum Segment Size (MSS) and Relationship to IP Datagram Size
| موقع= APNIC
| لغة= en
| تاريخ الوصول= 28 يونيو 2018}}</ref>

إنّ اختيار مقاس القطعة الأعظمي الخاص ببروتوكول التحكم بالنقل يُؤثّر بشكل مباشر على عملية تقطيع [[رزمة بيانات|رزم البيانات]] في طبقة الشبكة، فإذا كانت القيمة كبيرة جدًّا، كان التقطيع في طبقة الشبكة إلزاميًّا، أمّا إذا كانت صغيرة جدًّا، فلا يحصل تقطيع أبدًا، ولكن الكلفة غير المباشرة لذلك ستكون باهظة ومُؤثّرة على فعاليّة الإرسال، بسبب وجود حمل إضافي كبير هو مجموع أطوال الترويسات المُضافة إلى الرزم الصغيرة.<ref name="ietf-4">{{استشهاد بويب
| الأخير= Ziemba
| الأول= G. 
| مؤلف2-الأخير=  Reed
| مؤلف2-الأول= D.
| مؤلف3-الأخير=  Traina
| مؤلف3-الأول= P.
| تاريخ= أوكتوبر 1995
| مسار أرشيف = https://web.archive.org/web/20200509163436/https://www.ietf.org/rfc/rfc1858
| مسار= https://www.ietf.org/rfc/rfc1858
| عنوان=  RFC 1858,  Security Considerations for IP Fragment Filtering
| موقع= The Internet Society
| لغة= en
| تاريخ الوصول= 1 يوليو 2018|تاريخ أرشيف=2020-05-09}}</ref> يتم التحكّم بمقاس القطعة الأعظمي في بروتوكول التحكم بالنقل بشكل آليّ لتكون مُتوافقة مع قيمة [[نافذة منزلقة|النافذة المنزلقة]] الخاصة بالاتصال الذي قام البروتوكول بإنشائه.<ref name="Web-5">{{استشهاد بويب
| مؤلف = Charles M. Kozierok
| مسار أرشيف = https://web.archive.org/web/20170111074031/http://www.tcpipguide.com/free/t_TCPMaximumSegmentSizeMSSandRelationshiptoIPDatagra.htm
| تاريخ أرشيف = 11 يناير 2017
| تاريخ = 20 سبتمبر 2005
| مسار= http://www.tcpipguide.com/free/t_TCPMaximumSegmentSizeMSSandRelationshiptoIPDatagra.htm
| عنوان= TCP Maximum Segment Size (MSS) and Relationship to IP Datagram Size
| موقع= TCP/IP Guide
| لغة= en
| تاريخ الوصول= 28 يونيو 2018}}</ref>

إنّ القيمة الافتراضية لمقاس القطعة الأعظمي هي (536) [[بايت]]،<ref name="ietf-2">{{استشهاد بويب
| الأخير= Postel
| الأول= J.
| تاريخ= نوفمبر 1983
| مسار أرشيف = https://web.archive.org/web/20160308070820/http://www.ietf.org/rfc/rfc879| مسار= https://www.ietf.org/rfc/rfc879#Page1
| عنوان=  RFC 879, The TCP Maximum Segment Size and Related Topics
| صفحة = 1
| موقع= The Internet Society
| لغة= en
| تاريخ الوصول= 28 يوليو 2018| تاريخ أرشيف = 8 مارس 2016 }}</ref> وهي تضبط بشكل مستقل لكل طرف، ويمكن التفاوض على قيمتها في الاتجاهين بين الطرفين عند إنشاء الاتصال، ولكن لا يمكن تغييرها بعد ذلك.<ref name="ietf-3">{{استشهاد بويب
| الأخير= Postal
| الأول= J.
| تاريخ= سبتمبر 1981
| مسار= https://tools.ietf.org/html/rfc793
| عنوان= RFC 793, Transmission control protocol, DARPA internet program,protocol specification.
| موقع= The Internet Society
| صفحة = 19
| لغة= en
| تاريخ الوصول= 28 يونيو 2018| مسار أرشيف = https://web.archive.org/web/20190505045142/https://tools.ietf.org/html/rfc793 | تاريخ أرشيف = 5 مايو 2019 }}</ref>
== التقطيع في طبقة الشبكة ==
{| class="wikitable floatleft" width="65%"
|-
|+ قيم وحدة النقل العظمى [[:تصنيف:بروتوكولات تشبيك|لبروتوكولات التشبيك]].{{للهامش|3}}
|-
! اسم البروتوكول !! اختصار !! حجم وحدة النقل العظمى الأعظمي (بايت) !! حجم وحدة النقل العظمى الأدنى (بايت) !!المرجع
|-
| [[بروتوكول الإنترنت (الإصدار الرابع)|الإصدار الرابع من بروتوكول الإنترنت]] || IPv4|| 65536 || 68 || <ref name="ietf-5"/>
|-
| [[بروتوكول الإنترنت (الإصدار السادس)|الإصدار السادس من بروتوكول الإنترنت]] || IPv6 || 65576 {{Refn|لم يرد ذكر الرقم بشكل صريح في معيار البروتوكول، ولكن يُمكن حسابه من مجموع الطول الأعظمي المسموح للحمولة وهو (65536) بايت، مع طول الترويسة (40) بايت. |group=lower-alpha}}|| 1280 || <ref name="ietf-9">{{استشهاد بويب
| الأخير= Deering
| الأول= S.
| مؤلف2-الأخير= Hinden
| مؤلف2-الأول= R.
| تاريخ= يوليو 2017
| مسار أرشيف = https://web.archive.org/web/20190626225115/https://tools.ietf.org/html/rfc8200| مسار= https://tools.ietf.org/html/rfc8200
| عنوان= RFC 8200, Internet Protocol, Version 6 (IPv6) Specification
| موقع= The Internet Society
| لغة= en
| تاريخ الوصول= 13 يوليو 2018| تاريخ أرشيف = 26 يونيو 2019 }}</ref>
|-
|}
{{يسار|'''مُلاحظات'''<br />{{مراجع|group=lower-alpha}}}}
{{شريط جانبي بروتوكول الإنترنت}}
إنّ تقطيع [[رزمة بيانات|رزم البيانات]] وإعادة تجميعها هو وظيفة رئيسية [[بروتوكول (اتصالات)|لبروتوكولات]] [[طبقة الشبكة|الشبكة]].<ref name="Web-64"/><ref name="Web-31">{{استشهاد بويب
| مؤلف = Charles M. Kozierok.
| مسار أرشيف = https://web.archive.org/web/20170730053649/http://www.tcpipguide.com/free/t_NetworkLayerLayer3.htm
| تاريخ أرشيف = 30 يوليو 2017
| تاريخ = 5 سبتمبر 2005
| مسار= http://www.tcpipguide.com/free/t_NetworkLayerLayer3.htm
| عنوان= Network Layer (Layer 3)
| موقع= The TCP/IP Guide
| لغة= en
| تاريخ الوصول= 22 يوليو 2018}}</ref> يدعم الإصداران الرابع<ref name="ietf-5">{{استشهاد بويب
| الأخير=  Postel
| الأول= J.
| تاريخ= سبتمبر 1981
| مسار أرشيف = https://web.archive.org/web/20190918221259/https://tools.ietf.org/html/rfc791| مسار= https://tools.ietf.org/html/rfc791
| عنوان=  RFC 791, Internet Protocol, DARPA Internet Program Protocol Specification
| موقع=The Internet Society
| لغة= en
| تاريخ الوصول= 1 يوليو 2018| تاريخ أرشيف = 18 سبتمبر 2019 }}</ref> والسادس<ref name="ietf-9"/> من بروتوكول الإنترنت تقطيع حمولة رزم البيانات التي يتجاوز طولها قيمة محددة، إلى قطع تُستعمل لإنشاء رزم بيانات ذات أطوال أصغر من الرزمة الأصلية. تمرر الرزم المُقطعة إلى [[طبقة ربط البيانات]] ليصار إلى تغليفها وإنشاء [[إطار البيانات|أطر البيانات]].

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

يكون تقطيع [[رزمة بيانات]] [[بروتوكول الإنترنت (الإصدار الرابع)|الإصدار الرابع من بروتوكول الإنترنت]] {{إنج|IP Fragmentation}} ضروريًّا عندما يتم توليدها في [[شبكة محلية]] أُولى تسمح بحجم كبير [[وحدة النقل العظمى|لوحدة النقل العظمى]] الخاصة [[طبقة الشبكة|بطقبة الشبكة]]، لكنّ مسار الرزمة يقطع شبكة ثانية يكون حجم وحدة النقل العظمى فيها أصغر بالقيمة، وعندها لابد من تقطيع الرزمة في عقدة ما على المسار من أجل أن تصل إلى وجهتها. نتيجة لذلك، يتم توليد رزم بيانات بأطوال أصغر من طول الرزمة الأصلية.<ref name = "Book-6">{{استشهاد بكتاب
|مؤلف1= Shivendra Panwar, Shivendra S. Panwar, Shiwen Mao, Jeong-dong Ryoo, Yihan Li
|عنوان= TCP/IP Essentials: A Lab-Based Approach
|صفحة=101
|سنة= 2014
|ناشر= Cambridge University Press
|ردمك= 0521841445
|لغة= en
}}</ref>

يمكن أن تحصل عملية تقطيع الرزم في المُضيف المصدر الذي يُولّدها، أو في أي عقدة على مسارها نحو وجهتها، ويدعم البروتوكول أيضًا مفهوم التقطيع المتعدد، أي يمكن أن يتم تقطيع رزمة البيانات أكثر من مرة عبر مسارها، ولكن لا يمكن إعادة تجميع الرزمة الأصلية إلا في الوجهة النهائية.<ref name="Web-13"/>

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

[[ملف:IPv4 Packet-ar.svg|تصغير|300بك|[[رزمة بيانات]] [[بروتوكول الإنترنت (الإصدار الرابع)|الإصدار الرابع من بروتوكول الإنترنت]] (IPv4)، ويمكن تبين الحقول المرتبطة بعملية التقطيع وهي حقول مُعرّف القطعة والأعلام وإزاحة القطعة.]]
[[ملف:IPv4 Fragmentation Flag field-ar.svg|تصغير|300بك|حقل الأعلام في ترويسة الإصدار الرابع من بروتوكول الإنترنت، هناك علمين هما علم عدم التقطيع وعلم المزيد من القطع.]]

تتكون [[ترويسة (حوسبة)|ترويسة]] [[بروتوكول الإنترنت (الإصدار الرابع)|الإصدار الرابع من بروتوكول الإنترنت]] من 14 حقلًا،<ref name="ietf-5"/> لا ترتبط جميعها بعملية التقطيع. الحقول المُرتبطة بعملية التقطيع هي حقل مُعرّف القطعة، وحقل الأعلام وحقل الإزاحة، كما تتأثر قيمة حقلي الطول الإجمالي والتحقق الجمعي بعملية التقطيع وتختلف قيمتها في القطع عن قيمتها في الرزمة الأصلية،<ref name="Web-63">{{استشهاد بويب
| مؤلف = Joshua Johnson
| مسار أرشيف = https://web.archive.org/web/20180730005606/https://learningnetwork.cisco.com/thread/70817
| تاريخ أرشيف = 30 يوليو 2017
| تاريخ = 17 مايو 2014
| مسار= https://learningnetwork.cisco.com/thread/70817
| عنوان= Describe the IP Packet Header and each field in a Traffic Capture
| موقع= Cisco Systems, Inc.
| لغة= en
| تاريخ الوصول= 30 يوليو 2018}}</ref> بعض الخيارات تُنسخ لكل قطعة، وبعضها لا يُنسخ إلا للقطعة الأولى، ويتحدد ذلك بعلم خاص هو علم النسخ {{إنج|Copied flag}} الذي يوجد في بداية كل خيار.<ref name="Web-62">{{استشهاد بويب
| مسار أرشيف = https://web.archive.org/web/20170216042759/http://www.rhyshaden.com/ipdgram.htm
| تاريخ أرشيف = 16 فبراير 2017
| مسار= http://www.rhyshaden.com/ipdgram.htm
| عنوان= The IP Datagram
| موقع= Rhys Haden
| لغة= en
| تاريخ الوصول= 30 يوليو 2018}}</ref>

يمكن [[مضيف (حوسبة)|للمضيف]] المصدر أن يُؤشّر الرزم التي لا يريدها أن تُقطّع برفع علم عدم التقطيع، في هذه الحالة لا يتم تقطيع الرزمة أبدًا، وفي حال تعذّر إيصال الرزمة بدون تقطيعها، فسيتم التخلص منها.<ref name="Web-36">{{استشهاد بويب
| مؤلف = Geoff Huston
| مسار أرشيف = https://web.archive.org/web/20180425142248/https://labs.ripe.net/Members/gih/evaluating-ipv4-and-ipv6-packet-fragmentation
| تاريخ أرشيف =25 أبريل 2018
| تاريخ = 29 يناير 2016
| مسار= https://labs.ripe.net/Members/gih/evaluating-ipv4-and-ipv6-packet-fragmentation
| عنوان= Evaluating IPv4 and IPv6 Packet Fragmentation

| موقع= Réseaux IP Européens Network Coordination Centre RIPE NCC
| لغة= en
| تاريخ الوصول= 22 يوليو 2018}}</ref> إذا تمّ تقطيع رزمة البيانات في المصدر أو في أي عقدة على المسار فلابد من إعادة تجميع القطع الناتجة في المُضيف الوجهة، ولا يتمّ تجميع قطع الرزمة في أي [[عقدة (شبكات)|عقدة]] على المسار. يُستخدم حقل المُعرّف لتمييز رزمة البيانات الأصلية وجميع القطع الناتجة عن عملية التقطيع، ويقوم المُضيف الوجهة باستعمال هذا الحقل للتمييز بين مجموعات القطع الناتجة عن تقطيع رزم بيانات مختلفة بغرض إعادة تجميعها.<ref name="ietf-24">{{استشهاد بويب
| الأخير= Touch
| الأول= J.  
| تاريخ= فبراير 2013
| مسار أرشيف = https://web.archive.org/web/20200509163438/https://www.ietf.org/rfc/rfc6864
| مسار= https://www.ietf.org/rfc/rfc6864
| عنوان=  RFC 6864, Updated Specification of the IPv4 ID Field
| موقع= The Internet Society
| صفحة = 22
| لغة= en
| issn= 2070-1721
| تاريخ الوصول= 22 يوليو 2018|تاريخ أرشيف=2020-05-09|url-status=dead}}</ref>

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

حقول ترويسة البروتوكول المُستخدمة في عملية التقطيع:<ref name="ietf-5"/>
* '''حقل مُعرّف القطعة'''، طوله 16 بت ويحتوي على قيمة فريدة تُعرف رزمة البيانات الأصلية وجميع القطع الناتجة عن تقطيعها، وهو يستخدم في عملية إعادة التجميع لتمييز قطع الرزم الأصلية عن قطع بقية الرزمة.<ref name="ietf-24"/>
* '''حقل الأعلام'''، طوله 3 بت مقسم بالشكل التالي:
** '''البت 0'''، محجوز، لا يُستخدم، قيمته دائمًا هي 0.
** '''البت 1'''، علم عدم التقطيع {{إنج|Do not Fragment Flag اختصاراً DF}}، يستخدم من قبل مصدر الرزمة للإشارة إلى ضرورة عدم تقطيع الرزمة،<ref name="Web-33">{{استشهاد بويب
| مؤلف = Sean Wilkins
| مسار أرشيف = https://web.archive.org/web/20170327015623/http://www.pearsonitcertification.com/articles/article.aspx?p=1843887
| تاريخ أرشيف =27 مارس 2017
| تاريخ = 29 فبراير 2012
| مسار= https://www.pearsonitcertification.com/articles/article.aspx?p=1843887
| عنوان= Anatomy of an IPv4 Packet
| موقع= Pearson Education, Pearson IT Certification
| لغة= en
| تاريخ الوصول= 22 يوليو 2018}}</ref> تقوم الموجهات على كامل مسار الرزمة بالالتزام بذلك، وإذا كانت قيمة هذا البت مساوية للواحد، فلن يتم تقطيع الرزمة أبدًا حتى لو أدى ذلك إلى التخلص منها لعدم إمكانية توجيهها.<ref name="Web-36"/>
** '''البت 2'''، علم المزيد من القطع {{إنج|More Fragment Flag اختصاراً MF}} يستخدم لتمييز القطعة الأخيرة، إذا كانت قيمته 1 فهذا يعني أن هناك قطع أخرى نتجت بعد هذه القطعة من عملية تقطيع الرزمة الأصلية، أما إذا كانت قيمته 0، فهذا يعني أن هذه القطعة هي آخر قطعة نتجت عن عملية تقطيع الرزمة.
* '''حقل إزاحة القطعة'''، طوله 13 بت، ويحتوي على قيمة تدل على موقع القطعة النسبي بالنسبة لبقية القطع في الرزمة الأصلية، تكون قيمة الإزاحة مقسومة على ثمانية، أي إذا احتوى الحقل القيمة 1 فإن قيمة الإزاحة الحقيقية هي 8 بايت، وإذا احتوى 2 فإن قيمة الإزاحة الحقيقية هي 16، وأكبر قيمة ممكن للإزاحة في هذا الحقل هي: 2<sup>13</sup>=8192، وتقابل 65536 بايت.<ref name = "Book-5">{{استشهاد بكتاب
|مؤلف1= Toni Janevski
|عنوان= Internet Technologies for Fixed and Mobile Networks
|صفحة= 33
| طبعة= الأولى
|سنة= 2015
|ناشر= Artech House
|ردمك= 9781608079216
|لغة= en
}}</ref>

يجب عدم الخلط بين حقلي المُعرّف وإزاحة القطعة في ترويسة بروتوكول الإنترنت، فحقل المُعرّف هو قيمة مميزة تُعرّف بشكلٍ فريد رزمة البيانات الأصلية وكل القطع الناتجة عن عملية التقطيع سواء تم كمرحلة واحدة أو كان متعددًا، أما حقل الإزاحة فهو يمثل الموقع النسبي للقطعة الناتجة بالنسبة لبقية القطع ضكن رزمة البيانات الأصلية.<ref name="Web-11">{{استشهاد بويب
| مسار أرشيف = https://web.archive.org/web/20180701083420/https://learningnetwork.cisco.com/thread/123816
| تاريخ أرشيف = 1 يوليو 2018
| تاريخ = 27 يناير 2018
| مسار= https://learningnetwork.cisco.com/thread/123816
| عنوان= Identification vs Fragment Offset
| موقع= Cisco Systems, Inc.
| لغة= en
| تاريخ الوصول= 1 يوليو 2018}}</ref>

==== خوارزمية التقطيع ====
[[ملف:IPv4 Fragmentation Algorithm-ar.svg|تصغير|300بك|خوارزمية تقطيع رزم البيانات في [[بروتوكول الإنترنت (الإصدار الرابع)|الإصدار الرابع من بروتوكول الإنترنت]].]]
وصفت [[خوارزمية]] التقطيع في محددات البروتوكول، وهي تتبع المراحل التالية:<ref name="ietf-5"/>
# تحديد طول الرزمة ومقارنته مع وحدة النقل العظمى الخاصّة بالشبكة التي سيتم توجيه الرزمة إليها:
## إذا كان طول الرزمة أكبر من وحدة النقل العظمى، يجب أن يتم تقطيع الرزمة.
## إذا كان طول الرزمة أصغر أو يساوي وحدة النقل العظمى يتم إرسال الرزمة كما هي إلى المرحلة التالية من التغليف.
# إذا كان علم عدم التقطيع في الرزمة مرفوعًا، يتمّ التخلّص من الرزمة.
# يجري تحديد حجم حمولة القطعة بحسب وحدة النقل العظمى وطول ترويسة بروتوكول الإنترنت.
# يتم اقتطاع حمولة القطعة من حمولة الرزمة الأصلية.
# يتم بناء ترويسة القطعة، ويشمل ذلك:
## حساب طول ترويسة القطعة وإضافته إلى الحقل المخصص.
## حساب طول القطعة الإجمالي وإضافته إلى الحقل المخصص.
## تحديد زمن حياة القطعة.
## ضبط قيمة مُعرّف القطعة إلى قيمة مُعرّف الرزمة الأصلية.
## تحديد قيمة الإزاحة، وإضافتها إلى الحقل المخصص.
## تحديد قيمة العلمين. وإضافتهما إلى الحقل المخصص.
## حساب قيمة حقل التحقق الجمعي.
# توليد الرزمة الجديدة من خلال تغليف قطعة البيانات بالترويسة.
# تحديد فيما إذا كانت الرزمة الناتجة هي الرزمة الأخيرة بقراءة قيمة علم المزيد من القطع:
## إذا كانت الرزمة الناتجة هي الرزمة الأخيرة، يتم إرسالها إلى المرحلة التالية من التغليف.
## إذا لم تكن الرزمة الناتجة هي الرزمة الأخيرة، يتم إعادة تنفيذ الخوارزمية بدءًا من الخطوة الثالثة، مع اعتبار أن حجم حمولة الرزمة الأصلية هو الحجم المتبقي من عملية الاقتطاع السابقة.

أما عملية إعادة التجميع، فهي تجري بشكل معاكس، وهناك عدة خوارزميات لإنجازها، جرى مناقشتها في وثيقة طلب التعليقات RFC 815.<ref name="ietf-105">{{استشهاد بويب
| الأخير=  D. Clark
| الأول= David 
| تاريخ= يوليو 1982
| مسار أرشيف = https://web.archive.org/web/20200507010603/https://tools.ietf.org/html/rfc815 
| مسار= https://tools.ietf.org/html/rfc815
| عنوان= RFC 815, IP DATAGRAM REASSEMBLY ALGORITHMS
| موقع= The Internet Society
| لغة= en
| doi = 10.17487/RFC0815
| تاريخ الوصول= 9 يونيو 2019|تاريخ أرشيف=2020-05-07}}</ref>

==== قضايا أمنية ====
طوّر [[مخترق|المهاجمون]] عدد من الهجمات التي تعتمد على التقطيع أو [[ثغرة أمنية (حوسبة)|ثغرة أمنية]] قد تنتج عن استخدامه، من هذه الهجمات:
* '''هجوم القطعة الصغيرة''' {{إنج|Tiny Fragment Attack}}<ref name="ietf-25">{{استشهاد بويب
| الأخير= Miller
| الأول= I.  
| تاريخ= يونيو 2001
| مسار أرشيف = https://web.archive.org/web/20120811124557/http://www.ietf.org/rfc/rfc3128| مسار= https://www.ietf.org/rfc/rfc3128
| عنوان=  RFC 3128, Protection Against a Variant of the Tiny Fragment Attack
| موقع= The Internet Society
| صفحة = 22
| لغة= en
| تاريخ الوصول= 22 يوليو 2018| تاريخ أرشيف = 11 أغسطس 2012 }}</ref> يعتمد هذا الهجوم على حقيقة أن أصغر [[رزمة بيانات]] يمكن لأي وحدة تدعم [[بروتوكول الإنترنت (الإصدار الرابع)|الإصدار الرابع من بروتوكول الإنترنت]] التعامل معها هي بطول 68 [[بايت]]، حيث تكون [[ترويسة (حوسبة)|ترويسة]] بروتوكول الإنترنت بأقصى طول أعظمي مسموح لها، وهو 60 بايت، في حين تكون [[حمولة (حوسبة)|الحمولة]] بطول 8 بايت فقط،<ref name="ietf-5"/> لا يكفي هذا الطول لإدراج ترويسة بروتوكول [[طبقة النقل|النقل]] ضمن الرزمة، وقد يحاول المُهاجم تمرير قطعة خبيثة من [[جدار حماية (حوسبة)|جدار الحماية]]، الذي يتفحص عادة [[مقبس (شبكات)|أرقام المنافذ]] في طبقة النقل، على أساس أنها قطعة صغيرة من رزمة بيانات أكبر جرى تقطيعها.
* '''هجوم القطع المتراكبة''' {{إنج|Overlapping Fragment Attack}}<ref name="Web-38">{{استشهاد بويب
| مسار أرشيف = https://web.archive.org/web/20170211105219/http://www.datacomsystems.com/news-events/news/2015/nov/3/explore-new-firmware-that-s-helping-organizations-see-attacks-as-they-happen
| تاريخ أرشيف =11 فبراير 2017
| تاريخ = 3 نوفمبر 2015
| مسار= https://www.datacomsystems.com/news-events/news/2015/nov/3/explore-new-firmware-that-s-helping-organizations-see-attacks-as-they-happen
| عنوان= Explore new firmware that’s helping organizations see attacks as they happen.

| موقع= Datacom
| لغة= en
| تاريخ الوصول= 22 يوليو 2018|url-status=dead}}</ref> يعتمد هذا الهجوم على [[خوارزمية]] إعادة التجميع المُتبعة لإعادة تشكيل الرزمة الأصلية، حيث يمكن لأي قطعة تالية أن تتراكب مع قطعة أخرى سابقة، وتحل محلها جزئيًّا أو كليًّا، ويعني ذلك وجود ثغرة أمنية، حيث بالإمكان تمرير القطعة الأولى، التي تحتوي ترويسة بروتوكول الإنترنت من جدار الحماية بشكل شرعي، ثُمّ التلاعب بقيمتها عن طريقة التراكب مع قطعة تالية.<ref name = "JOU-8">{{استشهاد بدورية محكمة
|الأخير= H. Ptacek
|الأول= Thomas
|مؤلف2-الأخير= N. Newsham
|مؤلف2-الأول= Timothy
|صحيفة = Computer Systems Management and Standards
|عنوان= Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection
| تاريخ = يناير 1998
|صفحة= 46-52
| ناشر = DEFENSE TECHNICAL INFORMATION CENTER
| مسار = https://apps.dtic.mil/dtic/tr/fulltext/u2/a391565.pdf
| مسار أرشيف = https://web.archive.org/web/20170812174412/http://dtic.mil/dtic/tr/fulltext/u2/a391565.pdf | تاريخ أرشيف = 12 أغسطس 2017 }}</ref> على الرغم من التحسينات التي طرأت على خوارزمية إعادة التجميع، إلا أن الوثائق المعيارية للخوارزمية لم تتناول هذا الهجوم.<ref name="ietf-6">{{استشهاد بويب
| الأخير= D. Clark
| الأول= David
| تاريخ= يوليو 1982
| مسار أرشيف = https://web.archive.org/web/20190328194357/https://tools.ietf.org/html/rfc815| مسار= https://tools.ietf.org/html/rfc815
| عنوان=  RFC 815, IP DATAGRAM REASSEMBLY ALGORITHMS
| موقع=The Internet Society
| لغة= en
| تاريخ الوصول= 1 يوليو 2018| تاريخ أرشيف = 28 مارس 2019 }}</ref>

نُوقشت هذه الهجمات وطريقة التصدي لكل منها بالتفصيل في [[طلب تعليقات|وثيقة طلب التعليقات]] RFC 1858.<ref name="ietf-4"/>

==== أمثلة ====
[[ملف:IP Fragmentation example - ar.png|تصغير|300بك|مثال عن عملية التقطيع المتعدد في الإصدار الرابع من بروتوكول الإنترنت. يحصل التقطيع على مرحلتين في الأولى تكون وحدة النقل العظمى 4000 [[بايت]]، وفي الثانية 2500 بايت.<ref name="Web-15"/>]]
في هذا المثال، يُفترض أن طول [[ترويسة (حوسبة)|ترويسة]] [[بروتوكول الإنترنت (الإصدار الرابع)|الإصدار الرابع من بروتوكول الإنترنت]] هي 20 [[بايت]]، أي لا يوجد أي خيارات إضافية. إنّ قيمة [[وحدة النقل العظمى]] الخاصة ب[[طبقة الشبكة]] هو 1500 بايت، ويجري التقطيع على مرحلة واحدة فقط [[رزمة بيانات|لرزمة بيانات]] طولها الإجمالي هو 5140 بايت، أي أنها مكونة من [[حمولة (حوسبة)|حمولة]] هي 5120 وترويسة هي 20 بايت وقيمة المُعرّف في ترويسة بروتوكول الإنترنت فيها هو 345.<ref name="Web-3"/>

إنّ حجم الحمولة الأكثر مُلائمة لحجم وحدة النقل العظمى هو 1480 بايت، وهو يسمح بتشكيل رزمة بيانات ذات طول مُطابق تمامًا لحجم وحدة النقل العظمى من خلال [[تغليف (شبكات)|تغليف]] الحمولة 1480 بترويسة البروتوكول 20، ليكون طول الرزمة الأولى الإجمالي هو 1500 بايت، وإزاحتها هي 0 لأنّها تحتوي على القطعة الأولى،<ref name="Web-36"/> ويجب أن يضبط علم المزيد من القطع إلى القيمة 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))، بينما تكون قيم بقية الحقول الخاصة بالتقطيع في الترويسة مُطابقة للقيم في ترويسات الرزم السابقة.

{| class="wikitable " width="100%"
|-
|+ جدول بقيم حقول الترويسات في الرزمة الأصلية قبل التقطيع وفي الرزم الناتجة عن التقطيع.
|-
! colspan="6"| بعض حقول ترويسة الرزمة الأصلية قبل التقطيع
|-
! - !! حقل مُعرف القطعة !! حقل الطول الإجمالي (بايت) !! علم عدم التقطيع !! علم المزيد من القطع !! حقل الإزاحة
|-
| align="center" |- || align="center"| 345 || align="center"|5140|| align="center"|0 || align="center"|0 || align="center"|0
|-
! colspan="6"| بعض حقول ترويسات الرزم الناتجة عن التقطيع
|-
! رقم القطعة !! حقل مُعرف القطعة !! حقل الطول الإجمالي (بايت) !! علم عدم التقطيع !! علم المزيد من القطع !! حقل الإزاحة
|-
| align="center" |1 || align="center"| 345 || align="center"|1500|| align="center"|1 || align="center"|1 || align="center"|0
|-
| align="center"|2 || align="center"|345 || align="center"|1500|| align="center"|1 || align="center"|1 || align="center"|185
|-
| align="center"|3 || align="center"|345 || align="center"|1500|| align="center"|1 || align="center"|1 || align="center"|370
|-
| align="center"|4 || align="center"|345 || align="center"|700 || align="center"|1 || align="center"|0 || align="center"|555
|}

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

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

إن تقطيع [[رزمة بيانات|رزم البيانات]] التي يتجاوز طولها قيمة محددة [[وحدة النقل العظمى|بوحدة النقل العظمى]] [[طبقة الشبكة|لطبقة الشبكة]] هي وظيفة أساسيّة [[بروتوكول الإنترنت (الإصدار السادس)|للإصدار السادس من بروتوكول الإنترنت]].<ref name="ietf-9"/> بشكلٍ مشابه للإصدار الرابع من بروتوكول الإنترنت، يقوم الإصدار السادس بتقطيع [[حمولة (حوسبة)|حمولة]] رزمة بيانات لإنقاص طولها، وينتج عن ذلك مجموعة من القطع التي تستعمل لتنتج رزم بيانات جديدة، أطوالها أقل أو تساوي قيمة وحدة النقل الأعظيمة. ولكن على عكس الإصدار الرابع من بروتوكول الإنترنت، في الإصدار السادس، لا يحدث التقطيع إلا في [[مضيف (حوسبة)|المُضيف]] المصدر فقط، ولا تقوم [[موجه (شبكات)|المُوجّهات]] بتقطيع رزمة بيانات الإصدار السادس تحت أي ظرف،<ref name="Web-27">{{استشهاد بويب
| مؤلف = Matt Conran
| مسار أرشيف = https://web.archive.org/web/20180102061631/http://network-insight.net/2015/10/ipv6-fragmentation/
| تاريخ أرشيف = 2 يناير 2018
| تاريخ = 16 أوكتوبر 2018
| مسار= https://network-insight.net/2015/10/ipv6-fragmentation/
| عنوان= IPV6 FRAGMENTATION
| موقع= Technology Focused Hub PS Delivery ltd
| لغة= en
| تاريخ الوصول= 20 يوليو 2018}}</ref> لذلك فإن معرفة وحدة النقل العظمى للمسار هي عملية ذات أهمية خاصة في البروتوكول، وإذا لم يتمكن البروتوكول من تحديدها فإنّه يعتمد أدنى طول مسموح لرزمة البيانات وهو 1260 [[بايت]].<ref name="Web-20">{{استشهاد بويب
| مؤلف = Phillip Remaker
| مسار أرشيف = https://web.archive.org/web/20160919073320/https://blogs.cisco.com/enterprise/ipv6-mtu-gotchas-and-other-icmp-issues
| تاريخ أرشيف = 19 سبتمبر 2016
| تاريخ = 21 مارس 2011
| مسار= https://sun.iwu.edu/~jhaefner/CS390/Lecture13/lec13.htm
| عنوان= IPv6 MTU Gotchas and other ICMP issues
| موقع= Cisco Systems, Inc
| لغة= en
| تاريخ الوصول= 17 يوليو 2018}}</ref>

==== ترويسة القطعة ====
[[ملف:Fragment header structure-ar.svg|تصغير|300بك|[[ترويسة (حوسبة)|ترويسة]] القطعة الخاصة ب[[بروتوكول الإنترنت (الإصدار السادس)|الإصدار السادس من بروتوكول الإنترنت]].]]
[[ملف:IPv6 Fragmentation algorithm-ar.svg|تصغير|300بك| مخطط تدقفي يبين خوارزمية عملية التقطيع في الإصدار السادس من بروتوكول الإنترنت.]]
[[ملف:IPv6 Fragmentation Concept-ar.svg|تصغير|300بك|المبدأ العام للتقطيع في الإصدار السادس من بروتوكول الإنترنت.]]
[[ملف:Reassemled packet-ar.svg|تصغير|300 بك|بنية رزمة بيانات الإصدار السادس من بروتوكول الإنترنت الناتجة عن إعادة تجميع القطع في المضيف الوجهة.]]
لا تحتوي [[ترويسة (حوسبة)|ترويسة]] البروتوكول الأساسية على حقول خاصة بعملية التقطيع، ولكن هناك ترويسة أخرى خاصة بالتقطيع تسمى ترويسة القطعة {{إنج| Fragment Header}} يقوم البروتوكول بإضافتها في حال تقطيع الرزمة، إذا أضيفت هذه الترويسة بعد الترويسة الأساسية، يحب أن تكون قيمة حقل «الترويسة التالية» في ترويسة البروتوكول الأصلية مضبوطة إلى القيمة 44.<ref name="Web-21">{{استشهاد بويب
| مسار أرشيف = https://web.archive.org/web/20180104065343/https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
| تاريخ أرشيف = 4 يناير 2018
| مسار= https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
| عنوان= Protocol Numbers
| موقع= IANA
| لغة= en
| تاريخ الوصول= 18 يوليو 2018}}</ref>

يبلغ طول ترويسة القطعة 8 [[بايت]]، وتتألف من 6 حقول، هي بحسب ترتيب وردوها:<ref name="ietf-9"/>
* '''حقل الترويسة التالية''' 8 [[بت]]، ويضبط بشكل مشابه لحقل الترويسة التالية في ترويسة البروتوكول الأصلية.
* '''حقل محجوز''' 8 بت، يضبط إلى القيمة 0 عند الإرسال.
* '''حقل إزاحة القطعة''' 13 بت، يحتوي على موقع حمولة القطعة النسبي ضمن حمولة الرزمة الأصلية، وتعبر قيمة الرقم الموجود عن الإزاحة بواحدة هي 8 بايت، فإذا كانت قيمة هذا الحقل مثلًا هي 2، فإن إزاحة القطعة الحقيقية هي 16 بايت.
* '''حقل محجوز''' 2 بت، يُضبط إلى القيمة 0 عند الإرسال.
* '''علم المزيد من القطع''' 1 بت، ويستخدم للدلالة على القطعة الأخيرة، إذا كانت قيمته 1، فهذا يعني أن هناك قطع لاحقة نتجت عن عملية التقطيع، أما إذا كانت قيمته 0 فذلك يعني بأن هذه القطعة هي القطعة الأخيرة.
* '''حقل مُعرّف القطعة''' 32 بت، وهي يحتوي قيمة فريدة تميّز الرزمة الأصلية وجميع القطع التي نتجت عن تقطيعها. هناك عدة [[خوارزمية|خوارزميات]] لاختيار قيمة المعرّف بحيث يكون فريدًا وآمنًا، وهي موصوفة في [[طلب تعليقات|وثيقة طلب التعليقات]] RFC 7739.<ref name="ietf-17">{{استشهاد بويب
| الأخير= Gont
| الأول= F.
| تاريخ= فبراير 2016
| مسار أرشيف = https://web.archive.org/web/20200509163440/https://www.ietf.org/rfc/rfc7739
| مسار= https://www.ietf.org/rfc/rfc7739
| عنوان=  RFC 7739, Security Implications of Predictable Fragment Identification Values
| موقع= The Internet Society
| لغة= en
| issn = 2070-1721
| تاريخ الوصول= 17 يوليو 2018|تاريخ أرشيف=2020-05-09|url-status=dead}}</ref>

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

تتألف [[رزمة بيانات]] [[بروتوكول الإنترنت (الإصدار السادس)|الإصدار السادس من بروتوكول الإنترنت]] من [[ترويسة (حوسبة)|ترويسة]] البروتوكول الأساسية، ومجموعة من التوسيعات التي تشمل خيارات إضافية أو ترويسات مُحددة لابد من معالجتها في كل عقدة على المسار، بالإضافة إلى قسم [[حمولة (حوسبة)|الحمولة]] الذي يضمّ ترويسات الطبقات العليا، ويكون التقطيع إلزاميًا عندما يتجاوز طول الرزمة قيمة [[وحدة النقل العظمى]]، والتي غالبًا ما تكون وحدة النقل العظمى الدنيا للمسار الذي ستسلكه رزمة البيانات، بخلاف ذلك، تُضبط القيمة بشكلٍ آلي القيمة الدنيا المدعومة لوحدة النقل العظمى في أسوء الحالات وهي 1280 بايت.<ref name="Web-24">{{استشهاد بويب
| مؤلف = Geoff Huston
| مسار أرشيف = https://web.archive.org/web/20170505113340/https://labs.ripe.net/Members/gih/fragmenting-ipv6
| تاريخ أرشيف = 5 مايو 2017
| تاريخ = 19 مايو 2016
| مسار= https://labs.ripe.net/Members/gih/fragmenting-ipv6
| عنوان= Fragmenting IPv6
| موقع= Réseaux IP Européens Network Coordination Centre RIPE NCC
| لغة= en
| تاريخ الوصول= 18 يوليو 2018}}</ref> وُصفت خوارزمية التقطيع في [[طلب تعليقات|وثيقة طلب التعليقات]] الخاصة بالبروتوكول.<ref name="ietf-9"/>

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

بشكلٍ عام تنتج عن عملية التقطيع ثلاث حالات مختلفة:<ref name="Web-23">{{استشهاد بويب
| مؤلف = Charles M. Kozierok
| مسار أرشيف = https://web.archive.org/web/20170910013529/http://www.tcpipguide.com:80/free/t_IPv6DatagramSizeMaximumTransmissionUnitMTUFragment-4.htm
| تاريخ أرشيف = 10 سبتمبر 2017
| تاريخ = 20 سبتمبر 2005
| مسار= http://www.tcpipguide.com/free/t_IPv6DatagramSizeMaximumTransmissionUnitMTUFragment-4.htm
| عنوان= IPv6 Datagram Size, Maximum Transmission Unit (MTU), Fragmentation and Reassembly
| موقع= The TCP/IP Guide
| لغة= en
| تاريخ الوصول= 18 يوليو 2018}}</ref>
* '''الرزمة الأولى''': وتضم ترويسة البروتوكول والتوسيعات والترويسات الإضافية بالإضافة لترويسة القطعة، والقطعة الأولى من الحمولة، والتي تضم ترويسات الطبقات العليا،<ref name="Web-22">{{استشهاد بويب
| مؤلف = Bill Cerveny
| مسار أرشيف = https://web.archive.org/web/20180626001504/https://asert.arbornetworks.com/ipv6-fragmentation/
| تاريخ أرشيف = 26 يونيو 2018
| تاريخ = 25 يوليو 2011
| مسار= https://www.netscout.com/blog/asert/ipv6-fragmentation
| عنوان= IPv6 Fragmentation
| موقع= ARBOR NETWORKS, INC.
| لغة= en
| تاريخ الوصول= 18 يوليو 2018}}</ref> ويكون الطول الكليّ مُطابقًا أو قريبًا من طول وحدة النقل العظمى. يكون مُعرّف هذه الرزمة مُطابقًا لمعرف الرزمة الأصلية، ويُرفع فيها علم المزيد من القطع وتكون إزاحتها مساوية للصفر.<ref name="Web-36"/>
* '''رزم وسطيّة''': تظهر الرزم الوسطية إذا كان عدد القطع التانجة أكثر من اثنين، تضم الرزمة الوسطية ترويسة البروتوكول والتوسيعات وترويسة القطعة، وقطعة من الحمولة، ويكون الطول الكلي مُطابقًا أو قريبًا من طول وحدة النقل الأعظميّة. يكون مُعرّف هذه الرزمة مطابقًا لمعرف الرزمة الأصلية، ويُرفع فيها علم المزيد من القطع وتختلف قيمة الإزاحة فيها بحسب الموقع النسبي لقطعة الحمولة في الرزمة الأصلية.
* '''الرزمة الأخيرة''': وتضمّ ترويسة البروتوكول والتوسيعات وترويسة القطعة، وآحر قطعة من الحمولة، ويكون مُعرّف هذه الرزمة مُطابقًا لمعرف الرزمة الأصلية، ولا يُرفع فيها علم المزيد من القطع،<ref name="Web-30">{{استشهاد بويب
| مؤلف = Charles M. Kozierok.
| مسار أرشيف = https://web.archive.org/web/20180102061631/http://network-insight.net/2015/10/ipv6-fragmentation/
| تاريخ أرشيف = 11 يوليو 2017
| تاريخ = 5 سبتمبر 2005
| مسار= http://www.tcpipguide.com/free/t_IPv6DatagramExtensionHeaders-5.htm
| عنوان= IPV6 FRAGMENTATION
| موقع= The TCP/IP Guide
| لغة= en
| تاريخ الوصول= 20 يوليو 2018}}</ref> وتضبط قيمة الإزاحة فيها بحسب الموقع النسبي لقطعة الحمولة في الرزمة الأصلية. وليس بالضرورة أن يكون طول الرزمة الأخيرة الكلي مُطابقًا أو قريبًا من طول وحدة النقل العظمى، وغالبًا ما تكون ذات حجم صغير غير مناسب.<ref name="Web-37"/>

==== قضايا أمنية ====

ينتج عن استخدام التقطيع في [[بروتوكول الإنترنت (الإصدار السادس)|الإصدار السادس من بروتوكول الإنترنت]] عدد من [[ثغرة أمنية (حوسبة)|الثغرات أمنيّة]] التي قد تستخدم لشن هجمات مثل هجوم القطعة الصغيرة أو هجوم القطع المتراكبة، وتختلف إمكانية شن الهجمات بحسب [[نظام تشغيل|نظام التشغيل]] الذي يستعمل البروتوكول.<ref name = "JOU-9">{{استشهاد بدورية محكمة
|الأخير= Atlasis
|الأول= Antonios
|صحيفة = Black-Hat Europe
|عنوان= Attacking IPv6 Implementation Using Fragmentation
|سنة= 2002
| مسار = https://docs.huihoo.com/blackhat/europe-2012/bh-eu-12-Atlasis-Attacking_IPv6-WP.pdf
| مسار أرشيف = https://web.archive.org/web/20200325133126/https://docs.huihoo.com/blackhat/europe-2012/bh-eu-12-Atlasis-Attacking_IPv6-WP.pdf | تاريخ أرشيف = 25 مارس 2020 }}</ref> بشكلٍ مُشابه [[بروتوكول الإنترنت (الإصدار الرابع)|للإصدار الرابع من بروتوكول الإنترنت]]، لم تمنع مُحددات الإصدار السادس إنشاء قطع متراكبة عند التقطيع، أي من الممكن أن يتكرار نفس المقطع من [[حمولة (حوسبة)|الحمولة]] في أكثر من قطعة، على أن يُعتمد المقطع الوارد في آخر قطعة تمّ استقبالها عند التجميع، يسبب ذلك ثغرة أمنية، ويسمح بتنفيذ هجوم القطع المتراكبة، لاحقًا تمّ التأكيد بوضوح على منع تراكب القطع عند التقطيع في [[طلب تعليقات|وثيقة طلب التعليقات]] RFC 5722.<ref name="ietf-19">{{استشهاد بويب
| الأخير= Krishnan
| الأول= S. 
| تاريخ= فبراير 2016
| مسار أرشيف = https://web.archive.org/web/20200509163441/https://www.ietf.org/rfc/rfc5722
| مسار= https://www.ietf.org/rfc/rfc5722
| عنوان=  RFC 5722, Handling of Overlapping IPv6 Fragments
| موقع= The Internet Society
| لغة= en
| تاريخ الوصول= 21 يوليو 2018|تاريخ أرشيف=2020-05-09|url-status=dead}}</ref>

يقبل [[مضيف (حوسبة)|مُضيف]] الإصدار السادس من بروتوكول الإنترنت أن تحتوي [[رزمة بيانات|رزمة البيانات]] على [[ترويسة (حوسبة)|ترويسة]] القطعة بدون تكون القطعة ناتجة عن عملية تقطيع، وتسمى هذه القطع بالقطع الذرية {{إنج|Atomic Fragment}} وهي تنتج في حالات خاصة ناقشها المعيار الأصلي للبروتوكول،<ref name="ietf-9"/> على الرغم من أن هذه القطع تكون وحداناً، أي لا يجب أن يتم تجميعها مع أي قطع أخرى، فإنّ المُضيف الوجهة يعاملها مُعاملة القطع التي تنتظر التجميع، ما يُسبب ثغرة أمنية، فقد يقوم المهاجم بإرسال قطعة خبيثة مع قيم مُناسبة في ترويسة القطعة، بحيث تكون قطعة ذرية تقبل التجميع مع قطع أخرى خبيثة تُرسل لاحقًا، ناقشت الوثيقة RFC 6946 كيفية معالجة القطع الذرية لتلافي هذا النوع من الهجمات.<ref name="ietf-20">{{استشهاد بويب
| الأخير= Gont
| الأول= F.  
| تاريخ= مايو 2013
| مسار أرشيف = https://web.archive.org/web/20200509163442/https://www.ietf.org/rfc/rfc6946
| مسار= https://www.ietf.org/rfc/rfc6946
| عنوان=  RFC 6946, Processing of IPv6 "Atomic" Fragments
| موقع= The Internet Society
| لغة= en
| issn = 2070-1721
| تاريخ الوصول= 21 يوليو 2018|تاريخ أرشيف=2020-05-09|url-status=dead}}</ref>

== التقطيع في طبقة ربط البيانات ==
{| class="wikitable floatleft" width="65%"
|-
|+ قيم وحدة النقل العظمى لبعض بروتوكولات طبقة ربط البيانات.
|-
! اسم البروتوكول !! اختصار !! حجم وحدة النقل العظمى الأدنى (بايت) !! حجم وحدة النقل العظمى الأقصى (بايت) !! المرجع
|-
| [[إيثرنت|الإيثرنت]] || IEEE 802.3 || 64 || 1518 {{للهامش|5}} || <ref name="JOU-5"/>
|-
| بروتوكول حلقة الرمز || IEEE 802.5 || لا يوجد حد أدنى || 17794 || <ref name="Web-55">{{استشهاد بويب
| مؤلف = Brent Baccala
| مسار أرشيف = https://web.archive.org/web/20160605205826/http://www.freesoft.org/CIE/RFC/1042/10.htm
| تاريخ أرشيف = 5 يونيو 2016
| تاريخ = أبريل 1997
| مسار= https://www.freesoft.org/CIE/RFC/1042/10.htm
| عنوان= IEEE 802.5 Details
| موقع= Connected: An Internet Encyclopedia
| لغة= en
| تاريخ الوصول= 29 يوليو 2018}}</ref><ref name="Web-56">{{استشهاد بويب
| مسار أرشيف = https://web.archive.org/web/20180729160838/https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.hald001/tokenx.htm| تاريخ أرشيف = 29 يوليو 2018| مسار= https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.hald001/tokenx.htm
| عنوان= Token-Ring IEEE 802.5
| موقع= IBM Corporation
| لغة= en
| تاريخ الوصول= 29 يوليو 2018}}</ref>
|-
| [[آي تربل إي 802.11|بروتوكول الشبكات المحلية اللاسلكية]] || IEEE 802.11 || غير مُحدد || 2304 {{للهامش|6}} || <ref name="JOU-7"/>
|-
| بروتوكول الشبكات الشخصية اللاسلكية منخفضة المعدل || IEEE 802.15.4 || غير مُحدد || 127 || <ref name="JOU-10"/>
|}
في [[طبقة ربط البيانات]]، التقطيع هو تقسيم حمولة [[إطار البيانات]] إلى قطعتين أو أكثر، لينتج بعد عملية [[تغليف (شبكات)|التغليف]] إطاري بيانات أو أكثر ذوو أطوال أقصر من إطار البيانات الأصلي الذي تمّ تقطيعه. يُحدد كل بروتوكول ربط [[وحدة النقل العظمى|وحدة نقل أعظمية]] كعتبة لا يتجاوزها طول أطر البيانات التي يولّدها. التقطيع ليس وظيفة إلزامية لبروتوكولات الربط، وإذا لم يدعم بروتوكول الربط عملية التقطيع، فيجب على بروتوكول [[طبقة الشبكة|الشبكة]] أن يُولّد رزم بيانات تتناسب مع وحدة النقل لأعظمية لبروتوكول الربط المستعمل.

يُمكن أن يستخدم التقطيع في طبقة الربط في الحالات التي يكون فيها التطبيق حساسًا للتأخير الزمني، حيث يسبب طول إطار بيانات ما تأخيرًا غير مُستحب لأُطر بيانات أخرى، ويكون الحل بتقطيع الإطار الطويل إلى قطع أصغر وإرسالها عبر وسط الاتصال، وبذلك يقل زمن التأخير وتقلقل الإرسال، وتسمى هذه الآلية التقطيع والتوزيع في طبقة الربط {{إنج|Link Fragmentation and Interleaving اختصاراً LFI}}.<ref name="Web-26">{{استشهاد بويب
| مسار أرشيف = https://web.archive.org/web/20170513185941/https://www.cisco.com/c/en/us/support/docs/asynchronous-transfer-mode-atm/atm-traffic-management/24041-lfi-24041.html
| تاريخ أرشيف = 13 مايو 2017
| مسار= https://www.cisco.com/c/en/us/support/docs/asynchronous-transfer-mode-atm/atm-traffic-management/24041-lfi-24041.html
| عنوان= Configuring Link Fragmentation and Interleaving (LFI) With Campus ATM Switches
| موقع= Cisco Systems, Inc.
| لغة= en
| تاريخ الوصول= 20 يوليو 2018}}</ref><ref name="Web-25">{{استشهاد بويب
| مسار أرشيف = https://web.archive.org/web/20180720161603/https://www.juniper.net/documentation/en_US/junos/topics/concept/interface-link-services-lfi-understanding.html
| تاريخ أرشيف = 20 يوليو 2018
| مسار= https://www.juniper.net/documentation/en_US/junos/topics/topic-map/security-interface-link-fragmentation-interleaving.html#id-understanding-link-fragmentation-and-interleaving-configuration
| عنوان= Understanding Link Fragmentation and Interleaving Configuration
| موقع= Juniper Networks, Inc
| لغة= en
| تاريخ الوصول= 20 يوليو 2018}}</ref>

تحدد الشركات المُصنعة [[عتاد الشبكة|لعتاد الشبكة]] قيم وحدة النقل العظمى الافتراضية والعُظمى الخاصة ببروتوكولات الربط العاملة على منافذ تجهيزاتها، وترتبط عملية التقطيع في طبقة ربط البيانات بهذه القيم بشكلٍ مباشر.<ref name="Web-58">{{استشهاد بويب
| مسار أرشيف = https://web.archive.org/web/20170920164119/http://www.juniper.net:80/documentation/en_US/junos/topics/reference/general/interfaces-media-mtu-size-by-interface-type.html
| تاريخ أرشيف = 20 سبتمبر 2017
| مسار= https://www.juniper.net/documentation/en_US/junos/topics/topic-map/physical-interface-properties.html#id-media-mtu-sizes-by-interface-type
| عنوان= Media MTU Sizes by Interface Type
| موقع= Juniper Networks, Inc.
| لغة= en
| تاريخ الوصول= 29 يوليو 2018}}</ref><ref name="Web-59">{{استشهاد بويب
| مسار أرشيف = https://web.archive.org/web/20170630033729/http://www.cisco.com:80/c/en/us/support/docs/ios-nx-os-software/ios-xr-software/116350-trouble-ios-xr-mtu-00.html
| تاريخ أرشيف = 30 يونيو 2017
| مسار= https://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/ios-xr-software/116350-trouble-ios-xr-mtu-00.html
| عنوان= MTU Behavior on Cisco IOS XR and Cisco IOS Routers
| موقع= Cisco Systems, Inc.
| لغة= en
| تاريخ الوصول= 29 يوليو 2018}}</ref>

=== التقطيع في بروتوكول الشبكات المحلية اللاسلكية ===
[[ملف:IEEE 802.11 Fragmentation - ar.png|تصغير|300بك|مفهوم التقطيع في الشبكات المحلية اللاسلكية.]]
يُعرف معيار [[آي تربل إي 802.11|بروتوكول الشبكات المحلية اللاسلكية]] {{إنج|IEEE 802.11}} عملية التقطيع بأنها تجزيء وحدات بيانات البروتوكول الخاصة بطبقة [[تحكم بالوصول للوسط|التحكم بالوصول للوسط]] إلى أجزاء أصغر، بهدف زيادة الوثوقية، من خلال زيادة احتمال نجاح عملية نقل الإطار عبر قنوات الاتصال التي تبدي خواصها [[وثوقية (حوسبة)|وثوقية]] محدودة لاستقبال الأطر ذات الأطوال الكبيرة.{{للهامش|4}} تسمى العملية المعاكسة للتقطيع بإعادة التجميع {{إنج|Defragmentation}} ويجب أن تحصل في الوجهة التالية للقطع الناتجة، سواء كانت وجهة نهائية أو وسيطية على المسار.<ref name = "JOU-7">{{استشهاد بدورية محكمة
|عنوان= 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
| تاريخ = ديسمبر 2016
|صفحة= 1301
| ناشر = IEEE
| doi=10.1109/IEEESTD.2016.7786995
| isbn =978-1-5044-3645-8
}}</ref>

يتم التحكم بعملية التقطيع بواسطة مُحدد خاص اسمه عتبة التقطيع {{إنج|dot11FragmentThreshold}}، وتسمح تطبيقات البروتوكول لمشرفي الشبكة بضبط هذه القيمة، وأي إطار بيانات يتجاوز طوله قيمة العتبة يجب تقطيعه، ولكن لا يوجد خوارزمية محددة للتقطيع ويترك أمر تحديد الطريقة لمن يقوم بتنفيذ البروتوكول.<ref name = "Book-3">{{استشهاد بكتاب
|مؤلف1-الأخير = Gast
|مؤلف1-الأول =Matthew
|عنوان= 802.11 Wireless Networks: The Definitive Guide
|مسار = https://archive.org/details/wirelessnetworks00gast_193
|طبعة= الأولى
|صفحة= [https://archive.org/details/wirelessnetworks00gast_193/page/n45 46]
|سنة=2002
|ناشر= O'Reilly Media
|ردمك= 0596001835
|لغة= en
}}</ref>

وجدت دراسة لاحقة بأن عملية التقطيع تحسّن من أداء بروتوكول الشبكات المحلية اللاسلكية عند في حال التداخل الراديوي، فعند إنقاص قيمة عتبة التقطيع يتناقص معدل خطأ البت المحلي الخاص بالمستقبل الراديوي لنقطة الوصول ويتناقص العدد الكلي لمحاولات إعادة الإرسال وتزداد إنتاجية المستقبل الراديوي. أمّا عند زيادة قيمة عتبة التقطيع فيتناقص التأخير الكلي للوصول إلى الوسط، وأيضًا [[تقلقل الإرسال]] الكلي.<ref name = "JOU-3">{{استشهاد بدورية محكمة
|الأخير= Diaconu
|الأول=  Felix
|صحيفة = Bul. Inst. Politehnic, Iaşi, s. Electrot., Energ., Electron
|عنوان= IEEE 802.11 MAC frame fragmentation performances in jammed environments
|المجلد= 58
|العدد = 2
| تاريخ = يوليو 2011
|صفحة= 81-88
| مسار = http://www.bulipi-eee.tuiasi.ro/archive/2012/fasc.2/p8_f2_2012.pdf
| مسار أرشيف = https://web.archive.org/web/20151122203028/http://www.bulipi-eee.tuiasi.ro/archive/2012/fasc.2/p8_f2_2012.pdf | تاريخ أرشيف = 22 نوفمبر 2015 }}</ref>

=== التقطيع في شبكات تبديل الأطر ===
[[ملف:LFI in frame relay - ar.png|تصغير|300بك|والتقطيع والتوزيع في طبقة الربط في [[تبديل الأطر|شبكة تبديل الأطر]].]]
إن الهدف الأساسي من التقطيع في [[تبديل الأطر|شبكة تبديل الأطر]] هو دعم حركة البيانات الحساسة للتأخير عند حركتها عبر الشبكة، بحيث يتم تقطيع أطر البيانات ذات الأطوال الكبيرة إلى قطع صغيرة بحيث لا يسبب إرسالها تأخيرًا كبيرًا لبقية الأطر. تسمح هذه التقنية للأطر الحساسة وغير للتأخير الزمني بتشارك نفس القناة الافتراضية عبر نفس المنفذ.<ref name = "Book-7">{{استشهاد بكتاب
|مؤلف1=  Jeff T. Buckwalter
|عنوان= Frame Relay: Technology and Practice
|صفحة=215
|سنة= 1999
| طبعة = الأولى
|ناشر= Addison-Wesley Professional
|ردمك= 0201485249
|لغة= en
}}</ref> وُصفت محددات التقطيع بمعيار خاص تحت الاسم الرمزي (FRF.12).<ref name="Web-51">{{استشهاد بويب
| مؤلف = Andrew G. Malis
| مسار أرشيف = https://web.archive.org/web/20160426183112/https://www.broadband-forum.org/technical/download/FRF.12/frf12.pdf
| تاريخ أرشيف = 26 أبريل 2016
| تاريخ = ديسمبر 1997
| مسار= https://www.broadband-forum.org/technical/download/FRF.12/frf12.pdf
| عنوان= Frame Relay Fragmentation Implementation Agreement FRF.12
| موقع= Broadband Forum
| لغة= en
| تاريخ الوصول= 28 يوليو 2018|url-status=dead}}</ref>

يستخدم التقطيع في شبكة تبديل الأطر كجزء من آلية التقطيع والتوزيع في طبقة الربط (LFI).<ref name="Web-26"/> لا يوجد طول مُحدد مُلزم لوحدة النقل الأعظمي، ولكن من الأفضل أن يكون الطول المُختار متناسبًا مع [[معدل ساعة (حاسوب)|معدل الساعة]] للقناة الفيزيائية ومعدل التقل عبر القنوات الافتراضية.<ref name="Web-52">{{استشهاد بويب
| مؤلف = Andrew G. Malis
| مسار أرشيف = https://web.archive.org/web/20170612170757/http://www.rhyshaden.com/frame.htm
| تاريخ أرشيف = 12 يونيو 2017
| مسار= http://www.rhyshaden.com/frame.htm
| عنوان= Frame Relay, section: Frame Relay Fragmentation
| موقع= Rhys Haden
| لغة= en
| تاريخ الوصول= 28 يوليو 2018}}</ref> تُستخدم خوارزمية التقطيع الخاصّة ببروتوكول الربط بين نقطتين مُتعدد الوصلات.<ref name="ietf-27"/>

==== أنماط التقطيع ====
[[ملف:Frame Relay Fragmentation Types - ar.png|تصغير|300بك|أنماط التقطيع في شبكات تبديل الأطر: (1) تقطيع بين المستخدم والشبكة، (2) تقطيع داخل الشبكة، (3) تقطيع بين الطرفيات]]

يُعرّف معيار التقطيع في شبكات تبديل الأطر ثلاث أنماط من التقطيع:<ref name="Web-51"/>
* '''التقطيع بين المُستخدم والشبكة''' {{إنج|UNI Fragmentation}}: ويحصل بين [[جهاز اتصال البيانات|جهاز اتصال بيانات]] (DCE) و[[جهاز بيانات طرفي]] (DTE) بهدف السماح [[إطار البيانات|لأطر البيانات]] الحساسة وغير الحساسة للتأخير بتشارك نفس المنفذ الذي يصل بين المستخدم والشبكة، والذي غالبًا ما يكون ذو [[معدل نقل البتات|معدل]] نقل منخفض. في هذا النمط، يتم تجميع الإطار مجددًا قبل دخوله شبكة تبديل الإطار، ويُرسل كاملًا عبرها.
* '''التقطيع داخل الشبكة''' {{إنج|NNI Fragmentation}}: ويكون هذا التقطيع غير مرئي بالنسبة للطرفيات حيث تحصل عمليتي التقطيع والتجميع داخل شبكة تبديل الأطر، وهو يهدف للسماح لأطر البيانات الحساسة وغير الحساسة للتأخير بتشارك نفس القناة الافتراضية. إن عمليتي التقطيع بين المستخدم والشبكة، والتقطيع داخل الشبكة متطابقتين من حيث الينية والخوارزمية المستعملة، وتُستخدمان في القنوات الافتراضية الدائمة {{اختصار مخفي|SVC|اختصار أول}} والمبدلة {{اختصار مخفي|SVC|اختصار ثاني}}.
* '''التقطيع بين الطرفيات''' {{إنج|End-to-End Fragmentation}}: ويحصل هذا التقطيع بين الطرفيات، وتحديدًا بين جهازي بيانات طرفيين، ويكون غير مرئي بالنسبة لشبكة تبديل الأطر، ولا يُستخدم إلا في القنوات الافتراضية الدائمة.

==== ترويسة القطعة ====
[[ملف:Fragment Encapsulation in frame relay - ar.png|تصغير|300بك|الحالات المختلفة لتغليف قطعة بيانات عند استخدام بروتوكول تبديل الأطر كبروتوكول ربط.]]
يجري تقطيع حمولة الإطار الأصلي إلى قطعتين أو أكثر، وتضاف ترويسة بروتوكول تبديل الأطر إلى كل القطع، وهي بطول 2 بايت، وأيضًا ترويسة التقطيع، وهي بطول 2 بايت أيضًا، وفي حالة التقطيع بين الطرفيات يضاف مُعرف بروتوكول طبقة الشبكة {{إنج| Network Layer Protocol ID اختصاراً NLPID}} وهو بطول 1 بايت، ويضبط إلى القيمة <sub>16</sub>(1B) في حالة التقطيع.<ref name="ietf-28">{{استشهاد بويب
| الأخير= Brown
| الأول=   C.   
| مؤلف2-الأخير= Malis
| مؤلف2-الأول=   A.  
| تاريخ= سبتمبر 1998
| مسار أرشيف = https://web.archive.org/web/20200509163443/https://www.ietf.org/rfc/rfc2427
| مسار= https://www.ietf.org/rfc/rfc2427
| عنوان=  RFC 2427, Multiprotocol Interconnect over Frame Relay
| صفحة = 27
| موقع= The Internet Society
| لغة= en
| تاريخ الوصول= 29 يوليو 2018|تاريخ أرشيف=2020-05-09}}</ref> أما ترتيب الإضافة عند التغليف فيكون بالشكل التالي:<ref name="Web-51"/>
* في التقطيع بين المستخدم والشبكة، وفي التقطيع داخل الشبكة، تضاف ترويسة البروتوكول أولًا، ثم تضاف ترويسة التقطيع.
* في التقطيع بين الطرفيات، تضاف ترويسة التقطيع أولًا، ثُمّ مُعرف بروتوكول طبقة الشبكة، ثم بايت محجوز يضبط إلى القيمة <sub>16</sub>(03)، وأخيرًا ترويسة بروتوكول تبديل الأطر.

يضاف مُلحق بطول 2 بايت لكل القطع، يحتوي على ناتج تطبيق خوارزمية {{وإو|تتابع فحص الإطار|Frame check sequence|en|خوارزمية تتابع فحص الإطار}}.<ref name="Web-53">{{استشهاد بويب
| مسار أرشيف = https://web.archive.org/web/20160512174203/http://www.cisco.com/c/en/us/support/docs/wan/frame-relay/47202-87.pdf
| تاريخ أرشيف = 12 مايو 2016
| مسار= https://www.cisco.com/c/en/us/support/docs/wan/frame-relay/47202-87.pdf
| عنوان= Frame Relay Glossary
| صفحة = 3
| موقع= Cisco systems, Inc
| لغة= en
| تاريخ الوصول= 29 يوليو 2018}}</ref>

يبلغ طول ترويسة القطعة 2 بايت، وهي تتكون من الحقول التالية بحسب ترتيب ورودها:<ref name="Web-51"/>
* '''بت قطعة البداية''' {{إنج|Beginning fragment bit}}: وهو علم يشير إلى القطعة الأولى الناتجة عن التقطيع، يتم ضبطه إلى القيمة 1 في القطعة الأولى وإلى 0 في باقي القطع.
* '''بت قطعة النهاية''' {{إنج|Ending fragment bit}}: وهو علم يشير إلى القطعة الأخيرة، يتم ضبطه إلى القيمة 1 في القطعة الأخيرة وإلى 0 في باقي القطع.
* '''بت التحكم''' {{إنج|Control bit}}: محجوز لاستخدامات مستقبلية، يُضبط دائمًا إلى القيمة 0.
* '''الجزء العلوي من حقل التتابع''': طوله 4 بت، ويضم الجزء العلوي من حقل التتابع، وتزداد قيمة حقل التتابع بمقدار 1 مع كل قطعة جديدة يتم توليدها، بمعزل عن انتهاء إطار ما والبدء بتقطيع إطار جديد، أي إذا كانت قيمة الحقل N في آخر قطعة نتجت عن تقطيع إطار ما، فإن قيمة التتابع في القطعة الأولى التي ستنتج عن الإطار التالي الذي يتم تقطيع ستكون N+1. تضبط قيمة حقل التتابع بشكل اختياري لكل قناة افتراضية إلى قيمة ما، ثم تزداد بعد ذلك بقيمة واحد مع كل قطعة جديدة يتم تغليفها، يساعد هذا الحقل في إنجاز عملية التجميع من خلال تحديد الرزم القطع التي تنتمي لنفس الإطار الأصلي، وتحديد إزاحتها عن بدايته.
* '''بت محجوز''': قيمته دومًا هي 1.
* '''الجزء السفلي من حقل التتابع''' طوله 8 بت، ويضم الجزء السغلي من حقل التتابع.

=== التقطيع في بروتوكول الربط بين نقطتين متعدد الوصلات ===
[[ملف:MLPPP model, topology and encapsulation - ar.png|تصغير|300بك|بروتوكول الربط بين نقطتين متعدد الوصلات، في الأعلى وإلى اليسار: [[طوبولوجيا شبكة|طوبولوجيا الشبكة]]، في الأعلى وإلى اليمين: [[نموذج الربط البيني للأنظمة المفتوحة|نموذج الاتصال المعياري]] المُوافق، في الأسفل: عملية [[تغليف (شبكات)|التغليف]].]]
[[ملف:MLPPP encapsualtion types - ar.png|تصغير|300بك|[[تغليف (شبكات)|تغليف]] قطعة البيانات عند استعمال بروتوكول الربط بين نقطتين متعدد الوصلات. (أ) رقم تتابع قصير (ب) رقم تتابع طويل.]]
يُعرّف مُحدد [[بروتوكول الربط بين نقطتين]] (PPP) البرتوكول بأنه [[بروتوكول (اتصالات)|بروتوكول]] [[طبقة الوصلة|ربط]] يصل بين نقطتين هما طرفا الاتصال، ويمكن أن يقوم [[تغليف (شبكات)|بتغليف]] [[رزمة بيانات|رزم بيانات]] لبروتوكولات [[طبقة الشبكة|شبكة]] مختلفة.<ref name="ietf-26">{{استشهاد بويب
| الأخير= Simpson
| الأول=   W.   
| تاريخ= يوليو 1994
| مسار أرشيف = https://web.archive.org/web/20050508143240/http://www.ietf.org/rfc/rfc1661| مسار= https://www.ietf.org/rfc/rfc1661
| عنوان=  RFC 1661, The Point-to-Point Protocol (PPP)
| موقع= The Internet Society
| لغة= en
| تاريخ الوصول= 25 يوليو 2018| تاريخ أرشيف = 8 مايو 2005 }}</ref> لاحقًا أضيفت توسيعة لهذا البروتوكول تسمح بتجميع أكثر من خط نقل فيزيائي يمثل كل منها [[قناة اتصال]] مستقلة ضمن خط نقل افتراضي واحد يجمع هذه القنوات، وسميت هذه التوسيعة ببروتوكول النقل متعدد الوصلات بين نقطتين، ووصفت في وثيقة طلب التعليقات (RFC 1990).<ref name="ietf-27">{{استشهاد بويب
| الأخير= Sklower
| الأول=   K.   
| مؤلف2-الأخير= Lloyd
| مؤلف2-الأول=   B.  
| مؤلف3-الأخير=  McGregor
| مؤلف3-الأول=   G.  
| مؤلف4-الأخير= D. Carr
| مؤلف4-الأول=   W. 
| مؤلف5-الأخير= Coradetti
| مؤلف5-الأول=   T.  
| تاريخ= أغسطس 1996
| مسار أرشيف = https://web.archive.org/web/20200509163444/https://www.ietf.org/rfc/rfc1990
| مسار= https://www.ietf.org/rfc/rfc1990
| عنوان=  RFC 1990, The PPP Multilink Protocol (MP)
| موقع= The Internet Society
| لغة= en
| تاريخ الوصول= 25 يوليو 2018|تاريخ أرشيف=2020-05-09}}</ref> كما قد يُستخدم التقطيع كجزء من آلية التقطيع والتوزيع في طبقة الربط (LFI).<ref name="Web-60">{{استشهاد بويب
| مسار أرشيف = https://web.archive.org/web/20180720161603/https://www.juniper.net/documentation/en_US/junos/topics/concept/interface-link-services-lfi-understanding.html
| تاريخ أرشيف = 20 يوليو 2018
| تاريخ = 24 أكتوبر 2017
| مسار= https://www.juniper.net/documentation/en_US/junos/topics/topic-map/security-interface-link-fragmentation-interleaving.html#id-understanding-link-fragmentation-and-interleaving-configuration
| عنوان= Understanding Link Fragmentation and Interleaving Configuration
| موقع=  Juniper Networks, Inc.
| لغة= en
| تاريخ الوصول= 29 يوليو 2018}}</ref>

تُعرّف التوسيعة طبقة فرعية في نموذج الاتصال المعياري، تشغل الجزء العلوي من طبقة ربط البيانات، وتعمل فيها وحدة توسيعة البروتوكول، فترتبط مع وحدة بروتوكول طبقة الشبكة من جهة، ومع وحدتين أو أكثر من وحدات بروتوكول الربط بين نقطتين من جهة أخرى، التي تشغل طبقة فرعية أخرى تُشكل الجزء الأدنى من طبقة ربط البيانات.<ref name="Web-46">{{استشهاد بويب
| مؤلف = Charles M. Kozierok
| مسار أرشيف = https://web.archive.org/web/20170123080631/http://www.tcpipguide.com/free/t_PPPMultilinkProtocolMPMLPMLPPPPPPMP-2.htm
| تاريخ أرشيف = 23 يناير 2017
| تاريخ =  20 سبتمبر 2005
| مسار= http://www.tcpipguide.com/free/t_PPPMultilinkProtocolMPMLPMLPPPPPPMP-2.htm
| عنوان= PPP Multilink Protocol (MP/MLP/MLPPP)
| موقع= The TCP/IP Guide
| لغة= en
| تاريخ الوصول= 25 يوليو 2018}}</ref>

من أجل توزيع الحمل بين خطوط التقل التي تشكل الوسط الفيزيائي، تقوم توسيعة البروتوكول بتقطيع رزمة البيانات الواردة من طبقة الشبكة إلى عدد من القطع، ثم تضيف ترويسة خاصة تُسمى ترويسة القطعة لكل قطعة ناتجة، وتمرر القطع وفق سياسة توزيع محددة إلى وحدات بروتوكول الربط بين نقطتين، التي تقوم كل منها بدورها بإضافة ترويسة وملحق خاصين ببروتوكول الربط بين نقطتين، ويجري تغليف القطعة بهما، ثم يُمرر الناتج إلى الطبقة المادية، وتعاد هذه المراحل بترتيب معكوس في المستقبل، من أجل إعادة توليد رزمة البيانات الأصلية.<ref name="Web-47">{{استشهاد بويب
| مؤلف = Charles M. Kozierok
| مسار أرشيف = https://web.archive.org/web/20171222024340/http://www.tcpipguide.com:80/free/t_PPPMultilinkProtocolMPFrameFormat-3.htm
| تاريخ أرشيف = 22 ديسمبر 2017
| تاريخ =  20 سبتمبر 2005
| مسار= http://www.tcpipguide.com:80/free/t_PPPMultilinkProtocolMPFrameFormat-3.htm
| عنوان= PPP Multilink Protocol (MP/MLP/MLPPP)
| موقع= The TCP/IP Guide
| لغة= en
| تاريخ الوصول= 25 يوليو 2018}}</ref>

تضاف ترويسة التوسيعة لكل قطعة ناتجة، ثم تُضاف ترويسة البروتوكول التقليدية والمُلحق بعملية التغليف. يكون طول ترويسة التوسيعة إمّا (2) أو (4) بايت، وفي كلا الحالتين تتألف الترويسة من 4 حقول هي:<ref name="ietf-27"/><ref name="Web-48">{{استشهاد بويب
| مسار أرشيف = https://web.archive.org/web/20170513185941/http://www.cisco.com:80/c/en/us/support/docs/asynchronous-transfer-mode-atm/atm-traffic-management/24041-lfi-24041.html
| تاريخ أرشيف = 13 مايو 2017
| مسار= http://www.cisco.com:80/c/en/us/support/docs/asynchronous-transfer-mode-atm/atm-traffic-management/24041-lfi-24041.html
| عنوان= Configuring Link Fragmentation and Interleaving (LFI) With Campus ATM Switches
| موقع= Cisco Systems, Inc.
| لغة= en
| تاريخ الوصول= 25 يوليو 2018}}</ref>
* '''بت قطعة البداية''' (Beginning fragment bit): وهو علم يشير إلى القطعة الأولى، يتم ضبطه إلى القيمة (1) في أول قطعة تنتج عن عملية التقطيع، و (0) في بقية القطع.
* '''بت قطعة النهاية''' (Ending fragment bit): وهو علم يشير إلى القطعة الأخيرة، يتم ضبطه إلى القيمة (1) في آخر قطعة تنتج عن عملية التقطيع، و (0) في بقية القطع.
* '''حقل رقم التتابع''' (Sequence number): ويدل على ترتيب القطعة بالنسبة لبقية القطع، يضبط في البداية إلى قيمة ابتدائية، ثُم تجري زيادتها بمقدار (1) في كل قطعة جديدة يتم تغليفها، قد يكون الحقل بطول (12) بت، ويُسمّى عندها التتابع القصير {{إنج|Short Sequence}} أو بطول (24) بت، ويُسمّى عندها التتابع الطويل {{إنج|Long Sequence}}.<ref name="Web-61">{{استشهاد بويب
| مؤلف = Charles M. Kozierok
| مسار أرشيف = https://web.archive.org/web/20180121150314/http://www.tcpipguide.com/free/t_PPPMultilinkProtocolMPFrameFormat-3.htm
| تاريخ أرشيف = 21 يناير 2018
| تاريخ = 20 سبتمبر 2005
| مسار= http://www.tcpipguide.com/free/t_PPPMultilinkProtocolMPFrameFormat-3.htm
| عنوان= PPP Multilink Protocol (MP) Frame Format
| موقع= The TCP/IP Guide
| لغة= en
| تاريخ الوصول= 29 يوليو 2018}}</ref>
* '''بتات محجوزة''': تُوجد بين العلمين ورقم التتابع، تُضبط إلى القيمة (0)، وعددها (2) إذا استخدم التتابع القصير أو (6) إذا استخدم التتابع الطويل.
== التقطيع في الطبقة المادية ==
=== التقطيع في بروتوكول الإيثرنت ===
[[ملف:Fragmentation for APL - ar.png|تصغير|300بك|تقطيع [[إطار البيانات|أطر البيانات]] في [[طبقة مادية|الطبقة المادية]] بحسب بروتوكول [[إيثرنت|الإيثرنت]].]]
يدعم [[إيثرنت|بروتوكول الإيثرنت]] شكلًا خاصًّا من أشكال التقطيع في [[طبقة مادية|الطبقة المادية]]، وهو لا يهدف إلى إنقاص حجم وحدة بيانات البروتوكول، ولكنّ إلى إتاحة استخدام وسط [[قناة اتصال|الاتصال المادي]] الذي ينتج عن استخدام تقنية التجميع في الطبقة المادية {{إنج|Aggregation at physical layer اختصاراً APL}} بصورة مثاليّة، تسمح هذه التقنية بتجميع خطوط نقل ذات [[معدل نقل البتات|معدلات نقل]] مُعتدلة مثل 1 و2 و4 و10 [[جيجا]] [[بت]] في [[ثانية|الثانية]]، لبلوغ معدلات نقل عالية مثل 40 أو 100 جيجا بت في الثانية. يحدد البروتوكول طولًا أصغريًّا للقطعة هو 64 [[بايت]]، وأعظميًّا هو 512 بايت، ولا يمكن تجاوز هذه العتبات عند اختيار طول القطعة.<ref name = "JOU-5">{{استشهاد بدورية محكمة
|صحيفة = IEEE Standard
|عنوان= 802.3-2015 - IEEE Standard for Ethernet
| تاريخ = مارس 2016
|صفحة= 2690-2699
| ناشر = IEEE
| doi = 10.1109/IEEESTD.2016.7428776
| isbn = 978-1-5044-0078-7
| مسار = https://ieeexplore.ieee.org/document/7428776/
| مسار أرشيف = https://web.archive.org/web/20191214185749/https://ieeexplore.ieee.org/document/7428776 | تاريخ أرشيف = 14 ديسمبر 2019 }}</ref>

يتم تقطيع [[إطار البيانات]] كاملًا في طرف الإرسال إلى عدد من القطع، ثُمّ يجري إضافة [[ترويسة (حوسبة)|ترويسة]] بطول 32 بت وملحق بطول 16 بت لكل قطعة، ويلي ذلك توزيع القطع على خطوط النقل. تُرسل القطع الناتجة عبر خطوط النقل التي تشكل وسط الاتصال في نفس الوقت، ويجري تجميعها في طرف الإستقبال اعتمادًا على الترويسة المُضافة، والتي تحتوي على حقل بطول بت، يسمى رقم التتابع، وهي يساعد المستقبل على إيجاد الترتيب الصحيح للقطع لإعادة تجميعها وإنشاء إطار البيانات الأصلي مجددًا في الطرف الذي استقبلها.<ref name="Web-44">{{استشهاد بويب
| مؤلف = Howard Frazier
| مسار أرشيف = https://web.archive.org/web/20160913204023/http://www.ieee802.org/3/ba/public/jan08/frazier_01_0108.pdf
| تاريخ أرشيف = 13 سبتمبر 2016
| تاريخ =  23 يناير 2008
| مسار= http://www.ieee802.org/3/ba/public/jan08/frazier_01_0108.pdf
| عنوان= Aggregation at the Physical Layer

| موقع= IEEE
| لغة= en
| تاريخ الوصول= 24 يوليو 2018}}</ref>

== انظر أيضًا ==
* [[تغليف (شبكات)|تغليف البيانات]].
* [[حزمة بروتوكولات الإنترنت]] (TCP/IP).
* [[وحدة بيانات بروتوكول]] (PDU).
== هوامش ==
{{هامش|1}}. الرسالة هي رسالة «لا يمكن بلوغ الوجهة» {{إنج|Destination unreachable Message}}، لذلك يضبط حقل النوع في ترويسة البروتوكول إلى القيمة (3) وحقل الترميز إلى القيمة (4)، والتي تعني هناك حاجة للتقطيع ولكن علم عدم التقطيع مرفوع.<ref name="ietf-14">{{استشهاد بويب
| الأخير= Postal
| الأول= J.
| تاريخ= أغسطس 1981
| مسار= https://tools.ietf.org/html/rfc792
| عنوان=  RFC 792, Internet Control Message protocol, DARPA internet program,protocol specification.
| موقع= The Internet Society
| لغة= en
| تاريخ الوصول= 14 يوليو 2018| مسار أرشيف = https://web.archive.org/web/20190420021247/https://tools.ietf.org/html/rfc792 | تاريخ أرشيف = 20 أبريل 2019 }}</ref>

{{هامش|2}}. الرسالة هي رسالة «الرزمة كبيرة جدًّا» {{إنج|Packet Too big}} لذلك يضبط حقل النوع في ترويسة البروتوكول إلى القيمة (2) وحقل الترميز إلى القيمة (0).<ref name="ietf-15">{{استشهاد بويب
| الأخير= Conta
| الأول= A.
| الأخير= Deering
| الأول= S.
| الأخير= Gupta
| الأول= M.
| تاريخ= مارس 2006
| مسار= https://tools.ietf.org/html/rfc4443
| عنوان= RFC 4443,  Internet Control Message Protocol (ICMPv6),for the Internet Protocol Version 6 (IPv6) Specification
| موقع= The Internet Society
| لغة= en
| تاريخ الوصول= 15 يوليو 2018| مسار أرشيف = https://web.archive.org/web/20190402102314/https://tools.ietf.org/html/rfc4443 | تاريخ أرشيف = 2 أبريل 2019 }}</ref>

{{هامش|3}}. يجب التمييز بين بروتوكول طبقة الشبكة وبروتوكول التشبيك،<ref name = "JOU-AD1">{{استشهاد بدورية محكمة
|الأخير= POSTEL
|الأول= JONATHAN B.                   
|صحيفة = IEEE TRANSACTIONS ON COMMUNICATIONS
|عنوان= Internetwork Protocol Approaches
| تاريخ = أبريل 1980
| المجلد = 28
| العدد = 4
| صفحة= 604 - 611
| ناشر = IEEE
| doi = 10.1109/TCOM.1980.1094705
| issn = 0090-6778
| مسار = http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.233.1383&rep=rep1&type=pdf
| مسار أرشيف = https://web.archive.org/web/20180810175912/http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.233.1383&rep=rep1&type=pdf | تاريخ أرشيف = 10 أغسطس 2018 }}</ref> والذي يسمى أيضًا البروتوكول المُوجّه، فالأول تصنيف للبروتوكولات بحسب طبقة نموذج الاتصال المعياري، أما الثاني فهو تصنيف للبروتوكولات بحسب الوظيفة، وبروتوكولات الشبكة هي البروتوكولات التي تقوم بوظائف طبقة الشبكة. إن كل بروتوكول شبكة هو بروتوكول طبقة شبكة، مثل الإصدار الرابع لبروتوكول الإنترنت، ولكن العكس غير صحيح، فبروتوكول رسائل التحكم في الإنترنت هو بروتوكول طبقة شبكة، ولكنه ليس بروتوكول شبكة.

{{هامش|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) بايت،<ref name="Web-54">{{استشهاد بويب
| مسار أرشيف = https://web.archive.org/web/20170610042533/https://www.cisco.com/c/en/us/support/docs/lan-switching/8021q/17056-741-4.html
| تاريخ أرشيف = 10 يونيو 2017
| مسار= https://www.cisco.com/c/en/us/obsolete/switches/cisco-catalyst-2955-series-switches.html
| عنوان= Inter-Switch Link and IEEE 802.1Q Frame Format
| موقع= Cisco systems, Inc,
| لغة= en
| تاريخ الوصول= 29 يوليو 2018}}</ref> وثانيها [[تجسير (نظم)|الجسر]] المٌزوّد الموصوف بالمعيار (IEEE 802.1.ad)<ref name = "JOU-12">{{استشهاد بدورية محكمة
|صحيفة = IEEE Standards
|عنوان= 802.1Q-2014 - IEEE Standard for Local and metropolitan area networks--Bridges and Bridged Networks
| تاريخ = ديسمبر 2014
| ناشر= IEEE
| doi = 10.1109/IEEESTD.2014.6991462
| isbn = 978-0-7381-9433-2
}}</ref> الذي يضيف (8) بايت بوسمة خاصة إلى الطول الأصلي فيصبح الطول الإجمالي (1526) بايت، وثالثها أطر الإيثرنت العملاقة {{إنج| Jumbo frame}} التي تُعرّف بأنها أي إطار إيثرنت يزيد طول حمولته عن (1500) بايت،<ref name = "JOU-13">{{استشهاد بدورية محكمة
 |صحيفة              = IEEE Communications Magazine
 |عنوان              =Ethernet Jumbo Frames|تاريخ              = نوفمبر 2009
 |ناشر                = ethernet alliance
 |مسار                = http://www.ethernetalliance.org/wp-content/uploads/2011/10/EA-Ethernet-Jumbo-Frames-v0-1.pdf
 |مسار أرشيف     = https://web.archive.org/web/20200325133103/https://web.archive.org/web/20170812041549/http://www.ethernetalliance.org/wp-content/uploads/2011/10/EA-Ethernet-Jumbo-Frames-v0-1.pdf
 |تاريخ أرشيف   = 25 مارس 2020
 |تاريخ الوصول = 30 يوليو 2018
 |حالة المسار              = bot: unknown
}}</ref> وغيرها.

{{هامش|6}}. يسبب استخدام تقنيات أمنية مثل [[الخصوصية المكافئة للشبكات السلكية]] (WEP) أو أشكال مختلفة من الوصول الآمن للشبكة اللاسلكية (WPA) لتشفير إطار البيانات زيادة في الحجم الأعظمي قد تصل حتى (20) بايت، ليصبح حجم وحدة النقل الأعظمي الأقصى هو (2324) بايت.<ref name = "JOU-14">{{استشهاد بدورية محكمة
|الأخير= Ross
|الأول= David Andrew
|عنوان= Securing IEEE 802.11 Wireless LANs
| تاريخ = يونيو 2010
|صفحة= 119
| ناشر= Queensland University of Technology
| مسار = https://eprints.qut.edu.au/37638/1/David_Ross_Thesis.pdf
| مسار أرشيف = https://web.archive.org/web/20170812122813/http://eprints.qut.edu.au/37638/1/David_Ross_Thesis.pdf | تاريخ أرشيف = 12 أغسطس 2017 }}</ref><ref name="Web-57">{{استشهاد بويب
| مسار أرشيف = https://web.archive.org/web/20170223070803/https://www.cwnp.com/forums/posts?postNum=307311
| تاريخ أرشيف = 23 فبراير2017
| تاريخ = 5 أغسطس 2005
| مسار= https://www.cwnp.com/forums/posts?postNum=307311
| عنوان= 802.11 Packet Size
| موقع= Certified Wireless Network Professionals.
| لغة= en
| تاريخ الوصول= 29 يوليو 2018}}</ref>
== مراجع ==
{{مراجع|محاذاة=نعم}}
== وصلات خارجية ==
* [https://web.archive.org/web/20180626203534/https://www.cdn.geeksforgeeks.org/fragmentation-network-layer/ التقطيع في طبقة الشبكة]، مقالة عن التقطيع في [[بروتوكول الإنترنت (الإصدار الرابع)|الإصدار الرابع من بروتوكول الإنترنت]].
* [https://web.archive.org/web/20180425142248/https://labs.ripe.net/Members/gih/evaluating-ipv4-and-ipv6-packet-fragmentation تقييم تقطيع رزم البيانات في الإصدارين الرابع والسادس من بروتوكول الإنترنت] مقالة بقلم جيف هوستن.
{{حزمة بروتوكولات الإنترنت}}
{{شريط بوابات|إنترنت|علم الحاسوب}}
{{شريط محتوى متميز|مختارة|التاريخ=30 يونيو 2019|النسخة=36323011}}

[[تصنيف:بروتوكول الإنترنت]]
[[تصنيف:وظائف ومفاهيم طبقة الشبكة]]
[[تصنيف:وظائف ومفاهيم طبقة النقل]]
[[تصنيف:وظائف ومفاهيم طبقة ربط البيانات]]