こんにちは！NOC（ネットワークオペレーションセンター）で日々、張り詰めた空気の中でネットワークの番人をしているシニアエンジニアです。数え切れないほどの通信障害や、夜中の「回線が遅い！」という悲鳴のようなアラート対応をくぐり抜けてきました。
インフラの世界に足を踏み入れたばかりの頃って、専門用語の壁が高くそびえ立っていて圧倒されてしまいますよね。「パケット？」「TCPウィンドウ？」「スループット？」……なんだか呪文のように聞こえるかもしれません。でも、安心してください。一歩ずつ、身近な例えを交えながら一緒に紐解いていけば、必ず「なるほど！」と腑に落ちる瞬間がやってきます。
今回は、ネットワークのスピードの限界に挑み、ボトルネックを暴き出すための強力な相棒 iperf3 と、通信速度を劇的に変える「TCPウィンドウサイズチューニング」について、現場のリアルな視点から優しく解説していきますね。
—
1. なぜ「思ったよりスピードが出ない」のか？（身近な例えで理解する通信の仕組み）
皆さんは、遠く離れた友人に荷物を送るときを想像してみてください。
荷物を届けるとき、一度に1つの小さな封筒しか送れないバイク便があったとします。これでは、どれだけバイクのスピードが速くても（回線の物理的な帯域が広くても）、一度に運べる量が少なすぎて、トータルの荷物運び（スループット）は遅くなってしまいますよね。
ネットワークの世界でも全く同じことが起きています。
サーバーからクライアントへデータを送るとき、TCPという通信ルール（プロトコル）が使われます。TCPは「ちゃんと届いたよ！」という受領確認（ACK）を相手から受け取ってから、次の荷物を送り出す慎重な仕組みになっています。
ここで登場するのが、今回の主役である「TCPウィンドウサイズ」です。
これは、相手からの「届いたよ！」の返事を待たずに、「一気にどれだけの荷物を送り出していいか」のバッファ（箱）の大きさを意味します。
- ウィンドウサイズが小さい場合：
小さな手紙受け箱しか持っていない状態です。荷物を1つ送るたびに「届いた？」と立ち止まるため、遠くのサーバーと通信するほど、返事を待つ「空白の時間」が増えてスピードが出なくなります。
- ウィンドウサイズが大きい場合：
巨大なコンテナトラックを用意したような状態です。返事を待たずにどんどん荷物を送り出せるため、道路が混んでいなくても、一度に大量のデータを流し込むことができるようになります。
—
2. ネットワークの健康診断ツール iperf3 の基本
「うちの回線、本当に1Gbps出てるの？」
それを確かめるために私たちが現場で必ず使うのが iperf3 というツールです。これは、片方を「サーバー（待ち受け側）」、もう片方を「クライアント（測定者）」として起動し、限界までデータを流し込んで実効速度（スループット）を測定する、いわばネットワークのストレステスト装置です。
まずは、サーバー側とクライアント側で次のようにコマンドを叩いてみましょう。
サーバー側（待ち受け）の操作
# -s オプションでサーバーモードとして起動します
iperf3 -sクライアント側（測定実行）の操作
# -c オプションに続けてサーバーのIPアドレスを指定します
# 例として、サーバーのIPが 192.168.1.100 だと仮定します
iperf3 -c 192.168.1.100これだけで、数秒間のうちにどれだけのデータが流れたか、リアルタイムで測定結果が表示されます。基本の「き」ですね！
—
3. 遅延が大きい環境の罠！TCPウィンドウサイズのチューニング
さて、ここからが本題です。
例えば、東京のデータセンターから、海を越えたアメリカのサーバーへデータを送るシーンを想像してください。物理的な距離があるため、データが相手に届いて「届いたよ」の返事が返ってくるまでの時間（往復遅延時間：RTT）はどうしても大きくなります。
このような「遅延が大きい（ロングファットネットワーク：LFN）」環境では、デフォルトのウィンドウサイズ（OSが勝手に決める初期値）のままだと、先ほどの「バイク便の例え」のように、道路（回線）に十分な空きがあるのに荷物が少ししか流れない、というもったいない現象が起きます。
そこで、iperf3 を使って、送信側・受信側のTCPウィンドウサイズを意図的に大きくし、スループットがどう変化するかをテスト・チューニングしてみましょう。
ウィンドウサイズを指定して測定するコマンド例
iperf3 では、 -w オプションを使うことで、TCPのウィンドウサイズ（ソケットバッファサイズ）を直接指定することができます。
# ウィンドウサイズを 4MB ( Megabytes ) に指定してテストを実行する
iperf3 -c 192.168.1.100 -w 4Mもしあなたが遠隔地のサーバーと通信していて、「なんだか帯域が全然出ないな」と感じたら、この -w の値を徐々に大きく（例: 1M -> 4M -> 8M）して測定してみてください。あるポイントを境に、スループットが劇的に跳ね上がる瞬間を目撃できるはずです。
—
4. 現場のシニアエンジニアからのワンポイントアドバイスと注意点
ここまで聞くと、「じゃあ、ウィンドウサイズは常に大きければ大きいほど良いんだな！無限にデカくしよう！」と思われるかもしれません。しかし、現実はそう甘くありません。ここに現場ならではの落とし穴があります。
1. メモリの枯渇リスク
ウィンドウサイズを大きくするということは、OSが「相手からまだ返事をもらっていないデータ」を一時的に保持しておくためのメモリ（バッファ）を大量に確保するということです。同時に何百人ものユーザーがアクセスしてくるサーバーで、全員のウィンドウサイズを無闇に巨大化させると、サーバーのメモリがパンクしてしまいます。
2. ネットワーク機器のバッファとの関係
途中のルーターやスイッチの性能（バッファ容量）を超えてデータを送りつけてしまうと、途中で荷物が溢れてしまい（パケットロス）、逆に再送処理が発生してスピードがガタ落ちする原因になります。
チューニングとは、「大きければ正義」ではなく、「通信の距離（遅延）と、サーバーのメモリリソースのバランスを取る絶妙な落とし所を見つける作業」なのです。
—
おわりに
いかがでしたでしょうか？
iperf3 によるスループット測定と、TCPウィンドウサイズの変更がもたらす影響について、少しイメージが湧いてきたのではないでしょうか。
インフラやネットワークのトラブルシューティングは、見えないパケットの動きを頭の中でどれだけリアルに想像できるかが勝負の分かれ道です。まずはご自身のローカル環境や検証用サーバーで、今回紹介した iperf3 -c や -w オプションを気軽に試してみてください。
手を動かして得た「あ、ここでスピードが変わった！」という体感が、あなたを一人前のネットワークエンジニアへと引き上げてくれる最高の財産になります。
それでは、また次回の技術解説でお会いしましょう！快適なネットワークライフを！
コメント