ブログに戻る
·10分で読める·productdevbook

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_inbytes_out — プロセス起動以来の合計
  • rx_duperx_ooo — TCP再送と順序乱れパケット
  • re-tx — 再送
  • rtt_avg — ラウンドトリップタイム、遅いネットワーク発見に有用
  • rcvsizetx_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 Helpercom.docker.backend。折りたたみなし。生のカーネルビューを見ます。

ルートは意外なことがある。 VPNトンネルを通る接続はインターフェースutun0または同様を示し、en0ではない。認識しないインターフェースでトラフィックが見えるなら調査の価値あり。

nettopが落ちるところ

無料の組み込みツールとして、nettopは本当に有用。ただ実際の限界があります。

履歴なし

nettopを終了するとデータは消えます。ログファイル、ローリング窓、永続化された状態はありません。スパイクが起きたとき観察していなかったら見ていないのです。-Lログモードはキャプチャしたいイベントの前にセットアップしておけば役立ちますが、それは計画であってデバッグではない。

ヘルパー折りたたみなし

述べたように、Google Chrome Helper (GPU)(Plugin)(Renderer)などが別行として見えます。30の短命レンダラープロセスにわたって頭の中で合計するのは退屈でエラーが起きやすい。

ターミナルのみ

ライブnettopセッションはターミナルウィンドウを取ります。コードを書きながら「今何かが通信量を使っているか?」を一目で見たいなら、コンテキストを切り替える必要があります。メニューバーウィジェット、通知、トレイアイコンはありません。

紛らわしい列名

re-txrtt_vartx_dupe——列は人間ではなくカーネルTCP統計のために名付けられています。manページが友達ですが、学習曲線は本物です。

アプリやカテゴリでフィルタなし

「Chromeとそのヘルパーだけ表示」や「システムプロセス以外すべて表示」と言えません。grepにパイプしてフィルタしますが、機能はしても気持ちよくない。

警告なし

アプリが突然50MB/sを使い始めたとき知りたいなら、nettopは教えません。サンプルを差分してしきい値と比較するポーリングスクリプトでラップする必要があります。

ovaを動かしてみる

一目で分かるメニューバー通信量モニター——ローカル、署名済み、約3MB。

macOS用ダウンロード

UIが助ける理由

ほとんどの場合、フロー別TCP統計を実際に知りたいわけではありません。知りたいのは:

  1. 今何かが通信量を使っているか?
  2. それはどのアプリか?
  3. 各アプリは過去1時間、1日、1週間でどれだけ使ったか?

ovaのようなメニューバーアプリは、nettopが読むのとほぼ同じカーネルデータを読みますが、その上で3つのことをします:

  • ヘルパープロセスを親アプリの下に折りたたむので「Slack」は1行
  • 履歴をローカルに保存するので、遡って「2:47 PMに何が起きたか」を問える
  • メニューバーに住むので、作業中に一目離れた場所にある

それはnettopより優れているわけではない——違うのです。nettopは瞬間に手を伸ばすデバッグツール。通信量モニターは周辺認識です。

ライブ+履歴を1か所で
ovaはメニューバーに現在のレートを表示し、その後ろに完全なスクラブ可能なタイムライン。nettopはライブレートを表示。ovaは昨日午後3時も利用可能に保ちます。

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は何だったか、どんなレスポンスコードが返ってくるかを教えます。

実例

アイドル中にラップトップのファンが上がったとします。調査の連鎖:

  1. ターミナルを開き、nettop -P -L 5 -s 2 -J bytes_in,bytes_out,interfaceを実行。
  2. 出力を読む。clouddが10秒で80MB上りを示すとします。
  3. log show --last 1m --predicate 'process == "cloudd"' --infoを実行。
  4. ログはiCloudが今日早く電話で撮った写真をアップロード中だと言う。
  5. 待ち抜くか、iCloudを絞るか、アップロードを一時停止するか決める。

その全シーケンスは約90秒かかります。前日にovaをインストールしていたら、ステップ1は「メニューバーを見る」で、ターミナルを開く前にすでにclouddが犯人だと知っていたでしょう。統合ログのステップは引き続き当てはまります。

まとめ

macOSのnettopは、誰もマーケティングしない小さく速い組み込みツールです。存在を知れば、「ネットワークを使っているものを見る必要がある」の正しい答えです。限界は本物——履歴なし、折りたたみなし、ターミナルのみ——ですが、スコープ内では無料で打ち負かすのは難しい。

コマンドを入力せずに周辺認識、スクラブ可能な履歴、アプリ別折りたたみが欲しいなら、メニューバーアプリが欲しい。ovaはその部分をします: 約3MB、macOS 14+、Apple SiliconとIntel、約1Hzでサンプリング、すべてをディスクにローカル保存。nettopとovaは隣接する問題を解き、ほとんどのmacOSユーザーは両方を持つことから恩恵を得ます。