TCP atau UDP untuk game multi-pemain?


18

Ini pertanyaan yang sering saya lihat. Kebanyakan orang mengatakan UDP selalu lebih baik untuk gim real-time daripada TCP. Pemahaman saya adalah bahwa TCP mencoba mengirim ulang paket berulang kali sampai pihak lain mendapatkannya sedangkan UDP tidak peduli.

Sebagian besar hal yang saya baca adalah bahwa UDP adalah suatu keharusan untuk setiap permainan waktu nyata dan TCP mengerikan. Tapi masalahnya, kebanyakan orang tampaknya menerapkan beberapa bentuk TCP di atas UDP. Dan saya juga pernah mendengar bahwa perbedaan antara keduanya dapat diabaikan mengingat kita tidak berada di tahun 80-an dan internet sekarang cukup cepat dan dapat diandalkan.

Apakah pemahaman umum saya di sini salah? Bisakah seseorang membersihkan ini untuk saya?


7
internet is now pretty fast and reliableTidak, tidak. The bandwidth yang telah meningkat secara dramatis, ya, tapi latency masih cukup tinggi. Dengan TCP murni Anda perlu waktu centang server lebih dari latensi terjangkau maks, kecuali jika Anda melakukan pemerasan paket - yang terbaik dilakukan pada klien melalui UDP. Masalahnya adalah bahwa beberapa info dalam game harus dapat diandalkan, sementara beberapa lainnya harus cepat. Protokol khusus di atas UDP memungkinkan untuk itu, serta banyak protokol eksklusif yang memberikan semua yang Anda butuhkan dalam paket yang bagus.
Ordous

4
Mereka tidak benar-benar mengimplementasikan TCP over UDP. Ada beberapa fitur yang ditawarkan TCP yang diinginkan dan yang diimplementasikan di atas UDP. Poin utama menggunakan UDP adalah bahwa jika Anda mengirim paket yang berisi negara dunia pada waktu t0yang tidak pernah diterima, maka Anda mengirim negara dunia baru pada waktu itu t1, Anda tidak perlu menunggu sampai klien benar-benar menerima paket pertama, yang sudah usang.
Vincent Savard

@Ordous Saya pikir ini menjawab pertanyaan saya :) Terima kasih
flooblebit

4
Perlu diketahui juga bahwa UDP rentan terhadap IP spoofing yang dapat membuat server Anda terbuka terhadap serangan DDoS jika itu menjadi masalah. Anda bisa menghindarinya dengan memiliki koneksi TCP "kontrol" yang mengirim alamat IP klien dan detail lainnya ke server yang kemudian menerima paket UDP dari alamat "yang diautentikasi". Anda juga mungkin harus menerapkan lapisan enkripsi Anda sendiri karena tidak ada standar terbuka untuk itu di atas UDP.
ARau

@ blownie55 poin bagus di sana
Naresh Kumar

Jawaban:


12

Tergantung jika Anda berbicara tentang peer-to-peer, klien / server dengan pengguna yang menjalankan server, atau klien / server dengan pusat data yang menjalankan server. Hanya dalam kasus yang terakhir kebanyakan internet sangat cepat dan dapat diandalkan. Komputer pengguna Anda tidak dijamin cepat, dan tentu saja tidak dapat diandalkan.

UDP memungkinkan Anda kontrol lebih besar atas jenis implementasi TCP-like yang Anda buat. Ini memberi Anda fleksibilitas yang lebih besar untuk mengeksekusi paket-paket yang rusak, membuang paket-paket yang Anda anggap tidak perlu saat mencoba lagi paket-paket yang Anda anggap penting, hal-hal semacam itu. Tetapi ini hanya dapat dilakukan jika diperlukan dan jika Anda memiliki keahlian yang diperlukan.

Jika Anda dapat melakukannya tanpa fleksibilitas itu, TCP bekerja cukup baik dan menghemat banyak waktu. Bahkan studio profesional (seperti yang saya bekerja di) menggunakan TCP jika mereka tidak benar-benar membutuhkan UDP, dan mereka memiliki orang-orang yang berdedikasi untuk pemrograman jaringan.


Saya juga menyarankan bahwa "untuk apa" yang penting - misalnya untuk sistem obrolan dalam game, saya bahkan tidak akan mempertimbangkan UDP. Hal lain yang akan saya pertimbangkan (setidaknya untuk "server klien") adalah seberapa efisien server dapat menangani lalu lintas - NIC modern memiliki banyak hal bawaan "pembongkaran" untuk TCP (membelah dan menggabungkan paket, menyortir paket ke dalam aliran, dll) yang dirancang untuk mengurangi overhead CPU, dan sebagian besar tidak dapat bekerja untuk UDP.
Brendan

1
Hal-hal dapat berubah sekarang yaitu QUIC ( en.wikipedia.org/wiki/QUIC ) yang akan menjadi bagian dari HTTP / 3 yang menggunakan UDP dan dienkripsi menggunakan TLS secara default. Ini akan membutuhkan waktu untuk ini tersedia secara luas dan merupakan sesuatu yang dinanti-nantikan. Lebih detail tentang beberapa masalah yang perlu ditangani di sini blog.cloudflare.com/the-road-to-quic
ARau

3

Ini akan menjadi asumsi untuk mengatakan "Internet sekarang cukup cepat dan dapat diandalkan" seperti yang ditunjukkan @Ordous, dan juga berbahaya.

Alasan mengapa protokol khusus UDP + untuk paket pengiriman-kritis melakukan sihir di sebagian besar gim adalah bahwa, ada kalanya bisa "oke" jika Anda kehilangan beberapa paket (hanya untuk. Misalnya acara sekunder non-kritis untuk menyelesaikan permainan) , ada juga saat-saat di mana "sama sekali tidak oke" untuk kehilangan beberapa data untuk misalnya pergerakan kursor dll. (Saya tidak melakukan pengembangan game untuk mencari nafkah jadi maafkan contoh-contoh saya yang samar-samar)

UDP tidak membuang waktu dalam mendorong mereka lagi dan lagi, secara default.

Dan, banyak gim yang sepertinya memiliki paket "oke untuk kalah kadang" lebih dari paket "selalu harus dikirimkan tanpa gagal". Karenanya membuat cocok alami untuk tugas ini.

Semua yang diperlukan pada UDP adalah dengan menggunakan protokol khusus yang hanya membantu memberikan paket "selalu perlu untuk mengirim tanpa gagal" dengan benar, meninggalkan sisa data gim di tangan koneksi jaringan.

Sekarang memutuskan jenis lalu lintas apa yang membuat sebagian besar data ANDA yang akan dikirim akan membantu Anda memutuskan dengan lebih baik.

Intinya terhadap TCP adalah waktu yang dihabiskan untuk retries lebih baik dihabiskan untuk mengirim paket yang penting SEKARANG.

Ada juga kemungkinan bahwa jika ada masalah selama transmisi, TCP dapat mengalir ke skenario gim yang lebih terpecah bagi pengguna, memanjakan pengalaman mereka dibandingkan dengan UDP + Custom Stack (Bagian terakhir ini hanya dugaan. Saya akan meninggalkan ini untuk ahli lain di sini untuk mengomentari ini. Ingin belajar tentang kemungkinan skenario ini).

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.