Wat is nsurlsessiond op Mac? De achtergrond download daemon uitgelegd

nsurlsessiond is een systeemdaemon die wordt meegeleverd met macOS en door Apple is ondertekend. Het is de achtergrondtransferservice voor NSURLSession, de standaard netwerk-API die applicaties op Apple-platforms gebruiken om met servers te communiceren.

De naam wordt duidelijk zodra je dat weet. NSURLSession is de API, en het achtervoegsel d is de Unix-conventie voor een daemon, een achtergrondproces zonder venster en zonder dock-icoon. Het wordt gestart door het systeem in plaats van door jou, en het draait wanneer er werk voor is gepland.

Het belangrijke woord is achtergrond. Wanneer een ontwikkelaar NSURLSession gebruikt, kan hij of zij een download of upload markeren als een achtergrondtransfer, wat het systeem vertelt dat het moet overleven onder omstandigheden waarin de app zelf dat niet zou doen: de gebruiker sluit de app, de app wordt gepauzeerd, de app crasht, of de Mac wordt alleen gelaten. macOS respecteert dat door de overdracht over te dragen aan nsurlsessiond, die het uitvoert en de app later op de hoogte brengt, en het opnieuw opstart indien nodig om het resultaat te leveren. Daarom blijft een grote App Store-download doorgaan nadat je het App Store-venster hebt gesloten, en waarom een podcast-aflevering blijft binnenkomen, zelfs als je de podcast-app nooit hebt heropend.

Je zult vaak nsurlstoraged zien staan in de buurt. Het is een nauw verwante Apple-daemon die opslag beheert voor URL-sessiedata zoals gecachte antwoorden en cookies, en het is even normaal. Het vertoont doorgaans veel minder netwerkactiviteit, omdat zijn taak aan de opslagzijde ligt in plaats van op de draad.

Dit is het belangrijkste om te begrijpen over nsurlsessiond, en het is de reden dat zoveel mensen er argwaan tegen krijgen. Het verkeer dat aan nsurlsessiond wordt toegeschreven, behoort meestal tot een andere app. Het is een gedeelde koerier, die pakketjes vervoert voor iedereen die erom vraagt, en de pakketjes zijn niet aan hem geadresseerd.

Wanneer Foto's een batch afbeeldingen naar iCloud uploadt, reizen de bytes via nsurlsessiond. Wanneer de App Store een grote update binnenhaalt, hetzelfde. Wanneer een third-partyclient bestanden synchroniseert of media pre-cacht, gebeurt dat heel vaak weer hetzelfde. Al dat verkeer wordt geopend door één proces, toegeschreven aan één proces en verschijnt onder één naam.

Activity Monitor, en elk hulpmiddel dat verkeer puur identificeert op basis van het proces dat de socket bezit, kan dat niet uitpluizen. Het rapporteert wat waar is op het besturingssysteemniveau: de verbindingen behoren tot nsurlsessiond. Wat het niet kan tonen, is de app die de aanvraag doet achter elke overdracht, omdat die relatie zich één laag boven de socket bevindt. Het resultaat is een enkele regel die lijkt op één proces dat enorme bandbreedte verbruikt, terwijl het in werkelijkheid werk is van meerdere apps onder één label.

Dus een groot deel van nsurlsessiond-waarschuwingen is verkeerde toewijzing, niet verkeerd gedrag. Als je je afvraagt waarom een Apple-daemon vierentwintig gigabyte aan downloads nodig zou hebben, is het antwoord dat dat niet zo was. Iets op je Mac heeft erom gevraagd.

Dit verklaart ook waarom de daemon constant lijkt te draaien. Het houdt geen permanente verbinding van zichzelf. Het wordt wakker wanneer een overdracht in de wachtrij wordt geplaatst, doet het werk en wordt stil, en op een machine die Foto's, documenten, e-mailbijlagen en app-updates synchroniseert, is er bijna altijd iets in de wachtrij.

nsurlsessiond is geen malware. Het is een first-party component van macOS, aanwezig op elke huidige Mac, en het hoeft niet verwijderd, uitgeschakeld of opgeschoond te worden door een hulpprogramma.

De redelijke voorzichtigheid achter de vraag is dat malware soms namen aanneemt die op systeemprocessen lijken, in de hoop dat een snelle blik op een proceslijst het doorlaat. Twee controles in Terminal weerleggen dat, en ze zijn het waard om te weten voor elk proces, niet alleen dit.

De eerste controle is locatie. Vraag het systeem waar de werkende binary zich bevindt met het commando pgrep met de -lf vlaggen en nsurlsessiond als patroon. De echte daemon bevindt zich in een systeemframeworkpad, diep in het CFNetwork-framework. Alles dat die naam claimt vanuit je Downloads-map, je thuismap, of een onbekende applicatiebundle, is niet de Apple-daemon.

De tweede controle is de codehandtekening, en dat is de sterkere van de twee, omdat een pad geïmiteerd kan worden terwijl een geldige Apple-handtekening dat niet kan. Voer codesign uit met de -dv en verbose vlaggen tegen het gevonden binaire pad. De echte daemon rapporteert een autoriteitsketen die toebehoort aan Apple, met Software Signing en de Apple Code Signing Certification Authority. Een niet-ondertekend binaire, of eentje ondertekend door een onbekende ontwikkelaar, zou reden tot zorg geven.

Als beide controles slagen, is het proces wat het beweert te zijn, en is elke verrassing over het gedrag ervan een vraag over de apps die werk via het uitvoeren.

Omdat nsurlsessiond alleen werkt namens iets anders, is ongebruikelijke activiteit van hem een symptoom, en de nuttige diagnose ligt upstream. Een klein aantal oorzaken is verantwoordelijk voor de meeste gevallen.

De meest voorkomende is iCloud. Een pas ingeschakelde iCloud Foto's-bibliotheek, een herstelde Mac, of een grote batch nieuwe imports veroorzaken aanhoudend verkeer dat uren of dagen kan duren, afhankelijk van de bibliotheekgrootte en de verbindingssnelheid. iCloud Drive gedraagt zich hetzelfde na een grote mapwijziging. Vervolgens komt de App Store, inclusief grote app-updates en systeemupdates die op de achtergrond worden gestaged. Derde zijn media-apps die content pre-cachen, zoals podcast-clients die meerdere afleveringen vooruit trekken.

Een gestructureerde manier om te controleren, van goedkoop naar meest betrokken. Begin met de voorgrondkandidaten: open de App Store-updatesweergave en Systeeminstellingen om te zien of er een update wordt gedownload. Open vervolgens Foto's en lees de statusregel onderaan de bibliotheekweergave, die synchronisatievoortgang en itemaantallen rapporteert, en controleer iCloud Drive in Finder op pending items. Overweeg daarna alles dat recent is geïnstalleerd of opnieuw geconfigureerd, aangezien een nieuw toegevoegde sync-client vaak de trigger is. Laat het uiteindelijk draaien, want overdrachten met een vast einde worden afgerond.

Hoge CPU gebruikt meestal dezelfde oorzaken, omdat voortdurende overdrachten continu werk betekenen in plaats van inactief wachten. Persistent hoge CPU zonder zinvolle doorvoer is minder gebruikelijk, en verdwijnt vaak na een herstart, die de daemon en de wachtrij reset zonder blijvende effecten.

Wat je moet vermijden, is het blokkeren ervan. Je kunt nsurlsessiond netwerktoegang ontzeggen met een firewall, en het resultaat is dat achtergrondtransfers in het hele systeem stoppen, meestal zonder foutmelding. Downloads worden nooit voltooid, iCloud-synchronisatie stopt, en apps die verwachten dat hun overdrachten klaar zijn, ontdekken dat dat niet het geval is. Omdat het falen stil en systeemwijd is, is dat een slechte keuze. De juiste aanpak is de app die het werk in de wachtrij zet, niet de koerier die het vervoert.

Dat laat de vraag open die de ingebouwde tools niet kunnen beantwoorden: welke applicatie heeft hier daadwerkelijk om gevraagd. Activity Monitor stopt bij de procesgrens, dus de rij zegt nsurlsessiond en het spoor eindigt daar.

Een scherpere aanpak is om niet meer op procesnamen te vertrouwen, maar op bestemmingen te kijken. De verbindingen gaan nog steeds ergens naartoe, en die eindpunten identificeren de dienst achter een overdracht, zelfs als de procesnaam dat niet doet. Apple content delivery en iCloud-eindpunten zien er duidelijk anders uit dan een synchronisatiedienst van een derde partij of een media CDN, en zodra je de domeinen kunt zien, stopt het raden wie wat doet.

Dit is de kloof waar NetMute om gebouwd is. Het toont realtime per-app en per-proces verkeer in plaats van een enkel totaal, en combineert dat met domeinniveau logging zodat je kunt zien welke eindpunten een overdracht bereiken. Dat verandert een anonieme rij in een duidelijk beeld: zoveel gaat naar iCloud, zoveel naar een app die je vorige week hebt geïnstalleerd.

Zodra je de bron weet, geeft NetMute je proportionele manieren om er actie op te ondernemen, gericht op de verantwoordelijke app in plaats van de systeemdaemon. Je kunt de netwerktoegang van een app blokkeren met één klik, of tijdelijke regels instellen die vanzelf verlopen, of de datalimiet van een app automatisch laten blokkeren bij de limiet. Een per-app datalimiet wordt automatisch toegepast bij de limiet, wat geschikt is voor een app die zich goed gedraagt totdat hij besluit een seizoen van iets te pre-cachen. Netwerkprofielen laten die regels veranderen afhankelijk van de context, bijvoorbeeld een laptop op een meter hotspot die limieten afdwingt die thuis niet nodig zijn.

Niets daarvan vereist het aanraken van nsurlsessiond. De daemon blijft zijn werk doen, achtergronddownloads en iCloud-overdrachten worden gewoon voltooid, en de app die het verkeer genereert, wordt beperkt.