UDP vs TCP, seberapa cepat itu? [Tutup]


194

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


Anda juga dapat menambahkan tag "tcp" karena pertanyaannya juga tentang TCP.
Cristian Ciupitu

5
Apa yang dimaksud dengan "pertukaran pesan protokol umum"? Pertanyaannya perlu mengklarifikasi tentang efisiensi apa. Apakah kami ingin lebih sedikit latensi untuk pesan kecil? Atau, apakah kita ingin throughput yang lebih tinggi untuk aliran data yang berkelanjutan?
Johan Boulé

Tcp memiliki fitur yang lebih baik daripada UDP kecuali Speed.
RAJKUMAR NAGARETHINAM

3
Pertanyaan tentang kecepatan TCP vs. UDP sedang diperdebatkan. Pertanyaan dalam judul Anda sebenarnya tidak cocok dengan isi pertanyaan. Paket TCP dan UDP melakukan perjalanan dengan kecepatan yang persis sama pada media yang sama.
Ron Maupin

Jawaban:


86

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)


19
Sebenarnya ada banyak kasus di mana TCP sebenarnya lebih cepat dari UDP. Lihat jawaban saya di bawah ini.
Robert S. Barnes

2
Yang lebih cepat sepenuhnya tergantung pada karakteristik lalu lintas.

4
Meskipun jawabannya mungkin benar, itu tidak menjawab pertanyaan, dan mengulangi pengetahuan yang disebutkan di tempat lain berulang kali. Juga gagal menyebutkan bahwa metode UDP yang andal dengan ACK bisa lebih cepat dari TCP.
Elliot Woods

268

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


18
Jawaban yang bagus, saya bahkan akan lebih umum lagi, "flow control" (sebagai lawan dari kontrol congestion, yang merupakan subset dari flow control). Tidak hanya beberapa koneksi TCP yang dapat berbagi satu tautan, tetapi itu juga akan mencegah pengirim meluap dari buffer penerima jika mereka berhenti memproses data yang masuk dengan alasan apa pun.
Alex B

1
@ AaronLS: packet loss dan RTT (roundtrip time) meningkat (yang dapat dilihat sebagai proxy untuk penundaan antrian ) adalah / dapat (misalnya: jaringan WiFi dapat kehilangan paket tanpa kemacetan nyata, mengelabui beberapa algoritma kontrol kemacetan TCP menjadi penghindaran kemacetan) indikator kemacetan.
ninjalj

2
UDP adalah bajingan untuk berurusan dengan ... Aku sudah kehabisan ini. Apa pun yang saya lakukan, saya tidak dapat menemukan keseimbangan kinerja, latensi, keluaran, keandalan. Bagus untuk hal-hal real-time seperti hal-hal di timer ... tapi saya sedang mengerjakan penggantian TCP menggunakan UDP dan Forward Error Correction dan ini jauh lebih sulit daripada yang saya pikir akan terjadi. Kontrol kemacetan. Sistem universal yang bekerja pada jaringan 1GB dan jaringan nirkabel semuanya adalah karya seni. Saya merasa seperti saya mencoba merakit kembali paket yang dimuat ke dalam senapan.
Jason Nelson

1
Btw satu lagi dalam mendukung TCP adalah bahwa itu secara inheren berorientasi koneksi, yang sangat menyederhanakan logika penanganan klien aplikasi ( listen-> accept-> keadaan klien secara alami independen dari klien lain). Menangani beberapa koneksi dari satu klien khususnya menjadi sangat sulit dengan UDP. Dan satu hal yang menguntungkan UDP adalah tumpukan UDP sangat mudah diimplementasikan, yang merupakan nilai tambah besar pada sistem embedded (mikrokontroler, FPGA, dll., Khususnya implementasi TCP untuk FPGA umumnya adalah sesuatu yang Anda hanya ingin beli dari orang lain dan tidak memikirkan).
Jason C

1
Ini semua hanya anggapan bahwa kami tertarik pada pengiriman data yang cukup besar (tanpa terlalu peduli tentang latensi). Dalam beberapa aplikasi (game / VoIP), situasi secara drastis berbeda: kita memiliki very_small jumlah data, tapi peduli tentang latency BANYAK; ini adalah hal sederhana yang menyumbang 99% dari penggunaan yang sah untuk UDP. Dan beberapa nitpicks: (a) pengiriman grup TIDAK bekerja melalui Internet (dan tidak akan pernah mungkin), jadi itu adalah ranah khusus Intranet; (B) per Google, hanya 8-9% dari populasi Internet memiliki masalah dengan UDP, (c) "jaringan tidak ramah" tidak berlaku untuk aliran tingkat tetap
No-Bug Hare

93

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


3
Saya sebenarnya telah melakukan tolok ukur untuk efek ini. Saya mengirim paket yang sebesar UDP akan mendukung tanpa membuang pengecualian (di Jawa) dan TCP jauh lebih cepat. Saya kira banyak OS, driver, dan optimasi perangkat keras adalah bagian dari ini juga.
Charlie

14
@ Myforwik: Pertama, ini bukan implementasi yang ditentukan, ini adalah bagian dari protokol TCP Ini disebut algoritma Nagle. Ini membantu mencegah apa yang dikenal sebagai Sindrom Jendela Silly. Cari kedua istilah itu. Kedua, tidak ada konsep paket dari TCP's pov. Terakhir, buku "Pemrograman TCP / IP Efektif" mendedikasikan seluruh bab untuk subjek ini dan beberapa bab lain untuk subjek terkait mengetahui kapan harus menggunakan TCP vs UDP. Saya membahas situasi ini (yang sebenarnya cukup umum) karena OP mengajukan pertanyaan umum, dan ini adalah salah satu dari banyak jawaban yang mungkin.
Robert S. Barnes

46
@Myforwik. Ketika menyarankan moronisme pada orang lain, cobalah untuk menyadari bahwa kita semua memiliki kesenjangan dalam pengetahuan kita - Anda termasuk di dalamnya. SO, bagaimanapun, adalah forum untuk berbagi pengetahuan. Hampir semua penembak orang pertama menggunakan UDP, dan jarang bagi mereka untuk mengirim paket dengan ukuran mendekati MTU. Jika Anda ingin pergi dan menyarankan kepada John Carmack betapa tololnya dia untuk datang dengan pendekatan ini, saya akan mendorong Anda untuk mendidik diri sendiri secara menyeluruh dalam hal ini, pertama. 15 tahun, dan nilai industri dari kode jaringan berkinerja tinggi tidak menyerah dan mati karena Anda pikir itu "gila".
Insinyur

2
" Saya membaca percobaan di mana aliran paket 300 byte dikirim melalui Ethernet (1500 byte MTU) dan TCP 50% lebih cepat dari UDP. " - dapatkah Anda menghubungkan percobaan ini?
Leviathan

3
@Leviathan Ada di dalam buku Pemrograman TCP / IP yang Efektif.
Robert S. Barnes

31

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.


1
5 paket dari 100? Cukup banyak. Saya kira itu hanya sebuah contoh. Pertanyaan: dalam situasi sebenarnya berapa banyak paket yang bisa hilang? Karena jika itu misalnya 2 dari 10.000 (plus minus 1), maka saya tidak akan khawatir tentang itu.
Aneh

1
@ aneh, ya itu hanya contoh. Jumlah sebenarnya dari kehilangan paket tergantung pada koneksi Anda, jaringan hulu, dll. Saya dulu sering bermain game online, dan saya akan menemukan bahwa jika itu hanya saya yang menggunakan koneksi internet, saya tidak akan kehilangan paket, tetapi segera setelah saya meluncurkan unduhan latar belakang, saya akan mulai mendapatkan (mungkin 10% -20%). Ini sekitar 5 tahun yang lalu, dan koneksi internet yang lebih cepat dapat membantu.
Orion Edwards

2
Router internet melepaskan udp sebelum tcp
user1496062

19

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.


2
Ini bukan router yang benar akan menjatuhkan UDP sebelum TCP. Pada kabel bersama Anda bisa tenggelam oleh UDP tetapi apa yang mungkin terjadi dalam situasi kelebihan pasokan tergantung pada teknologi tetapi cukup mudah bagi UDP untuk mendegradasi ke titik sangat sedikit yang dikirim hanya tabrakan.
user1496062

Saya suka penjelasan Anda tetapi tidak mendapatkan satu poin pun. Jika koneksi UDP bisa mendapatkan semua trafik (jika bandwidth rendah atau data tinggi) dalam hal itu aplikasi Anda jika menggunakan TCP pada dasarnya disandera oleh mereka yang menggunakan UDP. Jika semua aplikasi menggunakan TCP maka mereka "bermain bagus" satu sama lain. Lalu mengapa mengizinkan UDP pada rauter?
Igor Čordaš

@PSIXO: Ya, TCP dan UDP melayani kebutuhan aplikasi yang berbeda, sehingga keduanya digunakan oleh aplikasi. Implikasi dari saran Anda adalah bahwa kita harus memiliki infrastruktur jaringan yang berbeda untuk lalu lintas TCP dan UDP - proposisi yang mahal, dan tentu saja bukan sesuatu yang bisa kita lakukan sekarang, terutama dengan semua investasi yang sudah dilakukan. Itu sebabnya para peneliti sibuk mencari cara alternatif untuk menyeimbangkan konflik dalam 'perangkat lunak'.
gjain

Ya intinya ya, memiliki dua infrastruktur akan menjadi solusi yang sempurna tetapi sayangnya itu tidak masuk akal. Apa yang ingin saya katakan dengan komentar saya adalah bahwa Anda melebih-lebihkan hit UDP ke TCP karena jika itu adalah faktor yang tinggi, orang hanya akan menonaktifkan UDP pada router (Seperti yang kadang-kadang mereka lakukan di perusahaan) jika mereka membutuhkan TCP untuk berfungsi dengan cepat. Perlu diingat juga bahwa paket-paket UDP memiliki peluang lebih besar untuk terkulai daripada TCP. Tentang sisa fakta dalam jawaban Anda, saya sepenuhnya setuju dan merasa cukup membantu, tetapi saya pikir Anda terlalu melebih-lebihkan efek tertentu.
Igor Čordaš

18

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


13

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.


Peluang kecil dari kegagalan dan batasan ukuran paket.

11

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


8
UDP juga digunakan karena jika Anda melewatkan satu atau dua paket, mungkin sudah terlambat, dan Anda mungkin lebih baik melewatkannya, dan melanjutkannya sehingga Anda dapat terus menonton. Sedikit kesalahan dalam video karena beberapa paket yang jatuh jauh lebih baik daripada memiliki banyak kemacetan.
Kibbee

1
Benar - multi casting jaringan cukup jarang sebagian besar router memblokirnya.
user1496062

8

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.


1
Ada referensi?
Gerard

8

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.


7

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.


5

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.


5

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

Satu lagi hal eksperimental eksklusif yang serupa

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


3

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.


1

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.

1
Untuk membuat tolok ukur yang relevan dengan Internet dunia nyata, Anda perlu menjalankannya kembali dengan simulator packet loss seperti netem. Jika melakukannya dengan benar (dan dengan simulasi RTT katakanlah 100 ms dan paket loss yang disimulasikan 1%), hasilnya akan berbeda secara drastis. Singkatnya - meskipun latensi TCP dan UDP memang sama untuk nol paket yang hilang - mereka mulai berbeda BANYAK untuk setiap paket yang hilang.
Kelinci Tanpa Hare
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.