Documentazione tecnica NetQuickCheck

Origini dati e selezione dell'interfaccia

NetQuickCheck combina campionamento del sistema, sonde di rete attive e statistiche derivate. Il campionamento del sistema fornisce informazioni sull'interfaccia, sulla connessione wireless e sul processo. Le sonde attive catturano la risposta di un target a una richiesta. Le statistiche derivate trasformano le osservazioni in tassi, percentili e grafici.

Le attività con un'interfaccia selezionata legano le loro richieste ad essa. Le richieste TCP, UDP e HTTP dirette utilizzano l'associazione dell'interfaccia Network.framework; le sonde ICMP utilizzano l'argomento dell'interfaccia del comando di sistema. Il routing automatico consente a macOS di scegliere il percorso e le richieste HTTP automatiche seguono la sessione di sistema e le policy proxy. L'interfaccia selezionata viene salvata con i risultati per supportare i confronti tra Wi-Fi, Ethernet e altre interfacce disponibili.

Rete attuale e controlli rapidi

Letture dell'interfaccia e velocità di trasferimento

La rete corrente legge lo stato dell'interfaccia, gli indirizzi, il gateway e il DNS, insieme alle letture wireless per la rete Wi-Fi connessa. I byte trasferiti provengono dai contatori dell'interfaccia di routing del sistema a 64 bit. Gli errori di ricezione, gli errori di invio e le eliminazioni della coda di ricezione vengono conservati separatamente.

Velocità di ricezione (B/s) = Aumento dei byte ricevuti tra i campioni ÷ Intervallo di campionamento (secondi)
Velocità di invio (B/s) = Aumento dei byte inviati tra i campioni ÷ Intervallo di campionamento (secondi)
Velocità in bit (Mbps) = Velocità in byte × 8 ÷ 1.000.000

Le velocità descrivono il volume di trasferimento medio durante l'intervallo di campionamento. MiB/s utilizza 1.048.576 byte per unità; Mbps utilizza un milione di bit al secondo. I contatori dell'interfaccia e i contatori aggregati per app coprono diversi insiemi di traffico.

La sequenza di un controllo rapido

Il controllo rapido conferma la connessione locale, analizza il gateway, interroga il DNS, controlla la connettività Internet, richiede HTTPS e quindi controlla le informazioni in uscita. L'attuale implementazione consente 8 secondi per l'intero controllo. Ciascun passaggio attivo può utilizzare fino a 2 secondi del budget rimanente e i risultati vengono aggiornati al termine di ciascun passaggio.

La fase del gateway tenta una connessione TCP alla porta gateway 443. Sia una connessione riuscita che un rifiuto esplicito della connessione confermano una risposta dal gateway; viene mantenuto anche il risultato della connessione originale. I passaggi DNS, Internet e HTTPS registrano le proprie risposte per aiutare a esaminare ogni parte del percorso di connessione.

Scansione Wi-Fi e metriche wireless

La scansione wireless utilizza CoreWLAN per ottenere SSID, BSSID, canale primario, banda, larghezza del canale e potenza del segnale ricevuto dei punti di accesso vicini. Il catalogo dei canali disponibili proviene dall'attuale interfaccia wireless. Gli elementi delle informazioni trasmesse aggiungono funzionalità di sicurezza, standard Wi-Fi, codici paese e altri dettagli. L'accesso a identificatori come SSID e BSSID segue le regole di autorizzazione alla posizione di macOS.

RSSI, rumore e rapporto segnale-rumore

RSSI e rumore utilizzano dBm, una misura di potenza logaritmica relativa a 1 milliwatt. Un valore RSSI più vicino a 0 indica un segnale ricevuto più forte. Quando entrambe le letture sono valide, l'app calcola il rapporto segnale-rumore:

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

Ad esempio, RSSI di −55 dBm e rumore di −92 dBm danno un SNR di 37 dB. Il calcolo attuale accetta letture da −127 a −1 dBm. Se manca una delle due letture, SNR rimane vuoto.

Il monitoraggio del segnale wireless ha due fonti di campionamento. La modalità locale legge periodicamente la rete Wi-Fi connessa; la modalità vicina esegue ripetutamente la scansione dei punti di accesso selezionati. I grafici conservano l'ora di ogni lettura e le identità dei punti di accesso distinguono diversi segnali wireless.

Utilizzo del canale di trasmissione

Quando un punto di accesso trasmette un elemento informativo BSS Load valido, l'app converte il campo di utilizzo del canale da 0 a 255 in una percentuale: valore del campo × 100 ÷ 255. Ciò preserva il significato del valore di trasmissione. Il grafico di sovrapposizione dei canali utilizza la copertura di frequenza e il modello di potenza descritti di seguito.

Copertura e valutazione del canale

Conversione dei canali in gamme di frequenza

La valutazione del canale crea gamme di frequenza dalla banda, dal canale primario e dalla larghezza del canale. Per i canali da 1 a 13 a 2,4 GHz, la frequenza centrale in MHz è 2407 + 5 × numero del canale; il canale 14 viene mappato separatamente su 2484 MHz. Per 5 GHz, è 5000 + 5 × numero di canale. Una gamma di 20 MHz si estende per 10 MHz su entrambi i lati del centro; i canali più ampi combinano blocchi di sottocanali supportati dal catalogo.

I candidati vengono generati in base alla banda di frequenza e alla larghezza del canale e ogni sottocanale in un candidato deve esistere nel catalogo corrente. L'app valuta le combinazioni da 20 e 40 MHz su 2,4 GHz e le combinazioni da 20, 40, 80 e 160 MHz su 5 e 6 GHz. I record di scansione vengono uniti per banda e BSSID. Quando manca il BSSID, l'identificatore del record di scansione funge da identità di fallback per evitare di contare due volte lo stesso punto di accesso.

Quando le informazioni sulla larghezza o sulla direzione del canale sono incomplete, l'app conserva separatamente la copertura confermata e possibile. Sono confermati i range condivisi da tutte le possibili posizioni; il resto resta una copertura possibile. Ogni punto di accesso viene conteggiato una volta.

Calcolo della potenza di sovrapposizione dalle letture del segnale logaritmico

L'intensità del segnale viene convertita da dBm in potenza lineare relativa, quindi ponderata in base alla frazione di sovrapposizione della frequenza. Per il punto di accesso i e il candidato c:

Pᵢ = 10 ^ ((RSSIᵢ + 100) ÷ 10)
wᵢ,c = larghezza di banda sovrapposta totale ÷ larghezza di banda totale del punto di accesso modellato
Poverlap,c = Σ (Pᵢ × wᵢ,c)

Il termine +100 fornisce un riferimento di potenza relativa condiviso. Quando la larghezza del canale è incerta e si sovrappone all'intervallo candidato, il peso viene impostato in modo conservativo su 1. Pertanto contribuiscono sia la potenza del segnale che la larghezza di copertura. Una differenza RSSI di 10 dB corrisponde a una differenza di potenza lineare dieci volte superiore.

Classifica dei candidati

Quando il punto di accesso corrente può essere identificato, viene escluso in modo che la classificazione valuti i segnali circostanti. La classifica attuale filtra i candidati DFS. Su 2,4 GHz a 20 MHz viene preferito il gruppo di canali 1, 6 e 11, seguito dal confronto dei punti di accesso con RSSI mancante, potenza di interferenza stimata, conteggio totale dei punti di accesso e sequenza dei canali.

Quando ogni candidato ha letture di rumore comparabili, anche il rumore viene convertito in potenza lineare e incluso. Altrimenti, i candidati vengono confrontati utilizzando solo la potenza del segnale sovrapposto. Ciascun sottocanale candidato utilizza il valore centrale delle letture di rumore valide ordinate; il candidato completo prende il più alto tra questi valori di rumore.

All'interno della stessa banda e larghezza di canale, la configurazione attuale è preferita quando condivide il gruppo di priorità e il numero di punti di accesso con RSSI mancante del miglior candidato e la sua potenza stimata non è superiore al doppio di quella del miglior candidato. Una doppia differenza di potenza lineare è di circa 3 dB. Ciò riduce i cambiamenti di classificazione causati da piccole differenze.

Visualizzazione delle curve di sovrapposizione

Le curve di sovrapposizione calcolano la potenza ponderata in una finestra di 20 MHz attorno al centro di ciascun canale, quindi utilizzano la compressione logaritmica per mapparla su un intervallo di visualizzazione relativo di 0–1:

Intensità di visualizzazione = min(1, max(0, log₁₀(1 + Poverlap) ÷ 7))

Questo asse verticale rappresenta l'intensità relativa della sovrapposizione derivata dalle letture della scansione. Se un punto di accesso sovrapposto non dispone di RSSI valido, quella posizione rimane vuota e la curva viene divisa. Le coperture confermate ed eventuali restano separate.

Rilevamento dei dispositivi di rete locale

Il rilevamento dei dispositivi combina le sonde di servizio Bonjour, WS-Discovery, SSDP e TCP. Bonjour fornisce istanze di servizi pubblicizzate. WS-Discovery e SSDP aggiungono risposte da dispositivi compatibili. Le sonde TCP controllano le risposte del servizio agli indirizzi all'interno dell'intervallo di scansione corrente.

Le attuali porte sonda TCP sono 80, 443, 445, 22, 631 e 9100, e coprono servizi web comuni, condivisione di file, accesso remoto e servizi di stampa. Le richieste utilizzano l'interfaccia selezionata. Le osservazioni conservano la loro fonte, indirizzo e risposta effettiva.

Il rilevamento unisce le osservazioni di ciascuna fonte in batch e organizza nomi, tipi e servizi in base agli indirizzi dei dispositivi e alle risposte dei servizi. Interfacce non disponibili, accessi negati, timeout e risposte vengono registrati separatamente. Annullare o riavviare una scansione isola i callback tardivi della scansione precedente, impedendo che alterino i nuovi risultati.

Traffico delle app e attribuzione delle connessioni

Ricerca di app dalla tabella delle connessioni di sistema

Traffico app legge processi, protocolli, endpoint locali e remoti, interfacce, stati di connessione e conteggi di byte dal nettop. L'app combina informazioni sull'applicazione in esecuzione, relazioni padre del processo e percorsi eseguibili per associare i processi di supporto all'app proprietaria.

Per identificare l’app associata, viene controllato prima il processo stesso e poi la catena dei processi padre, fino a 16 livelli. In assenza di corrispondenze, viene usato il percorso del pacchetto dell’app che contiene l’eseguibile. L’identità del processo comprende anche l’ora di avvio, per distinguere i PID riutilizzati.

Calcolo delle variazioni per connessione e aggregazione per app

I campioni consecutivi associano le connessioni in base a processo, protocollo, indirizzi e porte locali e remoti e interfaccia. Le velocità vengono calcolate solo se entrambi i contatori di byte appartengono alla stessa connessione confrontabile, poi sommate per app.

Velocità di ricezione della connessione = (Byte ricevuti attuali − Byte ricevuti precedenti) ÷ Intervallo di tempo
Velocità di invio della connessione = (Byte inviati attuali − Byte inviati precedenti) ÷ Intervallo di tempo
Velocità dell’app = Somma delle velocità valide delle connessioni dell’app e dei processi associati

Le nuove connessioni stabiliscono innanzitutto una linea di base. Un ripristino del contatore, una modifica dell'interfaccia o un gap di campione superiore a 15 secondi richiedono nuovi campioni comparabili. Se il sistema restituisce più righe identiche che non possono essere abbinate in modo univoco, l'app conserva tali righe e lascia vuote le relative velocità in modo che l'ambiguità di corrispondenza non venga visualizzata come un picco di traffico.

Connessioni remote e osservazioni ICMP

Il monitoraggio della connessione dell'app conserva l’ora della prima e dell’ultima osservazione, i cambiamenti di stato e i delta del traffico e analizza in modo indipendente gli IP remoti rilevati con ICMP. Il traffico, l'attività di connessione e i risultati ICMP sono allineati in base al tempo. La lettura della latenza proviene dalla risposta ICMP dell'IP di destinazione.

Sonde Ping e TCP

ICMP Echo e rapporto di mancata risposta

Il ping risolve e fissa l'indirizzo di destinazione per la sonda, quindi invia una richiesta IPv4 ICMP Echo o IPv6 ICMPv6 Echo. Il monitoraggio continuo si ripete in base alla configurazione, registrando gli invii effettivi, le risposte, le risposte mancanti e i tempi di andata e ritorno restituiti.

Percentuale senza risposta = Sonde senza risposta ÷ Sonde effettivamente inviate × 100%

I conteggi utilizzano il numero di invii confermati dall'output del sistema. Gli errori di risoluzione, i dinieghi di autorizzazione e le richieste che non è stato possibile inviare mantengono il loro stato specifico e non entrano nel denominatore della sonda inviata. Le statistiche sulla latenza utilizzano RTT di risposta validi.

Connessioni della porta TCP

Dopo aver risolto il target, il monitoraggio della porta TCP tenta una connessione alla porta selezionata e utilizza un orologio monotono per misurare il tempo fino al successo o all'errore. La risoluzione DNS termina per prima e i tempi di connessione TCP vengono misurati separatamente. Il successo, il rifiuto della connessione, il timeout e altri errori di sistema vengono conservati separatamente per mostrare come si comporta la stessa porta di servizio nel tempo.

Query DNS e convalida della risposta

Il monitoraggio DNS interroga il server selezionato e il tipo di record, come A, AAAA, CNAME, MX, TXT, NS, SOA o PTR. La risoluzione del sistema e le query esplicite del server seguono percorsi separati. Il routing automatico utilizza la risoluzione del sistema o dig in base alla richiesta; le query legate all'interfaccia selezionata scambiano pacchetti sulla porta UDP 53.

Le query dirette generano un ID di transazione e creano il nome, il tipo e la classe IN della domanda. Le risposte vengono controllate per lunghezza del pacchetto, ID transazione, flag di risposta, conteggio domande, nome, tipo e classe prima di analizzare codici di risposta, record di risorse e TTL. Il parser di pacchetti espande i puntatori dei nomi di dominio compressi.

NOERROR con record del tipo selezionato, NOERROR senza tali record, NXDOMAIN, pacchetti troncati e errori di trasporto vengono registrati separatamente. Le query PTR convertono innanzitutto l'indirizzo IPv4 o IPv6 nel nome di ricerca inversa. La tempistica copre l'analisi della query e della risposta e i risultati mantengono il server effettivo e il contenuto del record.

Risposta HTTP e tempistica della fase

Il monitoraggio del sito web invia richieste HTTP o HTTPS HEAD e registra il codice di stato restituito, l'URL finale e la durata. Il routing automatico utilizza le metriche delle transazioni URLSession. Con un'interfaccia o un percorso di risoluzione esplicito, l'implementazione HTTP diretta utilizza i report di connessione Network.framework e i timestamp delle richieste.

La durata della fase è la differenza tra i timestamp di fine e di inizio. Una connessione riutilizzata potrebbe non avere una nuova fase DNS, TCP o TLS; le fasi senza timestamp validi rimangono vuote. I reindirizzamenti mantengono i tempi per ogni richiesta. La durata totale del controllo viene misurata separatamente perché include anche la risoluzione, i reindirizzamenti, la pianificazione e altri costi generali effettivi.

HTTPS utilizza la convalida dell'attendibilità del certificato di sistema ed estrae il soggetto, l'emittente, il periodo di validità e l'impronta digitale SHA-256 dai certificati validi. I codici di stato HTTP descrivono la risposta del server; gli errori di trasporto descrivono il processo di connessione. Entrambi sono archiviati separatamente.

Percorso di rete e sonde hop-by-hop

Il monitoraggio del percorso di rete risolve l’indirizzo di destinazione e lo mantiene fisso durante la misura, quindi invia sonde ICMP con IPv4 TTL o IPv6 Hop Limit in aumento da 1. I router intermedi possono restituire risposte per tempo scaduto, mentre la destinazione può restituire una risposta Echo. L'app utilizza queste risposte per organizzare gli indirizzi hop e i tempi di risposta disponibili.

Ogni round attualmente analizza fino a 16 hop. Se un hop non risponde, vengono comunque controllati gli hop successivi. Una risposta di destinazione termina il round. Le risposte irraggiungibili e negate dalle politiche mantengono i loro risultati originali. Se un indirizzo è disponibile senza una durata valida, l'indirizzo viene mantenuto e il tempo rimane vuoto.

Throughput e reattività sotto carico

Rete attuale: Apple networkQuality

Rete attuale esegue macOS networkQuality e ne analizza i risultati strutturati, inclusi download, caricamento, latenza di inattività e reattività sotto carico in RPM. RPM significa scambi di andata e ritorno al minuto, misurati dallo strumento Apple; l'app conserva il valore restituito. Le velocità in bit di download e caricamento non elaborate vengono divise per 1.000.000 per la visualizzazione in Mbps.

Quando viene selezionata un'interfaccia, il comando di test della velocità include il relativo argomento interfaccia e controlla il nome dell'interfaccia restituito nel risultato. Se il sistema fornisce solo alcune metriche, tali campi vengono mantenuti e gli altri rimangono vuoti.

Monitor: test di velocità del server e del sistema

Ogni ciclo di test di velocità di Monitor esegue test di download e caricamento sull'endpoint Cloudflare o LibreSpeed selezionato, quindi esegue Apple networkQuality. I due metodi mantengono la propria fonte, tempo e risultati effettivi. I download degli endpoint leggono i payload di test; i caricamenti utilizzano dati temporanei generati dall'app. Il throughput medio viene calcolato dai byte effettivamente trasferiti e dal tempo trascorso per quella fase:

Throughput (Mbps) = Byte effettivamente trasferiti × 8 ÷ Tempo trascorso (secondi) ÷ 1.000.000

Le richieste utilizzano payload di test espliciti, timeout e policy di cache, conservando separatamente l'avanzamento del trasferimento, il conteggio dei byte di destinazione e i byte effettivamente trasferiti. I risultati delle fasi distinguono i trasferimenti completati, parziali e falliti. I record conservano il server e l'interfaccia per supportare i confronti nelle stesse condizioni.

Monitoraggio continuo, grafici e statistiche

Campionamento indipendente su una sequenza temporale condivisa

Monitor include dieci tipi di strumenti: ping, TCP, DNS, siti Web, percorsi di rete, test di velocità, segnale wireless, traffico di interfaccia, traffico di app e connessioni di app. Ogni attività conserva il proprio target, parametri e tempi di campionamento. Una finestra temporale condivisa allinea le osservazioni per confrontare la latenza, le letture wireless, il traffico e le risposte del servizio nel tempo.

Le sonde attive e i trasferimenti di larghezza di banda richiedono quote di risorse separate. L'attuale budget predefinito consente 8 operazioni di rilevamento simultanee e 2 trasferimenti simultanei. Le operazioni oltre il budget attendono fino al rilascio di una quota. L'annullamento attende la conclusione dell'operazione effettiva prima di rilasciare la propria quota. Le quote si applicano a ogni singola sonda o trasferimento; le attività ripetute le richiedono nuovamente per il turno successivo.

Segmenti dei grafici e variazioni relative

I grafici collegano i punti in base al tempo di campionamento e all'identità del segmento, mantenendo separate le interruzioni e mostrando i guasti individualmente. L'interpolazione ai limiti della finestra viene utilizzata solo per il disegno; le statistiche utilizzano osservazioni reali.

Quando i marcatori di picco di latenza relativa sono abilitati, l'app prende la mediana m dei 5 campioni precedenti nello stesso segmento. Viene contrassegnata una latenza maggiore di max(3 × m, m + 5 ms). I marcatori di variazione del segnale wireless confrontano le letture con la mediana recente e segnalano differenze di almeno 8 dB. Queste regole individuano le modifiche rispetto a una linea di base recente.

Mediana, P95 e variazione

Le statistiche usano i valori validi e finiti della finestra temporale, ordinati in modo crescente. Se il numero di valori è dispari, la mediana è il valore centrale; se è pari, è la media dei due valori centrali. Senza valori validi, le statistiche restano vuote. P95 usa il metodo del rango più vicino:

P95 = Valore alla posizione ceil(0.95 × n) in campioni ascendenti
Rapporto ICMP senza risposta = Sonde senza risposta ÷ Sonde effettivamente inviate
Variazione della latenza ICMP = Somma delle differenze RTT assolute tra risposte adiacenti valide ÷ Numero di coppie adiacenti valide

Le sessioni ICMP di connessione dell'app accumulano percentili utilizzando un istogramma con precisione di 0,1 ms, indipendentemente dalla finestra di conservazione della cronologia non elaborata. Le risposte valide da 0 a 2000 ms entrano negli intervalli dell'istogramma. Valori più grandi entrano in un conteggio di overflow e contribuiscono al massimo; i percentili che rientrano nell'intervallo di overflow rimangono vuoti. La variazione di latenza accoppia solo risposte adiacenti valide nello stesso segmento con un intervallo non superiore a 2,5 secondi.

Registrazioni di monitoraggio ed esportazione dei report

I record di monitoraggio salvano i parametri delle attività, gli obiettivi, i tempi di campionamento, i risultati effettivi e le prove di supporto. I grafici mostrano i cambiamenti nel tempo, mentre i report organizzano le osservazioni per la lettura o l'ulteriore elaborazione.

HTML

Un rapporto leggibile con riepiloghi delle attività, risultati e dettagli.

CSV

Prove organizzate in colonne come tempo, categoria, oggetto, destinazione, metodo, stato, valore, unità e dettagli per l'analisi del foglio di calcolo.

JSON

Record strutturati, configurazione e risultati per ulteriori elaborazioni.

Le sessioni lunghe di connessione dell'app utilizzano archivi segmentati. L'esportazione fissa innanzitutto l'intervallo di lettura dell'archivio, quindi trasmette i dati archiviati e la coda corrente in memoria in modo che un'esportazione utilizzi limiti di dati coerenti. I valori mancanti, gli errori e le cancellazioni mantengono i propri stati per supportare un'interpretazione coerente durante la revisione.