kcp
v1.7
LÉAME en inglés
KCP es un protocolo rápido y confiable que puede reducir el retraso promedio entre un 30% y un 40% y reducir el retraso máximo tres veces a un costo de entre un 10% y un 20% más de ancho de banda que TCP. La implementación pura del algoritmo no es responsable del envío y recepción de protocolos subyacentes (como UDP). Los usuarios deben definir el método de envío de paquetes de datos de capa inferior y proporcionárselo a KCP en forma de devolución de llamada. Incluso el reloj debe pasarse externamente y no habrá ninguna llamada al sistema internamente.
Todo el protocolo solo tiene dos archivos fuente, ikcp.h e ikcp.c, que se pueden integrar fácilmente en la pila de protocolos del propio usuario. Tal vez haya implementado un protocolo basado en P2P o UDP pero le falta una implementación completa y confiable del protocolo ARQ. Luego simplemente copie estos dos archivos al proyecto existente, escriba algunas líneas de código y podrá usarlo.
TCP está diseñado para el tráfico (cuántos KB de datos se pueden transmitir por segundo) y el énfasis está en aprovechar al máximo el ancho de banda. KCP está diseñado para la tasa de flujo (cuánto tiempo tarda un solo paquete de datos en enviarse de un extremo a otro). Intercambia entre el 10% y el 20% del desperdicio de ancho de banda por una velocidad de transmisión que es entre un 30% y un 40% más rápida que TCP. . El canal TCP es un canal grande con un caudal lento pero un gran caudal por segundo, mientras que el canal KCP es un canal pequeño y rápido con un flujo rápido. KCP tiene dos tipos: modo normal y modo rápido. El resultado de aumentar el caudal se logra mediante las siguientes estrategias:
El cálculo del tiempo de espera de TCP es RTOx2. Si pierde tres paquetes seguidos, se convertirá en RTOx8, lo cual da mucho miedo. Sin embargo, después de que KCP inicia el modo rápido, no es x2, sino solo x1.5 (los experimentos han demostrado que). el valor de 1,5 es relativamente bueno), lo que mejora la velocidad de transmisión.
Cuando TCP pierde un paquete, retransmitirá todos los datos a partir del paquete perdido. KCP retransmite selectivamente y solo retransmite los paquetes de datos realmente perdidos.
El remitente envió varios paquetes 1, 2, 3, 4 y 5, y luego recibió el ACK del extremo remoto: 1, 3, 4, 5. Al recibir ACK3, KCP supo que 2 se omitió una vez y recibió Cuando ACK4 Cuando se recibe, se sabe que el paquete 2 se ha omitido dos veces. En este momento, se puede considerar que el paquete número 2 se perdió. No es necesario esperar el tiempo de espera y el paquete número 2 se puede retransmitir directamente, lo que mejora enormemente. la velocidad de transmisión cuando se pierden paquetes.
Para aprovechar al máximo el ancho de banda, TCP retrasa el envío de ACK (NODELAY es inútil, de esta manera, el cálculo del tiempo de espera calculará un tiempo RTT mayor, lo que prolongará el proceso de evaluación cuando se produzca la pérdida de paquetes). Se puede ajustar si el ACK de KCP se envía con retraso.
Hay dos tipos de respuestas del modelo ARQ, UNA (se han recibido todos los paquetes anteriores a este número, como TCP) y ACK (se han recibido paquetes con este número). El uso de UNA solo provocará todas las retransmisiones, mientras que el uso de ACK solo provocará. un costo de pérdida demasiado alto En el pasado, los protocolos consistían en elegir uno de los dos, pero en el protocolo KCP, excepto los paquetes ACK individuales, todos los paquetes tienen información UNA.
El modo normal KCP utiliza la misma regla de concesión justa que TCP, es decir, el tamaño de la ventana de envío está determinado por cuatro factores: el tamaño del búfer de envío, el tamaño restante del búfer de recepción en el extremo receptor, la concesión de pérdida de paquetes y el inicio lento. Sin embargo, al transmitir datos pequeños con altos requisitos de puntualidad, puede optar por omitir los dos últimos pasos de la configuración y utilizar solo los dos primeros elementos para controlar la frecuencia de envío. A expensas de la equidad parcial y la utilización del ancho de banda, se puede lograr el efecto de una transmisión fluida incluso cuando BT está activado.
Puede descargar e instalar kcp utilizando el administrador de biblioteca vcpkg:
git clone https://github.com/Microsoft/vcpkg.git
cd vcpkg
./bootstrap-vcpkg.sh
./vcpkg integrate install
./vcpkg install kcp
Los miembros del equipo de Microsoft y los contribuyentes de la comunidad mantienen actualizada la biblioteca kcp en vcpkg. Si la versión no está actualizada, cree un problema o genere un PR en el repositorio de vcpkg.
Crear objeto KCP:
// 初始化 kcp对象，conv为一个表示会话编号的整数，和tcp的 conv一样，通信双
// 方需保证 conv相同，相互的数据包才能够被认可，user是一个给回调函数的指针
ikcpcb *kcp = ikcp_create(conv, user);Establecer función de devolución de llamada:
// KCP的下层协议输出函数，KCP需要发送数据时会调用它
// buf/len 表示缓存和长度
// user指针为 kcp对象创建时传入的值，用于区别多个 KCP对象
int udp_output ( const char *buf, int len, ikcpcb *kcp, void *user)
{
....
}
// 设置回调函数
kcp->output = udp_output;Llame a la actualización en un bucle:
// 以一定频率调用 ikcp_update来更新 kcp状态，并且传入当前时钟（毫秒单位）
// 如 10ms调用一次，或用 ikcp_check确定下次调用 update的时间不必每次调用
ikcp_update (kcp, millisec);Ingrese un paquete de capa inferior:
// 收到一个下层数据包（比如UDP包）时需要调用：
ikcp_input (kcp, received_udp_packet, received_udp_size);Después de procesar la salida/entrada del protocolo de capa inferior, el protocolo KCP puede funcionar normalmente. Utilice ikcp_send para enviar datos al extremo remoto. El otro extremo usa ikcp_recv(kcp, ptr, size) para recibir datos.
El modo predeterminado del protocolo es un ARQ estándar y es necesario activar varios interruptores de aceleración a través de la configuración:
Modo de trabajo:
int ikcp_nodelay (ikcpcb *kcp, int nodelay, int interval, int resend, int nc)Ventana máxima:
int ikcp_wndsize (ikcpcb *kcp, int sndwnd, int rcvwnd);Esta llamada establecerá el tamaño máximo de la ventana de envío y la ventana máxima de recepción del protocolo, que por defecto es 32. Esto puede entenderse como SND_BUF y RCV_BUF de TCP, pero las unidades son diferentes. La unidad SND/RCV_BUF son bytes, y esta unidad es. paquetes.
Unidad de transmisión máxima:
El protocolo de algoritmo puro no es responsable de detectar la MTU. La mtu predeterminada es 1400 bytes. Puede utilizar ikcp_setmtu para establecer este valor. Este valor afectará a la unidad máxima de transmisión al combinar y fragmentar paquetes de datos.
RTO mínimo:
Ya sea TCP o KCP, existe un límite mínimo de RTO al calcular el RTO. Incluso si el RTO calculado es 40 ms, dado que el RTO predeterminado es 100 ms, el protocolo solo puede detectar la pérdida de paquetes después de 100 ms. En modo rápido, es 30 ms. Este valor se puede cambiar manualmente:
kcp->rx_minrto = 10 ;El uso y configuración del protocolo es muy simple. En la mayoría de los casos, básicamente puede usarlo después de leer el contenido anterior. Si necesita un control más detallado, como cambiar el asignador de memoria de KCP, o necesita programar conexiones KCP de manera más eficiente a gran escala (como más de 3500), o cómo integrarse mejor con TCP, entonces puede sigue leyendo:
Lectura relacionada: "Genshin Impact" también usa KCP para acelerar las noticias del juego
KCP se ha ejecutado con éxito en múltiples proyectos con cientos de millones de usuarios, brindándoles una experiencia de red más fluida y con mayor capacidad de respuesta.
Bienvenido a contarnos más casos.
Si la red nunca se atasca, entonces KCP/TCP se comportará de manera similar, pero la red en sí no es confiable y la pérdida de paquetes y la fluctuación son inevitables (de lo contrario, ¿por qué necesitaríamos varios protocolos confiables)? Cuando se compara directamente en un entorno casi ideal como la intranet, todos son casi iguales. Sin embargo, cuando se los coloca en la red pública, en una red 3G/4G o se utiliza la simulación de pérdida de paquetes de la intranet, la brecha se vuelve obvia. La red pública tiene una pérdida promedio de paquetes cercana al 10% durante los períodos pico, y es aún peor con WiFi/3g/4g, lo que provocará retrasos en la transmisión.
Gracias a zhangyuan, el autor de asio-kcp, por una evaluación horizontal de KCP, enet y udt. Las conclusiones son las siguientes:
Para obtener más información, consulte: Los datos de evaluación y comparación horizontal brindan más orientación para quienes dudan en elegir.
El motor de servidor de juegos multijugador masivo SpatialOS hizo la misma evaluación que TCP/RakNet después de integrar el protocolo KCP:
Comparamos el tiempo de respuesta al mantener 50 caracteres al mismo tiempo con una frecuencia de actualización de 60 Hz en el lado del servidor. Consulte el informe de comparación detallado:
En los últimos años, los juegos en línea y varias redes sociales han crecido exponencialmente. Independientemente de los juegos en línea o de varias redes sociales interactivas, la interactividad y la complejidad están aumentando rápidamente y todos necesitan entregar datos simultáneamente en muy poco tiempo. de usuarios, la tecnología de transmisión se convertirá naturalmente en un factor importante que restringirá el desarrollo futuro, y varios protocolos de transmisión bien conocidos en el mundo del código abierto, como raknet/enet Por ejemplo, cuando se realiza un lanzamiento, se publica toda la pila de protocolos. Esta forma no favorece la diversificación. Mi proyecto solo puede elegir si lo usa o no, pero usted lo diseña. No importa lo bueno que sea un conjunto de pilas de protocolos, es muy difícil satisfacer diversas necesidades desde diferentes ángulos.
Por lo tanto, el método de KCP es "desmontar" la pila de protocolos para que todos puedan ajustarla y ensamblarla de manera flexible según las necesidades del proyecto. Puede agregar una capa de código de borrado de Reed Solomon a continuación para FEC y una capa encima para RC4/Salsa20. Para el cifrado de flujo, se diseña un intercambio de claves asimétrico en el protocolo de enlace y se construye un sistema de enrutamiento dinámico en la capa de transporte UDP subyacente para detectar múltiples rutas al mismo tiempo y seleccionar la mejor ruta para la transmisión. Estas diferentes "unidades de protocolo" se pueden combinar libremente según sea necesario como bloques de construcción para garantizar la "simplicidad" y la "desmontabilidad", de modo que puedan adaptarse de manera flexible a las necesidades comerciales cambiantes. Si algún módulo no es bueno, simplemente reemplácelo.
Las soluciones de transmisión futuras deben personalizarse profundamente según los escenarios de uso, por lo que brindamos a todos una "unidad de protocolo" que se puede combinar libremente para facilitar la integración en su propia pila de protocolos.
Para obtener más información, consulte las Historias de éxito.
Autor: Lin Wei (skywind3000)
Bienvenido a seguirme en: blog personal y Twitter.
En mis muchos años de experiencia en desarrollo, siempre me ha gustado estudiar y resolver algunos problemas de cuellos de botella en los programas. En mis primeros años, me gustaba el desarrollo de juegos. Seguí la "Programación VGA" para hacer gráficos de juegos y leí el "Programa de gráficos" de Michael Abrash. Guía del desarrollador" para realizar renderizado suave. Me gusta jugar con algún código que pueda exprimir la CPU y ejecutarse más rápido. Después de unirme al trabajo, mi interés se centró en las tecnologías del lado del servidor y relacionadas con la red.
En 2007, después de crear varios juegos tradicionales, comencé a estudiar el problema de sincronización de los juegos de acción rápida. Durante este período, escribí muchos artículos en China, pero descubrí que. No importa cómo resolver la sincronización, necesitamos hacer algo en términos de transmisión de red. Después de dejar el juego y cambiar a Internet, también descubrí que muchos campos tienen esta necesidad, así que comencé a dedicar tiempo al campo de la transmisión de red. , tratando de implementar algunos protocolos conservadores y confiables basados en UDP, e imitando el código de BSD Lite 4.4 para implementar algunos similares a TCP protocolo, lo encontré bastante interesante y luego implementé algunos juguetes relacionados con P2P y redes de enrutamiento dinámico. El protocolo KCP nació en 2011. Es básicamente uno de varios juguetes fabricados por él mismo en términos de transmisión.
El autor de Kcptun, xtaci, es mi compañero de clase en la universidad. Ambos nos especializamos en comunicaciones y, a menudo, estudiamos juntos cómo optimizar la transmisión.
Bienvenido a utilizar Alipay para escanear el código QR de arriba y donar a este proyecto. Las donaciones se utilizarán para optimizar continuamente el protocolo KCP y mejorar la documentación.
Gracias a: 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. . . (Lamento no haber registrado la lista anterior) Estamos esperando las donaciones y el apoyo de nuestros compañeros.
Bienvenido a prestar atención
Grupo de comunicación KCP: 364933586 (número de grupo QQ), integración de KCP, sintonización, transmisión de red y discusiones técnicas relacionadas
Grupo Gitter: https://gitter.im/skywind3000/KCP
blog: http://www.skywind.me
Este proyecto existe gracias a todas las personas que contribuyen.
