بروتوكول التحكم بتدفق النقل (بالإنجليزية: Stream Control Transmission Protocol) اختصاراً SCTP، هو بروتوكول اتصالات شبكة كمبيوتر يعمل على طبقة النقل ويخدم دورًا شبيهًا بالبروتوكولات الشائعة TCP و UDP. يتم توحيده بواسطة IETF في RFC 4960.
يوفر SCTP بعض ميزات كل من UDP و TCP: فهو موجه للرسائل مثل UDP ويضمن النقل الموثوق في التسلسل للرسائل مع التحكم في الازدحام مثل TCP. وهو يختلف عن تلك البروتوكولات من خلال توفير مسارات متعددة وفائقة التردد لزيادة المرونة والموثوقية.
في غياب دعم SCTP الأصلي في أنظمة التشغيل، من الممكن نفق SCTP عبر [1] UDP ، بالإضافة إلى تعيين استدعاءات TCP API إلى مكالمات SCTP بحيث يمكن للتطبيقات الموجودة استخدام SCTP بدون تعديل.[2] تم إصدار التطبيق المرجعي كجزء من إصدار FreeBSD 7. ومنذ ذلك الحين تم نقله على نطاق واسع.
قامت مجموعة عمل IETF Signaling Transport (SIGTRAN) بتعريف البروتوكول (رقم 132)[3] في عام [4] 2000 ، وحافظت عليه مجموعة عمل IETF Transport Area (TSVWG). يحدد RFC 4960 البروتوكول. يوفر RFC 3286 مقدمة.
تقدم تطبيقات SCTP بياناتها ليتم نقلها في رسائل (مجموعات من وحدات البايت) إلى طبقة النقل SCTP. يضع SCTP الرسائل ومعلومات التحكم في أجزاء منفصلة (قطع البيانات وقطع التحكم) ، كل تحديد بواسطة رأس القطعة. يمكن أن يقوم البروتوكول بتجزئة رسالة إلى عدد من أجزاء البيانات، ولكن يحتوي كل مقطع بيانات على بيانات من رسالة مستخدم واحدة فقط. يقوم SCTP بتجميع القطع في حزم SCTP. تتكون حزمة SCTP ، التي يتم إرسالها إلى بروتوكول الإنترنت، من رأس حزمة، وقطع تحكم SCTP (عند الضرورة) ، تليها قطع بيانات SCTP (عند توفرها).
يمكن للمرء أن يميز SCTP كموجه للرسالة، بمعنى أنه ينقل سلسلة من الرسائل (كل منها عبارة عن مجموعة من البايتات) ، بدلاً من نقل دفق غير متقطع من البايتات كما يفعل بروتوكول TCP. كما هو الحال في UDP ، في SCTP يرسل المرسل رسالة في عملية واحدة، ويتم تمرير تلك الرسالة بالضبط إلى عملية تلقي التطبيق في عملية واحدة. وعلى النقيض، فإن بروتوكول TCP عبارة عن بروتوكول ذي تيار متدفق، ينقل تدفقات البايتات بشكل موثوق به وبترتيب. على الرغم من أن بروتوكول TCP لا يسمح لجهاز الاستقبال بمعرفة عدد المرات التي يتم فيها استدعاء تطبيق المرسل على TCP الذي يمر عبره، يتم إرسال مجموعات من وحدات البايت. في المرسل، يقوم برنامج التعاون الفني ببساطة بإلحاق المزيد من وحدات البايت بقائمة انتظار من وحدات البايت التي تنتظر الخروج عبر الشبكة، بدلاً من الاضطرار إلى الاحتفاظ بقائمة انتظار من الرسائل الصادرة المنفصلة الفردية التي يجب حفظها بهذه الصفة.
يشير المصطلح متعدد الدفق إلى قدرة SCTP على إرسال عدة تدفقات مستقلة للقطع في نفس الوقت، على سبيل المثال نقل صور صفحة الويب مع نص صفحة الويب. في جوهره، فإنه ينطوي على تجميع عدة اتصالات في جمعية SCTP واحدة، تعمل على الرسائل (أو قطع) بدلا من بايت.
يحفظ TCP ترتيب البايتات في الدفق عن طريق تضمين رقم تسلسل بايت مع كل مقطع. SCTP ، من ناحية أخرى، يعين رقم تسلسل أو معرف الرسالة، لكل رسالة يتم إرسالها في الدفق. وهذا يسمح بطلب مستقل للرسائل في تدفقات مختلفة. ومع ذلك، فإن طلب الرسائل اختياري في SCTP ؛ قد يختار تطبيق الاستلام معالجة الرسائل في ترتيب الاستلام بدلاً من ترتيب الإرسال.
إرسال موثوق به لكل من تدفقات البيانات المرتبة وغير المرتبة.
دعم Multihoming يمكن أن تتكون فيه نقطة واحدة أو كلا طرفي الاتصال من أكثر من عنوان IP واحد، مما يتيح الفشل الشفاف بين مسارات الشبكة الزائدة.
يؤدي تسليم قطع البث داخل تيارات مستقلة إلى إزالة منع رأس الخط غير الضروري، على عكس تسليم تيار TCP.
موثوقية جزئية صريحة.
تحديد المسار والمراقبة لتحديد مسار إرسال البيانات الأساسي واختبار اتصال مسار الإرسال.
آليات التحقق من صحة والتعرف على حماية ضد الهجمات الفيضانات وتقديم إخطار قطع البيانات المتكررة أو المفقودة.
تحسين الكشف عن الخطأ المناسب لإطارات الجامبو إيثرنت.
كان مصممو SCTP في الأصل يهدفون إلى نقل المهاتفة (نظام التشوير 7) عبر بروتوكول الإنترنت، بهدف تكرار بعض خصائص الموثوقية لشبكة تشوير SS7 في بروتوكول الإنترنت. يُعرف جهد IETF هذا بـ SIGTRAN. في هذه الأثناء، تم اقتراح استخدامات أخرى، على سبيل المثال، بروتوكول القطر[5] وتجميع الخادم الموثوق (RSerPool).[6]
وفر برنامج التعاون الفني الوسيلة الأساسية لنقل البيانات بشكل موثوق عبر الإنترنت. ومع ذلك، فرض TCP قيودًا على عدة تطبيقات. من RFC 4960:
يوفر بروتوكول TCP نقل بيانات موثوق به ونقل بيانات صارمة لإرسال البيانات. تحتاج بعض التطبيقات إلى نقل موثوق به بدون صيانة متسلسلة، في حين أن البعض الآخر سيكون راضيًا عن الترتيب الجزئي للبيانات. في كلتا هاتين الحالتين، يؤدي خاصية حظر رأس السطر لـ TCP إلى تأخير غير ضروري.
بالنسبة للتطبيقات التي تتبادل السجلات أو الرسائل المتميزة، تتطلب طبيعة تدفق TCP الموجهة نحو الاتجاه إضافة علامات واضحة أو تشفير آخر لتحديد السجلات الفردية.
لتفادي إرسال العديد من حزم IP الصغيرة حيث سيكون هناك حزمة واحدة أكبر تكفي، قد يؤدي تنفيذ TCP إلى تأخير إرسال البيانات أثناء انتظار احتمال وجود مزيد من البيانات في قائمة الانتظار بواسطة التطبيق (خوارزمية Nagle). إذا كان مثل هذا التأخير الصغير غير مرغوب فيه ومتى، يجب أن يطلب التطبيق صراحة الإرسال غير الملائم على أساس كل حالة على حدة باستخدام أداة الدفع (أي عن طريق وضع علامة PSH في رأس حزمة TCP). ومن ناحية أخرى، يسمح SCTP بأن يتم تكوين الإرسال غير المفسَّر كإعداد افتراضي للترابط، مما يلغي أي تأخير غير مرغوب فيه، ولكن على حساب تكاليف نقل أعلى.[7]
يؤدي النطاق المحدود لمآخذ بروتوكول TCP إلى تعقيد مهمة توفير إمكانية نقل البيانات المتوفرة بشكل كبير باستخدام مضيفين متعددين.
TCP عرضة نسبياً لهجمات رفض الخدمة، مثل هجمات SYN.
وقد تبطئ التبني بسبب قلة الوعي، ونقص التنفيذ (خاصة في Microsoft Windows) ، وعدم وجود دعم للتطبيقات وقلة دعم الشبكة.[8]
تحتاج كل نقطة نهاية SCTP للتحقق من قابلية الوصول للعناوين الأولية والمكررة لنقطة النهاية البعيدة باستخدام ضربات القلب. تحتاج كل نقطة نهاية SCTP إلى ack heartbeats التي تتلقاها من نقطة النهاية البعيدة.
SCTP Multihoming
عندما يرسل SCTP رسالة إلى عنوان بعيد، سيتم تحديد واجهة المصدر فقط بواسطة جدول التوجيه الخاص بالمضيف (وليس بواسطة SCTP).
العنوان المشترك، الذي يشغل أول 12 بايت ومميز باللون الأزرق، و
غير متماثلة متعددة صاروخ موجه: المحلية صاروخ موجه واحد - بعد صاروخ موجه متعددةقطع البيانات، التي تشغل الجزء المتبقي من الحزمة. يتم تمييز القطعة الأولى باللون الأخضر، ويتم تمييز الجزء الأخير من N chunks (Chunk N) باللون الأحمر.
بت
0–7
8–15
16–23
24–31
+0
منفذ المصدر
منفذ الوجهة
32
علامة التحقق
64
اختباري
96
قطعة 1 نوع
القطعة 1 الأعلام
طول القطعة 1
128
القطعة 1 البيانات
…
…
…
نوع القطعة
أعلام القطعة
طول القطعة N
…
بيانات القطعة
وتبدأ كل قطعة بمعرّف نوع بايت واحد، مع 15 نوعاً من الأقسام المحددة بواسطة RFC 4960 ، وعلى الأقل 5 أكثر تحديدًا بواسطة RFC إضافية. ثمانية بت بت العلم، حقل طول اثنين بايت والبيانات يؤلف ما تبقى من القطعة. إذا كانت القطعة لا تشكل مضاعفًا من 4 بايت (أي أن الطول ليس مضاعفًا 4) ، فيكون مبطنًا بالأصفار التي لم يتم تضمينها في طول القطعة. ويحد حقل طول البايتين كل قطعة إلى طول 65535 بايت (بما في ذلك النوع، والأعلام، وحقول الطول).
على الرغم من أن التشفير لم يكن جزءًا من تصميم SCTP الأصلي، فقد تم تصميم SCTP بميزات لتحسين الأمان، مثل مصافحة 4 اتجاهات (مقارنة بمصافحة TCP ثلاثية الاتجاهات) للحماية ضد هجمات SYN الفيضانات، و «ملفات تعريف الارتباط» الكبيرة للتحقق من الارتباط والأصالة.
كانت الموثوقية أيضًا جزءًا أساسيًا من التصميم الأمني لـ SCTP. تمكّن ميزة multihoming اقترانًا للبقاء مفتوحًا حتى في حالة انخفاض بعض المسارات والواجهات. ويكتسي هذا الأمر أهمية خاصة بالنسبة لشركة SIGTRAN لأنها تحمل SS7 عبر شبكة IP تستخدم SCTP ، وتتطلب مرونة قوية أثناء انقطاع الوصلات للحفاظ على خدمة الاتصالات حتى عند تعرضها للشذوذات المستمرة في الشبكة.
SCTP هو في بعض الأحيان مرشح لبصمة جيدة. يتم شحن بعض أنظمة التشغيل مع دعم SCTP ، ولأنها غير معروفة تمامًا مثل TCP أو UDP ، فيتم أحيانًا تجاهلها في تكوينات جدار الحماية والكشف عن التطفل، مما يسمح في كثير من الأحيان بحساب حركة المرور.
^Tuexen, Michael; Randall R. Stewart (May 2013). UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication. IETF. doi:10.17487/RFC6951. RFC 6951. https://tools.ietf.org/html/rfc6951. "نسخة مؤرشفة". مؤرشف من الأصل في 2020-08-03. اطلع عليه بتاريخ 2018-06-11.{{استشهاد ويب}}: صيانة الاستشهاد: BOT: original URL status unknown (link)
^Bickhart, Ryan; Paul D. Amer; Randall R. Stewart (2007)
^Stream Control Transmission Protocol. IETF. October 2000. doi:10.17487/RFC2960. RFC 2960.
^"Transport". Diameter Base Protocol. IETF. sec. 2.1. doi:10.17487/RFC3588. RFC 3588. Retrieved 2012-05-18.
^"Example Scenario Using RSerPool Session Services". An Overview of Reliable Server Pooling Protocols. IETF. p. 10. sec. 4.2. doi:10.17487/RFC5351. RFC 5351.
