kcptube
Release 20241201
Haga clic aquí para ver la versión en inglés
Cualquiera que haya utilizado banda ancha doméstica de los tres principales operadores y necesite interconexión de banda ancha doméstica casi siempre experimentará que UDP tiene una velocidad limitada. Para evitar la QoS de los tres principales operadores para UDP, creé otra herramienta llamada UDP Hop. El principio es establecer nuevas conexiones periódicamente (cambiar los números de puerto y conectarse a nuevas direcciones).
Sin embargo, UDP Hop sólo admite el reenvío de tráfico UDP. Para poder utilizar UDP para reenviar tráfico TCP, existe KCP Tube. La retransmisión confiable de KCP se utiliza para garantizar que los paquetes TCP reenviados no se pierdan.
Otra razón para crear KCP Tube es que otras herramientas de reenvío de KCP solo pueden reenviar tráfico TCP, pero yo necesito usar KCP para reenviar tráfico UDP. Principalmente por la comodidad de jugar.
Por supuesto, udphop y kcptube fueron concebidos al mismo tiempo. Entonces, por conveniencia, primero configuramos KCP Tube y configuramos el marco, y luego lo cortamos en UDP Hop basado en KCP Tube. Luego, realice la fusión inversa del código del parche UDP Hop nuevamente en KCP Tube.
Para facilitar a los usuarios de Full Cone NAT de banda ancha doméstica, KCP Tube puede usar STUN para perforar agujeros cuando se ejecuta en modo de servidor básico y es compatible con IPv4 e IPv6.
Al igual que el propósito del propio KCP, el objetivo principal de KCP Tube es reducir la latencia, en lugar de favorecer la transmisión de un tráfico extremadamente grande. Entonces, ¿puede transmitir un tráfico extremadamente grande? Sí, pero el efecto puede no ser tan bueno como el de la herramienta de reenvío TCP-KCP existente.
Actualmente se admiten 3 modos:
Tenga en cuenta que la hora del cliente y la hora del servidor deben estar sincronizadas y la diferencia horaria no puede ser superior a 255 segundos.
Vaya a la página wiki o vaya a la página de documentación.
Si necesita un generador de perfiles, vaya aquí: KCPTube Generator
kcptube config.conf
Ejemplo de modo cliente:
mode=client
kcp=regular3
inbound_bandwidth=500M
outbound_bandwidth=50M
listen_port=59000
destination_port=3000
destination_address=123.45.67.89
encryption_password=qwerty1234
encryption_algorithm=AES-GCM
Ejemplo de modo servidor:
mode=server
kcp=regular3
inbound_bandwidth=1G
outbound_bandwidth=1G
listen_port=3000
destination_port=59000
destination_address=::1
encryption_password=qwerty1234
encryption_algorithm=AES-GCM
stun_server=stun.qq.com
log_path=./
Nota: Al conectarse por primera vez, el servidor informará al cliente de su rango de puertos, por lo que listen_port en modo cliente no tiene que ser igual destination_port en modo servidor. Los puertos en ambos lados pueden ser inconsistentes, pero el. El rango de números de puerto escrito por el cliente no puede ir más allá del alcance del servidor para evitar que el cliente seleccione el puerto incorrecto y no pueda conectarse.
Si desea especificar la tarjeta de red de escucha, especifique la dirección IP de la tarjeta de red y agregue una línea.
listen_on=192.168.1.1
Si desea escuchar varios puertos y varias tarjetas de red, separe varios archivos de configuración.
kcptube config1.conf config2.conf
Si desea probar si la conexión es fluida antes de conectarse, puede agregar la opción --try
kcptube --try config1.conf
o
kcptube config1.conf --try
Utilice la opción --check-config para verificar que el archivo de configuración sea correcto:
kcptube --check-config config1.conf
o
kcptube config1.conf --check-config
Ejemplo de modo cliente:
mode=client
kcp=regular3
inbound_bandwidth=500M
outbound_bandwidth=50M
listen_port=6000
destination_port=3000-4000
destination_address=123.45.67.89
dport_refresh=600
encryption_password=qwerty1234
encryption_algorithm=AES-GCM
Ejemplo de modo servidor:
mode=server
kcp=regular3
inbound_bandwidth=1G
outbound_bandwidth=1G
listen_port=3000-4000
destination_port=6000
destination_address=::1
encryption_password=qwerty1234
encryption_algorithm=AES-GCM
Ejemplo de modo cliente:
mode=client
kcp=manual
kcp_mtu=1400
kcp_sndwnd=512
kcp_rcvwnd=2048
kcp_nodelay=1
kcp_interval=10
kcp_resend=2
kcp_nc=true
udp_timeout=300
listen_port=6000
destination_port=3000-4000
destination_address=123.45.67.89
dport_refresh=600
encryption_password=qwerty1234
encryption_algorithm=AES-GCM
Ejemplo de modo servidor:
mode=server
kcp=manual
kcp_mtu=1400
kcp_sndwnd=512
kcp_rcvwnd=2048
kcp_nodelay=1
kcp_interval=10
kcp_resend=2
kcp_nc=true
udp_timeout=300
listen_port=3000-4000
destination_port=6000
destination_address=::1
encryption_password=qwerty1234
encryption_algorithm=AES-GCM
| nombre | Valor configurable | Requerido | Observación |
|---|---|---|---|
| modo | cliente servidor relé | Sí | Nodo de retransmisión del servidor cliente |
| escuchar_en | Nombre de dominio o dirección IP | No | Sólo se puede completar el nombre de dominio o la dirección IP. Separe varias direcciones con comas |
| puerto_escucha | 1-65535 | Sí | Cuando se ejecuta como servidor, puede especificar un rango de puertos |
| puerto_destino | 1-65535 | Sí | Los rangos de puertos se pueden especificar cuando se ejecuta como cliente. Separe varias direcciones con comas |
| dirección_destino | dirección IP, nombre de dominio | Sí | No se requieren corchetes al completar la dirección IPv6 |
| dport_refresh | 0 - 32767 | No | La unidad es "segunda". Si se deja en blanco, se utilizará el valor predeterminado de 60 segundos. De 1 a 20 se calcula como 20 segundos y más de 32767 se calcula como 32767 segundos. Establezca en 0 para desactivar. |
| algoritmo_cifrado | AES-GCM AES-OCB chacha20 xchacha20 ninguno | No | AES-256-GCM-AEAD AES-256-OCB-AEAD ChaCha20-Poly1305 XChaCha20-Poly1305 Sin cifrado |
| contraseña_cifrado | cualquier personaje | Depende de la situación | Requerido cuando el algoritmo_cifrado está configurado y no es ninguno |
| udp_timeout | 0 - 65535 | No | La unidad es "segunda". El valor predeterminado es 180 segundos. Si se establece en 0, se utiliza el valor predeterminado. Esta opción representa la configuración de tiempo de espera entre la aplicación UDP ↔ kcptube. |
| mantener_alive | 0 - 65535 | No | La unidad es "segunda". El valor predeterminado es 0, lo que equivale a deshabilitar Keep Alive. Esta opción se refiere a Keep Alive entre dos extremos de KCP. Se puede habilitar unilateralmente para detectar si el canal deja de responder. Si no hay respuesta después de 30 segundos, el canal se cerrará. |
| mux_tuneles | 0 - 65535 | No | El valor predeterminado es 0, lo que equivale a no utilizar canales de multiplexación. Esta opción se refiere al número de canales de multiplexación entre los dos extremos de KCP. Esta opción solo está habilitada en el lado del cliente. |
| servidor_aturdidor | dirección del servidor STUN | No | No se puede utilizar cuando listening_port está en modo de rango de puertos |
| ruta_log | Directorio para almacenar el registro | No | No se puede apuntar al archivo en sí |
| fec | uint8:uint8 | No | El formato es fec=D:R , por ejemplo, se puede completar fec=20:3 .Nota: El valor total máximo de D + R es 255 y no puede exceder este número. Un valor de 0 a cada lado de los dos puntos indica que la opción no se utiliza. La configuración debe ser la misma en ambos extremos. Para obtener más información, consulte la guía de uso de FEC. |
| mtu | entero positivo | No | Valor actual de MTU de la red, utilizado para calcular automáticamente kcp_mtu |
| kcp_mtu | entero positivo | No | El valor predeterminado es 1440. El valor establecido al llamar a ikcp_setmtu() es la longitud del contenido de datos en el paquete UDP. |
| kcp | manual rápido1-6 regular1-5 | Sí | Establecer manualmente la velocidad normal rápida (Número al final: cuanto menor sea el valor, más rápida será la velocidad) |
| kcp_sndwnd | entero positivo | No | Los valores predeterminados se muestran en la siguiente tabla y se pueden anular individualmente. |
| kcp_rcvwnd | entero positivo | No | Los valores predeterminados se muestran en la siguiente tabla y se pueden anular individualmente. |
| kcp_nodelay | entero positivo | Depende de la situación | Requerido cuando kcp=manual, el valor predeterminado se muestra en la siguiente tabla |
| intervalo_kcp | entero positivo | Depende de la situación | Requerido cuando kcp=manual, el valor predeterminado se muestra en la siguiente tabla |
| kcp_resend | entero positivo | Depende de la situación | Requerido cuando kcp=manual, el valor predeterminado se muestra en la siguiente tabla |
| kcp_nc | Sí verdadero 1 No FALSO 0 | Depende de la situación | Requerido cuando kcp=manual, el valor predeterminado se muestra en la siguiente tabla |
| ancho de banda_saliente | entero positivo | No | Ancho de banda saliente, utilizado para actualizar dinámicamente el valor de kcp_sndwnd durante la comunicación |
| ancho de banda entrante | entero positivo | No | Ancho de banda entrante, utilizado para actualizar dinámicamente el valor de kcp_rcvwnd durante el proceso de comunicación. |
| ipv4_solo | Sí verdadero 1 No FALSO 0 | No | Si IPv6 está deshabilitado en el sistema, esta opción debe estar habilitada y configurada en sí o verdadero o 1 |
| ipv6_solo | Sí verdadero 1 No FALSO 0 | No | Ignorar direcciones IPv4 |
| explosión | Sí verdadero 1 No FALSO 0 | No | Intente ignorar la configuración de control de flujo de KCP y reenvíe los paquetes lo más rápido posible. Puede causar una carga excesiva |
| [oyente] | N / A | Sí (solo modo relé) | La etiqueta del modo de retransmisión, utilizada para especificar el KCP en el modo de escucha. La configuración de esta etiqueta indica los datos de interacción con el cliente. |
| [promotor] | N / A | Sí (solo modo relé) | La etiqueta del modo de retransmisión, utilizada para especificar el KCP del modo de transferencia. La configuración de esta etiqueta indica los datos de interacción con el servidor. |
| [entrada_personalizada] | N / A | No | Etiqueta del modo de mapeo personalizado, consulte el método de uso del mapeo personalizado |
| [entrada_personalizada_tcp] | N / A | No | Etiqueta del modo de mapeo personalizado, consulte el método de uso del mapeo personalizado |
| [entrada_personalizada_udp] | N / A | No | Etiqueta del modo de mapeo personalizado, consulte el método de uso del mapeo personalizado |
Entre ellos, encryption_algorithm y encryption_password deben ser coherentes en ambos extremos de la comunicación.
| nombre | Valor configurable | Requerido | Observación |
|---|---|---|---|
| entrada_fib | 0 - 65535 | No | FIB utilizado por conexiones entrantes |
| salida_fib | 0 - 65535 | No | FIB utilizado para conexiones salientes |
Sufijos disponibles: K/M/G
El sufijo distingue entre mayúsculas y minúsculas, las mayúsculas se calculan como binario (1024) y las minúsculas se calculan como decimal (1000).
Complete 1000, lo que indica que el ancho de banda es de 1000 bps
Complete 100k, lo que indica que el ancho de banda es de 100 kbps (100000 bps)
Complete 100K, lo que indica que el ancho de banda es de 100 Kbps (102400 bps)
Complete 100M, lo que indica que el ancho de banda es de 100 Mbps (102400 Kbps)
Complete 1G, lo que indica que el ancho de banda es 1 Gbps (1024 Mbps)
Tenga en cuenta que son bps (bits por segundo), no Bps (bytes por segundo).
Cabe recordar que el valor del ancho de banda ingresado no debe exceder el ancho de banda real para evitar la congestión en la ventana de envío.
NOTA IMPORTANTE :
KCPTube calculará y establecerá el tamaño de la ventana de envío de KCP en función del valor de retraso del paquete de protocolo de enlace y los valores de outbound_bandwidth e inbound_bandwidth aproximadamente 5 segundos después de que se establezca el enlace KCP. Dentro de un período de tiempo después de completar la configuración, existe una alta probabilidad de que el tráfico fluctúe significativamente, o incluso que el tráfico caiga repentinamente a 0 y tomará varios segundos recuperarse.
| modo rápido | kcp_sndwnd | kcp_rcvwnd | kcp_nodelay | intervalo_kcp | kcp_resend | kcp_nc |
|---|---|---|---|---|---|---|
| rápido1 | 2048 | 2048 | 1 | 1 | 2 | 1 |
| rápido2 | 2048 | 2048 | 2 | 1 | 2 | 1 |
| rápido3 | 2048 | 2048 | 1 | 1 | 3 | 1 |
| rápido4 | 2048 | 2048 | 2 | 1 | 3 | 1 |
| rápido5 | 2048 | 2048 | 1 | 1 | 4 | 1 |
| rápido6 | 2048 | 2048 | 2 | 1 | 4 | 1 |
| modo de velocidad normal | kcp_sndwnd | kcp_rcvwnd | kcp_nodelay | intervalo_kcp | kcp_resend | kcp_nc |
|---|---|---|---|---|---|---|
| regular1 | 1024 | 1024 | 1 | 1 | 5 | 1 |
| regular2 | 1024 | 1024 | 2 | 1 | 5 | 1 |
| regular3 | 1024 | 1024 | 0 | 1 | 2 | 1 |
| regular4 | 1024 | 1024 | 0 | 15 | 2 | 1 |
| regular5 | 1024 | 1024 | 0 | 30 | 2 | 1 |
Entre ellos, cuanto mayor es la tasa de pérdida de paquetes (superior al 10%), más ventaja tiene kcp_nodelay=1 sobre kcp_nodelay=2. Cuando la tasa de pérdida de paquetes no es particularmente alta, kcp_nodelay=2 puede suavizar la fluctuación del retraso.
Para entornos con baja pérdida de paquetes, cada modo es adecuado para su uso. La única diferencia radica en si se utiliza más o menos tráfico desperdiciado y el límite superior de la velocidad máxima es diferente. Entre ellos, regular3 no desperdicia tanto tráfico.
Se recomienda habilitar blast=1 al mismo tiempo.
Para entornos con alta pérdida de paquetes, considere superponer la configuración FEC. Para obtener más información, consulte la guía de uso de FEC.
Para obtener más detalles, consulte la lista de parámetros.
Después de obtener la dirección IP y el puerto perforados por primera vez, y después de cambiar la dirección IP y el puerto perforados, se creará el archivo ip_address.txt en el directorio de registro (sobrescrito si existe), y la dirección IP La dirección y el puerto se escribirán en él.
La dirección de perforación obtenida se mostrará en la consola al mismo tiempo.
log_path= debe apuntar a un directorio, no al archivo en sí.
Si no necesita escribir en el archivo de registro, elimine la línea log_path .
Servidores STUN comunes encontrados en NatTypeTeste:
Servidor STUN encontrado en Natter:
Otros servidores STUN: public-stun-list.txt
Para facilitar su uso, se han proporcionado archivos ejecutables binarios para múltiples plataformas:
Los binarios precompilados se compilan todos estáticamente. La versión de Linux está básicamente compilada estáticamente, a excepción de libc, por lo que se preparan dos versiones, una para glibc (2.31) y otra para musl.
Para el entorno Linux, también se proporcionan imágenes de Docker (actualmente solo x64). Descargue kcptube_docker_image.zip y descomprímalo, y luego use docker load -i kcptube_docker.tar para importarlo.
Después de la importación, el método de uso es:
docker run -v /path/to/config_file.conf:/config_file.conf kcptube config_file.conf
Por ejemplo:
docker run -v /home/someone/config1.conf:/config1.conf kcptube config1.conf
Los usuarios de FreeBSD pueden copiar el archivo binario descargado a /usr/local/bin/ y luego ejecutar el comando
chmod +x /usr/local/bin/kcptube
Los archivos de servicio correspondientes se han preparado en el directorio service de este proyecto.
/usr/local/etc/rc.d/chmod +x /usr/local/etc/rc.d/kcptube/usr/local/etc/kcptube/config.conf/usr/local/etc/kcptube/config.confkcptube_enable="YES" a /etc/rc.conf Finalmente, ejecute service kcptube start para iniciar el servicio.
El compilador debe ser compatible con C++20.
Bibliotecas dependientes:
Utilice vcpkg para instalar los paquetes de dependencia asio y botan de antemano. El comando es el siguiente:
vcpkg install asio:x64-windows asio:x64-windows-static
vcpkg install botan:x64-windows botan:x64-windows-static
(Si necesita una versión ARM o x86 de 32 bits, ajuste las opciones usted mismo)
Luego use Visual Studio para abrir slnkcptube.sln y compílelo usted mismo
De manera similar, primero instale las dependencias asio y botan3. Además, se requiere cmake. Puede instalarlo con el paquete propio del sistema:
pkg install asio botan3 cmake
Luego compila en el directorio de compilación.
mkdir build
cd build
cmake ..
make
Los pasos son similares a los de FreeBSD. Para NetBSD, utilice pkgin para instalar dependencias y cmake:
pkgin install asio
pkgin install cmake
OpenBSD Utilice pkg_add para instalar las dos dependencias anteriores. DragonflyBSD utilice pkg , el uso es el mismo que FreeBSD.
Dado que botan-3 no se ha incluido en estos sistemas BSD, debes compilar botan-3 tú mismo.
Para conocer los pasos de compilación restantes, consulte FreeBSD arriba.
Tenga en cuenta que, dado que estos BSD vienen con versiones de compilador inferiores, instale una versión superior de GCC con antelación.
Los pasos son similares a los de FreeBSD. Utilice el administrador de paquetes que viene con la distribución para instalar asio, botan3 y cmake.
apk add asio botan3-libs cmake
Luego compila en el directorio de compilación.
mkdir build
cd build
cmake ..
make
Hay dos maneras
Práctica 1
Compile de acuerdo con el proceso normal, elimine el archivo binario kcptube recién generado y ejecute el comando
make VERBOSE=1
Luego extraiga el último comando de enlace de C++ del contenido de salida y cambie -lbotan-3 en el medio a la ruta completa de libbotan-3.a, como /usr/lib/x86_64-linux-gnu/libbotan-3.a .
Práctica 2
Abra src/CMakeLists.txt y cambie target_link_libraries(${PROJECT_NAME} PRIVATE botan-3) a target_link_libraries(${PROJECT_NAME} PRIVATE botan-3 -static)
Luego se compila normalmente. Tenga en cuenta que si el sistema usa glibc, se compilará estáticamente junto con glibc y aparecerá una advertencia sobre getaddrinfo.
No tengo una computadora Apple, así que resuelva todos los pasos usted mismo.
Aumentar la caché de recepción puede mejorar el rendimiento de la transmisión UDP
Puede utilizar el comando sysctl kern.ipc.maxsockbuf para ver el tamaño de la caché. Si es necesario realizar ajustes, ejecute el comando (cambie el número al valor deseado):
sysctl -w kern.ipc.maxsockbuf=33554434
O escriba en /etc/sysctl.conf
kern.ipc.maxsockbuf=33554434
Puede utilizar el comando sysctl net.inet.udp.recvspace para comprobar el tamaño del búfer de recepción. Si se necesitan ajustes, ejecute el comando (cambie el número al valor deseado):
sysctl -w net.inet.udp.recvspace=33554434
O escriba en /etc/sysctl.conf
net.inet.udp.recvspace=33554434
Si es necesario, puede ajustar el valor de net.inet.udp.sendspace al mismo tiempo. Esta es la configuración de caché de envío.
Para la caché de recepción, puede utilizar los comandos sysctl net.core.rmem_max y sysctl net.core.rmem_default para ver el tamaño de la caché de recepción.
Si se necesitan ajustes, ejecute el comando (cambie el número al valor deseado):
sysctl -w net.core.rmem_max=33554434
sysctl -w net.core.rmem_default=33554434
O escriba en /etc/sysctl.conf
net.core.rmem_max=33554434
net.core.rmem_default=33554434
Si es necesario, puedes ajustar los valores de net.core.wmem_max y net.core.wmem_default al mismo tiempo. Esta es la configuración de caché de envío.
Dado que kcptube utiliza internamente IPv6 de pila única + activa la dirección asignada IPv4 (IPv6 asignada a IPv4) para usar redes IPv4 e IPv6, asegúrese de que el valor de la opción v6only sea 0.
En circunstancias normales, no se requieren configuraciones adicionales. FreeBSD, Linux y Windows permiten que las direcciones IPv4 se asigne a IPv6 de forma predeterminada.
Si el sistema no admite IPv6 o IPv6 está deshabilitado, establezca ipv4_only=true en el archivo de configuración, para que kcptube vuelva a utilizar el modo de pila única IPv4.
usar comando
sysctl -w net.inet6.ip6.v6only=0
Después de la configuración, el modo de pila única + dirección asignada puede escuchar la pila dual.
Sin embargo, por motivos desconocidos, es posible que la dirección asignada IPv4 no esté conectada activamente.
Debido a que OpenBSD bloquea completamente las direcciones de mapeo IPv4, si usa pila dual en la plataforma OpenBSD, necesita guardar dos archivos de configuración, uno de los cuales habilita ipv4_only=1, y luego cargar ambos archivos de configuración al mismo tiempo cuando usa kcptube.
En la mayoría de los casos, este mensaje sólo se encontrará en el lado del servidor, no en el lado del cliente.
Si realmente se encuentra en el cliente, verifique si el valor de mux_tunnels es demasiado alto (por cierto, consulte el párrafo "Multiplexación (mux_tunnels = N)").
En circunstancias normales, la gran mayoría de los sistemas BSD no encontrarán este tipo de cosas. Solo GhostBSD que se actualizará en la segunda mitad de 2023 encontrará este fenómeno.
Esto se debe a que GhostBSD agregó esta línea a /etc/sysctl.conf :
kern.maxfiles=100000
Esta línea reduce el límite superior a mucho más bajo que el valor correspondiente en FreeBSD básico.
La solución es simple, simplemente elimina esta línea. También puedes comentarlo.
También puede utilizar el comando sysctl kern.maxfiles=300000 para modificar temporalmente el valor del límite superior.
Dado que la cantidad de archivos abiertos en los sistemas Linux está limitada a 1024, es fácil encontrar este problema.
Solución temporal:
ulimit -n para ver el valor de salidaulimit -n 300000 Solución permanente:
Edite /etc/security/limits.conf y agréguelo al final
* hard nofile 300000
* soft nofile 300000
root hard nofile 300000
root soft nofile 300000
Dado que los datos TCP deben transmitirse, la validación de datos no se puede ignorar, al igual que el propio TCP.
Independientemente de si está cifrado o no, kcptube reducirá la MTU en 2 bytes y agregará 2 bytes de datos.
Si se ha utilizado la opción de cifrado, los 2 bytes de datos adjuntos son el IV generado temporalmente.
Si elige no utilizar la función de cifrado, los datos de 2 bytes adjuntos son el código de verificación, que es el XOR de los bits alto y bajo de CRC32.
Cabe recordar que el uso de códigos de verificación aún no puede prevenir al 100% los errores de contenido, y lo mismo ocurre con el propio TCP. Si realmente necesita ser preciso, habilite la opción de cifrado.
Aunque KCP Tube tiene una función de "multiplexación", no se abre activamente de forma predeterminada. Sin esta característica, por cada conexión entrante aceptada, se crea una conexión saliente correspondiente.
El motivo es evitar la QoS del operador. En el estado de multiplexación, una vez que un determinado número de puerto tiene QoS, otras sesiones que compartan el mismo número de puerto se bloquearán al mismo tiempo hasta que se cambie el número de puerto.
Las conexiones son independientes entre sí. Incluso si un determinado número de puerto tiene QoS, solo esta sesión se verá afectada y las demás sesiones no.
A menos que el programa alojado genere una gran cantidad de conexiones independientes. En este caso, KCP Tube creará una gran cantidad de canales KCP, lo que consumirá más recursos de CPU durante el proceso de comunicación.
Si realmente desea utilizar la función "multiplexación", puede consultar las siguientes categorías:
Escenarios adecuados para utilizar "multiplexación":
Escenarios donde no es necesaria la "multiplexación":
Cuando la "Multiplexación" está habilitada, KCPTube creará previamente N enlaces y todas las nuevas conexiones entrantes transmitirán datos desde los enlaces existentes en lugar de crear nuevos enlaces por separado. En este momento, el tiempo de espera del canal KCP es de 30 segundos.
En términos generales, establecer `mux_tunnels en 3 ~ 10 es suficiente y no es necesario establecer un valor demasiado alto.
Para reducir la latencia, kcptube habilita la opción TCP_NODELAY. Para algunos escenarios de aplicaciones de gran tráfico, la cantidad de transmisión de datos TCP puede reducirse.
Basado en el KCP original, se han realizado las siguientes modificaciones:
flush() original primero transfiere los datos que se enviarán a la cola de envío y luego rehace las tres cosas de "enviar nuevos paquetes de datos", "reenviar paquetes de datos" y "enviar paquetes ACK" en el mismo ciclo. La versión modificada primero realiza la "retransmisión de paquetes de datos" y la "transmisión de paquetes ACK", y luego "transfiere los datos que se enviarán a la cola de envío" y los envía durante el período de transferencia.check() original recorrerá la cola de envío nuevamente cada vez para encontrar la marca de tiempo de retransmisión del punto alcanzado. La versión modificada se convierte en: lea la primera marca de tiempo de la tabla de mapeo ordenada, eliminando el paso de búsqueda.Además, la versión original tiene "errores" y kcptube también los tendrá. Por ejemplo:
Entonces kcptube estableció un plan de suspensión más obvio. Para los datos TCP, cuando se alcanza el límite de recepción (la cola está llena), la recepción de datos TCP se suspenderá hasta que haya espacio y luego se reanudará para los datos UDP, el paquete se perderá directamente cuando se alcance el límite de recepción;
Básicamente, esta limitación no tendrá ningún impacto en escenarios de aplicaciones donde el volumen de transmisión no es grande.
El grupo de subprocesos utilizado por kcptube proviene de BS::thread_pool, con algunas modificaciones para el procesamiento de cifrado y descifrado en paralelo durante múltiples conexiones.
El código está escrito de manera muy informal y lo escribo donde pienso, por lo que el diseño es confuso. Para ser precisos, es muy confuso.
Algunas de las líneas de código son tan largas como postes de bambú, principalmente porque era demasiado vago para cambiar de línea para seguir el hilo del pensamiento al escribir. Después de todo, no uso vim/emacs. Cuando uso un IDE, el tamaño del texto establecido en el área de código del IDE es diferente del tamaño del texto en otras áreas, e incluso las fuentes son diferentes, lo que me ayuda a aliviar el problema de confusión.
En cuanto a los sentimientos de los lectores... definitivamente no estarán contentos. No es asunto mío, déjalo en paz.
