Hva nsurlsessiond egentlig er
nsurlsessiond er en systemdaemon som følger med macOS og er kode-signert av Apple. Det er en bakgrunnsoverføringsagent for NSURLSession, det standard nettverks-API-et som apper på Apple-plattformer bruker for å snakke med servere.
Navnet deles opp tydelig når du vet det. NSURLSession er API-et, og den avsluttende d er Unix-konvensjonen for en daemon, en bakgrunnsprosess uten vindu og uten dock-ikon. Den startes av systemet i stedet for av deg, og den kjører når det er arbeid i kø for den.
Det viktige er ordet bakgrunn. Når en utvikler bruker NSURLSession, kan de merke en nedlasting eller opplasting som en bakgrunnsoverføring, noe som forteller systemet at den skal overleve omstendigheter som appen selv ikke ville: brukeren avslutter appen, appen blir suspendert, appen krasjer, eller maskinen blir forlatt alene. macOS respekterer dette ved å overlate overføringen til nsurlsessiond, som utfører den og varsler appen senere, og starter den på nytt om nødvendig for å levere resultatet. Derfor fortsetter en stor Mac App Store-nedlasting å gå fremover etter at du lukker App Store-vinduet, og hvorfor en podkastepisode fullfører ankomsten selv om du aldri åpnet podkast-appen igjen.
Du vil ofte se nsurlstoraged listet i nærheten. Det er en nært beslektet Apple-daemon som håndterer lagring for URL-session-data som bufrede svar og cookies, og det er like normalt. Det viser vanligvis langt mindre nettverksaktivitet, siden jobben dens ligger på lagringssiden i stedet for på nettet.
Hvorfor trafikken dens egentlig er andres apper sin trafikk
Dette er det viktigste å forstå om nsurlsessiond, og det er grunnen til at så mange blir mistenksomme. Trafikken som tilskrives nsurlsessiond tilhører vanligvis en annen app. Det er en delt budbringer, som frakter pakker for hvem som helst som spør, og pakkene er ikke adressert til den.
Når Bilder laster opp en batch med bilder til iCloud, går byte gjennom nsurlsessiond. Når App Store laster ned en oppdatering på flere gigabyte, er det det samme. Når en tredjeparts klient synkroniserer filer eller forhåndsbuffer media, er det ofte det samme igjen. All den trafikken åpnes av én prosess, tilskrives én prosess, og vises under ett navn.
Activity Monitor, og alle verktøy som identifiserer trafikk utelukkende basert på prosessen som eier socketen, har ingen måte å skille dette på. Det rapporterer det som er sant på operativsystemnivå: tilkoblingene tilhører nsurlsessiond. Det den ikke kan vise, er hvilken app som ber om dataene bak hver overføring, fordi det forholdet ligger et lag over socketen. Resultatet er en enkelt rad som ser ut som én prosess som bruker enorm båndbredde, når det egentlig er flere apper som jobber under én etikett.
Så en stor del av varsler fra nsurlsessiond er feiltilskrivning, ikke feiloppførsel. Hvis du lurer på hvorfor en Apple-daemon trenger førti gigabyte nedlastinger, er svaret at den ikke gjorde det. Noe på Mac-en din ba om dem.
Dette forklarer også hvorfor daemonen ser ut til å kjøre konstant. Den holder ikke en permanent forbindelse på egen hånd. Den våkner når en overføring er i kø, gjør jobben, og blir stille igjen. På en maskin som synkroniserer bilder, dokumenter, e-postvedlegg og app-oppdateringer, er det nesten alltid noe i kø.
Er nsurlsessiond trygt, og hvordan verifisere det selv
nsurlsessiond er ikke malware. Det er en førsteparts komponent i macOS, til stede på alle nåværende Mac-er, og det trenger ikke fjernes, deaktiveres eller ryddes opp i av noen verktøy.
Den fornuftige forsiktigheten bak spørsmålet er at malware noen ganger adopterer navn som ligner på systemprosesser, i håp om at en rask titt på prosesslisten vil la den passere. To sjekker i Terminal gjør det umulig, og de er verdt å vite for alle prosesser, ikke bare dette.
Den første sjekken er plassering. Spør systemet hvor den kjørende binæren ligger ved å bruke pgrep-kommandoen med -lf-flaggene og nsurlsessiond som mønster. Den ekte daemonen ligger inne i en systemrammeverksbane, dypt inne i CFNetwork-rammeverket. Alt som påstår det navnet fra nedlastingsmappen, hjemmekatalogen eller en ukjent applikasjonsbundle, er ikke Apple-daemonen.
Den andre sjekken er kode-signaturen, og den er den sterkeste av de to, fordi en bane kan imiteres, mens en gyldig Apple-signatur ikke kan. Kjør codesign med -dv og verbose-flaggene mot binærbanen du fant. Den ekte daemonen rapporterer en autoritetskjede som tilhører Apple, med navnene Software Signing og Apple Code Signing Certification Authority. En usignert binær, eller en signert av en ukjent utvikler, vil være grunn til bekymring.
Hvis begge sjekkene består, er prosessen det den utgir seg for å være, og eventuelle overraskelser om oppførselen er et spørsmål om appene som køer jobben gjennom den.
Høy nettverksbruk eller høy CPU: hva du bør sjekke
Siden nsurlsessiond bare jobber på vegne av noe annet, er unormal aktivitet fra den et symptom, og den nyttige diagnosen er oppstrøms. En liten gruppe årsaker står for det store flertallet av tilfellene.
Den vanligste er iCloud. En nylig aktivert iCloud Bilder-bibliotek, en gjenopprettet Mac, eller en stor batch med nye importeringer gir vedvarende trafikk som kan vare i timer eller dager, avhengig av bibliotekets størrelse og tilkoblingshastighet. iCloud Drive oppfører seg på samme måte etter en stor mappeendring. Deretter kommer App Store, inkludert store app-oppdateringer og systemoppdateringer som er satt i gang i bakgrunnen. Tredje er medieapper som forhåndsbuffer innhold, som podkastklienter som laster ned flere episoder på forhånd.
En systematisk måte å sjekke på, fra minst involvert til mest involvert. Start med de fremste kandidatene: åpne App Store-oppdateringsvisningen og Systeminnstillinger for å se om en oppdatering lastes ned. Deretter åpne Bilder og les statuslinjen nederst i bibliotekvisningen, som viser synkroniseringsfremdrift og antall elementer, og sjekk iCloud Drive i Finder for ventende elementer. Vurder også nylig installerte eller re-konfigurerte apper, siden en ny sync-klient ofte utløser dette. Til slutt, la det kjøre, fordi overføringer med et definert sluttpunkt faktisk fullføres.
Høy CPU følger ofte de samme årsakene, siden vedvarende overføringer betyr kontinuerlig arbeid, ikke inaktiv venting. Vedvarende høy CPU uten meningsfull gjennomstrømning er mindre vanlig, og den forsvinner ofte ved en omstart, som nullstiller daemonen og køen uten varig effekt.
Det som er verdt å unngå, er å blokkere den. Du kan nekte nsurlsessiond nettverkstilgang med en brannmur, og resultatet er at bakgrunnsoverføringer over hele systemet stopper opp, vanligvis uten feil som forklarer det. Nedlastinger fullføres aldri, iCloud-synkronisering stopper opp, og apper som forventer at overføringene er ferdige, oppdager at de ikke er det. Fordi feilen er stille og systemomfattende, er det en dårlig handel. Den riktige tilnærmingen er appen som køer jobben, ikke budbringeren som frakter den.
Finne appen som la inn overføringen i køen
Det lar oss stille det ubesvarte spørsmålet: hvilken applikasjon spurte faktisk om alt dette. Activity Monitor stopper ved prosessgrensen, så raden sier nsurlsessiond og sporet ender der.
En skarpere tilnærming er å slutte å stole på prosessnavn og heller se på destinasjoner. Tilkoblingene går fortsatt et sted, og disse endepunktene identifiserer tjenesten bak en overføring selv når prosessnavnet ikke gjør det. Apple innholdslevering og iCloud-endepunkter ser tydelig annerledes ut enn en tredjeparts synkroniseringstjeneste eller en media CDN, og når du kan se domenene, slutter tilknytningen å være gjetning.
Dette er gapet NetMute er bygget rundt. Det viser sanntids trafikk per app og prosess i stedet for en enkelt samlet figur, og kombinerer det med domenenivå logging slik at du kan se hvilke endepunkter en overføring når. Det gjør en anonym rad til et tydelig bilde: så mye som går til iCloud, så mye til en app du installerte forrige uke.
Når du vet kilden, gir NetMute deg proporsjonale måter å handle på, rettet mot den ansvarlige appen i stedet for systemdæmonen. Du kan blokkere en apps nettverkstilgang med ett klikk, eller bruke en selvutløpende midlertidig regel når du bare vil ha stille i neste time. En per-app datagrense blokkerer automatisk ved grensen, noe som passer en app som oppfører seg bra inntil den bestemmer seg for å forhåndslagre en sesong av noe. Nettverksprofiler lar disse reglene endre seg med kontekst, slik at en bærbar PC på en målt hotspot håndhever grenser den ikke trenger hjemme.
Ingen av disse krever at du berører nsurlsessiond. Dæmonen fortsetter å gjøre jobben sin, bakgrunnsnedlastinger og iCloud-overføringer fullføres, og appen som genererer trafikken er den som blir begrenset.