Cos'è nsurlsessiond su Mac? Il daemon di download in background spiegato

nsurlsessiond è un daemon di sistema che viene fornito con macOS ed è firmato da Apple. È l'agente di trasferimento in background per NSURLSession, l'API di rete standard che le applicazioni su piattaforme Apple usano per comunicare con i server.

Il nome si scompone facilmente una volta capito questo. NSURLSession è l'API, e la 'd' finale è la convenzione Unix per un daemon, un processo in background senza finestra e senza icona nel dock. Viene avviato dal sistema piuttosto che da te, e funziona ogni volta che c'è un lavoro in coda.

La parte importante è la parola background. Quando uno sviluppatore usa NSURLSession, può contrassegnare un download o upload come trasferimento in background, il che dice al sistema che dovrebbe sopravvivere a circostanze in cui l'app stessa non potrebbe: l'utente chiude l'app, l'app viene sospesa, l'app si blocca, o il Mac viene lasciato da solo. macOS rispetta questa impostazione affidando il trasferimento a nsurlsessiond, che lo esegue e notifica l'app successivamente, rilanciandola se necessario per consegnare il risultato. Per questo motivo un download di grandi dimensioni dall'App Store continua a progredire anche dopo aver chiuso la finestra dell'App Store, e perché un episodio di podcast termina di arrivare anche se non hai mai riaperto l'app del podcast.

Spesso vedrai anche nsurlstoraged elencato nelle vicinanze. È un daemon di Apple strettamente correlato che gestisce lo storage di dati di URL session come risposte cache e cookie, ed è ugualmente normale. Di solito mostra molto meno attività di rete, poiché il suo lavoro si svolge sul lato storage piuttosto che sulla rete.

Questa è la cosa più importante da capire su nsurlsessiond, ed è il motivo per cui molte persone diventano sospettose nei suoi confronti. Il traffico attribuito a nsurlsessiond di solito appartiene a qualche altra app. È un corriere condiviso, che trasporta pacchetti per chiunque lo richieda, e i pacchetti non sono indirizzati a lui.

Quando Photos carica un batch di immagini su iCloud, i byte viaggiano attraverso nsurlsessiond. Quando l'App Store scarica un aggiornamento di diversi gigabyte, lo stesso. Quando un client di terze parti sincronizza file o pre-carica media, molto spesso lo stesso. Tutto quel traffico viene aperto da un processo, attribuito a un processo, e appare sotto un solo nome.

Activity Monitor, e qualsiasi strumento che identifica il traffico esclusivamente in base al processo che possiede la socket, non può districare questo. Riporta ciò che è vero a livello del sistema operativo: le connessioni appartengono a nsurlsessiond. Quello che non può mostrare è l'app che richiede ogni trasferimento, perché quella relazione vive su un livello superiore rispetto alla socket. Il risultato è una singola riga che sembra rappresentare un processo che consuma una quantità enorme di banda, quando in realtà sono più app a lavorare sotto un'unica etichetta.

Quindi, una grande parte degli allarmi su nsurlsessiond sono attribuzioni errate, non comportamenti scorretti. Se ti chiedi perché un daemon Apple avrebbe bisogno di quarantacinque gigabyte di download, la risposta è che non li ha richiesti lui. Qualcosa sul tuo Mac li ha richiesti.

Questo spiega anche perché il daemon sembra funzionare costantemente. Non mantiene una connessione permanente propria. Si sveglia quando è in coda un trasferimento, esegue il lavoro e poi si mette in quiete; su un Mac che sincronizza foto, documenti, allegati di posta e aggiornamenti di app, c'è quasi sempre qualcosa in coda.

nsurlsessiond non è malware. È un componente di prima parte di macOS, presente su ogni Mac attuale, e non necessita di essere rimosso, disattivato o ripulito da utility.

La cautela ragionevole dietro alla domanda è che il malware a volte adotta nomi simili ai processi di sistema, sperando che una rapida occhiata alla lista dei processi lo faccia passare. Due controlli nel Terminale lo smentiscono, e sono utili da conoscere per qualsiasi processo, non solo questo.

Il primo controllo è la posizione. Chiedi al sistema dove si trova il binario in esecuzione usando il comando pgrep con le opzioni -lf e nsurlsessiond come pattern. Il daemon genuino si trova all’interno di un percorso di framework di sistema, nel profondo del framework CFNetwork. Qualsiasi cosa che dichiari quel nome dalla cartella Download, dalla directory home, o da un bundle di applicazioni sconosciuto, non è il daemon Apple.

Il secondo controllo è la firma del codice, ed è il più forte dei due, perché un percorso può essere imitato mentre una firma Apple valida no. Esegui codesign con le opzioni -dv e verbose contro il percorso del binario che hai trovato. Il daemon autentico riporta una catena di autorità appartenente ad Apple, nominando Software Signing e l’Apple Code Signing Certification Authority. Un binario non firmato, o firmato da uno sviluppatore sconosciuto, dovrebbe destare sospetti.

Se entrambi i controlli passano, il processo è quello che dice di essere, e qualsiasi sorpresa sul suo comportamento è una questione riguardante le app che gli affidano il lavoro.

Poiché nsurlsessiond opera sempre per conto di qualcos’altro, un’attività insolita da parte sua è un sintomo, e la diagnosi utile è a monte. Un piccolo insieme di cause rappresenta la maggior parte dei casi.

La più comune è iCloud. Una libreria di Photos appena attivata, un Mac ripristinato o un grande batch di importazioni produce traffico sostenuto che può durare ore o giorni, a seconda delle dimensioni della libreria e della velocità di connessione. iCloud Drive si comporta allo stesso modo dopo una grande modifica di cartella. Poi c’è l’App Store, inclusi grandi aggiornamenti di app e aggiornamenti di sistema messi in staging in background. Terzo ci sono le app multimediali che pre-caricano contenuti, come i client di podcast che scaricano diversi episodi in anticipo.

Un modo ordinato per controllare, dal meno al più impegnativo. Inizia con i candidati in primo piano: apri la vista Aggiornamenti dell’App Store e le Impostazioni di Sistema per vedere se un aggiornamento si sta scaricando. Poi apri Photos e leggi la riga di stato in basso nella vista Libreria, che indica lo stato della sincronizzazione e il conteggio degli elementi, e controlla iCloud Drive in Finder per gli elementi in sospeso. Considera anche qualsiasi cosa installata o riconfigurata di recente, poiché un client di sincronizzazione aggiunto di recente è un trigger frequente. Infine, lascialo completare, perché i trasferimenti con un termine definito si conclude­no.

L’elevato utilizzo di CPU di solito è dovuto alle stesse cause, poiché trasferimenti sostenuti significano lavoro continuo piuttosto che attesa inattiva. Un utilizzo persistente di CPU elevato senza throughput significativo è meno tipico, e spesso si risolve con un riavvio, che resetta il daemon e la sua coda senza effetti duraturi.

Quello che è bene evitare è bloccarlo. Puoi negare a nsurlsessiond l’accesso alla rete con un firewall, e il risultato è che i trasferimenti in background su tutto il sistema smettono di funzionare, di solito senza un errore che lo spieghi. I download non si completano mai, la sincronizzazione legata a iCloud si blocca, e le app che si aspettano che i trasferimenti siano terminati scoprono che non lo sono. Poiché il fallimento è silenzioso e interessa l’intero sistema, è un compromesso negativo. La leva giusta è l’app che mette in coda il lavoro, non il corriere che lo trasporta.

Questo lascia aperta la domanda a cui gli strumenti integrati non possono rispondere: quale applicazione ha effettivamente richiesto tutto questo. Activity Monitor si ferma al limite del processo, quindi la riga indica nsurlsessiond e la traccia termina lì.

Un approccio più preciso è smettere di fare affidamento sui nomi dei processi e guardare invece alle destinazioni. Le connessioni vanno ancora da qualche parte, e quegli endpoint identificano il servizio dietro a un trasferimento anche quando il nome del processo non lo fa. Gli endpoint di consegna contenuti di Apple e iCloud appaiono chiaramente diversi da un servizio di sincronizzazione di terze parti o da un CDN di media, e una volta che puoi vedere i domini, l'attribuzione smette di essere un'ipotesi.

Questa è la lacuna su cui si basa NetMute. Mostra traffico in tempo reale per-app e per-processo piuttosto che un singolo dato aggregato, e lo abbina a un logging a livello di dominio così puoi vedere a quali endpoint un trasferimento sta arrivando. Questo trasforma una riga anonima in un quadro chiaro: questa quantità va a iCloud, questa a un'app installata la settimana scorsa.

Una volta che conosci la fonte, NetMute ti offre modi proporzionati per agire, puntando all'app responsabile piuttosto che al daemon di sistema. Puoi bloccare l'accesso di un'app alla rete con un clic, o usare una regola temporanea a scadenza automatica quando vuoi solo un po' di silenzio per la prossima ora. Un limite di dati per-app si blocca automaticamente al raggiungimento del limite, adatto a un'app che si comporta bene finché non decide di pre-caching di una stagione di qualcosa. I profili di rete permettono di cambiare le regole in base al contesto, così un MacBook collegato a un hotspot con limiti di traffico applica restrizioni che a casa non sono necessarie.

Niente di tutto ciò richiede di toccare nsurlsessiond. Il daemon continua a fare il suo lavoro, i download in background e i trasferimenti di iCloud continuano a completarsi, e l'app che genera il traffico è quella che viene limitata.