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

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?

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

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.

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.

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?

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.

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.

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.