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

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

Название легко разбирается, если знать это. NSURLSession это API, а конечная буква d это unix-условность для демона, фонового процесса без окна и значка в Dock. Он запускается системой, а не вами, и работает, когда для него есть поставленные в очередь задачи.

Самое важное здесь слово background. Когда разработчик использует 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 и System Settings, чтобы проверить, не скачивается ли обновление. Затем откройте Photos и посмотрите строку статуса внизу вида Library, которая показывает прогресс синхронизации и число элементов, и проверьте iCloud Drive в Finder на наличие ожидающих элементов. Далее учтите всё, что было установлено или перенастроено недавно, поскольку новый клиент синхронизации часто вызывает такое поведение. Наконец, дайте процессу поработать, потому что передачи с определённым концом в итоге завершаются.

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

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

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

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

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

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

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