เหตุใด SCTP จึงไม่ค่อยถูกใช้ / รู้จัก

ฉันเพิ่งตรวจสอบออกหนังสือ"การเขียนโปรแกรม UNIX เครือข่าย 1 ฉบับ."โดยริชาร์ดสตีเวนส์และผมพบว่ามีความเป็นมาตรฐานชั้นการขนส่งที่สามนอกเหนือจาก TCP และ UDP: SCTP

สรุป: SCTP เป็นโปรโตคอลระดับการขนส่งที่ขับเคลื่อนด้วยข้อความเช่น UDP แต่เชื่อถือได้เช่น TCP นี่คือการแนะนำสั้นจาก IBM DeveloperWorks

สุจริตฉันไม่เคยได้ยิน SCTP มาก่อน ฉันจำไม่ได้ว่าอ่านมันในหนังสือเครือข่ายหรือได้ยินเรื่องนี้ในชั้นเรียนที่ฉันเรียน การอ่านคำถาม stackoverflow อื่น ๆที่กล่าวถึง SCTP แนะนำว่าฉันไม่ได้อยู่คนเดียวกับการขาดความรู้นี้

เหตุใด SCTP จึงไม่เป็นที่รู้จัก ทำไมมันไม่ใช้มาก?

แท้จริงแล้ว SCTP ใช้เป็นส่วนใหญ่ในพื้นที่โทรคมนาคม ตามเนื้อผ้าสวิตช์โทรคมนาคมใช้ SS7 ( ระบบส่งสัญญาณหมายเลข 7 ) เพื่อเชื่อมต่อเอนทิตีต่าง ๆ ในเครือข่ายโทรคมนาคม ตัวอย่างเช่น - ฐานข้อมูลสมาชิกของผู้ให้บริการโทรคมนาคม (HLR) พร้อมสวิตช์ (MSC) สมาชิกเชื่อมต่อด้วย (MSC)

พื้นที่โทรคมนาคมกำลังเคลื่อนที่ด้วยความเร็วที่สูงขึ้นและสภาพแวดล้อมที่เข้าถึงได้มากขึ้น หนึ่งในการเปลี่ยนแปลงเหล่านี้คือการแทนที่โปรโตคอล SS7 โดยใช้โปรโตคอล IP ที่หรูหรารวดเร็วและยืดหยุ่นมากขึ้น

พื้นที่โทรคมนาคมค่อนข้างอนุรักษ์นิยม เครือข่าย SS7 มีการใช้งานที่นี่มานานหลายทศวรรษ มันเป็นเครือข่ายที่เชื่อถือได้และปิด ซึ่งหมายความว่าผู้ใช้ทั่วไปไม่สามารถเข้าถึงได้

ในทางตรงกันข้ามเครือข่าย IP นั้นเปิดอยู่และไม่น่าเชื่อถือและเทเลคอมจะไม่แปลงเป็นมันหากจะไม่จัดการอย่างน้อยโหลดที่ SS7 จัดการ นี่คือสาเหตุที่ SCTP ได้รับการพัฒนา มันพยายาม:

• เพื่อเลียนแบบข้อดีทั้งหมดของเครือข่าย SS7 ที่สะสมมานานหลายทศวรรษ
• เพื่อสร้างโปรโตคอลการเชื่อมต่อที่ดีกว่า TCP ในเรื่องความเร็วความปลอดภัยและความซ้ำซ้อน

Linux รุ่นล่าสุดมีการรองรับ SCTP แล้ว

เราได้ปรับใช้ SCTP ในแอปพลิเคชั่นหลายตัวในขณะนี้และพบปัญหาที่สำคัญกับการสนับสนุน SCTP ในเราเตอร์โฮมต่างๆ พวกเขาจัดการ SCTP ไม่ถูกต้อง ฉันเชื่อว่านี่เป็นปัญหาด้านประสิทธิภาพเป็นหลัก (ข้อกำหนดของโปรโตคอล SCTP ต้องการการตรวจสอบสำหรับแพ็กเก็ตทั้งหมดเพื่อคำนวณใหม่และไม่ใช่เฉพาะส่วนหัว)

เช่นเดียวกับโปรโตคอลอื่น ๆ ที่มีแนวโน้มว่า SCTP จะตายอย่างน่าเศร้าในน้ำจนกระทั่ง D-link และ Netgear แก้ไขกล่อง NAT ที่เสีย

SCTP ต้องการการออกแบบเพิ่มเติมภายในแอปพลิเคชันเพื่อให้ได้ประโยชน์สูงสุดจากมัน มีตัวเลือกมากกว่า TCP, API คล้าย Sockets มาในภายหลังและยังอายุน้อย อย่างไรก็ตามฉันคิดว่าคนส่วนใหญ่ที่ใช้เวลาในการทำความเข้าใจ (และผู้ที่รู้ข้อบกพร่องของ TCP) ชื่นชมมัน - มันเป็นโปรโตคอลที่ออกแบบมาอย่างดีที่สร้างบนความรู้ ~ 30 ปีของเราเกี่ยวกับ TCP และ UDP

ด้านหนึ่งที่ต้องใช้ความคิดบางอย่างคือของกระแส สตรีมให้ (โดยปกติฉันคิดว่าคุณสามารถปิดได้) รับประกันการสั่งซื้อภายในพวกเขา (เหมือนกับการเชื่อมต่อ TCP) แต่สามารถมีสตรีมได้หลายรายการต่อการเชื่อมต่อ SCTP หากข้อมูลของแอปพลิเคชันของคุณสามารถส่งผ่านสตรีมได้หลายสายคุณจะหลีกเลี่ยงการบล็อกส่วนหัวที่ตัวรับสัญญาณค้างเนื่องจากแพ็คเก็ตผิดพลาดหนึ่งชุด การสนทนาที่แตกต่างกันอย่างมีประสิทธิภาพสามารถเกิดขึ้นได้ผ่านการเชื่อมต่อเดียวกันโดยไม่กระทบต่อกันและกัน

การเพิ่มที่มีประโยชน์อีกอย่างหนึ่งคือการรองรับมัลติโฮม - การเชื่อมต่อเดียวสามารถข้ามหลายอินเตอร์เฟสที่ปลายทั้งสองและจะเกิดความล้มเหลว คุณสามารถจำลองสิ่งนี้ใน TCP แต่ที่ชั้นโปรแกรม

การเชื่อมโยง heartbeating ที่เหมาะสมซึ่งเป็นสิ่งแรกที่แอปพลิเคชันใด ๆ ที่ใช้ TCP สำหรับการเชื่อมต่อที่ไม่ใช้ชั่วคราวจะมีให้ฟรี

สรุปส่วนตัวของฉันเกี่ยวกับ SCTP คือมันไม่ได้ทำอะไรที่คุณไม่สามารถทำได้อีกทางหนึ่ง (ใน TCP หรือ UDP) ด้วยการสนับสนุนแอปพลิเคชั่นมากมาย สิ่งที่ให้คือความสามารถในการไม่ต้องใช้โค้ดนั้น (แย่) ตัวคุณเอง

FYI, SCTP ได้รับคำสั่งให้รองรับกับเส้นผ่านศูนย์กลาง (cf RADIUS รุ่นถัดไป) ดู RFC 3588

   เส้นผ่านศูนย์กลางไคลเอนต์ต้องรองรับทั้ง TCP หรือ SCTP ในขณะที่ตัวแทนและ
   เซิร์ฟเวอร์ต้องรองรับทั้งสองอย่าง ข้อกำหนดในอนาคตของ MAY
   อาณัติที่ลูกค้าสนับสนุน SCTP

SCTP ไม่ค่อยเป็นที่รู้จักมากนักและไม่ได้ใช้ / ปรับใช้มากนักเนื่องจาก:

• อย่างกว้างขวาง: ไม่รวมอยู่ใน TCP / IP สแต็ค (ในปี 2013: ยังขาดอยู่ใน Mac OSX และ Windows ล่าสุด)
• ไลบรารี่ : มีการเชื่อมโยงระดับสูงในภาษาที่ใช้งานง่าย (ข้อจำกัดความรับผิดชอบ: ฉันเป็นผู้ดูแลpysctp , สนับสนุนสแต็ก SCTP ง่ายสำหรับ Python)
• NAT: ไม่ข้าม NAT ดี / เลย (น้อยกว่า 1% อินเทอร์เน็ตที่บ้านและเราเตอร์ขององค์กรทำ NAT บน SCTP)
• ความนิยม: ไม่มีแอปสาธารณะทั่วไปใช้
• กระบวนทัศน์การเขียนโปรแกรม: มันเปลี่ยนไปเล็กน้อย: มันยังคงเป็นซ็อกเก็ต แต่คุณสามารถเชื่อมต่อโฮสต์จำนวนมากกับโฮสต์จำนวนมาก (multihoming), ดาต้าแกรมได้รับคำสั่งและเชื่อถือได้ erc ...
• ความซับซ้อน: สแต็ก SCTP มีความซับซ้อนในการนำไปใช้ (เนื่องจากด้านบน)
• การแข่งขัน: Multipath TCP กำลังจะมาและควรจะตอบสนองความต้องการ / ความสามารถหลายคนเพื่อให้ผู้คนละเว้นจากการใช้ SCTP ถ้าเป็นไปได้รอ MTCP
• ช่อง: ความต้องการการเติม SCTP นั้นแปลกมาก (สั่งดาตาแกรมที่เชื่อถือได้, หลายสตรีม) และไม่ต้องการโดยแอปพลิเคชันจำนวนมาก
• ความปลอดภัย: SCTP เลี่ยงการควบคุมความปลอดภัย (ไฟร์วอลล์บางตัว, IDSes ส่วนใหญ่, DLP ทั้งหมดไม่ปรากฏบน netstat ยกเว้น CentOS / Redhat / Fedora ... )
• ความสามารถในการตรวจสอบ: มี บริษัท 3 แห่งในโลกทำการตรวจสอบความปลอดภัยของ SCTP เป็นประจำ (ข้อจำกัดความรับผิดชอบ: ฉันทำงานใน บริษัท ใด บริษัท หนึ่ง)
• โค้งการเรียนรู้: มี toolchain ไม่มากที่จะเล่นกับ SCTP (ตรวจสอบกับwithctct ที่ยอดเยี่ยมที่รวมอย่างดีกับ netcat หรือใช้ socat)
• ภายใต้ประทุน: ส่วนใหญ่ใช้ในโทรคมนาคมและทุกครั้งที่คุณส่ง SMS เริ่มท่องเน็ตบนมือถือของคุณหรือโทรคุณมักจะเรียกข้อความที่ไหลผ่าน SCTP (SIGTRAN / SS7 กับ GSM / UMTS, เส้นผ่าศูนย์กลางด้วย LTE / IMS / RCS, S1AP / X2AP กับ LTE) ดังนั้นคุณจะใช้มันบ่อยมาก แต่คุณไม่เคยรู้เลย ;-)

p1 SCTP ที่แมปโดยตรงผ่าน IPv4 ต้องการการสนับสนุนใน NAT เกตเวย์ซึ่งไม่เคยถูกนำไปใช้อย่างแพร่หลายในทุกที่และถ้าไม่มีเกตเวย์ NAT ทั่วไปจะอนุญาตให้โฮสต์ส่วนตัวหนึ่งรายต่อหนึ่งที่อยู่สาธารณะเท่านั้นที่จะใช้ SCTP ในเวลาเดียวกัน

P2 SCTP ที่แมปผ่าน UDP / IPv4 ช่วยให้โฮสต์ส่วนตัวมากขึ้นต่อที่อยู่สาธารณะ แต่การแมป UDP ในเกตเวย์ IPv4 / NAT นั้นเป็นการยากที่จะสร้างและดูแลรักษาเนื่องจากการที่ UDP นั้นเป็นการขนส่งแบบไร้การเชื่อมต่อโดยไม่มีสถานะชัดเจนใด ๆ .

p3 SCTP ถูกแมปโดยตรงผ่าน IPv6 ต้องการ ... ดี ... IPv6 คุณพยายามปรับใช้ IPv6 แล้วหรือยัง ถ้าเป็นเช่นนั้นคุณลองซื้อไฟร์วอลล์ IPv6 แล้วหรือยัง รองรับ SCTP หรือไม่ ตัวโหลดบาลานซ์ล่ะ? เร่งความเร็ว SSL?

P4 ในที่สุดอินเทอร์เน็ตจำนวนมากค่อนข้าง จำกัด กับสิ่งที่สามารถผ่าน TCP พอร์ต 80 และพอร์ต 443 ดังนั้น SCTP ของรสชาติใด ๆ จึงมีแนวโน้มที่จะสูญเสียไป ดังนั้นคุณจะเห็นความพยายามเช่นคณะทำงานMPTCPใน IETF

พวกเราหลายคนจะใช้ SCTP เร็ว ๆ นี้เนื่องจากมันถูกใช้โดย WebRTC datachannels เพื่อสร้างเลเยอร์ที่น่าเชื่อถือเหมือน TCP บน UDP - SCTP ผ่าน DTLS ผ่าน UDP: https://tools.ietf.org/html/draft-ietf -rtcweb ข้อมูลช่องทาง-13 # ส่วน-6

การอ่านหน้าวิกิพีเดีย SCTPฉันจะบอกว่าสาเหตุหลักคือ SCTP นั้นเป็นโพรโทคอลที่อายุน้อยมาก (เสนอในปี 2000) ซึ่งปัจจุบันยังไม่รองรับระบบปฏิบัติการหลัก ( Windows , OS X , Linux )

ถ้า "เด็กมาก" ดูไม่เหมาะสมกับคุณลองนึกถึงIPV6 : "ในเดือนธันวาคม 2551 แม้ว่าจะครบรอบ 10 ปีในฐานะโปรโตคอลติดตามมาตรฐาน แต่ IPv6 ก็ยังอยู่ในช่วงเริ่มต้นเท่านั้นในแง่ของการใช้งานทั่วโลกทั่วไป"

SCTP ถูกใช้อย่างกว้างขวางในเครือข่าย 4G LTE ที่ใช้เส้นผ่านศูนย์กลางสำหรับ AAA

มันอาจจะไม่เป็นที่รู้จัก แต่ก็ไม่ได้ใช้ ค่อนข้างเร็ว ๆ นี้มีการร่างการตีพิมพ์ในIETFเกี่ยวกับการใช้ SCTP เป็น Transport Layer Protocol สำหรับ HTTP

ในการอ้างอิงถึงความคิดเห็นทั้งหมดเกี่ยวกับเราเตอร์เชิงพาณิชย์ที่ถูกทำลายหรือขาดการสนับสนุน SCTP ปัญหาคือ SCTP ที่มี NAT ยังอยู่ในรูปแบบร่างด้วย IETF ดังนั้นจึงไม่มีข้อกำหนด RFC สำหรับพวกเขาที่จะใช้มัน

https://tools.ietf.org/html/draft-ietf-behave-sctpnat-09

Sctp เกิดมาช้าเกินไปและสำหรับหลาย ๆ สถานการณ์ TCP ก็เพียงพอแล้ว

และอย่างที่ทราบกันดีว่าการใช้งานส่วนใหญ่อยู่ในพื้นที่โทรคมนาคม