Mengapa UDP dengan keandalan (tidak diterapkan pada lapisan Aplikasi) merupakan pengganti TCP?


25

TCP memberikan keandalan pada layer transport sedangkan UDP tidak. Jadi, UDP cepat. Namun, protokol pada lapisan aplikasi dapat menerapkan mekanisme yang dapat diandalkan saat menggunakan UDP.

Dalam pengertian ini, mengapa bukankah UDP dengan reliabilitas (diimplementasikan pada lapisan Aplikasi) pengganti TCP dalam hal bahwa UDP lebih cepat daripada TCP sementara kita membutuhkan keandalan?


6
Mengapa setiap aplikasi menyediakan mekanisme reliabilitasnya sendiri ketika mereka hanya bisa mengandalkan protokol lain yang tersedia secara luas seperti TCP?
Nakrule

14
dan bagaimana Anda mengusulkan untuk menerapkan keandalan pada lapisan aplikasi tanpa memperlambat stack?
JFL

6
" Karena header UDP lebih kecil dari TCP, kita dapat mengambil keuntungan dari ukuran data. " Masalah dengan pemikiran itu adalah bahwa Anda mungkin akan makan banyak muatan UDP dengan header protokol lapisan aplikasi yang akan mengurangi data yang dapat digunakan di Muatan UDP. Perbedaan antara ukuran header TCP dan UDP hanya 12 byte. Juga, UDP benar-benar dirancang untuk muatan kecil, misalnya 576 byte; ingat bahwa UDP hanya akan kehilangan datagram, dan semakin banyak data dalam datagram, semakin banyak data yang hilang ketika datagram hilang.
Ron Maupin

21
Stack Overflow penuh dengan programmer yang mencoba, dan gagal, untuk membuat protokol mirip TCP menggunakan UDP. Pemrogram yang lebih berpengalaman memberi tahu mereka untuk menyerah dan hanya menggunakan TCP. Mereka semua berpikir bahwa mereka dapat melakukan pekerjaan yang lebih baik, tetapi sangat tidak mungkin.
Ron Maupin

11
Saya tahu ini bukan bagian dari pertanyaan Anda secara langsung, tetapi salah satu alasan UDP bisa lebih baik adalah Anda hanya dapat mengimplementasikan bagian keandalan yang Anda butuhkan. Dengan TCP Anda mendapatkan keandalan tentang pemesanan dan pengiriman. Ini berarti TCP dapat memiliki cegukan sementara menunggu pesan sebelumnya dikirim ulang. Dengan UDP Anda dapat memutuskan semua yang Anda inginkan adalah pengiriman, tetapi jika ada pesan yang keluar dari pesanan, Anda tidak menunggu yang hilang, Anda hanya membuangnya. Orang-orang yang terjebak dalam perangkap mencoba mereplikasi TCP 100%. Dalam hal ini, cukup gunakan TCP.
William Mariager

Jawaban:


47

TCP adalah secepat Anda dapat membuat sesuatu dengan properti keandalannya. Jika Anda hanya perlu, katakanlah, pengurutan dan deteksi kesalahan, UDP dapat dibuat untuk melayani dengan sangat baik. Ini adalah dasar untuk sebagian besar protokol waktu nyata seperti suara, streaming video dll, di mana lag dan jitter lebih penting daripada koreksi kesalahan "absolut".

Pada dasarnya, TCP mengatakan stream-nya bisa diandalkan pada akhirnya. Seberapa cepat itu tergantung pada berbagai penghitung waktu, kecepatan, dll. Waktu yang dibutuhkan untuk menyelesaikan kesalahan bisa tidak dapat diprediksi, tetapi operasi dasar secepat mungkin ketika tidak ada kesalahan. Jika suatu sistem mengetahui sesuatu tentang jenis kesalahan yang mungkin terjadi, ia mungkin dapat melakukan sesuatu yang tidak mungkin dilakukan dengan TCP. Misalnya, jika kesalahan bit tunggal sangat mungkin terjadi, Anda dapat menggunakan pengkodean koreksi kesalahan untuk kesalahan bit tersebut: namun, ini jauh lebih baik diimplementasikan di lapisan tautan. Sebagai contoh lain, jika ledakan singkat dari kehilangan seluruh paket adalah umum, Anda dapat mengatasinya dengan beberapa transmisi tanpa menunggu kehilangan, tetapi jelas ini mahal dalam bandwidth. Atau sebagai alternatif, memperlambat kecepatan hingga probabilitas kesalahan diabaikan: bandwidth juga mahal. Pada akhirnya,

Dalam istilah implementasi, Anda akan menemukan bahwa programmer-abad yang berinvestasi dalam TCP akan membuatnya lebih cepat daripada apa pun yang Anda mampu lakukan secara umum, serta lebih dapat diandalkan dalam kasus tepi yang tidak jelas.

TCP menyediakan: metode koneksi di mana-mana (penting di mana sistem komunikasi tidak memiliki kontrol bersama) yang memberikan aliran yang dapat diandalkan, dipesan, (dan diduplikasi), aliran dua arah, berjendela, byte dengan kontrol kemacetan melalui jaringan multi-hop sewenang-wenang.

Jika suatu aplikasi tidak memerlukan di mana-mana (perangkat lunak Anda berjalan di kedua sisi), atau tidak memerlukan semua fitur TCP, banyak orang secara menguntungkan menggunakan protokol lain, sering kali di atas UDP. Contohnya termasuk TFTP (minimalis, dengan penanganan kesalahan yang benar-benar tidak efisien, QUIC yang dirancang untuk mengurangi biaya overhead (masih ditandai sebagai eksperimental), dan perpustakaan seperti lidgren, yang memiliki kendali ketat atas fitur keandalan yang diperlukan. [Terima kasih komentator. ]


7
Protokol "UDP dengan keandalan" kustom juga sangat umum di permainan video. Ada banyak perpustakaan jaringan dengan berbagai implementasi. Mereka biasanya ingin paket dipesan dan mengalami koreksi kesalahan, tanpa menginginkan pengiriman ulang paket yang hilang (dan menerima penundaan semua paket yang akan datang).
BlueRaja - Danny Pflughoeft

Kedengarannya seperti Anda mengatakan "TCP adalah solusi umum yang optimal, jadi itu membuatnya untuk mendukungnya secara asli". +1
ikegami

1
@ BlueRaja-DannyPflughoeft Dan kadang-kadang Anda ingin paket unordered yang andal (mis. Efek visual diterapkan pada pemain terdekat).
user253751

@ BlueRaja-DannyPflughoeft jika Anda memiliki contoh perpustakaan protokol yang khas, saya akan dengan senang hati memasukkannya ke dalam jawaban
jonathanjo

1
@jonathanjo Satu yang saya gunakan adalah lidgren , yang mendukung 5 metode pengiriman yang berbeda (gulir ke bawah) . Unity dan Unreal Engine juga memiliki API jaringan mereka sendiri yang dibangun di atas UDP.
BlueRaja - Danny Pflughoeft

10

UDP dengan reliabilitas memang bisa menjadi pengganti TCP. Kami sudah memiliki contoh: disebut QUIC .

Dari Wikipedia:

Di antara aplikasi lain, QUIC meningkatkan kinerja aplikasi web berorientasi koneksi yang saat ini menggunakan TCP. Ini dilakukan dengan membuat sejumlah koneksi multiplexing antara dua titik akhir melalui User Datagram Protocol (UDP).

Keuntungan menggunakan UDP dibandingkan membuat protokol transport-layer baru adalah bahwa router dan perangkat jaringan lainnya sudah memahaminya.


QUIC memiliki karakteristik yang sedikit berbeda dari TCP. Dalam beberapa skenario (jaringan yang andal atau tidak memerlukan enkripsi) sebenarnya lebih lambat: quora.com/...
freakish

Anda juga bisa menambahkan databannel WebRTC ke daftar yang menggunakan UDP melalui sctp. Bahkan, ketika koneksi UDP tidak memungkinkan antara rekan-rekan WebRTC akan gagal ke TCP meninggalkan penurunan kinerja yang nyata.
JSON

@freakish lebih lambat adalah generalisasi dalam kasus ini. Misalnya QUIC menambahkan data tambahan ke paket-paket untuk mengurangi pengiriman ulang yang memengaruhi throughput tetapi bukan latensi.
JSON

4

Anda bisa menggunakan UDP untuk mengimplementasikan fungsionalitas TCP pada lapisan aplikasi (keandalan, kemampuan beradaptasi). Anda bisa menggunakan TCP di tempat pertama kecuali jika sesuatu aplikasi Anda benar-benar perlu tidak dapat dilakukan dengan TCP. Jika Anda menerapkan fungsi-fungsi itu sendiri, Anda kemungkinan besar berakhir jauh lebih buruk daripada dengan TCP. Biaya tambahan yang ditambahkan mengurangi efisiensi keseluruhan juga.

TCP tidak lambat - hanya diperlukan jabat tangan sebelum mentransmisikan dan jendela transmisi untuk beradaptasi dengan saluran. Ia dapat dengan baik membentuk throughputnya ke saluran transmisi yang ada dan beradaptasi dengan perubahan selama aliran, yang semuanya tidak dapat dilakukan oleh UDP (dengan sendirinya).

Namun, protokol di atas layer transport di luar topik di sini.


3
"Anda dapat menggunakan UDP untuk mengimplementasikan fungsionalitas TCP pada lapisan aplikasi (keandalan, kemampuan beradaptasi)" - Saya percaya bahwa secara praktis bagaimana QUIC, μTP, dan seringkali SCTP sudah diterapkan. (Meskipun begitu, saya biasanya menganggap mereka berada di bagian atas lapisan transport, sementara UDP duduk di bagian bawah.)
grawity

1
@grawity Itu tergantung pada POV Anda - dari perspektif aplikasi, lapisan perantara adalah ekstensi dari lapisan transport. Secara formal dan dari perspektif jaringan (perangkat), itu semua adalah bagian dari lapisan aplikasi.
Zac67

4

Pada jaringan yang bersih, mereka cukup setara. Ada kasus-kasus di mana TCP akan hang untuk periode (Siapa pun yang pernah melihat layar HTTP membeku saat dimuat?) Tetapi tidak akan mengirimkan sampah atau mencampur paket dan jarang menyerah sepenuhnya.

UDP dapat memberikan lapisan aplikasi kontrol lebih besar atas lalu lintas dengan biaya banyak pekerjaan.

Jawaban untuk pertanyaan Anda adalah, kadang-kadang dilakukan seperti itu. Game yang membutuhkan latensi rendah sering melakukan hal itu. Ini jauh lebih banyak pekerjaan, tetapi kemampuan untuk mengontrol dengan tepat berapa banyak paket luar biasa yang dapat Anda miliki dan seberapa sering mereka dicoba sering sepadan.

Jadi secara keseluruhan perbedaannya adalah bahwa TCP adalah implementasi tujuan umum yang sangat baik, tetapi ada tujuan khusus yang dapat dilakukan UDP agar TCP melakukan sangat buruk atau tidak sama sekali - misalnya:

  • TIDAK PERNAH menyerah (dengan TCP koneksi terkadang hang dan Anda harus memutuskan koneksi dan restart)
  • Mengirim paket dengan aliran cepat yang tidak memerlukan balasan dan Anda tidak keberatan melewatkannya sesekali (di mana hanya paket terbaru yang penting, yang lain dapat dibuang) - pikirkan pembaruan posisi permainan - Anda mungkin mendapat sedikit "Lompat" daripada setiap langkah, tetapi Anda mendapatkan hasil yang sama lebih cepat dan lebih andal.
  • Berurusan dengan jaringan yang rapuh dengan menganalisis penurunan paket dan secara dinamis mengubah seberapa sering dan seberapa cepat Anda mencoba lagi - bahkan mungkin ukuran paket maksimal.

Tetapi secara umum itu tidak layak, TCP cukup optimal jadi mengapa pergi ke semua pekerjaan ekstra dan menambahkan (besar) peluang untuk menambahkan bug dan kelemahan keamanan?


3

UDP tidak cepat karena itu adalah UDP. TCP tidak lambat karena itu TCP.

Kedua protokol dirancang dengan jaminan tertentu dan TCP mentah memiliki lebih banyak jaminan daripada UDP mentah.

Dan aturan praktisnya adalah: harga untuk jaminan adalah kinerja .

Tidak ada yang melarang Anda menerapkan jaminan TCP melalui UDP. Tetapi kemudian Anda mendapatkan lebih banyak jaminan sehingga Anda harus membayar harganya. Karenanya Anda mengurangi kinerja ke TCP atau lebih buruk (karena overhead UDP). Kecuali Anda tahu implementasi TCP yang lebih baik, yang tidak mungkin. Dan jika Anda melakukannya (harap-harap) Anda mengungkapkannya dan kami membuat standar TCP lebih cepat. Dan kita kembali ke tempat kita mulai. :)

Anda bisa bermain dengan jaminan itu juga. Sedikit modifikasi ini, sedikit modifikasi itu. Dan kemudian Anda berakhir dengan protokol seperti QUIC yang lebih dari UDP dan sangat mirip dengan TCP + TLS. Dalam banyak kasus lebih cepat dari TCP (walaupun menurut artikel ini latensi hingga 5% dan buffering hingga 15% yang IMO bukan masalah besar) tetapi dalam beberapa skenario (misalnya jaringan yang dapat diandalkan atau tidak perlu enkripsi) sebenarnya lebih lambat (lihat penjelasan di sini ).

Anda juga bisa melemahkan jaminan itu dan kemudian lebih masuk akal. Misalnya, Anda streaming dan paket lama tidak menarik. Hanya yang terbaru. Namun kemacetan masih penting. Jadi Anda mengambil beberapa jaminan dari TCP, tetapi tidak semua. Dan ya, orang benar-benar melakukan itu (misalnya game waktu nyata). Ini memberi Anda kinerja yang lebih baik dengan mengorbankan sejumlah jaminan.


1

Ide Anda akan bagus di luar angkasa.

Jawaban yang benar adalah "itu tergantung" dan "karena itu akan merusak jaringan secara keseluruhan". TCP / IP sangat baik untuk jaringan dan secara otomatis menyesuaikan kecepatan yang tepat untuk menjadi cepat tetapi tidak menghasilkan ton paket pengembalian ICMP.

Ketika sebuah router dengan RAM yang tidak mencukupi tiba-tiba menerima banyak paket apa pun - katakanlah dari Tsunami, Bittorrent atau FDT - itu menjatuhkannya dan menembak kembali ke pengirim sebuah paket kecil yang tidak dikenal. Sekarang server UDP Anda harus melacak dan mengirim kembali bagian itu secara manual. Beberapa router ISP membentuk Bittorrent sehingga ini menyakitkan Tsunami?

Protokol Tsunami menggunakan UDP dengan saluran kontrol dalam TCP. http://tsunami-udp.sourceforge.net/ Saya menemukan sebuah studi yang menunjukkan lebih lambat daripada sesuatu yang disebut FDT.

Protokol Fast Data Transfer (FDT) yang legendaris dari CERN mampu menjenuhkan jaringan apa pun menggunakan beberapa aliran TCP. Mungkin lebih cepat, karena menyebabkan transmisi ulang yang lebih sedikit daripada Tsunami, yang membanjiri jaringan dengan begitu banyak UDP, beberapa di antaranya tidak membuat semuanya melintas.

UDP digunakan oleh aplikasi yang tidak dapat diandalkan: streaming audio, input game / pembaruan IO, "ping" sebenarnya ICMP tetapi tidak dijamin, Bittorrent, mosh ssh sangat responsif, telepon VOIP, multicast, DNS dikirim melalui UDP AFAIK. Apa pun yang tidak keberatan dengan paket aneh yang hilang dan dapat "ditangkap" secara instan.

TCP / IP benar-benar penemuan pembunuh yang memungkinkan pengembang aplikasi jadi atur dan lupakan saja. Soket adalah sepasang alamat IP dan port, dan dirancang untuk dapat diatur dan tetap selama berjam-jam, berhari-hari, bahkan berminggu-minggu tanpa menghubungkan kembali. Email, web, IRC dan secara harfiah semua aplikasi pembunuh menggunakan TCP. Tapi Anda bisa mendapatkan jeda yang aneh dalam unduhan yang tiba-tiba berjalan lebih cepat ... dan di ruang angkasa yang dalam, sambungan mungkin akan habis waktu sehingga transfer gaya Tsunami terbaik untuk transfer file antarbintang - Anda mungkin menemukan sesuatu di sana !!

Buktinya ada dalam pernyataan terakhir dari ekstrak studi sains ini, yang menyebutkan semakin meningkatnya jarak yang saya lakukan tentang re: deep space From: https://uscholar.univie.ac.at/get/o:300623.pdf

Tanpa kemacetan, kinerja FDT dan GridFTP dengan TCP lebih tinggi dari Tsunami dan UDT. Output FDT tertinggi adalah 2,34 Gb / s dengan RTT 1 ms tetapi menurun dengan cepat setelah 100 ms dibandingkan dengan GridFTP, yang berkinerja lebih baik daripada FDT ketika link RTT lebih panjang dari 100 ms. Menariknya, throughput Tsunami tidak berkurang seiring meningkatnya RTT, menunjukkan bahwa ia memiliki kontrol kemacetan paling efektif dengan meningkatnya RTT.

Kemudian lagi ... sebenarnya ada protokol ruang yang sangat mirip email yang akan lebih baik untuk ruang. Aplikasi harus tidak mempermasalahkan nilai batas waktu seperti selamanya.


0

TCP! = Keandalan UDP +

TCP bukan hanya UDP dengan keandalan yang ditambahkan. TCP menawarkan lebih banyak fitur daripada sekadar keandalan. Anda dapat membacanya di banyak RFC.

Semua fitur ini "dapat" diimplementasikan pada lapisan aplikasi. Akhirnya ada titik di mana Anda mulai menemukan kembali roda.

Untuk menyebutkan beberapa fitur, TCP memiliki ...

  • Pembuatan dan pemutusan koneksi: melakukan jabat tangan dan penutupan koneksi

  • Kontrol Aliran: memastikan pengirim dan penerima mengirim dengan kecepatan di mana keduanya dapat menangani kecepatan data.

  • Kontrol kemacetan ujung ke ujung: memungkinkan node akhir untuk membatasi throughput mereka berdasarkan kerugian. Baca tentang mulai lambat, penghindaran kemacetan, dan pemulihan cepat.

Dalam pengalaman saya, UDP digunakan ketika kecepatan adalah masalah keandalan. Anda dapat menambahkan beberapa tingkat keandalan pada tingkat aplikasi yang tidak 100% dapat diandalkan seperti TCP. Misalnya jika Anda masih menginginkan kinerja cepat, Anda dapat menerapkan koreksi kesalahan maju (FEC) di mana Anda mengirimkan data lebih dari sekali. Anda masih mendapatkan kinerja yang baik dan beberapa tingkat keandalan (catat keandalan TCP) tanpa semua bolak-balik obrolan untuk mendapatkan paket yang hilang. Perdagangan adalah bahwa hal itu meningkatkan pemanfaatan jaringan tetapi mungkin cocok untuk aplikasi waktu nyata seperti game atau streaming.


Anda bisa menggambarkan pada fitur-fitur tambahan itu sebagai soal keandalan, pada akhirnya.
user207421
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.