Tại sao SCTP không được sử dụng / biết nhiều

Gần đây tôi đã xem cuốn sách "Lập trình mạng UNIX, Tập 1" của Richards Stevens và tôi thấy rằng có một tiêu chuẩn lớp vận chuyển thứ ba bên cạnh TCP và UDP: SCTP .

Tóm tắt: SCTP là một giao thức cấp vận chuyển được điều khiển bằng thông điệp như UDP, nhưng đáng tin cậy như TCP. Đây là một giới thiệu ngắn từ IBM DeveloperWorks .

Thành thật mà nói, tôi chưa bao giờ nghe nói về SCTP trước đây. Tôi không thể nhớ đã đọc về nó trong bất kỳ cuốn sách mạng nào hoặc nghe về nó trong các lớp tôi đã tham gia. Đọc các câu hỏi stackoverflow khác có đề cập đến SCTP cho thấy rằng tôi không đơn độc với sự thiếu hiểu biết này.

Tại sao SCTP không được biết đến? Tại sao nó không được sử dụng nhiều?

Thật vậy, SCTP được sử dụng chủ yếu trong lĩnh vực viễn thông. Theo truyền thống, các thiết bị chuyển mạch viễn thông sử dụng SS7 ( Hệ thống tín hiệu số 7 ) để kết nối các thực thể khác nhau trong mạng viễn thông. Ví dụ: cơ sở dữ liệu thuê bao của nhà cung cấp dịch vụ viễn thông (HLR), với một công tắc (MSC), thuê bao cũng được kết nối (MSC).

Khu vực viễn thông đang chuyển sang tốc độ cao hơn và môi trường dễ tiếp cận hơn. Một trong những thay đổi này là thay thế giao thức SS7 bằng một số giao thức dựa trên IP thanh lịch, nhanh chóng và linh hoạt hơn.

Khu vực viễn thông rất bảo thủ. Mạng SS7 đã được sử dụng ở đây trong nhiều thập kỷ. Nó là một mạng lưới đáng tin cậy và khép kín. Điều này có nghĩa là một người dùng thông thường không có quyền truy cập vào nó.

Ngược lại, mạng IP mở và không đáng tin cậy, và viễn thông sẽ không chuyển đổi sang mạng nếu nó không xử lý ít nhất là tải mà SS7 xử lý. Đây là lý do tại sao SCTP được phát triển. Nó cố gắng:

• để bắt chước tất cả các lợi thế của mạng SS7 được tích lũy qua nhiều thập kỷ.
• để tạo giao thức hướng kết nối tốt hơn TCP về tốc độ, bảo mật và dự phòng

Các bản phát hành mới nhất của Linux đã có hỗ trợ SCTP.

Chúng tôi đã triển khai SCTP trong một số ứng dụng và gặp phải sự cố đáng kể với hỗ trợ SCTP trong các bộ định tuyến gia đình khác nhau. Họ chỉ đơn giản là không xử lý SCTP chính xác. Tôi tin rằng đây chủ yếu là một vấn đề về hiệu năng (đặc tả giao thức SCTP yêu cầu tổng kiểm tra cho toàn bộ các gói được tính toán lại và không chỉ cho các tiêu đề).

Giống như nhiều giao thức đầy hứa hẹn khác, SCTP buồn bã chết trong nước cho đến khi D-link và Netgear sửa các hộp NAT bị hỏng của họ.

SCTP yêu cầu thiết kế nhiều hơn trong ứng dụng để sử dụng nó tốt nhất. Có nhiều tùy chọn hơn TCP, API giống như Sockets xuất hiện sau và nó còn non trẻ. Tuy nhiên, tôi nghĩ rằng hầu hết mọi người dành thời gian để hiểu về nó (và những người biết những thiếu sót của TCP) đều đánh giá cao nó - đó là một giao thức được thiết kế tốt, xây dựng trên ~ 30 năm kiến ​​thức về TCP và UDP của chúng tôi.

Một trong những khía cạnh đòi hỏi một số suy nghĩ là luồng. Các luồng cung cấp (thông thường, tôi nghĩ rằng bạn có thể tắt nó) một đảm bảo đơn hàng trong chúng (giống như kết nối TCP) nhưng có thể có nhiều luồng trên mỗi kết nối SCTP. Nếu dữ liệu của ứng dụng của bạn có thể được gửi qua nhiều luồng thì bạn sẽ tránh bị chặn đầu dòng nơi người nhận chết đói do một gói bị sai. Hiệu quả các cuộc hội thoại khác nhau có thể có trên cùng một kết nối mà không ảnh hưởng lẫn nhau.

Một bổ sung hữu ích khác là hỗ trợ đa hướng - một kết nối có thể đi qua nhiều giao diện ở cả hai đầu và nó đối phó với các lỗi. Bạn có thể mô phỏng điều này trong TCP, nhưng ở lớp ứng dụng.

Nhịp tim liên kết chính xác, là điều đầu tiên mà bất kỳ ứng dụng nào sử dụng TCP cho các kết nối không nhất thời đều được cung cấp miễn phí.

Tóm tắt cá nhân của tôi về SCTP là nó không làm bất cứ điều gì bạn không thể làm theo cách khác (trong TCP hoặc UDP) với sự hỗ trợ ứng dụng đáng kể. Điều nó cung cấp là khả năng không phải tự thực hiện mã đó (rất tệ).

FYI, SCTP được ủy quyền là được hỗ trợ cho Đường kính (cf RADIUS thế hệ tiếp theo). xem RFC 3588

   Khách hàng đường kính PHẢI hỗ trợ TCP hoặc SCTP, trong khi các tác nhân và
   máy chủ PHẢI hỗ trợ cả hai. Các phiên bản tương lai của thông số kỹ thuật này CÓ THỂ
   yêu cầu khách hàng hỗ trợ SCTP.

SCTP không được biết đến nhiều và không được sử dụng / triển khai nhiều vì:

• Phổ biến rộng rãi: Không được tích hợp rộng rãi trong các ngăn xếp TCP / IP (năm 2013: vẫn còn thiếu nguyên bản trong Mac OSX và Windows mới nhất)
• Thư viện: Rất ít ràng buộc cấp cao trong các ngôn ngữ dễ sử dụng (Tuyên bố miễn trừ trách nhiệm: tôi là người duy trì pysctp , hỗ trợ ngăn xếp dễ dàng SCTP cho Python)
• NAT: Không vượt qua NAT rất tốt / hoàn toàn (ít hơn 1% bộ định tuyến gia đình & doanh nghiệp internet làm NAT trên SCTP).
• Mức độ phổ biến: Không có ứng dụng chung nào sử dụng nó
• Mô hình lập trình: nó đã thay đổi một chút: nó vẫn là một ổ cắm, nhưng bạn có thể kết nối nhiều máy chủ với nhiều máy chủ (multihoming), datagram được đặt hàng và đáng tin cậy, ...
• Độ phức tạp: Ngăn xếp SCTP rất phức tạp để thực hiện (do ở trên)
• Cạnh tranh: TCP đa năng đang đến và sẽ giải quyết các nhu cầu / khả năng đa dạng để mọi người không thực hiện SCTP nếu có thể, chờ MTCP
• Thích hợp: Nhu cầu SCTP điền rất đặc biệt (được đặt hàng các datagram đáng tin cậy, đa tầng) và không cần nhiều ứng dụng
• Bảo mật: SCTP trốn tránh các kiểm soát bảo mật (một số tường lửa, hầu hết IDS, tất cả DLP, không xuất hiện trên netstat ngoại trừ CentOS / Redhat / Fedora ...)
• Khả năng kiểm toán: Một cái gì đó giống như 3 công ty trên thế giới thường xuyên thực hiện kiểm toán bảo mật SCTP (Tuyên bố miễn trừ trách nhiệm: Tôi làm việc tại một trong số họ)
• Đường cong học tập: Không có nhiều công cụ để chơi với SCTP (kiểm tra bản rút gọn tuyệt vời kết hợp độc đáo với netcat hoặc sử dụng socat)
• Dưới vỏ bọc: Được sử dụng chủ yếu trong viễn thông và mỗi khi bạn gửi SMS, bắt đầu lướt mạng trên điện thoại di động hoặc gọi điện thoại, bạn thường kích hoạt các tin nhắn truyền qua SCTP (SIGTRAN / SS7 với GSM / UMTS, Đường kính với LTE / IMS / RCS, S1AP / X2AP với LTE), vì vậy bạn thực sự sử dụng nó rất nhiều nhưng bạn không bao giờ biết về nó ;-)

p1. SCTP được ánh xạ trực tiếp qua IPv4 yêu cầu hỗ trợ trong các cổng NAT, chưa bao giờ được triển khai rộng rãi ở bất cứ đâu và nếu không có cổng NAT thông thường sẽ chỉ cho phép một máy chủ riêng trên mỗi địa chỉ công cộng sử dụng SCTP tại một thời điểm.

p2. SCTP được ánh xạ qua UDP / IPv4 cho phép nhiều máy chủ riêng tư hơn trên mỗi địa chỉ công cộng, nhưng ánh xạ UDP trong các cổng IPv4 / NAT nổi tiếng là khó khăn để thiết lập và duy trì, do thực tế rằng UDP là vận chuyển không kết nối mà không có bất kỳ trạng thái rõ ràng nào để NAT theo dõi .

p3. SCTP được ánh xạ trực tiếp qua IPv6 yêu cầu ... à ... IPv6. Bạn đã thử triển khai IPv6 chưa? Nếu vậy, bạn đã thử mua một tường lửa IPv6 chưa? Nó có hỗ trợ SCTP không? Làm thế nào về một cân bằng tải? Máy gia tốc SSL?

p4. Cuối cùng, rất nhiều Internet bị hạn chế khá nhiều so với những gì có thể phù hợp thông qua cổng TCP 80 và cổng 443, vì vậy SCTP của bất kỳ hương vị nào có xu hướng mất ở đó. Do đó, bạn thấy những nỗ lực như nhóm làm việc MPTCP trong IETF.

Nhiều người trong chúng ta sẽ sớm sử dụng SCTP, vì nó được sử dụng bởi các bảng dữ liệu WebRTC để tạo một lớp đáng tin cậy giống như TCP trên UDP - SCTP trên DTLS qua UDP: https://tools.ietf.org/html/draft-ietf -rtcweb-data-channel-13 # phần-6

Đọc trang Wikipedia SCTP tôi muốn nói rằng lý do chính là SCTP là một giao thức rất trẻ (được đề xuất vào năm 2000) hiện không được hỗ trợ bởi các HĐH chính thống ( Windows , OS X , Linux ).

Nếu "rất trẻ" có vẻ không phù hợp với bạn, hãy nghĩ về IPV6 : "vào tháng 12 năm 2008, mặc dù đánh dấu kỷ niệm 10 năm là giao thức Theo dõi Tiêu chuẩn, IPv6 chỉ ở giai đoạn sơ khai về mặt triển khai chung trên toàn thế giới."

SCTP được sử dụng rộng rãi trong mạng 4G LTE nơi Đường kính được sử dụng cho AAA.

Nó có thể không được biết đến nhiều, nhưng nó không được sử dụng. Gần đây, có một dự thảo được công bố tại IETF về việc sử dụng SCTP làm Giao thức lớp vận chuyển cho HTTP .

Liên quan đến tất cả các ý kiến ​​về các bộ định tuyến thương mại bị hỏng hoặc thiếu hỗ trợ SCTP, vấn đề là SCTP với NAT vẫn ở dạng dự thảo với IETF. Vì vậy, không có đặc điểm kỹ thuật RFC cho họ để thực hiện nó.

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

Sctp được sinh ra quá muộn và trong nhiều tình huống TCP là đủ.

Ngoài ra, như tôi biết phần lớn việc sử dụng nó là trên khu vực viễn thông.