Documentation technique NetQuickCheck

Sources de données et sélection d'interface

NetQuickCheck combine l'échantillonnage du système, les sondes de réseau actives et les statistiques dérivées. L'échantillonnage du système fournit des informations sur les interfaces, les connexions sans fil et les connexions des processus. Les sondes actives capturent la réponse d'une cible à une demande. Les statistiques dérivées transforment les observations en débits, percentiles et graphiques.

Les tâches avec une interface sélectionnée y lient leurs requêtes. Les requêtes TCP, UDP et HTTP directes utilisent la liaison d'interface Network.framework ; les sondes ICMP utilisent l'argument d'interface de la commande système. Le routage automatique permet à macOS de choisir le chemin et les requêtes HTTP automatiques suivent les politiques de session système et de proxy. L'interface sélectionnée est enregistrée avec les résultats pour prendre en charge les comparaisons entre Wi-Fi, Ethernet et autres interfaces disponibles.

Réseau actuel et vérifications rapides

Mesures des interfaces et débits de transfert

Le réseau actuel lit l'état de l'interface, les adresses, la passerelle et le DNS, ainsi que les lectures sans fil du réseau Wi-Fi connecté. Les octets transférés proviennent de compteurs d'interface de routage système 64 bits. Les erreurs de réception, les erreurs d’envoi et les suppressions de file d’attente de réception sont conservées séparément.

Taux de réception (B/s) = Augmentation du nombre d'octets reçus entre les échantillons ÷ Intervalle d'échantillonnage (secondes)
Débit d'envoi (B/s) = Augmentation du nombre d'octets envoyés entre les échantillons ÷ Intervalle d'échantillonnage (secondes)
Débit binaire (Mbps) = Débit d'octets × 8 ÷ 1 000 000

Les taux décrivent le volume de transfert moyen pendant l'intervalle d'échantillonnage. Mio/s utilise 1 048 576 octets par unité ; Mbps utilise un million de bits par seconde. Les compteurs d'interface et les compteurs agrégés par application couvrent différents ensembles de trafic.

La séquence d'un contrôle rapide

La vérification rapide confirme la connexion locale, sonde la passerelle, interroge le DNS, vérifie la connectivité Internet, demande HTTPS, puis vérifie les informations de sortie. La mise en œuvre actuelle autorise 8 secondes pour l’ensemble du contrôle. Chaque étape active peut utiliser jusqu'à 2 secondes du budget restant et les résultats sont mis à jour à la fin de chaque étape.

L'étape passerelle tente une connexion TCP au port de passerelle 443. Une connexion réussie et un refus de connexion explicite confirment une réponse de la passerelle ; le résultat de la connexion d'origine est également conservé. Les étapes DNS, Internet et HTTPS enregistrent leurs propres réponses pour aider à examiner chaque partie du chemin de connexion.

Analyse Wi-Fi et mesures sans fil

L’analyse sans fil utilise CoreWLAN pour obtenir le SSID, le BSSID, le canal principal, la bande, la largeur du canal et la force du signal reçu des points d'accès à proximité. Le catalogue de canaux disponible provient de l'interface sans fil actuelle. Les éléments d'information diffusés ajoutent des capacités de sécurité, des normes Wi-Fi, des codes de pays et d'autres détails. L'accès aux identifiants tels que SSID et BSSID suit les règles d'autorisation de localisation de macOS.

RSSI, bruit et rapport signal sur bruit

RSSI et bruit utilisent le dBm, une mesure de puissance logarithmique par rapport à 1 milliwatt. Une valeur RSSI plus proche de 0 signifie un signal reçu plus fort. Lorsque les deux lectures sont valides, l'application calcule le rapport signal/bruit :

SNR (dB) = RSSI (dBm) − Bruit (dBm)

Par exemple, un RSSI de −55 dBm et un bruit de −92 dBm donnent un SNR de 37 dB. Le calcul actuel accepte des lectures de −127 à −1 dBm. Si l’une des lectures est manquante, le SNR reste vide.

La surveillance des signaux sans fil dispose de deux sources d'échantillonnage. Le mode local lit périodiquement le réseau Wi-Fi connecté ; le mode à proximité analyse à plusieurs reprises les points d'accès sélectionnés. Les graphiques conservent l'heure de chaque lecture et les identités des points d'accès distinguent les différents signaux sans fil.

Utilisation des canaux de diffusion

Lorsqu'un point d'accès diffuse un élément d'information BSS Load valide, l'application convertit son champ d'utilisation du canal de 0 à 255 en pourcentage : valeur du champ × 100 ÷ 255. Cela préserve la signification de la valeur de diffusion. Le tableau de chevauchement des canaux utilise la couverture de fréquence et le modèle de puissance décrits ci-dessous.

Couverture et évaluation des canaux

Conversion des canaux en plages de fréquences

L'évaluation des canaux construit des plages de fréquences à partir de la bande, du canal principal et de la largeur du canal. Pour les canaux 1 à 13 de 2,4 GHz, la fréquence centrale en MHz est de 2 407 + 5 × numéro de canal ; le canal 14 correspond séparément à 2484 MHz. Pour 5 GHz, c'est 5000 + 5 × numéro de canal. Une plage de 20 MHz s'étend sur 10 MHz de chaque côté du centre ; les canaux plus larges combinent des blocs de sous-canaux pris en charge par le catalogue.

Les candidats sont générés par bande et largeur de canal, et chaque sous-canal d'un candidat doit exister dans le catalogue actuel. L'application évalue les combinaisons de 20 et 40 MHz sur 2,4 GHz et les combinaisons de 20, 40, 80 et 160 MHz sur 5 et 6 GHz. Les enregistrements numérisés sont fusionnés par bande et BSSID. Lorsque le BSSID est manquant, l'identifiant de l'enregistrement d'analyse sert d'identité de secours pour éviter de compter deux fois le même point d'accès.

Lorsque les informations sur la largeur ou la direction du canal sont incomplètes, l'application conserve séparément la couverture confirmée et possible. Les plages partagées par toutes les positions possibles constituent une couverture confirmée ; le reste reste une couverture possible. Chaque point d'accès est compté une fois.

Calcul de la puissance de chevauchement à partir des lectures de signaux logarithmiques

La force du signal est convertie du dBm en puissance linéaire relative, puis pondérée par la fraction de chevauchement de fréquence. Pour le point d'accès i et le candidat c :

Pᵢ = 10 ^ ((RSSIᵢ + 100) ÷ 10)
wᵢ,c = Bande passante totale superposée ÷ Bande passante totale modélisée du point d'accès
Poverlap,c = Σ (Pᵢ × wᵢ,c)

Le terme +100 fournit une référence de puissance relative partagée. Lorsque la largeur du canal est incertaine et chevauche la plage candidate, le poids est fixé de manière prudente à 1. La force du signal et la largeur de couverture y contribuent donc. Une différence RSSI de 10 dB correspond à une différence de puissance linéaire décuplée.

Classement des candidats

Lorsque le point d'accès actuel peut être identifié, il est exclu afin que le classement évalue les signaux environnants. Le classement actuel filtre les candidats DFS. Sur 2,4 GHz à 20 MHz, le groupe de canaux 1, 6 et 11 est préféré, suivi par des comparaisons des points d'accès avec RSSI manquant, de la puissance d'interférence estimée, du nombre total de points d'accès et de la séquence de canaux.

Lorsque chaque candidat a des lectures de bruit comparables, le bruit est également converti en puissance linéaire et inclus. Sinon, les candidats sont comparés uniquement en utilisant la puissance du signal qui se chevauche. Chaque sous-canal candidat utilise le milieu de ses lectures de bruit valides triées ; le candidat complet prend la plus élevée de ces valeurs de bruit.

Dans la même bande et largeur de canal, la configuration actuelle est préférée lorsqu'elle partage le groupe de priorité du meilleur candidat et le nombre de points d'accès avec RSSI manquant, et sa puissance estimée n'est pas supérieure à deux fois celle du meilleur candidat. Une différence de puissance linéaire double est d’environ 3 dB. Cela réduit les changements de classement causés par de petites différences.

Affichage des courbes de chevauchement

Les courbes de chevauchement calculent la puissance pondérée dans une fenêtre de 20 MHz autour de chaque centre de canal, puis utilisent la compression logarithmique pour la mapper sur une plage d'affichage relative de 0 à 1 :

Intensité d'affichage = min(1, max(0, log₁₀(1 + Poverlap) ÷ 7))

Cet axe vertical représente l’intensité relative du chevauchement dérivée des lectures d’analyse. Si un point d'accès superposé ne dispose pas d'un RSSI valide, cette position reste vide et la courbe est divisée. Les couvertures confirmées et possibles restent distinctes.

Découverte des périphériques du réseau local

La découverte de périphériques combine les sondes de service Bonjour, WS-Discovery, SSDP et TCP. Bonjour fournit des instances de service annoncées. WS-Discovery et SSDP ajoutent les réponses des appareils compatibles. Les sondes TCP vérifient les réponses du service aux adresses situées dans la plage d'analyse actuelle.

Les ports de sonde TCP actuels sont 80, 443, 445, 22, 631 et 9100, couvrant les services communs Web, partage de fichiers, accès à distance et impression. Les requêtes utilisent l'interface sélectionnée. Les observations conservent leur source, leur adresse et leur réponse réelle.

La découverte regroupe les observations de chaque source et organise les noms, types et services à partir des adresses des appareils et des informations de service. Les interfaces indisponibles, refus d’accès, délais dépassés et réponses sont enregistrés séparément. Annuler ou relancer une analyse isole les rappels tardifs de l’analyse précédente pour qu’ils ne modifient pas les nouveaux résultats.

Trafic des applications et attribution des connexions

Recherche d'applications à partir de la table de connexion système

Trafic des apps lit les processus, les protocoles, les points de terminaison locaux et distants, les interfaces, les états de connexion et le nombre d'octets à partir de nettop. L'application combine les informations sur l'application en cours d'exécution, les relations parent-processus et les chemins exécutables pour associer les processus d'assistance à leur application propriétaire.

La correspondance de propriété vérifie d'abord le processus lui-même, puis suit jusqu'à 16 processus parents. Si aucune correspondance n’est trouvée, il utilise le chemin du bundle d’applications contenant l’exécutable. L'identité du processus inclut également l'heure de début pour distinguer les PID réutilisés.

Calcul des variations par connexion et total par app

Les mesures successives associent les connexions selon le processus, le protocole, les adresses et ports locaux et distants, et l’interface. Les débits ne sont calculés que si les deux compteurs d’octets correspondent à la même connexion comparable, puis sont additionnés par application.

Débit de réception de la connexion = (Octets reçus actuels − Octets reçus précédents) ÷ Intervalle de temps
Débit d’envoi de la connexion = (Octets envoyés actuels − Octets envoyés précédents) ÷ Intervalle de temps
Débit de l’application = Somme des débits de connexion valides de l’application et de ses processus associés

Les nouvelles connexions établissent d’abord une base de référence. Une réinitialisation du compteur, un changement d'interface ou un écart d'échantillon supérieur à 15 secondes nécessite de nouveaux échantillons comparables. Si le système renvoie plusieurs lignes identiques qui ne peuvent pas être mises en correspondance de manière unique, l'application conserve ces lignes et laisse leurs débits vides afin que l'ambiguïté de correspondance n'apparaisse pas comme un pic de trafic.

Connexions à distance et observations ICMP

La surveillance des connexions d'applications conserve les premières et dernières heures vues, les changements d'état et les deltas de trafic, et sonde indépendamment les adresses IP distantes découvertes avec ICMP. Le trafic, l'activité de connexion et les résultats ICMP sont alignés dans le temps. La lecture de latence provient de la réponse ICMP de l'adresse IP cible.

Sondes Ping et TCP

ICMP Echo et le taux de non-réponse

Ping résout l’adresse cible et la fixe pour la sonde, puis envoie une demande d’écho IPv4 ICMP ou IPv6 ICMPv6 Echo. La surveillance continue se répète en fonction de la configuration, en enregistrant les envois réels, les réponses, les réponses manquantes et les temps d'aller-retour renvoyés.

Taux de non-réponse = Sondes sans réponse ÷ Sondes réellement envoyées × 100%

Les décomptes utilisent le nombre d'envois confirmés par la sortie du système. Les échecs de résolution, les refus d’autorisation et les demandes qui n’ont pas pu être envoyées conservent leur statut spécifique et n’entrent pas dans le dénominateur de la sonde envoyée. Les statistiques de latence utilisent des RTT de réponse valides.

Connexions des ports TCP

Après avoir résolu la cible, la surveillance du port TCP tente une connexion au port sélectionné et utilise une horloge monotone pour mesurer le temps jusqu'au succès ou à une erreur. La résolution DNS se termine en premier et la durée de connexion TCP est mesurée séparément. La réussite, le refus de connexion, le délai d'attente et les autres erreurs système sont conservés séparément pour montrer le comportement du même port de service au fil du temps.

Requêtes DNS et validation des réponses

La surveillance DNS interroge le serveur et le type d'enregistrement sélectionnés, tels que A, AAAA, CNAME, MX, TXT, NS, SOA ou PTR. La résolution du système et les requêtes explicites du serveur suivent des chemins distincts. Le routage automatique utilise la résolution du système ou dig selon la demande ; les requêtes liées à une interface sélectionnée échangent des paquets sur le port UDP 53.

Les requêtes directes génèrent un ID de transaction et créent le nom, le type et la classe IN de la question. Les réponses sont vérifiées pour la longueur du paquet, l'ID de transaction, l'indicateur de réponse, le nombre de questions, le nom, le type et la classe avant d'analyser les codes de réponse, les enregistrements de ressources et les TTL. L'analyseur de paquets développe les pointeurs de noms de domaine compressés.

NOERROR avec les enregistrements du type sélectionné, NOERROR sans ces enregistrements, NXDOMAIN, les paquets tronqués et les échecs de transport sont enregistrés séparément. Les requêtes PTR convertissent d’abord l’adresse IPv4 ou IPv6 en son nom de recherche inversée. Le timing couvre l'analyse des requêtes et des réponses, et les résultats conservent le contenu réel du serveur et de l'enregistrement.

Réponse HTTP et durée des phases

La surveillance du site Web envoie des requêtes HTTP ou HTTPS HEAD et enregistre le code d'état renvoyé, l'URL finale et la durée. Le routage automatique utilise les métriques de transaction URLSession. Avec une interface ou un chemin de résolution explicite, l'implémentation HTTP directe utilise les rapports de connexion Network.framework et les horodatages des demandes.

La durée de l'étape est la différence entre les horodatages de fin et de début. Une connexion réutilisée peut ne pas avoir de nouvelle étape DNS, TCP ou TLS ; les étapes sans horodatage valide restent vides. Les redirections conservent le timing pour chaque demande. La durée totale de la vérification est mesurée séparément car elle inclut également la résolution, les redirections, la planification et autres frais généraux réels.

HTTPS utilise la validation de confiance des certificats système et extrait le sujet, l'émetteur, la période de validité et l'empreinte SHA-256 des certificats valides. Les codes d'état HTTP décrivent la réponse du serveur ; les erreurs de transport décrivent le processus de connexion. Les deux sont stockés séparément.

Chemin réseau et sondes saut par saut

La surveillance du chemin réseau résout l’adresse cible et la fixe pour la mesure, puis envoie des sondes ICMP avec une limite de saut IPv4 TTL ou IPv6 augmentant de 1. Les routeurs intermédiaires peuvent renvoyer des réponses dont le temps est dépassé, tandis que la destination peut renvoyer une réponse d'écho. L'application utilise ces réponses pour organiser les adresses de saut et les horaires disponibles.

Chaque tour sonde actuellement jusqu'à 16 sauts. Si un saut ne répond pas, les sauts ultérieurs sont toujours vérifiés. Une réponse de destination met fin au tour. Les réponses inaccessibles et refusées par les politiques conservent leurs résultats d’origine. Si une adresse est disponible sans durée valide, l'adresse est conservée et le timing reste vide.

Débit et réactivité sous charge

Réseau actuel : Apple networkQuality

Réseau actuel exécute macOS networkQuality et analyse ses résultats structurés : débits descendant et montant, latence au repos et réactivité sous charge en RPM. RPM signifie allers-retours par minute, selon la mesure de l’outil Apple ; l’application conserve la valeur renvoyée. Les débits bruts en bits par seconde sont divisés par 1 000 000 pour l’affichage en Mbps.

Lorsqu'une interface est sélectionnée, la commande speed test inclut son argument d'interface et vérifie le nom de l'interface renvoyé dans le résultat. Si le système ne fournit que quelques métriques, ces champs sont conservés et les autres restent vides.

Moniteur : tests de débit par serveur et du système

Chaque cycle de test du moniteur mesure les débits descendant et montant auprès du serveur Cloudflare ou LibreSpeed sélectionné, puis exécute Apple networkQuality. Chaque méthode conserve sa source, son horodatage et ses résultats réels. La réception lit les données de test du serveur ; l’envoi utilise des données temporaires générées par l’application. Le débit moyen est calculé à partir des octets réellement transférés et de la durée de l’étape :

Débit (Mbps) = Octets réellement transférés × 8 ÷ Temps écoulé (secondes) ÷ 1 000 000

Les requêtes utilisent des charges utiles de test explicites, des délais d'attente et des politiques de cache, en conservant séparément la progression du transfert, le nombre d'octets cible et les octets réellement transférés. Les résultats des étapes distinguent les transferts terminés, partiels et échoués. Les enregistrements conservent le serveur et l'interface pour prendre en charge les comparaisons dans les mêmes conditions.

Surveillance continue, graphiques et statistiques

Échantillonnage indépendant sur une chronologie partagée

Le Moniteur comprend dix types d'outils : Ping, TCP, DNS, sites Web, chemins réseau, tests de vitesse, signal sans fil, trafic d'interface, trafic d'applications et connexions d'applications. Chaque tâche conserve sa propre cible, ses paramètres et ses durées d'échantillonnage. Une fenêtre temporelle partagée aligne les observations pour comparer la latence, les lectures sans fil, le trafic et les réponses des services au fil du temps.

Les sondes actives et les transferts de bande passante nécessitent des quotas de ressources distincts. Le budget par défaut actuel autorise 8 opérations de sonde simultanées et 2 transferts simultanés. Les opérations dépassant le budget attendent qu'un quota soit libéré. L'annulation attend la fin de l'opération réelle avant de libérer son quota. Des quotas s'appliquent à chaque sonde ou transfert individuel ; les tâches répétées les demandent à nouveau pour le tour suivant.

Segments de graphique et changements relatifs

Les graphiques relient les points par période d'échantillonnage et identité de segment, en séparant les interruptions et en affichant les échecs individuellement. L'interpolation aux limites de la fenêtre est utilisée uniquement pour le dessin ; les statistiques utilisent des observations réelles.

Lorsque les marqueurs de pics de latence relative sont activés, l'application prend la médiane m des 5 échantillons précédents dans le même segment. Une latence supérieure à max(3 × m, m + 5 ms) est marquée. Les marqueurs de changement de signal sans fil comparent les lectures avec la médiane récente et marquent des différences d'au moins 8 dB. Ces règles localisent les changements par rapport à une ligne de base récente.

Médiane, P95 et variation

Les statistiques utilisent les valeurs valides et finies de la fenêtre temporelle, triées par ordre croissant. Si le nombre de valeurs est impair, la médiane est la valeur centrale ; s’il est pair, c’est la moyenne des deux valeurs centrales. Sans valeur valide, les statistiques restent vides. P95 utilise la méthode du rang le plus proche :

P95 = Valeur à la position ceil(0.95 × n) dans les échantillons triés par ordre croissant
Taux de non-réponse ICMP = Sondes sans réponse ÷ Sondes réellement envoyées
Variation de latence ICMP = Somme des différences absolues de RTT entre réponses adjacentes valides ÷ Nombre de paires adjacentes valides

Les sessions ICMP de connexion à l'application accumulent des percentiles à l'aide d'un histogramme avec une précision de 0,1 ms, indépendamment de la fenêtre de conservation de l'historique brut. Les réponses valides de 0 à 2 000 ms entrent dans les compartiments d'histogramme. Les valeurs plus grandes entrent dans un compte de dépassement et contribuent au maximum ; les percentiles tombant dans la plage de dépassement restent vides. La variation de latence associe uniquement les réponses adjacentes valides dans le même segment avec un intervalle ne dépassant pas 2,5 secondes.

Enregistrements de surveillance et export de rapports

Les enregistrements de surveillance enregistrent les paramètres des tâches, les objectifs, les périodes d'échantillonnage, les résultats réels et les preuves à l'appui. Les graphiques montrent les changements au fil du temps, tandis que les rapports organisent les observations pour une lecture ou un traitement ultérieur.

HTML

Un rapport lisible avec des résumés des tâches, des résultats et des détails.

CSV

Preuves organisées en colonnes telles que l'heure, la catégorie, l'objet, la cible, la méthode, le statut, la valeur, l'unité et les détails pour l'analyse de la feuille de calcul.

JSON

Enregistrements structurés, configuration et résultats pour un traitement ultérieur.

Les longues sessions de connexion des applications utilisent des archives segmentées. L’exportation fixe d’abord la plage de lecture, puis lit les archives et les données restantes en mémoire pour conserver des limites cohérentes. Les valeurs manquantes, les échecs et les annulations conservent leur état pour l’analyse.