この記事を作った動機
最近 SSHFS やら TCP を使った通信において、VPN を経由した通信(ping において time=40ms 前後)が通信経路的には、100Mbps 程度のスループットが出るはずであるが、実際には、10Mbps 程度をうろついてめちゃくちゃに遅いということがあった。その症状はランダムであり、場合によってはそこそこ速度が出る場合もあれば、全然出ない場合もあるということがあった。
当初は、SoftEther VPN のコネクション数をいじったりしていたが、あまり効果が見られない場合があり、最終的に TCP の輻輳制御などに問題があるのではないかと思った。ただ設定をいちいち細々と調べるのはめんどくさかったので、ローカルのLLMに話題を投げてみたところ、実際に効果が見受けられる設定が出てきたので、それをとりあえず記録しておきたい。
設定内容 (/etc/sysctl.d/tcp.conf として保存)
以下の設定を/etc/sysctl.d/tcp.confとして保存したあと、既存の TCP コネクションが古い設定で動き続けるのを防ぐため、再起動する。輻輳制御アルゴリズムなどをデフォルトから変更している。
net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr
net.ipv4.tcp_window_scaling=1
net.core.rmem_max=16777216
net.core.wmem_max=16777216
net.ipv4.tcp_rmem=4096 87380 16777216
net.ipv4.tcp_wmem=4096 65536 16777216
設定が反映されたか確認
sysctl net.core.default_qdisc
sysctl net.ipv4.tcp_congestion_control
sysctl net.ipv4.tcp_window_scaling
sysctl net.core.rmem_max
sysctl net.core.wmem_max
sysctl net.ipv4.tcp_rmem
sysctl net.ipv4.tcp_wmem
# net.core.default_qdisc = fq
# net.ipv4.tcp_congestion_control = bbr
# net.ipv4.tcp_window_scaling = 1
# net.core.rmem_max = 16777216
# net.core.wmem_max = 16777216
# net.ipv4.tcp_rmem = 4096 87380 16777216
# net.ipv4.tcp_wmem = 4096 65536 16777216
もともとの設定
私の Arch Linux 環境で、インストール時からネットワーク設定に特段変更を加えていない機材から設定を読み出すと以下のような結果が得られた。輻輳制御アルゴリズムがbbrではなくcubicになっていたりするなど、色々設定が異なることがわかる。詳しいことは LLM に提案させて試しただけなので分かっていない。
net.core.default_qdisc = fq_codel
net.ipv4.tcp_congestion_control = cubic
net.ipv4.tcp_window_scaling = 1
net.core.rmem_max = 4194304
net.core.wmem_max = 4194304
net.ipv4.tcp_rmem = 4096 131072 33554432
net.ipv4.tcp_wmem = 4096 16384 4194304
設定前に見られた挙動
設定前に見られた挙動としては、ファイル転送などにおいて、本来10 MB/s程度の速度が出るところで、1.6 MB/s くらいしか出なかったり、システムモニターでネットワーク通信の速度を監視していると、ノコギリの刃先のように、TCP の制御でウィンドウサイズが大きくなって通信速度が出始めたと思ったら一気に通信速度が落ち込んで下がるといった挙動で安定していなかった。
今後はこれでしばらく使ってみてパケットロスや速度が落ち込む場合などがないか、様子を見てみようと考えている。
設定前の様子
設定後の様子
参考にしたサイトとか
- ローカルLLM (Gemma4-31B) (2026年9月21日)