kcp
v1.7
README dalam bahasa Inggris
KCP adalah protokol yang cepat dan andal yang dapat mengurangi penundaan rata-rata sebesar 30%-40% dan mengurangi penundaan maksimum sebanyak tiga kali lipat dengan biaya bandwidth 10%-20% lebih banyak daripada TCP. Implementasi algoritma murni tidak bertanggung jawab atas pengiriman dan penerimaan protokol yang mendasarinya (seperti UDP). Pengguna perlu menentukan metode pengiriman paket data lapisan bawah dan memberikannya ke KCP dalam bentuk panggilan balik. Bahkan jam perlu diteruskan secara eksternal, dan tidak akan ada panggilan sistem apa pun secara internal.
Seluruh protokol hanya memiliki dua file sumber, ikcp.h dan ikcp.c, yang dapat dengan mudah diintegrasikan ke dalam tumpukan protokol milik pengguna. Mungkin Anda telah mengimplementasikan protokol berbasis P2P atau UDP tetapi tidak memiliki implementasi protokol ARQ yang lengkap dan andal. Kemudian cukup salin kedua file ini ke proyek yang ada, tulis beberapa baris kode, dan Anda dapat menggunakannya.
TCP dirancang untuk lalu lintas (berapa KB data yang dapat dikirimkan per detik), dan penekanannya adalah pada pemanfaatan bandwidth secara penuh. KCP dirancang untuk laju aliran (berapa lama waktu yang dibutuhkan satu paket data untuk dikirim dari satu ujung ke ujung lainnya). KCP menukar 10%-20% bandwidth yang terbuang untuk kecepatan transmisi yang 30%-40% lebih cepat dari TCP. . Saluran TCP merupakan saluran besar yang laju alirannya lambat namun laju aliran per detiknya besar, sedangkan saluran KCP merupakan saluran kecil yang cepat dengan aliran yang cepat. KCP memiliki dua jenis: mode normal dan mode cepat. Hasil peningkatan laju aliran dicapai melalui strategi berikut:
Perhitungan batas waktu TCP adalah RTOx2. Jika Anda kehilangan tiga paket berturut-turut, itu akan menjadi RTOx8, yang sangat menakutkan, namun, setelah KCP memulai mode cepat, itu bukan x2, tetapi hanya x1.5 (percobaan telah membuktikannya). nilai 1,5 relatif baik), yang meningkatkan kecepatan transmisi.
Ketika TCP kehilangan sebuah paket, ia akan mengirimkan ulang seluruh data mulai dari paket yang hilang. KCP melakukan transmisi ulang secara selektif dan hanya mentransmisikan ulang paket data yang benar-benar hilang.
Pengirim mengirimkan beberapa paket 1, 2, 3, 4, dan 5, dan kemudian menerima ACK dari ujung jarak jauh: 1, 3, 4, 5. Saat menerima ACK3, KCP mengetahui bahwa 2 dilewati satu kali, dan menerimanya Ketika ACK4 diterima, diketahui bahwa paket 2 telah dilewati dua kali. Saat ini, dapat dianggap bahwa paket nomor 2 hilang. Tidak perlu menunggu batas waktu dan paket nomor 2 dapat langsung dikirim ulang, yang sangat meningkatkan kecepatan transmisi ketika paket hilang.
Untuk memanfaatkan bandwidth secara penuh, TCP menunda pengiriman ACK (NODELAY tidak berguna). Dengan cara ini, perhitungan batas waktu akan menghitung waktu RTT yang lebih besar, yang memperpanjang proses penilaian ketika terjadi kehilangan paket. Keterlambatan pengiriman ACK KCP dapat disesuaikan.
Ada dua jenis respons model ARQ, UNA (semua paket sebelum nomor ini telah diterima, seperti TCP) dan ACK (paket dengan nomor ini telah diterima). Menggunakan UNA saja akan menyebabkan semua transmisi ulang, sedangkan menggunakan ACK saja akan menyebabkan biaya kerugian yang terlalu tinggi. Di masa lalu, semua protokol memilih salah satu dari keduanya, tetapi dalam protokol KCP, kecuali untuk paket ACK individual, semua paket memiliki informasi UNA.
Mode normal KCP menggunakan aturan konsesi adil yang sama seperti TCP, yaitu ukuran jendela pengiriman ditentukan oleh empat faktor: ukuran buffer pengirim, ukuran buffer penerima yang tersisa di sisi penerima, konsesi kehilangan paket, dan start yang lambat. Namun, saat mengirimkan data kecil dengan persyaratan ketepatan waktu tinggi, Anda dapat memilih untuk melewati dua langkah terakhir melalui konfigurasi dan hanya menggunakan dua item pertama untuk mengontrol frekuensi pengiriman. Dengan mengorbankan keadilan parsial dan pemanfaatan bandwidth, efek kelancaran transmisi dapat dicapai bahkan ketika BT dihidupkan.
Anda dapat mengunduh dan menginstal kcp menggunakan pengelola perpustakaan vcpkg:
git clone https://github.com/Microsoft/vcpkg.git
cd vcpkg
./bootstrap-vcpkg.sh
./vcpkg integrate install
./vcpkg install kcp
Pustaka kcp di vcpkg selalu diperbarui oleh anggota tim Microsoft dan kontributor komunitas. Jika versinya sudah kadaluarsa, silakan buat isu atau ajukan PR pada repositori vcpkg.
Buat objek KCP:
// 初始化 kcp对象，conv为一个表示会话编号的整数，和tcp的 conv一样，通信双
// 方需保证 conv相同，相互的数据包才能够被认可，user是一个给回调函数的指针
ikcpcb *kcp = ikcp_create(conv, user);Atur fungsi panggilan balik:
// KCP的下层协议输出函数，KCP需要发送数据时会调用它
// buf/len 表示缓存和长度
// user指针为 kcp对象创建时传入的值，用于区别多个 KCP对象
int udp_output ( const char *buf, int len, ikcpcb *kcp, void *user)
{
....
}
// 设置回调函数
kcp->output = udp_output;Panggil pembaruan dalam satu lingkaran:
// 以一定频率调用 ikcp_update来更新 kcp状态，并且传入当前时钟（毫秒单位）
// 如 10ms调用一次，或用 ikcp_check确定下次调用 update的时间不必每次调用
ikcp_update (kcp, millisec);Masukkan paket lapisan bawah:
// 收到一个下层数据包（比如UDP包）时需要调用：
ikcp_input (kcp, received_udp_packet, received_udp_size);Setelah memproses keluaran/masukan protokol lapisan bawah, protokol KCP dapat bekerja secara normal. Gunakan ikcp_send untuk mengirim data ke ujung jarak jauh. Ujung lainnya menggunakan ikcp_recv(kcp, ptr, size) untuk menerima data.
Mode default protokol adalah ARQ standar, dan berbagai sakelar akselerasi perlu diaktifkan melalui konfigurasi:
Modus kerja:
int ikcp_nodelay (ikcpcb *kcp, int nodelay, int interval, int resend, int nc)Jendela maksimum:
int ikcp_wndsize (ikcpcb *kcp, int sndwnd, int rcvwnd);Panggilan ini akan mengatur jendela pengiriman maksimum dan ukuran jendela penerimaan maksimum protokol, yang defaultnya adalah 32. Ini dapat dipahami sebagai SND_BUF dan RCV_BUF TCP, tetapi unitnya berbeda. Unit SND/RCV_BUF adalah byte, dan unit ini adalah byte paket.
Unit transmisi maksimum:
Protokol algoritma murni tidak bertanggung jawab untuk mendeteksi MTU. Mtu default adalah 1400 byte. Nilai ini akan mempengaruhi unit transmisi maksimum saat menggabungkan dan memecah paket data.
RTO minimal:
Baik itu TCP atau KCP, ada batas RTO minimum saat menghitung RTO. Meskipun RTO yang dihitung adalah 40 md, karena RTO default adalah 100 md, protokol hanya dapat mendeteksi kehilangan paket setelah 100 md. Nilai ini dapat diubah secara manual:
kcp->rx_minrto = 10 ;Penggunaan dan konfigurasi protokolnya sangat sederhana. Dalam kebanyakan kasus, pada dasarnya Anda dapat menggunakannya setelah membaca konten di atas. Jika Anda memerlukan kontrol lebih lanjut, seperti mengubah pengalokasi memori KCP, atau Anda perlu menjadwalkan koneksi KCP secara lebih efisien dalam skala besar (misalnya lebih dari 3500), atau cara mengintegrasikan dengan TCP dengan lebih baik, maka Anda bisa lanjutkan membaca:
Bacaan terkait: "Genshin Impact" juga menggunakan KCP untuk mempercepat berita game
KCP telah berhasil dijalankan di banyak proyek dengan ratusan juta pengguna, memberikan mereka pengalaman jaringan yang lebih responsif dan lancar.
Selamat datang untuk memberi tahu kami lebih banyak kasus
Jika jaringan tidak pernah macet, maka KCP/TCP akan berperilaku serupa, namun jaringan itu sendiri tidak dapat diandalkan, dan kehilangan paket serta jitter tidak dapat dihindari (jika tidak, mengapa kita memerlukan berbagai protokol yang dapat diandalkan)? Jika dibandingkan secara langsung di lingkungan yang hampir ideal seperti intranet, semua orang hampir sama. Namun, ketika ditempatkan di jaringan publik, ditempatkan di jaringan 3G/4G, atau menggunakan simulasi kehilangan paket intranet, kesenjangannya menjadi jelas. Jaringan publik rata-rata kehilangan paket mendekati 10% selama periode puncak, dan lebih buruk lagi di bawah WiFi/3g/4g, yang akan menyebabkan penundaan transmisi.
Terima kasih kepada zhangyuan, penulis asio-kcp, atas evaluasi horizontal KCP, enet, dan udt.
Untuk detailnya, lihat: Data perbandingan dan evaluasi horizontal memberikan panduan lebih lanjut bagi mereka yang ragu untuk memilih.
Mesin server game multipemain masif SpatialOS melakukan evaluasi yang sama seperti TCP/RakNet setelah mengintegrasikan protokol KCP:
Kami membandingkan waktu respons ketika mempertahankan 50 karakter secara bersamaan dengan kecepatan refresh 60 Hz di sisi server.
Dalam beberapa tahun terakhir, game online dan berbagai jejaring sosial telah berkembang secara eksponensial. Terlepas dari game online atau berbagai jejaring sosial interaktif, interaktivitas dan kompleksitasnya meningkat dengan pesat, dan semuanya perlu mengirimkan data secara bersamaan dalam waktu yang sangat singkat pengguna, teknologi transmisi secara alami akan menjadi faktor penting yang membatasi perkembangan di masa depan, dan berbagai protokol transmisi terkenal di dunia open source, seperti raknet/enet Misalnya, ketika rilis dibuat, seluruh tumpukan protokol dirilis secara bersamaan. Formulir ini tidak kondusif untuk diversifikasi. Proyek saya hanya dapat memilih untuk menggunakan Anda atau tidak sekumpulan tumpukan protokol. Betapapun bagusnya, sangat sulit untuk memenuhi berbagai kebutuhan dari sudut yang berbeda.
Oleh karena itu, metode KCP adalah dengan "membongkar" tumpukan protokol sehingga setiap orang dapat secara fleksibel menyesuaikan dan merakitnya sesuai dengan kebutuhan proyek. Anda dapat menambahkan lapisan kode penghapusan reed solomon di bawah untuk FEC, dan lapisan di atasnya untuk RC4/Salsa20. Untuk enkripsi aliran, pertukaran kunci asimetris dirancang saat jabat tangan, dan sistem perutean dinamis dibangun pada lapisan transport UDP yang mendasarinya untuk mendeteksi beberapa jalur pada saat yang sama dan memilih jalur terbaik untuk transmisi. "Unit protokol" yang berbeda ini dapat digabungkan secara bebas sesuai kebutuhan seperti blok penyusun untuk memastikan "kesederhanaan" dan "kemampuan dilepas", sehingga dapat secara fleksibel beradaptasi dengan perubahan kebutuhan bisnis. Jika ada modul yang tidak bagus, ganti saja.
Solusi transmisi di masa depan harus disesuaikan secara mendalam sesuai dengan skenario penggunaan, jadi kami memberikan "unit protokol" kepada setiap orang yang dapat digabungkan secara bebas untuk memfasilitasi integrasi ke dalam tumpukan protokol Anda sendiri.
Untuk informasi lebih lanjut, silakan lihat Kisah Sukses.
Penulis: Lin Wei (skywind3000)
Selamat mengikuti saya di: blog pribadi dan Twitter.
Selama bertahun-tahun pengalaman pengembangan saya, saya selalu suka mempelajari dan memecahkan beberapa masalah kemacetan dalam program. Di tahun-tahun awal saya, saya menyukai pengembangan game. Saya mengikuti "Pemrograman VGA" untuk mengerjakan grafik game, dan membaca "Program Grafik" karya Michael Abrash Panduan Pengembang" untuk melakukan rendering lembut. Saya suka bermain-main dengan beberapa kode yang dapat memeras CPU dan berjalan lebih cepat. Setelah bergabung dengan pekerjaan ini, minat saya beralih ke teknologi sisi server dan yang berhubungan dengan jaringan.
Pada tahun 2007, setelah membuat beberapa permainan tradisional, saya mulai mempelajari masalah sinkronisasi permainan aksi cepat. Selama periode ini, saya menulis banyak artikel. Saya adalah salah satu orang paling awal di Tiongkok yang mempelajari masalah sinkronisasi tidak peduli bagaimana mengatasi sinkronisasi, kita perlu melakukan sesuatu dalam hal transmisi jaringan. Setelah keluar dari permainan dan beralih ke Internet, saya juga menemukan bahwa banyak bidang yang memiliki kebutuhan ini, jadi saya mulai menghabiskan waktu di bidang transmisi jaringan. , mencoba menerapkan beberapa protokol konservatif dan andal berdasarkan UDP, dan meniru kode BSD Lite 4.4 untuk mengimplementasikan beberapa protokol mirip TCP protokol, menurut saya cukup menarik, dan kemudian mengimplementasikan beberapa mainan yang berhubungan dengan P2P dan jaringan perutean dinamis. Protokol KCP lahir pada tahun 2011. Pada dasarnya ini adalah salah satu dari beberapa mainan yang dibuat sendiri dalam hal transmisi.
Penulis Kcptun, xtaci, adalah teman sekelas saya di kampus, Kami berdua mengambil jurusan komunikasi, dan kami sering belajar bersama bagaimana cara mengoptimalkan transmisi.
Selamat menggunakan Alipay untuk memindai kode QR di atas untuk berdonasi ke proyek ini. Donasi akan digunakan untuk terus mengoptimalkan protokol KCP dan memperbaiki dokumentasi.
Terima kasih kepada: Mingming, Xingzi, Jin, Fan, Yanzhao, Binquan, Xiaodan, Yu Zheng, Hu, Shenggan, Xu Wei, Wang Chuan, Zhao Gangqiang, Hu Zhifeng, Wan Xinchao, He Xinchao, Liu Yang, Hou Xianhui, Wu Peiyi , Hua Bin, Rutao, Hu Jian. . . (Maaf saya tidak mencatat daftar sebelumnya) Kami menunggu donasi dan dukungan dari teman-teman sekelas.
Selamat datang untuk memperhatikan
Grup komunikasi KCP: 364933586 (nomor grup QQ), integrasi KCP, penyetelan, transmisi jaringan, dan diskusi teknis terkait
Grup Gitter: https://gitter.im/skywind3000/KCP
blog: http://www.skywind.me
Proyek ini ada berkat semua orang yang berkontribusi.
