macOSのnettopの仕組み(そしてGUIが欲しくなる理由)
macOSのnettopを分かりやすく案内します。何を見せ、何を見せないのか、そしてGUI型通信量モニタが力を発揮する場面を解説します。
- Developer tools
- macOS
- Network monitoring
- Tutorial
ターミナルを開いてnettopと入力します。1秒以内に、Macでネットワークi/oをしているすべてのプロセスのライブのtopスタイル表示が得られます——送信バイト、受信バイト、取っているルート、使っているプロトコル。あなたが持っていることを知らなかったツールで、見つけるとなぜアクティビティモニタのネットワークタブを開いたのか不思議に思います。これはmacOSのnettopツアー、本当に重要なフラグ、そしてnettopが道を尽きる場所についてです。
ネタバレ: nettopはワンショットの観察に素晴らしいです。「Slackが昨日午後3時に何をしていたか」には素晴らしくない。これらの同じカーネルカウンタの上のUIが埋めるギャップです。
macOSのnettopは実際何か
nettopはmacOSに同梱され、/usr/bin/nettopに住み、少なくとも10.7以来そこにあります。アクティビティモニタとInstrumentsが使うのと同じカーネルAPI——主にソケットと統計バリアント付きのproc_pidinfo、加えてルート別カウンタ——の上の小さなコマンドラインフロントエンドです。ほとんどの用途でrootは要りません。パケットをキャプチャしません。インストーラ不要。
フラグなしで実行:
nettop次のようなものが見えます:
Processes
Google Chrome.40621 tcp4 34.117.x.x.443 Established
Google Chrome.40621 tcp4 142.250.x.x.443 Established
Slack Helper.41218 tcp4 52.5.x.x.443 Established
...qで終了、?でヘルプ、rでレートと合計の切り替え、dでデルタモードの切り替え。
知る価値のあるフラグ
nettopのフラグはたくさんあります。ほとんどはノイズ。実際に使うものはこちら。
-mでモード
-m routeはルート別トラフィックを表示——ローカルネットワーク、VPNトンネル、デフォルトルートのどれを通っているか見るのに有用。
-m tcpと-m udpは1つのプロトコルにフィルタ。
-m processは既定で、ほとんどの場合欲しいもの。
-Pでプロセスピッカー
-Pはnettopをライブ更新ではなく1度実行して静的スナップショットをダンプさせます。スクリプト化したり別ツールにパイプするときに欲しいものです。
nettop -P -L 1これは1サンプルの非対話モードでnettopを実行して終了。-Jと組み合わせて列を制限し(下記参照)きれいなログ出力を。
-Lでログモード
-L <count>は与えられた数のサンプルでログモードでnettopを実行して終了。-L 0は永遠に動き、間隔ごとにサンプル行をダンプ。既定の間隔は1秒、-sで変更。
nettop -L 60 -s 1 -P -J bytes_in,bytes_out,interface,stateこれは60秒間1秒に1サンプルキャプチャ、気にする列だけ、終了。後の分析のためファイルにパイプ。
-Jで列選択
-Jはカンマ区切りの列名リストを取ります。便利な列:
bytes_in、bytes_out— プロセス起動以来の合計rx_dupe、rx_ooo— TCP再送と順序乱れパケットre-tx— 再送rtt_avg— ラウンドトリップタイム、遅いネットワーク発見に有用rcvsize、tx_win— ソケットバッファ状態interface— どのインターフェース(en0、utun0、lo0)state— 接続状態(Established、TimeWait、Listen)
完全リストはman nettopに。約30列ありますが、ほとんどの場合bytes_in,bytes_out,interface,stateで十分です。
-xでXML
-xはplist XML形式で出力——解析可能、読むのは苦痛、ただnettopを別スクリプトに送りたいときに有用。実際には-Jと-L経由のJSON型列出力の方が通常作業しやすい。
-kで非表示
-k <column>は気にしない列を隠します。-Jの反対。ライブ表示を保ちながらノイズを減らしたいとき対話的に使う。
出力を読む
macOSのnettopが報告する数字について知っておくべきいくつかのこと:
合計はnettopを起動した時点ではなくプロセス起動以来。 clouddのような長く生きたプロセスは静かなシステムでも数百MBを示すかもしれません。実際のレートを見るにはデルタモード(対話的にd、または-Lログ出力からデルタを計算)。
各行はプロセスではなくフロー。 タブ40個の単一Chromeプロセスは40+行を持つかもしれません。PIDで自分で集約してください——nettopは集約しません。
ヘルパープロセスはヘルパー名で現れる。 Google Chrome Helper (Renderer)、Slack Helper、com.docker.backend。折りたたみなし。生のカーネルビューを見ます。
ルートは意外なことがある。 VPNトンネルを通る接続はインターフェースutun0または同様を示し、en0ではない。認識しないインターフェースでトラフィックが見えるなら調査の価値あり。
nettopが落ちるところ
無料の組み込みツールとして、nettopは本当に有用。ただ実際の限界があります。
履歴なし
nettopを終了するとデータは消えます。ログファイル、ローリング窓、永続化された状態はありません。スパイクが起きたとき観察していなかったら見ていないのです。-Lログモードはキャプチャしたいイベントの前にセットアップしておけば役立ちますが、それは計画であってデバッグではない。
ヘルパー折りたたみなし
述べたように、Google Chrome Helper (GPU)、(Plugin)、(Renderer)などが別行として見えます。30の短命レンダラープロセスにわたって頭の中で合計するのは退屈でエラーが起きやすい。
ターミナルのみ
ライブnettopセッションはターミナルウィンドウを取ります。コードを書きながら「今何かが通信量を使っているか?」を一目で見たいなら、コンテキストを切り替える必要があります。メニューバーウィジェット、通知、トレイアイコンはありません。
紛らわしい列名
re-tx、rtt_var、tx_dupe——列は人間ではなくカーネルTCP統計のために名付けられています。manページが友達ですが、学習曲線は本物です。
アプリやカテゴリでフィルタなし
「Chromeとそのヘルパーだけ表示」や「システムプロセス以外すべて表示」と言えません。grepにパイプしてフィルタしますが、機能はしても気持ちよくない。
警告なし
アプリが突然50MB/sを使い始めたとき知りたいなら、nettopは教えません。サンプルを差分してしきい値と比較するポーリングスクリプトでラップする必要があります。
ovaを動かしてみる
一目で分かるメニューバー通信量モニター——ローカル、署名済み、約3MB。
UIが助ける理由
ほとんどの場合、フロー別TCP統計を実際に知りたいわけではありません。知りたいのは:
- 今何かが通信量を使っているか?
- それはどのアプリか?
- 各アプリは過去1時間、1日、1週間でどれだけ使ったか?
ovaのようなメニューバーアプリは、nettopが読むのとほぼ同じカーネルデータを読みますが、その上で3つのことをします:
- ヘルパープロセスを親アプリの下に折りたたむので「Slack」は1行
- 履歴をローカルに保存するので、遡って「2:47 PMに何が起きたか」を問える
- メニューバーに住むので、作業中に一目離れた場所にある
それはnettopより優れているわけではない——違うのです。nettopは瞬間に手を伸ばすデバッグツール。通信量モニターは周辺認識です。
nettopを他のツールと組み合わせる
nettopはいくつかの組み込みとよく組み合わさります。
nettop + lsof
nettopはどのPIDが通信量を使っているかを示します。lsof -p <PID>はそのPIDが開いているすべてのファイルとソケットを示します。一緒に「このアプリはどのリモートエンドポイントと話しているか?」に答えます。
lsof -i -P -n -p 41218これはPID 41218が開いているすべてのIPv4/IPv6ソケットをリモートアドレスとポート付きでリスト。
nettop + log show
システムサービスが誤動作していると疑うなら、統合ログは通常nettopより多くのコンテキストを持ちます。nettopで問題のプロセスを見つけた後:
log show --last 5m --predicate 'process == "cloudd"'…で同じ時刻にclouddが何をしていたか見ます。
nettop + tcpdump
実際に回線上に何があるか知る必要があるなら、パケットキャプチャが答えです。nettopは「Chromeが12 MB/sで142.250.x.xにアップロード中」と教えます。sudo tcpdump -i en0 host 142.250.x.xはHTTP/2かQUICか、SNIは何だったか、どんなレスポンスコードが返ってくるかを教えます。
実例
アイドル中にラップトップのファンが上がったとします。調査の連鎖:
- ターミナルを開き、
nettop -P -L 5 -s 2 -J bytes_in,bytes_out,interfaceを実行。 - 出力を読む。
clouddが10秒で80MB上りを示すとします。 log show --last 1m --predicate 'process == "cloudd"' --infoを実行。- ログはiCloudが今日早く電話で撮った写真をアップロード中だと言う。
- 待ち抜くか、iCloudを絞るか、アップロードを一時停止するか決める。
その全シーケンスは約90秒かかります。前日にovaをインストールしていたら、ステップ1は「メニューバーを見る」で、ターミナルを開く前にすでにclouddが犯人だと知っていたでしょう。統合ログのステップは引き続き当てはまります。
まとめ
macOSのnettopは、誰もマーケティングしない小さく速い組み込みツールです。存在を知れば、「今ネットワークを使っているものを見る必要がある」の正しい答えです。限界は本物——履歴なし、折りたたみなし、ターミナルのみ——ですが、スコープ内では無料で打ち負かすのは難しい。
コマンドを入力せずに周辺認識、スクラブ可能な履歴、アプリ別折りたたみが欲しいなら、メニューバーアプリが欲しい。ovaはその部分をします: 約3MB、macOS 14+、Apple SiliconとIntel、約1Hzでサンプリング、すべてをディスクにローカル保存。nettopとovaは隣接する問題を解き、ほとんどのmacOSユーザーは両方を持つことから恩恵を得ます。