تقطيع (شبكات): الفرق بين النسختين
[نسخة منشورة] | [نسخة منشورة] |
وسم المقالة |
طلا ملخص تعديل |
||
(58 مراجعة متوسطة بواسطة 13 مستخدماً غير معروضة) | |||
سطر 1: | سطر 1: | ||
{{ |
{{عن|3=تقطيع (توضيح)}} |
||
[[ |
[[ملف:PDU Fragmentation-ar.png|تصغير|300بك|مثال عن تقطيع قسم حمولة [[وحدة بيانات بروتوكول|وحدة بيانات البروتوكول]] لينتج عنها قطع ذات طول أصغر من طول الحمولة الأصلية.]] |
||
في بعض طبقات [[نموذج |
في بعض من طبقات [[نموذج الربط البيني للأنظمة المفتوحة]] [[شبكة بيانات|لشبكات البيانات]]، '''التقطيع'''<ref name="almaany2">{{استشهاد بويكي بيانات|Q108442159|ص=72}}</ref> {{إنج|Fragmentation}} أو {{إنج|Segmentation}}<ref name="Web-17">{{استشهاد ويب |
||
| مسار= http://files.books.elebda3.net/download-pdf-ebooks.org-ku-12261.pdf |
|||
| عنوان= معنى كلمة segmentation مسرد مصطلحات المعلوماتية |
|||
| موقع= الجمعية العلمية السورية للمعلوماتية |
|||
| لغة= ar |
|||
| تاريخ الوصول= 30 يوليو 2018| وصلة مكسورة = yes }}</ref> أو '''التجزئة'''<ref name="almaany">{{مرجع ويب |
|||
| مسار= https://www.almaany.com/en/dict/ar-en/fragmentation/?c=Technology |
|||
| عنوان= معنى كلمة fragmentation في قاموس ومعجم المعاني الجامِع |
|||
| موقع= موقع المعاني |
|||
| لغة= ar |
|||
| تاريخ الوصول= 30 يوليو 2018}}</ref><ref name="almaany1">{{مرجع ويب |
|||
| مسار= http://files.books.elebda3.net/download-pdf-ebooks.org-ku-12261.pdf |
|||
| عنوان= معنى كلمة fragmentation مسرد مصطلحات المعلوماتية |
|||
| موقع= الجمعية العلمية السورية للمعلوماتية |
|||
| لغة= ar |
|||
| تاريخ الوصول= 30 يوليو 2018| وصلة مكسورة = yes }}</ref> {{إنج|Fragmentation}} أو {{إنج|Segmentation}}<ref name="Web-17">{{مرجع ويب |
|||
| مسار أرشيف = https://web.archive.org/web/20170425053540/http://productdevelop.blogspot.com/2013/09/differentiate-between-transparent-and.html |
| مسار أرشيف = https://web.archive.org/web/20170425053540/http://productdevelop.blogspot.com/2013/09/differentiate-between-transparent-and.html |
||
| تاريخ أرشيف = 25 أبريل 2017 |
| تاريخ أرشيف = 25 أبريل 2017 |
||
سطر 24: | سطر 9: | ||
| موقع= Blogspot |
| موقع= Blogspot |
||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 14 يوليو 2018}}</ref> |
| تاريخ الوصول= 14 يوليو 2018}}</ref> هو تقسيم [[حمولة (حوسبة)|الحمولة]] في [[وحدة بيانات بروتوكول]] إلى قسمين أو أكثر بأطوال أصغر من طول الحمولة الأصلية. يحصل التقطيع عندما يتجاوز طول حمولة وحدة بيانات البروتوكول عتبة مُحددة يحددها بروتوكول الطبقة. |
||
التقطيع هو وظيفة أساسية لبروتوكولات [[طبقة الشبكة]]،<ref name="Web-64">{{ |
التقطيع هو وظيفة أساسية لبروتوكولات [[طبقة الشبكة]]،<ref name="Web-64">{{استشهاد ويب |
||
| مؤلف = |
|||
| مسار أرشيف = https://web.archive.org/web/20180626203534/https://www.cdn.geeksforgeeks.org/fragmentation-network-layer/ |
| مسار أرشيف = https://web.archive.org/web/20180626203534/https://www.cdn.geeksforgeeks.org/fragmentation-network-layer/ |
||
| تاريخ أرشيف = 26 يونيو 2017 |
| تاريخ أرشيف = 26 يونيو 2017 |
||
| تاريخ = |
|||
| مسار= https://www.geeksforgeeks.org/fragmentation-network-layer/ |
| مسار= https://www.geeksforgeeks.org/fragmentation-network-layer/ |
||
| عنوان= Fragmentation at Network Layer |
| عنوان= Fragmentation at Network Layer |
||
| موقع= geeksforgeeks |
| موقع= geeksforgeeks |
||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 30 يوليو 2018}}</ref><ref name="Web-31"/> ولكنه قد يحصل في [[طبقة النقل]] أو في [[طبقة ربط البيانات]] أو في [[الطبقة المادية]].<ref name="Web-42"/> يهدف التقطيع بشكل الأساسي إلى توليد وحدات بيانات بروتوكول بأطوال أقل، لكنّه قد يُستخدم كجزء من آلية التقطيع والتوزيع في طبقة الربط (LFI)،<ref name="Web-26"/> أو لتحسين الوصول إلى الوسط المادي في الطبقة المادية.<ref name="Web-44"/> |
| تاريخ الوصول= 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بك|موقع [[ترويسة]] [[بروتوكول التحكم بالنقل]] عند تقطيع [[رزمة بيانات]] لبروتوكول الإنترنت، توجد الترويسة في القطعة الأولى فقط، ويسبب ذلك [[ثغرة أمنية]] يمكن استخدامها لإطلاق هجوم التقطيع عبر بروتوكول الإنترنت.]] |
[[ملف:TCP header location when fragmenting an IP packet - ar.png|تصغير|300بك|موقع [[ترويسة (حوسبة)|ترويسة]] [[بروتوكول التحكم بالنقل]] عند تقطيع [[رزمة بيانات]] لبروتوكول الإنترنت، توجد الترويسة في القطعة الأولى فقط، ويسبب ذلك [[ثغرة أمنية (حوسبة)|ثغرة أمنية]] يمكن استخدامها لإطلاق هجوم التقطيع عبر بروتوكول الإنترنت.]] |
||
بحسب [[نموذج |
بحسب [[نموذج الربط البيني للأنظمة المفتوحة|نموذج الاتصال المعياري]]، تتكون [[وحدة بيانات بروتوكول|وحدة بيانات البروتوكول]] في كل طبقة من [[حمولة (حوسبة)|حمولة]] و[[ترويسة (حوسبة)|ترويسة]]،<ref name="Web-40">{{استشهاد ويب |
||
| مؤلف = Charles M. Kozierok |
| مؤلف = Charles M. Kozierok |
||
| مسار أرشيف = https://web.archive.org/web/20170630085207/http://www.tcpipguide.com/free/t_DataEncapsulationProtocolDataUnitsPDUsandServiceDa.htm |
| مسار أرشيف = https://web.archive.org/web/20170630085207/http://www.tcpipguide.com/free/t_DataEncapsulationProtocolDataUnitsPDUsandServiceDa.htm |
||
سطر 53: | سطر 36: | ||
| موقع= TCP/IP guide |
| موقع= TCP/IP guide |
||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 23 يوليو 2018}}</ref> والتقطيع هو تقسيم الحمولة في بعض طبقات النموذج، إلى قطعتين أو أكثر بحيث تُشكّل كل |
| تاريخ الوصول= 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 |
| مسار أرشيف = https://web.archive.org/web/20180101021202/http://www.inetdaemon.com:80/tutorials/basic_concepts/communication/segmentation_and_reassembly.shtml |
||
| تاريخ أرشيف =1 يناير 2017 |
| تاريخ أرشيف =1 يناير 2017 |
||
| تاريخ = 6 أبريل 2014 |
| تاريخ = 6 أبريل 2014 |
||
| مسار= |
| مسار= https://www.inetdaemon.com/tutorials/basic_concepts/communication/segmentation_and_reassembly.shtml |
||
| عنوان= Segmentation, Fragmentation and Reassembly |
| عنوان= Segmentation, Fragmentation and Reassembly |
||
| موقع= InetDaemon Enterprises |
| موقع= InetDaemon Enterprises |
||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 23 يوليو 2018}}</ref> يحصل التقطيع في الطبقات الرابعة والثالثة والثانية والأولى من النموذج، وتحدد [[بروتوكول (اتصالات)|البروتوكولات]] التي تعمل في هذه الطبقات |
| تاريخ الوصول= 23 يوليو 2018}}</ref> يحصل التقطيع في الطبقات الرابعة والثالثة والثانية والأولى من النموذج، وتحدد [[بروتوكول (اتصالات)|البروتوكولات]] التي تعمل في هذه الطبقات قيمًا مُميزة لكل طبقة، تُستخدم كعتبة لتحديد متى يحصل التقطيع، فإذا كان طول وحدة بيانات البروتوكول أكبر من قيمة العتبة كان التقطيع إلزاميًّا.<ref name="Web-50">{{استشهاد ويب |
||
| مؤلف = |
|||
| مسار أرشيف = https://web.archive.org/web/20180223153949/http://www.linfo.org/mtu.html |
| مسار أرشيف = https://web.archive.org/web/20180223153949/http://www.linfo.org/mtu.html |
||
| تاريخ أرشيف = 23 فبراير 2018 |
| تاريخ أرشيف = 23 فبراير 2018 |
||
سطر 74: | سطر 55: | ||
| تاريخ الوصول= 25 يوليو 2018}}</ref> |
| تاريخ الوصول= 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 |
| مسار أرشيف = https://web.archive.org/web/20180703080025/https://docs.oracle.com/cd/E26505_01/html/E27061/ipov-29.html |
||
| تاريخ أرشيف =3 يوليو 2018 |
| تاريخ أرشيف =3 يوليو 2018 |
||
سطر 82: | سطر 63: | ||
| موقع= Oracle |
| موقع= Oracle |
||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 23 يوليو 2018}}</ref> يدعم [[بروتوكول التحكم بالنقل]] عملية التقطيع، وتسمى وحدة بيانات البروتوكول الناتجة عن تغليف أقسام الحمولة السابقة بترويسات البروتوكول قطعة {{إنج|Segment}}، أمّا [[بروتوكول حزم بيانات المستخدم]] فهو لا يدعم التقطيع، ويُغلّف الحمولة بإضافة ترويسته لها كما وردت، دون تقطيعها، وتسمى وحدة بيانات البروتوكول الناتجة حزمة البيانات {{إنج|Datagram}}. وفي الحالتين يتم تمرير وحدات بيانات البروتوكول الناتجة إلى [[طبقة الشبكة]].<ref name="Web-43">{{ |
| تاريخ الوصول= 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 |
| مسار أرشيف = 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 |
| تاريخ أرشيف =13 يوليو 2018 |
||
| تاريخ = 24 مارس 2008 |
| تاريخ = 24 مارس 2008 |
||
| مسار= https:// |
| مسار= 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 |
| عنوان= Segmentation vs fragmentation |
||
| موقع= Cisco systems, Inc. |
| موقع= Cisco systems, Inc. |
||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 23 يوليو 2018| |
| تاريخ الوصول= 23 يوليو 2018|url-status=dead}}</ref> |
||
التقطيع هو وظيفة أساسية لبروتوكولات الشبكة، وهو يحصل بعد اتخاذ قرار [[توجيه (شبكات)|التوجيه]] لوحدة بيانات البروتوكول، والتي تُسمى [[رزمة بيانات]] في هذه الطبقة، |
التقطيع هو وظيفة أساسية لبروتوكولات الشبكة، وهو يحصل بعد اتخاذ قرار [[توجيه (شبكات)|التوجيه]] لوحدة بيانات البروتوكول، والتي تُسمى [[رزمة بيانات]] في هذه الطبقة، وقد يكون في [[مضيف (حوسبة)|المُضيف]] المصدر الذي ولد الرزمة أو في أحد [[موجه (شبكات)|المُوجّهات]] على المسار، أو في كليهما. تتحدد عملية تقطيع رزمة البيانات بمقارنة طول الرزمة مع وحدة التقل العظمى لطبقة الشبكة، يحصل التقطيع إذا كان طول الرزمة أكبر من قيمة وحدة النقل العظمى، وهو يهدف إلى إنشاء رزم بيانات ذات طول أصغر من الرزمة الأصلية. يُمكن أن يحصل التقطيع أكثر من مرة على طول المسار لحين وصول الرزمة إلى وجهتها، ويُسمّى حينها بالتقطيع المُتعدد. لا يتمّ تجميع قطع الرزمة إلا في المُضيف الوجهة، والسبب في ذلك أن القطع قد لا تسلك نفس المسار، وبالتالي لن تمر عبر نفس المُوجّهات في طريقها للمضيف الوجهة.<ref name="Web-6">{{استشهاد ويب |
||
| مؤلف = uzair syed naveed |
| مؤلف = 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 مايو |
| تاريخ أرشيف = 17 مايو 20172020-05-09 |
||
| تاريخ = 25 أوكتوبر 2009 |
| تاريخ = 25 أوكتوبر 2009 |
||
| مسار= https:// |
| مسار= https://community.cisco.com/t5/switching/ip-reassembly-at-destination-host/td-p/1300609 |
||
| عنوان= IP reassembly at destination host |
| عنوان= IP reassembly at destination host |
||
| موقع= Cisco Systems, Inc. |
| موقع= Cisco Systems, Inc. |
||
سطر 105: | سطر 85: | ||
| تاريخ الوصول= 28 يونيو 2018}}</ref> تمرر طبقة الشبكة رزم البيانات إلى [[طبقة ربط البيانات]]. |
| تاريخ الوصول= 28 يونيو 2018}}</ref> تمرر طبقة الشبكة رزم البيانات إلى [[طبقة ربط البيانات]]. |
||
يُمكن أن يحصل التقطيع في طبقة ربط البيانات، إما لإنتاج أطر بيانات ذات طول أصغر، أو كجزء من آلية التقطيع والتوزيع في طبقة الربط {{إنج|Link Fragmentation and Interleaving اختصاراً LFI}}. يحصل التقطيع إذا كانت طول وحدة بيانات البروتوكول في طبقة ربط البيانات، ويسمى [[إطار البيانات]]، أكبر من قيمة وحدة النقل |
يُمكن أن يحصل التقطيع في طبقة ربط البيانات، إما لإنتاج أطر بيانات ذات طول أصغر، أو كجزء من آلية التقطيع والتوزيع في طبقة الربط {{إنج|Link Fragmentation and Interleaving اختصاراً LFI}}. يحصل التقطيع إذا كانت طول وحدة بيانات البروتوكول في طبقة ربط البيانات، ويسمى [[إطار البيانات]]، أكبر من قيمة وحدة النقل العظمى للطبقة. بعض بروتوكولات الربط لا يقوم بالتقطيع في هذه الطبقة، مثل الإيثرنت، ولكنه يحدد قيمة لوحدة النقل العظمى، ويجب على بروتوكول الشبكة أن يلتزم بها. تفرض بعض بروتوكولات الربط قيمة أعظمية محدودة بشكلٍ مُفرط لوحدة النقل العظمى، مثل {{وإو|أي تربل أي 802.15.4|IEEE 802.15.4|en|بروتوكول الشبكات الشخصية اللاسلكية منخفضة المُعدّل}} الذي يُحدد طول إطار البيانات الأعظمي ليكون 127 [[بايت]] فقط.<ref name = "JOU-10">{{استشهاد بدورية محكمة |
||
|صحيفة = IEEE STANDARD |
|صحيفة = IEEE STANDARD |
||
|عنوان= 802.15.4-2015 - IEEE Standard for Low-Rate Wireless Networks |
|عنوان= 802.15.4-2015 - IEEE Standard for Low-Rate Wireless Networks |
||
| |
| تاريخ = أبريل 2016 |
||
|شهر= أبريل |
|||
| ناشر= IEEE |
| ناشر= IEEE |
||
| doi = 10.1109/IEEESTD.2016.7460875 |
| doi = 10.1109/IEEESTD.2016.7460875 |
||
| isbn = 978-1-5044-0845-5 |
| isbn = 978-1-5044-0845-5 |
||
}}</ref> وقد يحصل التقطيع في [[الطبقة المادية]]، ولا يكون الهدف منه تقسيم وحدة بيانات البروتوكول إلى قطع أصغر، بل تحسين الوصول إلى وسط الاتصال المادي.<ref name = "JOU-11">{{ |
}}</ref> وقد يحصل التقطيع في [[طبقة مادية|الطبقة المادية]]، ولا يكون الهدف منه تقسيم وحدة بيانات البروتوكول إلى قطع أصغر، بل تحسين الوصول إلى وسط الاتصال المادي.<ref name = "JOU-11">{{استشهاد بدورية محكمة |
||
|الأخير= M. Frazier |
|الأخير= M. Frazier |
||
|الأول= Howard |
|الأول= Howard |
||
سطر 120: | سطر 99: | ||
|المجلد= 46 |
|المجلد= 46 |
||
|العدد = 2 |
|العدد = 2 |
||
| |
| تاريخ = مارس 2008 |
||
|شهر= مارس |
|||
|صفحة= 512 |
|صفحة= 512 |
||
| ناشر= IEEE |
| ناشر= IEEE |
||
| doi = 10.1109/MCOM.2008.4476164 |
| doi = 10.1109/MCOM.2008.4476164 |
||
| مسار = https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=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> |
|||
برتبط التقطيع بعملية [[تغليف (شبكات)|التغليف]] بشكلٍ وثيق، ويُسبب التقطيع زيادة في الطول الإجمالي للبيانات،<ref name="Web-15">{{ |
برتبط التقطيع بعملية [[تغليف (شبكات)|التغليف]] بشكلٍ وثيق، ويُسبب التقطيع زيادة في الطول الإجمالي للبيانات،<ref name="Web-15">{{استشهاد ويب |
||
| مؤلف = Charles M. Kozierok |
| مؤلف = Charles M. Kozierok |
||
| مسار أرشيف = https://web.archive.org/web/20170703132525/http://www.tcpipguide.com/free/t_IPMessageFragmentationProcess-2.htm |
| مسار أرشيف = https://web.archive.org/web/20170703132525/http://www.tcpipguide.com/free/t_IPMessageFragmentationProcess-2.htm |
||
سطر 137: | سطر 115: | ||
| موقع= The TCP/IP Guide |
| موقع= The TCP/IP Guide |
||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 13 يوليو 2018| |
| تاريخ الوصول= 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 |
| مسار أرشيف = 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 |
| تاريخ أرشيف = 21 مايو 2018 |
||
| تاريخ = |
|||
| مسار= https://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag.html |
| مسار= 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 |
| عنوان= Resolve IP Fragmentation, MTU, MSS, and PMTUD Issues with GRE and IPSEC |
||
| موقع= Cisco Systems, Inc. |
| موقع= Cisco Systems, Inc. |
||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 27 يونيو 2018}}</ref> فإذا كانت وحدة بيانات البروتوكول الأصليّة ذات طول ما |
| تاريخ الوصول= 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{Y=Y1+Y2+Y3}_{}}</math>}} |
||
سطر 153: | سطر 129: | ||
{{وسط|<math>{\text{X+(n-1)Z=X1+X2+..+Xn}_{}}</math>}} |
{{وسط|<math>{\text{X+(n-1)Z=X1+X2+..+Xn}_{}}</math>}} |
||
:حيث (<math>{\text{n}_{}}</math>) هي عدد القطع الناتجة عن عملية التقطيع. |
: حيث (<math>{\text{n}_{}}</math>) هي عدد القطع الناتجة عن عملية التقطيع. |
||
بالنسبة للبروتوكول الذي يقوم بالتقطيع كإحدى وظائف الطبقة، هناك نمطين للتقطيع، بحسب توافر إمكانية تجميع الرزمة الأصلية، الأول هو التقطيع المرئي أو الملحوظ بالنسبة للبروتوكول {{إنج|Transparent Fragmentation}}، وفيه يدرك البروتوكول عملية حصول التقطيع في أي نقطة في الشبكة، ونتيجة لذلك، يكون بإمكانه إعادة تجميع القطع ثم بناء حمولة الوحدة الأصلية، والثاني هو التقطيع غير المرئي أو غير الملحوظ بالنسبة للبروتوكول {{إنج|Non-Transparent Fragmentation}} وفيه لا يمكن للبروتوكول أن يعيد تجميع القطع إلا في وجهتها النهائية.<ref name="Web-19">{{ |
بالنسبة للبروتوكول الذي يقوم بالتقطيع كإحدى وظائف الطبقة، هناك نمطين للتقطيع، بحسب توافر إمكانية تجميع الرزمة الأصلية، الأول هو التقطيع المرئي أو الملحوظ بالنسبة للبروتوكول {{إنج|Transparent Fragmentation}}، وفيه يدرك البروتوكول عملية حصول التقطيع في أي نقطة في الشبكة، ونتيجة لذلك، يكون بإمكانه إعادة تجميع القطع ثم بناء حمولة الوحدة الأصلية، والثاني هو التقطيع غير المرئي أو غير الملحوظ بالنسبة للبروتوكول {{إنج|Non-Transparent Fragmentation}} وفيه لا يمكن للبروتوكول أن يعيد تجميع القطع إلا في وجهتها النهائية.<ref name="Web-19">{{استشهاد ويب |
||
| مؤلف = Joel Haefner |
| مؤلف = Joel Haefner |
||
| مسار= https://sun.iwu.edu/~jhaefner/CS390/Lecture13/lec13.htm |
| مسار= https://sun.iwu.edu/~jhaefner/CS390/Lecture13/lec13.htm |
||
سطر 161: | سطر 137: | ||
| موقع= Illinois Wesleyan University |
| موقع= Illinois Wesleyan University |
||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 15 يوليو 2018}}</ref> |
| تاريخ الوصول= 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 |
| مسار أرشيف = https://web.archive.org/web/20180627204301/https://tools.cisco.com/security/center/viewIpsSignature.x?signatureId=1200&signatureSubId=0&soft_1 |
||
| تاريخ أرشيف = 27 يونيو 2018 |
| تاريخ أرشيف = 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 |
| مسار= 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 |
| عنوان= IP Fragmentation Buffer |
||
| موقع= Cisco Systems |
| موقع= Cisco Systems |
||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 27 يونيو 2018}}</ref> فالتقطيع في طبقة الشبكة يسبب ثغرة أمنية، لأن ترويسة بروتوكول طبقة النقل التي تحتوي أرقام المنافذ لن تُوجد إلا في القطعة الأولى فقط،<ref name="Web-12">{{ |
| تاريخ الوصول= 27 يونيو 2018}}</ref> فالتقطيع في طبقة الشبكة يسبب ثغرة أمنية، لأن ترويسة بروتوكول طبقة النقل التي تحتوي أرقام المنافذ لن تُوجد إلا في القطعة الأولى فقط،<ref name="Web-12">{{استشهاد ويب |
||
| مسار أرشيف = https://web.archive.org/web/20180711172154/http://telescript.denayer.wenk.be/~hcr/cn/idoceo/udp_fragmentation.html |
| مسار أرشيف = https://web.archive.org/web/20180711172154/http://telescript.denayer.wenk.be/~hcr/cn/idoceo/udp_fragmentation.html |
||
| تاريخ أرشيف = 11 يوليو 2018 |
| تاريخ أرشيف = 11 يوليو 2018 |
||
سطر 182: | سطر 156: | ||
| موقع= De Nayer Instituut |
| موقع= De Nayer Instituut |
||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 11 يوليو 2018}}</ref> ويمكن أن يعتمد المهاجمون على غياب ترويسة بروتوكول النقل في باقي القطع لإطلاق هجوم يُعرف باسم بهجوم القطعة الصغيرة {{إنج|Tiny Segment Attack}} <ref name="ietf-4"/> أو قد يكون الهجوم |
| تاريخ الوصول= 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 |
| مسار أرشيف = https://web.archive.org/web/20170828001014/http://www.digital.net:80/~gandalf/Rose_Frag_Attack_Explained.htm |
||
| تاريخ أرشيف = 28 أغسطس 2017 |
| تاريخ أرشيف = 28 أغسطس 2017 |
||
سطر 189: | سطر 163: | ||
| موقع= Digintal.net |
| موقع= Digintal.net |
||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 27 يونيو 2018| |
| تاريخ الوصول= 27 يونيو 2018|url-status=dead}}</ref> |
||
يسبب الاعتماد على التقطيع العديد من المشاكل في الشبكة،<ref name = "Book-4">{{ |
يسبب الاعتماد على التقطيع العديد من المشاكل في الشبكة،<ref name = "Book-4">{{استشهاد بكتاب |
||
|مؤلف1= Ivan Pepelnjak |
|مؤلف1 = Ivan Pepelnjak |
||
|عنوان= The Never Ending Story of IP Fragmentation |
|عنوان = The Never Ending Story of IP Fragmentation |
||
|سنة=2008 |
|سنة = 2008 |
||
|ناشر= NIL Learning |
|ناشر = NIL Learning |
||
|لغة= en |
|لغة = 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 |
|||
}}</ref> فمثلاً يجب تجميع كل أجزاء الرزمة الأصلية قبل التمكن من استعادتها، ويسبب هذا إرهاقاً لموارد المُضيف الوجهة، بالإضافة لمشكلة القطعة الأخيرة التي قد تكون ذات حجم صغير، ويسبب إرسالها عبر الشبكة استهلاكاً غير مرغوب لمورد الشبكة.<ref name="Web-37">{{مرجع ويب |
|||
|تاريخ أرشيف = 25 مارس 2020 |
|||
|تاريخ الوصول = 30 يوليو 2018 |
|||
|حالة المسار = bot: unknown |
|||
}}</ref> فمثلًا يجب تجميع كل أجزاء الرزمة الأصلية قبل التمكن من استعادتها، ويسبب هذا إرهاقًا لموارد المُضيف الوجهة، بالإضافة لمشكلة القطعة الأخيرة التي قد تكون ذات حجم صغير، ويسبب إرسالها عبر الشبكة استهلاكًا غير مرغوب لمورد الشبكة.<ref name="Web-37">{{استشهاد ويب |
|||
| مؤلف = Marek Majkowski |
| مؤلف = Marek Majkowski |
||
| مسار أرشيف = https://web.archive.org/web/20180630205042/https://blog.cloudflare.com/ip-fragmentation-is-broken/ |
| مسار أرشيف = https://web.archive.org/web/20180630205042/https://blog.cloudflare.com/ip-fragmentation-is-broken/ |
||
| تاريخ أرشيف =30 يونيو 2018 |
| تاريخ أرشيف =30 يونيو 2018 |
||
| تاريخ = 18 أغسطس 2017 |
| تاريخ = 18 أغسطس 2017 |
||
| مسار= https://blog.cloudflare.com/ip-fragmentation-is-broken/fragmentation |
| مسار= https://blog.cloudflare.com/ip-fragmentation-is-broken/fragmentation/ |
||
| عنوان= Broken packets: IP fragmentation is flawed |
| عنوان= Broken packets: IP fragmentation is flawed |
||
| موقع= Cloudflare |
| موقع= Cloudflare |
||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 22 يوليو 2018| |
| تاريخ الوصول= 22 يوليو 2018|url-status=dead}}</ref> وأخيرًا، في حال تقطيع رزم أو أطر البيانات فإنّ معلومات تخص بروتوكول الطبقات العليا، مثل [[منفذ (شبكات)|أرقام المنافذ]] في طبقة النقل مثلًا لن تتواجد إلا في قطعة واحدة فقط، ما يعني أن [[جدار حماية (حوسبة)|جداران الحماية]] لا تستطيع أن تفحص هذه الرزم، ما يخلق بدوره [[ثغرة أمنية (حوسبة)|ثغرة أمنية]].<ref name = "JOU-2">{{استشهاد بدورية محكمة |
||
|الأخير= A. Kent |
|الأخير= A. Kent |
||
|الأول= Christopher |
|الأول= 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 |
|عنوان= Fragmentation considered harmful |
||
|المجلد= 17 |
|المجلد= 17 |
||
|العدد |
|العدد= 5 |
||
| |
|تاريخ= يناير 1995 |
||
|شهر= يناير |
|||
|صفحة= 75-87 |
|صفحة= 75-87 |
||
| |
|ناشر= ACM |
||
| |
|doi= 10.1145/205447.205456 |
||
|مسار= http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-87-3.pdf |
|||
| issn = |
|||
| |
|مسار أرشيف= 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> |
}}</ref> |
||
== آلية العمل == |
|||
==آلية العمل== |
|||
=== مفهوم الإزاحة === |
=== مفهوم الإزاحة === |
||
[[ |
[[ملف:Offset in Fragmentation - ar.png|تصغير|300بك|مفهوم الإزاحة عند تقطيع وحدة بيانات بروتوكول.]] |
||
إزاحة القطعة {{إنج|Fragment Offset}} هي قيمة تنتج أثناء عملية تقطيع [[حمولة (حوسبة)|حمولة]] [[وحدة بيانات بروتوكول]]، تحدد هذه القيمة الموقع النسبي لقطعة محددة بالنسبة لبقية القطع ضمن الحمولة الأصلية.<ref name="Web-10">{{ |
إزاحة القطعة {{إنج|Fragment Offset}} هي قيمة تنتج أثناء عملية تقطيع [[حمولة (حوسبة)|حمولة]] [[وحدة بيانات بروتوكول]]، تحدد هذه القيمة الموقع النسبي لقطعة محددة بالنسبة لبقية القطع ضمن الحمولة الأصلية.<ref name="Web-10">{{استشهاد ويب |
||
| مؤلف = |
|||
| مسار أرشيف = https://web.archive.org/web/20180623105322/https://www.sans.org/security-resources/glossary-of-terms/ |
| مسار أرشيف = https://web.archive.org/web/20180623105322/https://www.sans.org/security-resources/glossary-of-terms/ |
||
| تاريخ أرشيف = 23 يونيو 2018 |
| تاريخ أرشيف = 23 يونيو 2018 |
||
| تاريخ = |
|||
| مسار= https://www.sans.org/security-resources/glossary-of-terms/ |
| مسار= https://www.sans.org/security-resources/glossary-of-terms/ |
||
| عنوان= Glossary of Security Terms, F |
| عنوان= Glossary of Security Terms, F |
||
سطر 243: | سطر 219: | ||
| تاريخ الوصول= 29 يونيو 2018}}</ref> إنّ قيمة الإزاحة ضرورية لإنجاز عملية إعادة التجميع وبدونها لا يمكن إعادة تجميع القطع بالترتيب الصحيح لإعادة إنتاج وحدة بيانات البروتوكول الأصلية التي تمّ تقطيعها. |
| تاريخ الوصول= 29 يونيو 2018}}</ref> إنّ قيمة الإزاحة ضرورية لإنجاز عملية إعادة التجميع وبدونها لا يمكن إعادة تجميع القطع بالترتيب الصحيح لإعادة إنتاج وحدة بيانات البروتوكول الأصلية التي تمّ تقطيعها. |
||
تكون إزاحة القطعة الأولى مساوية للصفر |
تكون إزاحة القطعة الأولى مساوية للصفر دومًا.<ref name="Web-36"/> في حال حصول تقطيع متعدد، فإن قيمة الإزاحة تشير دائمًا إلى موقع القطعة الجديدة بالنسبة إلى الرزمة الأصلية في مرحلة التقطيع الأولى. |
||
=== إعادة التجميع === |
=== إعادة التجميع === |
||
[[ |
[[ملف:Time-based overlapped-fragment reassembly algorithms - ar.png|تصغير|300بك|خورازميات تجميع القطع المتراكبة بحسب تسلسل ورودها الزمني، إما باعتماد ما يرد أولًا عند التجميع أو ما يرد أخيرًا.]] |
||
إعادة التجميع {{إنج|Reassembly}} أو {{إنج|Defragmentation}} هي آلية لإعادة إنشاء [[وحدة بيانات بروتوكول|وحدة بيانات البروتوكول]] الأصلية |
إعادة التجميع {{إنج|Reassembly}} أو {{إنج|Defragmentation}} هي آلية لإعادة إنشاء [[وحدة بيانات بروتوكول|وحدة بيانات البروتوكول]] الأصلية انطلاقًا من القطع، وتتطلب عملية إعادة التجميع استقبال جميع القطع أولًا، والتي قد تصل بترتيب مختلف لترتيبها ضمن الوحدة الأصلية، ثُمّ يجب تحديد موقع القطع النسبي ضمن وحدة بيانات البروتوكول الأصلية، وأخيرًا، يتم استخلاص [[حمولة (حوسبة)|حمولة]] القطع والتخلص من [[ترويسة (حوسبة)|الترويسات]]، ثم يجري رصف القطع مع بعضها البعض بالترتيب الصحيح لإعادة إنشاء وحدة بيانات البروتوكول الأصلية.<ref name="Web-41"/> |
||
تحصل عملية إعادة تجميع الأطر |
تحصل عملية إعادة تجميع الأطر محليًّا في الوجهة التالية مباشرة في مسار حركة البيانات، ولا تغادر قطع الإطار [[شبكة محلية|الشبكة المحلية]]، أمّا [[رزمة بيانات|رزم البيانات]] فيجري تجميعها في الوجهة النهائية لحركة البيانات، لأن رزم بيانات مختلفة ناتجة عن تقطيع رزمة بيانات واحدة قد تسلك مسارات مختلفة لتصل إلى وجهتها، واختلاف المسارات يعني عدم إمكانية التجميع إلا في الوجهة النهائية،<ref name="Web-13">{{استشهاد ويب |
||
| مؤلف = Charles M. Kozierok |
| مؤلف = Charles M. Kozierok |
||
| مسار أرشيف = https://web.archive.org/web/20170615204930/http://www.tcpipguide.com/free/t_IPMessageReassemblyProcess.htm |
| مسار أرشيف = https://web.archive.org/web/20170615204930/http://www.tcpipguide.com/free/t_IPMessageReassemblyProcess.htm |
||
سطر 262: | سطر 238: | ||
| تاريخ الوصول= 11 يوليو 2018}}</ref> على الرغم من إمكانيّة التقطيع المتعدد في أي نقطة على مسار الرزم. |
| تاريخ الوصول= 11 يوليو 2018}}</ref> على الرغم من إمكانيّة التقطيع المتعدد في أي نقطة على مسار الرزم. |
||
قد تسمح [[خوارزمية]] التقطيع بإنشاء قطع مُتراكبة، أي أن أجزاء من الحمولة من توجد في أكثر من قطعة، ويسبب ذلك |
قد تسمح [[خوارزمية]] التقطيع بإنشاء قطع مُتراكبة، أي أن أجزاء من الحمولة من توجد في أكثر من قطعة، ويسبب ذلك تنوعًا في خوارزميات إعادة التجميع، فبعض الخوارزميات تعتمد الأجزاء التي وردت أولًا، وتهمل أجزاء القطع المكررة التي ترد لاحقًا، وهناك خوازميات أخرى تقوم بالعكس، فهي تعتمد الأجزاء الأحدث وصولًا عند إعادة التجميع، وتهمل أجزاء القطع المكررة التي وردت سابقًا، وهناك خوارزميات أخرى تأخد أيضًا إزاحة القطعة بالحسبان.<ref name="Web-32">{{استشهاد ويب |
||
| مؤلف = Mark Baggett |
| مؤلف = Mark Baggett |
||
| مسار أرشيف = https://web.archive.org/web/20180722113213/https://www.sans.org/reading-room/whitepapers/tools/ip-fragment-reassembly-scapy-33969 |
| مسار أرشيف = https://web.archive.org/web/20180722113213/https://www.sans.org/reading-room/whitepapers/tools/ip-fragment-reassembly-scapy-33969 |
||
سطر 273: | سطر 249: | ||
| تاريخ الوصول= 22 يوليو 2018}}</ref> |
| تاريخ الوصول= 22 يوليو 2018}}</ref> |
||
وصفت خوارزميات إعادة تجميع رزم بيانات [[الإصدار الرابع من بروتوكول الإنترنت]] في وثيقة [[طلب تعليقات|طلب التعليقات]] RFC 815.<ref name="ietf-7">{{ |
وصفت خوارزميات إعادة تجميع رزم بيانات [[بروتوكول الإنترنت (الإصدار الرابع)|الإصدار الرابع من بروتوكول الإنترنت]] في وثيقة [[طلب تعليقات|طلب التعليقات]] RFC 815.<ref name="ietf-7">{{استشهاد ويب |
||
| الأخير= D. Clark |
| الأخير= D. Clark |
||
| الأول= David |
| الأول= David |
||
| تاريخ= يوليو 1982 |
| تاريخ= يوليو 1982 |
||
| مسار أرشيف = https://web.archive.org/web/20160309181557/http://www.ietf.org/rfc/rfc815| مسار= https://www.ietf.org/rfc/rfc815 |
|||
| مسار أرشيف = |
|||
| مسار= https://www.ietf.org/rfc/rfc815 |
|||
| عنوان= RFC 815, IP DATAGRAM REASSEMBLY ALGORITHMS |
| عنوان= RFC 815, IP DATAGRAM REASSEMBLY ALGORITHMS |
||
| موقع= The Internet Society |
| موقع= The Internet Society |
||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 11 يوليو 2018}}</ref> |
| تاريخ الوصول= 11 يوليو 2018| تاريخ أرشيف = 9 مارس 2016 }}</ref> |
||
=== التقطيع المتعدد === |
=== التقطيع المتعدد === |
||
[[ |
[[ملف:Packet Fragmentation Example - ar.png|300بك|تصغير|مثال عن عملية تقطيع مُتعدد [[رزمة بيانات|لرزمة بيانات]] في [[شبكة حاسوب]]، يجري [[توجيه (شبكات)|توجيه]] [[رزمة بيانات|الرزمة]] من المصدر إلى الوجهة، ويتمّ تقطيعها مرتين، ثُمّ تسلك القطع مسارات مُختلفة ليصار إلى إعادة تجميعها في الوجهة.<ref name = "Book-2">{{استشهاد بكتاب |
||
|مؤلف1= Christoph Meinel |
|مؤلف1= Christoph Meinel |
||
|مؤلف2= Harald Sack |
|مؤلف2= Harald Sack |
||
سطر 292: | سطر 267: | ||
|سنة=2013 |
|سنة=2013 |
||
|ناشر= Springer Science & Business Media |
|ناشر= Springer Science & Business Media |
||
| |
|ردمك= 9783642353918 |
||
|لغة= en |
|لغة= en |
||
}}</ref>]] |
}}</ref>]] |
||
التقطيع المُتعدد هو تقسيم [[وحدة بيانات بروتوكول|وحدة بيانات البروتوكول]] أكثر من مرة أثناء سلوكها المسار بين مصدرها ووجهتها، يحصل التقطيع المُتعدد [[رزمة بيانات|لرزم بيانات]] [[الإصدار الرابع من بروتوكول الإنترنت]]، وينتج عنه رزم بيانات أصغر في كل مرة. لا يُوجد عدد محدد لمرات التقطيع المُمكنة، وطالما أن الرزمة تحتوي قسم بيانات قابل للتقطيع، فبالإمكان تقطيعها، لكن ذلك يؤثر على أداء الشبكة. |
التقطيع المُتعدد هو تقسيم [[وحدة بيانات بروتوكول|وحدة بيانات البروتوكول]] أكثر من مرة أثناء سلوكها المسار بين مصدرها ووجهتها، يحصل التقطيع المُتعدد [[رزمة بيانات|لرزم بيانات]] [[بروتوكول الإنترنت (الإصدار الرابع)|الإصدار الرابع من بروتوكول الإنترنت]]، وينتج عنه رزم بيانات أصغر في كل مرة. لا يُوجد عدد محدد لمرات التقطيع المُمكنة، وطالما أن الرزمة تحتوي قسم بيانات قابل للتقطيع، فبالإمكان تقطيعها، لكن ذلك يؤثر على أداء الشبكة. |
||
في كل مرة يتم فيها التقطيع يجب تحديد إزاحة القطع الجديدة، أي موقعها، بالنسبة لرزمة البيانات الأصلية في المصدر، وليس بالنسبة لرزمة البيانات التي جرى تقطيعها في هذه المرحلة،<ref name="Web-16">{{ |
في كل مرة يتم فيها التقطيع يجب تحديد إزاحة القطع الجديدة، أي موقعها، بالنسبة لرزمة البيانات الأصلية في المصدر، وليس بالنسبة لرزمة البيانات التي جرى تقطيعها في هذه المرحلة،<ref name="Web-16">{{استشهاد ويب |
||
| مؤلف = Charles M. Kozierok |
| مؤلف = Charles M. Kozierok |
||
| مسار أرشيف = https://web.archive.org/web/20171215235603/http://www.tcpipguide.com:80/free/t_IPMessageFragmentationProcess-3.htm |
| مسار أرشيف = https://web.archive.org/web/20171215235603/http://www.tcpipguide.com:80/free/t_IPMessageFragmentationProcess-3.htm |
||
سطر 307: | سطر 282: | ||
| موقع= The TCP/IP Guide |
| موقع= The TCP/IP Guide |
||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 13 يوليو 2018}}</ref> ونتيجة لذلك، وبما أن إعادة تجميع الرزم لا تحصل إلا في الوجهة النهائيّة، فإن تلك الوجهة قد تستقبل |
| تاريخ الوصول= 13 يوليو 2018}}</ref> ونتيجة لذلك، وبما أن إعادة تجميع الرزم لا تحصل إلا في الوجهة النهائيّة، فإن تلك الوجهة قد تستقبل قطعًا مُختلفة الطول. فإنّ سلكت الرزم مسارًا مُختلفًا بين المصدر والوجهة، فقد يتمّ تقطيعها بشكلٍ مُتعدد بحسب مسارها، وبالتالي فإن عدد القطع الناتجة يتعلق بالمسار المسلوك، أمّا قيمة إزاحة القطع لإعادة بناء الرزمة الأصلية فيجب أن تدل على موقع القطعة في الرزمة الأصلية بغض النظر عن المسار التي سلكته. |
||
لتجنب التقطيع المتعدد، هناك ميزة إضافية للإصدار الرابع من بروتوكول الإنترنت هي ميزة اكتشاف وحدة النقل |
لتجنب التقطيع المتعدد، هناك ميزة إضافية للإصدار الرابع من بروتوكول الإنترنت هي ميزة اكتشاف وحدة النقل العظمى للمسار، وهي تعتمد على [[بروتوكول رسائل التحكم في الإنترنت]]، وموصوفة في [[طلب تعليقات|وثيقة طلب التعليقات]] RFC 1191.<ref name="ietf-11">{{استشهاد ويب |
||
| الأخير= Mogul |
| الأخير= Mogul |
||
| الأول= J. |
| الأول= J. |
||
| |
| مؤلف2-الأخير= Deering |
||
| |
| مؤلف2-الأول= S. |
||
| تاريخ= نوفمبر 1990 |
| تاريخ= نوفمبر 1990 |
||
| مسار أرشيف = https://web.archive.org/web/20190620121637/https://tools.ietf.org/html/rfc1191| مسار= https://tools.ietf.org/html/rfc1191 |
|||
| مسار أرشيف = |
|||
| مسار= https://tools.ietf.org/html/rfc1191 |
|||
| عنوان= RFC 1191, Path MTU Discovery |
| عنوان= RFC 1191, Path MTU Discovery |
||
| موقع= The Internet Society |
| موقع= The Internet Society |
||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 13 يوليو 2018}}</ref> أمّا في العُقد التي تُشغّل [[الإصدار السادس من بروتوكول الإنترنت]]، فإنّها |
| تاريخ الوصول= 13 يوليو 2018| تاريخ أرشيف = 20 يونيو 2019 }}</ref> أمّا في العُقد التي تُشغّل [[بروتوكول الإنترنت (الإصدار السادس)|الإصدار السادس من بروتوكول الإنترنت]]، فإنّها غالبًا ما تدعم هذه التقنية بشكلٍ افتراضي، وقد أُشير إليها في معيار البروتوكول الأصلي، ووصفت بشكل مفصل في وثيقة طلب التعليقات RFC 8201.<ref name="ietf-12">{{استشهاد ويب |
||
| الأخير= McCann |
| الأخير= McCann |
||
| الأول= J. |
| الأول= J. |
||
| |
| مؤلف2-الأخير= Deering |
||
| |
| مؤلف2-الأول= S. |
||
| |
| مؤلف3-الأخير= Mogul |
||
| |
| مؤلف3-الأول= J. |
||
| |
| مؤلف4-الأخير= Hinden, Ed. |
||
| |
| مؤلف4-الأول= R. |
||
| تاريخ= يوليو 2017 |
| تاريخ= يوليو 2017 |
||
| مسار أرشيف = https://web.archive.org/web/20190321014214/https://tools.ietf.org/html/rfc8201| مسار= https://tools.ietf.org/html/rfc8201 |
|||
| مسار أرشيف = |
|||
| مسار= https://tools.ietf.org/html/rfc8201 |
|||
| عنوان= RFC 8201, Path MTU Discovery for IP version 6 |
| عنوان= RFC 8201, Path MTU Discovery for IP version 6 |
||
| موقع= The Internet Society |
| موقع= The Internet Society |
||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 13 يوليو 2018}}</ref> |
| تاريخ الوصول= 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 |
| مسار أرشيف = 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 |
| تاريخ أرشيف = 2 أغسطس 2014 |
||
| تاريخ = |
|||
| مسار= https://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag.pdf |
| مسار= 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 |
| عنوان= Resolve IP Fragmentation, MTU, MSS, and PMTUD issues with GRE and IPSEC |
||
سطر 350: | سطر 321: | ||
| تاريخ الوصول= 15 يوليو 2018}}</ref> قد لا يتمكن المصدر من تحديد حجم النقل الأعظمي الأدنى بدقة، ولكن استعمال هذه الآليّة يساعده على توليد رزم بيانات ذات أطوال أقل أو تساوي أدنى قيمة لحجم النقل الأعظمي على طول المسار.<ref name="Book-4"/> |
| تاريخ الوصول= 15 يوليو 2018}}</ref> قد لا يتمكن المصدر من تحديد حجم النقل الأعظمي الأدنى بدقة، ولكن استعمال هذه الآليّة يساعده على توليد رزم بيانات ذات أطوال أقل أو تساوي أدنى قيمة لحجم النقل الأعظمي على طول المسار.<ref name="Book-4"/> |
||
إذا استُخدم [[الإصدار الرابع من بروتوكول الإنترنت]] كبروتوكول [[طبقة الشبكة|شبكة]]، فإنّ آليّة الاكتشاف الخاصّة به هي [[برنامج مساعد (حوسبة)|توسيعة إضافية]] تعتمد على [[بروتوكول رسائل التحكم في الإنترنت]]،{{للهامش|1}} وعلى علم عدم التقطيع في [[ترويسة]] البروتوكول.<ref name="ietf-22">{{ |
إذا استُخدم [[بروتوكول الإنترنت (الإصدار الرابع)|الإصدار الرابع من بروتوكول الإنترنت]] كبروتوكول [[طبقة الشبكة|شبكة]]، فإنّ آليّة الاكتشاف الخاصّة به هي [[برنامج مساعد (حوسبة)|توسيعة إضافية]] تعتمد على [[بروتوكول رسائل التحكم في الإنترنت]]،{{للهامش|1}} وعلى علم عدم التقطيع في [[ترويسة (حوسبة)|ترويسة]] البروتوكول.<ref name="ietf-22">{{استشهاد ويب |
||
| الأخير= West |
| الأخير= West |
||
| الأول= M. |
| الأول= M. |
||
| |
| مؤلف2-الأخير= McCann |
||
| |
| مؤلف2-الأول= S. |
||
| تاريخ= مارس 2006 |
| تاريخ= مارس 2006 |
||
| مسار أرشيف = https://web.archive.org/web/20120811041843/http://www.ietf.org/rfc/rfc4413| مسار= https://www.ietf.org/rfc/rfc4413 |
|||
| مسار أرشيف = |
|||
| مسار= https://www.ietf.org/rfc/rfc4413 |
|||
| عنوان= RFC 4413, TCP/IP Field Behavior |
| عنوان= RFC 4413, TCP/IP Field Behavior |
||
| موقع= The Internet Society |
| موقع= The Internet Society |
||
| صفحة = 22 |
| صفحة = 22 |
||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 22 يوليو 2018}}</ref> تعتمد الآليّة على قيام المصدر بتوليد رزم بيانات بأطوال متغيرة مع رفع علم عدم التقطيع فيها، فإنّ لم يكن بالإمكان نقل الرزمة عبر شبكة ما بسبب حجمها يجري التخلص منها، ثُمّ إعلام المصدر بذلك عن طريق رسالة مُناسبة من رسائل بروتوكول التحكم في شبكة الإنترنت.<ref name="ietf-11"/> |
| تاريخ الوصول= 22 يوليو 2018| تاريخ أرشيف = 11 أغسطس 2012 }}</ref> تعتمد الآليّة على قيام المصدر بتوليد رزم بيانات بأطوال متغيرة مع رفع علم عدم التقطيع فيها، فإنّ لم يكن بالإمكان نقل الرزمة عبر شبكة ما بسبب حجمها يجري التخلص منها، ثُمّ إعلام المصدر بذلك عن طريق رسالة مُناسبة من رسائل بروتوكول التحكم في شبكة الإنترنت.<ref name="ietf-11"/> |
||
إذا استخدم [[الإصدار السادس من بروتوكول الإنترنت]] كبروتوكول شبكة، فإنّ آليّة الاكتشاف الخاصة به هي جزء مُدمج منه، ولابد من استعمالها قبل إرسال أي رزمة حتى لو كان المضيف المصدر يعتقد أن الوجهة موجودة في نفس [[شبكة محلية|الشبكة المحلية]]. تعتمد هذه الآلية على بروتوكول رسائل التحكم للإصدار السادس من بروتوكول الإنترنت،{{للهامش|2}} وبالتحديد رسالة "رزمة كبيرة جداً" والتي تُرسلها [[عقدة (شبكات)|عقدة]] ما على المسار، وتكون وجهة الرسالة هي مصدر رزمة بيانات لم تتمكن العقدة من إرسالها نحو الخطوة التالية على المسار، وذلك بسبب طولها، يجب على المصدر عندها أن يُعيد ضبط أطوال الرزم التي يُرسلها اعتماداً على هذه ما جاء في هذه الرسالة.<ref name="ietf-12"/> |
|||
إذا استخدم [[بروتوكول الإنترنت (الإصدار السادس)|الإصدار السادس من بروتوكول الإنترنت]] كبروتوكول شبكة، فإنّ آليّة الاكتشاف الخاصة به هي جزء مُدمج منه، ولابد من استعمالها قبل إرسال أي رزمة حتى لو كان المضيف المصدر يعتقد أن الوجهة موجودة في نفس [[شبكة محلية|الشبكة المحلية]]. تعتمد هذه الآلية على بروتوكول رسائل التحكم للإصدار السادس من بروتوكول الإنترنت،{{للهامش|2}} وبالتحديد رسالة «رزمة كبيرة جدًّا» والتي تُرسلها [[عقدة (شبكات)|عقدة]] ما على المسار، وتكون وجهة الرسالة هي مصدر رزمة بيانات لم تتمكن العقدة من إرسالها نحو الخطوة التالية على المسار، وذلك بسبب طولها، يجب على المصدر عندها أن يُعيد ضبط أطوال الرزم التي يُرسلها اعتمادًا على هذه ما جاء في هذه الرسالة.<ref name="ietf-12"/> |
|||
== التقطيع في طبقة النقل == |
== التقطيع في طبقة النقل == |
||
إنّ التقطيع ليس وظيفة إلزامية لبروتوكولات [[طبقة النقل]]، ولكن يساعد إنجاز عملية تقطيع مناسبة في هذه الطبقة في المضيف المصدر على تجنب أي عمليات تقطيع لاحقة سواءً في الطبقات الدنيا من نموذج الشبكة المستعمل في المضيف المصدر، أو في عقد الشبكات على طول المسار، ويؤثر ذلك بشكل مباشر على الأداء.<ref name = "JOU-6">{{استشهاد بدورية محكمة |
|||
إنّ التقطيع ليس وظيفة إلزامية لبروتوكولات [[طبقة النقل]]، ولكن يساعد إنجاز عملية تقطيع مناسبة في هذه الطبقة في المضيف المصدر على تجنب أي عمليات تقطيع لاحقة سواءً في الطبقات الدنيا من نموذج الشبكة المستعمل في المضيف المصدر، أو في عقد الشبكات على طول المسار، ويؤثر ذلك بشكل مباشر على الأداء.<ref name = "JOU-6">{{Cite journal |
|||
|الأخير= Genkov |
|الأخير= Genkov |
||
|الأول= Delian |
|الأول= Delian |
||
| |
|مؤلف2-الأخير= Ilarionov |
||
| |
|مؤلف2-الأول= Raycho |
||
|صحيفة = International Conference on Computer Systems and Technologies - CompSysTech’06 |
|صحيفة = International Conference on Computer Systems and Technologies - CompSysTech’06 |
||
|عنوان= Avoiding IP Fragmentation at the Transport Layer of the OSI Reference Model |
|عنوان= 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 |
| مسار = http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.87.3395&rep=rep1&type=pdf |
||
}}</ref> يدعم [[بروتوكول التحكم بالنقل]] آلية لتقطيع حمولة وحدة البيانات، وتسمى الوحدات الجديدة الناتجة عن التقطيع و[[تغليف (شبكات)|التغليف]] |
| مسار أرشيف = 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 |
| الأخير= Postal |
||
| الأول= J. |
| الأول= J. |
||
سطر 387: | سطر 353: | ||
| موقع= The Internet Society |
| موقع= The Internet Society |
||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 22 يوليو 2017| مسار |
| تاريخ الوصول= 22 يوليو 2017| مسار أرشيف = https://web.archive.org/web/20190505045142/https://tools.ietf.org/html/rfc793 | تاريخ أرشيف = 5 مايو 2019 }}</ref> في حين لا يقوم [[بروتوكول حزم بيانات المستخدم]] بعملية التقطيع، وعند استخدامه يجب أن تقوم التطبيقات بتوليد البيانات بشكل متقطع بطريقة يمكن من خلالها [[طبقة الشبكة|لطبقة الشبكة]] أن تقوم بتوليد رزم البيانات بناء على هذه القطع.<ref name="Web-8">{{استشهاد ويب |
||
| مؤلف = James Curtis |
| مؤلف = James Curtis |
||
| مسار أرشيف = https://web.archive.org/web/20170506212612/https://wand.net.nz/pubs/19/html/node6.html |
| مسار أرشيف = https://web.archive.org/web/20170506212612/https://wand.net.nz/pubs/19/html/node6.html |
||
سطر 399: | سطر 365: | ||
=== التقطيع في بروتوكول التحكم بالنقل === |
=== التقطيع في بروتوكول التحكم بالنقل === |
||
في [[بروتوكول التحكم بالنقل]] هناك مفهوم خاص مُرتبط بالتقطيع هو مقاس القطعة الأعظمي {{إنج| Maximum Segment Size اختصاراً MSS}} وهو يحدد [[حمولة (حوسبة)|الحمولة]] أو حجم البيانات التي يمكن [[مضيف (حوسبة)|لمُضيف]] ما أن يستقبله ضمن قطعة واحدة، يجب |
في [[بروتوكول التحكم بالنقل]] هناك مفهوم خاص مُرتبط بالتقطيع هو مقاس القطعة الأعظمي {{إنج| Maximum Segment Size اختصاراً MSS}} وهو يحدد [[حمولة (حوسبة)|الحمولة]] أو حجم البيانات التي يمكن [[مضيف (حوسبة)|لمُضيف]] ما أن يستقبله ضمن قطعة واحدة، يجب الانتباه إلى أن [[ترويسة (حوسبة)|ترويسة]] بروتوكول التحكم بالنقل غير مُشمولة ضمن مقاس القطعة الأعظمي، على عكس و[[وحدة النقل العظمى]] الخاصة ب[[طبقة الشبكة]]، التي تشمل ترويسة بروتوكول الشبكة بالإضافة للحمولة في وحدة بيانات بروتوكول تلك الطبقة.<ref name="ietf-1">{{استشهاد ويب |
||
| الأخير= Postel |
| الأخير= Postel |
||
| الأول= J. |
| الأول= J. |
||
| تاريخ= نوفمبر 1983 |
| تاريخ= نوفمبر 1983 |
||
| مسار أرشيف = https://web.archive.org/web/20160308070820/http://www.ietf.org/rfc/rfc879| مسار= https://www.ietf.org/rfc/rfc879 |
|||
| مسار أرشيف = |
|||
| مسار= https://www.ietf.org/rfc/rfc879 |
|||
| عنوان= RFC 879, The TCP Maximum Segment Size and Related Topics |
| عنوان= RFC 879, The TCP Maximum Segment Size and Related Topics |
||
| صفحة = 2 |
| صفحة = 2 |
||
| موقع= The Internet Society |
| موقع= The Internet Society |
||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 28 يوليو 2018}}</ref><ref name="Web-9">{{ |
| تاريخ الوصول= 28 يوليو 2018| تاريخ أرشيف = 8 مارس 2016 }}</ref><ref name="Web-9">{{استشهاد ويب |
||
| مؤلف = Nurul Islam Roman |
| مؤلف = 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/ |
| مسار أرشيف = https://web.archive.org/web/20170517051329/https://blog.apnic.net/2014/12/15/ip-mtu-and-tcp-mss-missmatch-an-evil-for-network-performance/ |
||
سطر 420: | سطر 385: | ||
| تاريخ الوصول= 28 يونيو 2018}}</ref> |
| تاريخ الوصول= 28 يونيو 2018}}</ref> |
||
إنّ اختيار مقاس القطعة الأعظمي الخاص ببروتوكول التحكم بالنقل يُؤثّر بشكل مباشر على عملية تقطيع [[رزمة بيانات|رزم البيانات]] في طبقة الشبكة، فإذا كانت القيمة كبيرة |
إنّ اختيار مقاس القطعة الأعظمي الخاص ببروتوكول التحكم بالنقل يُؤثّر بشكل مباشر على عملية تقطيع [[رزمة بيانات|رزم البيانات]] في طبقة الشبكة، فإذا كانت القيمة كبيرة جدًّا، كان التقطيع في طبقة الشبكة إلزاميًّا، أمّا إذا كانت صغيرة جدًّا، فلا يحصل تقطيع أبدًا، ولكن الكلفة غير المباشرة لذلك ستكون باهظة ومُؤثّرة على فعاليّة الإرسال، بسبب وجود حمل إضافي كبير هو مجموع أطوال الترويسات المُضافة إلى الرزم الصغيرة.<ref name="ietf-4">{{استشهاد ويب |
||
| الأخير= Ziemba |
| الأخير= Ziemba |
||
| الأول= G. |
| الأول= G. |
||
| |
| مؤلف2-الأخير= Reed |
||
| |
| مؤلف2-الأول= D. |
||
| |
| مؤلف3-الأخير= Traina |
||
| |
| مؤلف3-الأول= P. |
||
| تاريخ= أوكتوبر 1995 |
| تاريخ= أوكتوبر 1995 |
||
| مسار أرشيف = |
| مسار أرشيف = https://web.archive.org/web/20200509163436/https://www.ietf.org/rfc/rfc1858 |
||
| مسار= https://www.ietf.org/rfc/rfc1858 |
| مسار= https://www.ietf.org/rfc/rfc1858 |
||
| عنوان= RFC 1858, Security Considerations for IP Fragment Filtering |
| عنوان= RFC 1858, Security Considerations for IP Fragment Filtering |
||
| موقع= The Internet Society |
| موقع= The Internet Society |
||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 1 يوليو 2018}}</ref> يتم التحكّم بمقاس القطعة الأعظمي في بروتوكول التحكم بالنقل بشكل آليّ لتكون مُتوافقة مع قيمة [[نافذة منزلقة|النافذة المنزلقة]] الخاصة بالاتصال الذي قام البروتوكول بإنشائه.<ref name="Web-5">{{ |
| تاريخ الوصول= 1 يوليو 2018|تاريخ أرشيف=2020-05-09}}</ref> يتم التحكّم بمقاس القطعة الأعظمي في بروتوكول التحكم بالنقل بشكل آليّ لتكون مُتوافقة مع قيمة [[نافذة منزلقة|النافذة المنزلقة]] الخاصة بالاتصال الذي قام البروتوكول بإنشائه.<ref name="Web-5">{{استشهاد ويب |
||
| مؤلف = Charles M. Kozierok |
| مؤلف = Charles M. Kozierok |
||
| مسار أرشيف = https://web.archive.org/web/20170111074031/http://www.tcpipguide.com/free/t_TCPMaximumSegmentSizeMSSandRelationshiptoIPDatagra.htm |
| مسار أرشيف = https://web.archive.org/web/20170111074031/http://www.tcpipguide.com/free/t_TCPMaximumSegmentSizeMSSandRelationshiptoIPDatagra.htm |
||
سطر 444: | سطر 409: | ||
| تاريخ الوصول= 28 يونيو 2018}}</ref> |
| تاريخ الوصول= 28 يونيو 2018}}</ref> |
||
إنّ القيمة الافتراضية لمقاس القطعة الأعظمي هي (536) [[بايت]]،<ref name="ietf-2">{{ |
إنّ القيمة الافتراضية لمقاس القطعة الأعظمي هي (536) [[بايت]]،<ref name="ietf-2">{{استشهاد ويب |
||
| الأخير= Postel |
| الأخير= Postel |
||
| الأول= J. |
| الأول= J. |
||
| تاريخ= نوفمبر 1983 |
| تاريخ= نوفمبر 1983 |
||
| مسار أرشيف = https://web.archive.org/web/20160308070820/http://www.ietf.org/rfc/rfc879| مسار= https://www.ietf.org/rfc/rfc879#Page1 |
|||
| مسار أرشيف = |
|||
| مسار= https://www.ietf.org/rfc/rfc879#Page1 |
|||
| عنوان= RFC 879, The TCP Maximum Segment Size and Related Topics |
| عنوان= RFC 879, The TCP Maximum Segment Size and Related Topics |
||
| صفحة = 1 |
| صفحة = 1 |
||
| موقع= The Internet Society |
| موقع= The Internet Society |
||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 28 يوليو 2018}}</ref> وهي تضبط بشكل مستقل لكل طرف، ويمكن التفاوض على قيمتها في الاتجاهين بين الطرفين عند إنشاء الاتصال، ولكن لا يمكن تغييرها بعد ذلك.<ref name="ietf-3">{{ |
| تاريخ الوصول= 28 يوليو 2018| تاريخ أرشيف = 8 مارس 2016 }}</ref> وهي تضبط بشكل مستقل لكل طرف، ويمكن التفاوض على قيمتها في الاتجاهين بين الطرفين عند إنشاء الاتصال، ولكن لا يمكن تغييرها بعد ذلك.<ref name="ietf-3">{{استشهاد ويب |
||
| الأخير= Postal |
| الأخير= Postal |
||
| الأول= J. |
| الأول= J. |
||
سطر 463: | سطر 427: | ||
| صفحة = 19 |
| صفحة = 19 |
||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 28 يونيو 2018| مسار |
| تاريخ الوصول= 28 يونيو 2018| مسار أرشيف = https://web.archive.org/web/20190505045142/https://tools.ietf.org/html/rfc793 | تاريخ أرشيف = 5 مايو 2019 }}</ref> |
||
== التقطيع في طبقة الشبكة == |
== التقطيع في طبقة الشبكة == |
||
{| class="wikitable floatleft" width="65%" |
{| class="wikitable floatleft" width="65%" |
||
|- |
|- |
||
|+ قيم وحدة النقل |
|+ قيم وحدة النقل العظمى [[:تصنيف:بروتوكولات تشبيك|لبروتوكولات التشبيك]].{{للهامش|3}} |
||
|- |
|- |
||
! اسم البروتوكول !! اختصار !! حجم وحدة النقل |
! اسم البروتوكول !! اختصار !! حجم وحدة النقل العظمى الأعظمي (بايت) !! حجم وحدة النقل العظمى الأدنى (بايت) !!المرجع |
||
|- |
|- |
||
| [[الإصدار الرابع من بروتوكول الإنترنت]] || IPv4|| 65536 || 68 || |
| [[بروتوكول الإنترنت (الإصدار الرابع)|الإصدار الرابع من بروتوكول الإنترنت]] || IPv4|| 65536 || 68 || <ref name="ietf-5"/> |
||
|- |
|- |
||
| [[الإصدار السادس من بروتوكول الإنترنت]] || IPv6 || 65576 {{Refn|لم يرد ذكر الرقم بشكل صريح في معيار البروتوكول، ولكن يُمكن حسابه من مجموع الطول الأعظمي المسموح للحمولة وهو (65536) بايت، مع طول الترويسة (40) بايت. |group=lower-alpha}}|| 1280 || <ref name="ietf-9">{{ |
| [[بروتوكول الإنترنت (الإصدار السادس)|الإصدار السادس من بروتوكول الإنترنت]] || IPv6 || 65576 {{Refn|لم يرد ذكر الرقم بشكل صريح في معيار البروتوكول، ولكن يُمكن حسابه من مجموع الطول الأعظمي المسموح للحمولة وهو (65536) بايت، مع طول الترويسة (40) بايت. |group=lower-alpha}}|| 1280 || <ref name="ietf-9">{{استشهاد ويب |
||
| الأخير= Deering |
| الأخير= Deering |
||
| الأول= S. |
| الأول= S. |
||
| |
| مؤلف2-الأخير= Hinden |
||
| |
| مؤلف2-الأول= R. |
||
| تاريخ= يوليو 2017 |
| تاريخ= يوليو 2017 |
||
| مسار أرشيف = https://web.archive.org/web/20190626225115/https://tools.ietf.org/html/rfc8200| مسار= https://tools.ietf.org/html/rfc8200 |
|||
| سنة= 2017 |
|||
| شهر= يوليو |
|||
| مسار أرشيف = |
|||
| مسار= https://tools.ietf.org/html/rfc8200 |
|||
| عنوان= RFC 8200, Internet Protocol, Version 6 (IPv6) Specification |
| عنوان= RFC 8200, Internet Protocol, Version 6 (IPv6) Specification |
||
| موقع= The Internet Society |
| موقع= The Internet Society |
||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 13 يوليو 2018}}</ref> |
| تاريخ الوصول= 13 يوليو 2018| تاريخ أرشيف = 26 يونيو 2019 }}</ref> |
||
|- |
|- |
||
|} |
|} |
||
{{يسار|'''مُلاحظات'''<br>{{مراجع|group=lower-alpha}}}} |
{{يسار|'''مُلاحظات'''<br />{{مراجع|group=lower-alpha}}}} |
||
{{شريط جانبي بروتوكول الإنترنت}} |
|||
إنّ تقطيع [[رزمة بيانات|رزم البيانات]] وإعادة تجميعها هو وظيفة رئيسية [[بروتوكول (اتصالات)|لبروتوكولات]] [[طبقة الشبكة|الشبكة]].<ref name="Web-64"/><ref name="Web-31">{{ |
إنّ تقطيع [[رزمة بيانات|رزم البيانات]] وإعادة تجميعها هو وظيفة رئيسية [[بروتوكول (اتصالات)|لبروتوكولات]] [[طبقة الشبكة|الشبكة]].<ref name="Web-64"/><ref name="Web-31">{{استشهاد ويب |
||
| مؤلف = Charles M. Kozierok. |
| مؤلف = Charles M. Kozierok. |
||
| مسار أرشيف = https://web.archive.org/web/20170730053649/http://www.tcpipguide.com/free/t_NetworkLayerLayer3.htm |
| مسار أرشيف = https://web.archive.org/web/20170730053649/http://www.tcpipguide.com/free/t_NetworkLayerLayer3.htm |
||
سطر 502: | سطر 461: | ||
| موقع= The TCP/IP Guide |
| موقع= The TCP/IP Guide |
||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 22 يوليو 2018}}</ref> يدعم الإصداران الرابع<ref name="ietf-5">{{ |
| تاريخ الوصول= 22 يوليو 2018}}</ref> يدعم الإصداران الرابع<ref name="ietf-5">{{استشهاد ويب |
||
| الأخير= Postel |
| الأخير= Postel |
||
| الأول= J. |
| الأول= J. |
||
| تاريخ= سبتمبر 1981 |
| تاريخ= سبتمبر 1981 |
||
| مسار أرشيف = https://web.archive.org/web/20190918221259/https://tools.ietf.org/html/rfc791| مسار= https://tools.ietf.org/html/rfc791 |
|||
| سنة= 1981 |
|||
| شهر= سبتمبر |
|||
| مسار أرشيف = |
|||
| مسار= https://tools.ietf.org/html/rfc791 |
|||
| عنوان= RFC 791, Internet Protocol, DARPA Internet Program Protocol Specification |
| عنوان= RFC 791, Internet Protocol, DARPA Internet Program Protocol Specification |
||
| موقع=The Internet Society |
| موقع=The Internet Society |
||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 1 يوليو 2018}}</ref> والسادس<ref name="ietf-9"/> من بروتوكول الإنترنت تقطيع حمولة رزم البيانات التي يتجاوز طولها قيمة محددة، إلى قطع |
| تاريخ الوصول= 1 يوليو 2018| تاريخ أرشيف = 18 سبتمبر 2019 }}</ref> والسادس<ref name="ietf-9"/> من بروتوكول الإنترنت تقطيع حمولة رزم البيانات التي يتجاوز طولها قيمة محددة، إلى قطع تُستعمل لإنشاء رزم بيانات ذات أطوال أصغر من الرزمة الأصلية. تمرر الرزم المُقطعة إلى [[طبقة ربط البيانات]] ليصار إلى تغليفها وإنشاء [[إطار البيانات|أطر البيانات]]. |
||
=== التقطيع في الإصدار الرابع من بروتوكول الإنترنت === |
=== التقطيع في الإصدار الرابع من بروتوكول الإنترنت === |
||
يكون تقطيع [[رزمة بيانات]] [[الإصدار الرابع من بروتوكول الإنترنت]] {{إنج|IP Fragmentation}} |
يكون تقطيع [[رزمة بيانات]] [[بروتوكول الإنترنت (الإصدار الرابع)|الإصدار الرابع من بروتوكول الإنترنت]] {{إنج|IP Fragmentation}} ضروريًّا عندما يتم توليدها في [[شبكة محلية]] أُولى تسمح بحجم كبير [[وحدة النقل العظمى|لوحدة النقل العظمى]] الخاصة [[طبقة الشبكة|بطقبة الشبكة]]، لكنّ مسار الرزمة يقطع شبكة ثانية يكون حجم وحدة النقل العظمى فيها أصغر بالقيمة، وعندها لابد من تقطيع الرزمة في عقدة ما على المسار من أجل أن تصل إلى وجهتها. نتيجة لذلك، يتم توليد رزم بيانات بأطوال أصغر من طول الرزمة الأصلية.<ref name = "Book-6">{{استشهاد بكتاب |
||
|مؤلف1= Shivendra Panwar, Shivendra S. Panwar, Shiwen Mao, Jeong-dong Ryoo, Yihan Li |
|مؤلف1= Shivendra Panwar, Shivendra S. Panwar, Shiwen Mao, Jeong-dong Ryoo, Yihan Li |
||
|عنوان= TCP/IP Essentials: A Lab-Based Approach |
|عنوان= TCP/IP Essentials: A Lab-Based Approach |
||
سطر 523: | سطر 479: | ||
|سنة= 2014 |
|سنة= 2014 |
||
|ناشر= Cambridge University Press |
|ناشر= Cambridge University Press |
||
| |
|ردمك= 0521841445 |
||
|لغة= en |
|لغة= en |
||
}}</ref> |
}}</ref> |
||
يمكن أن تحصل عملية تقطيع الرزم في المُضيف المصدر الذي يُولّدها، أو في أي عقدة على مسارها نحو وجهتها، ويدعم البروتوكول |
يمكن أن تحصل عملية تقطيع الرزم في المُضيف المصدر الذي يُولّدها، أو في أي عقدة على مسارها نحو وجهتها، ويدعم البروتوكول أيضًا مفهوم التقطيع المتعدد، أي يمكن أن يتم تقطيع رزمة البيانات أكثر من مرة عبر مسارها، ولكن لا يمكن إعادة تجميع الرزمة الأصلية إلا في الوجهة النهائية.<ref name="Web-13"/> |
||
==== ترويسة البروتوكول ==== |
==== ترويسة البروتوكول ==== |
||
[[ملف:IPv4 Packet |
[[ملف:IPv4 Packet-ar.svg|تصغير|300بك|[[رزمة بيانات]] [[بروتوكول الإنترنت (الإصدار الرابع)|الإصدار الرابع من بروتوكول الإنترنت]] (IPv4)، ويمكن تبين الحقول المرتبطة بعملية التقطيع وهي حقول مُعرّف القطعة والأعلام وإزاحة القطعة.]] |
||
[[ملف:IPv4 Fragmentation Flag field-ar.svg|تصغير|300بك|حقل الأعلام في ترويسة الإصدار الرابع من بروتوكول الإنترنت، هناك علمين هما علم عدم التقطيع وعلم المزيد من القطع.]] |
|||
[[File:IPv4 header's flags field -ar.png|thumb|300بك|حقل الأعلام في ترويسة الإصدار الرابع من بروتوكول الإنترنت، هناك علمين هما علم عدم التقطيع وعلم المزيد من القطع.]] |
|||
تتكون [[ترويسة]] [[الإصدار الرابع من بروتوكول الإنترنت]] من 14 |
تتكون [[ترويسة (حوسبة)|ترويسة]] [[بروتوكول الإنترنت (الإصدار الرابع)|الإصدار الرابع من بروتوكول الإنترنت]] من 14 حقلًا،<ref name="ietf-5"/> لا ترتبط جميعها بعملية التقطيع. الحقول المُرتبطة بعملية التقطيع هي حقل مُعرّف القطعة، وحقل الأعلام وحقل الإزاحة، كما تتأثر قيمة حقلي الطول الإجمالي والتحقق الجمعي بعملية التقطيع وتختلف قيمتها في القطع عن قيمتها في الرزمة الأصلية،<ref name="Web-63">{{استشهاد ويب |
||
| مؤلف = Joshua Johnson |
| مؤلف = Joshua Johnson |
||
| مسار أرشيف = https://web.archive.org/web/20180730005606/https://learningnetwork.cisco.com/thread/70817 |
| مسار أرشيف = https://web.archive.org/web/20180730005606/https://learningnetwork.cisco.com/thread/70817 |
||
سطر 544: | سطر 499: | ||
| موقع= Cisco Systems, Inc. |
| موقع= Cisco Systems, Inc. |
||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 30 يوليو 2018}}</ref> بعض الخيارات تُنسخ لكل قطعة، وبعضها لا يُنسخ إلا للقطعة الأولى، ويتحدد ذلك بعلم خاص هو علم النسخ {{إنج|Copied flag}} الذي يوجد في بداية كل خيار.<ref name="Web-62">{{ |
| تاريخ الوصول= 30 يوليو 2018}}</ref> بعض الخيارات تُنسخ لكل قطعة، وبعضها لا يُنسخ إلا للقطعة الأولى، ويتحدد ذلك بعلم خاص هو علم النسخ {{إنج|Copied flag}} الذي يوجد في بداية كل خيار.<ref name="Web-62">{{استشهاد ويب |
||
| مسار أرشيف = https://web.archive.org/web/20170216042759/http://www.rhyshaden.com/ipdgram.htm |
| مسار أرشيف = https://web.archive.org/web/20170216042759/http://www.rhyshaden.com/ipdgram.htm |
||
| تاريخ أرشيف = 16 فبراير 2017 |
| تاريخ أرشيف = 16 فبراير 2017 |
||
| تاريخ = |
|||
| مسار= http://www.rhyshaden.com/ipdgram.htm |
| مسار= http://www.rhyshaden.com/ipdgram.htm |
||
| عنوان= The IP Datagram |
| عنوان= The IP Datagram |
||
سطر 554: | سطر 508: | ||
| تاريخ الوصول= 30 يوليو 2018}}</ref> |
| تاريخ الوصول= 30 يوليو 2018}}</ref> |
||
يمكن [[مضيف (حوسبة)|للمضيف]] المصدر أن يُؤشّر الرزم التي لا يريدها أن تُقطّع برفع علم عدم التقطيع، في هذه الحالة لا يتم تقطيع الرزمة |
يمكن [[مضيف (حوسبة)|للمضيف]] المصدر أن يُؤشّر الرزم التي لا يريدها أن تُقطّع برفع علم عدم التقطيع، في هذه الحالة لا يتم تقطيع الرزمة أبدًا، وفي حال تعذّر إيصال الرزمة بدون تقطيعها، فسيتم التخلص منها.<ref name="Web-36">{{استشهاد ويب |
||
| مؤلف = Geoff Huston |
| مؤلف = Geoff Huston |
||
| مسار أرشيف = https://web.archive.org/web/20180425142248/https://labs.ripe.net/Members/gih/evaluating-ipv4-and-ipv6-packet-fragmentation |
| مسار أرشيف = https://web.archive.org/web/20180425142248/https://labs.ripe.net/Members/gih/evaluating-ipv4-and-ipv6-packet-fragmentation |
||
سطر 564: | سطر 518: | ||
| موقع= Réseaux IP Européens Network Coordination Centre RIPE NCC |
| موقع= Réseaux IP Européens Network Coordination Centre RIPE NCC |
||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 22 يوليو 2018}}</ref> إذا تمّ تقطيع رزمة البيانات في المصدر أو في أي عقدة على المسار فلابد من إعادة تجميع القطع الناتجة في المُضيف الوجهة، ولا يتمّ تجميع قطع الرزمة في أي [[عقدة (شبكات)|عقدة]] على المسار. يُستخدم حقل المُعرّف لتمييز رزمة البيانات الأصلية وجميع القطع الناتجة عن عملية التقطيع، ويقوم المُضيف الوجهة باستعمال هذا الحقل للتمييز بين مجموعات القطع الناتجة عن تقطيع رزم بيانات مختلفة بغرض إعادة تجميعها.<ref name="ietf-24">{{ |
| تاريخ الوصول= 22 يوليو 2018}}</ref> إذا تمّ تقطيع رزمة البيانات في المصدر أو في أي عقدة على المسار فلابد من إعادة تجميع القطع الناتجة في المُضيف الوجهة، ولا يتمّ تجميع قطع الرزمة في أي [[عقدة (شبكات)|عقدة]] على المسار. يُستخدم حقل المُعرّف لتمييز رزمة البيانات الأصلية وجميع القطع الناتجة عن عملية التقطيع، ويقوم المُضيف الوجهة باستعمال هذا الحقل للتمييز بين مجموعات القطع الناتجة عن تقطيع رزم بيانات مختلفة بغرض إعادة تجميعها.<ref name="ietf-24">{{استشهاد ويب |
||
| الأخير= Touch |
| الأخير= Touch |
||
| الأول= J. |
| الأول= J. |
||
| تاريخ= فبراير 2013 |
| تاريخ= فبراير 2013 |
||
| مسار أرشيف = |
| مسار أرشيف = https://web.archive.org/web/20200509163438/https://www.ietf.org/rfc/rfc6864 |
||
| مسار= https://www.ietf.org/rfc/rfc6864 |
| مسار= https://www.ietf.org/rfc/rfc6864 |
||
| عنوان= RFC 6864, Updated Specification of the IPv4 ID Field |
| عنوان= RFC 6864, Updated Specification of the IPv4 ID Field |
||
سطر 575: | سطر 529: | ||
| لغة= en |
| لغة= en |
||
| issn= 2070-1721 |
| issn= 2070-1721 |
||
| تاريخ الوصول= 22 يوليو 2018| |
| تاريخ الوصول= 22 يوليو 2018|تاريخ أرشيف=2020-05-09|url-status=dead}}</ref> |
||
لإعادة تشكيل رزمة البيانات الأصلية، يجب أن يعرف المُضيف الوجهة موقع حمولة القطعة بالنسبة للحمولة الأصلية، ولتحقيق ذلك، هناك حقل خاص في ترويسة البروتوكول هو حقل إزاحة القطعة، وهو يدل على الموقع النسبي لحمولة القطعة قي الرزمة الأصلية. وعند تشكيل الرزمة الأصلية في الوجهة يتم ضبط قيمة حقل الإزاحة فيها إلى الصفر، إذا خضعت الحمولة للتقطيع المتعدد على طول المسار، فإن فيمة الإزاحة تدل |
لإعادة تشكيل رزمة البيانات الأصلية، يجب أن يعرف المُضيف الوجهة موقع حمولة القطعة بالنسبة للحمولة الأصلية، ولتحقيق ذلك، هناك حقل خاص في ترويسة البروتوكول هو حقل إزاحة القطعة، وهو يدل على الموقع النسبي لحمولة القطعة قي الرزمة الأصلية. وعند تشكيل الرزمة الأصلية في الوجهة يتم ضبط قيمة حقل الإزاحة فيها إلى الصفر، إذا خضعت الحمولة للتقطيع المتعدد على طول المسار، فإن فيمة الإزاحة تدل دومًا على الموقع النسبي في الرزمة الأصلية، وليس في قطعة ما، مهما تعددت مراحل التقطيع. |
||
حقول ترويسة البروتوكول المُستخدمة في عملية التقطيع:<ref name="ietf-5"/> |
حقول ترويسة البروتوكول المُستخدمة في عملية التقطيع:<ref name="ietf-5"/> |
||
* '''حقل مُعرّف القطعة'''، طوله 16 بت ويحتوي على قيمة فريدة تُعرف رزمة البيانات الأصلية وجميع القطع الناتجة عن تقطيعها، وهو يستخدم في عملية إعادة التجميع لتمييز قطع الرزم الأصلية عن قطع بقية الرزمة.<ref name="ietf-24"/> |
* '''حقل مُعرّف القطعة'''، طوله 16 بت ويحتوي على قيمة فريدة تُعرف رزمة البيانات الأصلية وجميع القطع الناتجة عن تقطيعها، وهو يستخدم في عملية إعادة التجميع لتمييز قطع الرزم الأصلية عن قطع بقية الرزمة.<ref name="ietf-24"/> |
||
* '''حقل الأعلام'''، طوله 3 بت مقسم بالشكل التالي: |
* '''حقل الأعلام'''، طوله 3 بت مقسم بالشكل التالي: |
||
** '''البت 0'''، محجوز، لا يُستخدم، قيمته |
** '''البت 0'''، محجوز، لا يُستخدم، قيمته دائمًا هي 0. |
||
** '''البت 1'''، علم عدم التقطيع {{إنج|Do not Fragment Flag اختصاراً DF}}، يستخدم من قبل مصدر الرزمة للإشارة إلى ضرورة عدم تقطيع الرزمة،<ref name="Web-33">{{ |
** '''البت 1'''، علم عدم التقطيع {{إنج|Do not Fragment Flag اختصاراً DF}}، يستخدم من قبل مصدر الرزمة للإشارة إلى ضرورة عدم تقطيع الرزمة،<ref name="Web-33">{{استشهاد ويب |
||
| مؤلف = Sean Wilkins |
| مؤلف = Sean Wilkins |
||
| مسار أرشيف = https://web.archive.org/web/20170327015623/http://www.pearsonitcertification.com/articles/article.aspx?p=1843887 |
| مسار أرشيف = https://web.archive.org/web/20170327015623/http://www.pearsonitcertification.com/articles/article.aspx?p=1843887 |
||
| تاريخ أرشيف =27 مارس 2017 |
| تاريخ أرشيف =27 مارس 2017 |
||
| تاريخ = 29 فبراير 2012 |
| تاريخ = 29 فبراير 2012 |
||
| مسار= |
| مسار= https://www.pearsonitcertification.com/articles/article.aspx?p=1843887 |
||
| عنوان= Anatomy of an IPv4 Packet |
| عنوان= Anatomy of an IPv4 Packet |
||
| موقع= Pearson Education, Pearson IT Certification |
| موقع= Pearson Education, Pearson IT Certification |
||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 22 يوليو 2018}}</ref> تقوم الموجهات على كامل مسار الرزمة بالالتزام بذلك، وإذا كانت قيمة هذا البت مساوية للواحد، فلن يتم تقطيع الرزمة |
| تاريخ الوصول= 22 يوليو 2018}}</ref> تقوم الموجهات على كامل مسار الرزمة بالالتزام بذلك، وإذا كانت قيمة هذا البت مساوية للواحد، فلن يتم تقطيع الرزمة أبدًا حتى لو أدى ذلك إلى التخلص منها لعدم إمكانية توجيهها.<ref name="Web-36"/> |
||
** '''البت 2'''، علم المزيد من القطع {{إنج|More Fragment Flag اختصاراً MF}} يستخدم لتمييز القطعة الأخيرة، إذا كانت قيمته 1 فهذا يعني أن هناك قطع أخرى نتجت بعد هذه القطعة من عملية تقطيع الرزمة الأصلية، أما إذا كانت قيمته 0، فهذا يعني أن هذه القطعة هي آخر قطعة نتجت عن عملية تقطيع الرزمة. |
** '''البت 2'''، علم المزيد من القطع {{إنج|More Fragment Flag اختصاراً MF}} يستخدم لتمييز القطعة الأخيرة، إذا كانت قيمته 1 فهذا يعني أن هناك قطع أخرى نتجت بعد هذه القطعة من عملية تقطيع الرزمة الأصلية، أما إذا كانت قيمته 0، فهذا يعني أن هذه القطعة هي آخر قطعة نتجت عن عملية تقطيع الرزمة. |
||
* '''حقل إزاحة القطعة'''، طوله 13 بت، ويحتوي على قيمة تدل على موقع القطعة النسبي بالنسبة لبقية القطع في الرزمة الأصلية، تكون قيمة الإزاحة مقسومة على ثمانية، |
* '''حقل إزاحة القطعة'''، طوله 13 بت، ويحتوي على قيمة تدل على موقع القطعة النسبي بالنسبة لبقية القطع في الرزمة الأصلية، تكون قيمة الإزاحة مقسومة على ثمانية، أي إذا احتوى الحقل القيمة 1 فإن قيمة الإزاحة الحقيقية هي 8 بايت، وإذا احتوى 2 فإن قيمة الإزاحة الحقيقية هي 16، وأكبر قيمة ممكن للإزاحة في هذا الحقل هي: 2<sup>13</sup>=8192، وتقابل 65536 بايت.<ref name = "Book-5">{{استشهاد بكتاب |
||
|مؤلف1= Toni Janevski |
|مؤلف1= Toni Janevski |
||
|عنوان= Internet Technologies for Fixed and Mobile Networks |
|عنوان= Internet Technologies for Fixed and Mobile Networks |
||
سطر 601: | سطر 555: | ||
|سنة= 2015 |
|سنة= 2015 |
||
|ناشر= Artech House |
|ناشر= Artech House |
||
| |
|ردمك= 9781608079216 |
||
|لغة= en |
|لغة= en |
||
}}</ref> |
}}</ref> |
||
يجب عدم الخلط بين حقلي المُعرّف وإزاحة القطعة في ترويسة بروتوكول الإنترنت، فحقل المُعرّف هو قيمة مميزة تُعرّف بشكلٍ فريد رزمة البيانات الأصلية وكل القطع الناتجة عن عملية التقطيع سواء تم كمرحلة واحدة أو كان |
يجب عدم الخلط بين حقلي المُعرّف وإزاحة القطعة في ترويسة بروتوكول الإنترنت، فحقل المُعرّف هو قيمة مميزة تُعرّف بشكلٍ فريد رزمة البيانات الأصلية وكل القطع الناتجة عن عملية التقطيع سواء تم كمرحلة واحدة أو كان متعددًا، أما حقل الإزاحة فهو يمثل الموقع النسبي للقطعة الناتجة بالنسبة لبقية القطع ضكن رزمة البيانات الأصلية.<ref name="Web-11">{{استشهاد ويب |
||
| مؤلف = |
|||
| مسار أرشيف = https://web.archive.org/web/20180701083420/https://learningnetwork.cisco.com/thread/123816 |
| مسار أرشيف = https://web.archive.org/web/20180701083420/https://learningnetwork.cisco.com/thread/123816 |
||
| تاريخ أرشيف = 1 يوليو 2018 |
| تاريخ أرشيف = 1 يوليو 2018 |
||
سطر 617: | سطر 570: | ||
==== خوارزمية التقطيع ==== |
==== خوارزمية التقطيع ==== |
||
[[ |
[[ملف:IPv4 Fragmentation Algorithm-ar.svg|تصغير|300بك|خوارزمية تقطيع رزم البيانات في [[بروتوكول الإنترنت (الإصدار الرابع)|الإصدار الرابع من بروتوكول الإنترنت]].]] |
||
وصفت [[خوارزمية]] التقطيع في محددات البروتوكول، وهي تتبع المراحل التالية:<ref name="ietf-5"/> |
وصفت [[خوارزمية]] التقطيع في محددات البروتوكول، وهي تتبع المراحل التالية:<ref name="ietf-5"/> |
||
# تحديد طول الرزمة ومقارنته مع وحدة النقل |
# تحديد طول الرزمة ومقارنته مع وحدة النقل العظمى الخاصّة بالشبكة التي سيتم توجيه الرزمة إليها: |
||
## إذا كان طول الرزمة أكبر من وحدة النقل |
## إذا كان طول الرزمة أكبر من وحدة النقل العظمى، يجب أن يتم تقطيع الرزمة. |
||
## إذا كان طول الرزمة أصغر أو يساوي وحدة النقل |
## إذا كان طول الرزمة أصغر أو يساوي وحدة النقل العظمى يتم إرسال الرزمة كما هي إلى المرحلة التالية من التغليف. |
||
# إذا كان علم عدم التقطيع في الرزمة |
# إذا كان علم عدم التقطيع في الرزمة مرفوعًا، يتمّ التخلّص من الرزمة. |
||
# يجري تحديد حجم حمولة القطعة بحسب وحدة النقل |
# يجري تحديد حجم حمولة القطعة بحسب وحدة النقل العظمى وطول ترويسة بروتوكول الإنترنت. |
||
# يتم اقتطاع حمولة القطعة من حمولة الرزمة الأصلية. |
# يتم اقتطاع حمولة القطعة من حمولة الرزمة الأصلية. |
||
# يتم بناء ترويسة القطعة، ويشمل ذلك: |
# يتم بناء ترويسة القطعة، ويشمل ذلك: |
||
سطر 636: | سطر 589: | ||
# تحديد فيما إذا كانت الرزمة الناتجة هي الرزمة الأخيرة بقراءة قيمة علم المزيد من القطع: |
# تحديد فيما إذا كانت الرزمة الناتجة هي الرزمة الأخيرة بقراءة قيمة علم المزيد من القطع: |
||
## إذا كانت الرزمة الناتجة هي الرزمة الأخيرة، يتم إرسالها إلى المرحلة التالية من التغليف. |
## إذا كانت الرزمة الناتجة هي الرزمة الأخيرة، يتم إرسالها إلى المرحلة التالية من التغليف. |
||
## إذا لم تكن الرزمة الناتجة هي الرزمة الأخيرة، يتم إعادة تنفيذ الخوارزمية |
## إذا لم تكن الرزمة الناتجة هي الرزمة الأخيرة، يتم إعادة تنفيذ الخوارزمية بدءًا من الخطوة الثالثة، مع اعتبار أن حجم حمولة الرزمة الأصلية هو الحجم المتبقي من عملية الاقتطاع السابقة. |
||
أما عملية إعادة التجميع، فهي تجري بشكل معاكس، وهناك عدة خوارزميات لإنجازها، جرى مناقشتها في وثيقة طلب التعليقات RFC 815.<ref name="ietf-105">{{ |
أما عملية إعادة التجميع، فهي تجري بشكل معاكس، وهناك عدة خوارزميات لإنجازها، جرى مناقشتها في وثيقة طلب التعليقات RFC 815.<ref name="ietf-105">{{استشهاد ويب |
||
| الأخير= D. Clark |
| الأخير= D. Clark |
||
| الأول= David |
| الأول= David |
||
| تاريخ= يوليو 1982 |
| تاريخ= يوليو 1982 |
||
| مسار أرشيف = |
| مسار أرشيف = https://web.archive.org/web/20200507010603/https://tools.ietf.org/html/rfc815 |
||
| مسار= https://tools.ietf.org/html/rfc815 |
| مسار= https://tools.ietf.org/html/rfc815 |
||
| عنوان= RFC 815, IP DATAGRAM REASSEMBLY ALGORITHMS |
| عنوان= RFC 815, IP DATAGRAM REASSEMBLY ALGORITHMS |
||
| |
| موقع= The Internet Society |
||
| |
| لغة= en |
||
| doi = 10.17487/RFC0815 |
| doi = 10.17487/RFC0815 |
||
| تاريخ الوصول= 9 يونيو 2019}}</ref> |
| تاريخ الوصول= 9 يونيو 2019|تاريخ أرشيف=2020-05-07}}</ref> |
||
==== قضايا أمنية ==== |
==== قضايا أمنية ==== |
||
طوّر [[مخترق|المهاجمون]] عدد من الهجمات التي تعتمد على التقطيع أو [[ثغرة أمنية]] قد تنتج عن استخدامه، من هذه الهجمات: |
طوّر [[مخترق|المهاجمون]] عدد من الهجمات التي تعتمد على التقطيع أو [[ثغرة أمنية (حوسبة)|ثغرة أمنية]] قد تنتج عن استخدامه، من هذه الهجمات: |
||
* '''هجوم القطعة الصغيرة''' {{إنج|Tiny Fragment Attack}}<ref name="ietf-25">{{ |
* '''هجوم القطعة الصغيرة''' {{إنج|Tiny Fragment Attack}}<ref name="ietf-25">{{استشهاد ويب |
||
| الأخير= Miller |
| الأخير= Miller |
||
| الأول= I. |
| الأول= I. |
||
| تاريخ= يونيو 2001 |
| تاريخ= يونيو 2001 |
||
| مسار أرشيف = https://web.archive.org/web/20120811124557/http://www.ietf.org/rfc/rfc3128| مسار= https://www.ietf.org/rfc/rfc3128 |
|||
| مسار أرشيف = |
|||
| مسار= https://www.ietf.org/rfc/rfc3128 |
|||
| عنوان= RFC 3128, Protection Against a Variant of the Tiny Fragment Attack |
| عنوان= RFC 3128, Protection Against a Variant of the Tiny Fragment Attack |
||
| موقع= The Internet Society |
| موقع= The Internet Society |
||
| صفحة = 22 |
| صفحة = 22 |
||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 22 يوليو 2018}}</ref> يعتمد هذا الهجوم على حقيقة أن أصغر [[رزمة بيانات]] يمكن لأي وحدة تدعم [[الإصدار الرابع من بروتوكول الإنترنت]] التعامل معها هي بطول 68 [[بايت]]، حيث تكون [[ترويسة]] بروتوكول الإنترنت بأقصى طول أعظمي مسموح لها، وهو 60 بايت، في حين تكون [[حمولة (حوسبة)|الحمولة]] بطول 8 بايت فقط،<ref name="ietf-5"/> لا يكفي هذا الطول لإدراج ترويسة بروتوكول [[طبقة النقل|النقل]] ضمن الرزمة، وقد يحاول المُهاجم تمرير قطعة خبيثة من [[جدار الحماية]]، الذي يتفحص عادة [[مقبس (شبكات)|أرقام المنافذ]] في طبقة النقل، على أساس أنها قطعة صغيرة من رزمة بيانات أكبر جرى تقطيعها. |
| تاريخ الوصول= 22 يوليو 2018| تاريخ أرشيف = 11 أغسطس 2012 }}</ref> يعتمد هذا الهجوم على حقيقة أن أصغر [[رزمة بيانات]] يمكن لأي وحدة تدعم [[بروتوكول الإنترنت (الإصدار الرابع)|الإصدار الرابع من بروتوكول الإنترنت]] التعامل معها هي بطول 68 [[بايت]]، حيث تكون [[ترويسة (حوسبة)|ترويسة]] بروتوكول الإنترنت بأقصى طول أعظمي مسموح لها، وهو 60 بايت، في حين تكون [[حمولة (حوسبة)|الحمولة]] بطول 8 بايت فقط،<ref name="ietf-5"/> لا يكفي هذا الطول لإدراج ترويسة بروتوكول [[طبقة النقل|النقل]] ضمن الرزمة، وقد يحاول المُهاجم تمرير قطعة خبيثة من [[جدار حماية (حوسبة)|جدار الحماية]]، الذي يتفحص عادة [[مقبس (شبكات)|أرقام المنافذ]] في طبقة النقل، على أساس أنها قطعة صغيرة من رزمة بيانات أكبر جرى تقطيعها. |
||
* '''هجوم القطع المتراكبة''' {{إنج|Overlapping Fragment Attack}}<ref name="Web-38">{{ |
* '''هجوم القطع المتراكبة''' {{إنج|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 |
| مسار أرشيف = 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 |
| تاريخ أرشيف =11 فبراير 2017 |
||
| تاريخ = 3 نوفمبر 2015 |
| تاريخ = 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. |
| عنوان= Explore new firmware that’s helping organizations see attacks as they happen. |
||
| موقع= Datacom |
| موقع= Datacom |
||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 22 يوليو 2018| |
| تاريخ الوصول= 22 يوليو 2018|url-status=dead}}</ref> يعتمد هذا الهجوم على [[خوارزمية]] إعادة التجميع المُتبعة لإعادة تشكيل الرزمة الأصلية، حيث يمكن لأي قطعة تالية أن تتراكب مع قطعة أخرى سابقة، وتحل محلها جزئيًّا أو كليًّا، ويعني ذلك وجود ثغرة أمنية، حيث بالإمكان تمرير القطعة الأولى، التي تحتوي ترويسة بروتوكول الإنترنت من جدار الحماية بشكل شرعي، ثُمّ التلاعب بقيمتها عن طريقة التراكب مع قطعة تالية.<ref name = "JOU-8">{{استشهاد بدورية محكمة |
||
|الأخير= H. Ptacek |
|الأخير= H. Ptacek |
||
|الأول= Thomas |
|الأول= Thomas |
||
| |
|مؤلف2-الأخير= N. Newsham |
||
| |
|مؤلف2-الأول= Timothy |
||
|صحيفة = Computer Systems Management and Standards |
|صحيفة = Computer Systems Management and Standards |
||
|عنوان= Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection |
|عنوان= Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection |
||
| تاريخ = يناير 1998 |
|||
|المجلد= |
|||
|العدد = |
|||
|سنة= 1998 |
|||
|شهر= يناير |
|||
|صفحة= 46-52 |
|صفحة= 46-52 |
||
| ناشر = DEFENSE TECHNICAL INFORMATION CENTER |
| ناشر = DEFENSE TECHNICAL INFORMATION CENTER |
||
| مسار = https://apps.dtic.mil/dtic/tr/fulltext/u2/a391565.pdf |
|||
| doi = |
|||
| مسار أرشيف = https://web.archive.org/web/20170812174412/http://dtic.mil/dtic/tr/fulltext/u2/a391565.pdf | تاريخ أرشيف = 12 أغسطس 2017 }}</ref> على الرغم من التحسينات التي طرأت على خوارزمية إعادة التجميع، إلا أن الوثائق المعيارية للخوارزمية لم تتناول هذا الهجوم.<ref name="ietf-6">{{استشهاد ويب |
|||
| مسار = http://www.dtic.mil/dtic/tr/fulltext/u2/a391565.pdf |
|||
}}</ref> على الرغم من التحسينات التي طرأت على خوارزمية إعادة التجميع، إلا أن الوثائق المعيارية للخوارزمية لم تتناول هذا الهجوم.<ref name="ietf-6">{{مرجع ويب |
|||
| الأخير= D. Clark |
| الأخير= D. Clark |
||
| الأول= David |
| الأول= David |
||
| تاريخ= يوليو 1982 |
| تاريخ= يوليو 1982 |
||
| مسار أرشيف = https://web.archive.org/web/20190328194357/https://tools.ietf.org/html/rfc815| مسار= https://tools.ietf.org/html/rfc815 |
|||
| مسار أرشيف = |
|||
| مسار= https://tools.ietf.org/html/rfc815 |
|||
| عنوان= RFC 815, IP DATAGRAM REASSEMBLY ALGORITHMS |
| عنوان= RFC 815, IP DATAGRAM REASSEMBLY ALGORITHMS |
||
| موقع=The Internet Society |
| موقع=The Internet Society |
||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 1 يوليو 2018}}</ref> |
| تاريخ الوصول= 1 يوليو 2018| تاريخ أرشيف = 28 مارس 2019 }}</ref> |
||
نُوقشت هذه الهجمات وطريقة التصدي لكل منها بالتفصيل في [[طلب تعليقات|وثيقة طلب التعليقات]] RFC 1858.<ref name="ietf-4"/> |
نُوقشت هذه الهجمات وطريقة التصدي لكل منها بالتفصيل في [[طلب تعليقات|وثيقة طلب التعليقات]] RFC 1858.<ref name="ietf-4"/> |
||
==== أمثلة ==== |
==== أمثلة ==== |
||
[[ |
[[ملف:IP Fragmentation example - ar.png|تصغير|300بك|مثال عن عملية التقطيع المتعدد في الإصدار الرابع من بروتوكول الإنترنت. يحصل التقطيع على مرحلتين في الأولى تكون وحدة النقل العظمى 4000 [[بايت]]، وفي الثانية 2500 بايت.<ref name="Web-15"/>]] |
||
في هذا المثال، يُفترض أن طول [[ترويسة]] [[الإصدار الرابع من بروتوكول الإنترنت]] هي 20 [[بايت]]، أي لا يوجد أي خيارات إضافية. إنّ قيمة |
في هذا المثال، يُفترض أن طول [[ترويسة (حوسبة)|ترويسة]] [[بروتوكول الإنترنت (الإصدار الرابع)|الإصدار الرابع من بروتوكول الإنترنت]] هي 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) بايت. |
بشكلٍ مُشابه لإنتاج الرزمة الأولى، يتم اقتطاع 1480 بايت من الحمولة المُتبقية، ويتمّ تغليفها بترويسة البروتوكول المناسبة التي تكون قيم حقولها الخاصة بالتقطيع مُشابهة لحقول ترويسة الرزمة الأولى باستثناء قيمة حقل الإزاحة الذي يتمّ ضبطه إلى القيمة (185=1480/8). وتكون الحمولة المُتبقية بعد إنشاء القطعة اقتطاع الثانية هي (2160=1480-3640). ثُمّ، وبشكلٍ مُشابه يتم اقتطاع القطعة الثالثة، ويجري تغليفها بترويسة البروتوكول المُناسبة التي تكون قيم حقولها الخاصّة بالتقطيع مُشابهة لحقول ترويسة الرزمة الأولى باستثناء قيمة حقل الإزاحة الذي يتم ضبطه إلى القيمة (370=8/(1480+1480)) وتكون الحمولة المتبقية بعد إنشاء القطعة اقتطاع الثالثة هي (680=1480-2160) بايت. |
||
سطر 711: | سطر 657: | ||
تُشكّل الحمولة المُتبقية القطعة الأخيرة، وتُغلّف بترويسة بروتوكول الإنترنت ليصبح الطول الإجمالي للرزمة الناتجة 700 بايت، ويجب أن يتم ضبط علم المزيد من القطع إلى القيمة 0 لأنّها القطعة الأخيرة، وحقل الإزاحة إلى القيمة (555=8/(1480+1480+1480))، بينما تكون قيم بقية الحقول الخاصة بالتقطيع في الترويسة مُطابقة للقيم في ترويسات الرزم السابقة. |
تُشكّل الحمولة المُتبقية القطعة الأخيرة، وتُغلّف بترويسة بروتوكول الإنترنت ليصبح الطول الإجمالي للرزمة الناتجة 700 بايت، ويجب أن يتم ضبط علم المزيد من القطع إلى القيمة 0 لأنّها القطعة الأخيرة، وحقل الإزاحة إلى القيمة (555=8/(1480+1480+1480))، بينما تكون قيم بقية الحقول الخاصة بالتقطيع في الترويسة مُطابقة للقيم في ترويسات الرزم السابقة. |
||
{| class="wikitable |
{| class="wikitable " width="100%" |
||
|- |
|- |
||
|+ جدول بقيم حقول الترويسات في الرزمة الأصلية قبل التقطيع وفي الرزم الناتجة عن التقطيع. |
|+ جدول بقيم حقول الترويسات في الرزمة الأصلية قبل التقطيع وفي الرزم الناتجة عن التقطيع. |
||
|- |
|- |
||
! colspan="6"| بعض |
! colspan="6"| بعض حقول ترويسة الرزمة الأصلية قبل التقطيع |
||
|- |
|- |
||
! - !! حقل مُعرف القطعة !! حقل الطول الإجمالي (بايت) !! علم عدم التقطيع !! علم المزيد من القطع !! حقل الإزاحة |
! - !! حقل مُعرف القطعة !! حقل الطول الإجمالي (بايت) !! علم عدم التقطيع !! علم المزيد من القطع !! حقل الإزاحة |
||
|- |
|- |
||
| |
| align="center" |- || align="center"| 345 || align="center"|5140|| align="center"|0 || align="center"|0 || align="center"|0 |
||
|- |
|- |
||
! colspan="6"| بعض حقول ترويسات الرزم الناتجة عن التقطيع |
! colspan="6"| بعض حقول ترويسات الرزم الناتجة عن التقطيع |
||
سطر 725: | سطر 671: | ||
! رقم القطعة !! حقل مُعرف القطعة !! حقل الطول الإجمالي (بايت) !! علم عدم التقطيع !! علم المزيد من القطع !! حقل الإزاحة |
! رقم القطعة !! حقل مُعرف القطعة !! حقل الطول الإجمالي (بايت) !! علم عدم التقطيع !! علم المزيد من القطع !! حقل الإزاحة |
||
|- |
|- |
||
| |
| 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"|2 || align="center"|345 || align="center"|1500|| align="center"|1 || align="center"|1 || align="center"|185 |
||
سطر 734: | سطر 680: | ||
|} |
|} |
||
إنّ مجموع أطوال الرزم الناتجة عن عملية التقطيع هو 5200 بايت، وهو أكبر من طول الرزمة الأصلية بمقدار 60 |
إنّ مجموع أطوال الرزم الناتجة عن عملية التقطيع هو 5200 بايت، وهو أكبر من طول الرزمة الأصلية بمقدار 60 بايتًا أو 1.15%، وهي حمولة إضافية تنتج عن إضافة الترويسات للقطع الناجمة عن عملية التقطيع. |
||
=== التقطيع في الإصدار السادس من بروتوكول الإنترنت === |
=== التقطيع في الإصدار السادس من بروتوكول الإنترنت === |
||
إن تقطيع [[رزمة بيانات|رزم البيانات]] التي يتجاوز طولها قيمة محددة |
إن تقطيع [[رزمة بيانات|رزم البيانات]] التي يتجاوز طولها قيمة محددة [[وحدة النقل العظمى|بوحدة النقل العظمى]] [[طبقة الشبكة|لطبقة الشبكة]] هي وظيفة أساسيّة [[بروتوكول الإنترنت (الإصدار السادس)|للإصدار السادس من بروتوكول الإنترنت]].<ref name="ietf-9"/> بشكلٍ مشابه للإصدار الرابع من بروتوكول الإنترنت، يقوم الإصدار السادس بتقطيع [[حمولة (حوسبة)|حمولة]] رزمة بيانات لإنقاص طولها، وينتج عن ذلك مجموعة من القطع التي تستعمل لتنتج رزم بيانات جديدة، أطوالها أقل أو تساوي قيمة وحدة النقل الأعظيمة. ولكن على عكس الإصدار الرابع من بروتوكول الإنترنت، في الإصدار السادس، لا يحدث التقطيع إلا في [[مضيف (حوسبة)|المُضيف]] المصدر فقط، ولا تقوم [[موجه (شبكات)|المُوجّهات]] بتقطيع رزمة بيانات الإصدار السادس تحت أي ظرف،<ref name="Web-27">{{استشهاد ويب |
||
| مؤلف = Matt Conran |
| مؤلف = Matt Conran |
||
| مسار أرشيف = https://web.archive.org/web/20180102061631/http://network-insight.net/2015/10/ipv6-fragmentation/ |
| مسار أرشيف = https://web.archive.org/web/20180102061631/http://network-insight.net/2015/10/ipv6-fragmentation/ |
||
| تاريخ أرشيف = 2 يناير 2018 |
| تاريخ أرشيف = 2 يناير 2018 |
||
| تاريخ = 16 أوكتوبر 2018 |
| تاريخ = 16 أوكتوبر 2018 |
||
| مسار= |
| مسار= https://network-insight.net/2015/10/ipv6-fragmentation/ |
||
| عنوان= IPV6 FRAGMENTATION |
| عنوان= IPV6 FRAGMENTATION |
||
| موقع= Technology Focused Hub PS Delivery ltd |
| موقع= Technology Focused Hub PS Delivery ltd |
||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 20 يوليو 2018}}</ref> لذلك فإن معرفة وحدة النقل |
| تاريخ الوصول= 20 يوليو 2018}}</ref> لذلك فإن معرفة وحدة النقل العظمى للمسار هي عملية ذات أهمية خاصة في البروتوكول، وإذا لم يتمكن البروتوكول من تحديدها فإنّه يعتمد أدنى طول مسموح لرزمة البيانات وهو 1260 [[بايت]].<ref name="Web-20">{{استشهاد ويب |
||
| مؤلف = Phillip Remaker |
| مؤلف = Phillip Remaker |
||
| مسار أرشيف = https://web.archive.org/web/20160919073320/https://blogs.cisco.com/enterprise/ipv6-mtu-gotchas-and-other-icmp-issues |
| مسار أرشيف = https://web.archive.org/web/20160919073320/https://blogs.cisco.com/enterprise/ipv6-mtu-gotchas-and-other-icmp-issues |
||
سطر 759: | سطر 705: | ||
==== ترويسة القطعة ==== |
==== ترويسة القطعة ==== |
||
[[ |
[[ملف:Fragment header structure-ar.svg|تصغير|300بك|[[ترويسة (حوسبة)|ترويسة]] القطعة الخاصة ب[[بروتوكول الإنترنت (الإصدار السادس)|الإصدار السادس من بروتوكول الإنترنت]].]] |
||
[[ملف:IPv6 Fragmentation algorithm-ar.svg|تصغير|300بك| مخطط تدقفي يبين خوارزمية عملية التقطيع في الإصدار السادس من بروتوكول الإنترنت.]] |
|||
لا تحتوي [[ترويسة]] البروتوكول الأساسية على حقول خاصة بعملية التقطيع، ولكن هناك ترويسة أخرى خاصة بالتقطيع تسمى ترويسة القطعة {{إنج| Fragment Header}} يقوم البروتوكول بإضافتها في حال تقطيع الرزمة، إذا أضيفت هذه الترويسة بعد الترويسة الأساسية، يحب أن تكون قيمة حقل "الترويسة التالية" في ترويسة البروتوكول الأصلية مضبوطة إلى القيمة 44.<ref name="Web-21">{{مرجع ويب |
|||
[[ملف: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 |
| مسار أرشيف = https://web.archive.org/web/20180104065343/https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml |
||
| تاريخ أرشيف = 4 يناير 2018 |
| تاريخ أرشيف = 4 يناير 2018 |
||
سطر 772: | سطر 721: | ||
* '''حقل الترويسة التالية''' 8 [[بت]]، ويضبط بشكل مشابه لحقل الترويسة التالية في ترويسة البروتوكول الأصلية. |
* '''حقل الترويسة التالية''' 8 [[بت]]، ويضبط بشكل مشابه لحقل الترويسة التالية في ترويسة البروتوكول الأصلية. |
||
* '''حقل محجوز''' 8 بت، يضبط إلى القيمة 0 عند الإرسال. |
* '''حقل محجوز''' 8 بت، يضبط إلى القيمة 0 عند الإرسال. |
||
* '''حقل إزاحة القطعة''' 13 بت، يحتوي على موقع حمولة القطعة النسبي ضمن حمولة الرزمة الأصلية، وتعبر قيمة الرقم الموجود عن الإزاحة |
* '''حقل إزاحة القطعة''' 13 بت، يحتوي على موقع حمولة القطعة النسبي ضمن حمولة الرزمة الأصلية، وتعبر قيمة الرقم الموجود عن الإزاحة بواحدة هي 8 بايت، فإذا كانت قيمة هذا الحقل مثلًا هي 2، فإن إزاحة القطعة الحقيقية هي 16 بايت. |
||
* '''حقل محجوز''' 2 بت، يُضبط إلى القيمة 0 عند الإرسال. |
* '''حقل محجوز''' 2 بت، يُضبط إلى القيمة 0 عند الإرسال. |
||
* '''علم المزيد من القطع''' 1 بت، ويستخدم للدلالة على القطعة الأخيرة، إذا كانت قيمته 1، فهذا يعني أن هناك قطع لاحقة نتجت عن عملية التقطيع، أما إذا كانت قيمته 0 فذلك يعني بأن هذه القطعة هي القطعة الأخيرة. |
* '''علم المزيد من القطع''' 1 بت، ويستخدم للدلالة على القطعة الأخيرة، إذا كانت قيمته 1، فهذا يعني أن هناك قطع لاحقة نتجت عن عملية التقطيع، أما إذا كانت قيمته 0 فذلك يعني بأن هذه القطعة هي القطعة الأخيرة. |
||
* '''حقل مُعرّف القطعة''' 32 بت، وهي يحتوي قيمة فريدة تميّز الرزمة الأصلية وجميع القطع التي نتجت عن تقطيعها. هناك عدة [[خوارزمية|خوارزميات]] لاختيار قيمة المعرّف بحيث يكون |
* '''حقل مُعرّف القطعة''' 32 بت، وهي يحتوي قيمة فريدة تميّز الرزمة الأصلية وجميع القطع التي نتجت عن تقطيعها. هناك عدة [[خوارزمية|خوارزميات]] لاختيار قيمة المعرّف بحيث يكون فريدًا وآمنًا، وهي موصوفة في [[طلب تعليقات|وثيقة طلب التعليقات]] RFC 7739.<ref name="ietf-17">{{استشهاد ويب |
||
| الأخير= Gont |
| الأخير= Gont |
||
| الأول= F. |
| الأول= F. |
||
| تاريخ= فبراير 2016 |
| تاريخ= فبراير 2016 |
||
| مسار أرشيف = |
| مسار أرشيف = https://web.archive.org/web/20200509163440/https://www.ietf.org/rfc/rfc7739 |
||
| مسار= https://www.ietf.org/rfc/rfc7739 |
| مسار= https://www.ietf.org/rfc/rfc7739 |
||
| عنوان= RFC 7739, Security Implications of Predictable Fragment Identification Values |
| عنوان= RFC 7739, Security Implications of Predictable Fragment Identification Values |
||
سطر 785: | سطر 734: | ||
| لغة= en |
| لغة= en |
||
| issn = 2070-1721 |
| issn = 2070-1721 |
||
| تاريخ الوصول= 17 يوليو 2018| |
| تاريخ الوصول= 17 يوليو 2018|تاريخ أرشيف=2020-05-09|url-status=dead}}</ref> |
||
==== خوارزمية التقطيع ==== |
==== خوارزمية التقطيع ==== |
||
[[File:IPv6 Fragmentation - ar.png|thumb|300بك|[[خوارزمية]] التقطيع في الإصدار السادس من بروتوكول الإنترنت.]] |
|||
تتألف [[رزمة بيانات]] [[الإصدار السادس من بروتوكول الإنترنت]] من [[ترويسة]] البروتوكول الأساسية، ومجموعة من التوسيعات التي تشمل خيارات إضافية أو ترويسات مُحددة لابد من معالجتها في كل عقدة على المسار، بالإضافة إلى قسم [[حمولة (حوسبة)|الحمولة]] الذي يضمّ ترويسات الطبقات العليا، ويكون التقطيع |
تتألف [[رزمة بيانات]] [[بروتوكول الإنترنت (الإصدار السادس)|الإصدار السادس من بروتوكول الإنترنت]] من [[ترويسة (حوسبة)|ترويسة]] البروتوكول الأساسية، ومجموعة من التوسيعات التي تشمل خيارات إضافية أو ترويسات مُحددة لابد من معالجتها في كل عقدة على المسار، بالإضافة إلى قسم [[حمولة (حوسبة)|الحمولة]] الذي يضمّ ترويسات الطبقات العليا، ويكون التقطيع إلزاميًا عندما يتجاوز طول الرزمة قيمة [[وحدة النقل العظمى]]، والتي غالبًا ما تكون وحدة النقل العظمى الدنيا للمسار الذي ستسلكه رزمة البيانات، بخلاف ذلك، تُضبط القيمة بشكلٍ آلي القيمة الدنيا المدعومة لوحدة النقل العظمى في أسوء الحالات وهي 1280 بايت.<ref name="Web-24">{{استشهاد ويب |
||
| مؤلف = Geoff Huston |
| مؤلف = Geoff Huston |
||
| مسار أرشيف = https://web.archive.org/web/20170505113340/https://labs.ripe.net/Members/gih/fragmenting-ipv6 |
| مسار أرشيف = https://web.archive.org/web/20170505113340/https://labs.ripe.net/Members/gih/fragmenting-ipv6 |
||
سطر 800: | سطر 749: | ||
| تاريخ الوصول= 18 يوليو 2018}}</ref> وُصفت خوارزمية التقطيع في [[طلب تعليقات|وثيقة طلب التعليقات]] الخاصة بالبروتوكول.<ref name="ietf-9"/> |
| تاريخ الوصول= 18 يوليو 2018}}</ref> وُصفت خوارزمية التقطيع في [[طلب تعليقات|وثيقة طلب التعليقات]] الخاصة بالبروتوكول.<ref name="ietf-9"/> |
||
تتم عملية التقطيع بتقسيم حمولة الرزمة الأصلية إلى عدد من القطع، بحيث لا يزيد طول الرزمة الناتجة عن إضافة ترويسة القطعة |
تتم عملية التقطيع بتقسيم حمولة الرزمة الأصلية إلى عدد من القطع، بحيث لا يزيد طول الرزمة الناتجة عن إضافة ترويسة القطعة وترويسة البروتوكول والتوسيعات إلى أي من القطع عن وحدة النقل العظمى. تكون أطوال القطع الناتجة من مرتبة 8 [[بايت]]، أي أن أصغر حمولة قطعة يكون طولها 8 بايت، وثاني أصغر قطعة تكون بطول 16 بايت وهكذا، وتلتزم كل القطع بذلك فيما عدا القطعة الأخيرة. |
||
بشكلٍ عام تنتج عن عملية التقطيع ثلاث حالات مختلفة:<ref name="Web-23">{{ |
بشكلٍ عام تنتج عن عملية التقطيع ثلاث حالات مختلفة:<ref name="Web-23">{{استشهاد ويب |
||
| مؤلف = Charles M. Kozierok |
| مؤلف = Charles M. Kozierok |
||
| مسار أرشيف = https://web.archive.org/web/20170910013529/http://www.tcpipguide.com:80/free/t_IPv6DatagramSizeMaximumTransmissionUnitMTUFragment-4.htm |
| مسار أرشيف = https://web.archive.org/web/20170910013529/http://www.tcpipguide.com:80/free/t_IPv6DatagramSizeMaximumTransmissionUnitMTUFragment-4.htm |
||
سطر 812: | سطر 761: | ||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 18 يوليو 2018}}</ref> |
| تاريخ الوصول= 18 يوليو 2018}}</ref> |
||
* '''الرزمة الأولى''': وتضم ترويسة البروتوكول والتوسيعات والترويسات الإضافية بالإضافة لترويسة القطعة، والقطعة الأولى من الحمولة، والتي تضم ترويسات الطبقات العليا،<ref name="Web-22">{{ |
* '''الرزمة الأولى''': وتضم ترويسة البروتوكول والتوسيعات والترويسات الإضافية بالإضافة لترويسة القطعة، والقطعة الأولى من الحمولة، والتي تضم ترويسات الطبقات العليا،<ref name="Web-22">{{استشهاد ويب |
||
| مؤلف = Bill Cerveny |
| مؤلف = Bill Cerveny |
||
| مسار أرشيف = https://web.archive.org/web/20180626001504/https://asert.arbornetworks.com/ipv6-fragmentation/ |
| مسار أرشيف = https://web.archive.org/web/20180626001504/https://asert.arbornetworks.com/ipv6-fragmentation/ |
||
| تاريخ أرشيف = 26 يونيو 2018 |
| تاريخ أرشيف = 26 يونيو 2018 |
||
| تاريخ = 25 يوليو 2011 |
| تاريخ = 25 يوليو 2011 |
||
| مسار= https:// |
| مسار= https://www.netscout.com/blog/asert/ipv6-fragmentation |
||
| عنوان= IPv6 Fragmentation |
| عنوان= IPv6 Fragmentation |
||
| موقع= ARBOR NETWORKS, INC. |
| موقع= ARBOR NETWORKS, INC. |
||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 18 يوليو 2018}}</ref> ويكون الطول الكليّ |
| تاريخ الوصول= 18 يوليو 2018}}</ref> ويكون الطول الكليّ مُطابقًا أو قريبًا من طول وحدة النقل العظمى. يكون مُعرّف هذه الرزمة مُطابقًا لمعرف الرزمة الأصلية، ويُرفع فيها علم المزيد من القطع وتكون إزاحتها مساوية للصفر.<ref name="Web-36"/> |
||
* '''رزم وسطيّة''': تظهر الرزم الوسطية إذا كان عدد القطع التانجة أكثر من اثنين، تضم الرزمة الوسطية ترويسة البروتوكول والتوسيعات وترويسة القطعة، وقطعة من الحمولة، ويكون الطول الكلي |
* '''رزم وسطيّة''': تظهر الرزم الوسطية إذا كان عدد القطع التانجة أكثر من اثنين، تضم الرزمة الوسطية ترويسة البروتوكول والتوسيعات وترويسة القطعة، وقطعة من الحمولة، ويكون الطول الكلي مُطابقًا أو قريبًا من طول وحدة النقل الأعظميّة. يكون مُعرّف هذه الرزمة مطابقًا لمعرف الرزمة الأصلية، ويُرفع فيها علم المزيد من القطع وتختلف قيمة الإزاحة فيها بحسب الموقع النسبي لقطعة الحمولة في الرزمة الأصلية. |
||
* '''الرزمة الأخيرة''': وتضمّ ترويسة البروتوكول والتوسيعات وترويسة القطعة، وآحر قطعة من الحمولة، ويكون مُعرّف هذه الرزمة |
* '''الرزمة الأخيرة''': وتضمّ ترويسة البروتوكول والتوسيعات وترويسة القطعة، وآحر قطعة من الحمولة، ويكون مُعرّف هذه الرزمة مُطابقًا لمعرف الرزمة الأصلية، ولا يُرفع فيها علم المزيد من القطع،<ref name="Web-30">{{استشهاد ويب |
||
| مؤلف = Charles M. Kozierok. |
| مؤلف = Charles M. Kozierok. |
||
| مسار أرشيف = https://web.archive.org/web/20180102061631/http://network-insight.net/2015/10/ipv6-fragmentation/ |
| مسار أرشيف = https://web.archive.org/web/20180102061631/http://network-insight.net/2015/10/ipv6-fragmentation/ |
||
سطر 832: | سطر 781: | ||
| موقع= The TCP/IP Guide |
| موقع= The TCP/IP Guide |
||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 20 يوليو 2018}}</ref> وتضبط قيمة الإزاحة فيها بحسب الموقع النسبي لقطعة الحمولة في الرزمة الأصلية. وليس بالضرورة أن يكون طول الرزمة الأخيرة الكلي |
| تاريخ الوصول= 20 يوليو 2018}}</ref> وتضبط قيمة الإزاحة فيها بحسب الموقع النسبي لقطعة الحمولة في الرزمة الأصلية. وليس بالضرورة أن يكون طول الرزمة الأخيرة الكلي مُطابقًا أو قريبًا من طول وحدة النقل العظمى، وغالبًا ما تكون ذات حجم صغير غير مناسب.<ref name="Web-37"/> |
||
==== قضايا أمنية ==== |
==== قضايا أمنية ==== |
||
ينتج عن استخدام التقطيع في [[الإصدار السادس من بروتوكول الإنترنت]] عدد من [[ثغرة أمنية|الثغرات أمنيّة]] التي قد تستخدم لشن هجمات مثل هجوم القطعة الصغيرة أو هجوم القطع المتراكبة، وتختلف إمكانية شن الهجمات بحسب [[نظام التشغيل]] الذي يستعمل البروتوكول.<ref name = "JOU-9">{{ |
ينتج عن استخدام التقطيع في [[بروتوكول الإنترنت (الإصدار السادس)|الإصدار السادس من بروتوكول الإنترنت]] عدد من [[ثغرة أمنية (حوسبة)|الثغرات أمنيّة]] التي قد تستخدم لشن هجمات مثل هجوم القطعة الصغيرة أو هجوم القطع المتراكبة، وتختلف إمكانية شن الهجمات بحسب [[نظام تشغيل|نظام التشغيل]] الذي يستعمل البروتوكول.<ref name = "JOU-9">{{استشهاد بدورية محكمة |
||
|الأخير= Atlasis |
|الأخير= Atlasis |
||
|الأول= Antonios |
|الأول= Antonios |
||
سطر 842: | سطر 791: | ||
|عنوان= Attacking IPv6 Implementation Using Fragmentation |
|عنوان= Attacking IPv6 Implementation Using Fragmentation |
||
|سنة= 2002 |
|سنة= 2002 |
||
| مسار = |
| مسار = https://docs.huihoo.com/blackhat/europe-2012/bh-eu-12-Atlasis-Attacking_IPv6-WP.pdf |
||
}}</ref> بشكلٍ مُشابه [[ |
| مسار أرشيف = 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 |
| الأخير= Krishnan |
||
| الأول= S. |
| الأول= S. |
||
| تاريخ= فبراير 2016 |
| تاريخ= فبراير 2016 |
||
| مسار أرشيف = |
| مسار أرشيف = https://web.archive.org/web/20200509163441/https://www.ietf.org/rfc/rfc5722 |
||
| مسار= https://www.ietf.org/rfc/rfc5722 |
| مسار= https://www.ietf.org/rfc/rfc5722 |
||
| عنوان= RFC 5722, Handling of Overlapping IPv6 Fragments |
| عنوان= RFC 5722, Handling of Overlapping IPv6 Fragments |
||
| موقع= The Internet Society |
| موقع= The Internet Society |
||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 21 يوليو 2018| |
| تاريخ الوصول= 21 يوليو 2018|تاريخ أرشيف=2020-05-09|url-status=dead}}</ref> |
||
يقبل [[مضيف (حوسبة)|مُضيف]] الإصدار السادس من بروتوكول الإنترنت أن تحتوي [[رزمة بيانات|رزمة البيانات]] على [[ترويسة]] القطعة بدون تكون القطعة ناتجة عن عملية تقطيع، وتسمى هذه القطع بالقطع الذرية {{إنج|Atomic Fragment}} وهي تنتج في حالات خاصة ناقشها المعيار الأصلي للبروتوكول،<ref name="ietf-9"/> على الرغم من أن هذه القطع تكون وحداناً، أي لا يجب أن يتم تجميعها مع أي قطع أخرى، فإنّ المُضيف الوجهة يعاملها مُعاملة القطع التي تنتظر التجميع، ما يُسبب ثغرة أمنية، فقد يقوم المهاجم بإرسال قطعة خبيثة مع قيم مُناسبة في ترويسة القطعة، بحيث تكون قطعة ذرية تقبل التجميع مع قطع أخرى خبيثة تُرسل |
يقبل [[مضيف (حوسبة)|مُضيف]] الإصدار السادس من بروتوكول الإنترنت أن تحتوي [[رزمة بيانات|رزمة البيانات]] على [[ترويسة (حوسبة)|ترويسة]] القطعة بدون تكون القطعة ناتجة عن عملية تقطيع، وتسمى هذه القطع بالقطع الذرية {{إنج|Atomic Fragment}} وهي تنتج في حالات خاصة ناقشها المعيار الأصلي للبروتوكول،<ref name="ietf-9"/> على الرغم من أن هذه القطع تكون وحداناً، أي لا يجب أن يتم تجميعها مع أي قطع أخرى، فإنّ المُضيف الوجهة يعاملها مُعاملة القطع التي تنتظر التجميع، ما يُسبب ثغرة أمنية، فقد يقوم المهاجم بإرسال قطعة خبيثة مع قيم مُناسبة في ترويسة القطعة، بحيث تكون قطعة ذرية تقبل التجميع مع قطع أخرى خبيثة تُرسل لاحقًا، ناقشت الوثيقة RFC 6946 كيفية معالجة القطع الذرية لتلافي هذا النوع من الهجمات.<ref name="ietf-20">{{استشهاد ويب |
||
| الأخير= Gont |
| الأخير= Gont |
||
| الأول= F. |
| الأول= F. |
||
| تاريخ= مايو 2013 |
| تاريخ= مايو 2013 |
||
| مسار أرشيف = |
| مسار أرشيف = https://web.archive.org/web/20200509163442/https://www.ietf.org/rfc/rfc6946 |
||
| مسار= https://www.ietf.org/rfc/rfc6946 |
| مسار= https://www.ietf.org/rfc/rfc6946 |
||
| عنوان= RFC 6946, Processing of IPv6 "Atomic" Fragments |
| عنوان= RFC 6946, Processing of IPv6 "Atomic" Fragments |
||
سطر 864: | سطر 813: | ||
| لغة= en |
| لغة= en |
||
| issn = 2070-1721 |
| issn = 2070-1721 |
||
| تاريخ الوصول= 21 يوليو 2018| |
| تاريخ الوصول= 21 يوليو 2018|تاريخ أرشيف=2020-05-09|url-status=dead}}</ref> |
||
== التقطيع في طبقة ربط البيانات == |
== التقطيع في طبقة ربط البيانات == |
||
{| class="wikitable floatleft" width="65%" |
{| class="wikitable floatleft" width="65%" |
||
|- |
|- |
||
|+ قيم وحدة النقل |
|+ قيم وحدة النقل العظمى لبعض بروتوكولات طبقة ربط البيانات. |
||
|- |
|- |
||
! اسم البروتوكول !! اختصار !! حجم وحدة النقل |
! اسم البروتوكول !! اختصار !! حجم وحدة النقل العظمى الأدنى (بايت) !! حجم وحدة النقل العظمى الأقصى (بايت) !! المرجع |
||
|- |
|- |
||
| [[الإيثرنت]] || IEEE 802.3 || 64 || 1518 {{للهامش|5}} || <ref name="JOU-5"/> |
| [[إيثرنت|الإيثرنت]] || IEEE 802.3 || 64 || 1518 {{للهامش|5}} || <ref name="JOU-5"/> |
||
|- |
|- |
||
| بروتوكول حلقة الرمز || IEEE 802.5 || لا يوجد حد أدنى || 17794 || <ref name="Web-55">{{ |
| بروتوكول حلقة الرمز || IEEE 802.5 || لا يوجد حد أدنى || 17794 || <ref name="Web-55">{{استشهاد ويب |
||
| مؤلف = Brent Baccala |
| مؤلف = Brent Baccala |
||
| مسار أرشيف = https://web.archive.org/web/20160605205826/http://www.freesoft.org/CIE/RFC/1042/10.htm |
| مسار أرشيف = https://web.archive.org/web/20160605205826/http://www.freesoft.org/CIE/RFC/1042/10.htm |
||
| تاريخ أرشيف = 5 يونيو 2016 |
| تاريخ أرشيف = 5 يونيو 2016 |
||
| تاريخ = أبريل 1997 |
| تاريخ = أبريل 1997 |
||
| مسار= |
| مسار= https://www.freesoft.org/CIE/RFC/1042/10.htm |
||
| عنوان= IEEE 802.5 Details |
| عنوان= IEEE 802.5 Details |
||
| موقع= Connected: An Internet Encyclopedia |
| موقع= Connected: An Internet Encyclopedia |
||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 29 يوليو 2018}}</ref><ref name="Web-56">{{ |
| تاريخ الوصول= 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 |
|||
| مسار أرشيف = |
|||
| تاريخ أرشيف = |
|||
| مسار= https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.hald001/tokenx.htm |
|||
| عنوان= Token-Ring IEEE 802.5 |
| عنوان= Token-Ring IEEE 802.5 |
||
| موقع= IBM Corporation |
| موقع= IBM Corporation |
||
سطر 898: | سطر 844: | ||
| بروتوكول الشبكات الشخصية اللاسلكية منخفضة المعدل || IEEE 802.15.4 || غير مُحدد || 127 || <ref name="JOU-10"/> |
| بروتوكول الشبكات الشخصية اللاسلكية منخفضة المعدل || 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 |
| مسار أرشيف = 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 |
| تاريخ أرشيف = 13 مايو 2017 |
||
| تاريخ = |
|||
| مسار= https://www.cisco.com/c/en/us/support/docs/asynchronous-transfer-mode-atm/atm-traffic-management/24041-lfi-24041.html |
| مسار= 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 |
| عنوان= Configuring Link Fragmentation and Interleaving (LFI) With Campus ATM Switches |
||
| موقع= Cisco Systems, Inc. |
| موقع= Cisco Systems, Inc. |
||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 20 يوليو 2018}}</ref><ref name="Web-25">{{ |
| تاريخ الوصول= 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 |
| مسار أرشيف = https://web.archive.org/web/20180720161603/https://www.juniper.net/documentation/en_US/junos/topics/concept/interface-link-services-lfi-understanding.html |
||
| تاريخ أرشيف = 20 يوليو 2018 |
| تاريخ أرشيف = 20 يوليو 2018 |
||
| مسار= https://www.juniper.net/documentation/en_US/junos/topics/ |
| مسار= 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 |
| عنوان= Understanding Link Fragmentation and Interleaving Configuration |
||
| موقع= Juniper Networks, Inc |
| موقع= Juniper Networks, Inc |
||
سطر 918: | سطر 862: | ||
| تاريخ الوصول= 20 يوليو 2018}}</ref> |
| تاريخ الوصول= 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 |
| مسار أرشيف = 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 |
| تاريخ أرشيف = 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 |
| عنوان= Media MTU Sizes by Interface Type |
||
| موقع= Juniper Networks, Inc. |
| موقع= Juniper Networks, Inc. |
||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 29 يوليو 2018}}</ref><ref name="Web-59">{{ |
| تاريخ الوصول= 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 |
| مسار أرشيف = 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 |
| تاريخ أرشيف = 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 |
| عنوان= MTU Behavior on Cisco IOS XR and Cisco IOS Routers |
||
| موقع= Cisco Systems, Inc. |
| موقع= Cisco Systems, Inc. |
||
سطر 935: | سطر 879: | ||
=== التقطيع في بروتوكول الشبكات المحلية اللاسلكية === |
=== التقطيع في بروتوكول الشبكات المحلية اللاسلكية === |
||
[[ |
[[ملف:IEEE 802.11 Fragmentation - ar.png|تصغير|300بك|مفهوم التقطيع في الشبكات المحلية اللاسلكية.]] |
||
يُعرف معيار [[آي تربل إي 802.11|بروتوكول الشبكات المحلية اللاسلكية]] {{إنج|IEEE 802.11}} عملية التقطيع بأنها تجزيء وحدات بيانات البروتوكول الخاصة بطبقة [[تحكم بالوصول للوسط|التحكم بالوصول للوسط]] إلى أجزاء أصغر، |
يُعرف معيار [[آي تربل إي 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 |
|عنوان= 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 |
|صفحة= 1301 |
||
| ناشر = IEEE |
| ناشر = IEEE |
||
سطر 946: | سطر 889: | ||
}}</ref> |
}}</ref> |
||
يتم التحكم بعملية التقطيع بواسطة مُحدد خاص اسمه عتبة التقطيع {{إنج|dot11FragmentThreshold}}، وتسمح تطبيقات البروتوكول لمشرفي الشبكة بضبط هذه القيمة، وأي إطار بيانات يتجاوز طوله قيمة العتبة يجب تقطيعه، ولكن لا يوجد خوارزمية محددة للتقطيع ويترك أمر تحديد الطريقة لمن يقوم بتنفيذ البروتوكول.<ref name = "Book-3">{{ |
يتم التحكم بعملية التقطيع بواسطة مُحدد خاص اسمه عتبة التقطيع {{إنج|dot11FragmentThreshold}}، وتسمح تطبيقات البروتوكول لمشرفي الشبكة بضبط هذه القيمة، وأي إطار بيانات يتجاوز طوله قيمة العتبة يجب تقطيعه، ولكن لا يوجد خوارزمية محددة للتقطيع ويترك أمر تحديد الطريقة لمن يقوم بتنفيذ البروتوكول.<ref name = "Book-3">{{استشهاد بكتاب |
||
| |
|مؤلف1-الأخير = Gast |
||
| |
|مؤلف1-الأول =Matthew |
||
|عنوان= 802.11 Wireless Networks: The Definitive Guide |
|عنوان= 802.11 Wireless Networks: The Definitive Guide |
||
|مسار = https://archive.org/details/wirelessnetworks00gast_193 |
|||
|طبعة= الأولى |
|طبعة= الأولى |
||
|صفحة= [https://archive.org/details/wirelessnetworks00gast_193/page/n45 46] |
|||
|صفحة= 46 |
|||
|سنة=2002 |
|سنة=2002 |
||
|ناشر= O'Reilly Media |
|ناشر= O'Reilly Media |
||
| |
|ردمك= 0596001835 |
||
|لغة= en |
|لغة= en |
||
}}</ref> |
}}</ref> |
||
وجدت دراسة لاحقة بأن عملية التقطيع تحسّن من أداء بروتوكول الشبكات المحلية اللاسلكية عند في حال التداخل الراديوي، فعند إنقاص قيمة عتبة التقطيع يتناقص معدل خطأ البت المحلي الخاص بالمستقبل الراديوي لنقطة الوصول ويتناقص العدد الكلي لمحاولات إعادة الإرسال وتزداد إنتاجية المستقبل الراديوي. أمّا عند زيادة قيمة عتبة التقطيع فيتناقص التأخير الكلي للوصول إلى الوسط، |
وجدت دراسة لاحقة بأن عملية التقطيع تحسّن من أداء بروتوكول الشبكات المحلية اللاسلكية عند في حال التداخل الراديوي، فعند إنقاص قيمة عتبة التقطيع يتناقص معدل خطأ البت المحلي الخاص بالمستقبل الراديوي لنقطة الوصول ويتناقص العدد الكلي لمحاولات إعادة الإرسال وتزداد إنتاجية المستقبل الراديوي. أمّا عند زيادة قيمة عتبة التقطيع فيتناقص التأخير الكلي للوصول إلى الوسط، وأيضًا [[تقلقل الإرسال]] الكلي.<ref name = "JOU-3">{{استشهاد بدورية محكمة |
||
|الأخير= Diaconu |
|الأخير= Diaconu |
||
|الأول= Felix |
|الأول= Felix |
||
سطر 965: | سطر 909: | ||
|المجلد= 58 |
|المجلد= 58 |
||
|العدد = 2 |
|العدد = 2 |
||
| |
| تاريخ = يوليو 2011 |
||
|شهر= يوليو |
|||
|صفحة= 81-88 |
|صفحة= 81-88 |
||
| ناشر = |
|||
| doi = |
|||
| issn = |
|||
| مسار = http://www.bulipi-eee.tuiasi.ro/archive/2012/fasc.2/p8_f2_2012.pdf |
| مسار = 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> |
|||
}}</ref> |
|||
=== التقطيع في شبكات تبديل الأطر === |
=== التقطيع في شبكات تبديل الأطر === |
||
[[ |
[[ملف:LFI in frame relay - ar.png|تصغير|300بك|والتقطيع والتوزيع في طبقة الربط في [[تبديل الأطر|شبكة تبديل الأطر]].]] |
||
إن الهدف الأساسي من التقطيع في [[تبديل الأطر|شبكة تبديل الأطر]] هو دعم حركة البيانات الحساسة للتأخير عند حركتها عبر الشبكة، بحيث يتم تقطيع أطر البيانات ذات الأطوال الكبيرة إلى قطع صغيرة بحيث لا يسبب إرسالها |
إن الهدف الأساسي من التقطيع في [[تبديل الأطر|شبكة تبديل الأطر]] هو دعم حركة البيانات الحساسة للتأخير عند حركتها عبر الشبكة، بحيث يتم تقطيع أطر البيانات ذات الأطوال الكبيرة إلى قطع صغيرة بحيث لا يسبب إرسالها تأخيرًا كبيرًا لبقية الأطر. تسمح هذه التقنية للأطر الحساسة وغير للتأخير الزمني بتشارك نفس القناة الافتراضية عبر نفس المنفذ.<ref name = "Book-7">{{استشهاد بكتاب |
||
|مؤلف1= Jeff T. Buckwalter |
|مؤلف1= Jeff T. Buckwalter |
||
|عنوان= Frame Relay: Technology and Practice |
|عنوان= Frame Relay: Technology and Practice |
||
سطر 983: | سطر 923: | ||
| طبعة = الأولى |
| طبعة = الأولى |
||
|ناشر= Addison-Wesley Professional |
|ناشر= Addison-Wesley Professional |
||
| |
|ردمك= 0201485249 |
||
|لغة= en |
|لغة= en |
||
}}</ref> وُصفت محددات التقطيع بمعيار خاص تحت الاسم الرمزي (FRF.12).<ref name="Web-51">{{ |
}}</ref> وُصفت محددات التقطيع بمعيار خاص تحت الاسم الرمزي (FRF.12).<ref name="Web-51">{{استشهاد ويب |
||
| مؤلف = Andrew G. Malis |
| مؤلف = Andrew G. Malis |
||
| مسار أرشيف = https://web.archive.org/web/20160426183112/https://www.broadband-forum.org/technical/download/FRF.12/frf12.pdf |
| مسار أرشيف = https://web.archive.org/web/20160426183112/https://www.broadband-forum.org/technical/download/FRF.12/frf12.pdf |
||
سطر 994: | سطر 934: | ||
| موقع= Broadband Forum |
| موقع= Broadband Forum |
||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 28 يوليو 2018| |
| تاريخ الوصول= 28 يوليو 2018|url-status=dead}}</ref> |
||
يستخدم التقطيع في شبكة تبديل الأطر كجزء من آلية التقطيع والتوزيع في طبقة الربط (LFI).<ref name="Web-26"/> لا يوجد طول مُحدد مُلزم لوحدة النقل الأعظمي، ولكن من الأفضل أن يكون الطول المُختار |
يستخدم التقطيع في شبكة تبديل الأطر كجزء من آلية التقطيع والتوزيع في طبقة الربط (LFI).<ref name="Web-26"/> لا يوجد طول مُحدد مُلزم لوحدة النقل الأعظمي، ولكن من الأفضل أن يكون الطول المُختار متناسبًا مع [[معدل ساعة (حاسوب)|معدل الساعة]] للقناة الفيزيائية ومعدل التقل عبر القنوات الافتراضية.<ref name="Web-52">{{استشهاد ويب |
||
| مؤلف = Andrew G. Malis |
| مؤلف = Andrew G. Malis |
||
| مسار أرشيف = https://web.archive.org/web/20170612170757/http://www.rhyshaden.com/frame.htm |
| مسار أرشيف = https://web.archive.org/web/20170612170757/http://www.rhyshaden.com/frame.htm |
||
| تاريخ أرشيف = 12 يونيو 2017 |
| تاريخ أرشيف = 12 يونيو 2017 |
||
| تاريخ = |
|||
| مسار= http://www.rhyshaden.com/frame.htm |
| مسار= http://www.rhyshaden.com/frame.htm |
||
| عنوان= Frame Relay, section: Frame Relay Fragmentation |
| عنوان= Frame Relay, section: Frame Relay Fragmentation |
||
| موقع= Rhys Haden |
| موقع= Rhys Haden |
||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 28 يوليو 2018}}</ref> |
| تاريخ الوصول= 28 يوليو 2018}}</ref> تُستخدم خوارزمية التقطيع الخاصّة ببروتوكول الربط بين نقطتين مُتعدد الوصلات.<ref name="ietf-27"/> |
||
==== أنماط التقطيع ==== |
==== أنماط التقطيع ==== |
||
[[ |
[[ملف:Frame Relay Fragmentation Types - ar.png|تصغير|300بك|أنماط التقطيع في شبكات تبديل الأطر: (1) تقطيع بين المستخدم والشبكة، (2) تقطيع داخل الشبكة، (3) تقطيع بين الطرفيات]] |
||
يُعرّف معيار التقطيع في شبكات تبديل الأطر ثلاث أنماط من التقطيع:<ref name="Web-51"/> |
يُعرّف معيار التقطيع في شبكات تبديل الأطر ثلاث أنماط من التقطيع:<ref name="Web-51"/> |
||
* '''التقطيع بين المُستخدم والشبكة''' {{إنج|UNI Fragmentation}}: ويحصل بين [[ |
* '''التقطيع بين المُستخدم والشبكة''' {{إنج|UNI Fragmentation}}: ويحصل بين [[جهاز اتصال البيانات|جهاز اتصال بيانات]] (DCE) و[[جهاز بيانات طرفي]] (DTE) بهدف السماح [[إطار البيانات|لأطر البيانات]] الحساسة وغير الحساسة للتأخير بتشارك نفس المنفذ الذي يصل بين المستخدم والشبكة، والذي غالبًا ما يكون ذو [[معدل نقل البتات|معدل]] نقل منخفض. في هذا النمط، يتم تجميع الإطار مجددًا قبل دخوله شبكة تبديل الإطار، ويُرسل كاملًا عبرها. |
||
* '''التقطيع داخل الشبكة''' {{إنج|NNI Fragmentation}}: ويكون هذا التقطيع غير مرئي بالنسبة للطرفيات حيث تحصل عمليتي التقطيع والتجميع داخل شبكة تبديل الأطر، وهو يهدف للسماح لأطر البيانات الحساسة وغير الحساسة للتأخير بتشارك نفس القناة الافتراضية. إن عمليتي التقطيع بين المستخدم والشبكة، والتقطيع داخل الشبكة متطابقتين من حيث الينية والخوارزمية المستعملة، وتُستخدمان في القنوات الافتراضية الدائمة {{اختصار مخفي|SVC|اختصار أول}} |
* '''التقطيع داخل الشبكة''' {{إنج|NNI Fragmentation}}: ويكون هذا التقطيع غير مرئي بالنسبة للطرفيات حيث تحصل عمليتي التقطيع والتجميع داخل شبكة تبديل الأطر، وهو يهدف للسماح لأطر البيانات الحساسة وغير الحساسة للتأخير بتشارك نفس القناة الافتراضية. إن عمليتي التقطيع بين المستخدم والشبكة، والتقطيع داخل الشبكة متطابقتين من حيث الينية والخوارزمية المستعملة، وتُستخدمان في القنوات الافتراضية الدائمة {{اختصار مخفي|SVC|اختصار أول}} والمبدلة {{اختصار مخفي|SVC|اختصار ثاني}}. |
||
* '''التقطيع بين الطرفيات''' {{إنج|End-to-End Fragmentation}}: ويحصل هذا التقطيع بين الطرفيات، |
* '''التقطيع بين الطرفيات''' {{إنج|End-to-End Fragmentation}}: ويحصل هذا التقطيع بين الطرفيات، وتحديدًا بين جهازي بيانات طرفيين، ويكون غير مرئي بالنسبة لشبكة تبديل الأطر، ولا يُستخدم إلا في القنوات الافتراضية الدائمة. |
||
==== ترويسة القطعة ==== |
==== ترويسة القطعة ==== |
||
[[ |
[[ملف:Fragment Encapsulation in frame relay - ar.png|تصغير|300بك|الحالات المختلفة لتغليف قطعة بيانات عند استخدام بروتوكول تبديل الأطر كبروتوكول ربط.]] |
||
يجري تقطيع حمولة الإطار الأصلي إلى قطعتين أو أكثر، وتضاف ترويسة بروتوكول تبديل الأطر إلى كل القطع، وهي بطول 2 بايت، |
يجري تقطيع حمولة الإطار الأصلي إلى قطعتين أو أكثر، وتضاف ترويسة بروتوكول تبديل الأطر إلى كل القطع، وهي بطول 2 بايت، وأيضًا ترويسة التقطيع، وهي بطول 2 بايت أيضًا، وفي حالة التقطيع بين الطرفيات يضاف مُعرف بروتوكول طبقة الشبكة {{إنج| Network Layer Protocol ID اختصاراً NLPID}} وهو بطول 1 بايت، ويضبط إلى القيمة <sub>16</sub>(1B) في حالة التقطيع.<ref name="ietf-28">{{استشهاد ويب |
||
| الأخير= Brown |
| الأخير= Brown |
||
| الأول= C. |
| الأول= C. |
||
| |
| مؤلف2-الأخير= Malis |
||
| |
| مؤلف2-الأول= A. |
||
| تاريخ= سبتمبر 1998 |
| تاريخ= سبتمبر 1998 |
||
| مسار أرشيف = |
| مسار أرشيف = https://web.archive.org/web/20200509163443/https://www.ietf.org/rfc/rfc2427 |
||
| مسار= https://www.ietf.org/rfc/rfc2427 |
| مسار= https://www.ietf.org/rfc/rfc2427 |
||
| عنوان= RFC 2427, Multiprotocol Interconnect over Frame Relay |
| عنوان= RFC 2427, Multiprotocol Interconnect over Frame Relay |
||
سطر 1٬029: | سطر 968: | ||
| موقع= The Internet Society |
| موقع= The Internet Society |
||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 29 يوليو 2018}}</ref> أما ترتيب الإضافة عند التغليف فيكون بالشكل التالي:<ref name="Web-51"/> |
| تاريخ الوصول= 29 يوليو 2018|تاريخ أرشيف=2020-05-09}}</ref> أما ترتيب الإضافة عند التغليف فيكون بالشكل التالي:<ref name="Web-51"/> |
||
* في التقطيع بين المستخدم والشبكة، وفي التقطيع داخل الشبكة، تضاف ترويسة البروتوكول |
* في التقطيع بين المستخدم والشبكة، وفي التقطيع داخل الشبكة، تضاف ترويسة البروتوكول أولًا، ثم تضاف ترويسة التقطيع. |
||
* في التقطيع بين الطرفيات، تضاف ترويسة التقطيع |
* في التقطيع بين الطرفيات، تضاف ترويسة التقطيع أولًا، ثُمّ مُعرف بروتوكول طبقة الشبكة، ثم بايت محجوز يضبط إلى القيمة <sub>16</sub>(03)، وأخيرًا ترويسة بروتوكول تبديل الأطر. |
||
يضاف مُلحق بطول 2 بايت لكل القطع، يحتوي على ناتج تطبيق خوارزمية {{ |
يضاف مُلحق بطول 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 |
| مسار أرشيف = https://web.archive.org/web/20160512174203/http://www.cisco.com/c/en/us/support/docs/wan/frame-relay/47202-87.pdf |
||
| تاريخ أرشيف = 12 مايو 2016 |
| تاريخ أرشيف = 12 مايو 2016 |
||
| مسار= https://www.cisco.com/c/en/us/support/docs/wan/frame-relay/47202-87.pdf |
|||
| تاريخ = |
|||
| مسار= http://www.cisco.com/c/en/us/support/docs/wan/frame-relay/47202-87.pdf |
|||
| عنوان= Frame Relay Glossary |
| عنوان= Frame Relay Glossary |
||
| صفحة = 3 |
| صفحة = 3 |
||
سطر 1٬048: | سطر 985: | ||
* '''بت قطعة البداية''' {{إنج|Beginning fragment bit}}: وهو علم يشير إلى القطعة الأولى الناتجة عن التقطيع، يتم ضبطه إلى القيمة 1 في القطعة الأولى وإلى 0 في باقي القطع. |
* '''بت قطعة البداية''' {{إنج|Beginning fragment bit}}: وهو علم يشير إلى القطعة الأولى الناتجة عن التقطيع، يتم ضبطه إلى القيمة 1 في القطعة الأولى وإلى 0 في باقي القطع. |
||
* '''بت قطعة النهاية''' {{إنج|Ending fragment bit}}: وهو علم يشير إلى القطعة الأخيرة، يتم ضبطه إلى القيمة 1 في القطعة الأخيرة وإلى 0 في باقي القطع. |
* '''بت قطعة النهاية''' {{إنج|Ending fragment bit}}: وهو علم يشير إلى القطعة الأخيرة، يتم ضبطه إلى القيمة 1 في القطعة الأخيرة وإلى 0 في باقي القطع. |
||
* '''بت التحكم''' {{إنج|Control bit}}: محجوز لاستخدامات مستقبلية، يُضبط |
* '''بت التحكم''' {{إنج|Control bit}}: محجوز لاستخدامات مستقبلية، يُضبط دائمًا إلى القيمة 0. |
||
* '''الجزء العلوي من حقل التتابع''': طوله 4 بت، ويضم الجزء العلوي من حقل التتابع، وتزداد قيمة حقل التتابع بمقدار 1 مع كل قطعة جديدة يتم توليدها، بمعزل عن انتهاء إطار ما والبدء بتقطيع إطار جديد، أي إذا كانت قيمة الحقل N في آخر قطعة نتجت عن تقطيع إطار ما، فإن قيمة التتابع في القطعة الأولى التي ستنتج عن الإطار التالي الذي يتم تقطيع ستكون N+1. تضبط قيمة حقل التتابع بشكل اختياري لكل قناة افتراضية إلى قيمة ما، ثم تزداد بعد ذلك بقيمة واحد مع كل قطعة جديدة يتم تغليفها، يساعد هذا الحقل في إنجاز عملية التجميع من خلال تحديد الرزم القطع التي تنتمي لنفس الإطار الأصلي، وتحديد إزاحتها عن بدايته. |
* '''الجزء العلوي من حقل التتابع''': طوله 4 بت، ويضم الجزء العلوي من حقل التتابع، وتزداد قيمة حقل التتابع بمقدار 1 مع كل قطعة جديدة يتم توليدها، بمعزل عن انتهاء إطار ما والبدء بتقطيع إطار جديد، أي إذا كانت قيمة الحقل N في آخر قطعة نتجت عن تقطيع إطار ما، فإن قيمة التتابع في القطعة الأولى التي ستنتج عن الإطار التالي الذي يتم تقطيع ستكون N+1. تضبط قيمة حقل التتابع بشكل اختياري لكل قناة افتراضية إلى قيمة ما، ثم تزداد بعد ذلك بقيمة واحد مع كل قطعة جديدة يتم تغليفها، يساعد هذا الحقل في إنجاز عملية التجميع من خلال تحديد الرزم القطع التي تنتمي لنفس الإطار الأصلي، وتحديد إزاحتها عن بدايته. |
||
* '''بت محجوز''': قيمته |
* '''بت محجوز''': قيمته دومًا هي 1. |
||
* '''الجزء السفلي من حقل التتابع''' طوله 8 بت، ويضم الجزء السغلي من حقل التتابع. |
* '''الجزء السفلي من حقل التتابع''' طوله 8 بت، ويضم الجزء السغلي من حقل التتابع. |
||
=== التقطيع في بروتوكول الربط بين نقطتين متعدد الوصلات === |
=== التقطيع في بروتوكول الربط بين نقطتين متعدد الوصلات === |
||
[[ |
[[ملف:MLPPP model, topology and encapsulation - ar.png|تصغير|300بك|بروتوكول الربط بين نقطتين متعدد الوصلات، في الأعلى وإلى اليسار: [[طوبولوجيا شبكة|طوبولوجيا الشبكة]]، في الأعلى وإلى اليمين: [[نموذج الربط البيني للأنظمة المفتوحة|نموذج الاتصال المعياري]] المُوافق، في الأسفل: عملية [[تغليف (شبكات)|التغليف]].]] |
||
[[ |
[[ملف:MLPPP encapsualtion types - ar.png|تصغير|300بك|[[تغليف (شبكات)|تغليف]] قطعة البيانات عند استعمال بروتوكول الربط بين نقطتين متعدد الوصلات. (أ) رقم تتابع قصير (ب) رقم تتابع طويل.]] |
||
يُعرّف مُحدد [[ |
يُعرّف مُحدد [[بروتوكول الربط بين نقطتين]] (PPP) البرتوكول بأنه [[بروتوكول (اتصالات)|بروتوكول]] [[طبقة الوصلة|ربط]] يصل بين نقطتين هما طرفا الاتصال، ويمكن أن يقوم [[تغليف (شبكات)|بتغليف]] [[رزمة بيانات|رزم بيانات]] لبروتوكولات [[طبقة الشبكة|شبكة]] مختلفة.<ref name="ietf-26">{{استشهاد ويب |
||
| الأخير= Simpson |
| الأخير= Simpson |
||
| الأول= W. |
| الأول= W. |
||
| تاريخ= يوليو 1994 |
| تاريخ= يوليو 1994 |
||
| مسار أرشيف = https://web.archive.org/web/20050508143240/http://www.ietf.org/rfc/rfc1661| مسار= https://www.ietf.org/rfc/rfc1661 |
|||
| مسار أرشيف = |
|||
| مسار= https://www.ietf.org/rfc/rfc1661 |
|||
| عنوان= RFC 1661, The Point-to-Point Protocol (PPP) |
| عنوان= RFC 1661, The Point-to-Point Protocol (PPP) |
||
| موقع= The Internet Society |
| موقع= The Internet Society |
||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 25 يوليو 2018}}</ref> |
| تاريخ الوصول= 25 يوليو 2018| تاريخ أرشيف = 8 مايو 2005 }}</ref> لاحقًا أضيفت توسيعة لهذا البروتوكول تسمح بتجميع أكثر من خط نقل فيزيائي يمثل كل منها [[قناة اتصال]] مستقلة ضمن خط نقل افتراضي واحد يجمع هذه القنوات، وسميت هذه التوسيعة ببروتوكول النقل متعدد الوصلات بين نقطتين، ووصفت في وثيقة طلب التعليقات (RFC 1990).<ref name="ietf-27">{{استشهاد ويب |
||
| الأخير= Sklower |
| الأخير= Sklower |
||
| الأول= K. |
| الأول= K. |
||
| |
| مؤلف2-الأخير= Lloyd |
||
| |
| مؤلف2-الأول= B. |
||
| |
| مؤلف3-الأخير= McGregor |
||
| |
| مؤلف3-الأول= G. |
||
| |
| مؤلف4-الأخير= D. Carr |
||
| |
| مؤلف4-الأول= W. |
||
| |
| مؤلف5-الأخير= Coradetti |
||
| |
| مؤلف5-الأول= T. |
||
| تاريخ= أغسطس 1996 |
| تاريخ= أغسطس 1996 |
||
| مسار أرشيف = |
| مسار أرشيف = https://web.archive.org/web/20200509163444/https://www.ietf.org/rfc/rfc1990 |
||
| مسار= https://www.ietf.org/rfc/rfc1990 |
| مسار= https://www.ietf.org/rfc/rfc1990 |
||
| عنوان= RFC 1990, The PPP Multilink Protocol (MP) |
| عنوان= RFC 1990, The PPP Multilink Protocol (MP) |
||
| موقع= The Internet Society |
| موقع= The Internet Society |
||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 25 يوليو 2018}}</ref> كما قد يُستخدم التقطيع كجزء من آلية التقطيع والتوزيع في طبقة الربط (LFI).<ref name="Web-60">{{ |
| تاريخ الوصول= 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 |
| مسار أرشيف = https://web.archive.org/web/20180720161603/https://www.juniper.net/documentation/en_US/junos/topics/concept/interface-link-services-lfi-understanding.html |
||
| تاريخ أرشيف = 20 يوليو 2018 |
| تاريخ أرشيف = 20 يوليو 2018 |
||
| تاريخ = 24 أكتوبر 2017 |
| تاريخ = 24 أكتوبر 2017 |
||
| مسار= https://www.juniper.net/documentation/en_US/junos/topics/ |
| مسار= 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 |
| عنوان= Understanding Link Fragmentation and Interleaving Configuration |
||
| موقع= Juniper Networks, Inc. |
| موقع= Juniper Networks, Inc. |
||
سطر 1٬092: | سطر 1٬028: | ||
| تاريخ الوصول= 29 يوليو 2018}}</ref> |
| تاريخ الوصول= 29 يوليو 2018}}</ref> |
||
تُعرّف التوسيعة طبقة فرعية في نموذج الاتصال المعياري، تشغل الجزء العلوي من طبقة ربط البيانات، وتعمل فيها وحدة توسيعة البروتوكول، فترتبط مع وحدة بروتوكول طبقة الشبكة من جهة، ومع وحدتين أو أكثر |
تُعرّف التوسيعة طبقة فرعية في نموذج الاتصال المعياري، تشغل الجزء العلوي من طبقة ربط البيانات، وتعمل فيها وحدة توسيعة البروتوكول، فترتبط مع وحدة بروتوكول طبقة الشبكة من جهة، ومع وحدتين أو أكثر من وحدات بروتوكول الربط بين نقطتين من جهة أخرى، التي تشغل طبقة فرعية أخرى تُشكل الجزء الأدنى من طبقة ربط البيانات.<ref name="Web-46">{{استشهاد ويب |
||
| مؤلف = Charles M. Kozierok |
| مؤلف = Charles M. Kozierok |
||
| مسار أرشيف = https://web.archive.org/web/20170123080631/http://www.tcpipguide.com/free/t_PPPMultilinkProtocolMPMLPMLPPPPPPMP-2.htm |
| مسار أرشيف = https://web.archive.org/web/20170123080631/http://www.tcpipguide.com/free/t_PPPMultilinkProtocolMPMLPMLPPPPPPMP-2.htm |
||
سطر 1٬103: | سطر 1٬039: | ||
| تاريخ الوصول= 25 يوليو 2018}}</ref> |
| تاريخ الوصول= 25 يوليو 2018}}</ref> |
||
من أجل توزيع الحمل بين خطوط التقل التي تشكل الوسط الفيزيائي، تقوم توسيعة البروتوكول بتقطيع رزمة البيانات الواردة من طبقة الشبكة إلى عدد من القطع، ثم تضيف ترويسة خاصة تُسمى ترويسة القطعة لكل قطعة ناتجة، وتمرر القطع وفق سياسة توزيع محددة إلى وحدات بروتوكول الربط بين نقطتين، التي تقوم كل منها بدورها بإضافة ترويسة وملحق خاصين ببروتوكول الربط بين نقطتين، ويجري تغليف القطعة بهما، ثم يُمرر الناتج إلى الطبقة المادية، وتعاد هذه المراحل بترتيب معكوس في المستقبل، من أجل إعادة توليد رزمة البيانات الأصلية.<ref name="Web-47">{{ |
من أجل توزيع الحمل بين خطوط التقل التي تشكل الوسط الفيزيائي، تقوم توسيعة البروتوكول بتقطيع رزمة البيانات الواردة من طبقة الشبكة إلى عدد من القطع، ثم تضيف ترويسة خاصة تُسمى ترويسة القطعة لكل قطعة ناتجة، وتمرر القطع وفق سياسة توزيع محددة إلى وحدات بروتوكول الربط بين نقطتين، التي تقوم كل منها بدورها بإضافة ترويسة وملحق خاصين ببروتوكول الربط بين نقطتين، ويجري تغليف القطعة بهما، ثم يُمرر الناتج إلى الطبقة المادية، وتعاد هذه المراحل بترتيب معكوس في المستقبل، من أجل إعادة توليد رزمة البيانات الأصلية.<ref name="Web-47">{{استشهاد ويب |
||
| مؤلف = Charles M. Kozierok |
| مؤلف = Charles M. Kozierok |
||
| مسار أرشيف = https://web.archive.org/web/20171222024340/http://www.tcpipguide.com:80/free/t_PPPMultilinkProtocolMPFrameFormat-3.htm |
| مسار أرشيف = https://web.archive.org/web/20171222024340/http://www.tcpipguide.com:80/free/t_PPPMultilinkProtocolMPFrameFormat-3.htm |
||
سطر 1٬114: | سطر 1٬050: | ||
| تاريخ الوصول= 25 يوليو 2018}}</ref> |
| تاريخ الوصول= 25 يوليو 2018}}</ref> |
||
تضاف ترويسة التوسيعة لكل قطعة ناتجة، ثم تُضاف ترويسة البروتوكول التقليدية والمُلحق بعملية التغليف. يكون طول ترويسة التوسيعة إمّا (2) أو (4) بايت، وفي كلا الحالتين تتألف الترويسة من 4 حقول هي:<ref name="ietf-27"/><ref name="Web-48">{{ |
تضاف ترويسة التوسيعة لكل قطعة ناتجة، ثم تُضاف ترويسة البروتوكول التقليدية والمُلحق بعملية التغليف. يكون طول ترويسة التوسيعة إمّا (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 |
| مسار أرشيف = 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 |
| تاريخ أرشيف = 13 مايو 2017 |
||
سطر 1٬123: | سطر 1٬058: | ||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 25 يوليو 2018}}</ref> |
| تاريخ الوصول= 25 يوليو 2018}}</ref> |
||
* '''بت قطعة البداية''' (Beginning fragment bit): وهو علم يشير إلى القطعة الأولى، يتم ضبطه إلى القيمة (1) في أول قطعة تنتج عن عملية التقطيع، و(0) في بقية القطع. |
* '''بت قطعة البداية''' (Beginning fragment bit): وهو علم يشير إلى القطعة الأولى، يتم ضبطه إلى القيمة (1) في أول قطعة تنتج عن عملية التقطيع، و (0) في بقية القطع. |
||
* '''بت قطعة النهاية''' (Ending fragment bit): وهو علم يشير إلى القطعة الأخيرة، يتم ضبطه إلى القيمة (1) في آخر قطعة تنتج عن عملية التقطيع، و(0) في بقية القطع. |
* '''بت قطعة النهاية''' (Ending fragment bit): وهو علم يشير إلى القطعة الأخيرة، يتم ضبطه إلى القيمة (1) في آخر قطعة تنتج عن عملية التقطيع، و (0) في بقية القطع. |
||
* '''حقل رقم التتابع''' (Sequence number): ويدل على ترتيب القطعة بالنسبة لبقية القطع، يضبط في البداية إلى قيمة ابتدائية، ثُم تجري زيادتها بمقدار (1) في كل قطعة جديدة يتم تغليفها، قد يكون الحقل بطول (12) بت، ويُسمّى عندها التتابع القصير {{إنج|Short Sequence}} أو بطول (24) بت، ويُسمّى عندها التتابع الطويل {{إنج|Long Sequence}}.<ref name="Web-61">{{ |
* '''حقل رقم التتابع''' (Sequence number): ويدل على ترتيب القطعة بالنسبة لبقية القطع، يضبط في البداية إلى قيمة ابتدائية، ثُم تجري زيادتها بمقدار (1) في كل قطعة جديدة يتم تغليفها، قد يكون الحقل بطول (12) بت، ويُسمّى عندها التتابع القصير {{إنج|Short Sequence}} أو بطول (24) بت، ويُسمّى عندها التتابع الطويل {{إنج|Long Sequence}}.<ref name="Web-61">{{استشهاد ويب |
||
| مؤلف = Charles M. Kozierok |
| مؤلف = Charles M. Kozierok |
||
| مسار أرشيف = https://web.archive.org/web/20180121150314/http://www.tcpipguide.com/free/t_PPPMultilinkProtocolMPFrameFormat-3.htm |
| مسار أرشيف = https://web.archive.org/web/20180121150314/http://www.tcpipguide.com/free/t_PPPMultilinkProtocolMPFrameFormat-3.htm |
||
سطر 1٬136: | سطر 1٬071: | ||
| تاريخ الوصول= 29 يوليو 2018}}</ref> |
| تاريخ الوصول= 29 يوليو 2018}}</ref> |
||
* '''بتات محجوزة''': تُوجد بين العلمين ورقم التتابع، تُضبط إلى القيمة (0)، وعددها (2) إذا استخدم التتابع القصير أو (6) إذا استخدم التتابع الطويل. |
* '''بتات محجوزة''': تُوجد بين العلمين ورقم التتابع، تُضبط إلى القيمة (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 |
|صحيفة = IEEE Standard |
||
|عنوان= 802.3-2015 - IEEE Standard for Ethernet |
|عنوان= 802.3-2015 - IEEE Standard for Ethernet |
||
| |
| تاريخ = مارس 2016 |
||
|شهر= مارس |
|||
|صفحة= 2690-2699 |
|صفحة= 2690-2699 |
||
| ناشر = IEEE |
| ناشر = IEEE |
||
سطر 1٬151: | سطر 1٬083: | ||
| isbn = 978-1-5044-0078-7 |
| isbn = 978-1-5044-0078-7 |
||
| مسار = https://ieeexplore.ieee.org/document/7428776/ |
| مسار = https://ieeexplore.ieee.org/document/7428776/ |
||
| مسار أرشيف = https://web.archive.org/web/20191214185749/https://ieeexplore.ieee.org/document/7428776 | تاريخ أرشيف = 14 ديسمبر 2019 }}</ref> |
|||
}}</ref> |
|||
يتم تقطيع [[إطار البيانات]] |
يتم تقطيع [[إطار البيانات]] كاملًا في طرف الإرسال إلى عدد من القطع، ثُمّ يجري إضافة [[ترويسة (حوسبة)|ترويسة]] بطول 32 بت وملحق بطول 16 بت لكل قطعة، ويلي ذلك توزيع القطع على خطوط النقل. تُرسل القطع الناتجة عبر خطوط النقل التي تشكل وسط الاتصال في نفس الوقت، ويجري تجميعها في طرف الإستقبال اعتمادًا على الترويسة المُضافة، والتي تحتوي على حقل بطول بت، يسمى رقم التتابع، وهي يساعد المستقبل على إيجاد الترتيب الصحيح للقطع لإعادة تجميعها وإنشاء إطار البيانات الأصلي مجددًا في الطرف الذي استقبلها.<ref name="Web-44">{{استشهاد ويب |
||
| مؤلف = Howard Frazier |
| مؤلف = Howard Frazier |
||
| مسار أرشيف = https://web.archive.org/web/20160913204023/http://www.ieee802.org/3/ba/public/jan08/frazier_01_0108.pdf |
| مسار أرشيف = https://web.archive.org/web/20160913204023/http://www.ieee802.org/3/ba/public/jan08/frazier_01_0108.pdf |
||
سطر 1٬165: | سطر 1٬097: | ||
| تاريخ الوصول= 24 يوليو 2018}}</ref> |
| تاريخ الوصول= 24 يوليو 2018}}</ref> |
||
== انظر |
== انظر أيضًا == |
||
* [[تغليف (شبكات)|تغليف البيانات]]. |
* [[تغليف (شبكات)|تغليف البيانات]]. |
||
* [[حزمة بروتوكولات الإنترنت]] (TCP/IP). |
* [[حزمة بروتوكولات الإنترنت]] (TCP/IP). |
||
* [[وحدة النقل الأعظمية]] (MTU). |
|||
* [[وحدة بيانات بروتوكول]] (PDU). |
* [[وحدة بيانات بروتوكول]] (PDU). |
||
== هوامش == |
== هوامش == |
||
{{هامش|1}}. الرسالة هي رسالة «لا يمكن بلوغ الوجهة» {{إنج|Destination unreachable Message}}، لذلك يضبط حقل النوع في ترويسة البروتوكول إلى القيمة (3) وحقل الترميز إلى القيمة (4)، والتي تعني هناك حاجة للتقطيع ولكن علم عدم التقطيع مرفوع.<ref name="ietf-14">{{استشهاد ويب |
|||
{{هامش|1}}. الرسالة هي رسالة «لا يمكن بلوغ الوجهة» {{إنج|Destination unreachable Message}}، لذلك يضبط حقل النوع في ترويسة البروتوكول إلى القيمة (3) وحقل الترميز إلى القيمة (4)، والتي تعني هناك حاجة للتقطيع ولكن علم عدم التقطيع مرفوع.<ref name="ietf-14">{{مرجع ويب |
|||
| الأخير= Postal |
| الأخير= Postal |
||
| الأول= J. |
| الأول= J. |
||
سطر 1٬181: | سطر 1٬110: | ||
| موقع= The Internet Society |
| موقع= The Internet Society |
||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 14 يوليو 2018| مسار |
| تاريخ الوصول= 14 يوليو 2018| مسار أرشيف = https://web.archive.org/web/20190420021247/https://tools.ietf.org/html/rfc792 | تاريخ أرشيف = 20 أبريل 2019 }}</ref> |
||
{{هامش|2}}. الرسالة هي رسالة «الرزمة كبيرة |
{{هامش|2}}. الرسالة هي رسالة «الرزمة كبيرة جدًّا» {{إنج|Packet Too big}} لذلك يضبط حقل النوع في ترويسة البروتوكول إلى القيمة (2) وحقل الترميز إلى القيمة (0).<ref name="ietf-15">{{استشهاد ويب |
||
| الأخير= Conta |
| الأخير= Conta |
||
| الأول= A. |
| الأول= A. |
||
سطر 1٬195: | سطر 1٬124: | ||
| موقع= The Internet Society |
| موقع= The Internet Society |
||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 15 يوليو 2018| مسار |
| تاريخ الوصول= 15 يوليو 2018| مسار أرشيف = https://web.archive.org/web/20190402102314/https://tools.ietf.org/html/rfc4443 | تاريخ أرشيف = 2 أبريل 2019 }}</ref> |
||
{{هامش|3}}. يجب التمييز بين بروتوكول طبقة الشبكة وبروتوكول التشبيك،<ref name = "JOU-AD1">{{ |
{{هامش|3}}. يجب التمييز بين بروتوكول طبقة الشبكة وبروتوكول التشبيك،<ref name = "JOU-AD1">{{استشهاد بدورية محكمة |
||
|الأخير= POSTEL |
|الأخير= POSTEL |
||
|الأول= JONATHAN B. |
|الأول= JONATHAN B. |
||
|صحيفة = IEEE TRANSACTIONS ON COMMUNICATIONS |
|صحيفة = IEEE TRANSACTIONS ON COMMUNICATIONS |
||
|عنوان= Internetwork Protocol Approaches |
|عنوان= Internetwork Protocol Approaches |
||
| |
| تاريخ = أبريل 1980 |
||
|شهر= أبريل |
|||
| المجلد = 28 |
| المجلد = 28 |
||
| العدد = 4 |
| العدد = 4 |
||
سطر 1٬209: | سطر 1٬137: | ||
| ناشر = IEEE |
| ناشر = IEEE |
||
| doi = 10.1109/TCOM.1980.1094705 |
| doi = 10.1109/TCOM.1980.1094705 |
||
| isbn = |
|||
| issn = 0090-6778 |
| issn = 0090-6778 |
||
| مسار = http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.233.1383&rep=rep1&type=pdf |
| مسار = http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.233.1383&rep=rep1&type=pdf |
||
}}</ref> والذي يسمى |
| مسار أرشيف = 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"}}. |
{{هامش|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) |
{{هامش|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 |
| مسار أرشيف = https://web.archive.org/web/20170610042533/https://www.cisco.com/c/en/us/support/docs/lan-switching/8021q/17056-741-4.html |
||
| تاريخ أرشيف = 10 يونيو 2017 |
| تاريخ أرشيف = 10 يونيو 2017 |
||
| مسار= https://www.cisco.com/c/en/us/ |
| مسار= https://www.cisco.com/c/en/us/obsolete/switches/cisco-catalyst-2955-series-switches.html |
||
| عنوان= Inter-Switch Link and IEEE 802.1Q Frame Format |
| عنوان= Inter-Switch Link and IEEE 802.1Q Frame Format |
||
| موقع= Cisco systems, Inc, |
| موقع= Cisco systems, Inc, |
||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 29 يوليو 2018}}</ref> وثانيها [[تجسير (نظم)|الجسر]] المٌزوّد الموصوف بالمعيار (IEEE 802.1.ad)<ref name = "JOU-12">{{ |
| تاريخ الوصول= 29 يوليو 2018}}</ref> وثانيها [[تجسير (نظم)|الجسر]] المٌزوّد الموصوف بالمعيار (IEEE 802.1.ad)<ref name = "JOU-12">{{استشهاد بدورية محكمة |
||
|الأخير= |
|||
|الأول= |
|||
|صحيفة = IEEE Standards |
|صحيفة = IEEE Standards |
||
|عنوان= 802.1Q-2014 - IEEE Standard for Local and metropolitan area networks--Bridges and Bridged Networks |
|عنوان= 802.1Q-2014 - IEEE Standard for Local and metropolitan area networks--Bridges and Bridged Networks |
||
| تاريخ = ديسمبر 2014 |
|||
|المجلد= |
|||
|العدد = |
|||
|سنة= 2014 |
|||
|شهر= ديسمبر |
|||
|صفحة= |
|||
| ناشر= IEEE |
| ناشر= IEEE |
||
| doi = 10.1109/IEEESTD.2014.6991462 |
| doi = 10.1109/IEEESTD.2014.6991462 |
||
| isbn = 978-0-7381-9433-2 |
| isbn = 978-0-7381-9433-2 |
||
}}</ref> الذي يضيف (8) بايت بوسمة خاصة إلى الطول الأصلي فيصبح الطول الإجمالي (1526) بايت، وثالثها أطر الإيثرنت العملاقة {{إنج| Jumbo frame}} التي تُعرّف بأنها أي إطار إيثرنت يزيد طول حمولته عن (1500) بايت،<ref name = "JOU-13">{{ |
}}</ref> الذي يضيف (8) بايت بوسمة خاصة إلى الطول الأصلي فيصبح الطول الإجمالي (1526) بايت، وثالثها أطر الإيثرنت العملاقة {{إنج| Jumbo frame}} التي تُعرّف بأنها أي إطار إيثرنت يزيد طول حمولته عن (1500) بايت،<ref name = "JOU-13">{{استشهاد بدورية محكمة |
||
|صحيفة = IEEE Communications Magazine |
|صحيفة = IEEE Communications Magazine |
||
|عنوان |
|عنوان =Ethernet Jumbo Frames|تاريخ = نوفمبر 2009 |
||
|ناشر = ethernet alliance |
|||
|سنة= 2009 |
|||
|مسار = 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 |
|||
| ناشر= ethernet alliance |
|||
|تاريخ أرشيف = 25 مارس 2020 |
|||
| مسار = https://web.archive.org/web/20170812041549/http://www.ethernetalliance.org/wp-content/uploads/2011/10/EA-Ethernet-Jumbo-Frames-v0-1.pdf |
|||
|تاريخ الوصول = 30 يوليو 2018 |
|||
|حالة المسار = bot: unknown |
|||
}}</ref> وغيرها. |
}}</ref> وغيرها. |
||
{{هامش|6}}. يسبب استخدام تقنيات أمنية مثل [[الخصوصية المكافئة للشبكات السلكية]] (WEP) أو أشكال مختلفة من الوصول الآمن للشبكة اللاسلكية (WPA) لتشفير إطار البيانات زيادة في الحجم الأعظمي قد تصل حتى (20) |
{{هامش|6}}. يسبب استخدام تقنيات أمنية مثل [[الخصوصية المكافئة للشبكات السلكية]] (WEP) أو أشكال مختلفة من الوصول الآمن للشبكة اللاسلكية (WPA) لتشفير إطار البيانات زيادة في الحجم الأعظمي قد تصل حتى (20) بايت، ليصبح حجم وحدة النقل الأعظمي الأقصى هو (2324) بايت.<ref name = "JOU-14">{{استشهاد بدورية محكمة |
||
|الأخير= Ross |
|الأخير= Ross |
||
|الأول= David Andrew |
|الأول= David Andrew |
||
|صحيفة = |
|||
|عنوان= Securing IEEE 802.11 Wireless LANs |
|عنوان= Securing IEEE 802.11 Wireless LANs |
||
| |
| تاريخ = يونيو 2010 |
||
|شهر= يونيو |
|||
|صفحة= 119 |
|صفحة= 119 |
||
| ناشر= Queensland University of Technology |
| ناشر= Queensland University of Technology |
||
| مسار = https://eprints.qut.edu.au/37638/1/David_Ross_Thesis.pdf |
| مسار = 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">{{استشهاد ويب |
|||
}}</ref><ref name="Web-57">{{مرجع ويب |
|||
| مؤلف = |
|||
| مسار أرشيف = https://web.archive.org/web/20170223070803/https://www.cwnp.com/forums/posts?postNum=307311 |
| مسار أرشيف = https://web.archive.org/web/20170223070803/https://www.cwnp.com/forums/posts?postNum=307311 |
||
| تاريخ أرشيف = 23 فبراير2017 |
| تاريخ أرشيف = 23 فبراير2017 |
||
سطر 1٬265: | سطر 1٬185: | ||
| لغة= en |
| لغة= en |
||
| تاريخ الوصول= 29 يوليو 2018}}</ref> |
| تاريخ الوصول= 29 يوليو 2018}}</ref> |
||
== مراجع == |
== مراجع == |
||
{{مراجع|محاذاة=نعم}} |
|||
<div class="reflist4" style="height: 250px; overflow: auto; padding: 3px" > |
|||
{{مراجع|2|محاذاة=نعم}} |
|||
</div> |
|||
== وصلات خارجية == |
== وصلات خارجية == |
||
* [https://web.archive.org/web/20180626203534/https://www.cdn.geeksforgeeks.org/fragmentation-network-layer/ التقطيع في طبقة الشبكة]، مقالة عن التقطيع في [[بروتوكول الإنترنت (الإصدار الرابع)|الإصدار الرابع من بروتوكول الإنترنت]]. |
|||
{{تصنيف كومنز|Fragmentation (Networking)}} |
|||
{{ويكي الجامعة|Wireshark/IPv4 fragments}} |
|||
* [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 تقييم تقطيع رزم البيانات في الإصدارين الرابع والسادس من بروتوكول الإنترنت] مقالة بقلم جيف هوستن. |
* [https://web.archive.org/web/20180425142248/https://labs.ripe.net/Members/gih/evaluating-ipv4-and-ipv6-packet-fragmentation تقييم تقطيع رزم البيانات في الإصدارين الرابع والسادس من بروتوكول الإنترنت] مقالة بقلم جيف هوستن. |
||
{{حزمة بروتوكولات الإنترنت}} |
{{حزمة بروتوكولات الإنترنت}} |
||
{{شريط بوابات|إنترنت|علم الحاسوب}} |
{{شريط بوابات|إنترنت|علم الحاسوب}} |
||
{{شريط مختارة| |
{{شريط محتوى متميز|مختارة|التاريخ=30 يونيو 2019|النسخة=36323011}} |
||
[[تصنيف:بروتوكول الإنترنت]] |
[[تصنيف:بروتوكول الإنترنت]] |
||
[[تصنيف:بنية الإنترنت]] |
|||
[[تصنيف:بنية الشبكة]] |
|||
[[تصنيف:وظائف ومفاهيم طبقة الشبكة]] |
[[تصنيف:وظائف ومفاهيم طبقة الشبكة]] |
||
[[تصنيف:وظائف ومفاهيم طبقة النقل]] |
[[تصنيف:وظائف ومفاهيم طبقة النقل]] |
النسخة الحالية 14:56، 14 أبريل 2024
![](http://upload.wikimedia.org/wikipedia/commons/thumb/4/42/PDU_Fragmentation-ar.png/300px-PDU_Fragmentation-ar.png)
في بعض من طبقات نموذج الربط البيني للأنظمة المفتوحة لشبكات البيانات، التقطيع[1] (بالإنجليزية: Fragmentation) أو (بالإنجليزية: Segmentation)[2] هو تقسيم الحمولة في وحدة بيانات بروتوكول إلى قسمين أو أكثر بأطوال أصغر من طول الحمولة الأصلية. يحصل التقطيع عندما يتجاوز طول حمولة وحدة بيانات البروتوكول عتبة مُحددة يحددها بروتوكول الطبقة.
التقطيع هو وظيفة أساسية لبروتوكولات طبقة الشبكة،[3][4] ولكنه قد يحصل في طبقة النقل أو في طبقة ربط البيانات أو في الطبقة المادية.[5] يهدف التقطيع بشكل الأساسي إلى توليد وحدات بيانات بروتوكول بأطوال أقل، لكنّه قد يُستخدم كجزء من آلية التقطيع والتوزيع في طبقة الربط (LFI)،[6] أو لتحسين الوصول إلى الوسط المادي في الطبقة المادية.[7]
نظرة عامة
[عدل]![](http://upload.wikimedia.org/wikipedia/commons/thumb/4/4c/TCP-IP_fragmentation_-_ar.png/300px-TCP-IP_fragmentation_-_ar.png)
![](http://upload.wikimedia.org/wikipedia/commons/thumb/0/04/Types_of_Fragmentation_-_ar.png/300px-Types_of_Fragmentation_-_ar.png)
![](http://upload.wikimedia.org/wikipedia/commons/thumb/4/44/TCP_header_location_when_fragmenting_an_IP_packet_-_ar.png/300px-TCP_header_location_when_fragmenting_an_IP_packet_-_ar.png)
بحسب نموذج الاتصال المعياري، تتكون وحدة بيانات البروتوكول في كل طبقة من حمولة وترويسة،[8] والتقطيع هو تقسيم الحمولة في بعض طبقات النموذج، إلى قطعتين أو أكثر بحيث تُشكّل كل قطعة حمولة لوحدة بيانات بروتوكول أصغر من وحدة البيانات الأصلية التي تمّ تقطيعُها.[9] يحصل التقطيع في الطبقات الرابعة والثالثة والثانية والأولى من النموذج، وتحدد البروتوكولات التي تعمل في هذه الطبقات قيمًا مُميزة لكل طبقة، تُستخدم كعتبة لتحديد متى يحصل التقطيع، فإذا كان طول وحدة بيانات البروتوكول أكبر من قيمة العتبة كان التقطيع إلزاميًّا.[10]
إذا كان بروتوكول النقل المستعمل يدعم التقطيع، فإنّ التقطيع في طبقة النقل لا يحصل إلا في المُضيف المصدر فقط، وهو يهدف إلى إنشاء وحدات بيانات بروتوكول ذات طول أقصر من طول الوحدة الأصلية. لإنجاز التقطيع في هذه الطبقة، يتمّ اعتبار كل ما ورد من الطبقة الأعلى حمولة، ويجري تقسيمها إلى قطع، ثُم تُغلّف القطع بترويسة البروتوكول لتُنتج وحدات بيانات بروتوكول طبقة النقل.[5] يدعم بروتوكول التحكم بالنقل عملية التقطيع، وتسمى وحدة بيانات البروتوكول الناتجة عن تغليف أقسام الحمولة السابقة بترويسات البروتوكول قطعة (بالإنجليزية: Segment)، أمّا بروتوكول حزم بيانات المستخدم فهو لا يدعم التقطيع، ويُغلّف الحمولة بإضافة ترويسته لها كما وردت، دون تقطيعها، وتسمى وحدة بيانات البروتوكول الناتجة حزمة البيانات (بالإنجليزية: Datagram). وفي الحالتين يتم تمرير وحدات بيانات البروتوكول الناتجة إلى طبقة الشبكة.[11]
التقطيع هو وظيفة أساسية لبروتوكولات الشبكة، وهو يحصل بعد اتخاذ قرار التوجيه لوحدة بيانات البروتوكول، والتي تُسمى رزمة بيانات في هذه الطبقة، وقد يكون في المُضيف المصدر الذي ولد الرزمة أو في أحد المُوجّهات على المسار، أو في كليهما. تتحدد عملية تقطيع رزمة البيانات بمقارنة طول الرزمة مع وحدة التقل العظمى لطبقة الشبكة، يحصل التقطيع إذا كان طول الرزمة أكبر من قيمة وحدة النقل العظمى، وهو يهدف إلى إنشاء رزم بيانات ذات طول أصغر من الرزمة الأصلية. يُمكن أن يحصل التقطيع أكثر من مرة على طول المسار لحين وصول الرزمة إلى وجهتها، ويُسمّى حينها بالتقطيع المُتعدد. لا يتمّ تجميع قطع الرزمة إلا في المُضيف الوجهة، والسبب في ذلك أن القطع قد لا تسلك نفس المسار، وبالتالي لن تمر عبر نفس المُوجّهات في طريقها للمضيف الوجهة.[12] تمرر طبقة الشبكة رزم البيانات إلى طبقة ربط البيانات.
يُمكن أن يحصل التقطيع في طبقة ربط البيانات، إما لإنتاج أطر بيانات ذات طول أصغر، أو كجزء من آلية التقطيع والتوزيع في طبقة الربط (بالإنجليزية: Link Fragmentation and Interleaving اختصاراً LFI). يحصل التقطيع إذا كانت طول وحدة بيانات البروتوكول في طبقة ربط البيانات، ويسمى إطار البيانات، أكبر من قيمة وحدة النقل العظمى للطبقة. بعض بروتوكولات الربط لا يقوم بالتقطيع في هذه الطبقة، مثل الإيثرنت، ولكنه يحدد قيمة لوحدة النقل العظمى، ويجب على بروتوكول الشبكة أن يلتزم بها. تفرض بعض بروتوكولات الربط قيمة أعظمية محدودة بشكلٍ مُفرط لوحدة النقل العظمى، مثل بروتوكول الشبكات الشخصية اللاسلكية منخفضة المُعدّل [الإنجليزية] الذي يُحدد طول إطار البيانات الأعظمي ليكون 127 بايت فقط.[13] وقد يحصل التقطيع في الطبقة المادية، ولا يكون الهدف منه تقسيم وحدة بيانات البروتوكول إلى قطع أصغر، بل تحسين الوصول إلى وسط الاتصال المادي.[14]
برتبط التقطيع بعملية التغليف بشكلٍ وثيق، ويُسبب التقطيع زيادة في الطول الإجمالي للبيانات،[15] والسبب في هذه الزيادة هو الترويسات المُضافة للقطع أثناء تغليفها،[16] فإذا كانت وحدة بيانات البروتوكول الأصليّة ذات طول ما مثلًا () بايت، ناتج عن حمولة بطول () بايت وترويسة بطول () بايت حيث ()، فإنّ تقطيع قسم الحمولة إلى ثلاث قطع أطوالها () بايت بالترتيب، وإضافة ترويسة الطبقة بطول () بايت لكل قطعة، سيسبب زيادة في الطول الإجمالي للبيانات، لتبيان هذه الزيادة، يُمكن التعبير عن وحدات بيانات البروتوكول الناتجة عن التقطيع بالثلاثيات () و () و () على الترتيب. ويكون مجموع أطوال الحمولة في القطع مُساويًا لطول الحمولة في القطعة الأصلية، أي:
أمّا الطول الإجمالي، أي مجموع أطوال كل الترويسات والحمولات، فهو يزداد بمقدار ترويستين أي () بايت في هذه الحالة،[15] ويُمكن التعبير عن هذه الزيادة بشكلٍ عام بالطريقة التالية:
- حيث () هي عدد القطع الناتجة عن عملية التقطيع.
بالنسبة للبروتوكول الذي يقوم بالتقطيع كإحدى وظائف الطبقة، هناك نمطين للتقطيع، بحسب توافر إمكانية تجميع الرزمة الأصلية، الأول هو التقطيع المرئي أو الملحوظ بالنسبة للبروتوكول (بالإنجليزية: Transparent Fragmentation)، وفيه يدرك البروتوكول عملية حصول التقطيع في أي نقطة في الشبكة، ونتيجة لذلك، يكون بإمكانه إعادة تجميع القطع ثم بناء حمولة الوحدة الأصلية، والثاني هو التقطيع غير المرئي أو غير الملحوظ بالنسبة للبروتوكول (بالإنجليزية: Non-Transparent Fragmentation) وفيه لا يمكن للبروتوكول أن يعيد تجميع القطع إلا في وجهتها النهائية.[17]
عند استخدام بروتوكول التحكم بالنقل كبروتوكول نقل في الشبكة، فإن فقدان قطعة واحدة من مجموعة القطع التي نتجت عن تقطيع رزمة البيانات الأصليّة سيسبب إعادة إرسال كل القطع مرة أخرى، والسبب في ذلك أن المُضيف الوجهة لا يكون قادرًا على تجميع الرزمة ما لم تصل كُل قطعها، وبالتالي لن يقوم بإرسال إشعار لتأكيد الاستلام. نتيجة لذلك، في مصدر الرزمة الأصليّة، سيسبب غياب إشعار الاستلام إعادة إرسال نسخة من الرزمة الأصلية كاملة، وستمر النسخة بنفس المراحل التي مرت فيها الرزمة الأصلية، أي سيتم تقطيعها وإرسال كل القطع عبر الشبكة مرة أخرى، على الرغم من أن ما فقد هو قطعة واحدة فقط وليس كامل الرزمة.[18]
في بعض الحالات، قد يسبب استقبال حركة بيانات مكونة من عدد كبير من القطع من رزم بيانات مختلفة لا يمكن تجميعها امتلاء الذاكرة المخصصة لحفظ القطع، وقد يكون ذلك وسيلة لبدء هجوم ينتمي لعائلة من الهجمات التي تعتمد على حصول التقطيع في الشبكة، وقد تهدف إلى محاولة تجاوز نظام كشف التسلل مثلًا.[19] فالتقطيع في طبقة الشبكة يسبب ثغرة أمنية، لأن ترويسة بروتوكول طبقة النقل التي تحتوي أرقام المنافذ لن تُوجد إلا في القطعة الأولى فقط،[20] ويمكن أن يعتمد المهاجمون على غياب ترويسة بروتوكول النقل في باقي القطع لإطلاق هجوم يُعرف باسم بهجوم القطعة الصغيرة (بالإنجليزية: Tiny Segment Attack) [21] أو قد يكون الهجوم شكلًا من أشكال هجوم حجب الخدمة، من خلال محاولة ملء الذاكرة المخصصة لعملية التجميع أو استهلاك حدة المعالجة المركزية بشكلٍ مُفرط.[22]
يسبب الاعتماد على التقطيع العديد من المشاكل في الشبكة،[23] فمثلًا يجب تجميع كل أجزاء الرزمة الأصلية قبل التمكن من استعادتها، ويسبب هذا إرهاقًا لموارد المُضيف الوجهة، بالإضافة لمشكلة القطعة الأخيرة التي قد تكون ذات حجم صغير، ويسبب إرسالها عبر الشبكة استهلاكًا غير مرغوب لمورد الشبكة.[24] وأخيرًا، في حال تقطيع رزم أو أطر البيانات فإنّ معلومات تخص بروتوكول الطبقات العليا، مثل أرقام المنافذ في طبقة النقل مثلًا لن تتواجد إلا في قطعة واحدة فقط، ما يعني أن جداران الحماية لا تستطيع أن تفحص هذه الرزم، ما يخلق بدوره ثغرة أمنية.[18]
آلية العمل
[عدل]مفهوم الإزاحة
[عدل]![](http://upload.wikimedia.org/wikipedia/commons/thumb/e/e0/Offset_in_Fragmentation_-_ar.png/300px-Offset_in_Fragmentation_-_ar.png)
إزاحة القطعة (بالإنجليزية: Fragment Offset) هي قيمة تنتج أثناء عملية تقطيع حمولة وحدة بيانات بروتوكول، تحدد هذه القيمة الموقع النسبي لقطعة محددة بالنسبة لبقية القطع ضمن الحمولة الأصلية.[25] إنّ قيمة الإزاحة ضرورية لإنجاز عملية إعادة التجميع وبدونها لا يمكن إعادة تجميع القطع بالترتيب الصحيح لإعادة إنتاج وحدة بيانات البروتوكول الأصلية التي تمّ تقطيعها.
تكون إزاحة القطعة الأولى مساوية للصفر دومًا.[26] في حال حصول تقطيع متعدد، فإن قيمة الإزاحة تشير دائمًا إلى موقع القطعة الجديدة بالنسبة إلى الرزمة الأصلية في مرحلة التقطيع الأولى.
إعادة التجميع
[عدل]![](http://upload.wikimedia.org/wikipedia/commons/thumb/5/57/Time-based_overlapped-fragment_reassembly_algorithms_-_ar.png/300px-Time-based_overlapped-fragment_reassembly_algorithms_-_ar.png)
إعادة التجميع (بالإنجليزية: Reassembly) أو (بالإنجليزية: Defragmentation) هي آلية لإعادة إنشاء وحدة بيانات البروتوكول الأصلية انطلاقًا من القطع، وتتطلب عملية إعادة التجميع استقبال جميع القطع أولًا، والتي قد تصل بترتيب مختلف لترتيبها ضمن الوحدة الأصلية، ثُمّ يجب تحديد موقع القطع النسبي ضمن وحدة بيانات البروتوكول الأصلية، وأخيرًا، يتم استخلاص حمولة القطع والتخلص من الترويسات، ثم يجري رصف القطع مع بعضها البعض بالترتيب الصحيح لإعادة إنشاء وحدة بيانات البروتوكول الأصلية.[9]
تحصل عملية إعادة تجميع الأطر محليًّا في الوجهة التالية مباشرة في مسار حركة البيانات، ولا تغادر قطع الإطار الشبكة المحلية، أمّا رزم البيانات فيجري تجميعها في الوجهة النهائية لحركة البيانات، لأن رزم بيانات مختلفة ناتجة عن تقطيع رزمة بيانات واحدة قد تسلك مسارات مختلفة لتصل إلى وجهتها، واختلاف المسارات يعني عدم إمكانية التجميع إلا في الوجهة النهائية،[27] على الرغم من إمكانيّة التقطيع المتعدد في أي نقطة على مسار الرزم.
قد تسمح خوارزمية التقطيع بإنشاء قطع مُتراكبة، أي أن أجزاء من الحمولة من توجد في أكثر من قطعة، ويسبب ذلك تنوعًا في خوارزميات إعادة التجميع، فبعض الخوارزميات تعتمد الأجزاء التي وردت أولًا، وتهمل أجزاء القطع المكررة التي ترد لاحقًا، وهناك خوازميات أخرى تقوم بالعكس، فهي تعتمد الأجزاء الأحدث وصولًا عند إعادة التجميع، وتهمل أجزاء القطع المكررة التي وردت سابقًا، وهناك خوارزميات أخرى تأخد أيضًا إزاحة القطعة بالحسبان.[28]
وصفت خوارزميات إعادة تجميع رزم بيانات الإصدار الرابع من بروتوكول الإنترنت في وثيقة طلب التعليقات RFC 815.[29]
التقطيع المتعدد
[عدل]![](http://upload.wikimedia.org/wikipedia/commons/thumb/8/87/Packet_Fragmentation_Example_-_ar.png/300px-Packet_Fragmentation_Example_-_ar.png)
التقطيع المُتعدد هو تقسيم وحدة بيانات البروتوكول أكثر من مرة أثناء سلوكها المسار بين مصدرها ووجهتها، يحصل التقطيع المُتعدد لرزم بيانات الإصدار الرابع من بروتوكول الإنترنت، وينتج عنه رزم بيانات أصغر في كل مرة. لا يُوجد عدد محدد لمرات التقطيع المُمكنة، وطالما أن الرزمة تحتوي قسم بيانات قابل للتقطيع، فبالإمكان تقطيعها، لكن ذلك يؤثر على أداء الشبكة.
في كل مرة يتم فيها التقطيع يجب تحديد إزاحة القطع الجديدة، أي موقعها، بالنسبة لرزمة البيانات الأصلية في المصدر، وليس بالنسبة لرزمة البيانات التي جرى تقطيعها في هذه المرحلة،[31] ونتيجة لذلك، وبما أن إعادة تجميع الرزم لا تحصل إلا في الوجهة النهائيّة، فإن تلك الوجهة قد تستقبل قطعًا مُختلفة الطول. فإنّ سلكت الرزم مسارًا مُختلفًا بين المصدر والوجهة، فقد يتمّ تقطيعها بشكلٍ مُتعدد بحسب مسارها، وبالتالي فإن عدد القطع الناتجة يتعلق بالمسار المسلوك، أمّا قيمة إزاحة القطع لإعادة بناء الرزمة الأصلية فيجب أن تدل على موقع القطعة في الرزمة الأصلية بغض النظر عن المسار التي سلكته.
لتجنب التقطيع المتعدد، هناك ميزة إضافية للإصدار الرابع من بروتوكول الإنترنت هي ميزة اكتشاف وحدة النقل العظمى للمسار، وهي تعتمد على بروتوكول رسائل التحكم في الإنترنت، وموصوفة في وثيقة طلب التعليقات RFC 1191.[32] أمّا في العُقد التي تُشغّل الإصدار السادس من بروتوكول الإنترنت، فإنّها غالبًا ما تدعم هذه التقنية بشكلٍ افتراضي، وقد أُشير إليها في معيار البروتوكول الأصلي، ووصفت بشكل مفصل في وثيقة طلب التعليقات RFC 8201.[33]
اكتشاف وحدة النقل العظمى للمسار
[عدل]اكتشاف وحدة النقل العظمى للمسار (بالإنجليزية: Path Maximum Transmission Unit Discovery اختصاراً PMTUD) هي آليّة تستخدم في المُضيف المصدر، لتحديد أدنى قيمة لوحدة النقل العظمى على طول مسار ما، وبالتالي توليد رزم بيانات بأطوال متوافقة معها، بحيث لا يعود هناك حاجة لتقطيع الرزم أثناء حركتها على المسار من المصدر إلى الوجهة.[34] قد لا يتمكن المصدر من تحديد حجم النقل الأعظمي الأدنى بدقة، ولكن استعمال هذه الآليّة يساعده على توليد رزم بيانات ذات أطوال أقل أو تساوي أدنى قيمة لحجم النقل الأعظمي على طول المسار.[23]
إذا استُخدم الإصدار الرابع من بروتوكول الإنترنت كبروتوكول شبكة، فإنّ آليّة الاكتشاف الخاصّة به هي توسيعة إضافية تعتمد على بروتوكول رسائل التحكم في الإنترنت،(1) وعلى علم عدم التقطيع في ترويسة البروتوكول.[35] تعتمد الآليّة على قيام المصدر بتوليد رزم بيانات بأطوال متغيرة مع رفع علم عدم التقطيع فيها، فإنّ لم يكن بالإمكان نقل الرزمة عبر شبكة ما بسبب حجمها يجري التخلص منها، ثُمّ إعلام المصدر بذلك عن طريق رسالة مُناسبة من رسائل بروتوكول التحكم في شبكة الإنترنت.[32]
إذا استخدم الإصدار السادس من بروتوكول الإنترنت كبروتوكول شبكة، فإنّ آليّة الاكتشاف الخاصة به هي جزء مُدمج منه، ولابد من استعمالها قبل إرسال أي رزمة حتى لو كان المضيف المصدر يعتقد أن الوجهة موجودة في نفس الشبكة المحلية. تعتمد هذه الآلية على بروتوكول رسائل التحكم للإصدار السادس من بروتوكول الإنترنت،(2) وبالتحديد رسالة «رزمة كبيرة جدًّا» والتي تُرسلها عقدة ما على المسار، وتكون وجهة الرسالة هي مصدر رزمة بيانات لم تتمكن العقدة من إرسالها نحو الخطوة التالية على المسار، وذلك بسبب طولها، يجب على المصدر عندها أن يُعيد ضبط أطوال الرزم التي يُرسلها اعتمادًا على هذه ما جاء في هذه الرسالة.[33]
التقطيع في طبقة النقل
[عدل]إنّ التقطيع ليس وظيفة إلزامية لبروتوكولات طبقة النقل، ولكن يساعد إنجاز عملية تقطيع مناسبة في هذه الطبقة في المضيف المصدر على تجنب أي عمليات تقطيع لاحقة سواءً في الطبقات الدنيا من نموذج الشبكة المستعمل في المضيف المصدر، أو في عقد الشبكات على طول المسار، ويؤثر ذلك بشكل مباشر على الأداء.[36] يدعم بروتوكول التحكم بالنقل آلية لتقطيع حمولة وحدة البيانات، وتسمى الوحدات الجديدة الناتجة عن التقطيع والتغليف قطعًا (بالإنجليزية: Segment)،[37] في حين لا يقوم بروتوكول حزم بيانات المستخدم بعملية التقطيع، وعند استخدامه يجب أن تقوم التطبيقات بتوليد البيانات بشكل متقطع بطريقة يمكن من خلالها لطبقة الشبكة أن تقوم بتوليد رزم البيانات بناء على هذه القطع.[38]
التقطيع في بروتوكول التحكم بالنقل
[عدل]في بروتوكول التحكم بالنقل هناك مفهوم خاص مُرتبط بالتقطيع هو مقاس القطعة الأعظمي (بالإنجليزية: Maximum Segment Size اختصاراً MSS) وهو يحدد الحمولة أو حجم البيانات التي يمكن لمُضيف ما أن يستقبله ضمن قطعة واحدة، يجب الانتباه إلى أن ترويسة بروتوكول التحكم بالنقل غير مُشمولة ضمن مقاس القطعة الأعظمي، على عكس ووحدة النقل العظمى الخاصة بطبقة الشبكة، التي تشمل ترويسة بروتوكول الشبكة بالإضافة للحمولة في وحدة بيانات بروتوكول تلك الطبقة.[39][40]
إنّ اختيار مقاس القطعة الأعظمي الخاص ببروتوكول التحكم بالنقل يُؤثّر بشكل مباشر على عملية تقطيع رزم البيانات في طبقة الشبكة، فإذا كانت القيمة كبيرة جدًّا، كان التقطيع في طبقة الشبكة إلزاميًّا، أمّا إذا كانت صغيرة جدًّا، فلا يحصل تقطيع أبدًا، ولكن الكلفة غير المباشرة لذلك ستكون باهظة ومُؤثّرة على فعاليّة الإرسال، بسبب وجود حمل إضافي كبير هو مجموع أطوال الترويسات المُضافة إلى الرزم الصغيرة.[21] يتم التحكّم بمقاس القطعة الأعظمي في بروتوكول التحكم بالنقل بشكل آليّ لتكون مُتوافقة مع قيمة النافذة المنزلقة الخاصة بالاتصال الذي قام البروتوكول بإنشائه.[41]
إنّ القيمة الافتراضية لمقاس القطعة الأعظمي هي (536) بايت،[42] وهي تضبط بشكل مستقل لكل طرف، ويمكن التفاوض على قيمتها في الاتجاهين بين الطرفين عند إنشاء الاتصال، ولكن لا يمكن تغييرها بعد ذلك.[43]
التقطيع في طبقة الشبكة
[عدل]اسم البروتوكول | اختصار | حجم وحدة النقل العظمى الأعظمي (بايت) | حجم وحدة النقل العظمى الأدنى (بايت) | المرجع |
---|---|---|---|---|
الإصدار الرابع من بروتوكول الإنترنت | IPv4 | 65536 | 68 | [44] |
الإصدار السادس من بروتوكول الإنترنت | IPv6 | 65576 [a] | 1280 | [45] |
- ^ لم يرد ذكر الرقم بشكل صريح في معيار البروتوكول، ولكن يُمكن حسابه من مجموع الطول الأعظمي المسموح للحمولة وهو (65536) بايت، مع طول الترويسة (40) بايت.
جزء من سلسلة مقالات حول |
بروتوكول الإنترنت |
---|
![]() |
إنّ تقطيع رزم البيانات وإعادة تجميعها هو وظيفة رئيسية لبروتوكولات الشبكة.[3][4] يدعم الإصداران الرابع[44] والسادس[45] من بروتوكول الإنترنت تقطيع حمولة رزم البيانات التي يتجاوز طولها قيمة محددة، إلى قطع تُستعمل لإنشاء رزم بيانات ذات أطوال أصغر من الرزمة الأصلية. تمرر الرزم المُقطعة إلى طبقة ربط البيانات ليصار إلى تغليفها وإنشاء أطر البيانات.
التقطيع في الإصدار الرابع من بروتوكول الإنترنت
[عدل]يكون تقطيع رزمة بيانات الإصدار الرابع من بروتوكول الإنترنت (بالإنجليزية: IP Fragmentation) ضروريًّا عندما يتم توليدها في شبكة محلية أُولى تسمح بحجم كبير لوحدة النقل العظمى الخاصة بطقبة الشبكة، لكنّ مسار الرزمة يقطع شبكة ثانية يكون حجم وحدة النقل العظمى فيها أصغر بالقيمة، وعندها لابد من تقطيع الرزمة في عقدة ما على المسار من أجل أن تصل إلى وجهتها. نتيجة لذلك، يتم توليد رزم بيانات بأطوال أصغر من طول الرزمة الأصلية.[46]
يمكن أن تحصل عملية تقطيع الرزم في المُضيف المصدر الذي يُولّدها، أو في أي عقدة على مسارها نحو وجهتها، ويدعم البروتوكول أيضًا مفهوم التقطيع المتعدد، أي يمكن أن يتم تقطيع رزمة البيانات أكثر من مرة عبر مسارها، ولكن لا يمكن إعادة تجميع الرزمة الأصلية إلا في الوجهة النهائية.[27]
ترويسة البروتوكول
[عدل]![](http://upload.wikimedia.org/wikipedia/commons/thumb/f/f8/IPv4_Packet-ar.svg/300px-IPv4_Packet-ar.svg.png)
![](http://upload.wikimedia.org/wikipedia/commons/thumb/b/b3/IPv4_Fragmentation_Flag_field-ar.svg/300px-IPv4_Fragmentation_Flag_field-ar.svg.png)
تتكون ترويسة الإصدار الرابع من بروتوكول الإنترنت من 14 حقلًا،[44] لا ترتبط جميعها بعملية التقطيع. الحقول المُرتبطة بعملية التقطيع هي حقل مُعرّف القطعة، وحقل الأعلام وحقل الإزاحة، كما تتأثر قيمة حقلي الطول الإجمالي والتحقق الجمعي بعملية التقطيع وتختلف قيمتها في القطع عن قيمتها في الرزمة الأصلية،[47] بعض الخيارات تُنسخ لكل قطعة، وبعضها لا يُنسخ إلا للقطعة الأولى، ويتحدد ذلك بعلم خاص هو علم النسخ (بالإنجليزية: Copied flag) الذي يوجد في بداية كل خيار.[48]
يمكن للمضيف المصدر أن يُؤشّر الرزم التي لا يريدها أن تُقطّع برفع علم عدم التقطيع، في هذه الحالة لا يتم تقطيع الرزمة أبدًا، وفي حال تعذّر إيصال الرزمة بدون تقطيعها، فسيتم التخلص منها.[26] إذا تمّ تقطيع رزمة البيانات في المصدر أو في أي عقدة على المسار فلابد من إعادة تجميع القطع الناتجة في المُضيف الوجهة، ولا يتمّ تجميع قطع الرزمة في أي عقدة على المسار. يُستخدم حقل المُعرّف لتمييز رزمة البيانات الأصلية وجميع القطع الناتجة عن عملية التقطيع، ويقوم المُضيف الوجهة باستعمال هذا الحقل للتمييز بين مجموعات القطع الناتجة عن تقطيع رزم بيانات مختلفة بغرض إعادة تجميعها.[49]
لإعادة تشكيل رزمة البيانات الأصلية، يجب أن يعرف المُضيف الوجهة موقع حمولة القطعة بالنسبة للحمولة الأصلية، ولتحقيق ذلك، هناك حقل خاص في ترويسة البروتوكول هو حقل إزاحة القطعة، وهو يدل على الموقع النسبي لحمولة القطعة قي الرزمة الأصلية. وعند تشكيل الرزمة الأصلية في الوجهة يتم ضبط قيمة حقل الإزاحة فيها إلى الصفر، إذا خضعت الحمولة للتقطيع المتعدد على طول المسار، فإن فيمة الإزاحة تدل دومًا على الموقع النسبي في الرزمة الأصلية، وليس في قطعة ما، مهما تعددت مراحل التقطيع.
حقول ترويسة البروتوكول المُستخدمة في عملية التقطيع:[44]
- حقل مُعرّف القطعة، طوله 16 بت ويحتوي على قيمة فريدة تُعرف رزمة البيانات الأصلية وجميع القطع الناتجة عن تقطيعها، وهو يستخدم في عملية إعادة التجميع لتمييز قطع الرزم الأصلية عن قطع بقية الرزمة.[49]
- حقل الأعلام، طوله 3 بت مقسم بالشكل التالي:
- البت 0، محجوز، لا يُستخدم، قيمته دائمًا هي 0.
- البت 1، علم عدم التقطيع (بالإنجليزية: Do not Fragment Flag اختصاراً DF)، يستخدم من قبل مصدر الرزمة للإشارة إلى ضرورة عدم تقطيع الرزمة،[50] تقوم الموجهات على كامل مسار الرزمة بالالتزام بذلك، وإذا كانت قيمة هذا البت مساوية للواحد، فلن يتم تقطيع الرزمة أبدًا حتى لو أدى ذلك إلى التخلص منها لعدم إمكانية توجيهها.[26]
- البت 2، علم المزيد من القطع (بالإنجليزية: More Fragment Flag اختصاراً MF) يستخدم لتمييز القطعة الأخيرة، إذا كانت قيمته 1 فهذا يعني أن هناك قطع أخرى نتجت بعد هذه القطعة من عملية تقطيع الرزمة الأصلية، أما إذا كانت قيمته 0، فهذا يعني أن هذه القطعة هي آخر قطعة نتجت عن عملية تقطيع الرزمة.
- حقل إزاحة القطعة، طوله 13 بت، ويحتوي على قيمة تدل على موقع القطعة النسبي بالنسبة لبقية القطع في الرزمة الأصلية، تكون قيمة الإزاحة مقسومة على ثمانية، أي إذا احتوى الحقل القيمة 1 فإن قيمة الإزاحة الحقيقية هي 8 بايت، وإذا احتوى 2 فإن قيمة الإزاحة الحقيقية هي 16، وأكبر قيمة ممكن للإزاحة في هذا الحقل هي: 213=8192، وتقابل 65536 بايت.[51]
يجب عدم الخلط بين حقلي المُعرّف وإزاحة القطعة في ترويسة بروتوكول الإنترنت، فحقل المُعرّف هو قيمة مميزة تُعرّف بشكلٍ فريد رزمة البيانات الأصلية وكل القطع الناتجة عن عملية التقطيع سواء تم كمرحلة واحدة أو كان متعددًا، أما حقل الإزاحة فهو يمثل الموقع النسبي للقطعة الناتجة بالنسبة لبقية القطع ضكن رزمة البيانات الأصلية.[52]
خوارزمية التقطيع
[عدل]![](http://upload.wikimedia.org/wikipedia/commons/thumb/b/ba/IPv4_Fragmentation_Algorithm-ar.svg/300px-IPv4_Fragmentation_Algorithm-ar.svg.png)
وصفت خوارزمية التقطيع في محددات البروتوكول، وهي تتبع المراحل التالية:[44]
- تحديد طول الرزمة ومقارنته مع وحدة النقل العظمى الخاصّة بالشبكة التي سيتم توجيه الرزمة إليها:
- إذا كان طول الرزمة أكبر من وحدة النقل العظمى، يجب أن يتم تقطيع الرزمة.
- إذا كان طول الرزمة أصغر أو يساوي وحدة النقل العظمى يتم إرسال الرزمة كما هي إلى المرحلة التالية من التغليف.
- إذا كان علم عدم التقطيع في الرزمة مرفوعًا، يتمّ التخلّص من الرزمة.
- يجري تحديد حجم حمولة القطعة بحسب وحدة النقل العظمى وطول ترويسة بروتوكول الإنترنت.
- يتم اقتطاع حمولة القطعة من حمولة الرزمة الأصلية.
- يتم بناء ترويسة القطعة، ويشمل ذلك:
- حساب طول ترويسة القطعة وإضافته إلى الحقل المخصص.
- حساب طول القطعة الإجمالي وإضافته إلى الحقل المخصص.
- تحديد زمن حياة القطعة.
- ضبط قيمة مُعرّف القطعة إلى قيمة مُعرّف الرزمة الأصلية.
- تحديد قيمة الإزاحة، وإضافتها إلى الحقل المخصص.
- تحديد قيمة العلمين. وإضافتهما إلى الحقل المخصص.
- حساب قيمة حقل التحقق الجمعي.
- توليد الرزمة الجديدة من خلال تغليف قطعة البيانات بالترويسة.
- تحديد فيما إذا كانت الرزمة الناتجة هي الرزمة الأخيرة بقراءة قيمة علم المزيد من القطع:
- إذا كانت الرزمة الناتجة هي الرزمة الأخيرة، يتم إرسالها إلى المرحلة التالية من التغليف.
- إذا لم تكن الرزمة الناتجة هي الرزمة الأخيرة، يتم إعادة تنفيذ الخوارزمية بدءًا من الخطوة الثالثة، مع اعتبار أن حجم حمولة الرزمة الأصلية هو الحجم المتبقي من عملية الاقتطاع السابقة.
أما عملية إعادة التجميع، فهي تجري بشكل معاكس، وهناك عدة خوارزميات لإنجازها، جرى مناقشتها في وثيقة طلب التعليقات RFC 815.[53]
قضايا أمنية
[عدل]طوّر المهاجمون عدد من الهجمات التي تعتمد على التقطيع أو ثغرة أمنية قد تنتج عن استخدامه، من هذه الهجمات:
- هجوم القطعة الصغيرة (بالإنجليزية: Tiny Fragment Attack)[54] يعتمد هذا الهجوم على حقيقة أن أصغر رزمة بيانات يمكن لأي وحدة تدعم الإصدار الرابع من بروتوكول الإنترنت التعامل معها هي بطول 68 بايت، حيث تكون ترويسة بروتوكول الإنترنت بأقصى طول أعظمي مسموح لها، وهو 60 بايت، في حين تكون الحمولة بطول 8 بايت فقط،[44] لا يكفي هذا الطول لإدراج ترويسة بروتوكول النقل ضمن الرزمة، وقد يحاول المُهاجم تمرير قطعة خبيثة من جدار الحماية، الذي يتفحص عادة أرقام المنافذ في طبقة النقل، على أساس أنها قطعة صغيرة من رزمة بيانات أكبر جرى تقطيعها.
- هجوم القطع المتراكبة (بالإنجليزية: Overlapping Fragment Attack)[55] يعتمد هذا الهجوم على خوارزمية إعادة التجميع المُتبعة لإعادة تشكيل الرزمة الأصلية، حيث يمكن لأي قطعة تالية أن تتراكب مع قطعة أخرى سابقة، وتحل محلها جزئيًّا أو كليًّا، ويعني ذلك وجود ثغرة أمنية، حيث بالإمكان تمرير القطعة الأولى، التي تحتوي ترويسة بروتوكول الإنترنت من جدار الحماية بشكل شرعي، ثُمّ التلاعب بقيمتها عن طريقة التراكب مع قطعة تالية.[56] على الرغم من التحسينات التي طرأت على خوارزمية إعادة التجميع، إلا أن الوثائق المعيارية للخوارزمية لم تتناول هذا الهجوم.[57]
نُوقشت هذه الهجمات وطريقة التصدي لكل منها بالتفصيل في وثيقة طلب التعليقات RFC 1858.[21]
أمثلة
[عدل]![](http://upload.wikimedia.org/wikipedia/commons/thumb/8/8a/IP_Fragmentation_example_-_ar.png/300px-IP_Fragmentation_example_-_ar.png)
في هذا المثال، يُفترض أن طول ترويسة الإصدار الرابع من بروتوكول الإنترنت هي 20 بايت، أي لا يوجد أي خيارات إضافية. إنّ قيمة وحدة النقل العظمى الخاصة بطبقة الشبكة هو 1500 بايت، ويجري التقطيع على مرحلة واحدة فقط لرزمة بيانات طولها الإجمالي هو 5140 بايت، أي أنها مكونة من حمولة هي 5120 وترويسة هي 20 بايت وقيمة المُعرّف في ترويسة بروتوكول الإنترنت فيها هو 345.[16]
إنّ حجم الحمولة الأكثر مُلائمة لحجم وحدة النقل العظمى هو 1480 بايت، وهو يسمح بتشكيل رزمة بيانات ذات طول مُطابق تمامًا لحجم وحدة النقل العظمى من خلال تغليف الحمولة 1480 بترويسة البروتوكول 20، ليكون طول الرزمة الأولى الإجمالي هو 1500 بايت، وإزاحتها هي 0 لأنّها تحتوي على القطعة الأولى،[26] ويجب أن يضبط علم المزيد من القطع إلى القيمة 1 لأن عملية التقطيع مستمرة، وقيمة المعرف إلى القيمة 345، وهي معرف الرزمة الأصلية نفسه، وعلم عدم التقطيع إلى القيمة 0 لأن المطلوب هو أن يكون التقطيع على مرحلة واحدة فقط. إنّ حجم الحمولة المُتبقية بعد اقتطاع القطعة الأولى هو (3640=1480-5120) بايت.
بشكلٍ مُشابه لإنتاج الرزمة الأولى، يتم اقتطاع 1480 بايت من الحمولة المُتبقية، ويتمّ تغليفها بترويسة البروتوكول المناسبة التي تكون قيم حقولها الخاصة بالتقطيع مُشابهة لحقول ترويسة الرزمة الأولى باستثناء قيمة حقل الإزاحة الذي يتمّ ضبطه إلى القيمة (185=1480/8). وتكون الحمولة المُتبقية بعد إنشاء القطعة اقتطاع الثانية هي (2160=1480-3640). ثُمّ، وبشكلٍ مُشابه يتم اقتطاع القطعة الثالثة، ويجري تغليفها بترويسة البروتوكول المُناسبة التي تكون قيم حقولها الخاصّة بالتقطيع مُشابهة لحقول ترويسة الرزمة الأولى باستثناء قيمة حقل الإزاحة الذي يتم ضبطه إلى القيمة (370=8/(1480+1480)) وتكون الحمولة المتبقية بعد إنشاء القطعة اقتطاع الثالثة هي (680=1480-2160) بايت.
تُشكّل الحمولة المُتبقية القطعة الأخيرة، وتُغلّف بترويسة بروتوكول الإنترنت ليصبح الطول الإجمالي للرزمة الناتجة 700 بايت، ويجب أن يتم ضبط علم المزيد من القطع إلى القيمة 0 لأنّها القطعة الأخيرة، وحقل الإزاحة إلى القيمة (555=8/(1480+1480+1480))، بينما تكون قيم بقية الحقول الخاصة بالتقطيع في الترويسة مُطابقة للقيم في ترويسات الرزم السابقة.
بعض حقول ترويسة الرزمة الأصلية قبل التقطيع | |||||
---|---|---|---|---|---|
- | حقل مُعرف القطعة | حقل الطول الإجمالي (بايت) | علم عدم التقطيع | علم المزيد من القطع | حقل الإزاحة |
- | 345 | 5140 | 0 | 0 | 0 |
بعض حقول ترويسات الرزم الناتجة عن التقطيع | |||||
رقم القطعة | حقل مُعرف القطعة | حقل الطول الإجمالي (بايت) | علم عدم التقطيع | علم المزيد من القطع | حقل الإزاحة |
1 | 345 | 1500 | 1 | 1 | 0 |
2 | 345 | 1500 | 1 | 1 | 185 |
3 | 345 | 1500 | 1 | 1 | 370 |
4 | 345 | 700 | 1 | 0 | 555 |
إنّ مجموع أطوال الرزم الناتجة عن عملية التقطيع هو 5200 بايت، وهو أكبر من طول الرزمة الأصلية بمقدار 60 بايتًا أو 1.15%، وهي حمولة إضافية تنتج عن إضافة الترويسات للقطع الناجمة عن عملية التقطيع.
التقطيع في الإصدار السادس من بروتوكول الإنترنت
[عدل]إن تقطيع رزم البيانات التي يتجاوز طولها قيمة محددة بوحدة النقل العظمى لطبقة الشبكة هي وظيفة أساسيّة للإصدار السادس من بروتوكول الإنترنت.[45] بشكلٍ مشابه للإصدار الرابع من بروتوكول الإنترنت، يقوم الإصدار السادس بتقطيع حمولة رزمة بيانات لإنقاص طولها، وينتج عن ذلك مجموعة من القطع التي تستعمل لتنتج رزم بيانات جديدة، أطوالها أقل أو تساوي قيمة وحدة النقل الأعظيمة. ولكن على عكس الإصدار الرابع من بروتوكول الإنترنت، في الإصدار السادس، لا يحدث التقطيع إلا في المُضيف المصدر فقط، ولا تقوم المُوجّهات بتقطيع رزمة بيانات الإصدار السادس تحت أي ظرف،[58] لذلك فإن معرفة وحدة النقل العظمى للمسار هي عملية ذات أهمية خاصة في البروتوكول، وإذا لم يتمكن البروتوكول من تحديدها فإنّه يعتمد أدنى طول مسموح لرزمة البيانات وهو 1260 بايت.[59]
ترويسة القطعة
[عدل]![](http://upload.wikimedia.org/wikipedia/commons/thumb/7/7c/Fragment_header_structure-ar.svg/300px-Fragment_header_structure-ar.svg.png)
![](http://upload.wikimedia.org/wikipedia/commons/thumb/5/57/IPv6_Fragmentation_algorithm-ar.svg/300px-IPv6_Fragmentation_algorithm-ar.svg.png)
![](http://upload.wikimedia.org/wikipedia/commons/thumb/5/55/IPv6_Fragmentation_Concept-ar.svg/300px-IPv6_Fragmentation_Concept-ar.svg.png)
![](http://upload.wikimedia.org/wikipedia/commons/thumb/3/38/Reassemled_packet-ar.svg/300px-Reassemled_packet-ar.svg.png)
لا تحتوي ترويسة البروتوكول الأساسية على حقول خاصة بعملية التقطيع، ولكن هناك ترويسة أخرى خاصة بالتقطيع تسمى ترويسة القطعة (بالإنجليزية: Fragment Header) يقوم البروتوكول بإضافتها في حال تقطيع الرزمة، إذا أضيفت هذه الترويسة بعد الترويسة الأساسية، يحب أن تكون قيمة حقل «الترويسة التالية» في ترويسة البروتوكول الأصلية مضبوطة إلى القيمة 44.[60]
يبلغ طول ترويسة القطعة 8 بايت، وتتألف من 6 حقول، هي بحسب ترتيب وردوها:[45]
- حقل الترويسة التالية 8 بت، ويضبط بشكل مشابه لحقل الترويسة التالية في ترويسة البروتوكول الأصلية.
- حقل محجوز 8 بت، يضبط إلى القيمة 0 عند الإرسال.
- حقل إزاحة القطعة 13 بت، يحتوي على موقع حمولة القطعة النسبي ضمن حمولة الرزمة الأصلية، وتعبر قيمة الرقم الموجود عن الإزاحة بواحدة هي 8 بايت، فإذا كانت قيمة هذا الحقل مثلًا هي 2، فإن إزاحة القطعة الحقيقية هي 16 بايت.
- حقل محجوز 2 بت، يُضبط إلى القيمة 0 عند الإرسال.
- علم المزيد من القطع 1 بت، ويستخدم للدلالة على القطعة الأخيرة، إذا كانت قيمته 1، فهذا يعني أن هناك قطع لاحقة نتجت عن عملية التقطيع، أما إذا كانت قيمته 0 فذلك يعني بأن هذه القطعة هي القطعة الأخيرة.
- حقل مُعرّف القطعة 32 بت، وهي يحتوي قيمة فريدة تميّز الرزمة الأصلية وجميع القطع التي نتجت عن تقطيعها. هناك عدة خوارزميات لاختيار قيمة المعرّف بحيث يكون فريدًا وآمنًا، وهي موصوفة في وثيقة طلب التعليقات RFC 7739.[61]
خوارزمية التقطيع
[عدل]تتألف رزمة بيانات الإصدار السادس من بروتوكول الإنترنت من ترويسة البروتوكول الأساسية، ومجموعة من التوسيعات التي تشمل خيارات إضافية أو ترويسات مُحددة لابد من معالجتها في كل عقدة على المسار، بالإضافة إلى قسم الحمولة الذي يضمّ ترويسات الطبقات العليا، ويكون التقطيع إلزاميًا عندما يتجاوز طول الرزمة قيمة وحدة النقل العظمى، والتي غالبًا ما تكون وحدة النقل العظمى الدنيا للمسار الذي ستسلكه رزمة البيانات، بخلاف ذلك، تُضبط القيمة بشكلٍ آلي القيمة الدنيا المدعومة لوحدة النقل العظمى في أسوء الحالات وهي 1280 بايت.[62] وُصفت خوارزمية التقطيع في وثيقة طلب التعليقات الخاصة بالبروتوكول.[45]
تتم عملية التقطيع بتقسيم حمولة الرزمة الأصلية إلى عدد من القطع، بحيث لا يزيد طول الرزمة الناتجة عن إضافة ترويسة القطعة وترويسة البروتوكول والتوسيعات إلى أي من القطع عن وحدة النقل العظمى. تكون أطوال القطع الناتجة من مرتبة 8 بايت، أي أن أصغر حمولة قطعة يكون طولها 8 بايت، وثاني أصغر قطعة تكون بطول 16 بايت وهكذا، وتلتزم كل القطع بذلك فيما عدا القطعة الأخيرة.
بشكلٍ عام تنتج عن عملية التقطيع ثلاث حالات مختلفة:[63]
- الرزمة الأولى: وتضم ترويسة البروتوكول والتوسيعات والترويسات الإضافية بالإضافة لترويسة القطعة، والقطعة الأولى من الحمولة، والتي تضم ترويسات الطبقات العليا،[64] ويكون الطول الكليّ مُطابقًا أو قريبًا من طول وحدة النقل العظمى. يكون مُعرّف هذه الرزمة مُطابقًا لمعرف الرزمة الأصلية، ويُرفع فيها علم المزيد من القطع وتكون إزاحتها مساوية للصفر.[26]
- رزم وسطيّة: تظهر الرزم الوسطية إذا كان عدد القطع التانجة أكثر من اثنين، تضم الرزمة الوسطية ترويسة البروتوكول والتوسيعات وترويسة القطعة، وقطعة من الحمولة، ويكون الطول الكلي مُطابقًا أو قريبًا من طول وحدة النقل الأعظميّة. يكون مُعرّف هذه الرزمة مطابقًا لمعرف الرزمة الأصلية، ويُرفع فيها علم المزيد من القطع وتختلف قيمة الإزاحة فيها بحسب الموقع النسبي لقطعة الحمولة في الرزمة الأصلية.
- الرزمة الأخيرة: وتضمّ ترويسة البروتوكول والتوسيعات وترويسة القطعة، وآحر قطعة من الحمولة، ويكون مُعرّف هذه الرزمة مُطابقًا لمعرف الرزمة الأصلية، ولا يُرفع فيها علم المزيد من القطع،[65] وتضبط قيمة الإزاحة فيها بحسب الموقع النسبي لقطعة الحمولة في الرزمة الأصلية. وليس بالضرورة أن يكون طول الرزمة الأخيرة الكلي مُطابقًا أو قريبًا من طول وحدة النقل العظمى، وغالبًا ما تكون ذات حجم صغير غير مناسب.[24]
قضايا أمنية
[عدل]ينتج عن استخدام التقطيع في الإصدار السادس من بروتوكول الإنترنت عدد من الثغرات أمنيّة التي قد تستخدم لشن هجمات مثل هجوم القطعة الصغيرة أو هجوم القطع المتراكبة، وتختلف إمكانية شن الهجمات بحسب نظام التشغيل الذي يستعمل البروتوكول.[66] بشكلٍ مُشابه للإصدار الرابع من بروتوكول الإنترنت، لم تمنع مُحددات الإصدار السادس إنشاء قطع متراكبة عند التقطيع، أي من الممكن أن يتكرار نفس المقطع من الحمولة في أكثر من قطعة، على أن يُعتمد المقطع الوارد في آخر قطعة تمّ استقبالها عند التجميع، يسبب ذلك ثغرة أمنية، ويسمح بتنفيذ هجوم القطع المتراكبة، لاحقًا تمّ التأكيد بوضوح على منع تراكب القطع عند التقطيع في وثيقة طلب التعليقات RFC 5722.[67]
يقبل مُضيف الإصدار السادس من بروتوكول الإنترنت أن تحتوي رزمة البيانات على ترويسة القطعة بدون تكون القطعة ناتجة عن عملية تقطيع، وتسمى هذه القطع بالقطع الذرية (بالإنجليزية: Atomic Fragment) وهي تنتج في حالات خاصة ناقشها المعيار الأصلي للبروتوكول،[45] على الرغم من أن هذه القطع تكون وحداناً، أي لا يجب أن يتم تجميعها مع أي قطع أخرى، فإنّ المُضيف الوجهة يعاملها مُعاملة القطع التي تنتظر التجميع، ما يُسبب ثغرة أمنية، فقد يقوم المهاجم بإرسال قطعة خبيثة مع قيم مُناسبة في ترويسة القطعة، بحيث تكون قطعة ذرية تقبل التجميع مع قطع أخرى خبيثة تُرسل لاحقًا، ناقشت الوثيقة RFC 6946 كيفية معالجة القطع الذرية لتلافي هذا النوع من الهجمات.[68]
التقطيع في طبقة ربط البيانات
[عدل]اسم البروتوكول | اختصار | حجم وحدة النقل العظمى الأدنى (بايت) | حجم وحدة النقل العظمى الأقصى (بايت) | المرجع |
---|---|---|---|---|
الإيثرنت | IEEE 802.3 | 64 | 1518 (5) | [69] |
بروتوكول حلقة الرمز | IEEE 802.5 | لا يوجد حد أدنى | 17794 | [70][71] |
بروتوكول الشبكات المحلية اللاسلكية | IEEE 802.11 | غير مُحدد | 2304 (6) | [72] |
بروتوكول الشبكات الشخصية اللاسلكية منخفضة المعدل | IEEE 802.15.4 | غير مُحدد | 127 | [13] |
في طبقة ربط البيانات، التقطيع هو تقسيم حمولة إطار البيانات إلى قطعتين أو أكثر، لينتج بعد عملية التغليف إطاري بيانات أو أكثر ذوو أطوال أقصر من إطار البيانات الأصلي الذي تمّ تقطيعه. يُحدد كل بروتوكول ربط وحدة نقل أعظمية كعتبة لا يتجاوزها طول أطر البيانات التي يولّدها. التقطيع ليس وظيفة إلزامية لبروتوكولات الربط، وإذا لم يدعم بروتوكول الربط عملية التقطيع، فيجب على بروتوكول الشبكة أن يُولّد رزم بيانات تتناسب مع وحدة النقل لأعظمية لبروتوكول الربط المستعمل.
يُمكن أن يستخدم التقطيع في طبقة الربط في الحالات التي يكون فيها التطبيق حساسًا للتأخير الزمني، حيث يسبب طول إطار بيانات ما تأخيرًا غير مُستحب لأُطر بيانات أخرى، ويكون الحل بتقطيع الإطار الطويل إلى قطع أصغر وإرسالها عبر وسط الاتصال، وبذلك يقل زمن التأخير وتقلقل الإرسال، وتسمى هذه الآلية التقطيع والتوزيع في طبقة الربط (بالإنجليزية: Link Fragmentation and Interleaving اختصاراً LFI).[6][73]
تحدد الشركات المُصنعة لعتاد الشبكة قيم وحدة النقل العظمى الافتراضية والعُظمى الخاصة ببروتوكولات الربط العاملة على منافذ تجهيزاتها، وترتبط عملية التقطيع في طبقة ربط البيانات بهذه القيم بشكلٍ مباشر.[74][75]
التقطيع في بروتوكول الشبكات المحلية اللاسلكية
[عدل]![](http://upload.wikimedia.org/wikipedia/commons/thumb/c/cf/IEEE_802.11_Fragmentation_-_ar.png/300px-IEEE_802.11_Fragmentation_-_ar.png)
يُعرف معيار بروتوكول الشبكات المحلية اللاسلكية (بالإنجليزية: IEEE 802.11) عملية التقطيع بأنها تجزيء وحدات بيانات البروتوكول الخاصة بطبقة التحكم بالوصول للوسط إلى أجزاء أصغر، بهدف زيادة الوثوقية، من خلال زيادة احتمال نجاح عملية نقل الإطار عبر قنوات الاتصال التي تبدي خواصها وثوقية محدودة لاستقبال الأطر ذات الأطوال الكبيرة.(4) تسمى العملية المعاكسة للتقطيع بإعادة التجميع (بالإنجليزية: Defragmentation) ويجب أن تحصل في الوجهة التالية للقطع الناتجة، سواء كانت وجهة نهائية أو وسيطية على المسار.[72]
يتم التحكم بعملية التقطيع بواسطة مُحدد خاص اسمه عتبة التقطيع (بالإنجليزية: dot11FragmentThreshold)، وتسمح تطبيقات البروتوكول لمشرفي الشبكة بضبط هذه القيمة، وأي إطار بيانات يتجاوز طوله قيمة العتبة يجب تقطيعه، ولكن لا يوجد خوارزمية محددة للتقطيع ويترك أمر تحديد الطريقة لمن يقوم بتنفيذ البروتوكول.[76]
وجدت دراسة لاحقة بأن عملية التقطيع تحسّن من أداء بروتوكول الشبكات المحلية اللاسلكية عند في حال التداخل الراديوي، فعند إنقاص قيمة عتبة التقطيع يتناقص معدل خطأ البت المحلي الخاص بالمستقبل الراديوي لنقطة الوصول ويتناقص العدد الكلي لمحاولات إعادة الإرسال وتزداد إنتاجية المستقبل الراديوي. أمّا عند زيادة قيمة عتبة التقطيع فيتناقص التأخير الكلي للوصول إلى الوسط، وأيضًا تقلقل الإرسال الكلي.[77]
التقطيع في شبكات تبديل الأطر
[عدل]![](http://upload.wikimedia.org/wikipedia/commons/thumb/d/d6/LFI_in_frame_relay_-_ar.png/300px-LFI_in_frame_relay_-_ar.png)
إن الهدف الأساسي من التقطيع في شبكة تبديل الأطر هو دعم حركة البيانات الحساسة للتأخير عند حركتها عبر الشبكة، بحيث يتم تقطيع أطر البيانات ذات الأطوال الكبيرة إلى قطع صغيرة بحيث لا يسبب إرسالها تأخيرًا كبيرًا لبقية الأطر. تسمح هذه التقنية للأطر الحساسة وغير للتأخير الزمني بتشارك نفس القناة الافتراضية عبر نفس المنفذ.[78] وُصفت محددات التقطيع بمعيار خاص تحت الاسم الرمزي (FRF.12).[79]
يستخدم التقطيع في شبكة تبديل الأطر كجزء من آلية التقطيع والتوزيع في طبقة الربط (LFI).[6] لا يوجد طول مُحدد مُلزم لوحدة النقل الأعظمي، ولكن من الأفضل أن يكون الطول المُختار متناسبًا مع معدل الساعة للقناة الفيزيائية ومعدل التقل عبر القنوات الافتراضية.[80] تُستخدم خوارزمية التقطيع الخاصّة ببروتوكول الربط بين نقطتين مُتعدد الوصلات.[81]
أنماط التقطيع
[عدل]![](http://upload.wikimedia.org/wikipedia/commons/thumb/d/d5/Frame_Relay_Fragmentation_Types_-_ar.png/300px-Frame_Relay_Fragmentation_Types_-_ar.png)
يُعرّف معيار التقطيع في شبكات تبديل الأطر ثلاث أنماط من التقطيع:[79]
- التقطيع بين المُستخدم والشبكة (بالإنجليزية: UNI Fragmentation): ويحصل بين جهاز اتصال بيانات (DCE) وجهاز بيانات طرفي (DTE) بهدف السماح لأطر البيانات الحساسة وغير الحساسة للتأخير بتشارك نفس المنفذ الذي يصل بين المستخدم والشبكة، والذي غالبًا ما يكون ذو معدل نقل منخفض. في هذا النمط، يتم تجميع الإطار مجددًا قبل دخوله شبكة تبديل الإطار، ويُرسل كاملًا عبرها.
- التقطيع داخل الشبكة (بالإنجليزية: NNI Fragmentation): ويكون هذا التقطيع غير مرئي بالنسبة للطرفيات حيث تحصل عمليتي التقطيع والتجميع داخل شبكة تبديل الأطر، وهو يهدف للسماح لأطر البيانات الحساسة وغير الحساسة للتأخير بتشارك نفس القناة الافتراضية. إن عمليتي التقطيع بين المستخدم والشبكة، والتقطيع داخل الشبكة متطابقتين من حيث الينية والخوارزمية المستعملة، وتُستخدمان في القنوات الافتراضية الدائمة SVC والمبدلة SVC.
- التقطيع بين الطرفيات (بالإنجليزية: End-to-End Fragmentation): ويحصل هذا التقطيع بين الطرفيات، وتحديدًا بين جهازي بيانات طرفيين، ويكون غير مرئي بالنسبة لشبكة تبديل الأطر، ولا يُستخدم إلا في القنوات الافتراضية الدائمة.
ترويسة القطعة
[عدل]![](http://upload.wikimedia.org/wikipedia/commons/thumb/d/d2/Fragment_Encapsulation_in_frame_relay_-_ar.png/300px-Fragment_Encapsulation_in_frame_relay_-_ar.png)
يجري تقطيع حمولة الإطار الأصلي إلى قطعتين أو أكثر، وتضاف ترويسة بروتوكول تبديل الأطر إلى كل القطع، وهي بطول 2 بايت، وأيضًا ترويسة التقطيع، وهي بطول 2 بايت أيضًا، وفي حالة التقطيع بين الطرفيات يضاف مُعرف بروتوكول طبقة الشبكة (بالإنجليزية: Network Layer Protocol ID اختصاراً NLPID) وهو بطول 1 بايت، ويضبط إلى القيمة 16(1B) في حالة التقطيع.[82] أما ترتيب الإضافة عند التغليف فيكون بالشكل التالي:[79]
- في التقطيع بين المستخدم والشبكة، وفي التقطيع داخل الشبكة، تضاف ترويسة البروتوكول أولًا، ثم تضاف ترويسة التقطيع.
- في التقطيع بين الطرفيات، تضاف ترويسة التقطيع أولًا، ثُمّ مُعرف بروتوكول طبقة الشبكة، ثم بايت محجوز يضبط إلى القيمة 16(03)، وأخيرًا ترويسة بروتوكول تبديل الأطر.
يضاف مُلحق بطول 2 بايت لكل القطع، يحتوي على ناتج تطبيق خوارزمية خوارزمية تتابع فحص الإطار [الإنجليزية].[83]
يبلغ طول ترويسة القطعة 2 بايت، وهي تتكون من الحقول التالية بحسب ترتيب ورودها:[79]
- بت قطعة البداية (بالإنجليزية: Beginning fragment bit): وهو علم يشير إلى القطعة الأولى الناتجة عن التقطيع، يتم ضبطه إلى القيمة 1 في القطعة الأولى وإلى 0 في باقي القطع.
- بت قطعة النهاية (بالإنجليزية: Ending fragment bit): وهو علم يشير إلى القطعة الأخيرة، يتم ضبطه إلى القيمة 1 في القطعة الأخيرة وإلى 0 في باقي القطع.
- بت التحكم (بالإنجليزية: Control bit): محجوز لاستخدامات مستقبلية، يُضبط دائمًا إلى القيمة 0.
- الجزء العلوي من حقل التتابع: طوله 4 بت، ويضم الجزء العلوي من حقل التتابع، وتزداد قيمة حقل التتابع بمقدار 1 مع كل قطعة جديدة يتم توليدها، بمعزل عن انتهاء إطار ما والبدء بتقطيع إطار جديد، أي إذا كانت قيمة الحقل N في آخر قطعة نتجت عن تقطيع إطار ما، فإن قيمة التتابع في القطعة الأولى التي ستنتج عن الإطار التالي الذي يتم تقطيع ستكون N+1. تضبط قيمة حقل التتابع بشكل اختياري لكل قناة افتراضية إلى قيمة ما، ثم تزداد بعد ذلك بقيمة واحد مع كل قطعة جديدة يتم تغليفها، يساعد هذا الحقل في إنجاز عملية التجميع من خلال تحديد الرزم القطع التي تنتمي لنفس الإطار الأصلي، وتحديد إزاحتها عن بدايته.
- بت محجوز: قيمته دومًا هي 1.
- الجزء السفلي من حقل التتابع طوله 8 بت، ويضم الجزء السغلي من حقل التتابع.
التقطيع في بروتوكول الربط بين نقطتين متعدد الوصلات
[عدل]![](http://upload.wikimedia.org/wikipedia/commons/thumb/2/27/MLPPP_model%2C_topology_and_encapsulation_-_ar.png/300px-MLPPP_model%2C_topology_and_encapsulation_-_ar.png)
![](http://upload.wikimedia.org/wikipedia/commons/thumb/d/df/MLPPP_encapsualtion_types_-_ar.png/300px-MLPPP_encapsualtion_types_-_ar.png)
يُعرّف مُحدد بروتوكول الربط بين نقطتين (PPP) البرتوكول بأنه بروتوكول ربط يصل بين نقطتين هما طرفا الاتصال، ويمكن أن يقوم بتغليف رزم بيانات لبروتوكولات شبكة مختلفة.[84] لاحقًا أضيفت توسيعة لهذا البروتوكول تسمح بتجميع أكثر من خط نقل فيزيائي يمثل كل منها قناة اتصال مستقلة ضمن خط نقل افتراضي واحد يجمع هذه القنوات، وسميت هذه التوسيعة ببروتوكول النقل متعدد الوصلات بين نقطتين، ووصفت في وثيقة طلب التعليقات (RFC 1990).[81] كما قد يُستخدم التقطيع كجزء من آلية التقطيع والتوزيع في طبقة الربط (LFI).[85]
تُعرّف التوسيعة طبقة فرعية في نموذج الاتصال المعياري، تشغل الجزء العلوي من طبقة ربط البيانات، وتعمل فيها وحدة توسيعة البروتوكول، فترتبط مع وحدة بروتوكول طبقة الشبكة من جهة، ومع وحدتين أو أكثر من وحدات بروتوكول الربط بين نقطتين من جهة أخرى، التي تشغل طبقة فرعية أخرى تُشكل الجزء الأدنى من طبقة ربط البيانات.[86]
من أجل توزيع الحمل بين خطوط التقل التي تشكل الوسط الفيزيائي، تقوم توسيعة البروتوكول بتقطيع رزمة البيانات الواردة من طبقة الشبكة إلى عدد من القطع، ثم تضيف ترويسة خاصة تُسمى ترويسة القطعة لكل قطعة ناتجة، وتمرر القطع وفق سياسة توزيع محددة إلى وحدات بروتوكول الربط بين نقطتين، التي تقوم كل منها بدورها بإضافة ترويسة وملحق خاصين ببروتوكول الربط بين نقطتين، ويجري تغليف القطعة بهما، ثم يُمرر الناتج إلى الطبقة المادية، وتعاد هذه المراحل بترتيب معكوس في المستقبل، من أجل إعادة توليد رزمة البيانات الأصلية.[87]
تضاف ترويسة التوسيعة لكل قطعة ناتجة، ثم تُضاف ترويسة البروتوكول التقليدية والمُلحق بعملية التغليف. يكون طول ترويسة التوسيعة إمّا (2) أو (4) بايت، وفي كلا الحالتين تتألف الترويسة من 4 حقول هي:[81][88]
- بت قطعة البداية (Beginning fragment bit): وهو علم يشير إلى القطعة الأولى، يتم ضبطه إلى القيمة (1) في أول قطعة تنتج عن عملية التقطيع، و (0) في بقية القطع.
- بت قطعة النهاية (Ending fragment bit): وهو علم يشير إلى القطعة الأخيرة، يتم ضبطه إلى القيمة (1) في آخر قطعة تنتج عن عملية التقطيع، و (0) في بقية القطع.
- حقل رقم التتابع (Sequence number): ويدل على ترتيب القطعة بالنسبة لبقية القطع، يضبط في البداية إلى قيمة ابتدائية، ثُم تجري زيادتها بمقدار (1) في كل قطعة جديدة يتم تغليفها، قد يكون الحقل بطول (12) بت، ويُسمّى عندها التتابع القصير (بالإنجليزية: Short Sequence) أو بطول (24) بت، ويُسمّى عندها التتابع الطويل (بالإنجليزية: Long Sequence).[89]
- بتات محجوزة: تُوجد بين العلمين ورقم التتابع، تُضبط إلى القيمة (0)، وعددها (2) إذا استخدم التتابع القصير أو (6) إذا استخدم التتابع الطويل.
التقطيع في الطبقة المادية
[عدل]التقطيع في بروتوكول الإيثرنت
[عدل]![](http://upload.wikimedia.org/wikipedia/commons/thumb/4/45/Fragmentation_for_APL_-_ar.png/300px-Fragmentation_for_APL_-_ar.png)
يدعم بروتوكول الإيثرنت شكلًا خاصًّا من أشكال التقطيع في الطبقة المادية، وهو لا يهدف إلى إنقاص حجم وحدة بيانات البروتوكول، ولكنّ إلى إتاحة استخدام وسط الاتصال المادي الذي ينتج عن استخدام تقنية التجميع في الطبقة المادية (بالإنجليزية: Aggregation at physical layer اختصاراً APL) بصورة مثاليّة، تسمح هذه التقنية بتجميع خطوط نقل ذات معدلات نقل مُعتدلة مثل 1 و2 و4 و10 جيجا بت في الثانية، لبلوغ معدلات نقل عالية مثل 40 أو 100 جيجا بت في الثانية. يحدد البروتوكول طولًا أصغريًّا للقطعة هو 64 بايت، وأعظميًّا هو 512 بايت، ولا يمكن تجاوز هذه العتبات عند اختيار طول القطعة.[69]
يتم تقطيع إطار البيانات كاملًا في طرف الإرسال إلى عدد من القطع، ثُمّ يجري إضافة ترويسة بطول 32 بت وملحق بطول 16 بت لكل قطعة، ويلي ذلك توزيع القطع على خطوط النقل. تُرسل القطع الناتجة عبر خطوط النقل التي تشكل وسط الاتصال في نفس الوقت، ويجري تجميعها في طرف الإستقبال اعتمادًا على الترويسة المُضافة، والتي تحتوي على حقل بطول بت، يسمى رقم التتابع، وهي يساعد المستقبل على إيجاد الترتيب الصحيح للقطع لإعادة تجميعها وإنشاء إطار البيانات الأصلي مجددًا في الطرف الذي استقبلها.[7]
انظر أيضًا
[عدل]- تغليف البيانات.
- حزمة بروتوكولات الإنترنت (TCP/IP).
- وحدة بيانات بروتوكول (PDU).
هوامش
[عدل]1. الرسالة هي رسالة «لا يمكن بلوغ الوجهة» (بالإنجليزية: Destination unreachable Message)، لذلك يضبط حقل النوع في ترويسة البروتوكول إلى القيمة (3) وحقل الترميز إلى القيمة (4)، والتي تعني هناك حاجة للتقطيع ولكن علم عدم التقطيع مرفوع.[90]
2. الرسالة هي رسالة «الرزمة كبيرة جدًّا» (بالإنجليزية: Packet Too big) لذلك يضبط حقل النوع في ترويسة البروتوكول إلى القيمة (2) وحقل الترميز إلى القيمة (0).[91]
3. يجب التمييز بين بروتوكول طبقة الشبكة وبروتوكول التشبيك،[92] والذي يسمى أيضًا البروتوكول المُوجّه، فالأول تصنيف للبروتوكولات بحسب طبقة نموذج الاتصال المعياري، أما الثاني فهو تصنيف للبروتوكولات بحسب الوظيفة، وبروتوكولات الشبكة هي البروتوكولات التي تقوم بوظائف طبقة الشبكة. إن كل بروتوكول شبكة هو بروتوكول طبقة شبكة، مثل الإصدار الرابع لبروتوكول الإنترنت، ولكن العكس غير صحيح، فبروتوكول رسائل التحكم في الإنترنت هو بروتوكول طبقة شبكة، ولكنه ليس بروتوكول شبكة.
4. التعريف كما ورد في المعيار الأصلي هو: (بالإنجليزية: The process of partitioning an MSDU or an MMPDU into smaller MAC level" frames, MPDUs, is called fragmentation. Fragmentation creates MPDUs smaller than the original MSDU or MMPDU length to increase reliability, by increasing the probability of successful transmission of the MSDU or MMPDU when channel characteristics limit reception reliability for longer frames").
5. هناك استثناءات كثيرة لهذا الرقم، أولها عملية الوسم الخاصة بالشبكات المحلية الافتراضية (VLAN) والموصوفة بالمعيار (IEEE 802.1q)، والتي تضيف (4) بايت للترويسة ليصبح الطول الإجمالي (1522) بايت،[93] وثانيها الجسر المٌزوّد الموصوف بالمعيار (IEEE 802.1.ad)[94] الذي يضيف (8) بايت بوسمة خاصة إلى الطول الأصلي فيصبح الطول الإجمالي (1526) بايت، وثالثها أطر الإيثرنت العملاقة (بالإنجليزية: Jumbo frame) التي تُعرّف بأنها أي إطار إيثرنت يزيد طول حمولته عن (1500) بايت،[95] وغيرها.
6. يسبب استخدام تقنيات أمنية مثل الخصوصية المكافئة للشبكات السلكية (WEP) أو أشكال مختلفة من الوصول الآمن للشبكة اللاسلكية (WPA) لتشفير إطار البيانات زيادة في الحجم الأعظمي قد تصل حتى (20) بايت، ليصبح حجم وحدة النقل الأعظمي الأقصى هو (2324) بايت.[96][97]
مراجع
[عدل]- ^ نزار الحافظ (2007)، مسرد مصطلحات المعلوماتية (بالعربية والإنجليزية)، الجمعية العلمية السورية للمعلوماتية، ص. 72، QID:Q108442159
- ^ "Differentiate between transparent and nontransparent fragmentation?". Blogspot (بالإنجليزية). 20 Sep 2013. Archived from the original on 2017-04-25. Retrieved 2018-07-14.
- ^ ا ب "Fragmentation at Network Layer". geeksforgeeks (بالإنجليزية). Archived from the original on 2017-06-26. Retrieved 2018-07-30.
{{استشهاد ويب}}
:|archive-date=
/|archive-url=
timestamp mismatch (help) - ^ ا ب Charles M. Kozierok. (5 Sep 2005). "Network Layer (Layer 3)". The TCP/IP Guide (بالإنجليزية). Archived from the original on 2017-07-30. Retrieved 2018-07-22.
- ^ ا ب "How the TCP/IP Protocols Handle Data Communications". Oracle (بالإنجليزية). 6 Apr 2014. Archived from the original on 2018-07-03. Retrieved 2018-07-23.
- ^ ا ب ج "Configuring Link Fragmentation and Interleaving (LFI) With Campus ATM Switches". Cisco Systems, Inc. (بالإنجليزية). Archived from the original on 2017-05-13. Retrieved 2018-07-20.
- ^ ا ب Howard Frazier (23 Jan 2008). "Aggregation at the Physical Layer" (PDF). IEEE (بالإنجليزية). Archived from the original (PDF) on 2016-09-13. Retrieved 2018-07-24.
- ^ Charles M. Kozierok (5 Sep 2015). "Data Encapsulation, Protocol Data Units (PDUs) and Service Data Units (SDUs)". TCP/IP guide (بالإنجليزية). Archived from the original on 2017-07-30. Retrieved 2018-07-23.
{{استشهاد ويب}}
:|archive-date=
/|archive-url=
timestamp mismatch (help) - ^ ا ب "Segmentation, Fragmentation and Reassembly". InetDaemon Enterprises (بالإنجليزية). 6 Apr 2014. Archived from the original on 2017-01-01. Retrieved 2018-07-23.
{{استشهاد ويب}}
:|archive-date=
/|archive-url=
timestamp mismatch (help) - ^ "MTU Definition". Linux Information Project (بالإنجليزية). 9 أوكتوبر 2005. Archived from the original on 23 فبراير 2018. Retrieved 25 يوليو 2018.
{{استشهاد ويب}}
: تحقق من التاريخ في:|تاريخ=
(help) - ^ "Segmentation vs fragmentation". Cisco systems, Inc. (بالإنجليزية). 24 Mar 2008. Archived from the original on 2018-07-13. Retrieved 2018-07-23.
- ^ uzair syed naveed (25 أوكتوبر 2009). "IP reassembly at destination host". Cisco Systems, Inc. (بالإنجليزية). Archived from the original on 17 مايو 20172020-05-09. Retrieved 28 يونيو 2018.
{{استشهاد ويب}}
: تحقق من التاريخ في:|تاريخ=
and|تاريخ أرشيف=
(help) - ^ ا ب "802.15.4-2015 - IEEE Standard for Low-Rate Wireless Networks". IEEE STANDARD. IEEE. أبريل 2016. DOI:10.1109/IEEESTD.2016.7460875. ISBN:978-1-5044-0845-5.
- ^ M. Frazier، Howard (مارس 2008). "Aggregation at the physical layer". IEEE Communications Magazine. IEEE. ج. 46 ع. 2: 512. DOI:10.1109/MCOM.2008.4476164. مؤرشف من الأصل في 2020-03-13.
- ^ ا ب ج Charles M. Kozierok (20 Sep 2005). "IP Message Fragmentation Process". The TCP/IP Guide (بالإنجليزية). Archived from the original on 2017-07-03. Retrieved 2018-07-13.
- ^ ا ب "Resolve IP Fragmentation, MTU, MSS, and PMTUD Issues with GRE and IPSEC". Cisco Systems, Inc. (بالإنجليزية). Archived from the original on 2018-05-21. Retrieved 2018-06-27.
- ^ Joel Haefner. "Internetworking Concepts". Illinois Wesleyan University (بالإنجليزية). Archived from the original on 2020-03-13. Retrieved 2018-07-15.
- ^ ا ب A. Kent، Christopher؛ C. Mogul، Jeffrey (يناير 1995). "Fragmentation considered harmful" (PDF). ACM SIGCOMM Computer Communication Review - Special twenty-fifth anniversary issue. Highlights from 25 years of the Computer Communication Review. ACM. ج. 17 ع. 5: 75-87. DOI:10.1145/205447.205456. مؤرشف من الأصل في 2020-03-25. اطلع عليه بتاريخ 2018-07-30.
{{استشهاد بدورية محكمة}}
: صيانة الاستشهاد: BOT: original URL status unknown (link) - ^ "IP Fragmentation Buffer". Cisco Systems (بالإنجليزية). Archived from the original on 2018-06-27. Retrieved 2018-06-27.
- ^ "Packet Fragmentation". De Nayer Instituut (بالإنجليزية). Sep 2002. Archived from the original on 2018-07-11. Retrieved 2018-07-11.
- ^ ا ب ج Ziemba, G.; Reed, D.; Traina, P. (أوكتوبر 1995). "RFC 1858, Security Considerations for IP Fragment Filtering". The Internet Society (بالإنجليزية). Archived from the original on 2020-05-09. Retrieved 1 يوليو 2018.
{{استشهاد ويب}}
: تحقق من التاريخ في:|تاريخ=
(help) - ^ "Rose Frag Attack Explained". Digintal.net (بالإنجليزية). Archived from the original on 2017-08-28. Retrieved 2018-06-27.
- ^ ا ب Ivan Pepelnjak (2008). The Never Ending Story of IP Fragmentation (PDF) (بالإنجليزية). NIL Learning. Archived from the original on 2020-03-25. Retrieved 2018-07-30.
{{استشهاد بكتاب}}
: صيانة الاستشهاد: BOT: original URL status unknown (link) - ^ ا ب Marek Majkowski (18 Aug 2017). "Broken packets: IP fragmentation is flawed". Cloudflare (بالإنجليزية). Archived from the original on 2018-06-30. Retrieved 2018-07-22.
- ^ "Glossary of Security Terms, F". SANS™ Institute (بالإنجليزية). Archived from the original on 2018-06-23. Retrieved 2018-06-29.
- ^ ا ب ج د ه Geoff Huston (29 Jan 2016). "Evaluating IPv4 and IPv6 Packet Fragmentation". Réseaux IP Européens Network Coordination Centre RIPE NCC (بالإنجليزية). Archived from the original on 2018-04-25. Retrieved 2018-07-22.
- ^ ا ب Charles M. Kozierok (20 Sep 2005). "IP Message Reassembly Process". The TCP/IP Guide (بالإنجليزية). Archived from the original on 2017-06-15. Retrieved 2018-07-11.
- ^ Mark Baggett (13 Jun 2012). "IP Fragment Reassembly with Scapy". SANS Institute (بالإنجليزية). Archived from the original on 2018-07-22. Retrieved 2018-07-22.
- ^ D. Clark, David (Jul 1982). "RFC 815, IP DATAGRAM REASSEMBLY ALGORITHMS". The Internet Society (بالإنجليزية). Archived from the original on 2016-03-09. Retrieved 2018-07-11.
- ^ Christoph Meinel; Harald Sack (2013). Internetworking: Technological Foundations and Applications (بالإنجليزية). Springer Science & Business Media. p. 469. ISBN:9783642353918.
- ^ Charles M. Kozierok (20 Sep 2005). "IP Message Fragmentation Process". The TCP/IP Guide (بالإنجليزية). Archived from the original on 2017-12-15. Retrieved 2018-07-13.
- ^ ا ب Mogul, J.; Deering, S. (Nov 1990). "RFC 1191, Path MTU Discovery". The Internet Society (بالإنجليزية). Archived from the original on 2019-06-20. Retrieved 2018-07-13.
- ^ ا ب McCann, J.; Deering, S.; Mogul, J.; Hinden, Ed., R. (Jul 2017). "RFC 8201, Path MTU Discovery for IP version 6". The Internet Society (بالإنجليزية). Archived from the original on 2019-03-21. Retrieved 2018-07-13.
- ^ "Resolve IP Fragmentation, MTU, MSS, and PMTUD issues with GRE and IPSEC" (PDF). Cisco Systems, Inc. (بالإنجليزية). Archived from the original (PDF) on 2014-08-02. Retrieved 2018-07-15.
- ^ West, M.; McCann, S. (Mar 2006). "RFC 4413, TCP/IP Field Behavior". The Internet Society (بالإنجليزية). p. 22. Archived from the original on 2012-08-11. Retrieved 2018-07-22.
- ^ Genkov، Delian؛ Ilarionov، Raycho (يناير 2006). "Avoiding IP Fragmentation at the Transport Layer of the OSI Reference Model". International Conference on Computer Systems and Technologies - CompSysTech’06. مؤرشف من الأصل في 2020-03-25.
- ^ Postal, J. (Sep 1981). "RFC 793, Transmission control protocol, DARPA internet program,protocol specification". The Internet Society (بالإنجليزية). Archived from the original on 2019-05-05. Retrieved 2017-07-22.
- ^ James Curtis (17 Jan 2000). "UDP vs TCP". Wand (بالإنجليزية). Archived from the original on 2017-05-06. Retrieved 2018-06-29.
- ^ Postel, J. (Nov 1983). "RFC 879, The TCP Maximum Segment Size and Related Topics". The Internet Society (بالإنجليزية). p. 2. Archived from the original on 2016-03-08. Retrieved 2018-07-28.
- ^ Nurul Islam Roman (15 Dec 2014). "TCP Maximum Segment Size (MSS) and Relationship to IP Datagram Size". APNIC (بالإنجليزية). Archived from the original on 2017-05-17. Retrieved 2018-06-28.
- ^ Charles M. Kozierok (20 Sep 2005). "TCP Maximum Segment Size (MSS) and Relationship to IP Datagram Size". TCP/IP Guide (بالإنجليزية). Archived from the original on 2017-01-11. Retrieved 2018-06-28.
- ^ Postel, J. (Nov 1983). "RFC 879, The TCP Maximum Segment Size and Related Topics". The Internet Society (بالإنجليزية). p. 1. Archived from the original on 2016-03-08. Retrieved 2018-07-28.
- ^ Postal, J. (Sep 1981). "RFC 793, Transmission control protocol, DARPA internet program,protocol specification". The Internet Society (بالإنجليزية). p. 19. Archived from the original on 2019-05-05. Retrieved 2018-06-28.
- ^ ا ب ج د ه و Postel, J. (Sep 1981). "RFC 791, Internet Protocol, DARPA Internet Program Protocol Specification". The Internet Society (بالإنجليزية). Archived from the original on 2019-09-18. Retrieved 2018-07-01.
- ^ ا ب ج د ه و Deering, S.; Hinden, R. (Jul 2017). "RFC 8200, Internet Protocol, Version 6 (IPv6) Specification". The Internet Society (بالإنجليزية). Archived from the original on 2019-06-26. Retrieved 2018-07-13.
- ^ Shivendra Panwar, Shivendra S. Panwar, Shiwen Mao, Jeong-dong Ryoo, Yihan Li (2014). TCP/IP Essentials: A Lab-Based Approach (بالإنجليزية). Cambridge University Press. p. 101. ISBN:0521841445.
{{استشهاد بكتاب}}
: صيانة الاستشهاد: أسماء متعددة: قائمة المؤلفين (link) - ^ Joshua Johnson (17 May 2014). "Describe the IP Packet Header and each field in a Traffic Capture". Cisco Systems, Inc. (بالإنجليزية). Archived from the original on 2017-07-30. Retrieved 2018-07-30.
{{استشهاد ويب}}
:|archive-date=
/|archive-url=
timestamp mismatch (help) - ^ "The IP Datagram". Rhys Haden (بالإنجليزية). Archived from the original on 2017-02-16. Retrieved 2018-07-30.
- ^ ا ب Touch, J. (Feb 2013). "RFC 6864, Updated Specification of the IPv4 ID Field". The Internet Society (بالإنجليزية). p. 22. ISSN:2070-1721. Archived from the original on 2020-05-09. Retrieved 2018-07-22.
- ^ Sean Wilkins (29 Feb 2012). "Anatomy of an IPv4 Packet". Pearson Education, Pearson IT Certification (بالإنجليزية). Archived from the original on 2017-03-27. Retrieved 2018-07-22.
- ^ Toni Janevski (2015). Internet Technologies for Fixed and Mobile Networks (بالإنجليزية) (الأولى ed.). Artech House. p. 33. ISBN:9781608079216.
- ^ "Identification vs Fragment Offset". Cisco Systems, Inc. (بالإنجليزية). 27 Jan 2018. Archived from the original on 2018-07-01. Retrieved 2018-07-01.
- ^ D. Clark, David (Jul 1982). "RFC 815, IP DATAGRAM REASSEMBLY ALGORITHMS". The Internet Society (بالإنجليزية). DOI:10.17487/RFC0815. Archived from the original on 2020-05-07. Retrieved 2019-06-09.
- ^ Miller, I. (Jun 2001). "RFC 3128, Protection Against a Variant of the Tiny Fragment Attack". The Internet Society (بالإنجليزية). p. 22. Archived from the original on 2012-08-11. Retrieved 2018-07-22.
- ^ "Explore new firmware that's helping organizations see attacks as they happen". Datacom (بالإنجليزية). 3 Nov 2015. Archived from the original on 2017-02-11. Retrieved 2018-07-22.
- ^ H. Ptacek، Thomas؛ N. Newsham، Timothy (يناير 1998). "Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection" (PDF). Computer Systems Management and Standards. DEFENSE TECHNICAL INFORMATION CENTER: 46-52. مؤرشف من الأصل (PDF) في 2017-08-12.
- ^ D. Clark, David (Jul 1982). "RFC 815, IP DATAGRAM REASSEMBLY ALGORITHMS". The Internet Society (بالإنجليزية). Archived from the original on 2019-03-28. Retrieved 2018-07-01.
- ^ Matt Conran (16 أوكتوبر 2018). "IPV6 FRAGMENTATION". Technology Focused Hub PS Delivery ltd (بالإنجليزية). Archived from the original on 2 يناير 2018. Retrieved 20 يوليو 2018.
{{استشهاد ويب}}
: تحقق من التاريخ في:|تاريخ=
(help) - ^ Phillip Remaker (21 Mar 2011). "IPv6 MTU Gotchas and other ICMP issues". Cisco Systems, Inc (بالإنجليزية). Archived from the original on 2016-09-19. Retrieved 2018-07-17.
- ^ "Protocol Numbers". IANA (بالإنجليزية). Archived from the original on 2018-01-04. Retrieved 2018-07-18.
- ^ Gont, F. (Feb 2016). "RFC 7739, Security Implications of Predictable Fragment Identification Values". The Internet Society (بالإنجليزية). ISSN:2070-1721. Archived from the original on 2020-05-09. Retrieved 2018-07-17.
- ^ Geoff Huston (19 May 2016). "Fragmenting IPv6". Réseaux IP Européens Network Coordination Centre RIPE NCC (بالإنجليزية). Archived from the original on 2017-05-05. Retrieved 2018-07-18.
- ^ Charles M. Kozierok (20 Sep 2005). "IPv6 Datagram Size, Maximum Transmission Unit (MTU), Fragmentation and Reassembly". The TCP/IP Guide (بالإنجليزية). Archived from the original on 2017-09-10. Retrieved 2018-07-18.
- ^ Bill Cerveny (25 Jul 2011). "IPv6 Fragmentation". ARBOR NETWORKS, INC. (بالإنجليزية). Archived from the original on 2018-06-26. Retrieved 2018-07-18.
- ^ Charles M. Kozierok. (5 Sep 2005). "IPV6 FRAGMENTATION". The TCP/IP Guide (بالإنجليزية). Archived from the original on 2017-07-11. Retrieved 2018-07-20.
{{استشهاد ويب}}
:|archive-date=
/|archive-url=
timestamp mismatch (help) - ^ Atlasis، Antonios (2002). "Attacking IPv6 Implementation Using Fragmentation" (PDF). Black-Hat Europe. مؤرشف من الأصل (PDF) في 2020-03-25.
- ^ Krishnan, S. (Feb 2016). "RFC 5722, Handling of Overlapping IPv6 Fragments". The Internet Society (بالإنجليزية). Archived from the original on 2020-05-09. Retrieved 2018-07-21.
- ^ Gont, F. (May 2013). "RFC 6946, Processing of IPv6 "Atomic" Fragments". The Internet Society (بالإنجليزية). ISSN:2070-1721. Archived from the original on 2020-05-09. Retrieved 2018-07-21.
- ^ ا ب "802.3-2015 - IEEE Standard for Ethernet". IEEE Standard. IEEE: 2690-2699. مارس 2016. DOI:10.1109/IEEESTD.2016.7428776. ISBN:978-1-5044-0078-7. مؤرشف من الأصل في 2019-12-14.
- ^ Brent Baccala (Apr 1997). "IEEE 802.5 Details". Connected: An Internet Encyclopedia (بالإنجليزية). Archived from the original on 2016-06-05. Retrieved 2018-07-29.
- ^ "Token-Ring IEEE 802.5". IBM Corporation (بالإنجليزية). Archived from the original on 2018-07-29. Retrieved 2018-07-29.
- ^ ا ب "802.11-2016 - IEEE Standard for Information technology--Telecommunications and information exchange between systems Local and metropolitan area networks--Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications". IEEE. ديسمبر 2016: 1301. DOI:10.1109/IEEESTD.2016.7786995. ISBN:978-1-5044-3645-8.
{{استشهاد بدورية محكمة}}
: الاستشهاد بدورية محكمة يطلب|دورية محكمة=
(مساعدة) - ^ "Understanding Link Fragmentation and Interleaving Configuration". Juniper Networks, Inc (بالإنجليزية). Archived from the original on 2018-07-20. Retrieved 2018-07-20.
- ^ "Media MTU Sizes by Interface Type". Juniper Networks, Inc. (بالإنجليزية). Archived from the original on 2017-09-20. Retrieved 2018-07-29.
- ^ "MTU Behavior on Cisco IOS XR and Cisco IOS Routers". Cisco Systems, Inc. (بالإنجليزية). Archived from the original on 2017-06-30. Retrieved 2018-07-29.
- ^ Gast, Matthew (2002). 802.11 Wireless Networks: The Definitive Guide (بالإنجليزية) (الأولى ed.). O'Reilly Media. p. 46. ISBN:0596001835.
- ^ Diaconu، Felix (يوليو 2011). "IEEE 802.11 MAC frame fragmentation performances in jammed environments" (PDF). Bul. Inst. Politehnic, Iaşi, s. Electrot., Energ., Electron. ج. 58 ع. 2: 81-88. مؤرشف من الأصل (PDF) في 2015-11-22.
- ^ Jeff T. Buckwalter (1999). Frame Relay: Technology and Practice (بالإنجليزية) (الأولى ed.). Addison-Wesley Professional. p. 215. ISBN:0201485249.
- ^ ا ب ج د Andrew G. Malis (Dec 1997). "Frame Relay Fragmentation Implementation Agreement FRF.12" (PDF). Broadband Forum (بالإنجليزية). Archived from the original (PDF) on 2016-04-26. Retrieved 2018-07-28.
- ^ Andrew G. Malis. "Frame Relay, section: Frame Relay Fragmentation". Rhys Haden (بالإنجليزية). Archived from the original on 2017-06-12. Retrieved 2018-07-28.
- ^ ا ب ج Sklower, K.; Lloyd, B.; McGregor, G.; D. Carr, W.; Coradetti, T. (Aug 1996). "RFC 1990, The PPP Multilink Protocol (MP)". The Internet Society (بالإنجليزية). Archived from the original on 2020-05-09. Retrieved 2018-07-25.
- ^ Brown, C.; Malis, A. (Sep 1998). "RFC 2427, Multiprotocol Interconnect over Frame Relay". The Internet Society (بالإنجليزية). p. 27. Archived from the original on 2020-05-09. Retrieved 2018-07-29.
- ^ "Frame Relay Glossary" (PDF). Cisco systems, Inc (بالإنجليزية). p. 3. Archived from the original (PDF) on 2016-05-12. Retrieved 2018-07-29.
- ^ Simpson, W. (Jul 1994). "RFC 1661, The Point-to-Point Protocol (PPP)". The Internet Society (بالإنجليزية). Archived from the original on 2005-05-08. Retrieved 2018-07-25.
- ^ "Understanding Link Fragmentation and Interleaving Configuration". Juniper Networks, Inc. (بالإنجليزية). 24 Oct 2017. Archived from the original on 2018-07-20. Retrieved 2018-07-29.
- ^ Charles M. Kozierok (20 Sep 2005). "PPP Multilink Protocol (MP/MLP/MLPPP)". The TCP/IP Guide (بالإنجليزية). Archived from the original on 2017-01-23. Retrieved 2018-07-25.
- ^ Charles M. Kozierok (20 Sep 2005). "PPP Multilink Protocol (MP/MLP/MLPPP)". The TCP/IP Guide (بالإنجليزية). Archived from the original on 2017-12-22. Retrieved 2018-07-25.
- ^ "Configuring Link Fragmentation and Interleaving (LFI) With Campus ATM Switches". Cisco Systems, Inc. (بالإنجليزية). Archived from the original on 2017-05-13. Retrieved 2018-07-25.
- ^ Charles M. Kozierok (20 Sep 2005). "PPP Multilink Protocol (MP) Frame Format". The TCP/IP Guide (بالإنجليزية). Archived from the original on 2018-01-21. Retrieved 2018-07-29.
- ^ Postal, J. (Aug 1981). "RFC 792, Internet Control Message protocol, DARPA internet program,protocol specification". The Internet Society (بالإنجليزية). Archived from the original on 2019-04-20. Retrieved 2018-07-14.
- ^ Gupta, M. (Mar 2006). "RFC 4443, Internet Control Message Protocol (ICMPv6),for the Internet Protocol Version 6 (IPv6) Specification". The Internet Society (بالإنجليزية). Archived from the original on 2019-04-02. Retrieved 2018-07-15.
- ^ POSTEL، JONATHAN B. (أبريل 1980). "Internetwork Protocol Approaches". IEEE TRANSACTIONS ON COMMUNICATIONS. IEEE. ج. 28 ع. 4: 604 - 611. DOI:10.1109/TCOM.1980.1094705. ISSN:0090-6778. مؤرشف من الأصل في 2018-08-10.
- ^ "Inter-Switch Link and IEEE 802.1Q Frame Format". Cisco systems, Inc, (بالإنجليزية). Archived from the original on 2017-06-10. Retrieved 2018-07-29.
{{استشهاد ويب}}
: صيانة الاستشهاد: علامات ترقيم زائدة (link) - ^ "802.1Q-2014 - IEEE Standard for Local and metropolitan area networks--Bridges and Bridged Networks". IEEE Standards. IEEE. ديسمبر 2014. DOI:10.1109/IEEESTD.2014.6991462. ISBN:978-0-7381-9433-2.
- ^ "Ethernet Jumbo Frames" (PDF). IEEE Communications Magazine. ethernet alliance. نوفمبر 2009. مؤرشف من الأصل في 2020-03-25. اطلع عليه بتاريخ 2018-07-30.
{{استشهاد بدورية محكمة}}
: صيانة الاستشهاد: BOT: original URL status unknown (link) - ^ Ross، David Andrew (يونيو 2010). "Securing IEEE 802.11 Wireless LANs" (PDF). Queensland University of Technology: 119. مؤرشف من الأصل (PDF) في 2017-08-12.
{{استشهاد بدورية محكمة}}
: الاستشهاد بدورية محكمة يطلب|دورية محكمة=
(مساعدة) - ^ "802.11 Packet Size". Certified Wireless Network Professionals. (بالإنجليزية). 5 أغسطس 2005. Archived from the original on 23 فبراير2017. Retrieved 29 يوليو 2018.
{{استشهاد ويب}}
: تحقق من التاريخ في:|تاريخ أرشيف=
(help)
وصلات خارجية
[عدل]- التقطيع في طبقة الشبكة، مقالة عن التقطيع في الإصدار الرابع من بروتوكول الإنترنت.
- تقييم تقطيع رزم البيانات في الإصدارين الرابع والسادس من بروتوكول الإنترنت مقالة بقلم جيف هوستن.