Mac에서 nsurlsessiond는 무엇인가요? 백그라운드 다운로드 데몬 설명

nsurlsessiond는 macOS에 기본 탑재된 시스템 데몬으로, Apple이 서명했어. 이건 NSURLSession의 백그라운드 전송 에이전트로, Apple 플랫폼의 애플리케이션들이 서버와 통신하는 데 사용하는 표준 네트워킹 API야.

이 이름은 그걸 알게 되면 깔끔하게 분해돼. NSURLSession은 API이고, 뒤에 붙은 d는 유닉스 관습으로 데몬, 즉 창이나 도크 아이콘이 없는 백그라운드 프로세스를 의미해. 시스템이 시작하며, 네가 시작하는 게 아니고, 작업이 대기 중일 때마다 실행돼.

중요한 부분은 백그라운드라는 단어야. 개발자가 NSURLSession을 사용할 때, 다운로드나 업로드를 백그라운드 전송으로 표시할 수 있는데, 이는 시스템에 앱이 종료되거나 정지되거나 충돌하거나 기기가 혼자 남았을 때도 전송이 계속되도록 하는 거야. macOS는 이를 nsurlsessiond에 넘기고, 이후에 앱에 알리거나 필요시 다시 시작해서 결과를 전달하지. 그래서 큰 App Store 다운로드가 앱을 닫은 후에도 계속 진행되고, 팟캐스트 에피소드가 도착하는 것도 앱을 다시 열지 않아도 끝나는 거야.

자주 nsurlstoraged도 함께 보여. 이건 URL 세션 데이터(캐시된 응답이나 쿠키 등)를 저장하는 역할을 하는 Apple 데몬으로, 역시 정상적인 거야. 이 프로세스는 네트워크 활동이 훨씬 적게 나타나는데, 그 이유는 저장 쪽에 집중되어 있고 네트워크와는 별개이기 때문이야.

이것이 nsurlsessiond에 대해 이해하는 데 가장 중요한 유일한 포인트이며, 많은 사람들이 그것에 대해 의심을 품게 되는 이유입니다. nsurlsessiond에 귀속된 트래픽은 보통 다른 앱에 속해 있습니다. 이것은 공유 택배원으로, 요청하는 누구에게나 패키지를 전달하며, 그 패키지들은 그에게 주소가 지정되어 있지 않습니다.

Photos가 이미지를 일괄적으로 iCloud에 업로드할 때, 그 바이트들은 nsurlsessiond를 통해 이동합니다. App Store가 수 기가바이트의 업데이트를 다운로드할 때도 마찬가지입니다. 서드파티 클라이언트가 파일을 동기화하거나 미디어를 사전 캐시할 때도 거의 동일하게 발생합니다. 이 모든 트래픽은 하나의 프로세스에 의해 열리고, 하나의 프로세스에 귀속되며, 하나의 이름 아래 표시됩니다.

Activity Monitor와 소켓 소유 프로세스만으로 트래픽을 식별하는 도구는 이를 구별할 방법이 없습니다. 그것은 운영체제 수준에서 사실인 것을 보고할 뿐입니다: 연결은 nsurlsessiond에 속합니다. 그러나 각 전송 뒤에 요청하는 앱이 무엇인지 보여줄 수 없는 이유는 그 관계가 소켓 위의 계층에 존재하기 때문입니다. 그 결과는 하나의 프로세스가 엄청난 대역폭을 사용하는 것처럼 보이지만, 실제로는 여러 앱이 하나의 라벨 아래서 작업하는 것에 불과합니다.

그래서 nsurlsessiond 알람의 큰 부분은 오인된 귀속이지, 오작동이 아닙니다. 만약 Apple 데몬이 40기가바이트의 다운로드를 필요로 하는 이유를 궁금해한다면, 답은 그것이 필요하지 않았다는 것입니다. 당신의 Mac에서 어떤 것이 그것들을 요청했기 때문입니다.

이것은 또한 데몬이 계속 실행되는 것처럼 보이는 이유를 설명합니다. 그것은 자체적으로 영구 연결을 유지하는 것이 아닙니다. 전송이 대기열에 오르면 깨어나서 작업을 수행하고 조용히 돌아가며, 사진, 문서, 메일 첨부파일, 앱 업데이트를 동기화하는 기기에서는 거의 항상 대기열에 무언가가 있습니다.

nsurlsessiond는 악성코드가 아닙니다. 이것은 macOS의 1차 파트 구성요소로, 모든 최신 Mac에 존재하며, 어떤 유틸리티로도 제거, 비활성화 또는 정리할 필요가 없습니다.

이 질문 뒤에 있는 합리적인 주의는 때때로 악성코드가 시스템 프로세스와 유사한 이름을 채택하여, 프로세스 목록을 빠르게 보면 통과할 수 있다고 기대하는 데 있습니다. 터미널에서 두 가지 검사를 통해 이를 무력화할 수 있으며, 이는 이 프로세스뿐만 아니라 어떤 프로세스에 대해서도 알아두면 좋습니다.

첫 번째 검사는 위치입니다. pgrep 명령어를 -lf 플래그와 함께 사용하여 nsurlsessiond라는 패턴으로 실행 중인 바이너리의 위치를 시스템에 요청하세요. 진짜 데몬은 시스템 프레임워크 경로 내, CFNetwork 프레임워크 깊숙한 곳에 존재합니다. 다운로드 폴더, 홈 디렉터리 또는 낯선 애플리케이션 번들에서 그 이름을 주장하는 것은 Apple 데몬이 아닙니다.

두 번째 검사는 코드 서명입니다. 이것이 두 가지 중 더 강력한 검사입니다. 유효한 Apple 서명이 없는 경로나, 위조된 서명을 가진 바이너리라면 걱정할 만합니다. 찾은 바이너리 경로에 대해 codesign 명령어를 -dv와 verbose 플래그와 함께 실행하세요. 진짜 데몬은 Apple에 속하는 권한 체인을 보고하며, Software Signing과 Apple Code Signing Certification Authority를 명시합니다. 서명되지 않았거나 알 수 없는 개발자가 서명한 바이너리는 우려를 불러일으킬 수 있습니다.

두 검사가 모두 통과하면, 그 프로세스는 자신이 주장하는 대로이며, 그 행동에 대해 놀라운 점이 있다면 그것은 그를 통해 작업을 대기하는 앱들에 관한 질문입니다.

nsurlsessiond는 항상 다른 것의 대리로만 작동하기 때문에, 이로 인한 비정상적인 활동은 증상에 불과하며, 유용한 진단은 상류에 있다. 대부분의 경우는 소수의 원인에 의해 발생한다.

가장 흔한 원인은 iCloud이다. 새로 활성화된 iCloud 사진 라이브러리, 복구된 Mac 또는 대량의 새 가져오기 작업은 라이브러리 크기와 연결 속도에 따라 몇 시간 또는 며칠 동안 지속되는 트래픽을 발생시킨다. iCloud Drive도 큰 폴더 변경 후에 같은 방식으로 동작한다. 다음은 App Store로, 대형 앱 업데이트와 시스템 업데이트가 백그라운드에서 단계별로 진행될 때이다. 세 번째는 팟캐스트 클라이언트와 같이 여러 에피소드를 미리 캐시하는 미디어 앱이다.

비용이 적은 것부터 가장 복잡한 것까지 순서대로 점검하는 방법이다. 먼저 전경 후보부터 시작하자: App Store 업데이트 보기와 시스템 환경설정을 열어 업데이트가 다운로드 중인지 확인한다. 그런 다음 Photos를 열고 라이브러리 보기 하단의 상태 표시줄을 읽어보자. 여기에는 동기화 진행률과 항목 수가 표시되며, Finder에서 iCloud Drive의 대기 항목도 확인할 수 있다. 다음으로 최근에 설치하거나 재구성된 항목을 고려하자. 새로 추가된 동기화 클라이언트는 자주 트리거가 되기 때문이다. 마지막으로, 계속 실행하게 두자. 종료가 정해진 전송은 결국 끝나기 때문이다.

높은 CPU 사용량은 보통 같은 원인을 따른다. 지속적인 전송은 유휴 상태가 아닌 지속적인 작업을 의미하기 때문이다. 의미 있는 처리량 없이 지속적인 높은 CPU 사용은 드물며, 종종 재시작으로 해결된다. 재시작은 데몬과 그 큐를 재설정하지만, 영구적인 영향을 미치지 않는다.

피해야 할 것은 차단하는 것이다. 방화벽으로 nsurlsessiond의 네트워크 접근을 차단할 수 있으며, 그 결과 시스템 전체의 백그라운드 전송이 멈추고, 보통 오류 없이 정지한다. 다운로드는 절대 완료되지 않고, iCloud 관련 동기화는 정체되며, 전송이 끝났다고 기대하는 앱들은 그렇지 않음을 알게 된다. 실패가 조용히 일어나고 시스템 전체에 영향을 미치기 때문에, 이는 바람직하지 않다. 적절한 조작 방법은 작업을 큐에 넣는 앱이고, 그것을 운반하는 전달자가 아니다.

그것은 내장 도구들이 답할 수 없는 질문을 남긴다: 실제로 이 모든 것을 요청한 애플리케이션은 무엇인가? Activity Monitor는 프로세스 경계까지만 보여주기 때문에, 행은 nsurlsessiond라고 표시되고 그 뒤는 끝난다.

더 날카로운 접근법은 프로세스 이름에 의존하는 것을 멈추고 대신 목적지에 주목하는 것이다. 연결은 여전히 어디론가 가며, 그 끝점들은 프로세스 이름이 아니더라도 전송 뒤에 있는 서비스를 식별한다. 애플 콘텐츠 전달과 iCloud 끝점은 서드파티 동기화 서비스 또는 미디어 CDN과는 뚜렷이 구별되며, 도메인을 볼 수 있게 되면 귀속이 추측이 아니게 된다.

이것이 NetMute가 구축된 핵심이다. 이는 단일 집계 수치 대신 실시간으로 애플리케이션별, 프로세스별 트래픽을 보여주며, 도메인 수준의 로깅과 함께 전송이 도달하는 끝점을 보여준다. 이를 통해 익명의 행이 명확한 그림으로 바뀐다: 이만큼이 iCloud로 가고, 이만큼이 지난 주에 설치한 앱으로 간다.

원본을 알게 되면, NetMute는 책임 있는 앱에 초점을 맞춘 비례적 조치를 제공한다. 하나의 클릭으로 앱의 네트워크 접근을 차단하거나, 잠시 동안 조용히 하고 싶을 때 임시 규칙을 사용할 수 있다. 앱별 데이터 제한은 자동으로 정점에서 차단하며, 이는 시즌별 콘텐츠를 미리 캐시하는 앱에 적합하다. 네트워크 프로필은 상황에 따라 규칙을 변경할 수 있어, 메터드된 핫스팟의 노트북이 집에서는 필요 없는 제한을 강제하지 않도록 한다.

이 모든 것은 nsurlsessiond를 건드릴 필요가 없다. 데몬은 계속 일을 하며, 백그라운드 다운로드와 iCloud 전송은 계속 완료되고, 트래픽을 생성하는 앱이 제약을 받는다.