Apa yang Anda gunakan saat Anda membutuhkan UDP yang andal?

93

Jika Anda mengalami situasi di mana koneksi TCP berpotensi terlalu lambat dan 'koneksi' UDP berpotensi terlalu tidak dapat diandalkan, apa yang Anda gunakan? Ada berbagai protokol UDP standar yang dapat diandalkan di luar sana, pengalaman apa yang Anda miliki dengannya?

Harap diskusikan satu protokol per balasan dan jika orang lain telah menyebutkan protokol yang Anda gunakan, pertimbangkan untuk memilihnya dan gunakan komentar untuk menjelaskannya jika diperlukan.

Saya tertarik dengan berbagai opsi di sini, di mana TCP berada di satu ujung skala dan UDP di ujung lain. Berbagai opsi UDP yang andal tersedia dan masing-masing membawa beberapa elemen TCP ke UDP.

Saya tahu bahwa seringkali TCP adalah pilihan yang tepat tetapi memiliki daftar alternatif seringkali berguna dalam membantu seseorang sampai pada kesimpulan itu. Hal-hal seperti Enet, RUDP, dll. Yang dibangun di atas UDP memiliki pro dan kontra yang beragam, apakah Anda pernah menggunakannya, apa pengalaman Anda?

Untuk menghindari keraguan, tidak ada lagi informasi, ini adalah pertanyaan hipotetis dan yang saya harap akan memperoleh daftar tanggapan yang merinci berbagai pilihan dan alternatif yang tersedia bagi seseorang yang perlu membuat keputusan.

— Len Holgate
sumber

1

Pertanyaan ini tampaknya di luar topik karena merupakan jajak pendapat untuk teknologi

— Dave Hillier

Mereka yang menganggap TCP adalah yang terbaik dalam semua kasus, harap baca: en.wikipedia.org/wiki/Bandwidth-delay_product

— nullptr

Wikipedia memiliki tabel bagus yang membandingkan berbagai aspek UDP, UDP Lite, TCP, Multipath TCP, SCTP, DCCP, dan RUDP . SCTP mendukung sebagian besar fitur dalam daftar itu.

— Evgeniy Berezovsky

@EugeneBeresovsky Saya membuat sedikit riset tentang SCTP, sebagian besar infonya, termasuk dari jawaban SO, tanggal hingga 2013 dan sebelumnya.Kebanyakan orang menulis saat itu bahwa adopsi SCTP sangat rendah. Saya bertanya-tanya bagaimana hari ini? Juga lihat utas ini stackoverflow.com/questions/1171555/…

— Michael IV

@MichaelIvanov Adopsi memang rendah. Tetapi jika Anda berniat untuk menggunakannya di dalam pusat data Anda, Anda tidak peduli tentang adopsi luar, selama sakelar dan router tidak menyebabkan masalah (yang, di pusat data, seharusnya tidak), dan Anda memiliki OS dan dukungan perpustakaan, yang mungkin menjadi masalah, seperti yang dijelaskan di salah satu jawaban dalam pertanyaan yang Anda tautkan.

— Evgeniy Berezovsky

25

Sulit untuk menjawab pertanyaan ini tanpa beberapa informasi tambahan tentang domain masalahnya. Misalnya, berapa volume data yang Anda gunakan? Seberapa sering? Apa sifat datanya? (misalnya, apakah unik, satu data? Atau aliran data sampel? dll.) Untuk platform apa Anda mengembangkan? (mis. desktop / server / tertanam) Untuk menentukan apa yang Anda maksud dengan "terlalu lambat", media jaringan apa yang Anda gunakan?

Tetapi dalam istilah umum (sangat!) Saya pikir Anda harus berusaha sangat keras untuk mengalahkan tcp untuk kecepatan, kecuali jika Anda dapat membuat beberapa asumsi keras tentang data yang Anda coba kirim.

Misalnya, jika data yang Anda coba kirim sedemikian rupa sehingga Anda dapat mentolerir hilangnya satu paket (mis. Data sampel secara teratur di mana tingkat pengambilan sampelnya berkali-kali lebih tinggi daripada bandwidth sinyal) maka Anda mungkin dapat mengorbankan beberapa keandalan transmisi dengan memastikan bahwa Anda dapat mendeteksi kerusakan data (misalnya melalui penggunaan CRC yang baik)

Tetapi jika Anda tidak dapat mentolerir hilangnya satu paket, maka Anda harus mulai memperkenalkan jenis teknik keandalan yang sudah dimiliki tcp. Dan, tanpa melakukan sejumlah pekerjaan yang wajar, Anda mungkin menemukan bahwa Anda mulai membangun elemen-elemen itu menjadi solusi ruang pengguna dengan semua masalah kecepatan yang melekat yang menyertainya.

— Andrew Edgecombe
sumber

4

Oke, saya akan menyesuaikan pertanyaannya. Saya lebih tertarik pada pro dan kontra dari berbagai protokol UDP yang andal di luar sana daripada respons 'gunakan TCP';)

— Len Holgate

9

@ Andrew - sangat MUDAH untuk mengalahkan TCP dalam dua kasus: (1) aplikasi Anda memiliki persyaratan keandalan yang lebih ringan daripada "semua data, selalu teratur, tidak ada duplikat, tidak ada antrian yang berlebihan". Atau (2) Anda menggunakan multicast. UDP yang andal sangat umum untuk lingkungan multicast.

— Tom

4

Juga, TCP sangat menderita ketika digunakan pada koneksi WAN (masalah jarak jauh). Kenapa, sederhana. TCP menggunakan jendela di mana paket di jendela harus di-ack. Protokol ACK menderita karena latensi karena jarak jalur. Google: WAN TCP "speed of light"

— Ajaxx

3

@ Ajaxx, Anda sangat benar dalam hal ini, namun TCP / IP sengaja melakukan ini karena internet meltdown terakhir. Jika Anda melakukan protokol bit rate tinggi tanpa kontrol kemacetan, pada dasarnya memalukan bagi Anda. Jika Anda memiliki jaringan, maka jadilah liar.

— Kevin Nisbet

2

"di mana tingkat pengambilan sampel secara signifikan lebih tinggi daripada tingkat nyquist" - tingkat pengambilan sampel selalu dua kali tingkat nyquist, menurut definisi.

— Steve

27

Bagaimana dengan SCTP . Ini adalah protokol standar oleh IETF (RFC 4960)

Ini memiliki kemampuan chunking yang dapat membantu kecepatan.

Pembaruan: perbandingan antara TCP dan SCTP menunjukkan bahwa kinerja dapat dibandingkan kecuali dua antarmuka dapat digunakan.

Pembaruan: artikel pengantar yang bagus .

— dermawan
sumber

Itu bagus, saya lebih tertarik pada hal-hal yang dapat dibangun di atas UDP daripada dibangun di atas IP tetapi tentu saja itu adalah sesuatu yang sesuai dengan ruang solusi.

— Len Holgate

SCTP memiliki banyak fitur hebat (seperti multihoming) dan dengan ekstensi keandalan parsial (RFC 3758) ini adalah opsi yang sangat fleksibel. Ini termasuk dalam versi kernel linux terbaru, tetapi untuk windows Anda harus menginstal tumpukan SCTP Anda sendiri.

— Andrew Johnson

6

SCTP dapat disalurkan melalui UDP. tools.ietf.org/id/draft-ietf-sigtran-sctptunnel-00.txt

— Miles

Terima kasih Miles, itu tautan yang berguna!

— Len Holgate

1

Ya ... Tapi sesuatu yang dibangun di atas UDP daripada pada level yang sama dengan UDP kemungkinan akan lebih mudah diimplementasikan di ruang pengguna, setidaknya di Windows ...

— Len Holgate

22

ENET - http://enet.bespin.org/

Saya telah bekerja dengan ENET sebagai protokol UDP yang andal dan menulis versi ramah soket asinkron untuk klien saya yang menggunakannya di server mereka. Ini bekerja dengan cukup baik tetapi saya tidak suka overhead yang ditambahkan oleh ping peer to peer ke koneksi yang tidak aktif; ketika Anda memiliki banyak koneksi, melakukan ping ke semuanya secara teratur adalah pekerjaan yang sangat sibuk.

ENET memberi Anda opsi untuk mengirim beberapa 'saluran' data dan agar data yang dikirim tidak dapat diandalkan, dapat diandalkan, atau diurutkan. Ini juga termasuk ping peer to peer tersebut yang bertindak sebagai tetap hidup.

— Len Holgate
sumber

14

Kami memiliki beberapa pelanggan industri pertahanan yang menggunakan UDT (Transfer Data berbasis UDP) (lihat http://udt.sourceforge.net/ ) dan sangat menyukainya. Saya melihat itu memiliki lisensi BSD yang ramah juga.

— Chris Markle
sumber

2

Dapatkah Anda menjelaskan tentang pelanggan Anda dan kasus penggunaan mereka, khususnya di sektor pertahanan? Mungkin tidak, tapi itu layak dicoba. Saya sebenarnya telah melemparkan ide kepada atasan saya tentang UDT dalam aplikasi transfer file, tetapi belum benar-benar pergi ke mana pun.

— Thomas Owens

10

RUDP - Protokol Datagram Pengguna yang Andal

Ini memberikan:

Pengakuan paket yang diterima
Jendela dan kontrol kemacetan
Transmisi ulang paket yang hilang
Overbuffering (Lebih cepat dari streaming real-time)

Tampaknya sedikit lebih dapat dikonfigurasi sehubungan dengan tetap hidup daripada ENet tetapi tidak memberi Anda banyak opsi (yaitu semua data dapat diandalkan dan diurutkan bukan hanya bit yang Anda putuskan seharusnya). Ini terlihat cukup mudah untuk diterapkan.

— Len Holgate
sumber

Saya melihat ini tetapi tampaknya tidak banyak penerapannya. Punya rekomendasi?

— Nicholas

Tidak, maaf. Saya tidak menggunakannya pada akhirnya dan akan selalu melakukan implementasi dari awal.

— Len Holgate

9

Seperti yang ditunjukkan orang lain, pertanyaan Anda sangat umum, dan apakah ada sesuatu yang 'lebih cepat' dari TCP atau tidak sangat bergantung pada jenis aplikasinya.

TCP umumnya secepat yang didapat untuk streaming data yang andal dari satu host ke host lainnya. Namun, jika aplikasi Anda melakukan banyak semburan kecil lalu lintas dan menunggu respons, UDP mungkin lebih tepat untuk meminimalkan latensi.

Ada jalan tengah yang mudah. Algoritme Nagle adalah bagian dari TCP yang membantu memastikan bahwa pengirim tidak membebani penerima aliran data yang besar, yang mengakibatkan kemacetan dan kehilangan paket.

Jika Anda memerlukan pengiriman TCP yang andal dan teratur, serta respons UDP yang cepat, dan tidak perlu khawatir tentang kemacetan pengiriman aliran data yang besar, Anda dapat menonaktifkan algoritme Nagle:

int opt = -1;
if (setsockopt(sock_fd, IPPROTO_TCP, TCP_NODELAY, (char *)&opt, sizeof(opt)))
  printf("Error disabling Nagle's algorithm.\n");

— smo
sumber

Seperti yang saya katakan, dengan asumsi TCP berada di satu ujung skala dan UDP di ujung lain, apa lagi yang ada.

— Len Holgate

Jika Anda ingin bertele-tele, sebagian besar protokol yang dibahas dibangun di atas UDP.

— smo

Asumsi bahwa TCP berada di satu ujung dan UDP di ujung lainnya adalah salah. misalnya UDP tidak memiliki kontrol aliran, Anda dapat dengan mudah mengirim paket terlalu cepat, menyebabkan peralihan perute menjatuhkan semuanya. Lalu apa yang kau lakukan ? Abaikan paket yang hilang atau kirim ulang? Mengirim ulang dan Anda akan lebih atau kurang menerapkan ulang TCP. Pilihan lain untuk komunikasi yang andal adalah SCTP.

— no

1

Respons yang cepat tidak selalu sama dengan throughput yang tinggi.

— Matt

1

Saya tidak setuju. Ketika nagle digunakan pada protokol berbasis TCP dengan banyak paket yang lebih kecil, itu akan menggabungkan mereka bersama dan membuat paket yang lebih besar. Ini menyebabkan sedikit keterlambatan dalam pengiriman sehingga latecy mungkin meningkat sangat sedikit. Namun, throughput bisa lebih rendah dengan nagle off karena lebih banyak paket = lebih banyak header paket = overhead lebih besar. Paket yang dijatuhkan pada LAN biasanya lebih berkaitan dengan pengisian buffer input. Jika Anda memiliki banyak klien yang mengirim data ke host yang sama, itu mungkin tidak membuat perbedaan. Saya tidak percaya mematikan dan mematikan nagle akan mempengaruhinya dalam praktik.

— Matt

8

Siapa pun yang memutuskan bahwa daftar di atas tidak cukup dan bahwa mereka ingin mengembangkan UDP yang andal SENDIRI harus melihat spesifikasi Google QUIC karena ini mencakup banyak kasus sudut yang rumit dan potensi serangan penolakan layanan. Saya belum bermain-main dengan implementasi ini, dan Anda mungkin tidak menginginkan atau membutuhkan semua yang disediakannya, tetapi dokumen ini sangat berharga untuk dibaca sebelum memulai desain UDP baru yang "dapat diandalkan".

Titik awal yang bagus untuk QUIC ada di sini , di Blog Chromium.

Dokumen desain QUIC saat ini dapat ditemukan di sini .

— Len Holgate
sumber

4

Jika Anda mengalami situasi di mana koneksi TCP berpotensi terlalu lambat dan 'koneksi' UDP berpotensi terlalu tidak dapat diandalkan, apa yang Anda gunakan? Ada berbagai protokol UDP standar yang dapat diandalkan di luar sana, pengalaman apa yang Anda miliki dengannya?

Kata kunci dalam kalimat Anda adalah 'berpotensi'. Saya pikir Anda benar-benar perlu membuktikan kepada diri sendiri bahwa TCP, pada kenyataannya, terlalu lambat untuk kebutuhan Anda jika Anda membutuhkan keandalan dalam protokol Anda.

Jika Anda ingin mendapatkan keandalan dari UDP maka pada dasarnya Anda akan mengimplementasikan ulang beberapa fitur TCP di atas UDP yang mungkin akan membuat segalanya lebih lambat daripada hanya menggunakan TCP di tempat pertama.

— 17 dari 26
sumber

Ya, Andrew Edgecombe mengatakan sebanyak itu, tetapi, seperti yang saya katakan, saya tertarik dengan pro dan kontra dari APA alternatif yang ada. Tanpa daftar alternatif dan pro dan kontra mereka maka sulit untuk memutuskan mana yang terbaik.

— Len Holgate

Mengingat fungsi keandalan yang diketahui, terkadang aliran UDP dapat disetel secara manual untuk melampaui aliran TCP di hte OS. Jarang sekali.

— Joshua

1

@ 17 dari 26, Saya setuju dengan Len Holgate, TCP akan lebih lambat daripada UDP yang dapat diandalkan dalam beberapa keadaan. Seperti jaringan BDP tinggi, misalkan Anda memiliki koneksi internet 1 Gbps dari Cina ke NewYork, saya yakin TCP akan menyedot untuk menggunakan hampir semua kecepatan 1 Gbps. TCP lebih baik untuk sebagian besar koneksi di bumi, tetapi tidak untuk jaringan dengan Produk Penundaan Bandwidth Tinggi.

— nullptr

4

Protocol DCCP, terstandarisasi dalam RFC 4340 , "Datagram Congestion Control Protocol" mungkin adalah yang Anda cari.

Sepertinya diterapkan di Linux .

— bortzmeyer.dll
sumber

3

Semoga RFC 5405 , "Pedoman Penggunaan UDP Unicast untuk Desainer Aplikasi" akan berguna untuk Anda.

— bortzmeyer.dll
sumber

2

Apakah Anda mempertimbangkan untuk mengompresi data Anda?

Seperti yang dinyatakan di atas, kami kekurangan informasi tentang sifat sebenarnya dari masalah Anda, tetapi mengompresi data untuk memindahkannya dapat membantu.

— dermawan
sumber

1

Terutama dengan pustaka kompresi modern. Beberapa secepat memcpy. misalnya lz4.

— Matt

2

RUDP . Banyak server soket untuk game menerapkan hal serupa.

— Insinyur
sumber

-2

Cara terbaik untuk mencapai keandalan menggunakan UDP adalah dengan membangun keandalan dalam program aplikasi itu sendiri (misalnya, dengan menambahkan mekanisme pengakuan dan transmisi ulang)

— kushan singh
sumber