kcptube
Release 20241201
英語版はここをクリックしてください
大手 3 つの通信事業者のホーム ブロードバンドを使用したことがあり、ホーム ブロードバンドの相互接続が必要な場合は、ほとんどの場合、UDP の速度制限を経験することになります。 UDP の主要 3 事業者の QoS を回避するために、UDP Hop と呼ばれる別のツールを作成しました。原則は、定期的に新しい接続を確立することです (ポート番号を変更し、新しいアドレスに接続します)。
ただし、UDP ホップは UDP トラフィックの転送のみをサポートします。 UDP を使用して TCP トラフィックを転送できるようにするために、KCP Tube があります。 KCP の信頼性の高い再送信は、転送された TCP パケットが失われないことを保証するために使用されます。
KCP Tube を作成するもう 1 つの理由は、他の KCP 転送ツールは TCP トラフィックのみを転送できるが、UDP トラフィックを転送するには KCP を使用する必要があるためです。主にゲームをプレイする際の利便性を目的としています。
もちろん、udphop と kcptube は実際には同時に考案されました。そこで、便宜上、まず KCP Tube を設定してフレームワークをセットアップし、次に KCP Tube に基づいて UDP Hop に切り出します。次に、UDP ホップ パッチ コードを逆マージして KCP チューブに戻します。
ホーム ブロードバンド フル コーン NAT ユーザーを容易にするために、KCP Tube は基本サーバー モードで実行するときに STUN を使用して穴を開けることができ、IPv4 と IPv6 の両方をサポートします。
KCP 自体の目的と同様に、KCP Tube の主な目的は、非常に大規模なトラフィックの送信を優先することではなく、遅延を削減することです。では、非常に大規模なトラフィックを送信できるのでしょうか?はい、ただし、その効果は既存の TCP-KCP 転送ツールほど良くない可能性があります。
現在、3 つのモードがサポートされています。
クライアントの時刻とサーバーの時刻は同期する必要があり、時刻の差は 255 秒を超えることができないことに注意してください。
Wiki ページまたはドキュメント ページにアクセスしてください。
プロファイル ジェネレーターが必要な場合は、ここにアクセスしてください: KCPTube Generator
kcptube config.conf
クライアントモードの例:
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
サーバーモードの例:
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=./
注: 初めて接続するとき、サーバーはクライアントにポート範囲を通知するため、クライアント モードのlisten_portサーバー モードのdestination_portと必ずしも一致する必要はありませんが、両側のポートが一致しない場合があります。クライアントによって書き込まれるポート番号の範囲は、クライアントが間違ったポートを選択して接続に失敗することを防ぐために、サーバーの範囲を超えることはできません。
リスニングするネットワーク カードを指定する場合は、ネットワーク カードの IP アドレスを指定し、1 行追加します。
listen_on=192.168.1.1
複数のポートと複数のネットワーク カードをリッスンする場合は、複数の設定ファイルを分離します。
kcptube config1.conf config2.conf
接続する前に接続がスムーズかどうかをテストしたい場合は、 --tryオプションを追加できます。
kcptube --try config1.conf
または
kcptube config1.conf --try
--check-configオプションを使用して、構成ファイルが正しいことを確認します。
kcptube --check-config config1.conf
または
kcptube config1.conf --check-config
クライアントモードの例:
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
サーバーモードの例:
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
クライアントモードの例:
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
サーバーモードの例:
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
| 名前 | 設定可能値 | 必須 | 述べる |
|---|---|---|---|
| モード | クライアント サーバ リレー | はい | クライアント・サーバー中継ノード |
| 聞いてください | ドメイン名またはIPアドレス | いいえ | ドメイン名またはIPアドレスのみを入力できます。複数のアドレスはカンマで区切ってください |
| リッスンポート | 1-65535 | はい | サーバーとして実行する場合、ポート範囲を指定できます |
| 宛先ポート | 1-65535 | はい | クライアントとして実行する場合、ポート範囲を指定できます。複数のアドレスはカンマで区切ってください |
| 宛先アドレス | IPアドレス、ドメイン名 | はい | IPv6 アドレスを入力するときに角括弧は必要ありません |
| dport_refresh | 0～32767 | いいえ | 単位は「秒」です。空白のままにすると、デフォルト値の 60 秒が使用されます。 1 ～ 20 は 20 秒として計算され、32767 を超える場合は 32767 秒として計算されます。 無効にするには 0 に設定します。 |
| 暗号化アルゴリズム | AES-GCM AES-OCB ちゃちゃ20 xchacha20 なし | いいえ | AES-256-GCM-AEAD AES-256-OCB-AEAD ChaCha20-ポリ1305 XChaCha20-ポリ1305 暗号化なし |
| 暗号化_パスワード | 任意の文字 | 状況によります | encryption_algorithm が設定されており、 none ではない場合は必須です |
| udp_timeout | 0～65535 | いいえ | 単位は「秒」です。デフォルト値は 180 秒です。0 に設定すると、このオプションは UDP アプリケーション ↔ kcptube 間のタイムアウト設定を表します。 |
| キープアライブ | 0～65535 | いいえ | 単位は「秒」です。デフォルト値は 0 で、これはキープアライブを無効にすることと同じです。 このオプションは、2 つの KCP エンド間のキープアライブを指します。 チャネルが応答を停止したかどうかを検出するために一方的に有効にすることができます。 30 秒経過しても応答がない場合、チャネルは閉じられます。 |
| マルチプレクサトンネル | 0～65535 | いいえ | デフォルト値は 0 で、多重化チャネルを使用しないことと同じです。このオプションは、2 つの KCP エンド間の多重化チャネルの数を指します。このオプションはクライアント側でのみ有効です。 |
| スタンサーバー | STUNサーバーアドレス | いいえ | listen_port がポート範囲モードの場合は使用できません |
| ログパス | ログを保存するディレクトリ | いいえ | ファイル自体を指すことはできません |
| 糞 | uint8:uint8 | いいえ | 形式はfec=D:Rで、たとえばfec=20:3と入力できます。注: D + R の最大合計値は 255 であり、この数値を超えることはできません。 コロンの両側の値 0 は、オプションが使用されないことを示します。設定は両端で同じである必要があります。 詳細については、FEC の使用ガイドを参照してください。 |
| mtu | 正の整数 | いいえ | 現在のネットワーク MTU 値。kcp_mtu の自動計算に使用されます。 |
| kcp_mtu | 正の整数 | いいえ | デフォルト値は 1440 です。 ikcp_setmtu() を呼び出して設定される値は、UDP パケット内のデータ コンテンツの長さです。 |
| kcp | マニュアル 速い1-6 レギュラー1-5 | はい | 手動で高速の通常速度を設定 （末尾の数字：数字が小さいほど速度が速くなります） |
| kcp_sndwnd | 正の整数 | いいえ | デフォルト値は以下の表に示されており、個別にオーバーライドできます。 |
| kcp_rcvwnd | 正の整数 | いいえ | デフォルト値は以下の表に示されており、個別にオーバーライドできます。 |
| kcp_nodelay | 正の整数 | 状況によります | kcp=manual の場合は必須。デフォルト値は以下の表に示されています。 |
| kcp_interval | 正の整数 | 状況によります | kcp=manual の場合は必須。デフォルト値は以下の表に示されています。 |
| kcp_resend | 正の整数 | 状況によります | kcp=manual の場合は必須。デフォルト値は以下の表に示されています。 |
| kcp_nc | はい 真実 1 いいえ 間違い 0 | 状況によります | kcp=manual の場合は必須です。デフォルト値は以下の表に示されています。 |
| アウトバウンド帯域幅 | 正の整数 | いいえ | 送信帯域幅。通信プロセス中に kcp_sndwnd の値を動的に更新するために使用されます。 |
| 受信帯域幅 | 正の整数 | いいえ | 受信帯域幅。通信プロセス中に kcp_rcvwnd の値を動的に更新するために使用されます。 |
| ipv4_のみ | はい 真実 1 いいえ 間違い 0 | いいえ | システムで IPv6 が無効になっている場合は、このオプションを有効にして、yes、true、または 1 に設定する必要があります。 |
| ipv6_のみ | はい 真実 1 いいえ 間違い 0 | いいえ | IPv4アドレスを無視する |
| 爆発 | はい 真実 1 いいえ 間違い 0 | いいえ | KCP フロー制御設定を無視し、できるだけ早くパケットを転送するようにしてください。過大な負荷がかかる可能性があります |
| [リスナー] | 該当なし | はい (リレーモードのみ) | リレー モードのラベル。リスニング モードで KCP を指定するために使用されます。このラベルの設定は、クライアントとの対話データを示します。 |
| [フォワーダー] | 該当なし | はい (リレーモードのみ) | リレー モードのラベル。転送モードの KCP を指定するために使用されます。このラベルを設定すると、サーバーとの対話データが示されます。 |
| [カスタム入力] | 該当なし | いいえ | カスタムマッピングモードのラベルは、カスタムマッピングの使用方法を参照してください。 |
| [カスタム入力_tcp] | 該当なし | いいえ | カスタムマッピングモードのラベル 使用方法については、カスタムマッピングの使用方法を参照してください。 |
| [カスタム入力_udp] | 該当なし | いいえ | カスタムマッピングモードのラベル 使用方法については、カスタムマッピングの使用方法を参照してください。 |
このうち、 encryption_algorithmとencryption_password通信の両端で一致している必要があります。
| 名前 | 設定可能値 | 必須 | 述べる |
|---|---|---|---|
| fib_ingress | 0～65535 | いいえ | インバウンド接続で使用される FIB |
| fib_egress | 0～65535 | いいえ | アウトバウンド接続に使用される FIB |
利用可能なサフィックス: K/M/G
サフィックスは大文字と小文字が区別され、大文字は 2 進数 (1024) として計算され、小文字は 10 進数 (1000) として計算されます。
帯域幅が 1000 bps であることを示す 1000 を入力します。
帯域幅が 100 kbps (100000 bps) であることを示す 100k を入力します。
帯域幅が 100 Kbps (102400 bps) であることを示す 100K を入力します。
帯域幅が 100 Mbps (102400 Kbps) であることを示す 100M を入力します。
帯域幅が 1 Gbps (1024 Mbps) であることを示す「1G」を入力します。
Bps (バイト/秒) ではなく、bps (ビット/秒) であることに注意してください。
送信ウィンドウの輻輳を避けるために、入力される帯域幅の値は実際の帯域幅を超えてはいけないことに注意してください。
重要な注意事項:
KCPTube は、KCP リンクが確立されてから約 5 秒後に、ハンドシェイク パケットの遅延値と outbound_bandwidth とinbound_bandwidth の値に基づいて、KCP 送信ウィンドウ サイズを計算して設定します。セットアップ完了後、一定期間は通信量が大きく変動したり、突然通信量がゼロになったり、回復までに数秒かかる可能性が高くなります。
| クイックモード | kcp_sndwnd | kcp_rcvwnd | kcp_nodelay | kcp_interval | kcp_resend | kcp_nc |
|---|---|---|---|---|---|---|
| 速い1 | 2048年 | 2048年 | 1 | 1 | 2 | 1 |
| 速い2 | 2048年 | 2048年 | 2 | 1 | 2 | 1 |
| 速い3 | 2048年 | 2048年 | 1 | 1 | 3 | 1 |
| 速い4 | 2048年 | 2048年 | 2 | 1 | 3 | 1 |
| 速い5 | 2048年 | 2048年 | 1 | 1 | 4 | 1 |
| 速い6 | 2048年 | 2048年 | 2 | 1 | 4 | 1 |
| 通常速度モード | kcp_sndwnd | kcp_rcvwnd | kcp_nodelay | kcp_interval | kcp_resend | kcp_nc |
|---|---|---|---|---|---|---|
| レギュラー1 | 1024 | 1024 | 1 | 1 | 5 | 1 |
| レギュラー2 | 1024 | 1024 | 2 | 1 | 5 | 1 |
| レギュラー3 | 1024 | 1024 | 0 | 1 | 2 | 1 |
| レギュラー4 | 1024 | 1024 | 0 | 15 | 2 | 1 |
| レギュラー5 | 1024 | 1024 | 0 | 30 | 2 | 1 |
このうち、パケット損失率が高い (10% を超える) ほど、kcp_nolay=1 のほうが kcp_nolay=2 よりも有利になります。パケットロス率がそれほど高くない場合は、kcp_nolay=2 にすると遅延ジッターが滑らかになります。
パケットロスの少ない環境では、各モードの使用に適しています。違いは、無駄なトラフィックが多いか少ないかだけであり、最大速度の上限が異なります。このうち、 Regular3 は通信量の無駄があまりありません。
同時にblast=1設定を有効にすることをお勧めします。
パケット損失の多い環境では、FEC 設定をオーバーレイすることを検討してください。詳細については、FEC の使用ガイドを参照してください。
詳細についてはパラメータリストを参照してください。
ホールパンチされた IP アドレスとポートが初めて取得された後、およびホールパンチされた IP アドレスとポートが変更された後、ip_address.txt ファイルが Log ディレクトリに作成され (存在する場合は上書きされます)、IPアドレスとポートが書き込まれます。
同時に取得した穴加工アドレスがコンソールに表示されます。
log_path=ファイル自体ではなく、ディレクトリを指す必要があります。
ログ ファイルに書き込む必要がない場合は、 log_path行を削除します。
NatTypeTeste から見つかった一般的な STUN サーバー:
Natter から見つかった STUN サーバー:
その他の STUN サーバー: public-stun-list.txt
使いやすさを考慮して、複数のプラットフォーム用のバイナリ実行可能ファイルが提供されています。
プリコンパイルされたバイナリはすべて静的にコンパイルされます。 Linux 版は libc を除いて基本的に静的コンパイルなので、glibc (2.31) 用と musl 用の 2 つのバージョンが用意されています。
Linux 環境の場合は、Docker イメージも提供されています (現時点では x64 のみ)。kcptube_docker_image.zip をダウンロードして解凍し、 docker load -i kcptube_docker.tarを使用してインポートします。
インポート後の使用方法は次のとおりです。
docker run -v /path/to/config_file.conf:/config_file.conf kcptube config_file.conf
例えば：
docker run -v /home/someone/config1.conf:/config1.conf kcptube config1.conf
FreeBSD ユーザーは、ダウンロードしたバイナリ ファイルを/usr/local/bin/にコピーして、コマンドを実行できます。
chmod +x /usr/local/bin/kcptube
対応するサービスファイルは本プロジェクトのserviceディレクトリに用意されています。
/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/etc/rc.confにkcptube_enable="YES"行を追加します。最後に、 service kcptube startを実行してサービスを開始します
コンパイラは C++20 をサポートする必要があります
依存ライブラリ:
vcpkg を使用して依存パッケージasioとbotan事前にインストールしてください。 コマンドは次のとおりです。
vcpkg install asio:x64-windows asio:x64-windows-static
vcpkg install botan:x64-windows botan:x64-windows-static
(ARM または 32 ビット x86 バージョンが必要な場合は、オプションを自分で調整してください)
次に、Visual Studio を使用してslnkcptube.slnを開き、自分でコンパイルします。
同様に、最初に依存関係である asio と botan3 をインストールしてください。さらに、システム独自の pkg を使用してインストールすることもできます。
pkg install asio botan3 cmake
次に、ビルドディレクトリにビルドします
mkdir build
cd build
cmake ..
make
この手順は FreeBSD の場合と同様で、pkgin を使用して依存関係と cmake をインストールしてください。
pkgin install asio
pkgin install cmake
OpenBSD 上記 2 つの依存関係をインストールするには、 pkg_add使用してください。 DragonflyBSD ではpkg使用してください。使い方は FreeBSD と同じです。
botan-3 はこれらの BSD システムに含まれていないため、botan-3 を自分でコンパイルする必要があります。
残りのビルド手順については、上記の FreeBSD を参照してください。
これらの BSD には下位のコンパイラ バージョンが付属しているため、事前に上位バージョンの GCC をインストールしてください。
手順は FreeBSD と同様です。asio、botan3、cmake をインストールするには、ディストリビューションに付属するパッケージ マネージャーを使用してください。
apk add asio botan3-libs cmake
次に、ビルドディレクトリにビルドします
mkdir build
cd build
cmake ..
make
2つの方法があります
練習1
通常のプロセスに従ってコンパイルし、生成されたばかりの kcptube バイナリ ファイルを削除して、コマンドを実行します。
make VERBOSE=1
次に、出力内容から最後の C++ リンク コマンドを抽出し、中央の-lbotan-3 libbotan-3.a のフル パス( /usr/lib/x86_64-linux-gnu/libbotan-3.a
練習2
src/CMakeLists.txt を開き、 target_link_libraries(${PROJECT_NAME} PRIVATE botan-3)をtarget_link_libraries(${PROJECT_NAME} PRIVATE botan-3 -static)に変更します。
その後、正常にコンパイルされます。システムが glibc を使用している場合、glibc とともに静的にコンパイルされ、getaddrinfo に関する警告がポップアップ表示されることに注意してください。
私は Apple コンピュータを持っていないので、すべての手順を自分で解決してください。
受信キャッシュを増やすと、UDP 送信パフォーマンスが向上します。
コマンドsysctl kern.ipc.maxsockbuf使用すると、キャッシュ サイズを表示できます。調整が必要な場合は、次のコマンドを実行します (数値を目的の値に変更します)。
sysctl -w kern.ipc.maxsockbuf=33554434
または/etc/sysctl.confに書き込みます
kern.ipc.maxsockbuf=33554434
コマンドsysctl net.inet.udp.recvspace使用して、受信バッファ サイズを確認できます。調整が必要な場合は、次のコマンドを実行します (数値を目的の値に変更します)。
sysctl -w net.inet.udp.recvspace=33554434
または/etc/sysctl.confに書き込みます
net.inet.udp.recvspace=33554434
必要に応じて、 net.inet.udp.sendspaceの値を同時に調整できます。送信キャッシュの設定です。
受信キャッシュの場合、コマンドsysctl net.core.rmem_maxおよびsysctl net.core.rmem_defaultを使用して受信キャッシュ サイズを表示できます。
調整が必要な場合は、次のコマンドを実行します (数値を目的の値に変更します)。
sysctl -w net.core.rmem_max=33554434
sysctl -w net.core.rmem_default=33554434
または/etc/sysctl.confに書き込みます
net.core.rmem_max=33554434
net.core.rmem_default=33554434
必要に応じて、 net.core.wmem_maxとnet.core.wmem_defaultの値を同時に調整できます。送信キャッシュの設定です。
kcptube は内部で IPv6 シングル スタックを使用し、IPv4 と IPv6 の両方のネットワークを使用するために IPv4 マップされたアドレス (IPv4 マップされた IPv6) をオンにするため、v6only オプションの値が 0 であることを確認してください。
通常の状況では、FreeBSD、Linux、および Windows ではすべて、デフォルトで IPv4 アドレスを IPv6 にマッピングできます。
システムが IPv6 をサポートしていない場合、または IPv6 が無効になっている場合は、kcptube が IPv4 シングルスタック モードの使用にフォールバックするように、構成ファイルで ipv4_only=true を設定してください。
コマンドを使用する
sysctl -w net.inet6.ip6.v6only=0
設定後は、シングル スタック + マップド アドレス モードでデュアル スタックをリッスンできるようになります。
ただし、不明な理由により、IPv4 マップされたアドレスがアクティブに接続されない可能性があります。
OpenBSD は IPv4 マッピング アドレスを完全にブロックするため、OpenBSD プラットフォームでデュアル スタックを使用する場合は、2 つの設定ファイルを保存し、そのうちの 1 つで ipv4_only=1 を有効にし、kcptube を使用するときに両方の設定ファイルを同時にロードする必要があります。
ほとんどの場合、このプロンプトはサーバー側でのみ表示され、クライアント側では表示されません。
実際にクライアントでこの問題が発生した場合は、 mux_tunnelsの値が高すぎないかどうかを確認してください (ちなみに、「多重化 (mux_tunnels=N)」の段落を参照してください)。
通常の状況では、大多数の BSD システムではこのような現象は発生しません。2023 年後半に更新される GhostBSD だけがこの現象に遭遇します。
これは、GhostBSD が次の行を/etc/sysctl.confに追加したためです。
kern.maxfiles=100000
この行は、上限を標準の FreeBSD の対応する値よりも大幅に低くします。
解決策は簡単で、この行を削除するだけです。コメントアウトすることもできます。
コマンドsysctl kern.maxfiles=300000使用して、上限値を一時的に変更することもできます。
Linux システムではオープン ファイルの数が 1024 に制限されているため、この問題が発生しやすくなります。
一時的な解決策:
ulimit -n実行して出力値を表示します。ulimit -n 300000を実行してください。恒久的な解決策:
/etc/security/limits.conf を編集して最後に追加します
* hard nofile 300000
* soft nofile 300000
root hard nofile 300000
root soft nofile 300000
TCP データは送信する必要があるため、TCP 自体と同様にデータ検証を無視することはできません。
暗号化されているかどうかに関係なく、kcptube は MTU を 2 バイト削減し、2 バイトのデータを追加します。
暗号化オプションが使用されている場合、追加された 2 バイトのデータが一時的に生成された IV になります。
暗号化機能を使用しない場合、付加される 2 バイトのデータは、CRC32 の上位ビットと下位ビットの XOR であるチェック コードです。
チェック コードを使用してもコンテンツ エラーを 100% 防ぐことはできず、同様のことが TCP 自体にも当てはまることに注意してください。本当に正確にする必要がある場合は、暗号化オプションを有効にしてください。
KCP Tube には「多重化」機能がありますが、デフォルトでは積極的に開かれません。この機能を使用しない場合、受け入れられるすべての受信接続に対して、対応する送信接続が作成されます。
その理由は、オペレータの QoS を回避するためです。多重化状態では、特定のポート番号が QoS になると、そのポート番号が変更されるまで、同じポート番号を共有する他のセッションが同時にブロックされます。
接続は互いに独立しています。特定のポート番号が QoS である場合でも、このセッションのみが影響を受け、他のセッションは影響を受けません。
ホストされるプログラムが多数の独立した接続を生成しない限り。この場合、KCP チューブは多数の KCP チャネルを作成するため、通信プロセス中により多くの CPU リソースを消費します。
どうしても「多重化」機能を使いたい場合は、以下のカテゴリーを参照してください。
「多重化」の使用に適したシナリオ:
「多重化」が必要ないシナリオ:
「多重化」が有効な場合、KCPTube は N 個のリンクを事前に作成し、すべての新しい受信接続は新しいリンクを個別に作成するのではなく、既存のリンクからデータを送信します。このとき、KCP チャネルのタイムアウト時間は 30 秒です。
一般に、「mux_tunnels」を 3 ～ 10 に設定すれば十分であり、あまり高い値を設定する必要はありません。
待ち時間を短縮するために、kcptube は TCP_NODELAY オプションを有効にします。一部の大規模トラフィック アプリケーション シナリオでは、TCP データ送信の量が削減される場合があります。
元の KCP に基づいて、次の変更が加えられました。
flush()まず送信するデータを送信キューに転送し、その後「新規データパケットの送信」「データパケットの再送信」「ACKパケットの送信」の3つを同一サイクルでやり直します。修正版では、まず「データパケットの再送」と「ACKパケットの送信」を行った後、「送信するデータを送信キューに転送」し、転送期間内に送信します。check()到達ポイントの再送信タイムスタンプを見つけるために毎回送信キューを再度トラバースします。変更されたバージョンは次のようになります。ソートされたマッピング テーブルから最初のタイムスタンプを読み取り、検索ステップを削除します。さらに、オリジナル版には「バグ」があり、kcptubeにもバグがあります。例えば：
そこでkcptubeはより明白な停止計画を立てた。 TCP データの場合、受信制限に達すると (キューがいっぱいになると)、TCP データの受信は空きができるまで一時停止され、その後再開されます。UDP データの場合、受信制限に達するとパケットは直接失われます。
この制限は、送信量が大きくないアプリケーション シナリオには基本的に影響しません。
kcptube によって使用されるスレッド プールは BS::thread_pool に由来しており、複数の接続中の並列暗号化および復号化処理のためにいくつかの変更が加えられています。
コードは非常にカジュアルに書いていて、思いついたところに書いているのでレイアウトがわかりにくいです。正確に言うと、非常に混乱します。
コード行の中には竹の棒ほど長いものもありますが、これは主に、書いているときに思考の流れを追うために行を変更するのが面倒だったためです。結局のところ、私は vim/emacs を使用しません。 IDE を使用すると、IDE のコード領域に設定されたテキスト サイズが他の領域のテキスト サイズと異なり、さらにフォントも異なるため、混乱の問題が軽減されます。
読者の気持ちはというと…間違いなく不幸になるでしょう。それは私には関係ありません、放っておいてください。
