Apakah UDP masih lebih baik dari TCP untuk game realtime yang berat data?

Saya tahu bahwa UDP biasanya direkomendasikan untuk game multipemain waktu nyata dengan penggunaan data tinggi.

Sebagian besar artikel berumur bertahun-tahun, dan karena ~ 80% dari semua data yang dikirimkan di internet adalah TCP, banyak optimasi yang harus dilakukan untuk TCP.

Ini membuat saya bertanya-tanya: apakah UDP masih unggul dalam hal kecepatan dan latensi? Mungkinkah optimasi TCP baru-baru ini membuat TCP berkinerja lebih baik daripada UDP?

Tidak, UDP masih lebih unggul dalam hal latensi kinerja , dan akan selalu lebih cepat, karena filosofi dari 2 protokol - dengan asumsi data komunikasi Anda dirancang dengan UDP atau komunikasi lainnya yang merugi.

TCP membuat abstraksi di mana semua paket jaringan tiba, dan mereka tiba dalam urutan yang tepat di mana mereka dikirim. Untuk mengimplementasikan abstraksi pada saluran lossy, ia harus menerapkan transmisi ulang dan waktu habis, yang menghabiskan waktu. Jika Anda mengirim 2 pembaruan pada TCP, dan paket pembaruan pertama hilang, Anda tidak akan melihat pembaruan kedua hingga:

1. Hilangnya pembaruan pertama terdeteksi.
2. Diperlukan pengiriman ulang pembaruan pertama.
3. pengiriman ulang telah tiba dan telah diproses.

Tidak masalah seberapa cepat ini dilakukan dalam TCP, karena dengan UDP Anda cukup membuang pembaruan pertama dan gunakan yang kedua, yang lebih baru, sekarang. Tidak seperti TCP, UDP tidak menjamin bahwa semua paket tiba dan itu tidak menjamin bahwa mereka tiba secara berurutan.

Ini mengharuskan Anda untuk mengirim jenis data yang tepat, dan merancang komunikasi Anda sedemikian rupa sehingga kehilangan data dapat diterima.

Jika Anda memiliki data di mana setiap paket harus tiba, dan paket-paket itu harus diproses oleh gim Anda sesuai urutan pengirimannya, maka UDP tidak akan lebih cepat. Sebenarnya menggunakan UDP dalam hal ini kemungkinan akan lebih lambat karena Anda merekonstruksi TCP dan mengimplementasikannya dengan menggunakan UDP dalam hal ini Anda mungkin juga menggunakan TCP.

EDIT - Menambahkan beberapa informasi tambahan untuk memasukkan / mengatasi beberapa komentar:

Biasanya, tingkat kehilangan paket pada Ethernet sangat rendah, tetapi menjadi jauh lebih tinggi begitu WiFi terlibat atau jika pengguna memiliki unggahan / unduhan yang sedang berlangsung. Mari kita asumsikan kita memiliki paket loss yang seragam sempurna sebesar 0,01% (satu arah, bukan pulang pergi). Pada penembak orang pertama, klien harus mengirim pembaruan setiap kali terjadi sesuatu, seperti ketika kursor mouse memutar pemain, yang terjadi sekitar 20 kali per detik. Mereka juga dapat mengirim pembaruan per frame atau pada interval tetap, yang akan menjadi 60-120 pembaruan per detik. Karena pembaruan ini dikirim pada waktu yang berbeda, mereka akan / harus dikirim dalam satu paket per pembaruan. Pada permainan 16 pemain, semua 16 pemain mengirim 20-120 paket per detik ini ke server, menghasilkan total 320-1920 paket per detik. Dengan tingkat kehilangan paket sebesar 0,01%, kami memperkirakan akan kehilangan satu paket setiap 5,2-31,25 detik.

Pada setiap paket yang kami terima setelah paket yang hilang, kami akan mengirim DupAck, dan setelah DupAck ke-3 pengirim akan mengirim ulang paket yang hilang . Jadi waktu yang diperlukan TCP untuk memulai pengiriman ulang adalah 3 paket, ditambah waktu yang diperlukan untuk DupAck terakhir untuk sampai di pengirim. Maka kita perlu menunggu pengiriman ulang tiba, jadi secara total kita menunggu 3 paket + 1 latensi pulang pergi. Latensi pulang-pergi biasanya 0-1 ms di jaringan lokal dan 50-200 ms di internet. 3 paket biasanya akan tiba dalam 25 ms jika kami mengirim 120 paket per detik, dan dalam 150 ms jika kami mengirim 20 paket per detik.

Sebaliknya, dengan UDP kami pulih dari paket yang hilang segera setelah kami mendapatkan paket berikutnya, jadi kami kehilangan 8,3 ms jika kami mengirim 120 paket per detik, dan 50 ms jika kami mengirim 20 paket per detik.

Dengan hal-hal TCP menjadi berantakan jika kita juga perlu mempertimbangkan Nagle (jika pengembang lupa untuk mematikan mengirim penggabungan, atau tidak dapat menonaktifkan ACK yang tertunda ), penghindaran kemacetan jaringan , atau jika kehilangan paket cukup buruk sehingga kita harus memperhitungkan beberapa packet loss (termasuk kehilangan Ack dan DupAck). Dengan UDP kita dapat dengan mudah menulis kode lebih cepat karena kita tidak peduli menjadi warga jaringan yang baik seperti TCP.

Kami menyetujui TCP dan UDP sebagai protokol yang dibangun di atas IP , bukan? IP menentukan bagaimana pesan dikirim di internet, tetapi tidak ada yang tentang struktur pesan, format. Di sinilah protokol TCP dan UDP. Mereka menggunakan properti IP, tetapi membiarkan programmer fokus pada pertukaran pesan tanpa khawatir tentang lapisan bawah dari komunikasi internet. Dan itu hebat, karena berurusan dengan sinyal analog di kabel secara langsung akan agak menyakitkan.

• TCP menyediakan serangkaian fungsi untuk mengirim dan menerima pesan. Ini membagi data kami menjadi paket kecil untuk kami sendiri dan mengirimkannya ke seluruh jaringan. Yang kami minta hanyalah port yang digunakan untuk soket internet, dan pesan sebenarnya yang ingin kami kirim. Selain itu, dapat diandalkan, artinya jika beberapa paket hilang di sepanjang jaringan yang terdeteksi, maka dikirim lagi dengan hati-hati mengirimkannya dalam urutan yang sama dengan saat mereka seharusnya tiba.

• Di sisi lain, UDP adalah protokol yang berorientasi pada kontrol pengguna. Ketika menggunakan UDP untuk mengirim datagram kami , kami tidak dapat memastikan apakah datagram akan pernah sampai di tujuan atau tidak (dan kami maksud kepastian matematis di sini: ketika kami mengirim paket itu mungkin akan tiba, tetapi kami tidak dapat memastikan pada 100%). Juga, ketika suatu paket hilang itu tidak akan terdeteksi atau dikirim lagi.

Pada titik ini, TCP akan terlihat seperti solusi ideal untuk semua masalah kita. Ini dapat diandalkan, cepat, ini memecahkan latensi koneksi bagi kami dengan melacak paket apa yang tiba dan paket apa yang masih perlu kami kirim.

TAPI , lihat ke luar. Satu-satunya keuntungan yang diberikan UDP kepada kami adalah kecepatannya, dan itu benar satu hal yang kami inginkan. Paket UDP hanya dibuat, dicek dan dikirim tanpa kontrol khusus, karena itulah cara kerja protokol UDP. Paket TCP harus dibuat, diberi label, dicentang, dan ketika tiba, ACK dikirim kembali untuk memberi tahu pengirim "paket x ada di sini," lanjutkan, dan ketika sinyal ini tidak dikirim maka itu berarti paket x tersebut harus dikirim lagi.

Saya tahu bahwa UDP biasanya direkomendasikan untuk game multipemain waktu nyata dengan penggunaan data tinggi.

Ya, tetapi tidak hanya. UDP lebih disukai daripada TCP terutama karena kecepatan tinggi adalah ide untuk menangani pengiriman dan manajemen data yang tinggi. Ini terjadi ketika, dengan asumsi videogame berjalan pada langkah deterministik (apa yang terjadi pada server direplikasi secara identik pada setiap klien terlepas dari latensi jaringan), paket pembaruan hilang dan tidak pernah sampai ke tujuannya. TCP akan mengirim ulang paket seperti itu, dan paket-paket berikut dijatuhkan karena tiba tidak berurutan, dan kemudian dikirim kembali setelah yang hilang. UDP jauh lebih toleran dalam skenario ini: tidak akan peduli dengan paket ini, karena pembaruan yang lebih baru akan datang. Pembaruan yang hilang tidak diberikan, melainkan fisika game diinterpolasikan dengan metode integrasi yang digunakan dan pembaruan terakhir diterima.

TCP menyebabkan jittering ketika latensi cukup tinggi, UDP tidak:

<video style="min-width: 100% height: auto" autoplay="" preload="auto" loop="true"><source src="https://gafferongames.com/videos/deterministic_lockstep_tcp_250ms_5pc.mp4" type="video/mp4"><source src="http://173.255.195.190/cubes_deterministic_lockstep_tcp_250ms_5pc.webm" type="video/webm">Your browser does not support the video tag.</video>

Ini membuat saya bertanya-tanya apakah UDP masih unggul dalam hal kecepatan dan latensi.

Ya, benar dan akan lama . Anda dapat membaca lebih lanjut tentang TCP vs UDP di sini .

TCP <- Protokol Kontrol Transmisi . Itu dibuat untuk mengontrol transmisi.

TCP diciptakan untuk menjadi warga jaringan yang baik dan diplomatik. Ini berfokus pada membuat jaringan pengalaman yang baik untuk semua orang, dan dengan rela mengurangi throughput untuk mencapai itu. Ini menyesuaikan dengan lingkungan dengan menambahkan latensi . Alasannya misalnya:

• Penerima mendeteksi paket yang hilang, memberi tahu pengirim untuk memperlambat (membagi dua tarif untuk sementara waktu).
• Penerima mendeteksi urutan paket masuk yang salah (mungkin mereka mengambil jalur jaringan yang berbeda), memberi tahu pengirim untuk memperlambat - dan, penerima tidak akan menerima paket lebih lanjut sampai yang hilang masuk. Menangani ini membutuhkan waktu.
• Pengirim mendeteksi kemacetan jaringan (mis. Waktu pulang-pergi yang lambat), menambah latensi.
• Penerima tidak dapat mengikuti kecepatan (buffer input terlalu penuh), meminta pengirim untuk menambahkan latensi (kontrol aliran).
• Ada penerima lambat tunggal (bajingan ping tinggi, crybaby, apa namanya) di antara penerima, latensi (mungkin) ditambahkan dalam rumah tangga.

Selain itu

• Algoritma Nagle dapat menahan data pengirim, sampai ada lebih banyak untuk dikirim (untuk memanfaatkan bingkai data lebih efisien). Data penting waktu tertunda.
• Saya percaya router rumahan biasa dengan wlan dapat melakukan hal-hal cerdas (melambat) untuk memperlancar throughput TCP antara banyak klien (antarmuka wlan menjadi penghambat, bahkan jika game tidak menggunakannya). Berkaitan dengan penyiaran / multicasting, yaitu. Data "lain" dapat mengurangi throughput TCP Anda.
• TCP ACKnowledges semuanya, yang tidak perlu untuk lingkungan gaming. Tidak ada gunanya dalam ACKing setiap pembaruan fisika tunggal. Cukup untuk mengakui misalnya sekali per detik, atau serupa. Jika klien (atau server) diam untuk waktu yang lebih lama, maka inilah saatnya untuk bereaksi.

Meskipun demikian, TCP memberikan angka tertinggi untuk (data yang ditransmisikan secara keseluruhan) / (keseluruhan waktu yang dikonsumsi). Hanya saja itu tidak terjadi tepat ketika Anda menginginkannya terjadi.

UDP tidak melakukan ini. Itu menyala atas kehendak Anda , hanya saja orang tidak bisa berharap untuk memukul setiap kali - insead target harus mengumumkan bahwa "Anda tidak menembak dalam waktu yang lama, mengapa?" Anda masih dapat membuat paket ACK kustom sendiri, meletakkan beberapa catatan dalam satu paket, dll. Dan juga yang penting, mengontrol NAT traversal. UDP sangat cocok untuk gim dengan permintaan latensi rendah.

Anda dapat membandingkan diagram pertama RFC 768 (UDP) dengan diagram pertama RFCP 793 (TCP) halaman 15 .

Keduanya menunjukkan 16 bit untuk "port sumber" diikuti oleh 16 bit untuk "port tujuan". Keduanya menunjukkan 16 bit untuk "checksum". Menurut RFC 768, "prosedur checksum UDP sama dengan yang digunakan dalam TCP."

Sedangkan Panjang UDP merangkum detail diagram UDP, panjang TCP adalah bagian dari “header pseudo 96 bit” yang dijelaskan pada halaman 15 dan 16.

Jangan berharap TCP mengungguli UDP. Itu tidak mungkin terjadi, karena berbagai alasan. Salah satunya adalah TCP hanya memiliki lebih banyak bit. Jadi, jika peralatan dapat secara efektif memproses sejumlah bit per detik, itu akan memungkinkan lebih banyak paket UDP daripada paket TCP.

Alasan lainnya adalah bahwa "jabat tangan tiga arah" TCP berarti bahwa pengirim harus menunggu jawaban. Persyaratan ini memperkenalkan overhead tambahan yang tidak ditangani oleh UDP. Ada alasan mengapa sebagian besar komunikasi Internet Anda dimulai dengan komunikasi UDP. DNS dasar menggunakan UDP karena permintaan dan respons dapat diselesaikan dalam beberapa langkah lebih sedikit daripada proses "jabat tangan" TCP. Fitur TCP untuk melacak paket yang hilang agak tidak menyenangkan, karena komputer hanya dapat membuat permintaan baru daripada mencoba membiarkan sistem jarak jauh tahu bahwa ada permintaan sebelumnya yang tidak terpenuhi.

Pertimbangkan apa yang terjadi sejenak. Untuk menyederhanakan skenario, Anda memiliki dua pilihan ketika mencoba mengirim perubahan negara (seperti pemain Anda baru saja mengubah arah, atau menembakkan pistol, atau pemain lain hanya mengeluarkan bom):

1. Tetap buka sesi TCP, dan ketika bom meledak, kirim pesan TCP ke semua pemain (jika mungkin, lihat di bawah)
2. Tetap dengarkan port UDP, dan ketika bomnya padam, kirim pesan UDP ke semua pemain, apa pun kondisinya

Dengan asumsi tidak ada pembaruan yang diperlukan sebelum itu, waktu ketika pembaruan tunggal itu tiba dalam 1 vs 2 tidak akan sangat berbeda. Ini satu perjalanan dari server ke klien. Tetapi, katakanlah, alih-alih hanya bom yang meledak, Anda mencoba untuk terus menyampaikan aktivitas seseorang yang berlari melalui labirin; menenun, merunduk, menembak, dll. Dalam kasus UDP, setiap tindakan akan dikirim dalam datagram, segera setelah itu terjadi. Dalam kasus TCP setiap tindakan akan dikirim dalam satu paket hanya jika server diizinkan untuk mengirim. Apa yang dikatakan boleh dikirim? Memiliki ruang di jendela TCP (dengan anggapan ack tertunda aktif) sehingga pesan dapat diletakkan di kawat. Jika tidak, ia harus menunggu ACK tiba dari klien sebelum mengirim.

Seberapa lamakah sangat lama itu? Ketika pengembangan multiplayer first person shooter melaju kembali pada akhir 90-an dan awal 2000-an koneksi latensi rendah tidak umum. Modem dialup akan memiliki latensi satu arah tipikal 180ms. Menunggu ack sebelum mengirim pembaruan lain, secara efektif menggandakan waktu itu menjadi 360ms, sangat menyakitkan; bahkan pengguna pemula pasti bisa merasakan perbedaannya. Ketika koneksi broadband tertangkap, mereka membuat latensi turun banyak tetapi masih bertahan saat bandwidth terbatas (cukup sering di beberapa daerah). Jadi preferensi untuk latensi serendah mungkin tetap ada.

Koneksi rumah modern dan interkoneksi telah mengubah ini, ke titik di mana latensi regional, bahkan selama waktu yang padat, berada dalam kisaran 15 ms atau di bawah kisaran. Memilih TCP alih-alih UDP tidak akan terlihat dalam banyak kasus, karena latensi "cukup rendah". Namun, masih ada kecenderungan UDP untuk diprioritaskan daripada TCP mengingat sejarahnya sebagai protokol latensi rendah. Jadi, untuk saat ini (dan mungkin beberapa waktu ke depan) UDP akan lebih disukai untuk komunikasi waktu nyata.

Saya tahu bahwa UDP biasanya direkomendasikan untuk game multipemain real-time dengan penggunaan data tinggi
Apakah UDP masih unggul dalam hal kecepatan dan latensi? Mungkinkah optimasi TCP baru-baru ini membuat TCP berkinerja lebih baik daripada UDP?

Asumsi Anda salah. TCP dan UDP berbeda terutama dalam model apa yang mereka wakili (datagram tidak dapat diandalkan versus aliran virtual andal yang sesuai pesanan).

Mereka tidak berbeda dalam hal volume ("penggunaan data tinggi") atau throughput. TCP akan mendorong sebanyak data sebanyak UDP, itu akan dengan mudah menjenuhkan kabel fisik.

Di hadapan hilangnya paket, keduanya memang berbeda dalam latensi, tetapi hanya dalam kondisi itu. Jika tidak, TCP memiliki latensi serendah UDP (memberi atau menerima mungkin beberapa lusin nanodetik karena tumpukan jaringan memiliki sedikit lebih banyak logika untuk dilakukan, tetapi itu agak dapat diabaikan).
Ada sedikit perbedaan dalam ukuran tajuk, jadi secara teknis, lebih banyak byte harus membuatnya melalui kabel pada garis serial, tetapi yang satu juga agak tidak penting. Itu hanya sangat penting untuk transfer massal, dan kemudian perbedaannya sekitar 0,5%. Kebanyakan orang dengan akses internet DSL rumah merutekan semua lalu lintas mereka melalui ATM yang menambahkan lebih dari 10% protokol overhead (5 byte kontrol untuk 48 byte payload, ditambah frame parsial), dan tidak ada yang memperhatikan.

Beberapa orang membangun keandalan di atas UDP. Jika beberapa tingkat keandalan diinginkan, tetapi pengiriman dalam urutan yang ketat tidak diperlukan, itu mungkin memberikan keuntungan kecil. Namun, masih bisa diperdebatkan apakah pendekatan itu masuk akal, dan Anda membayar harga yang lumayan untuk keuntungan kecil itu.
Jika Anda memiliki klien yang terhubung dari WiFis hotel atau tempat "aneh" lainnya, Anda akan melihat bahwa sering kali keseluruhan dukungan untuk TCP jauh, jauh lebih baik daripada untuk UDP.

Game umumnya menggunakan UDP bukan karena lebih unggul dalam salah satu cara yang disebutkan sebelumnya - bukan - atau karena Anda dapat mengurangi jitter hingga setengah milidetik dengan menerapkan keandalan tanpa urutan, tetapi karena game (seperti telepon IP) sering mengandung banyak data yang sangat tidak stabil, seperti misalnya pembaruan posisi.
Data yang mudah menguap ini secara teratur dan cepat usang baik oleh berlalunya waktu, dan dengan datagram berikutnya yang masuk. Yang berarti tidak lebih dan tidak kurang dari Anda sebenarnya tidak terlalu peduli untuk menjadi 100% dapat diandalkan (atau dalam urutan).

Dengan asumsi paket jaringan dijatuhkan dalam layanan yang berjalan pada kecepatan yang stabil dengan pembaruan yang sering datang (game shooter, telepon, obrolan video) itu tidak masuk akal untuk memiliki waktu habis mengakui dan mengirim ulang paket, dan sementara itu bekukan semuanya di ujung yang lain sambil menunggu paket yang dikirim kembali tiba. Itu terlalu mengganggu, dan tidak baik.

Sebaliknya, Anda hanya mempertimbangkan paket yang hilang dan melanjutkan, mengambil data dari paket berikutnya yang berhasil melaluinya dan sementara itu, dengan kemampuan terbaik Anda, sembunyikan fakta bahwa paket hilang dari pengguna. Interpolasi, perhitungan mati, sebut saja.

Perhatikan bahwa paket loss adalah kondisi normal. Sementara IP umumnya "cukup dapat diandalkan", paket-paket yang kadang-kadang dijatuhkan dapat terjadi, dan akan terjadi . Walaupun paket yang hilang biasanya berada pada sisi yang jarang (<1% di sini), itu bukan sesuatu yang luar biasa atau teoretis, atau indikasi bahwa ada sesuatu yang rusak. Itu sangat normal.
Setiap transfer massal TCP tentu akan menyertakan paket yang hilang, misalnya (begitulah cara kontrol kemacetan bekerja).

Dalam MPG bandwidth tinggi, Anda tidak peduli jika Anda melewatkan paket yang memberi Anda lokasi dan kesehatan monster # 425, karena Anda akan mendapatkan pembaruan lain dalam sepersekian detik. Ini adalah dan contoh di mana UDP membuat TCP terlihat bodoh karena membuat Anda menunggu data usang secara instan.

Dalam gim yang sama, Anda ingin tambalan muncul persis seperti yang dirancang. TCP sudah memiliki fitur "beri tahu saya jika gagal" bawaan, memfasilitasi coba ulang otomatis dan kegagalan terverifikasi. Anda dapat melakukannya di UDP, tetapi mengapa harus membuat ulang teknologinya?

Inilah deskripsi sederhana tentang apa yang terjadi.

UDP - Isolate chunk O'data.
Buat paket.
Enkapsulasi dalam IP.
Kirim itu.

TCP - Mengisolasi Stream O'data.
Buat paket dari depan sungai.
Enkapsulasi dalam IP.
Tunggu ruang di jendela TCP.
Kirim itu.
Terus reshipping sampai tanda terima diterima atau batas waktu.
Tetap di jendela TCP sampai tanda terima diterima atau batas waktu.

Pengiriman hanya berarti berhasil melalui NIC lokal, tidak lebih.

Penerimaan tanda terima TCP menjamin penerimaan data dan membebaskan ruang di jendela untuk paket selanjutnya.

Mengirim ulang (sedikit) meningkatkan kemungkinan penerimaan akhirnya.

Paket TCP dipasang kembali di sisi lain sebagai aliran data yang dipesan. Paket-paket UPD diterima sebagai paket yang berbeda. Protokol tidak menjaga ketertiban.

TCP baik untuk mendorong data yang dibutuhkan dan data dalam jumlah besar yang dipesan. TCP memberikan pemberitahuan tentang kegagalan yang terus-menerus. TCP self-throttles melalui pipa tersedak (ref: window). TCP memiliki jabat tangan untuk memperlambat inisialisasi. TCP memerlukan "koneksi" sebelum transmisi.

UDP hanya menempatkan data di kabel dan memungkinkan Anda melanjutkan tanpa menunggu windows dan transmisi ulang. UDP akan meledakkan data dengan kecepatan penuh ke dalam pipa tersedak, tidak peduli berapa banyak data yang hilang.

Saya merancang dan menulis Utilitas Transport File UDP Multicast yang diterapkan secara komersial. Saya telah bekerja pada tumpukan IP. Ini hanya dasar-dasar, sans minutia. Menjelaskan "soket, MTU dan mainan menyenangkan lainnya" sedikit di luar apa yang akan berguna untuk pertanyaan ini.

Ps (Saya tidak bisa menambahkan komentar untuk membalas komentar) UDP juga baik untuk data yang diinginkan tetapi tidak diperlukan. Forward Error Correction adalah contohnya, banyak paket yang tidak perlu tetapi diinginkan.

Apakah semua router yang dioptimalkan TCP membuat TCP berkinerja lebih baik daripada UDP?

Satu pertanyaan lagi adalah: apakah "data berat" berarti Anda akan sering memuat adegan?

Jika ya, Anda mungkin perlu mengirim data dalam jumlah besar (> 1k) secara intensif di mana TCP mungkin jauh lebih efisien karena terutama di sisi server NIC akan menyediakan berbagai pembongkaran dengan siklus yang sama. Aplikasi ruang pengguna dapat mengeluarkan penulisan besar dengan TCP sementara di UDP upaya untuk mengirim lebih dari ukuran byte header MTU akan menyebabkan fragmentasi IP dan overhead lainnya yang akan mematikan kinerja

Baik UDP atau TCP (atau varian lainnya) lebih unggul , bahkan dalam hal kecepatan / latensi. Pilihan Anda harus dibuat tergantung pada persyaratan aplikasi Anda. Untuk melakukan ini, Anda harus membandingkan fitur yang ditawarkan masing-masing protokol, menyadari bahwa lebih banyak fitur menyiratkan lebih banyak overhead. Jadi, jika tujuannya adalah untuk meminimalkan latensi atau memaksimalkan kecepatan, maka Anda harus memilih protokol dengan fitur sesedikit mungkin, tetapi tetap menjaga fitur-fitur penting yang diperlukan untuk memenuhi kebutuhan Anda.

Perbandingan Protokol

Secara umum, UDP (User Datagram Protocol) menawarkan jumlah fitur yang paling sedikit. Sangat sederhana karena Anda mengirim data tanpa tanda terima / pengakuan apa pun.

Di sisi lain, TCP (Transmission Control Protocol) menawarkan sebagian besar fitur yang dibutuhkan untuk komunikasi yang andal dan terhubung. Komunikasi TCP mengirimkan duplikat atau lebih paket dan menandainya dengan informasi pemesanan. Setelah diterima di tujuan, ACK (pengakuan) harus dikirim kembali bersama dengan informasi tentang paket mana yang hilang sehingga pengirim asli dapat mengirim ulang paket yang hilang tersebut. Jika saya ingat dengan benar, bahkan paket ACK mungkin perlu pengakuan untuk keandalan yang tepat.

Contoh: Panggilan Konferensi Skype

Untuk panggilan konferensi Skype, tidak penting untuk memastikan bahwa semua data video dan audio dikirim / diterima dengan cara yang andal. Saat ini, UDP melakukan pekerjaan yang baik dalam meminimalkan kehilangan paket. Yang penting untuk diketahui adalah bahwa sama sekali tidak ada jaminan di UDP apakah transmisi berhasil atau tidak. Untuk data audio / video dalam panggilan konferensi, UDP adalah pilihan yang tepat karena kami lebih peduli untuk mendapatkan data waktu-nyata (yaitu, yang terbaru). Jika beberapa paket hilang di sana-sini, itu tidak akan mengganggu komunikasi secara dramatis.

Namun, dalam panggilan konferensi, orang dapat mengirim pesan instan (IM) atau mengirim file. Dalam kasus ini, keandalan merupakan persyaratan yang diperlukan untuk memastikan bahwa file dan pesan tidak rusak atau hilang. Untuk IM, Anda mungkin tidak memerlukan status terhubung yang disediakan oleh TCP. Protokol perantara, seperti RUDP (Reliable UDP) mungkin cukup. Namun, untuk file, mungkin perlu memiliki status terhubung yang disediakan oleh TCP.

Pilihan Implementasi

Jika Anda memiliki aplikasi yang kompleks atau perlu mengoptimalkan komunikasi Anda, maka akan bermanfaat untuk memulai dengan komunikasi UDP. Setelah itu, Anda dapat menambahkan semua fitur yang Anda butuhkan di atasnya. Ini akan memberi Anda kontrol paling besar pada komunikasi jaringan Anda.

Jika Anda memiliki aplikasi sederhana di mana optimasi tidak diperlukan, pertimbangkan untuk menggunakan salah satu standar (UDP atau TCP) untuk memenuhi kebutuhan Anda. Itu akan memungkinkan Anda untuk beralih ke hal-hal yang lebih penting.

Saya melihat banyak komentar di mana orang percaya bahwa paket TCP lebih besar daripada paket UDP. Jangan hanya percaya padaku, baca dokumentasinya. Protokolnya adalah sebagai berikut: beberapa byte untuk header Ethernet (tipe pesan 2 byte, 48 bit MAC, 6 byte) (untuk Wifi, header mungkin berbeda) 20 byte untuk IP 20 byte untuk TCP atau UDP x byte untuk data x mulai dari 0 hingga sekitar 1500 (lihat MTU) Terakhir, checksum untuk memastikan tidak ada kerusakan yang terjadi pada paket Ethernet tersebut.

TCP memungkinkan untuk mengirim paket "stream" yang lebih besar sekitar 64K. Blok "besar" ini sebenarnya dipotong dalam banyak paket Ethernet yang lebih kecil.