ova
블로그로 돌아가기
·10분 분량·productdevbook

macOS의 nettop은 어떻게 동작하는가 (그리고 왜 UI가 필요한가)

macOS의 nettop을 가볍게 둘러봅니다. 무엇을 보여 주고 무엇을 보여 주지 않는지, 그래픽 대역폭 모니터가 어디서부터 역할을 이어받는지 살펴봅니다.

  • Developer tools
  • macOS
  • Network monitoring
  • Tutorial

터미널을 열고 nettop을 입력하세요. 1초 안에 네트워크 I/O를 하는 Mac의 모든 프로세스의 라이브, top 스타일 디스플레이를 갖게 됩니다 — 들어오는 바이트, 나가는 바이트, 사용하는 경로, 사용하는 프로토콜. 가지고 있는 줄 몰랐던 도구이며, 일단 발견하면 왜 활성 상태 보기의 네트워크 탭을 열었는지 의문이 듭니다. 이는 macOS의 nettop 투어, 실제로 중요한 플래그, 그리고 nettop이 길의 끝에 도달하는 곳에 관한 것입니다.

스포일러: nettop은 한 번 보기에는 좋습니다. "어제 오후 3시에 Slack이 무엇을 하고 있었는가?"에는 좋지 않습니다. 그 간극을 같은 커널 카운터 위의 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는 한 프로토콜로 필터링합니다.

-m process는 기본값이며 대부분의 경우 원하는 것입니다.

프로세스 선택을 위한 -P

-P는 nettop이 라이브 새로 고침 대신 한 번 실행하고 정적 스냅샷을 덤프하게 합니다. 스크립트하거나 다른 도구로 파이프할 때 원하는 것입니다.

nettop -P -L 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초 동안 초당 한 샘플을, 신경 쓰는 열만으로 캡처하고 종료합니다. 나중 분석을 위해 파일로 파이프하세요.

열 선택을 위한 -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로 충분합니다.

XML을 위한 -x

-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 터널을 통과하는 연결은 en0이 아니라 utun0 또는 비슷한 인터페이스를 보여줄 것입니다. 인식하지 못하는 인터페이스에 트래픽이 보인다면 조사할 만합니다.

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.

macOS용 다운로드

UI가 도움이 되는 이유

대부분의 경우, 실제로 흐름별 TCP 통계를 알고 싶지 않습니다. 다음을 알고 싶습니다.

  1. 지금 무언가가 대역폭을 사용하고 있는가?
  2. 어떤 앱인가?
  3. 지난 한 시간, 하루, 일주일에 각 앱이 얼마나 사용했는가?

ova 같은 메뉴 바 앱은 nettop이 읽는 것과 거의 같은 커널 데이터를 읽지만, 그 위에 세 가지를 합니다.

  • 도우미 프로세스를 상위 앱 아래로 접어서 "Slack"이 한 줄
  • 기록을 로컬에 저장해 거슬러 스크럽하고 "오후 2:47에 무슨 일이 있었는가"를 물을 수 있음
  • 메뉴 바에 살고 있어, 작업하는 동안 시선 거리에 있음

그것은 nettop보다 더 좋은 것이 아닙니다 — 다릅니다. nettop은 순간에 손을 뻗는 디버깅 도구입니다. 대역폭 모니터는 환경 인식입니다.

한 곳의 라이브 + 기록
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이 142.250.x.x로 12MB/s를 업로드하고 있다"고 알려줍니다. 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 사용자는 둘 다를 가짐으로써 혜택을 봅니다.