Kapan tepat menggunakan UDP dan bukan TCP? [Tutup]

304

Karena TCP menjamin pengiriman paket dan dengan demikian dapat dianggap "dapat diandalkan", sedangkan UDP tidak menjamin apa pun dan paket dapat hilang. Apa keuntungan mentransmisikan data menggunakan UDP dalam suatu aplikasi daripada melalui aliran TCP? Dalam situasi seperti apa UDP akan menjadi pilihan yang lebih baik, dan mengapa?

Saya berasumsi bahwa UDP lebih cepat karena tidak memiliki overhead untuk membuat dan memelihara aliran, tetapi bukankah itu tidak relevan jika beberapa data tidak pernah mencapai tujuannya?

Jeff L.
sumber
55
Selain menderita kemungkinan kehilangan paket, UDP tidak menjamin bahwa Anda hanya akan menerima paket satu kali. Jika Anda memiliki jaringan yang berbelit-belit atau tidak terkonfigurasi dengan baik, Anda dapat menerima paket yang sama beberapa kali. Hanya kepala karena orang cenderung melupakan ini!
Brian Agnew
3
Bahkan tidak menjamin pemesanan paket.
Mehrdad Afshari
19
TCP tidak menjamin pengiriman , itu hanya menjamin bahwa jika ia mampu mengirimkan paket mereka akan berada dalam urutan yang sama dengan yang mereka kirim.
Chaim Geretz
5
BTW, saya sering melihat orang menyamakan keandalan / pengiriman in-order ke transmisi ulang TCP. Para "pakar" itu akan memberi tahu Anda bahwa untuk mengatasi kesalahan transmisi pada UDP, Anda akan mengimplementasikan ulang TCP (buruk) dan karenanya Anda sebaiknya menggunakan TCP. Ini tidak benar. Ada beberapa teknik pemulihan kesalahan selain pengiriman ulang, yang tidak mengalami latensi atau throughput yang terdegradasi secara eksponensial sebagai hasil dari tingkat kesalahan yang kecil tapi tidak nol.
Ben Voigt
TCP juga menjamin bahwa Anda akan tahu jika tujuan tidak menerima paket.
csga5000

Jawaban:

354

Ini adalah salah satu pertanyaan favorit saya. UDP sangat disalahpahami.

Dalam situasi di mana Anda benar-benar ingin mendapatkan jawaban sederhana ke server lain dengan cepat, UDP berfungsi paling baik. Secara umum, Anda ingin jawabannya berada dalam satu paket respons, dan Anda siap menerapkan protokol Anda sendiri untuk keandalan atau mengirim ulang. DNS adalah deskripsi sempurna dari use case ini. Biaya pengaturan koneksi terlalu tinggi (namun, DNS juga mendukung mode TCP).

Kasus lain adalah ketika Anda mengirimkan data yang bisa hilang karena data yang lebih baru yang masuk akan menggantikan data / keadaan sebelumnya. Data cuaca, streaming video, layanan kuota stok (tidak digunakan untuk perdagangan aktual), atau data game muncul di pikiran.

Kasus lain adalah ketika Anda mengelola sejumlah besar negara dan Anda ingin menghindari menggunakan TCP karena OS tidak dapat menangani banyak sesi. Ini adalah kasus yang jarang terjadi saat ini. Bahkan, sekarang ada tumpukan TCP pengguna-tanah yang dapat digunakan sehingga penulis aplikasi mungkin memiliki kontrol yang lebih baik atas sumber daya yang dibutuhkan untuk keadaan TCP itu. Sebelum tahun 2003, UDP adalah satu-satunya game di kota ini.

Satu kasus lain adalah untuk lalu lintas multicast. UDP dapat di-multicasted ke beberapa host sedangkan TCP tidak bisa melakukan ini sama sekali.

drudru
sumber
Terima kasih atas jawaban yang menarik. Kami memiliki server yang saat ini melakukan segalanya dalam UDP (persyaratan bandwidth tinggi) yang OK karena ada hop tunggal benar-benar (routing dinonaktifkan, ...), tetapi telah memperhatikan bahwa paket reordering dapat menjadi masalah pada beberapa kartu jaringan yang rusak. Apa yang disarankan oleh pengguna-mode TCP (atau beberapa pengguna-mode aliran terkontrol)?
dashesy
@dashesy - dapatkah Anda menyingkirkan persyaratan pemesanan? Apakah ada angka yang meningkat secara monoton di dalam muatan yang dapat Anda gunakan? Jika demikian, Anda tidak benar-benar membutuhkan tanah penuh pengguna TCP stack.
drudru
@ drudru- ya nomor urut ada, saya mungkin perlu buffer dan de-jitter sendiri. Terima kasih, menghilangkan satu opsi lagi selalu bagus.
dashesy
64

Jika paket TCP hilang, itu akan dikirim ulang. Itu tidak berguna untuk aplikasi yang bergantung pada data yang ditangani dalam urutan tertentu secara real time.

Contohnya termasuk streaming video dan terutama VoIP (misalnya Skype ). Namun dalam kasus-kasus itu, paket yang dijatuhkan bukanlah masalah besar: indera kita tidak sempurna, jadi kita bahkan mungkin tidak menyadarinya. Itulah sebabnya jenis aplikasi ini menggunakan UDP, bukan TCP.

Stephan202
sumber
16
Saya pikir Anda memilikinya mundur. TCP memesan kembali paket-paket sehingga data dikirimkan dalam pesanan yang dikirim. UDP tidak re-order dan memberikan data apapun memesannya diterima dalam.
Hans Malherbe
1
UDP tidak menjamin pesanan, namun Anda dapat memberi nomor pada paket dan memesan kembali setelah menerima kembali.
Kugel
7
@ Stephan202: Saya pikir saya harus tidak setuju tentang tidak memperhatikan paket yang jatuh di Skype ;-)
Robert S. Barnes
6
@ Kugel: Berhati-hatilah bahwa Anda mungkin menerapkan tumpukan TCP baru. Anda tidak mungkin melakukan pekerjaan yang lebih baik daripada OS saat ini.
erikkallen
1
@ erikkallen: Jika seseorang menggunakan UDP untuk mengimplementasikan protokol tingkat yang lebih tinggi dengan persyaratan yang sama yang dirancang untuk dipenuhi oleh TCP, ia tidak mungkin melakukan jauh lebih baik daripada protokol yang ada. Di sisi lain, beberapa aplikasi mendapat manfaat dari penambahan beberapa fitur pada protokol yang dapat ditangani oleh pembungkus UDP dengan lebih baik daripada TCP.
supercat
56

"Tidak dapat diandalkan" UDP adalah formalisme. Transmisi tidak dijamin sepenuhnya. Secara praktis, mereka hampir selalu berhasil. Mereka tidak diakui dan dicoba lagi setelah waktu habis.

Biaya overhead dalam negosiasi untuk soket TCP dan handshaking paket TCP sangat besar. Sangat besar. Tidak ada overhead UDP yang cukup besar.

Yang paling penting, Anda dapat dengan mudah menambah UDP dengan getaran tangan pengiriman yang dapat diandalkan yang lebih murah dari TCP. Baca ini: http://en.wikipedia.org/wiki/R reliable_User_Datagram_Protocol

UDP berguna untuk menyiarkan informasi dalam jenis aplikasi terbitkan-berlangganan. IIRC, TIBCO banyak menggunakan UDP untuk pemberitahuan perubahan status.

Segala jenis lain dari aktivitas "peristiwa penting" atau "logging" satu arah dapat ditangani dengan baik dengan paket UDP. Anda ingin mengirim pemberitahuan tanpa membuat seluruh soket. Anda tidak mengharapkan tanggapan dari berbagai pendengar.

Pesan sistem "detak jantung" atau "Aku hidup" juga merupakan pilihan yang baik. Yang hilang bukan krisis. Hilang setengah lusin (berturut-turut) adalah.

S.Lott
sumber
5
"Secara praktis, mereka hampir selalu berhasil". Sangat tergantung pada keandalan lapisan jaringan yang lebih rendah.
m0skit0
selain itu, apakah ada perbedaan antara perencanaan untuk "beberapa" paket loss dan "terlalu banyak" packet loss? kerugian adalah kerugian. Anda harus tetap merencanakannya.
Sedat Kapanoglu
30

Saya bekerja pada produk yang mendukung komunikasi UDP (IP) dan TCP / IP antara klien dan server. Ini dimulai dengan IPX lebih dari 15 tahun yang lalu dengan dukungan IP ditambahkan 13 tahun yang lalu. Kami menambahkan dukungan TCP / IP 3 atau 4 tahun yang lalu. Tebakan liar yang muncul: Rasio kode UDP ke TCP mungkin sekitar 80/20. Produk adalah server basis data, sehingga keandalan sangat penting. Kami harus menangani semua masalah yang diberlakukan oleh UDP (packet loss, packet doubling, packet order, dll.) Yang telah disebutkan dalam jawaban lain. Jarang ada masalah, tetapi kadang-kadang terjadi dan harus ditangani. Manfaat untuk mendukung UDP adalah kita dapat menyesuaikannya sedikit untuk penggunaan kita sendiri dan mengubah sedikit lebih banyak kinerja darinya.

Setiap jaringan akan berbeda, tetapi protokol komunikasi UDP umumnya sedikit lebih cepat bagi kita. Pembaca yang skeptis dengan tepat akan mempertanyakan apakah kita menerapkan semuanya dengan benar. Plus, apa yang dapat Anda harapkan dari seorang pria dengan perwakilan 2 digit? Meskipun demikian, saya baru saja menjalankan tes karena penasaran. Tes membaca 1 juta catatan (pilih * dari sesuatu yang mungkin terjadi). Saya menetapkan jumlah catatan untuk kembali dengan setiap permintaan klien individu menjadi 1, 10, dan kemudian 100 (tiga tes berjalan dengan masing-masing protokol). Server hanya berjarak dua hop lebih dari 100Mbit LAN. Angka-angka tersebut tampaknya sesuai dengan apa yang ditemukan orang lain di masa lalu (UDP sekitar 5% lebih cepat di sebagian besar situasi). Total waktu dalam milidetik adalah sebagai berikut untuk pengujian khusus ini:

  1. 1 catatan
    • IP: 390.760 ms
    • TCP: 416.903 ms
  2. 10 catatan
    • IP: 91.707 ms
    • TCP: 95.662 ms
  3. 100 catatan
    • IP: 29.664 ms
    • TCP: 30.968 ms

Jumlah total data yang dikirimkan hampir sama untuk IP dan TCP. Kami memiliki overhead tambahan dengan komunikasi UDP karena kami memiliki beberapa hal yang sama yang Anda dapatkan dengan "gratis" dengan TCP / IP (checksum, nomor urut, dll.). Sebagai contoh, Wireshark menunjukkan bahwa permintaan untuk set rekaman berikutnya adalah 80 byte dengan UDP dan 84 byte dengan TCP.

Mark Wilkins
sumber
Bagaimana jika Anda mengembangkannya hanya untuk TCP dan membeli perangkat keras yang lebih baik daripada upaya pengkodean 5x lebih banyak?
inf3rno
2
Terima kasih untuk bilangan konkretnya! Peningkatan 5% sedikit mengecewakan untuk kompleksitas yang ditambahkannya.
Sergei
1
Mungkin 5% itu karena dikirim dalam jaringan lokal (dua harapan lagi)? Dugaan saya adalah semakin jauh, semakin tinggi perbedaannya.
lepe
19

Sudah ada banyak jawaban bagus di sini, tetapi saya ingin menambahkan satu faktor yang sangat penting serta ringkasan. UDP dapat mencapai throughput yang jauh lebih tinggi dengan penyetelan yang benar karena tidak menggunakan kontrol kemacetan . Kontrol kemacetan di TCP sangat sangatpenting. Ini mengontrol laju dan throughput koneksi untuk meminimalkan kemacetan jaringan dengan mencoba memperkirakan kapasitas koneksi saat ini. Bahkan ketika paket dikirim melalui tautan yang sangat andal, seperti di jaringan inti, router memiliki buffer ukuran terbatas. Buffer ini memenuhi kapasitasnya dan paket-paket kemudian dijatuhkan, dan TCP memperhatikan penurunan ini melalui kurangnya pengakuan yang diterima, sehingga memperlambat kecepatan koneksi ke estimasi kapasitas. TCP juga menggunakan sesuatu yang disebut start lambat , tetapi throughput (sebenarnya jendela kemacetan)) secara perlahan ditingkatkan hingga paket-paket dijatuhkan, dan kemudian diturunkan dan perlahan-lahan meningkat lagi sampai paket-paket dijatuhkan dll. Hal ini menyebabkan throughput TCP berfluktuasi. Anda dapat melihat ini dengan jelas ketika Anda mengunduh file besar.

Karena UDP tidak menggunakan kontrol kemacetan, ia dapat menjadi lebih cepat dan mengalami lebih sedikit penundaan karena ia tidak akan berusaha untuk memaksimalkan buffer hingga titik jatuh, yaitu paket-paket UDP menghabiskan lebih sedikit waktu dalam buffer dan sampai di sana lebih cepat dengan lebih sedikit penundaan. Karena UDP tidak menggunakan kontrol kemacetan, tetapi TCP melakukannya, ia dapat mengambil kapasitas dari TCP yang menghasilkan aliran UDP.

UDP masih rentan terhadap kemacetan dan penurunan paket, jadi aplikasi Anda harus siap untuk menangani komplikasi ini, entah bagaimana, menggunakan transmisi ulang atau kode koreksi kesalahan.

Hasilnya adalah bahwa UDP dapat:

  • Dapatkan throughput yang lebih tinggi daripada TCP selama tingkat penurunan jaringan masih dalam batas yang dapat ditangani oleh aplikasi.
  • Memberikan paket lebih cepat dari TCP dengan sedikit penundaan.
  • Atur koneksi lebih cepat karena tidak ada jabat tangan awal untuk mengatur koneksi
  • Mengirim paket multicast, sedangkan TCP harus menggunakan beberapa koneksi.
  • Mengirimkan paket ukuran tetap, sedangkan TCP mengirimkan data dalam segmen. Jika Anda mentransfer paket UDP 300 Bytes, Anda akan menerima 300 Bytes di ujung lainnya. Dengan TCP, Anda dapat memberi makan soket pengiriman 300 Bytes, tetapi penerima hanya membaca 100 Bytes, dan Anda harus mengetahui entah bagaimana bahwa ada 200 Bytes di jalan. Ini penting jika aplikasi Anda mengirimkan pesan ukuran tetap, bukan aliran byte.

Singkatnya, UDP dapat digunakan untuk setiap jenis aplikasi yang dapat dilakukan TCP, selama Anda juga menerapkan mekanisme pengiriman ulang yang tepat. UDP bisa sangat cepat, memiliki sedikit penundaan, tidak terpengaruh oleh kemacetan berdasarkan koneksi, mentransmisikan datagram berukuran tetap, dan dapat digunakan untuk multicasting.

Andy
sumber
1
Ketika jaringan menjadi cukup padat untuk menyebabkan hilangnya paket, TCP mencoba untuk meminimalkan dampaknya terhadap pengguna lain dari jaringan, sementara banyak implementasi berbasis UDP tidak. Ini memungkinkan mereka mengambil porsi yang lebih besar dari pie yang berkurang, tetapi juga mengurangi jumlah total periode bandwidth yang berguna yang tersedia (misalnya sebagai konsekuensi dari pengiriman ulang yang tidak perlu dalam kasus-kasus di mana data sebenarnya akan dikirim tetapi pengirim tidak menyadari bahwa)
supercat
Pertama-tama, terima kasih atas jawaban yang bagus, saya benar-benar belajar banyak dari itu! Tapi saya punya pertanyaan: bukankah segmentasi terjadi pada layer 3 (IP) karena keterbatasan adaptor Ethernet untuk semua paket yang diterima dari layer 4 (baik TCP dan UDP)? Apakah yang Anda maksud jenis segmentasi lain yang terjadi dalam TCP tetapi tidak terjadi dalam UDP? Saya akan sangat menghargai jika Anda bisa menjelaskannya kepada saya.
RuslanSh
1
@ Freezy. Anda benar, fragmentasi paket yang melebihi MTU tautan (lapisan 2) terjadi pada lapisan 3-IP. Namun, TCP adalah protokol berbasis aliran dan memperlakukan data sebagai aliran byte. TCP memang mengirimkan datanya dalam segmen-segmen agar sesuai dengan paket-paket IP, yang berukuran sesuai dengan MSS, sehingga segmentasi juga terjadi dalam TCP. Namun, berapa banyak data yang dimasukkan oleh TCP ke dalam suatu segmen, atau berapa banyak data yang dibaca oleh soket Anda bervariasi oleh banyak faktor; bisa 1 byte atau byte MSS. Dengan UDP, penerima selalu mendapatkan jumlah byte yang tepat yang dikirim pemancar, jika paket tidak hilang dalam perjalanan.
Andy
15

UDP memang memiliki lebih sedikit overhead dan baik untuk melakukan hal-hal seperti streaming data waktu nyata seperti audio atau video, atau dalam hal apa pun di mana ok jika data hilang.

Dana Holt
sumber
15

UDP adalah protokol tanpa koneksi dan digunakan dalam protokol seperti SNMP dan DNS di mana paket data yang rusak tidak dapat diterima dan transmisi langsung dari masalah paket data.

Ini digunakan dalam SNMP karena manajemen jaringan harus sering dilakukan ketika jaringan berada dalam tekanan yaitu ketika dapat diandalkan, transfer data yang dikendalikan kemacetan sulit dicapai.

Ini digunakan dalam DNS karena tidak melibatkan koneksi, sehingga menghindari penundaan koneksi.

Bersulang

Arnkrishn
sumber
12

Salah satu jawaban terbaik yang saya tahu untuk pertanyaan ini berasal dari pengguna zAy0LfpBZLC8mAC di Hacker News . Jawaban ini sangat bagus, saya hanya akan mengutipnya apa adanya.

TCP memiliki head-of-queue blocking, karena menjamin pengiriman lengkap dan sesuai pesanan, sehingga ketika suatu paket hilang dalam perjalanan, ia harus menunggu pengiriman ulang paket yang hilang, sedangkan UDP mengirimkan paket ke aplikasi saat mereka tiba , termasuk duplikat dan tanpa jaminan bahwa paket datang sama sekali atau urutan mana mereka tiba (itu sebenarnya IP dengan nomor port dan (opsional) payload checksum ditambahkan), tetapi itu tidak masalah untuk telepon, misalnya, di mana biasanya sama sekali tidak masalah ketika beberapa milidetik audio hilang, tetapi penundaan sangat mengganggu, sehingga Anda tidak repot dengan transmisi ulang, Anda hanya perlu menggandakan duplikat, mengurutkan paket-paket yang disusun ulang ke dalam urutan yang tepat untuk beberapa ratus milidetik buffer jitter , dan jika paket tidak muncul tepat waktu atau tidak, mereka hanya dilewati,mungkin diinterpolasi jika didukung oleh codec.

Juga, bagian utama dari TCP adalah kontrol aliran, untuk memastikan Anda mendapatkan sebanyak mungkin transfer, tetapi tanpa membebani jaringan (yang agak berlebihan, karena jaringan yang kelebihan beban akan menjatuhkan paket Anda, yang berarti Anda harus melakukan mentransmisikan kembali, yang melukai throughput), UDP tidak memiliki semua itu - yang masuk akal untuk aplikasi seperti telepon, karena telepon dengan codec tertentu membutuhkan sejumlah bandwidth, Anda tidak dapat "memperlambatnya", dan bandwidth tambahan juga tidak membuat panggilan lebih cepat.

Selain aplikasi real-time / latensi rendah, UDP masuk akal untuk transaksi yang sangat kecil, seperti pencarian DNS, hanya karena tidak memiliki koneksi TCP dan overhead teardown, baik dalam hal latensi maupun dalam hal penggunaan bandwidth. Jika permintaan Anda lebih kecil dari MTU biasa dan repsonse mungkin juga, Anda dapat dilakukan dalam satu perjalanan pulang-pergi, tanpa perlu menjaga status apa pun di server, dan mengontrol aliran serta memesan dan semua yang mungkin tidak terlalu berguna baik untuk penggunaan seperti itu.

Dan kemudian, Anda dapat menggunakan UDP untuk membangun pengganti TCP Anda sendiri, tentu saja, tetapi mungkin itu bukan ide yang baik tanpa pemahaman mendalam tentang dinamika jaringan, algoritma TCP modern cukup canggih.

Juga, saya kira harus disebutkan bahwa ada lebih dari UDP dan TCP, seperti SCTP dan DCCP. Satu-satunya masalah saat ini adalah bahwa (IPv4) internet penuh dengan gateway NAT yang membuatnya tidak mungkin untuk menggunakan protokol selain UDP dan TCP dalam aplikasi pengguna akhir.

Shital Shah
sumber
Anda dapat menjalankan SCTP dan DCCP melalui UDP.
Demi
9

Streaming video adalah contoh sempurna menggunakan UDP.

Daniel A. White
sumber
Tolong berikan beberapa contoh.
Gaurav Singh
"Video Streaming" adalah contohnya. Pertimbangkan pertandingan langsung yang disiarkan di atas hotstar.
Sisir
8

UDP memiliki overhead yang lebih rendah, sebagaimana dinyatakan sudah baik untuk streaming hal-hal seperti video dan audio di mana lebih baik kehilangan paket kemudian mencoba mengirim ulang dan mengejar ketinggalan.

Tidak ada jaminan pengiriman TCP, Anda hanya akan diberi tahu jika soket terputus atau pada dasarnya jika data tidak akan tiba. Kalau tidak, ia akan sampai di sana ketika sampai di sana.

Satu hal besar yang dilupakan orang adalah udp berbasis paket, dan tcp berbasis bytestream, tidak ada jaminan bahwa "paket tcp" yang Anda kirim adalah paket yang muncul di ujung yang lain, dapat dibagi menjadi banyak paket sebagai keinginan router dan tumpukan. Jadi perangkat lunak Anda memiliki biaya tambahan parsing byte kembali ke potongan data yang dapat digunakan, yang dapat mengambil cukup banyak biaya overhead. UDP dapat rusak sehingga Anda harus memberi nomor pada paket Anda atau menggunakan mekanisme lain untuk memesan ulang jika Anda ingin melakukannya. Tetapi jika Anda mendapatkan paket udp itu tiba dengan semua byte yang sama dalam urutan yang sama seperti yang tersisa, tidak ada perubahan. Jadi istilah paket udp masuk akal tetapi paket tcp tidak selalu. TCP memiliki mekanisme coba ulang dan pemesanan sendiri yang disembunyikan dari aplikasi Anda,

UDP jauh lebih mudah untuk menulis kode pada kedua ujungnya, pada dasarnya karena Anda tidak harus membuat dan mempertahankan koneksi point to point. Pertanyaan saya biasanya di mana situasi di mana Anda ingin overhead TCP? Dan jika Anda mengambil jalan pintas seperti mengasumsikan "paket" tcp yang diterima adalah paket lengkap yang dikirim, apakah Anda lebih baik? (Anda cenderung membuang dua paket jika Anda repot-repot memeriksa panjang / konten)

old_timer
sumber
TCP memang memiliki jaminan pengiriman: chunk A akan dikirim ke aplikasi sebelum chunk B, oleh karena itu jika aplikasi mengakui (pada level aplikasi) chunk B Anda tahu mendapat chunk A. Tetapi ini juga terjadi pada level handling TCP juga.
Simeon Pilgrim
Dalam TCP, seseorang dapat dengan aman membatasi potongan data hanya dengan mengawali setiap potongan dengan panjangnya. Bergantung pada aplikasinya, seseorang dapat mengawali setiap potongan dengan panjang satu byte, dua byte, atau empat byte yang tetap, atau satu dapat mengawali setiap potongan berukuran 128 ^ N atau kurang dengan panjang byte N. Bukan overhead yang besar. Desain seperti itu akan buruk dengan protokol yang tidak menjamin pengiriman dalam urutan tanpa kesenjangan, tetapi ketika menggunakan TCP desain seperti itu baik-baik saja.
supercat
jika mencari jumlah data dengan panjang tetap Anda bahkan tidak perlu panjang Anda hanya menghitung byte saat mereka masuk ...
old_timer
1
@ supercat. Anda memang benar. Ini juga berarti Anda menambahkan kompleksitas ke aplikasi Anda; kompleksitas yang sebenarnya dibutuhkan dalam UDP. Karena alasan ini, TCP lebih baik untuk mentransfer aliran, seperti file. Tapi saya melakukan apa yang Anda lakukan ketika saya ingin keandalan data chunked, dan mungkin keamanan ekstra TLS pada TCP teratas.
Andy
5

Komunikasi jaringan untuk video game hampir selalu dilakukan melalui UDP.

Kecepatan sangat penting dan tidak masalah jika pembaruan dilewatkan karena setiap pembaruan berisi kondisi lengkap saat ini dari apa yang pemain dapat lihat.

17 dari 26
sumber
5
normal bukan kondisi lengkap sama sekali, tetapi delta sejak pengakuan terakhir, oleh karena itu pembaruan semakin besar.
Simeon Pilgrim
5

Pertanyaan kunci terkait dengan "situasi seperti apa yang akan menjadi pilihan yang lebih baik [atas tcp]"

Ada banyak jawaban bagus di atas tetapi yang kurang adalah penilaian formal dan objektif tentang dampak ketidakpastian transportasi terhadap kinerja TCP.

Dengan pertumbuhan besar aplikasi mobile, dan paradigma "sesekali terhubung" atau "sesekali terputus" yang menyertainya, tentu ada situasi di mana overhead dari upaya TCP untuk mempertahankan koneksi ketika koneksi sulit didapat dengan mengarah pada kuat kasus untuk UDP dan sifatnya "berorientasi pesan".

Sekarang saya tidak memiliki matematika / penelitian / angka tentang ini, tapi saya telah menghasilkan aplikasi yang telah bekerja lebih andal menggunakan dan ACK / NAK dan penomoran pesan lebih dari UDP daripada yang bisa dicapai dengan TCP ketika konektivitas umumnya buruk dan TCP tua yang buruk hanya menghabiskan waktu dan uang klien saya hanya mencoba untuk terhubung. Anda mendapatkan ini di daerah regional dan pedesaan di banyak negara barat ....

Rob Von Nesselrode
sumber
3

Dalam beberapa kasus, yang telah disorot orang lain, jaminan kedatangan paket tidak penting, dan karenanya menggunakan UDP tidak masalah. Ada kasus lain di mana UDP lebih disukai daripada TCP.

Satu kasus unik di mana Anda ingin menggunakan UDP alih-alih TCP adalah ketika Anda melakukan tunneling TCP melalui protokol lain (mis. Terowongan, jaringan virtual, dll.). Jika Anda tunnel TCP melalui TCP, kontrol kemacetan masing-masing akan saling mengganggu. Oleh karena itu orang umumnya lebih suka tunnel TCP melalui UDP (atau protokol stateless lainnya). Lihat artikel TechRepublic: Memahami TCP Over TCP: Efek dari Tunneling TCP pada Throughput dan Latency End-to-End .

Brian M. Hunt
sumber
2

UDP dapat digunakan ketika aplikasi lebih peduli tentang data "waktu-nyata" daripada replikasi data yang tepat. Sebagai contoh, VOIP dapat menggunakan UDP dan aplikasi akan khawatir tentang pemesanan ulang paket, tetapi pada akhirnya VOIP tidak membutuhkan setiap paket tunggal, tetapi yang lebih penting membutuhkan aliran berkelanjutan dari banyak paket tersebut. Mungkin Anda di sini "kesalahan" dalam kualitas suara, tetapi tujuan utamanya adalah bahwa Anda mendapatkan pesan dan bukan bahwa itu diciptakan kembali dengan sempurna di sisi lain. UDP juga digunakan dalam situasi di mana biaya membuat koneksi dan menyinkronkan dengan TCP lebih besar daripada payload. Permintaan DNS adalah contoh sempurna. Satu paket keluar, satu paket kembali, per kueri. Jika menggunakan TCP ini akan jauh lebih intensif. Jika Anda tidak mendapatkan kembali respons DNS, coba lagi.

RC.
sumber
2

UDP saat kecepatan diperlukan dan akurasi jika paket tidak, dan TCP saat Anda membutuhkan akurasi.

UDP seringkali lebih sulit karena Anda harus menulis program Anda sedemikian rupa sehingga tidak tergantung pada keakuratan paket.

bgw
sumber
2

Itu tidak selalu jelas. Namun, jika Anda membutuhkan pengiriman paket yang terjamin tanpa kehilangan dan dalam urutan yang tepat maka TCP mungkin adalah yang Anda inginkan.

Di sisi lain UDP cocok untuk mentransmisikan paket informasi pendek di mana urutan informasi kurang penting atau di mana data dapat masuk ke dalam satu paket.

Ini juga sesuai ketika Anda ingin menyiarkan informasi yang sama ke banyak pengguna.

Di waktu lain, itu tepat ketika Anda mengirim data berurutan tetapi jika beberapa hilang, Anda tidak terlalu khawatir (misalnya aplikasi VOIP).

Beberapa protokol lebih kompleks karena yang dibutuhkan adalah beberapa (tetapi tidak semua) fitur TCP, tetapi lebih dari yang disediakan oleh UDP. Di situlah lapisan aplikasi harus mengimplementasikan fungsionalitas tambahan. Dalam kasus-kasus itu, UDP juga sesuai (mis. Radio Internet, pesanan itu penting tetapi tidak setiap paket harus melewatinya).

Contoh di mana itu / bisa digunakan 1) Server waktu menyiarkan waktu yang tepat untuk sekelompok mesin pada LAN. 2) Protokol VOIP 3) Pencarian DNS 4) Meminta layanan LAN misalnya di mana Anda? 5) radio Internet 6) dan banyak lainnya ...

Pada unix Anda dapat mengetikkan grep udp / etc / services untuk mendapatkan daftar protokol UDP yang diimplementasikan hari ini ... ada ratusan.

Mat
sumber
2

Lihatlah bagian 22.4 dari Pemrograman Jaringan Unix Steven , "Kapan Menggunakan UDP Bukan TCP".

Juga, lihat jawaban SO lainnya ini tentang kesalahpahaman bahwa UDP selalu lebih cepat daripada TCP .

Apa yang dikatakan Steven dapat disimpulkan sebagai berikut:

  • Gunakan UDP untuk siaran dan multicast karena itu adalah satu-satunya pilihan Anda (gunakan multicast untuk semua aplikasi baru)
  • Anda dapat menggunakan UDP untuk aplikasi permintaan / balasan sederhana, tetapi Anda harus membangun acks, timeout, dan transmisi ulang Anda sendiri
  • Jangan gunakan UDP untuk transfer data massal.
Robert S. Barnes
sumber
1
Sedikit lebih banyak informasi tentang poin terakhir itu, untuk siapa saja yang datang. TCP berfungsi untuk transfer data massal, tetapi jika Anda tidak peduli bahwa data Anda tiba dalam urutan awal-ke-akhir, Anda dapat menulis protokol melalui UDP yang mungkin lebih cepat - jauh lebih cepat dalam kasus patologis yang sangat spesifik. Bukannya Anda tidak dapat melakukan transfer massal dalam UDP, ini bukan berarti ia selalu berkinerja lebih buruk; itu hanya rasa sakit di pantat untuk menerapkan bahwa itu jarang layak repot.
ijw
1
Ya, Anda dapat menggunakan UDP untuk transfer massal, dan Anda harus menerapkan mekanisme kontrol Anda sendiri. Jika rasa sakit di pantat atau tidak tergantung pada kemampuan pemrograman Anda, tapi itu pasti tidak selalu pemain yang lebih buruk. Anda harus tahu apa yang Anda lakukan; jika Anda tidak ya, Anda mungkin menderita.
Andy
2

Kita tahu bahwa UDP adalah protokol tanpa koneksi, begitulah

  1. cocok untuk proses yang membutuhkan komunikasi permintaan-respons sederhana.
  2. cocok untuk proses yang memiliki aliran internal, kontrol kesalahan
  3. cocok untuk casting luas dan multicasting

Contoh spesifik:

  • digunakan dalam SNMP
  • digunakan untuk beberapa protokol pembaruan rute seperti RIP
Vikki
sumber
2

Membandingkan TCP dengan UDP, protokol tanpa koneksi seperti UDP menjamin kecepatan, tetapi tidak keandalan transmisi paket. Sebagai contoh dalam permainan video biasanya tidak memerlukan jaringan yang dapat diandalkan tetapi kecepatan adalah yang paling penting dan menggunakan UDP untuk permainan memiliki keuntungan mengurangi penundaan jaringan.

masukkan deskripsi gambar di sini

Jorgesys
sumber
1

Anda ingin menggunakan UDP melalui TCP dalam kasus di mana kehilangan beberapa data sepanjang jalan tidak akan sepenuhnya merusak data yang sedang dikirim. Banyak kegunaannya dalam aplikasi waktu nyata, seperti bermain game (yaitu, FPS, di mana Anda tidak selalu harus tahu di mana setiap pemain pada waktu tertentu, dan jika Anda kehilangan beberapa paket di sepanjang jalan, baru data akan memberi tahu Anda dengan tepat di mana para pemain berada), dan streaming video waktu-nyata (satu frame yang rusak tidak akan merusak pengalaman menonton).

Zachary Murray
sumber
Nah satu frame yang rusak akan merusak bagian tampilan itu, tetapi Anda tidak ingin itu menghentikan semua frame yang terakhir, sambil menunggu, jika frame yang kemudian memiliki nilai lebih dari frame yang hilang.
Simeon Pilgrim
1

Kami memiliki layanan web yang memiliki ribuan winforms client di banyak PC. PC tidak memiliki koneksi dengan DB backend, semua akses adalah melalui layanan web. Jadi kami memutuskan untuk mengembangkan server logging pusat yang mendengarkan pada port UDP dan semua klien mengirimkan paket log kesalahan xml (menggunakan log4net UDP appender) yang akan dibuang ke tabel DB setelah diterima. Karena kami tidak begitu peduli jika ada beberapa log kesalahan yang terlewatkan dan dengan ribuan klien, ini cepat dengan layanan pendataan khusus yang tidak memuat layanan web utama.

softveda
sumber
0

Saya agak enggan untuk menyarankan UDP ketika TCP mungkin bisa bekerja. Masalahnya adalah jika TCP tidak berfungsi karena suatu alasan, karena koneksi terlalu lambat atau macet, mengubah aplikasi untuk menggunakan UDP tidak akan membantu. Koneksi yang buruk juga buruk untuk UDP. TCP sudah melakukan pekerjaan yang sangat baik untuk meminimalkan kemacetan.

Satu-satunya kasus yang dapat saya pikirkan di mana UDP diperlukan adalah untuk protokol siaran. Dalam kasus di mana aplikasi melibatkan dua, host yang dikenal, UDP kemungkinan hanya akan menawarkan manfaat kinerja marjinal untuk secara substansial meningkatkan biaya kompleksitas kode.

SingleNegationElimination
sumber
Salah satu aplikasi di mana Anda akan mendapatkan hasil yang lebih baik dari UDP adalah melalui uji put, jika simpul menengah melakukan pemolisian lalu lintas, karena Anda dapat mengontrol laju paket dengan lebih mudah, ayat TCP yang akan mendorong paket dengan cepat, dan interaksi TCP windowing berinteraksi secara negatif dengan kepolisian.
Simeon Pilgrim
Ini masih merupakan optimasi, yang harus mengikuti dari pengujian yang sebenarnya. Argumen saya adalah bahwa Anda harus tetap mencoba menggunakan TCP terlebih dahulu, dan hanya mencoba alternatif ketika Anda menemukan bahwa TCP tidak berfungsi karena suatu alasan. Memilih UDP karena secara teoritis mendukung penggunaan bandwidth yang lebih baik adalah bentuk optimasi prematur.
SingleNegationElimination
Oh setuju di bagian depan optimasi. Tetapi pengetahuan tentang kapan TCP mungkin menjadi masalah ayat sesuatu yang lain membantu ketika Anda mencoba menyelesaikan masalah kinerja itu.
Simeon Pilgrim
-1

Gunakan UDP hanya jika Anda benar-benar tahu apa yang Anda lakukan. UDP dalam kasus yang sangat langka saat ini, tetapi jumlah (bahkan sangat berpengalaman) ahli yang akan mencoba untuk menempel di mana-mana tampaknya tidak proporsional. Mungkin mereka menikmati penerapan kode penanganan kesalahan dan pemeliharaan koneksi sendiri.

TCP seharusnya diharapkan lebih cepat dengan kartu antarmuka jaringan modern karena apa yang dikenal sebagai checksum imprint . Anehnya, pada kecepatan koneksi cepat (seperti 1Gbps) menghitung sebuah checksum akan menjadi beban besar untuk CPU sehingga diturunkan ke perangkat keras NIC yang mengenali paket TCP untuk dicetak, dan tidak akan menawarkan layanan yang sama kepada Anda.

Pavel Radzivilovsky
sumber
2
Offload checksum UDP tersedia seperti halnya TCP checksum offload.
Ben Voigt
tetapi tidak validasi checksum.
Pavel Radzivilovsky
1
Bahkan adaptor ethernet tingkat konsumen saat ini memiliki muatan UDP checksum untuk pengiriman dan penerimaan (penerimaan yang menerima sedang melakukan validasi). Dan saya melihat fitur itu dalam perangkat keras prosumer satu dekade yang lalu, saya yakin itu sudah ada di NIC kelas server bahkan lebih lama.
Ben Voigt
-2

UDP sempurna untuk VoIP yang ditujukan ke mana paket data harus dikirim karena kurang keandalannya ... Obrolan video adalah contoh UDP (Anda dapat memeriksanya dengan menangkap jaringan wireshark selama obrolan video apa pun). Juga TCP tidak berfungsi dengan Protokol DNS dan SNMP. UDP tidak memiliki overhead sementara TCP memiliki banyak Overhead

Himanshu Saxena
sumber