Kapan tepat menggunakan UDP dan bukan TCP? [Tutup]

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?

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.

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.

"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.

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.

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.

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.

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

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.

Streaming video adalah contoh sempurna menggunakan UDP.

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)

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.

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 ....

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 .

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.

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.

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.

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.

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

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.

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).

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.

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.

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.

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