パケットロス

🐾 猫で例えると？

ハンモックから上を見つめる茶トラ。「渡してもらったはずのおやつが、どこかで引っかかって届かない…」と待つ場面を想像してみましょう。通信を小さく分けたデータの塊がパケットで、送ったパケットが相手へ届かないのがパケットロスです。茶トラが待つ姿を、受け取る側の立場に重ねています。

💻 IT現場における「パケットロス」とは？

インターネット上のデータは、すべて「パケット」という小さな小包に分割されてバケツリレーのようにルーターを経由して運ばれます。しかし、途中のルーターに許容量を超える大量のアクセスが集中したり（輻輳・ふくそう）、LANケーブルが劣化していたりすると、ルーターは処理しきれなくなった小包を容赦なく「破棄」します。これがパケットロスです。

TCPには、確認応答やタイマーを使って失われたデータを再送する仕組みがあります。UDP自体には配送・順序・再送の保証がありませんが、その上で動くアプリが再送や補正を実装することはできます。したがって「UDPなら再送しない」「動画はすべてUDP」とは言い切れません。

⚠️ パケットロスの仕組みと確認方法

「なんかネットが遅い」「Zoomの声が途切れる」という時、インフラエンジニアはまず通信相手との間にパケットロスが発生していないかを調べます。

pingコマンドによるパケットロスの調査

以下はmacOS/LinuxでICMPの応答を10回確認する例です。Windowsでは ping -n 10 8.8.8.8 を使います。これはWebや通話そのものではなく、指定した宛先からICMP応答が戻るかを調べる測定です。

# Googleのサーバー（8.8.8.8）へパケットを10回送信してロス率を確認する
$ ping -c 10 8.8.8.8

PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=117 time=12.145 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=13.012 ms
# （中略）
--- 8.8.8.8 ping statistics ---
10 packets transmitted, 8 packets received, 20.0% packet loss
round-trip min/avg/max/stddev = 11.512/12.445/13.881/0.655 ms

この例ではICMPの応答が10回中2回戻りませんでした。ただし、相手や途中の機器がICMPを制限している場合もあり、これだけでアプリ通信に20%のロスがある、あるいは致命的な障害だとは断定できません。自宅ルーターへの測定、有線接続との比較、実際の通話品質などを合わせて切り分けます。

🛠️ パケットロスを防ぐためのポイント

現場でネットワークの安定性を高め、パケットロスを最小限に抑えるための対策です。

• 無線と有線を比較： 同じ端末で有線に切り替えて改善するかを確認すると、電波や無線区間の問題を絞れます。ケーブルは必要な速度と距離に合う規格・状態を確認し、カテゴリ番号が新しいだけで解決すると考えないようにします。
• 帯域とキューを確認： 混雑時のQoSは通話などの優先順位を調整できますが、帯域自体を増やすものではなく、すべてのロスを防げるわけではありません。回線利用率と機器の廃棄カウンターも確認します。
• 中継機器（ルーターやスイッチ）のスペックアップ： 処理能力の低い古いルーターは、大量のパケットが押し寄せるとすぐに悲鳴を上げてデータを破棄します。おやつの圧がすごいアメショにも耐えられるよう、機材のスケールアップが必要です。

おやつが届かず待つ茶トラのように、通信でも途中の欠落が待ち時間につながることがあります。途切れた時刻や頻度を記録し、無線区間や経路、機器の状態を順に確認すると、一時的な混雑か継続する不調かを切り分けやすくなります。