Что такое nsurlsessiond на Mac? Объяснение демона фона загрузки

nsurlsessiond — это системный демон, поставляемый с macOS, и подписанный Apple. Он является фоновым агентом для NSURLSession, стандартного API для сетевых соединений, который используют приложения на платформах Apple для связи с серверами.

Название легко разбирается, если знать, что NSURLSession — это API, а завершающая буква d — это соглашение Unix для демона, фонового процесса без окна и иконки в доке. Он запускается системой, а не вами, и работает, когда для него есть очередь задач.

Самое важное слово — фон. Когда разработчик использует NSURLSession, он может пометить загрузку или выгрузку как фоновую передачу, что говорит системе, что она должна продолжать работу даже в таких случаях, когда приложение не активно: пользователь закрывает приложение, оно приостановлено, происходит сбой, или устройство оставлено в покое. macOS соблюдает это, передавая задачу nsurlsessiond, который выполняет её и уведомляет приложение позже, перезапуская его при необходимости, чтобы доставить результат. Поэтому крупная загрузка из App Store продолжает идти после закрытия окна App Store, а эпизод подкаста заканчивается, даже если вы никогда не открывали приложение подкаста.

Часто рядом можно увидеть nsurlstoraged. Это связанный с ним демон Apple, который занимается хранением данных сессий URL, таких как кэшированные ответы и cookies, и он также является нормальным. Обычно он показывает гораздо меньшую сетевую активность, так как его задача связана с хранением, а не с передачей по сети.

Это самое важное, что нужно понять о nsurlsessiond, и именно поэтому так много людей начинают ему подозревать. Трафик, связанный с nsurlsessiond, обычно принадлежит какому-то другому приложению. Это общий курьер, перевозящий пакеты для тех, кто их запрашивает, и пакеты не адресованы ему.

Когда Photos загружает партию изображений в iCloud, байты проходят через nsurlsessiond. Когда App Store скачивает обновление объёмом в несколько гигабайт, то же самое. Когда сторонний клиент синхронизирует файлы или предварительно кэширует медиа, очень часто происходит то же самое. Весь этот трафик открыт одним процессом, приписан одному процессу и отображается под одним именем.

Activity Monitor и любые инструменты, которые определяют трафик исключительно по процессу, владеющему сокетом, не могут это распутать. Они показывают то, что верно на уровне операционной системы: соединения принадлежат nsurlsessiond. Что они не могут показать — это запрашивающее приложение за каждым переносом, потому что эта связь находится на уровне выше сокета. В результате получается одна строка, которая выглядит как один процесс, потребляющий огромную пропускную способность, хотя на самом деле это работа нескольких приложений под одним ярлыком.

Так что большая часть тревог по поводу nsurlsessiond — это неправильное приписывание, а не неправильное поведение. Если вы задаётесь вопросом, почему Apple-демону нужны сорок гигабайт загрузок, ответ в том, что он их не запрашивал. Что-то на вашем Mac попросило их.

Это также объясняет, почему демон кажется работающим постоянно. Он не держит постоянное соединение. Он просыпается, когда есть очередь на передачу, выполняет работу и снова засыпает. На Mac, который синхронизирует фотографии, документы, вложения в почте и обновления приложений, почти всегда есть что-то в очереди.

nsurlsessiond не является вредоносным ПО. Это компонент первого уровня macOS, присутствующий на каждом современном Mac, и его не нужно удалять, отключать или очищать с помощью утилит.

Обоснованная осторожность при вопросе заключается в том, что вредоносное ПО иногда использует имена, похожие на системные процессы, надеясь, что быстрый взгляд на список процессов пропустит его. Два способа проверки в Terminal это опровергнуть, и их стоит знать для любого процесса, не только этого.

Первая проверка — местоположение. Спроси систему, где находится запущенный бинарный файл, используя команду pgrep с флагами -lf и шаблоном nsurlsessiond. Настоящий демон находится внутри системного фреймворка, глубоко в пути CFNetwork. Всё, что утверждает, что это имя из папки Downloads, домашней директории или незнакомого пакета приложений — не Apple-демон.

Вторая проверка — подпись кода, и она более надежна, потому что путь можно подделать, а действительная подпись Apple — нет. Запусти codesign с флагами -dv и verbose против найденного пути к бинарнику. Настоящий демон показывает цепочку доверия, принадлежащую Apple, с указанием Software Signing и Apple Code Signing Certification Authority. Не подписанный бинарник или подписанный неизвестным разработчиком — повод для беспокойства.

Если обе проверки пройдены успешно, процесс — это то, чем он заявляется, и любые удивления по поводу его поведения — вопрос к очереди приложений, которые через него работают.

Поскольку nsurlsessiond работает только от имени другого процесса, необычная активность — это симптом, а полезная диагностика — это проверка на более высоком уровне. Есть несколько причин, которые объясняют большинство случаев.

Самая распространённая — iCloud. Только что включённая библиотека iCloud Photos, восстановленный Mac или большой объём новых импортов создают устойчивый трафик, который может продолжаться часами или днями в зависимости от размера библиотеки и скорости соединения. iCloud Drive ведёт себя так же после изменения большой папки. Далее идёт App Store, включая крупные обновления приложений и системные обновления, подготовленные в фоновом режиме. Третьи — медиа‑приложения, предварительно кэширующие контент, например подкаст‑клиенты, скачивающие несколько эпизодов вперёд.

Упорядоченный способ проверки — от наименее затратного к более сложному. Начните с кандидатов в активных приложениях: откройте раздел обновлений App Store и Системные настройки, чтобы проверить, не скачивается ли обновление. Затем откройте Photos и посмотрите строку статуса внизу вида «Библиотека», которая показывает прогресс синхронизации и число элементов, и проверьте iCloud Drive в Finder на наличие ожидающих элементов. Далее учтите всё, что было установлено или перенастроено недавно, поскольку новый клиент синхронизации часто вызывает такое поведение. Наконец, дайте процессу поработать, потому что передачи с определённым концом в итоге завершаются.

Высокая нагрузка на CPU обычно связана с теми же причинами, поскольку продолжительные передачи означают непрерывную работу, а не простой режим ожидания. Постоянно высокий уровень загрузки CPU без существенной пропускной способности встречается реже, и часто исчезает после перезагрузки, которая сбрасывает демон и его очередь без долговременных последствий.

Чего стоит избегать — так это блокировки его работы. Вы можете запретить nsurlsessiond доступ к сети через брандмауэр, и в результате фоновые передачи во всей системе остановятся, обычно без каких‑либо ошибок. Загрузки не завершаются, синхронизация iCloud зависает, а приложения, которые ожидают, что их передачи завершены, обнаруживают, что это не так. Поскольку сбой молчалив и системен, это плохая альтернатива. Правильная рычаг — это приложение, ставящее работу в очередь, а не курьер, который её доставляет.

Это оставляет вопрос, на который встроенные инструменты не могут ответить: какое приложение на самом деле запрашивало всё это. Activity Monitor останавливается на границе процесса, поэтому строка показывает nsurlsessiond, и след заканчивается там.

Более точный подход — перестать полагаться на имена процессов и вместо этого смотреть на назначения. Соединения всё равно идут куда‑то, и эти конечные точки определяют сервис, стоящий за передачей, даже когда имя процесса этого не показывает. Конечные точки доставки контента Apple и iCloud выглядят явно отличающимися от сторонних сервисов синхронизации или медиa‑CDN, и как только вы видите домены, attribution перестаёт быть догадкой.

Это тот пробел, вокруг которого построен NetMute. Он показывает трафик в реальном времени для каждого приложения и процесса, а не одну агрегированную цифру, и сочетает это с логированием на уровне доменов, чтобы вы могли видеть, к каким конечным точкам идёт передача. Это превращает анонимную строку в ясную картину: сколько идёт в iCloud, сколько — в приложение, которое вы установили на прошлой неделе.

Как только вы узнаете источник, NetMute предоставляет пропорциональные способы реагировать, ориентированные на ответственное приложение, а не на системный демон. Вы можете заблокировать сетевой доступ приложения одним кликом или использовать временное правило с истекающим сроком действия, если вам нужно, чтобы было тихо только в течение следующего часа. Ограничение данных для каждого приложения автоматически срабатывает при достижении лимита, что подходит для приложения, которое ведёт себя хорошо, пока не решит предварительно кэшировать сезон чего‑то. Профили сети позволяют этим правилам меняться в зависимости от контекста, например ноутбук, подключённый к платному хот‑споту, может применять лимиты, которые не нужны дома.

Ничего из этого не требует вмешательства в nsurlsessiond. Демон продолжает выполнять свою работу, фоновые загрузки и передачи в iCloud продолжают завершаться, а приложение, генерирующее трафик, — это то, которое ограничивается.