ネットワークの「静かなる悲鳴」を聴け：ss と netstat が暴くパケットロスの深淵
深夜2時、監視アラートが鳴り響く。レイテンシがスパイクし、特定のマイクロサービスで 504 Gateway Timeout が散発している。開発チームは「アプリケーションは正常だ」と主張し、インフラチームは「ネットワークは通っている」と返す。よくある光景だ。
しかし、パケットは嘘をつかない。OSの深層で何が起きているのか。今回は、GUIのダッシュボードでは決して見えてこない、カーネルのバッファとNICの戦場を ss と netstat で紐解く手法を解説する。
—
1. カウンタが語る「見えない壁」
我々がまず疑うべきは、netstat -i や ss -i が吐き出す統計情報だ。ここで「エラー」や「ドロップ」がカウントされているなら、それは論理的なルーティングの問題ではなく、ハードウェアやカーネルバッファの限界に直面している証拠である。
特に注目すべきは RX-DRP（受信ドロップ）と RX-OVR（オーバーラン）だ。
# インターフェイス統計を詳細に確認する
# Ierr/Oerr（エラー）, Idrop/Odrop（ドロップ）, Iover（オーバーラン）を注視する
netstat -iRX-DRP: カーネルの受信バッファが溢れ、処理しきれずに捨てられたパケット。RX-OVR: NICのハードウェアバッファからカーネルへデータを渡すスピードが追いつかず、NIC上で破棄されたパケット。
もし RX-OVR が増えているなら、それはPCIeバスの帯域不足か、あるいはNICのドライバ割り込み処理がCPUコアに偏っていることを示唆している。cat /proc/interrupts を叩き、特定のCPUコアに負荷が集中していないか確認してほしい。
—
2. カーネルの「胃袋」を調整する：TCPバッファチューニング
パフォーマンスのボトルネックは、多くの場合「TCPウィンドウサイズ」の不適合にある。現代の高速なネットワーク環境において、カーネルのデフォルト値はあまりに控えめだ。
高RTT（往復遅延時間）の環境下でスループットを最大化するには、BDP（Bandwidth Delay Product）に基づいたバッファの拡張が不可欠だ。
# /etc/sysctl.conf に追記し、カーネルパラメータを最適化する
# 10GbpsネットワークでRTTが10ms程度の場合を想定
# TCP送受信バッファの最小、デフォルト、最大値
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
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 = bbrbbr（Bottleneck Bandwidth and Round-trip propagation time）は、従来の cubic とは異なり、パケットロスを「輻輳」と誤認せず、純粋な帯域幅と遅延を計算してスループットを叩き出す。これを適用するだけで、パケットロス発生時の回復速度が劇的に変わる。
—
3. TLSハンドシェイクとコネクションの「詰まり」を可視化する
ss -it コマンドは、現在のTCP接続状態を詳細にダンプする。ここで重要なのは rto（再送タイムアウト）と rtt（往復遅延）の値だ。
# 特定のポートへの接続におけるTCP情報を詳細に表示
ss -itn 'sport = :443'出力結果の cubic wscale:7,7 rtt:12.5/2.1 ... といった行に注目してほしい。
rtt: 接続先との物理的な距離とルータホップによる遅延。rto: パケットロス発生時に再送を待機する時間。
もし TLS ハンドシェイクの最中に rto が増大しているなら、それは証明書のサイズによる「TCPスロースタート」の罠にはまっている可能性がある。TLS 1.3 の 0-RTT（Zero Round Trip Time）を導入し、ハンドシェイクのラウンドトリップを削減することが、現代のWebインフラにおけるセキュリティと速度の両立の要だ。
—
4. 現場の教訓：なぜ「パケットドロップ」は無視されるのか
多くのエンジニアが犯す過ちは、ss や netstat の統計を「瞬間的」にしか見ないことだ。ネットワークの負荷は往々にしてバースト的に発生する。
現場では、以下のようなワンライナーで「ドロップが進行しているか」を1秒単位で追跡するのが定石だ。
# 1秒ごとにRX-DRPの増分を監視し、パケット損失の瞬間を捉える
watch -n 1 "netstat -i | grep eth0"もしドロップが発生したなら、それは iptables や nftables のログを確認するか、ebpf を活用して「どのシステムコールがパケットを処理できていないのか」をプロファイリングすべきだ。
最後に
ネットワークのトラブルシューティングは、デバッグではなく「鑑識」に近い。断片化された統計情報から、背後にあるパケットの叫びを聴き取る。教科書的なコマンドを叩くのは誰にでもできるが、その結果が何を意味するのかをOSのカーネルコードやTCP/IPの仕様に照らし合わせて解釈できるか。
インフラアーキテクトとして、自身の管理するネットワークの「正常値」を日々計測し、異常の予兆を捉える感性を磨いてほしい。パケットロスは、システムの限界を知らせる最も正直なシグナルなのだから。
コメント