【テクニカル・上級編】ルーターのCPU負荷とメモリ消費のボトルネック – 家庭用ネットワーク・IoT・モバイル通信実践ガイド

ルーターの「脳」を酷使するな：パケット処理のボトルネックとハードウェア選定の深淵

ネットワークエンジニアとして現場に立つと、たびたび遭遇する光景がある。「最新のWi-Fi 7対応ルーターを買ったのに、なぜかスループットが頭打ちになる」「VPNを張った途端、レイテンシが跳ね上がる」。

家電量販店のパッケージに書かれた「最大通信速度」という甘い言葉を信じてはいけない。家庭用ルーターの心臓部であるCPUとメモリは、実は極めて過酷な環境に置かれている。本稿では、パケットがルーターの深淵を通過する際、何がハードウェアを蝕み、我々はどう最適化すべきかを解き明かす。

パケットの迷宮：ハードウェア・オフロードの限界

一般的なホームルーターにおいて、パケット処理の主役はCPUだ。しかし、全ての処理をCPUに任せていては、ギガビットイーサネットのラインレートを維持することは不可能に近い。

多くのルーターは Fast Path や Shortcut Forwarding と呼ばれるハードウェア・オフロード機能を持っている。これは、一度ルーティングテーブルに登録されたフローを、CPUを介さずにスイッチングチップ（ASIC）レベルで処理する仕組みだ。

問題は、この「ショートカット」が成立しないケースにある。

VPN（IPsec/OpenVPN/WireGuard）: 暗号化処理はほぼCPUの演算能力に依存する。
パケットフィルタリング/IDS: iptables や nftables で複雑なルールを適用すると、パケット毎にカーネル空間でのコンテキストスイッチが発生する。
QoS制御: トラフィックシェーピングは、一度パケットをバッファにキューイングする必要があるため、オフロードが強制的に無効化される。

これらの処理が重なると、CPU使用率は瞬く間に100%に張り付き、SoftIRQ（ソフトウェア割り込み）による遅延が蓄積し、結果としてパケットロスやRTT（Round Trip Time）の増大を招く。

トランスポート層のチューニング：TCPバッファとウィンドウ制御

ルーターのメモリ不足は、TCPの Window Size に直接的な影響を与える。ルーターがパケットを処理しきれずメモリ上のキューが溢れれば、Tail Drop が発生し、TCPのスロースタートが繰り返される。

Linuxベースのルーターを運用している場合、以下の sysctl パラメータを調整することで、バッファ管理を最適化できる。

# TCPウィンドウサイズの自動チューニングを有効化
# メモリに余裕がある場合、バッファを拡大してスループットを稼ぐ
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

# ルーターのキューイング遅延を緩和するための設定
# BBRアルゴリズムを有効化し、パケットロスに対する耐性を向上させる
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

特に BBR（Bottleneck Bandwidth and RTT）は、パケットロスを輻輳とみなさず、あくまでRTTとスループットの均衡点を探るため、家庭内のような不安定な無線環境において非常に有効だ。

TLSハンドシェイクとセキュリティの代償

現代のトラフィックのほとんどはTLSで保護されている。ルーターで SNI（Server Name Indication）ベースのフィルタリングや、ディープパケットインスペクション（DPI）を行う場合、ルーターはTLSのハンドシェイク過程を監視しなければならない。

ここで発生するボトルネックは、CPUの「暗号化処理」だけではない。ハンドシェイク時に交換される証明書の検証や、暗号スイートのネゴシエーション処理が、ルーターのメモリを消費する。特に、安価なルーターで大量の同時接続（例えば、IoTデバイスが頻繁にクラウドへ接続を試みる環境）が発生すると、メモリの断片化（フラグメンテーション）が深刻化し、ルーターのフリーズを引き起こす。

回避策：ルーターに負荷をかけない設計

1. 名前解決の分離: ルーターのDNSリレー機能を使わず、CoreDNS 等を立てたラズパイやサーバーにDNS処理をオフロードする。
2. VPNの適材適所: 全トラフィックをVPNへ流すのではなく、Policy Based Routing（PBR）を使用して、必要な通信のみをルーティングする。

選定基準としての「真のスペック」

ルーター選定において、パッケージの速度表記を見るのはやめよう。代わりに以下の点を確認すべきだ。

SoCのアーキテクチャ: ARM v8以降の Cortex-A53 以上を推奨。できれば AES-NI 命令セットをサポートしているものを選びたい（VPN性能に直結する）。
RAMの実装量: 512MB以上が現代のミニマムラインだ。特に NAT テーブルの保持数や、将来的なIPv6移行を考慮すると、256MBでは心許ない。
オープンソース対応: OpenWrt や pfSense をインストールできるか否か。これは、メーカーのサポート終了後もカーネルアップデートを継続し、脆弱性から身を守るための唯一の手段となる。

最後に：ネットワークは「生き物」である

パケットは、ルーターという迷宮を通る際、常に物理的な制約と戦っている。ハードウェアリソースを極限まで使い切ることは、アーキテクトとしての醍醐味でもあるが、家庭環境においては「安定」こそが最大のパフォーマンスだ。

パケットが効率よく、かつ最短距離でターゲットまで到達できるよう、我々はルーターという小さなコンピュータを、OSのカーネルチューニングから物理配置に至るまで、丹念にケアし続けなければならない。

次は、メッシュWi-Fiにおける「ローミングの最適化」と、バックホール帯域を食い尽くす「マルチキャストトラフィック」の制御について深掘りしようと思う。ネットワークの深淵は、まだまだ深い。