Technische documentatie van NetQuickCheck

Gegevensbronnen en interfaceselectie

NetQuickCheck combineert systeembemonstering, actieve netwerkonderzoeken en afgeleide statistieken. Systeembemonstering biedt interface-, draadloze en procesverbindingsinformatie. Actieve sondes registreren de reactie van een doelwit op een verzoek. Afgeleide statistieken zetten observaties om in overdrachtssnelheden, percentielen en grafieken.

Taken met een geselecteerde interface binden hun verzoeken daaraan. TCP-, UDP- en directe HTTP-verzoeken maken gebruik van Network.framework-interfacebinding; ICMP-sondes gebruiken het interface-argument van de systeemopdracht. Dankzij automatische routering kan macOS het pad kiezen, en automatische HTTP-verzoeken volgen het systeemsessie- en proxybeleid. De geselecteerde interface wordt samen met de resultaten opgeslagen om vergelijkingen tussen Wi-Fi, Ethernet en andere beschikbare interfaces te ondersteunen.

Huidig netwerk en snelle controles

Interface-metingen en overdrachtssnelheden

Het huidige netwerk leest de interfacestatus, adressen, gateway en DNS, samen met draadloze metingen voor het verbonden Wi-Fi-netwerk. Overgedragen bytes zijn afkomstig van 64-bits systeemrouteringsinterfacetellers. Ontvangstfouten, verzendfouten en verliezen in de ontvangstwachtrij worden afzonderlijk bewaard.

Ontvangstsnelheid (B/s) = Toename van ontvangen bytes tussen samples ÷ Sample-interval (seconden)
Verzendsnelheid (B/s) = Toename van verzonden bytes tussen samples ÷ Sample-interval (seconden)
Bitsnelheid (Mbps) = Bytesnelheid × 8 ÷ 1.000.000

Overdrachtssnelheden zijn gemiddelden over het meetinterval. 1 MiB/s is 1.048.576 bytes per seconde; 1 Mbps is één miljoen bits per seconde. Interfacetellers en tellers per app meten verschillende verkeersstromen.

De volgorde van een snelle controle

Snelle controle bevestigt de lokale verbinding, onderzoekt de gateway, vraagt DNS op, controleert de internetverbinding, vraagt HTTPS aan en controleert vervolgens de uitgaande informatie. De huidige implementatie staat 8 seconden toe voor de hele controle. Elke actieve stap kan maximaal 2 seconden van het resterende budget in beslag nemen, en de resultaten worden bijgewerkt zodra elke stap is voltooid.

De gatewaystap probeert een TCP-verbinding tot stand te brengen met gatewaypoort 443. Zowel een succesvolle verbinding als een expliciete verbindingsweigering bevestigen een reactie van de gateway; het oorspronkelijke verbindingsresultaat blijft ook behouden. DNS-, internet- en HTTPS-stappen registreren hun eigen antwoorden om elk deel van het verbindingspad te helpen onderzoeken.

Wi-Fi-scannen en draadloze statistieken

Draadloos scannen maakt gebruik van CoreWLAN om de SSID, BSSID, het primaire kanaal, de band, de kanaalbreedte en de ontvangen signaalsterkte van toegangspunten in de buurt te verkrijgen. De beschikbare zendercatalogus is afkomstig van de huidige draadloze interface. Uitgezonden informatie-elementen voegen beveiligingsmogelijkheden, Wi-Fi-standaarden, landcodes en andere details toe. Toegang tot ID's zoals SSID en BSSID volgt de macOS-locatietoestemmingsregels.

RSSI, ruis en signaal-ruisverhouding

RSSI en ruis gebruiken dBm, een logaritmische vermogensmaatstaf ten opzichte van 1 milliwatt. Een RSSI-waarde dichter bij 0 betekent een sterker ontvangen signaal. Wanneer beide metingen geldig zijn, berekent de app de signaal-ruisverhouding:

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

RSSI van −55 dBm en ruis van −92 dBm geven bijvoorbeeld een SNR van 37 dB. De huidige berekening accepteert metingen van −127 tot −1 dBm. Als een van beide metingen ontbreekt, blijft SNR leeg.

Draadloze signaalmonitoring heeft twee bemonsteringsbronnen. De lokale modus leest periodiek het verbonden Wi-Fi-netwerk; de nabijgelegen modus scant herhaaldelijk geselecteerde toegangspunten. Grafieken houden de tijd van elke meting bij, en toegangspuntidentiteiten onderscheiden verschillende draadloze signalen.

Gemeld kanaalgebruik

Wanneer een toegangspunt een geldig BSS Load-informatie-element uitzendt, converteert de app het kanaalgebruiksveld van 0-255 naar een percentage: veldwaarde × 100 ÷ 255. Hierdoor blijft de betekenis van de uitzendwaarde behouden. Het kanaaloverlappingsdiagram maakt gebruik van het hieronder beschreven frequentiedekkings- en vermogensmodel.

Kanaaldekking en evaluatie

Kanalen converteren naar frequentiebereiken

Kanaalevaluatie bouwt frequentiebereiken op van band, primair kanaal en kanaalbreedte. Voor 2,4 GHz-kanalen 1–13 is de middenfrequentie in MHz 2407 + 5 × kanaalnummer; kanaal 14 wordt afzonderlijk toegewezen aan 2484 MHz. Voor 5 GHz is dit 5000 + 5 × kanaalnummer. Een bereik van 20 MHz strekt zich uit over 10 MHz naar beide zijden van het midden; bredere kanalen combineren subkanaalblokken die door de catalogus worden ondersteund.

Kandidaten worden gegenereerd op basis van band- en kanaalbreedte, en elk subkanaal in een kandidaat moet in de huidige catalogus voorkomen. De app evalueert combinaties van 20 en 40 MHz op 2,4 GHz, en combinaties van 20, 40, 80 en 160 MHz op 5 en 6 GHz. Scanrecords worden samengevoegd per band en BSSID. Wanneer BSSID ontbreekt, dient de scanrecord-ID als reserve-identiteit om te voorkomen dat hetzelfde toegangspunt twee keer wordt geteld.

Wanneer informatie over de kanaalbreedte of -richting onvolledig is, bewaart de app bevestigde en mogelijke dekking afzonderlijk. Bereiken die door alle mogelijke posities worden gedeeld, vormen een bevestigde dekking; de rest blijft mogelijke dekking. Elk toegangspunt wordt één keer geteld.

Berekening van het overlapvermogen op basis van logaritmische signaalmetingen

De signaalsterkte wordt omgezet van dBm naar relatief lineair vermogen en vervolgens gewogen op basis van de fractie van de frequentie-overlapping. Voor toegangspunt i en kandidaat c:

Pᵢ = 10 ^ ((RSSIᵢ + 100) ÷ 10)
wᵢ,c = Totale overlappende bandbreedte ÷ Totale gemodelleerde bandbreedte van het toegangspunt
Poverlap,c = Σ (Pᵢ × wᵢ,c)

De +100-term biedt een gedeelde relatieve vermogensreferentie. Wanneer de kanaalbreedte onzeker is en het kandidaatbereik overlapt, wordt het gewicht conservatief ingesteld op 1. Zowel de signaalsterkte als de dekkingsbreedte dragen daarom bij. Een RSSI-verschil van 10 dB komt overeen met een tienvoudig lineair vermogensverschil.

Kandidaten rangschikken

Wanneer het huidige toegangspunt kan worden geïdentificeerd, wordt dit uitgesloten, zodat de ranking de omliggende signalen evalueert. De huidige ranglijst filtert DFS-kandidaten uit. Op 2,4 GHz bij 20 MHz wordt de voorkeur gegeven aan de 1-, 6- en 11-kanaalsgroep, gevolgd door vergelijkingen van toegangspunten met ontbrekende RSSI, geschat interferentievermogen, totaal aantal toegangspunten en kanaalvolgorde.

Wanneer elke kandidaat vergelijkbare ruismetingen heeft, wordt de ruis ook omgezet naar lineair vermogen en meegenomen. Anders worden de kandidaten vergeleken met alleen overlappend signaalvermogen. Elk kandidaat-subkanaal gebruikt het midden van zijn gesorteerde geldige ruismetingen; de volledige kandidaat neemt de hoogste van deze ruiswaarden.

Binnen dezelfde band- en kanaalbreedte heeft de huidige configuratie de voorkeur als deze de prioriteitsgroep en het aantal toegangspunten van de beste kandidaat deelt met ontbrekende RSSI, en het geschatte vermogen niet meer dan tweemaal dat van de beste kandidaat is. Een tweevoudig lineair vermogensverschil is ongeveer 3 dB. Dit vermindert rangschikkingsveranderingen veroorzaakt door kleine verschillen.

Overlappende curven weergeven

Overlapcurven berekenen het gewogen vermogen in een 20 MHz-venster rond elk kanaalcentrum en gebruiken vervolgens logaritmische compressie om dit in kaart te brengen in een relatief weergavebereik van 0–1:

Weergave-intensiteit = min(1, max(0, log₁₀(1 + Poverlap) ÷ 7))

Deze verticale as vertegenwoordigt de relatieve overlapintensiteit afgeleid van scanmetingen. Als een overlappend toegangspunt geen geldige RSSI heeft, blijft die positie leeg en wordt de curve gesplitst. Bevestigde en mogelijke dekking blijven gescheiden.

Apparaten in het lokale netwerk ontdekken

Apparaatdetectie combineert Bonjour-, WS-Discovery-, SSDP- en TCP-servicetests. Bonjour levert geadverteerde service-exemplaren. WS-Discovery en SSDP voegen reacties toe van compatibele apparaten. TCP-sondes controleren servicereacties op adressen binnen het huidige scanbereik.

De huidige TCP-testpoorten zijn 80, 443, 445, 22, 631 en 9100, voor gangbare webdiensten, bestandsdeling, externe toegang en afdrukken. Verzoeken gebruiken de geselecteerde interface. Waarnemingen behouden hun bron, adres en daadwerkelijke antwoord.

Apparaatdetectie voegt waarnemingen van elke bron in batches samen en ordent namen, typen en diensten op basis van apparaatadressen en servicegegevens. Niet-beschikbare interfaces, geweigerde toegang, time-outs en serviceantwoorden worden apart geregistreerd. Bij annuleren of herstarten van een scan worden vertraagde callbacks van de vorige scan geïsoleerd, zodat ze de nieuwe resultaten niet beïnvloeden.

App-verkeer en toewijzing van verbindingen

Apps zoeken uit de systeemverbindingstabel

App-verkeer leest processen, protocollen, lokale en externe eindpunten, interfaces, verbindingsstatussen en bytetellingen van nettop. De app combineert actieve applicatie-informatie, procesouderrelaties en uitvoerbare paden om helperprocessen te koppelen aan de app die eigenaar is.

De toewijzing controleert eerst het proces zelf en volgt daarna de keten van bovenliggende processen, tot 16 niveaus. Zonder overeenkomst wordt het pad gebruikt van de appbundel die het uitvoerbare bestand bevat. De starttijd maakt deel uit van de procesidentiteit om hergebruikte PID’s te onderscheiden.

Verbindingswijzigingen berekenen en per app optellen

Opeenvolgende metingen koppelen verbindingen op basis van proces, protocol, lokale en externe adressen en poorten en interface. Overdrachtssnelheden worden alleen berekend als beide bytetellers bij dezelfde vergelijkbare verbinding horen en worden daarna per app opgeteld.

Downloadsnelheid verbinding = (Huidige ontvangen bytes − Vorige ontvangen bytes) ÷ Tijdsverschil
Uploadsnelheid verbinding = (Huidige verzonden bytes − Vorige verzonden bytes) ÷ Tijdsverschil
App-snelheid = Som van de geldige verbindingssnelheden van de app en de bijbehorende processen

Nieuwe verbindingen leggen eerst een referentiewaarde vast. Na een tellerreset, een interfacewijziging of een meetinterval van meer dan 15 seconden zijn nieuwe, vergelijkbare metingen nodig. Als het systeem meerdere identieke rijen teruggeeft die niet eenduidig gekoppeld kunnen worden, blijven de rijen behouden maar hun snelheden leeg. Zo wordt een onduidelijke koppeling niet als een verkeerspiek weergegeven.

Verbindingen op afstand en ICMP-waarnemingen

App-verbindingsmonitoring houdt de eerste en laatst geziene tijden, statuswijzigingen en verkeersdelta's bij, en onderzoekt onafhankelijk ontdekte externe IP's met ICMP. Verkeer, verbindingsactiviteit en ICMP-resultaten worden op tijd op elkaar afgestemd. De latentielezing is afkomstig van het ICMP-antwoord van het doel-IP.

Ping- en TCP-tests

ICMP Echo en de no-responsratio

Ping zoekt het doeladres op en houdt het vast voor de meting, en verzendt vervolgens een IPv4 ICMP Echo- of IPv6 ICMPv6 Echo-verzoek. Continue monitoring herhaalt zich volgens de configuratie, waarbij daadwerkelijke verzendingen, antwoorden, ontbrekende antwoorden en geretourneerde retourtijden worden geregistreerd.

Geen-responsratio = Probes zonder antwoord ÷ Probes daadwerkelijk verzonden × 100%

Tellingen gebruiken het aantal verzendingen dat wordt bevestigd door de systeemuitvoer. Oplossingsfouten, weigeringen van toestemming en verzoeken die niet konden worden verzonden, behouden hun specifieke status en komen niet in de noemer van de verzonden probe terecht. Latentiestatistieken gebruiken geldige antwoord-RTT's.

TCP-poortverbindingen

Nadat het doel is opgelost, probeert TCP-poortmonitoring een verbinding met de geselecteerde poort tot stand te brengen en gebruikt een monotone klok om de tijd tot succes of een fout te meten. De DNS-resolutie wordt als eerste voltooid en de timing van de TCP-verbinding wordt afzonderlijk gemeten. Succes, verbindingsweigering, time-out en andere systeemfouten worden afzonderlijk bewaard om te laten zien hoe dezelfde servicepoort zich in de loop van de tijd gedraagt.

DNS-query's en antwoordvalidatie

DNS-monitoring vraagt het geselecteerde server- en recordtype op, zoals A, AAAA, CNAME, MX, TXT, NS, SOA of PTR. Systeemresolutie en expliciete serverquery's volgen afzonderlijke paden. Automatische routering maakt gebruik van systeemresolutie of dig op basis van het verzoek; queries gebonden aan een geselecteerde interface wisselen pakketten uit via UDP-poort 53.

Directe zoekopdrachten genereren een transactie-ID en bouwen de vraagnaam, het type en de IN-klasse op. Antwoorden worden gecontroleerd op pakketlengte, transactie-ID, antwoordvlag, aantal vragen, naam, type en klasse voordat antwoordcodes, bronrecords en TTL's worden geparseerd. De pakketparser breidt gecomprimeerde domeinnaamaanwijzers uit.

NOERROR met records van het geselecteerde type, NOERROR zonder deze records, NXDOMAIN, afgekapte pakketten en transportfouten worden afzonderlijk geregistreerd. PTR-query's converteren eerst het IPv4- of IPv6-adres naar de reverse lookup-naam. De timing omvat het parseren van query's en antwoorden, en de resultaten behouden de daadwerkelijke server- en recordinhoud.

HTTP-reactie en fasetiming

Websitemonitoring verzendt HTTP- of HTTPS HEAD-verzoeken en registreert de geretourneerde statuscode, uiteindelijke URL en duur. Automatische routering maakt gebruik van URLSession-transactiestatistieken. Met een expliciet interface- of resolutiepad maakt de directe HTTP-implementatie gebruik van Network.framework-verbindingsrapporten en tijdstempels van aanvragen.

De faseduur is het verschil tussen de eind- en starttijdstempels. Bij een hergebruikte verbinding kan een nieuwe DNS-, TCP- of TLS-fase ontbreken; fasen zonder geldige tijdstempels blijven leeg. Omleidingen behouden de timing voor elk verzoek. De totale controleduur wordt afzonderlijk gemeten, omdat deze ook de resolutie, omleidingen, planning en andere feitelijke overhead omvat.

HTTPS maakt gebruik van systeemcertificaatvertrouwensvalidatie en haalt het onderwerp, de uitgever, de geldigheidsperiode en de SHA-256-vingerafdruk uit geldige certificaten. HTTP-statuscodes beschrijven de reactie van de server; transportfouten beschrijven het verbindingsproces. Beide worden apart opgeslagen.

Netwerkpad en hop-by-hop-sondes

Netwerkpadmonitoring zoekt het doeladres op en houdt het vast voor de meting, en verzendt vervolgens ICMP-sondes waarbij de IPv4 TTL- of IPv6-hoplimiet toeneemt vanaf 1. Tussenliggende routers kunnen antwoorden retourneren die de tijd overschrijden, terwijl de bestemming een echo-antwoord kan retourneren. De app gebruikt deze reacties om hopadressen en beschikbare tijden te organiseren.

Elke ronde onderzoekt momenteel maximaal 16 hops. Als een hop niet reageert, worden latere hops nog steeds gecontroleerd. Een bestemmingsantwoord beëindigt de ronde. Onbereikbare en door het beleid geweigerde reacties behouden hun oorspronkelijke resultaten. Als een adres zonder geldige duur beschikbaar is, wordt het adres behouden en blijft de timing leeg.

Doorvoer en reactievermogen onder belasting

Huidig netwerk: Apple networkQuality

Huidig netwerk voert macOS networkQuality uit en parseert de gestructureerde resultaten ervan, inclusief downloaden, uploaden, inactieve latentie en reactievermogen onder belasting in RPM. RPM betekent netwerkuitwisselingen heen en terug per minuut, zoals gemeten door de tool van Apple; de app behoudt de geretourneerde waarde. De onbewerkte download- en uploadbitsnelheden worden gedeeld door 1.000.000 voor weergave in Mbps.

Wanneer een interface is geselecteerd, neemt het snelheidstestcommando het interface-argument op en controleert de interfacenaam die in het resultaat wordt geretourneerd. Als het systeem slechts enkele metrieken levert, blijven die velden behouden en blijven de andere leeg.

Monitor: snelheidsmetingen via server en systeem

Elke Monitor-snelheidstestronde voert download- en uploadtests uit tegen het geselecteerde Cloudflare- of LibreSpeed-eindpunt en voert vervolgens Apple networkQuality uit. De twee methoden behouden hun eigen bron, tijd en daadwerkelijke resultaten. Eindpuntdownloads lezen testpayloads; uploads maken gebruik van tijdelijke gegevens die door de app worden gegenereerd. De gemiddelde doorvoer wordt berekend op basis van de feitelijk overgedragen bytes en de verstreken tijd voor die fase:

Doorvoer (Mbps) = daadwerkelijk overgedragen bytes × 8 ÷ Verstreken tijd (seconden) ÷ 1.000.000

Verzoeken maken gebruik van expliciete testpayloads, time-outs en cachebeleid, waarbij de voortgang van de overdracht, het aantal doelbytes en de feitelijk overgedragen bytes afzonderlijk worden bewaard. Faseresultaten onderscheiden voltooide, gedeeltelijke en mislukte overdrachten. Records behouden de server en interface om vergelijkingen onder dezelfde omstandigheden te ondersteunen.

Continue monitoring, grafieken en statistieken

Onafhankelijke bemonstering op een gedeelde tijdlijn

Monitor bevat tien soorten tools: Ping, TCP, DNS, websites, netwerkpaden, snelheidstests, draadloos signaal, interfaceverkeer, app-verkeer en app-verbindingen. Elke taak behoudt zijn eigen doel, parameters en bemonsteringstijden. Een gedeeld tijdvenster lijnt observaties uit om latentie, draadloze metingen, verkeer en servicereacties in de loop van de tijd te vergelijken.

Voor actieve tests en bandbreedteoverdrachten zijn afzonderlijke resourcequota vereist. Het huidige standaardbudget staat acht gelijktijdige testbewerkingen en twee gelijktijdige overdrachten toe. Bij operaties buiten het budget wordt gewacht tot er een quotum wordt vrijgegeven. Bij annulering wordt gewacht totdat de daadwerkelijke bewerking is beëindigd voordat het quotum wordt vrijgegeven. Quota zijn van toepassing op elke individuele sonde of overdracht; bij herhaalde taken worden ze opnieuw gevraagd voor de volgende ronde.

Grafieksegmenten en relatieve veranderingen

Grafieken verbinden punten op basis van bemonsteringstijd en segmentidentiteit, waardoor onderbrekingen gescheiden blijven en fouten afzonderlijk worden weergegeven. Interpolatie bij de grenzen van de vensters wordt alleen gebruikt voor tekenen; statistieken maken gebruik van feitelijke waarnemingen.

Bij ingeschakelde markeringen voor relatieve latentiepieken berekent de app de mediaan m van de vorige 5 metingen in hetzelfde segment. Een latentie boven max(3 × m, m + 5 ms) wordt gemarkeerd. Voor het draadloze signaal worden afwijkingen van minstens 8 dB ten opzichte van de recente mediaan gemarkeerd. De markeringen tonen veranderingen ten opzichte van een recent referentieniveau.

Mediaan, P95 en variatie

Voor de statistieken worden geldige, eindige waarden in het tijdvenster geselecteerd en oplopend gesorteerd. Bij een oneven aantal is de mediaan de middelste waarde; bij een even aantal is dit het gemiddelde van de twee middelste waarden. Zonder geldige metingen blijven de statistieken leeg. P95 gebruikt de nearest-rank-methode:

P95 = Waarde op positie ceil(0.95 × n) in oplopend gesorteerde meetwaarden
ICMP-geen-responsratio = Onbeantwoorde probes ÷ Daadwerkelijk verzonden probes
ICMP-latentievariatie = Som van absolute RTT-verschillen tussen geldige aangrenzende antwoorden ÷ Aantal geldige aangrenzende paren

App-verbinding ICMP-sessies verzamelen percentielen met behulp van een histogram met een precisie van 0,1 ms, onafhankelijk van het bewaarvenster voor de onbewerkte geschiedenis. Geldige antwoorden van 0 tot 2000 ms komen in histogrambuckets terecht. Grotere waarden vormen een overflowtelling en dragen bij aan het maximum; percentielen die binnen het overloopbereik vallen, blijven leeg. Latentievariatie koppelt alleen geldige aangrenzende antwoorden in hetzelfde segment met een tussenruimte van niet meer dan 2,5 seconden.

Monitoringgegevens en rapportexport

In monitoringrecords worden taakparameters, doelstellingen, bemonsteringstijden, daadwerkelijke resultaten en ondersteunend bewijsmateriaal opgeslagen. Grafieken tonen veranderingen in de loop van de tijd, terwijl rapporten observaties organiseren voor lezing of verdere verwerking.

HTML

Een leesbaar rapport met taaksamenvattingen, resultaten en details.

CSV

Bewijsmateriaal georganiseerd in kolommen zoals tijd, categorie, object, doel, methode, status, waarde, eenheid en details voor spreadsheetanalyse.

JSON

Gestructureerde records, configuratie en resultaten voor verdere verwerking.

Lange app-verbindingssessies gebruiken gesegmenteerde archieven. Bij export wordt eerst het leesbereik vastgelegd. Daarna worden de archiefgegevens en de resterende gegevens in het geheugen uitgelezen, zodat elke export consistente gegevensgrenzen gebruikt. Ontbrekende waarden, fouten en annuleringen behouden hun eigen status.