Qu’est-ce que nsurlsessiond sur Mac ? Le démon de téléchargement en arrière-plan expliqué

nsurlsessiond est un daemon système livré avec macOS et signé par Apple. C’est l’agent de transfert en arrière-plan pour NSURLSession, l’API réseau standard que les applications sur les plateformes Apple utilisent pour communiquer avec les serveurs.

Le nom se décompose clairement une fois que vous savez cela. NSURLSession est l’API, et le d final est la convention Unix pour un daemon, un processus en arrière-plan sans fenêtre ni icône dans le dock. Il est lancé par le système plutôt que par vous, et il fonctionne chaque fois qu’il y a du travail en file d’attente.

Ce qui importe, c’est le mot background. Lorsqu’un développeur utilise NSURLSession, il peut marquer un téléchargement ou un upload comme une transfert en arrière-plan, ce qui indique au système qu’il doit survivre à des circonstances que l’application elle-même ne supporterait pas : l’utilisateur quitte l’application, l’application est suspendue, l’application plante, ou la machine est laissée seule. macOS respecte cela en confiant le transfert à nsurlsessiond, qui l’effectue et notifie l’application plus tard, la relançant si nécessaire pour livrer le résultat. C’est pourquoi un téléchargement important depuis l’App Store continue de progresser après que vous avez fermé la fenêtre de l’App Store, et pourquoi un épisode de podcast se termine d’arriver même si vous n’avez jamais rouvert l’application de podcast.

Vous verrez souvent nsurlstoraged listé à proximité. C’est un daemon Apple étroitement lié qui gère le stockage des données de session URL, comme les réponses en cache et les cookies, et c’est tout aussi normal. Il affiche généralement beaucoup moins d’activité réseau, car son travail se situe du côté du stockage plutôt que sur le fil.

C'est la chose la plus importante à comprendre à propos de nsurlsessiond, et c'est la raison pour laquelle beaucoup de personnes deviennent méfiantes à son sujet. Le trafic attribué à nsurlsessiond appartient généralement à une autre application. C'est un messager partagé, transportant des paquets pour quiconque en fait la demande, et ces paquets ne lui sont pas destinés.

Lorsque Photos téléverse un lot d'images sur iCloud, les octets transitent par nsurlsessiond. Lorsqu'une mise à jour de plusieurs gigaoctets est téléchargée depuis l'App Store, c'est pareil. Lorsqu'un client tiers synchronise des fichiers ou pré-cache des médias, très souvent, c'est encore la même chose. Tout ce trafic est ouvert par un seul processus, attribué à un seul processus, et apparaît sous un seul nom.

Activity Monitor, et tout outil qui identifie le trafic uniquement par le processus propriétaire du socket, ne peut pas faire la différence. Il indique ce qui est vrai au niveau du système d'exploitation : les connexions appartiennent à nsurlsessiond. Ce qu'il ne peut pas montrer, c'est l'application qui fait la requête derrière chaque transfert, car cette relation se situe à un niveau au-dessus du socket. Le résultat est une seule ligne qui ressemble à un seul processus consommant une bande passante énorme, alors qu'il s'agit en réalité du travail de plusieurs applications sous une seule étiquette.

Donc, une grande partie des alertes concernant nsurlsessiond sont des erreurs d'attribution, et non un mauvais comportement. Si vous vous demandez pourquoi un démon Apple aurait besoin de quarante gigaoctets de téléchargements, la réponse est qu'il ne les a pas demandés. Quelque chose sur votre Mac en a fait la demande.

Cela explique aussi pourquoi le démon semble fonctionner en permanence. Il ne maintient pas une connexion permanente. Il se réveille lorsqu'un transfert est mis en file d'attente, effectue le travail, puis se tait, et sur une machine synchronisant des photos, des documents, des pièces jointes d'e-mails et des mises à jour d'applications, il y a presque toujours quelque chose en attente.

nsurlsessiond n’est pas un logiciel malveillant. Il s’agit d’un composant Apple intégré (first‑party) de macOS, présent sur tous les Mac actuels, et il n’a pas besoin d’être supprimé, désactivé ou nettoyé par une quelconque utilité.

La prudence justifiée derrière la question vient du fait que des logiciels malveillants adoptent parfois des noms proches de ceux des processus système, espérant qu’un simple coup d’œil à la liste des processus leur permettra de passer inaperçus. Deux vérifications dans le Terminal permettent de le déceler, et elles valent la peine d’être connues pour n’importe quel processus, pas seulement celui‑ci.

La première vérification porte sur l’emplacement. Demandez au système où se trouve le binaire en cours d’exécution en utilisant la commande pgrep avec les options -lf et nsurlsessiond comme motif. Le véritable démon se trouve dans un chemin de framework système, profondément dans le framework CFNetwork. Tout élément portant ce nom depuis votre dossier Téléchargements, votre répertoire personnel ou un bundle d’application inconnu n’est pas le démon Apple.

La deuxième vérification porte sur la signature du code, et elle est la plus fiable des deux, car un chemin peut être imité alors qu’une signature Apple valide ne peut pas. Exécutez codesign avec les options -dv et --verbose sur le chemin du binaire que vous avez trouvé. Le véritable démon affiche une chaîne d’autorité appartenant à Apple, mentionnant Software Signing et l’Apple Code Signing Certification Authority. Un binaire non signé, ou signé par un développeur inconnu, justifierait une inquiétude.

Si les deux vérifications sont concluantes, le processus est bien ce qu’il prétend être, et toute surprise quant à son comportement relève des applications qui lui confient du travail.

Parce que nsurlsessiond ne travaille jamais que pour le compte de quelque chose d'autre, une activité inhabituelle de sa part est un symptôme, et le diagnostic utile se trouve en amont. Un petit nombre de causes explique la majorité des cas.

La cause la plus courante est iCloud. Une bibliothèque Photos iCloud récemment activée, un Mac restauré, ou un gros lot d'importations produit un trafic soutenu qui peut durer des heures ou des jours selon la taille de la bibliothèque et la vitesse de connexion. iCloud Drive se comporte de la même manière après un changement important de dossier. Ensuite, vient l'App Store, y compris les mises à jour importantes d'applications et les mises à jour système en arrière-plan. Troisièmement, les applications médias pré-cachent du contenu, comme les clients de podcasts qui téléchargent plusieurs épisodes à l'avance.

Une méthode ordonnée pour vérifier, du moins coûteux au plus impliquant. Commence par les candidats en premier plan : ouvre la vue des mises à jour de l'App Store et les Paramètres Système pour voir si une mise à jour est en cours de téléchargement. Ensuite, ouvre Photos et lis la ligne d'état en bas de la vue Bibliothèque, qui indique la progression de la synchronisation et le nombre d'éléments, puis vérifie iCloud Drive dans le Finder pour voir s'il y a des éléments en attente. Considère aussi tout ce qui a été installé ou reconfiguré récemment, car un nouveau client de synchronisation ajouté est souvent un déclencheur. Enfin, laisse faire, car les transferts avec une fin définie se terminent.

Une utilisation élevée du CPU suit généralement les mêmes causes, puisque des transferts soutenus impliquent un travail continu plutôt qu'une attente inactive. Une utilisation persistante du CPU sans débit significatif est moins courante, et elle disparaît souvent après un redémarrage, qui réinitialise le daemon et sa file d'attente sans effet durable.

Ce qu'il faut éviter, c'est de le bloquer. Tu peux refuser à nsurlsessiond l'accès réseau via un pare-feu, mais le résultat est que les transferts en arrière-plan dans tout le système cessent de fonctionner, généralement sans message d'erreur explicatif. Les téléchargements ne se terminent jamais, la synchronisation liée à iCloud se bloque, et les applications qui attendent que leurs transferts soient terminés constatent qu'ils ne le sont pas. Étant donné que cette défaillance est silencieuse et systémique, c'est un mauvais compromis. Le bon levier, c'est la file d'attente du travail des applications, pas le messager qui le transporte.

Cela soulève la question à laquelle les outils intégrés ne peuvent pas répondre : quelle application a réellement demandé tout cela. Activity Monitor s'arrête à la limite du processus, donc la ligne indique nsurlsessiond et la piste s'arrête là.

Une approche plus précise consiste à cesser de se fier aux noms des processus et à examiner plutôt les destinations. Les connexions vont toujours quelque part, et ces points de terminaison identifient le service derrière un transfert même lorsque le nom du processus ne le fait pas. Les points de terminaison de la livraison de contenu Apple et d'iCloud ont une apparence nettement différente d'un service de synchronisation tiers ou d'un CDN média, et une fois que vous pouvez voir les domaines, l'attribution cesse d'être une supposition.

C'est l'écart autour duquel NetMute est construit. Il affiche le trafic en temps réel par application et par processus plutôt qu'une seule valeur agrégée, et le combine avec une journalisation au niveau du domaine pour que vous puissiez voir quels points de terminaison un transfert atteint. Cela transforme une ligne anonyme en une image claire : tant vers iCloud, tant vers une application que vous avez installée la semaine dernière.

Une fois que vous connaissez la source, NetMute vous offre des moyens proportionnels d'agir, ciblant l'application responsable plutôt que le daemon système. Vous pouvez bloquer l'accès réseau d'une application en un clic, ou utiliser une règle temporaire à expiration automatique lorsque vous souhaitez simplement un peu de silence pendant l'heure suivante. Une limite de données par application se bloque automatiquement au seuil, ce qui convient à une application qui se comporte bien jusqu'à ce qu'elle décide de précharger une saison de quelque chose. Les profils réseau permettent à ces règles de changer selon le contexte, par exemple un MacBook connecté à un hotspot avec quota impose des limites qu'il n'a pas besoin d'appliquer à la maison.

Aucun de ces réglages ne nécessite de toucher à nsurlsessiond. Le daemon continue de faire son travail, les téléchargements en arrière-plan et les transferts iCloud se terminent, et l'application générant le trafic est celle qui est limitée.