UDP vs TCP, seberapa cepat itu? [Tutup]

Untuk pertukaran pesan protokol umum, yang dapat mentolerir beberapa paket yang hilang. Seberapa jauh lebih efisienkah UDP dari TCP?

UDP lebih cepat dari TCP, dan alasan sederhananya adalah karena tidak ada paket yang mengakui (ACK) yang memungkinkan aliran paket kontinu, bukannya TCP yang mengakui satu set paket, dihitung dengan menggunakan ukuran jendela TCP dan waktu perjalanan pulang pergi (RTT).

Untuk informasi lebih lanjut, saya merekomendasikan penjelasan Skullbox yang sederhana namun sangat mudah dipahami (TCP vs. UDP)

Orang-orang mengatakan bahwa hal utama yang diberikan TCP adalah keandalan. Tapi itu tidak sepenuhnya benar. Hal terpenting yang diberikan TCP kepada Anda adalah kontrol kemacetan: Anda dapat menjalankan 100 koneksi TCP di seluruh link DSL semua berjalan dengan kecepatan maksimal, dan semua 100 koneksi akan menjadi produktif, karena mereka semua "merasakan" bandwidth yang tersedia. Cobalah itu dengan 100 aplikasi UDP yang berbeda, semua paket mendorong secepat mungkin, dan lihat seberapa baik semuanya berjalan baik untuk Anda.

Pada skala yang lebih besar, perilaku TCP inilah yang menjaga Internet dari mengunci menjadi "keruntuhan kemacetan".

Hal-hal yang cenderung mendorong aplikasi ke arah UDP:

• Semantik pengiriman grup: pengiriman yang andal ke sekelompok orang mungkin dilakukan dengan lebih efisien daripada pengakuan point-to-point TCP.

• Pengiriman out-of-order: di banyak aplikasi, selama Anda mendapatkan semua data, Anda tidak peduli urutan apa yang masuk; Anda dapat mengurangi latensi tingkat aplikasi dengan menerima blok yang rusak.

• Tidak ramah: pada pihak LAN, Anda mungkin tidak peduli jika browser web Anda berfungsi dengan baik asalkan Anda memutarkan pembaruan ke jaringan secepat mungkin.

Tetapi bahkan jika Anda peduli dengan kinerja, Anda mungkin tidak ingin menggunakan UDP:

• Anda sedang berada di jalur untuk keandalan sekarang, dan banyak hal yang mungkin Anda lakukan untuk menerapkan keandalan dapat menjadi lebih lambat dari apa yang sudah dilakukan TCP.

• Sekarang Anda tidak ramah jaringan, yang dapat menyebabkan masalah di lingkungan yang dibagikan.

• Yang paling penting, firewall akan memblokir Anda.

Anda berpotensi mengatasi beberapa masalah kinerja dan latensi TCP dengan "trunking" beberapa koneksi TCP secara bersamaan; iSCSI melakukan ini untuk mengatasi kontrol kemacetan di jaringan area lokal, tetapi Anda juga dapat melakukannya untuk membuat saluran pesan "urgensi" latensi rendah (perilaku "URGENT" TCP benar-benar rusak).

Dalam beberapa aplikasi TCP lebih cepat (throughput lebih baik) daripada UDP.

Ini adalah kasus ketika melakukan banyak menulis kecil relatif terhadap ukuran MTU. Sebagai contoh, saya membaca percobaan di mana aliran paket 300 byte dikirim melalui Ethernet (1500 byte MTU) dan TCP 50% lebih cepat dari UDP .

Alasannya adalah karena TCP akan mencoba dan buffer data dan mengisi segmen jaringan penuh sehingga membuat penggunaan bandwidth yang tersedia menjadi lebih efisien.

UDP di sisi lain segera menempatkan paket pada kabel sehingga memadatkan jaringan dengan banyak paket kecil.

Anda mungkin tidak boleh menggunakan UDP kecuali Anda memiliki alasan yang sangat spesifik untuk melakukannya. Terutama karena Anda dapat memberikan TCP jenis latensi yang sama dengan UDP dengan menonaktifkan algoritme Nagle (misalnya jika Anda mentransmisikan data sensor waktu nyata dan Anda tidak khawatir tentang kemacetan jaringan dengan banyak paket kecil).

dengan toleran kerugian

Maksud Anda "dengan toleransi kehilangan"?

Pada dasarnya, UDP bukan "loss tolerant". Anda dapat mengirim 100 paket kepada seseorang, dan mereka mungkin hanya mendapatkan 95 paket, dan beberapa mungkin salah urutan.

Untuk hal-hal seperti streaming video, dan permainan multi-pemain, di mana lebih baik melewatkan paket daripada menunda semua paket lain di belakangnya, ini adalah pilihan yang jelas

Untuk sebagian besar hal lain, paket yang hilang atau 'diatur ulang' sangat penting. Anda harus menulis beberapa kode tambahan untuk dijalankan di atas UDP untuk mencoba lagi jika ada yang terlewat, dan menegakkan urutan yang benar. Ini akan menambah sedikit overhead di tempat-tempat tertentu.

Untungnya, beberapa orang yang sangat pintar telah melakukan ini, dan mereka menyebutnya TCP.

Pikirkan seperti ini: Jika sebuah paket hilang, apakah Anda lebih suka mendapatkan paket berikutnya secepat mungkin dan melanjutkan (menggunakan UDP), atau apakah Anda benar-benar membutuhkan data yang hilang (gunakan TCP). Overhead tidak akan menjadi masalah kecuali Anda benar-benar dalam skenario kasus tepi.

Protokol mana yang berkinerja lebih baik (dalam hal throughput) - UDP atau TCP - sangat tergantung pada karakteristik jaringan dan lalu lintas jaringan. Robert S. Barnes, misalnya, menunjukkan skenario di mana TCP berkinerja lebih baik (tulisan berukuran kecil). Sekarang, pertimbangkan skenario di mana jaringan padat dan memiliki lalu lintas TCP dan UDP. Pengirim dalam jaringan yang menggunakan TCP, akan merasakan 'kemacetan' dan mengurangi tarif pengiriman mereka. Namun, UDP tidak memiliki penghindaran kemacetan atau mekanisme kontrol kemacetan, dan pengirim yang menggunakan UDP akan terus memompa data dengan kecepatan yang sama. Secara bertahap, pengirim TCP akan mengurangi tingkat pengiriman mereka ke minimum dan jika pengirim UDP memiliki cukup data untuk dikirim melalui jaringan, mereka akan menanggung sebagian besar bandwidth yang tersedia. Jadi, dalam kasus seperti itu, Pengirim UDP akan memiliki throughput yang lebih besar, karena mereka mendapatkan pie yang lebih besar dari bandwidth jaringan. Bahkan, ini adalah topik penelitian aktif - Bagaimana meningkatkan throughput TCP di hadapan lalu lintas UDP. Salah satu cara, yang saya tahu, menggunakan aplikasi TCP mana yang dapat meningkatkan throughput adalah dengan membuka beberapa koneksi TCP. Dengan begitu, meskipun, setiap throughput koneksi TCP mungkin terbatas, jumlah total throughput semua koneksi TCP mungkin lebih besar dari throughput untuk aplikasi yang menggunakan UDP.

Ketika berbicara tentang "apa yang lebih cepat" - setidaknya ada dua aspek yang sangat berbeda: throughput dan latensi.

Jika berbicara tentang throughput - kontrol aliran TCP (seperti yang disebutkan dalam jawaban lain), sangat penting dan melakukan apa pun yang sebanding dengan UDP, sementara tentu mungkin, akan menjadi Sakit Kepala Besar (tm). Akibatnya - menggunakan UDP saat Anda membutuhkan throughput , jarang memenuhi syarat sebagai ide yang baik (kecuali jika Anda ingin mendapatkan keuntungan yang tidak adil atas TCP).

Namun, jika berbicara tentang latensi - semuanya benar-benar berbeda. Sementara dengan tidak adanya packet loss, TCP dan UDP berperilaku sangat mirip (semua perbedaan, jika ada, menjadi marginal) - setelah paket hilang, seluruh pola berubah secara drastis.

Setelah kehilangan paket, TCP akan menunggu untuk mentransmisikan ulang setidaknya 200ms (1sec per paragraf 2.4 dari RFC6298, tetapi implementasi modern yang praktis cenderung menguranginya menjadi 200ms). Selain itu, dengan TCP, bahkan paket-paket yang mencapai host tujuan - tidak akan dikirimkan ke aplikasi Anda sampai paket yang hilang diterima (yaitu, seluruh komunikasi tertunda ~ 200 ms) - BTW, efek ini, yang dikenal sebagai Head-of -Line Blocking, melekat pada semua stream pesanan yang dapat diandalkan, baik TCP atau + dapat dipesan UDP. Untuk membuat segalanya lebih buruk - jika paket yang dikirim ulang juga hilang, maka kita akan berbicara tentang penundaan ~ 600 ms (karena apa yang disebut sebagai backoff eksponensial, pengiriman ulang pertama adalah 200 ms, dan yang kedua adalah 200 * 2 = 400 ms). Jika saluran kami mengalami kehilangan paket 1% (yang tidak buruk menurut standar saat ini), dan kami memiliki permainan dengan 20 pembaruan per detik - penundaan 600 ms seperti itu akan terjadi rata-rata setiap 8 menit. Dan 600ms lebih dari cukup untuk membuat Anda terbunuh dalam permainan yang serba cepat - yah, itu sangat buruk untuk gameplay. Efek ini adalah persis mengapa gamedevs lebih suka UDP daripada TCP.

Namun, ketika menggunakan UDP untuk mengurangi latensi - penting untuk menyadari bahwa hanya "menggunakan UDP" tidak cukup untuk mendapatkan peningkatan latensi yang substansial, itu semua tentang BAGAIMANA Anda menggunakan UDP. Secara khusus, sementara perpustakaan RUDP biasanya menghindari "backoff eksponensial" dan menggunakan waktu pengiriman ulang yang lebih pendek - jika mereka digunakan sebagai aliran "dapat dipesan", mereka masih harus menderita dari Head-of-Line Blocking (jadi dalam kasus penggandaan packet loss, bukannya 600ms kita akan mendapatkan sekitar 1,5 * 2 * RTT - atau untuk RTT 80ms yang cukup bagus, ini adalah penundaan ~ 250ms, yang merupakan peningkatan, tetapi masih mungkin untuk melakukan yang lebih baik). Di sisi lain, jika menggunakan teknik yang dibahas dalam http://gafferongames.com/networked-physics/snapshot-compression/ dan / atau http: // ithare. , itu mungkin untuk menghilangkan pemblokiran Head-of-Line sepenuhnya (jadi untuk kehilangan paket ganda untuk game dengan 20 pembaruan / detik, penundaan akan 100 ms terlepas dari RTT).

Dan sebagai catatan tambahan - jika Anda kebetulan memiliki akses hanya ke TCP tetapi tidak ada UDP (seperti di browser, atau jika klien Anda berada di belakang salah satu dari 6-9% firewall jelek yang memblokir UDP) - sepertinya ada cara untuk menerapkan UDP-over-TCP tanpa menimbulkan latensi terlalu banyak, lihat di sini: http://ithare.com/almost-zero-additional-latency-udp-over-tcp/ (pastikan untuk membaca komentar juga (!)).

Setiap koneksi TCP memerlukan jabat tangan awal sebelum data dikirimkan. Juga, tajuk TCP berisi banyak overhead yang ditujukan untuk sinyal yang berbeda dan deteksi pengiriman pesan. Untuk pertukaran pesan, UDP mungkin akan cukup jika peluang kecil kegagalan dapat diterima. Jika tanda terima harus diverifikasi, TCP adalah pilihan terbaik Anda.

@Andrew , saya mohon berbeda. UDP adalah pilihan dalam beberapa jenis aplikasi karena persyaratan kinerja. Salah satu contoh klasik adalah konferensi video. Aplikasi semacam ini tidak merespons dengan baik terhadap kontrol TCP.

Aspek lain yang perlu dipertimbangkan adalah jika Anda akan membutuhkan multicast. Jika demikian, gunakan UDP.

Jika Anda perlu dengan cepat meledakkan pesan di internet antara dua IP yang bahkan belum berbicara, maka UDP akan tiba setidaknya 3 kali lebih cepat, biasanya 5 kali lebih cepat.

Saya hanya akan menjelaskan semuanya. TCP / UDP adalah dua mobil yang sedang dikendarai di jalan. anggaplah bahwa rambu-rambu lalu lintas & penghalang adalah Kesalahan TCP memperhatikan rambu-rambu lalu lintas, menghargai segala yang ada di sekitarnya. Mengemudi lambat karena sesuatu dapat terjadi pada mobil. Sementara UDP hanya pergi, kecepatan penuh tidak menghormati rambu-rambu jalan. Tidak ada, pengemudi gila. UDP tidak memiliki pemulihan kesalahan, Jika ada hambatan, itu hanya akan berbenturan dengannya kemudian melanjutkan. Sementara TCP memastikan bahwa semua paket dikirim & diterima dengan sempurna, Tidak ada kesalahan, jadi, mobil hanya melewati rintangan tanpa bertabrakan. Saya harap ini adalah contoh yang baik bagi Anda untuk mengerti, Mengapa UDP lebih disukai dalam bermain game. Game membutuhkan kecepatan. TCP lebih disukai dalam unduhan, atau file yang diunduh mungkin rusak.

UDP sedikit lebih cepat dalam pengalaman saya, tetapi tidak banyak. Pilihan tidak harus dibuat pada kinerja tetapi pada konten pesan dan teknik kompresi.

Jika ini protokol dengan pertukaran pesan , saya sarankan kinerja yang sangat kecil yang Anda terima dengan TCP lebih dari sepadan. Anda diberi koneksi antara dua titik akhir yang akan memberi Anda semua yang Anda butuhkan. Jangan mencoba dan membuat protokol dua arah yang andal di atas UDP kecuali Anda benar-benar yakin dengan apa yang Anda lakukan.

Ingatlah bahwa TCP biasanya menyimpan banyak pesan. Jika Anda ingin menerapkan ini di UDP Anda akan memiliki banyak pekerjaan jika Anda ingin melakukannya dengan andal. Solusi Anda akan menjadi kurang dapat diandalkan, kurang cepat atau jumlah pekerjaan yang luar biasa. Ada aplikasi UDP yang valid, tetapi jika Anda mengajukan pertanyaan ini, Anda mungkin tidak.

Ada beberapa pekerjaan yang dilakukan untuk memungkinkan programmer untuk mendapatkan manfaat dari kedua dunia.

SCTP

Ini adalah protolol lapisan transport independen, tetapi dapat digunakan sebagai pustaka yang menyediakan lapisan tambahan di atas UDP. Unit dasar komunikasi adalah pesan (dipetakan ke satu atau lebih paket UDP). Ada kontrol kemacetan bawaan. Protokol ini memiliki kenop dan twiddle untuk dihidupkan

• dalam rangka pengiriman pesan
• transmisi ulang otomatis pesan yang hilang, dengan parameter yang ditentukan pengguna

jika semua ini diperlukan untuk aplikasi khusus Anda.

Salah satu masalah dengan ini adalah bahwa pembentukan koneksi itu rumit (dan karena itu proses lambat)

Hal serupa lainnya

• https://en.wikipedia.org/wiki/R reliable_User_Datagram_Protocol

Satu lagi hal eksperimental eksklusif yang serupa

• https://en.wikipedia.org/wiki/QUIC

Ini juga mencoba untuk meningkatkan pada jabat tangan tripel dari TCP dan mengubah kontrol kemacetan untuk lebih baik berurusan dengan jalur cepat.

Tidak ada artinya berbicara tentang TCP atau UDP tanpa memperhitungkan kondisi jaringan. Jika jaringan antara dua titik memiliki kualitas yang sangat tinggi, UDP benar-benar lebih cepat daripada TCP, tetapi dalam beberapa kasus lain seperti jaringan GPRS, TCP mungkin lebih cepat dan lebih andal daripada UDP.

Pengaturan jaringan sangat penting untuk pengukuran apa pun. Itu membuat perbedaan besar, jika Anda berkomunikasi melalui soket pada mesin lokal Anda atau dengan ujung lain dunia.

Tiga hal yang ingin saya tambahkan ke diskusi:

1. Anda dapat menemukan di sini artikel yang sangat bagus tentang TCP vs UDP dalam konteks pengembangan game.
2. Selain itu, iperf ( jperf meningkatkan iperf dengan GUI) adalah alat yang sangat bagus untuk menjawab pertanyaan Anda sendiri dengan mengukur.
3. Saya menerapkan tolok ukur dalam Python (lihat pertanyaan SO ini ). Rata-rata 10 ^ 6 iterasi perbedaan untuk mengirim 8 byte adalah sekitar 1-2 mikrodetik untuk UDP.