Cliquez ici pour la version anglaise
Quiconque a utilisé le haut débit domestique des trois principaux opérateurs et a besoin d’une interconnexion haut débit domestique verra presque toujours la vitesse d’UDP limitée. Afin d'éviter la QoS des trois principaux opérateurs pour UDP, j'ai créé un autre outil appelé UDP Hop. Le principe est d'établir régulièrement de nouvelles connexions (changer de numéro de port et se connecter à de nouvelles adresses).
Cependant, UDP Hop ne prend en charge que le transfert du trafic UDP. Afin de pouvoir utiliser UDP pour transférer le trafic TCP, il existe KCP Tube. La retransmission fiable de KCP est utilisée pour garantir que les paquets TCP transférés ne seront pas perdus.
Une autre raison pour laquelle KCP Tube est créé est que d'autres outils de transfert KCP ne peuvent transférer que le trafic TCP, mais je dois utiliser KCP pour transférer le trafic UDP. Principalement pour la commodité de jouer à des jeux.
Bien entendu, udphop et kcptube ont été conçus en même temps. Donc, par souci de commodité, nous avons d'abord configuré le KCP Tube et configuré le framework, puis l'avons découpé en UDP Hop basé sur le KCP Tube. Ensuite, fusionnez à l'envers le code du patch UDP Hop vers KCP Tube.
Afin de faciliter les utilisateurs de NAT Full Cone à large bande à domicile, KCP Tube peut utiliser STUN pour percer des trous lors de l'exécution en mode serveur de base et prend en charge à la fois IPv4 et IPv6.
Tout comme le but de KCP lui-même, l’objectif principal de KCP Tube est de réduire la latence, plutôt que de favoriser la transmission d’un trafic extrêmement important. Alors peut-il transmettre un trafic extrêmement important ? Oui, mais l'effet n'est peut-être pas aussi bon que celui de l'outil de transfert TCP-KCP existant.
Actuellement 3 modes sont pris en charge :
Notez que l'heure du client et celle du serveur doivent être synchronisées et que le décalage horaire ne peut pas être supérieur à 255 secondes.
Veuillez vous rendre sur la page wiki ou sur la page de documentation.
Si vous avez besoin d'un générateur de profil, allez ici : KCPTube Generator
kcptube config.conf
Exemple de mode client :
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
Exemple de mode serveur :
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=./
Remarque : lors de la première connexion, le serveur informera le client de sa plage de ports. Il n'est donc pas nécessaire que listen_port
en mode client soit égal destination_port
en mode serveur. Les ports des deux côtés peuvent être incohérents, mais les ports sont incohérents. La plage de numéros de port écrite par le client ne peut pas dépasser la portée du serveur pour empêcher le client de sélectionner le mauvais port et de ne pas se connecter.
Si vous souhaitez spécifier la carte réseau d'écoute, spécifiez l'adresse IP de la carte réseau et ajoutez une ligne.
listen_on=192.168.1.1
Si vous souhaitez écouter plusieurs ports et plusieurs cartes réseau, séparez plusieurs fichiers de configuration.
kcptube config1.conf config2.conf
Si vous souhaitez tester si la connexion est fluide avant de vous connecter, vous pouvez ajouter l'option --try
kcptube --try config1.conf
ou
kcptube config1.conf --try
Utilisez l'option --check-config
pour vérifier que le fichier de configuration est correct :
kcptube --check-config config1.conf
ou
kcptube config1.conf --check-config
Exemple de mode client :
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
Exemple de mode serveur :
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
Exemple de mode client :
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
Exemple de mode serveur :
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
nom | Valeur réglable | Requis | Remarque |
---|---|---|---|
mode | client serveur relais | Oui | Nœud de relais client-serveur |
écouter_on | Nom de domaine ou adresse IP | Non | Seuls le nom de domaine ou l'adresse IP peuvent être renseignés. Veuillez séparer plusieurs adresses par des virgules |
port_écoute | 1-65535 | Oui | Lors de l'exécution en tant que serveur, vous pouvez spécifier une plage de ports |
port_destination | 1-65535 | Oui | Les plages de ports peuvent être spécifiées lors de l'exécution en tant que client. Veuillez séparer plusieurs adresses par des virgules |
adresse_de destination | Adresse IP, nom de domaine | Oui | Aucun crochet n'est requis lors du remplissage de l'adresse IPv6 |
dport_refresh | 0 - 32767 | Non | L'unité est la "seconde". Si laissé vide, la valeur par défaut de 60 secondes sera utilisée. 1 à 20 est calculé comme 20 secondes et supérieur à 32 767 est calculé comme 32 767 secondes. Réglez sur 0 pour désactiver. |
algorithme_de cryptage | AES-GCM AES-OCB chacha20 xchacha20 aucun | Non | AES-256-GCM-AEAD AES-256-OCB-AEAD ChaCha20-Poly1305 XChaCha20-Poly1305 Pas de cryptage |
mot de passe_cryptage | n'importe quel personnage | Cela dépend de la situation | Obligatoire lorsque le chiffrement_algorithm est défini et n'est pas aucun |
udp_timeout | 0 - 65535 | Non | L'unité est la "seconde". La valeur par défaut est de 180 secondes. Si elle est définie sur 0, la valeur par défaut est utilisée. Cette option représente le paramètre de délai d'attente entre l'application UDP et kcptube. |
garder_en vie | 0 - 65535 | Non | L'unité est la "seconde". La valeur par défaut est 0, ce qui équivaut à désactiver Keep Alive. Cette option fait référence à Keep Alive entre deux extrémités KCP Peut être activé unilatéralement pour détecter si le canal cesse de répondre. S'il n'y a pas de réponse après 30 secondes, le canal sera fermé. |
mux_tunnels | 0 - 65535 | Non | La valeur par défaut est 0, ce qui équivaut à ne pas utiliser de canaux de multiplexage. Cette option fait référence au nombre de canaux de multiplexage entre les deux extrémités KCP. Cette option n'est activée que côté client. |
serveur_étourdissant | Adresse du serveur STUN | Non | Ne peut pas être utilisé lorsque Listen_port est en mode plage de ports |
chemin_journal | Répertoire pour stocker le journal | Non | Impossible de pointer vers le fichier lui-même |
fec | uint8:uint8 | Non | Le format est fec=D:R , par exemple, fec=20:3 peut être renseigné.Remarque : La valeur totale maximale de D + R est de 255 et ne peut pas dépasser ce nombre. Une valeur de 0 de chaque côté des deux points indique que l’option n’est pas utilisée. Les paramètres doivent être les mêmes aux deux extrémités. Pour plus de détails, veuillez vous référer au guide d'utilisation de FEC. |
mtu | entier positif | Non | Valeur MTU actuelle du réseau, utilisée pour calculer automatiquement kcp_mtu |
kcp_mtu | entier positif | Non | La valeur par défaut est 1440. La valeur définie en appelant ikcp_setmtu() est la longueur du contenu des données dans le paquet UDP. |
kcp | manuel rapide1-6 régulier1-5 | Oui | Régler manuellement la vitesse normale rapide (Chiffre à la fin : plus la valeur est petite, plus la vitesse est rapide) |
kcp_sndwnd | entier positif | Non | Les valeurs par défaut sont indiquées dans le tableau ci-dessous et peuvent être remplacées individuellement. |
kcp_rcvwnd | entier positif | Non | Les valeurs par défaut sont indiquées dans le tableau ci-dessous et peuvent être remplacées individuellement. |
kcp_nodelay | entier positif | Cela dépend de la situation | Obligatoire lorsque kcp=manuel, la valeur par défaut est indiquée dans le tableau ci-dessous |
kcp_intervalle | entier positif | Cela dépend de la situation | Obligatoire lorsque kcp=manuel, la valeur par défaut est indiquée dans le tableau ci-dessous |
kcp_resend | entier positif | Cela dépend de la situation | Obligatoire lorsque kcp=manuel, la valeur par défaut est indiquée dans le tableau ci-dessous |
kcp_nc | Oui vrai 1 Non FAUX 0 | Cela dépend de la situation | Obligatoire lorsque kcp=manuel, la valeur par défaut est indiquée dans le tableau ci-dessous |
largeur_bande sortante | entier positif | Non | Bande passante sortante, utilisée pour mettre à jour dynamiquement la valeur de kcp_sndwnd pendant la communication |
bande passante entrante | entier positif | Non | Bande passante entrante, utilisée pour mettre à jour dynamiquement la valeur de kcp_rcvwnd pendant le processus de communication |
ipv4_uniquement | Oui vrai 1 Non FAUX 0 | Non | Si IPv6 est désactivé sur le système, cette option doit être activée et définie sur oui ou vrai ou 1 |
ipv6_uniquement | Oui vrai 1 Non FAUX 0 | Non | Ignorer les adresses IPv4 |
explosion | Oui vrai 1 Non FAUX 0 | Non | Essayez d'ignorer les paramètres de contrôle de flux KCP et de transférer les paquets aussi rapidement que possible. Peut entraîner une charge excessive |
[auditeur] | N / A | Oui (mode relais uniquement) | Le label du mode relais, utilisé pour spécifier le KCP en mode écoute. Le paramétrage de ce label indique les données d'interaction avec le client. |
[transitaire] | N / A | Oui (mode relais uniquement) | Le label du mode relais, utilisé pour spécifier le KCP du mode de transfert. Le paramétrage de ce label indique les données d'interaction avec le serveur. |
[entrée_personnalisée] | N / A | Non | Étiquette du mode de mappage personnalisé, veuillez vous référer à la méthode d'utilisation du mappage personnalisé |
[custom_input_tcp] | N / A | Non | Étiquette du mode de mappage personnalisé, veuillez vous référer à la méthode d'utilisation du mappage personnalisé |
[custom_input_udp] | N / A | Non | Étiquette du mode de mappage personnalisé, veuillez vous référer à la méthode d'utilisation du mappage personnalisé |
Parmi eux, encryption_algorithm
et encryption_password
doivent être cohérents aux deux extrémités de la communication.
nom | Valeur réglable | Requis | Remarque |
---|---|---|---|
fib_entrée | 0 - 65535 | Non | FIB utilisé par les connexions entrantes |
fib_egress | 0 - 65535 | Non | FIB utilisé pour les connexions sortantes |
Suffixes disponibles : K/M/G
Le suffixe est sensible à la casse, les majuscules sont calculées en binaire (1024) et les minuscules sont calculées en décimal (1000).
Remplissez 1000, indiquant que la bande passante est de 1000 bps
Remplissez 100k, indiquant que la bande passante est de 100 kbps (100 000 bps)
Remplissez 100K, indiquant que la bande passante est de 100 Kbps (102400 bps)
Remplissez 100M, indiquant que la bande passante est de 100 Mbps (102 400 Kbps)
Remplissez 1G, indiquant que la bande passante est de 1 Gbps (1024 Mbps)
Notez qu'il s'agit de bps (Bits Per Second), et non de Bps (Bytes Per Second).
Il convient de rappeler que la valeur de bande passante renseignée ne doit pas dépasser la bande passante réelle afin d'éviter un encombrement dans la fenêtre d'envoi.
REMARQUE IMPORTANTE :
KCPTube calculera et définira la taille de la fenêtre d'envoi KCP en fonction de la valeur de délai du paquet de prise de contact et des valeurs de outbound_bandwidth et inbound_bandwidth environ 5 secondes après l'établissement de la liaison KCP. Dans un certain temps après la fin de la configuration, il y a de fortes chances que le trafic fluctue considérablement, voire que le trafic tombe soudainement à 0, et il faudra plusieurs secondes pour récupérer.
Mode rapide | kcp_sndwnd | kcp_rcvwnd | kcp_nodelay | kcp_intervalle | kcp_resend | kcp_nc |
---|---|---|---|---|---|---|
rapide1 | 2048 | 2048 | 1 | 1 | 2 | 1 |
rapide2 | 2048 | 2048 | 2 | 1 | 2 | 1 |
rapide3 | 2048 | 2048 | 1 | 1 | 3 | 1 |
rapide4 | 2048 | 2048 | 2 | 1 | 3 | 1 |
rapide5 | 2048 | 2048 | 1 | 1 | 4 | 1 |
rapide6 | 2048 | 2048 | 2 | 1 | 4 | 1 |
mode vitesse normale | kcp_sndwnd | kcp_rcvwnd | kcp_nodelay | kcp_intervalle | kcp_resend | kcp_nc |
---|---|---|---|---|---|---|
régulier1 | 1024 | 1024 | 1 | 1 | 5 | 1 |
régulier2 | 1024 | 1024 | 2 | 1 | 5 | 1 |
régulier3 | 1024 | 1024 | 0 | 1 | 2 | 1 |
régulier4 | 1024 | 1024 | 0 | 15 | 2 | 1 |
régulier5 | 1024 | 1024 | 0 | 30 | 2 | 1 |
Parmi eux, plus le taux de perte de paquets est élevé (supérieur à 10 %), plus kcp_nodelay=1 a l'avantage sur kcp_nodelay=2. Lorsque le taux de perte de paquets n'est pas particulièrement élevé, kcp_nodelay=2 peut rendre la gigue du délai plus fluide.
Pour les environnements à faible perte de paquets, chaque mode est adapté à l'utilisation. La seule différence réside dans le fait que plus ou moins de trafic gaspillé est utilisé, et la limite supérieure de la vitesse maximale est différente. Parmi eux, Regular3 ne gaspille pas autant de trafic.
Il est recommandé d'activer blast=1
en même temps.
Pour les environnements à perte de paquets élevée, envisagez de superposer le paramètre FEC. Pour plus de détails, veuillez vous référer au guide d'utilisation de FEC.
Pour plus de détails, consultez la liste des paramètres.
Une fois l'adresse IP et le port perforés obtenus pour la première fois, et après le changement d'adresse IP et de port perforés, le fichier ip_address.txt sera créé dans le répertoire Log (écrasé s'il existe), et l'adresse IP. l'adresse et le port y seront écrits.
L'adresse de forage de trou obtenue sera affichée dans la console en même temps.
log_path=
doit pointer vers un répertoire, pas vers le fichier lui-même.
Si vous n'avez pas besoin d'écrire dans le fichier journal, supprimez la ligne log_path
.
Serveurs STUN courants trouvés à partir de NatTypeTeste :
Serveur STUN trouvé sur Natter :
Autres serveurs STUN : public-stun-list.txt
Pour faciliter l'utilisation, des fichiers exécutables binaires pour plusieurs plates-formes ont été fournis :
Les binaires précompilés sont tous compilés statiquement. La version Linux est essentiellement compilée de manière statique, à l'exception de la libc, donc deux versions sont préparées, une pour la glibc (2.31) et l'autre pour musl.
Pour l'environnement Linux, des images Docker sont également fournies (actuellement x64 uniquement). Téléchargez kcptube_docker_image.zip et décompressez-le, puis utilisez docker load -i kcptube_docker.tar
pour l'importer.
Après l'importation, la méthode d'utilisation est :
docker run -v /path/to/config_file.conf:/config_file.conf kcptube config_file.conf
Par exemple:
docker run -v /home/someone/config1.conf:/config1.conf kcptube config1.conf
Les utilisateurs de FreeBSD peuvent copier le fichier binaire téléchargé dans /usr/local/bin/
puis exécuter la commande
chmod +x /usr/local/bin/kcptube
Les fichiers de service correspondants ont été préparés dans le répertoire service
de ce projet.
/usr/local/etc/rc.d/
chmod +x /usr/local/etc/rc.d/kcptube
/usr/local/etc/kcptube/
config.conf
/usr/local/etc/kcptube/config.conf
kcptube_enable="YES"
à /etc/rc.conf
Enfin, exécutez service kcptube start
pour démarrer le service
Le compilateur doit prendre en charge C++20
Bibliothèques dépendantes :
Veuillez utiliser vcpkg pour installer les packages de dépendances asio
et botan
à l'avance. La commande est la suivante :
vcpkg install asio:x64-windows asio:x64-windows-static
vcpkg install botan:x64-windows botan:x64-windows-static
(Si vous avez besoin d'une version ARM ou x86 32 bits, veuillez ajuster les options vous-même)
Utilisez ensuite Visual Studio pour ouvrir slnkcptube.sln
et compilez-le vous-même
De même, veuillez d'abord installer les dépendances asio et botan3. De plus, cmake est requis. Vous pouvez l'installer avec le propre package du système :
pkg install asio botan3 cmake
Ensuite, construisez dans le répertoire build
mkdir build
cd build
cmake ..
make
Les étapes sont similaires à FreeBSD. Pour NetBSD, veuillez utiliser pkgin pour installer les dépendances et cmake :
pkgin install asio
pkgin install cmake
OpenBSD Veuillez utiliser pkg_add
pour installer les deux dépendances ci-dessus. DragonflyBSD veuillez utiliser pkg
, l'utilisation est la même que celle de FreeBSD.
Puisque botan-3 n'a pas été inclus dans ces systèmes BSD, vous devez compiler botan-3 vous-même.
Pour les étapes de construction restantes, veuillez vous référer à FreeBSD ci-dessus.
Notez que puisque ces BSD sont livrés avec des versions inférieures du compilateur, veuillez installer une version supérieure de GCC à l'avance.
Les étapes sont similaires à FreeBSD. Veuillez utiliser le gestionnaire de packages fourni avec la distribution pour installer asio, botan3 et cmake.
apk add asio botan3-libs cmake
Ensuite, construisez dans le répertoire build
mkdir build
cd build
cmake ..
make
Il y a deux manières
Pratique 1
Compilez selon le processus normal, supprimez le fichier binaire kcptube qui vient d'être généré et exécutez la commande
make VERBOSE=1
Extrayez ensuite la dernière commande de lien C++ du contenu de sortie et remplacez -lbotan-3
au milieu par le chemin complet de libbotan-3.a, tel que /usr/lib/x86_64-linux-gnu/libbotan-3.a
.
Pratique 2
Ouvrez src/CMakeLists.txt et remplacez target_link_libraries(${PROJECT_NAME} PRIVATE botan-3)
par target_link_libraries(${PROJECT_NAME} PRIVATE botan-3 -static)
Ensuite, il compile normalement. Notez que si le système utilise la glibc, elle sera compilée statiquement avec la glibc et un avertissement concernant getaddrinfo apparaîtra.
Je n'ai pas d'ordinateur Apple, veuillez donc résoudre toutes les étapes vous-même.
L'augmentation du cache de réception peut améliorer les performances de transmission UDP
Vous pouvez utiliser la commande sysctl kern.ipc.maxsockbuf
pour afficher la taille du cache. Si des ajustements sont nécessaires, exécutez la commande (remplacez le nombre par la valeur souhaitée) :
sysctl -w kern.ipc.maxsockbuf=33554434
Ou écrivez dans /etc/sysctl.conf
kern.ipc.maxsockbuf=33554434
Vous pouvez utiliser la commande sysctl net.inet.udp.recvspace
pour vérifier la taille du tampon de réception. Si des ajustements sont nécessaires, exécutez la commande (remplacez le nombre par la valeur souhaitée) :
sysctl -w net.inet.udp.recvspace=33554434
Ou écrivez dans /etc/sysctl.conf
net.inet.udp.recvspace=33554434
Si nécessaire, vous pouvez ajuster la valeur de net.inet.udp.sendspace
en même temps. Il s'agit du paramètre de cache d'envoi.
Pour le cache de réception, vous pouvez utiliser les commandes sysctl net.core.rmem_max
et sysctl net.core.rmem_default
pour afficher la taille du cache de réception.
Si des ajustements sont nécessaires, exécutez la commande (remplacez le nombre par la valeur souhaitée) :
sysctl -w net.core.rmem_max=33554434
sysctl -w net.core.rmem_default=33554434
Ou écrivez dans /etc/sysctl.conf
net.core.rmem_max=33554434
net.core.rmem_default=33554434
Si nécessaire, vous pouvez ajuster les valeurs de net.core.wmem_max
et net.core.wmem_default
en même temps. Il s'agit du paramètre de cache d'envoi.
Étant donné que kcptube utilise en interne une pile unique IPv6 + active l'adresse mappée IPv4 (IPv6 mappé IPv4) pour utiliser à la fois les réseaux IPv4 et IPv6, veuillez vous assurer que la valeur de l'option v6only est 0.
Dans des circonstances normales, aucun paramètre supplémentaire n'est requis. FreeBSD, Linux et Windows autorisent tous le mappage des adresses IPv4 sur IPv6 par défaut.
Si le système ne prend pas en charge IPv6 ou si IPv6 est désactivé, veuillez définir ipv4_only=true dans le fichier de configuration, afin que kcptube revienne à l'utilisation du mode IPv4 à pile unique.
Utiliser la commande
sysctl -w net.inet6.ip6.v6only=0
Après réglage, le mode pile simple + adresse mappée peut écouter la double pile.
Cependant, pour des raisons inconnues, l'adresse mappée IPv4 peut ne pas être activement connectée.
Étant donné qu'OpenBSD bloque complètement les adresses de mappage IPv4, si vous utilisez la double pile sur la plate-forme OpenBSD, vous devez enregistrer deux fichiers de configuration, dont l'un active ipv4_only=1, puis charger les deux fichiers de configuration en même temps lorsque vous utilisez kcptube.
Dans la plupart des cas, cette invite ne sera rencontrée que du côté serveur, pas du côté client.
Si cela est effectivement rencontré sur le client, veuillez vérifier si la valeur de mux_tunnels
est trop élevée (veuillez vous référer au passage au paragraphe "Multiplexage (mux_tunnels=N)").
Dans des circonstances normales, la grande majorité des systèmes BSD ne rencontreront pas ce genre de chose. Seul GhostBSD, qui sera mis à jour au cours du second semestre 2023, rencontrera ce phénomène.
C'est parce que GhostBSD a ajouté cette ligne à /etc/sysctl.conf
:
kern.maxfiles=100000
Cette ligne réduit la limite supérieure à un niveau bien inférieur à la valeur correspondante dans Vanilla FreeBSD.
La solution est simple, supprimez simplement cette ligne. Vous pouvez également le commenter.
Vous pouvez également utiliser la commande sysctl kern.maxfiles=300000
pour modifier temporairement la valeur limite supérieure.
Étant donné que le nombre de fichiers ouverts sur les systèmes Linux est limité à 1024, il est facile de rencontrer ce problème.
Solution temporaire :
ulimit -n
pour afficher la valeur de sortieulimit -n 300000
Solution permanente :
Modifiez /etc/security/limits.conf et ajoutez à la fin
* hard nofile 300000
* soft nofile 300000
root hard nofile 300000
root soft nofile 300000
Puisque les données TCP doivent être transmises, la validation des données ne peut être ignorée, tout comme TCP lui-même.
Qu'il soit chiffré ou non, kcptube réduira la MTU de 2 octets et ajoutera 2 octets de données.
Si l'option de cryptage a été utilisée, les 2 octets de données ajoutés constituent le IV généré temporairement.
Si vous choisissez de ne pas utiliser la fonction de cryptage, les données de 2 octets ajoutées constituent le code de contrôle, qui est le XOR des bits haut et bas du CRC32.
Il convient de rappeler que l’utilisation de codes de contrôle ne peut toujours pas empêcher à 100 % les erreurs de contenu, et il en va de même pour TCP lui-même. Si vous avez vraiment besoin d'être précis, activez l'option de cryptage.
Bien que KCP Tube ait une fonction de « multiplexage », il n'est pas activement ouvert par défaut. Sans cette fonctionnalité, pour chaque connexion entrante acceptée, une connexion sortante correspondante est créée.
La raison est d'éviter la QoS de l'opérateur. Dans l'état de multiplexage, une fois qu'un certain numéro de port est QoS, les autres sessions partageant le même numéro de port seront bloquées en même temps jusqu'à ce que le numéro de port soit modifié.
Les connexions sont indépendantes les unes des autres. Même si un certain numéro de port est QoS, seule cette session sera affectée et les autres sessions ne le seront pas.
Sauf si le programme hébergé génère un grand nombre de connexions indépendantes. Dans ce cas, KCP Tube créera un grand nombre de canaux KCP, qui consommeront plus de ressources CPU pendant le processus de communication.
Si vous souhaitez réellement utiliser la fonction « multiplexage », vous pouvez vous référer aux catégories suivantes :
Scénarios adaptés à l'utilisation du « multiplexage » :
Scénarios où le « multiplexage » n'est pas nécessaire :
Lorsque le « Multiplexage » est activé, KCPTube précréera N liens et toutes les nouvelles connexions entrantes transmettront les données des liens existants au lieu de créer de nouveaux liens séparément. À l'heure actuelle, le délai d'attente du canal KCP est de 30 secondes.
D'une manière générale, définir `mux_tunnels sur 3 ~ 10 est suffisant, et il n'est pas nécessaire de définir une valeur trop élevée.
Pour réduire la latence, kcptube active l'option TCP_NODELAY. Pour certains scénarios d'application à trafic important, la quantité de transmission de données TCP peut être réduite.
Sur la base du KCP original, les modifications suivantes ont été apportées :
flush()
d'origine transfère d'abord les données à envoyer à la file d'attente d'envoi, puis refait les trois choses "envoyer de nouveaux paquets de données", "renvoyer des paquets de données" et "envoyer des paquets ACK" dans le même cycle. La version modifiée effectue d'abord une « retransmission des paquets de données » et une « transmission des paquets ACK », puis « transfère les données à envoyer à la file d'attente d'envoi » et les envoie pendant la période de transfert.check()
d'origine parcourra à nouveau la file d'attente d'envoi à chaque fois pour trouver l'horodatage de retransmission du point atteint. La version modifiée devient : lire le premier horodatage de la table de mappage triée, éliminant l'étape de recherche.De plus, la version originale comporte des "bugs", et kcptube en aura également. Par exemple:
Kcptube a donc mis en place un plan de suspension plus évident. Pour les données TCP, lorsque la limite de réception est atteinte (la file d'attente est pleine), la réception des données TCP sera suspendue jusqu'à ce qu'il y ait de la place puis reprise ; pour les données UDP, le paquet sera perdu directement lorsque la limite de réception sera atteinte.
Cette limitation n’aura fondamentalement aucun impact sur les scénarios d’application dans lesquels le volume de transmission n’est pas important.
Le pool de threads utilisé par kcptube provient de BS::thread_pool, avec quelques modifications pour le traitement de chiffrement et de déchiffrement parallèle lors de plusieurs connexions.
Le code est écrit de manière très décontractée et je l'écris partout où je pense, donc la mise en page prête à confusion. Pour être précis, c'est très déroutant.
Certaines lignes de code sont aussi longues que des perches de bambou, principalement parce que j'étais trop paresseux pour changer de ligne afin de suivre le fil de ma pensée lors de l'écriture. Après tout, je n'utilise pas vim/emacs. Lorsque j'utilise un IDE, la taille du texte définie dans la zone de code de l'IDE est différente de la taille du texte dans les autres zones, et même les polices sont différentes, ce qui m'aide à atténuer le problème de confusion.
Quant aux sentiments des lecteurs... ils seront certainement mécontents. Ce ne sont pas mes affaires, laisse tomber.