Mengapa SCTP tidak banyak digunakan / diketahui

190

Saya baru-baru ini memeriksa buku "UNIX Network Programming, Vol. 1" oleh Richards Stevens dan saya menemukan bahwa ada standar lapisan transport ketiga selain TCP dan UDP: SCTP .

Rangkuman: SCTP adalah protokol tingkat transportasi yang digerakkan oleh pesan seperti UDP, tetapi dapat diandalkan seperti TCP. Berikut ini adalah pengantar singkat dari IBM DeveloperWorks .

Jujur, saya belum pernah mendengar tentang SCTP sebelumnya. Saya tidak ingat pernah membacanya di buku jejaring apa pun atau mendengarnya di kelas yang telah saya ikuti. Membaca pertanyaan stackoverflow lainnya yang menyebutkan SCTP menunjukkan bahwa saya tidak sendirian dengan kurangnya pengetahuan ini.

Mengapa SCTP begitu tidak dikenal? Mengapa tidak banyak digunakan?

networking  tcp  popularity  sctp 
— tuan
sumber
4
+1 tidak pernah mendengarnya - terima kasih.
— Robert Venables
1
Siapa pun yang ingin membandingkan SCTP dengan ZeroMQ (selain itu satu adalah protokol, yang lain perpustakaan - lihat mereka sebagai alat untuk memecahkan masalah).
— Emil Ivanov
Saya hanya ingin tahu: Apa yang salah / berbeda pada 3/1/2013? Mengapa begitu banyak suara dalam satu hari ini?
— dmeister
8
@dister: Karena saya menempatkan Anda di Reddit . Salam dari Darmstadt.
— Janus Troelsen
32
Tolong jangan menulis 3/1/2013. Setiap dari "1 Maret 2013", "1-Mar-2013", "1 Maret '13" .. lebih disukai. Hanya saja, jangan menulis bulan dan hari dalam sebulan dengan cara yang bisa disalahartikan.
— Zecc

Jawaban:

94

Memang, SCTP digunakan sebagian besar di area telekomunikasi. Secara tradisional, switch telekomunikasi menggunakan SS7 ( Signaling System No. 7 ) untuk menghubungkan berbagai entitas dalam jaringan telekomunikasi. Misalnya - basis data pelanggan penyedia telekomunikasi (HLR), dengan sakelar (MSC), pelanggan juga terhubung (MSC).

Area telekomunikasi bergerak ke kecepatan yang lebih tinggi dan lingkungan yang lebih terjangkau. Salah satu perubahan ini adalah untuk menggantikan protokol SS7 dengan beberapa protokol berbasis IP yang lebih elegan, cepat dan fleksibel.

Area telekomunikasi sangat konservatif. Jaringan SS7 telah digunakan di sini selama beberapa dekade. Ini adalah jaringan yang sangat andal dan tertutup. Ini berarti pengguna biasa tidak memiliki akses ke sana.

Jaringan IP, sebaliknya, terbuka dan tidak dapat diandalkan, dan telekomunikasi tidak akan mengubahnya jika tidak akan menangani setidaknya beban yang ditangani SS7. Inilah sebabnya mengapa SCTP dikembangkan. Mencoba:

  • untuk meniru semua keuntungan dari jaringan SS7 yang terakumulasi selama beberapa dekade.
  • untuk membuat protokol berorientasi koneksi yang lebih baik daripada TCP dalam kecepatan, keamanan, dan redundansi

Rilis terbaru Linux sudah memiliki dukungan SCTP.

— dimba
sumber
khusus Anda harus melihat output dari kelompok kerja "SIGTRAN" IETF yang menulis pemetaan antara SS7 dan SCTP.
— Alnitak
22
Mungkin alasan utama SCTP tidak banyak digunakan di Internet publik adalah bahwa gateway IPv4 / NAT perumahan perlu menjadi SCTP-aware untuk mendukung asosiasi multiplexing antara beberapa endpoint pribadi simultan dan host eksterior. Carilah SCTP untuk menjadi lebih berguna setelah transisi IPv6 mulai mengambil lebih banyak uap.
— james woodyatt
@ jameswoodyatt ada implementasi perpustakaan SCTP melalui UDP. Ini memecahkan beberapa masalah dengan router tingkat konsumen.
— user7610
1
Ini sama sekali tidak menjawab pertanyaan. Respons James mengandung lebih banyak informasi daripada jawaban yang sebenarnya.
— Ken Sharp
@ jameswoodyatt Router tingkat konsumen yang pernah saya atasi dengan semua memiliki dukungan untuk itu, bahkan beberapa yang cukup lama. Masalahnya adalah itu tidak diekspos melalui UI biasa, jadi Anda harus melakukan beberapa hal mengerikan pada sistem untuk masuk ke tempat Anda dapat mengkonfigurasinya. Sesuatu yang keliru menurut saya.
— Perkins
70

Kami telah menggunakan SCTP di beberapa aplikasi sekarang, dan mengalami masalah signifikan dengan dukungan SCTP di berbagai router rumah. Mereka tidak menangani SCTP dengan benar. Saya percaya ini terutama masalah kinerja (spesifikasi protokol SCTP membutuhkan checksum untuk seluruh paket untuk dihitung ulang dan bukan hanya untuk header).

Seperti banyak protokol lain yang menjanjikan, SCTP sayangnya mati di air sampai D-link dan Netgear memperbaiki kotak NAT mereka yang rusak.

— pehrs
sumber
7
Wow, saya tidak menyadari hambatan masuk ini. Anda sepenuhnya benar - lihat tools.ietf.org/html/draft-ietf-behave-sctpnat-05 untuk cara yang diusulkan seputar hal ini. Ini adalah set ke-3 dari Internet Draft dengan topik yang sama ...
— Bwooce
Anda terdengar sangat pesimis - setidaknya untuk router rumah. Dengan asumsi router yang digunakan dalam lingkungan produksi profesional mendukungnya, SCTP masih terlihat sangat berguna. Ada banyak kasus penggunaan di mana topologi jaringan tidak meninggalkan tempat pusat data, dalam hal ini SCTP harus sempurna.
— Eugene Beresovsky
4
@EugeneBeresovksy: Sudah beberapa tahun sejak saya memposting jawaban itu. Kesan saya adalah bahwa SCTP tidak membuat kemajuan yang berarti sejak saat itu. Ini masih digunakan dalam beberapa aplikasi khusus di lingkungan yang terkendali, tetapi jarang terlihat di alam liar. Windows dan Mac OS X masih kekurangan dukungan SCTP. Kurangnya keakraban dan kerapuhan protokol yang dipecahkan oleh sebagian besar firewall dan kotak NAT membuat orang enggan menggunakannya.
— pehrs
@pehrs Saya ingin menggunakannya dalam pusat data, jadi tidak ada NAT yang terlibat, dan tidak ada firewall, kecuali yang built-in OS. Dalam lingkungan server Linux, saya harap itu hanya berfungsi. Tetapi bahkan menggunakan Windows, ada perpustakaan SCTP - dan saya percaya tanpa harus mengotak-atik OS.
— Eugene Beresovsky
SCTP biasanya tidak diaktifkan di Linux karena kurangnya adopsi, tetapi bahkan pada sistem Ubuntu Precise (lama) saya tersedia sebagai modul yang dapat dimuat. Menyediakan aplikasi yang ingin menggunakan SCTP tetapi akan kembali ke TCP (misalnya) adalah masalah yang mirip dengan penumpukan ganda, tetapi lebih menyakitkan.
— Ken Sharp
55

SCTP membutuhkan lebih banyak desain dalam aplikasi untuk mendapatkan penggunaan terbaik dari itu. Ada lebih banyak pilihan daripada TCP, API seperti Soket datang kemudian, dan masih muda. Namun saya pikir sebagian besar orang yang meluangkan waktu untuk memahaminya (dan yang tahu kekurangan TCP) menghargainya - ini adalah protokol yang dirancang dengan baik yang dibangun berdasarkan ~ 30 tahun pengetahuan kita tentang TCP dan UDP.

Salah satu aspek yang perlu dipikirkan adalah aliran. Streaming menyediakan (biasanya, saya pikir Anda dapat mematikannya) jaminan pesanan di dalamnya (seperti koneksi TCP) tetapi mungkin ada beberapa stream per koneksi SCTP. Jika data aplikasi Anda dapat dikirim melalui beberapa aliran, maka Anda menghindari pemblokiran head-of-line di mana penerima kelaparan karena satu paket salah bayar. Percakapan yang berbeda secara efektif dapat dilakukan melalui koneksi yang sama tanpa saling memengaruhi.

Tambahan lain yang bermanfaat adalah dukungan multi-homing - satu koneksi dapat melintasi beberapa antarmuka di kedua ujungnya dan mengatasi kegagalan. Anda dapat meniru ini dalam TCP, tetapi pada lapisan aplikasi.

Detak jantung tautan yang tepat, yang merupakan hal pertama yang digunakan aplikasi apa pun menggunakan TCP untuk koneksi non-transien, tersedia gratis.

Ringkasan pribadi saya tentang SCTP adalah bahwa ia tidak melakukan apa pun yang tidak dapat Anda lakukan dengan cara lain (dalam TCP atau UDP) dengan dukungan aplikasi substansial. Hal yang disediakannya adalah kemampuan untuk tidak harus mengimplementasikan kode itu (buruk) sendiri.

FYI, SCTP diamanatkan sebagai didukung untuk Diameter (cf RADIUS gen berikutnya). lihat RFC 3588

   Diameter klien HARUS mendukung TCP atau SCTP, sementara agen dan
   server HARUS mendukung keduanya. Versi mendatang dari spesifikasi ini MUNGKIN
   mengamanatkan bahwa klien mendukung SCTP.
— Bwooce
sumber
43

SCTP tidak banyak diketahui dan tidak banyak digunakan karena:

  • Tersebar luas: Tidak terintegrasi secara luas dalam tumpukan TCP / IP (pada 2013: masih hilang secara native di Mac OSX dan Windows terbaru)
  • Perpustakaan: Beberapa binding tingkat tinggi dalam bahasa yang mudah digunakan (Penafian: saya pengelola pysctp , dukungan stack mudah SCTP untuk Python)
  • NAT: Tidak melintasi NAT dengan sangat baik / sama sekali (kurang dari 1% router internet di rumah & perusahaan melakukan NAT di SCTP).
  • Popularitas: Tidak ada aplikasi umum yang menggunakannya
  • Pemrograman paradigma: itu berubah sedikit: itu masih soket, tetapi Anda dapat menghubungkan banyak host ke banyak host (multihoming), datagram dipesan dan dapat diandalkan, ...
  • Kompleksitas: Tumpukan SCTP rumit untuk diterapkan (karena di atas)
  • Persaingan: Multipath TCP akan datang dan harus mengatasi berbagai kebutuhan / kemampuan sehingga orang-orang menahan diri untuk tidak menerapkan SCTP jika mungkin, menunggu MTCP
  • Ceruk: Kebutuhan Isi SCTP sangat aneh (dipesan datagram terpercaya, multistream) dan tidak diperlukan oleh banyak aplikasi
  • Keamanan: SCTP menghindari kontrol keamanan (beberapa firewall, sebagian besar IDS, semua DLP, tidak muncul di netstat kecuali CentOS / Redhat / Fedora ...)
  • Kemampuan audit: Seperti 3 perusahaan di dunia yang secara rutin melakukan audit keamanan SCTP (Penafian: Saya bekerja di salah satu dari mereka)
  • Kurva pembelajaran: Tidak banyak toolchain untuk dimainkan dengan SCTP (periksa withsctp yang sangat bagus yang dipadukan dengan netcat atau gunakan socat)
  • Di bawah tenda: Sebagian besar digunakan dalam telekomunikasi dan setiap kali Anda mengirim SMS, mulai menjelajahi internet di ponsel Anda atau melakukan panggilan telepon, Anda sering memicu pesan yang mengalir melalui SCTP (SIGTRAN / SS7 dengan GSM / UMTS, Diameter dengan LTE / IMS / RCS, S1AP / X2AP dengan LTE), jadi Anda benar-benar sering menggunakannya tetapi Anda tidak pernah tahu tentang hal itu ;-)
— Phil L.
sumber
14
Re: "Ceruk / tidak dibutuhkan oleh banyak aplikasi". Browser web akan mendapat manfaat darinya, lihat HTTP2 dan upayanya untuk mengimplementasikan, di atas TCP, sebagian dari apa yang diberikan SCTP secara gratis. Sebagian besar teknik pengoptimalan HTTP (sprite, sharding, inlining, concatenation) akan dibuat (hampir sepenuhnya - header HTTP1 yang boros tetap tidak terpecahkan) berlebihan oleh SCTP. hal yang sama berlaku untuk aplikasi yang memiliki kumpulan koneksi untuk memungkinkan akses bersamaan ke DB atau layanan lainnya. Dengan kata lain: Ada kebutuhan besar oleh banyak aplikasi untuk beberapa fitur SCTP.
— Eugene Beresovsky
4
"Tidak ada aplikasi umum yang menggunakannya": Tidak benar lagi karena SCTP digunakan oleh WebRTC. "Keamanan: SCTP menghindari kontrol keamanan" - itu lebih merupakan masalah kontrol 'keamanan'. Jika memang menghindari cek itu maka akan menjadi protokol yang bagus untuk malware untuk tetap di bawah radar.
— Maciej Piechotka
14

p1. SCTP yang dipetakan langsung melalui IPv4 memerlukan dukungan di gateway NAT, yang belum pernah digunakan secara luas di mana pun, dan tanpa itu gateway NAT biasanya hanya akan mengizinkan satu host pribadi per alamat publik untuk menggunakan SCTP pada suatu waktu.

p2. SCTP yang dipetakan di atas UDP / IPv4 memungkinkan lebih banyak host pribadi per alamat publik, tetapi pemetaan UDP di gateway IPv4 / NAT terkenal rumit untuk dibangun dan dipelihara, karena fakta bahwa UDP adalah transportasi tanpa koneksi tanpa keadaan eksplisit untuk dilacak oleh NAT. .

p3. SCTP yang dipetakan langsung melalui IPv6 membutuhkan ... yah ... IPv6. Sudahkah Anda mencoba menggunakan IPv6? Jika demikian, pernahkah Anda mencoba membeli firewall IPv6? Apakah ini mendukung SCTP? Bagaimana dengan penyeimbang beban? Akselerator SSL?

p4. Akhirnya, banyak Internet yang terkendala dengan apa yang dapat ditampung melalui port TCP 80 dan port 443, sehingga SCTP dari rasa apa pun cenderung hilang di sana. Karenanya, Anda melihat upaya seperti kelompok kerja MPTCP di IETF.

— james woodyatt
sumber
"Sudahkah Anda mencoba membeli firewall IPv6? Apakah mendukung SCTP" - yang biasa didistribusikan secara bebas iptables mendukungnya dengan baik . Saya bukan orang jaringan, jadi saya tidak bisa mengatakan sisanya.
— Hi-Angel
12

Banyak dari kita akan segera menggunakan SCTP, karena ini digunakan oleh datachannels WebRTC untuk membuat lapisan andal seperti TCP di atas UDP - SCTP melalui DTLS melalui UDP: https://tools.ietf.org/html/draft-ietf -rtcweb-data-channel-13 # section-6

— cjb
sumber
Lupa menyebutkan bahwa fokus utama WebRTC adalah gabungan streaming video dan audio. Itu tidak dimaksudkan untuk digunakan sebagai relay pesan. layanan turn / ice / stun adalah bagian lain dari teknologi yang dijalankan WebRTC di atas. Tapi ini adalah teknologi yang digunakan WebRTC. Teknologi itu bukan WebRTC.
— TamusJRoyce
6

Membaca halaman Wikipedia SCTP Saya akan mengatakan bahwa alasan utama adalah bahwa SCTP adalah protokol yang sangat muda (diusulkan pada tahun 2000) yang saat ini tidak didukung oleh OS arus utama ( Windows , OS X , Linux ).

Jika "sangat muda" tampaknya tidak sesuai untuk Anda, pikirkan tentang IPV6 : "pada bulan Desember 2008, meskipun menandai peringatan 10 tahun sebagai protokol Standar Track, IPv6 hanya dalam masa pertumbuhan dalam hal penyebaran umum di seluruh dunia."

— IlDan
sumber
3
Menurut artikel Wikipedia yang Anda tautkan, SCTP diimplementasikan di Linux, Solaris, FreeBSD, HP-UX dan lainnya.
— drrlvn
Artikel yang ditautkan sekarang mengatakan juga bahwa itu berjalan pada OS X dan Windows.
— tuan
2

Mungkin tidak dikenal, tetapi tidak digunakan. Baru-baru ini ada draft yang diterbitkan di IETF tentang Menggunakan SCTP sebagai Transport Layer Protocol untuk HTTP .

— mkoeller
sumber
2
Ketika Anda mengatakan "tidak digunakan" saya memikirkan penggunaan protokol yang sebenarnya. Tetapi kemudian Anda hanya memberikan contoh konsep dokumen , yang berpotensi menyebabkan penggunaan nyata di masa mendatang.
— Kissaki
-1

Sctp dilahirkan terlambat, dan untuk banyak situasi TCP sudah cukup.

Juga, seperti yang saya tahu sebagian besar penggunaannya adalah di bidang telekomunikasi.

— Sam Liao
sumber
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.