NetQuickCheck teknisk dokumentation

Datakällor och val av gränssnitt

NetQuickCheck kombinerar systemsampling, aktiva nätverkssonder och härledd statistik. Systemsampling ger information om gränssnitt, trådlöst och processanslutning. Aktiva sonder fångar ett måls svar på en begäran. Härledd statistik omvandlar observationer till hastigheter, percentiler och diagram.

Uppgifter med ett valt gränssnitt binder sina förfrågningar till det. TCP, UDP och direkta HTTP-förfrågningar använder Network.framework-gränssnittsbindning; ICMP-sonder använder systemkommandots gränssnittsargument. Automatisk routing låter macOS välja sökvägen, och automatiska HTTP-förfrågningar följer systemsessionen och proxypolicyer. Det valda gränssnittet sparas med resultaten för att stödja jämförelser över Wi-Fi, Ethernet och andra tillgängliga gränssnitt.

Aktuellt nätverk och snabba kontroller

Gränssnittsavläsningar och överföringshastigheter

Aktuellt nätverk läser gränssnittsstatus, adresser, gateway och DNS, tillsammans med trådlösa avläsningar för det anslutna Wi-Fi-nätverket. Överförda byte kommer från 64-bitars gränssnittsräknare för systemrouting. Mottagningsfel, sändningsfel och bortfall i mottagningskön behålls separat.

Mottagningshastighet (B/s) = Ökning av mottagna byte mellan sampel ÷ Samplingsintervall (sekunder)
Sändningshastighet (B/s) = Ökning av skickade byte mellan sampel ÷ Samplingsintervall (sekunder)
Bithastighet (Mbps) = Bytehastighet × 8 ÷ 1 000 000

Hastigheter beskriver den genomsnittliga överföringsvolymen under provintervallet. MiB/s använder 1 048 576 byte per enhet; Mbps använder en miljon bitar per sekund. Gränssnitträknare och räknare aggregerade av app täcker olika uppsättningar av trafik.

Sekvensen av en snabb kontroll

Snabbkontroll bekräftar den lokala anslutningen, sonderar gatewayen, frågar efter DNS, kontrollerar Internetanslutning, begär HTTPS och kontrollerar sedan utgående information. Den nuvarande implementeringen tillåter 8 sekunder för hela kontrollen. Varje aktivt steg kan använda upp till 2 sekunder av den återstående budgeten, och resultaten uppdateras när varje steg avslutas.

Gatewaysteget försöker en TCP-anslutning till gatewayport 443. Både en framgångsrik anslutning och en explicit anslutningsvägran bekräftar ett svar från gatewayen; det ursprungliga anslutningsresultatet behålls också. DNS-, Internet- och HTTPS-steg registrerar sina egna svar för att undersöka varje del av anslutningsvägen.

Wi-Fi-skanning och trådlösa mätvärden

Trådlös skanning använder CoreWLAN för att erhålla närliggande accesspunkters SSID, BSSID, primära kanal, band, kanalbredd och mottagna signalstyrka. Den tillgängliga kanalkatalogen kommer från det aktuella trådlösa gränssnittet. Sändningsinformationselement lägger till säkerhetsfunktioner, Wi-Fi-standarder, landskoder och andra detaljer. Åtkomst till identifierare som SSID och BSSID följer macOS platsbehörighetsregler.

RSSI, brus och signal-brus-förhållande

RSSI och brus använder dBm, ett logaritmiskt effektmått i förhållande till 1 milliwatt. Ett RSSI-värde närmare 0 betyder en starkare mottagen signal. När båda avläsningarna är giltiga, beräknar appen signal-brusförhållande:

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

Till exempel ger RSSI på −55 dBm och brus på −92 dBm ett SNR på 37 dB. Den aktuella beräkningen accepterar avläsningar från −127 till −1 dBm. Om någon av läsningarna saknas förblir SNR tom.

Trådlös signalövervakning har två samplingskällor. Lokalt läge läser regelbundet det anslutna Wi-Fi-nätverket; närläge skannar upprepade gånger valda åtkomstpunkter. Diagram behåller tiden för varje läsning, och accesspunktsidentiteter särskiljer olika trådlösa signaler.

Utnyttjande av sändningskanaler

När en åtkomstpunkt sänder ett giltigt BSS Load-informationselement, konverterar appen sitt kanalutnyttjandefält från 0–255 till en procentandel: fältvärde × 100 ÷ 255. Detta bevarar betydelsen av sändningsvärdet. Kanalöverlappningsdiagrammet använder frekvenstäcknings- och effektmodellen som beskrivs nedan.

Kanaltäckning och utvärdering

Konvertera kanaler till frekvensområden

Kanalutvärdering bygger frekvensområden från band, primär kanal och kanalbredd. För 2,4 GHz-kanalerna 1–13 är mittfrekvensen i MHz 2407 + 5 × kanalnummer; kanal 14 mappar separat till 2484 MHz. För 5 GHz är det 5000 + 5 × kanalnummer. Ett 20 MHz-område sträcker sig 10 MHz till vardera sidan av mitten; bredare kanaler kombinerar subkanalblock som stöds av katalogen.

Kandidater genereras av band och kanalbredd, och varje underkanal i en kandidat måste finnas i den aktuella katalogen. Appen utvärderar 20 och 40 MHz-kombinationer på 2,4 GHz och 20, 40, 80 och 160 MHz-kombinationer på 5 och 6 GHz. Skanningsresultat slås samman efter band och BSSID. När BSSID saknas fungerar skanningspostens identifierare som reservidentitet för att undvika att samma åtkomstpunkt räknas två gånger.

När information om kanalbredd eller riktning är ofullständig behåller appen bekräftad och möjlig täckning separat. Områden som delas av alla möjliga positioner är bekräftad täckning; resten förblir möjlig täckning. Varje åtkomstpunkt räknas en gång.

Beräknar överlappningseffekt från logaritmiska signalavläsningar

Signalstyrkan omvandlas från dBm till relativ linjär effekt och viktas sedan med andelen frekvensöverlappning. För åtkomstpunkt i och kandidat c:

Pᵢ = 10 ^ ((RSSIᵢ + 100) ÷ 10)
wᵢ,c = Total överlappande bandbredd ÷ Total modellerad accesspunktsbandbredd
Poverlap,c = Σ (Pᵢ × wᵢ,c)

Termen +100 ger en delad relativ effektreferens. När kanalbredden är osäker och överlappar kandidatområdet sätts vikten konservativt till 1. Både signalstyrka och täckningsbredd bidrar därför. En 10 dB RSSI-skillnad motsvarar en tiofaldig linjär effektskillnad.

Rankning av kandidater

När den aktuella åtkomstpunkten kan identifieras utesluts den så att rankningen utvärderar omgivande signaler. Den nuvarande rankningen filtrerar bort DFS-kandidater. På 2,4 GHz vid 20 MHz föredras gruppen 1, 6 och 11 kanaler, följt av jämförelser av åtkomstpunkter med saknad RSSI, uppskattad störningseffekt, totalt antal åtkomstpunkter och kanalsekvens.

När varje kandidat har jämförbara brusavläsningar omvandlas även brus till linjär effekt och inkluderas. I annat fall jämförs kandidater med enbart överlappande signaleffekt. Varje kandidatunderkanal använder mitten av sina sorterade giltiga brusavläsningar; den kompletta kandidaten tar det högsta av dessa brusvärden.

Inom samma band och kanalbredd föredras den aktuella konfigurationen när den delar den bästa kandidatens prioritetsgrupp och antalet accesspunkter med saknad RSSI, och dess uppskattade effekt inte är mer än dubbelt så hög som den bästa kandidatens. En dubbel linjär effektskillnad är cirka 3 dB. Detta minskar rankningsförändringar orsakade av små skillnader.

Visar överlappskurvor

Överlappskurvor beräknar viktad effekt i ett 20 MHz-fönster runt varje kanalcentrum och använder sedan logaritmisk komprimering för att mappa den till ett relativt visningsområde på 0–1:

Visningsintensitet = min(1, max(0, log₁₀(1 + Poverlap) ÷ 7))

Denna vertikala axel representerar relativ överlappningsintensitet härledd från skanningsavläsningar. Om en överlappande åtkomstpunkt saknar giltig RSSI, förblir den positionen tom och kurvan delas. Bekräftad och möjlig täckning förblir separata.

Lokal nätverksenhetsupptäckt

Enhetsupptäckt kombinerar Bonjour-, WS-Discovery-, SSDP- och TCP-tjänstsonder. Bonjour tillhandahåller annonserade tjänsteinstanser. WS-Discovery och SSDP lägger till svar från kompatibla enheter. TCP-sonder kontrollerar servicesvar på adresser inom det aktuella skanningsintervallet.

Aktuella TCP-sondportar är 80, 443, 445, 22, 631 och 9100, som täcker vanliga webb-, fildelnings-, fjärråtkomst- och utskriftstjänster. Förfrågningar använder det valda gränssnittet. Observationer behåller sin källa, adress och faktiska svar.

Enhetsupptäckten slår samman observationer från varje källa i omgångar och ordnar namn, typer och tjänster utifrån enhetsadresser och tjänsteuppgifter. Otillgängliga gränssnitt, nekad åtkomst, timeouter och tjänstesvar registreras separat. När en skanning avbryts eller startas om isoleras fördröjda återanrop från den föregående skanningen så att de inte påverkar de nya resultaten.

Apptrafik och koppling till appar

Hitta appar från systemets anslutningstabell

Apptrafik läser processer, protokoll, lokala och fjärranslutna slutpunkter, gränssnitt, anslutningstillstånd och antal byte från nettop. Appen kombinerar information om körapplikationer, processförälderrelationer och körbara sökvägar för att associera hjälpprocesser med deras ägande app.

Ägarmatchning kontrollerar först själva processen och följer sedan upp till 16 överordnade processer. Om ingen matchning hittas använder den app-paketets sökväg som innehåller den körbara filen. Processidentitet inkluderar också starttid för att särskilja återanvända PID.

Beräknar varje anslutnings ändring och aggregerar sedan per app

Efterföljande mätningar matchar anslutningar efter process, protokoll, lokala och fjärranslutna adresser och portar samt gränssnitt. Hastigheter beräknas bara om båda byteräknarna gäller samma jämförbara anslutning och summeras sedan per app.

Anslutningsnedladdningshastighet = (Nuvarande mottagna bytes − Tidigare mottagna bytes) ÷ Tidsskillnad
Uppladdningshastighet för anslutning = (Nuvarande skickade bytes − Tidigare skickade bytes) ÷ Tidsskillnad
Appens hastighet = Summan av giltiga anslutningshastigheter för appen och dess associerade processer

Nya anslutningar upprättar först en baslinje. En återställning av räknaren, gränssnittsändring eller sampelgap som är större än 15 sekunder kräver nya jämförbara sampel. Om systemet returnerar flera identiska rader som inte kan matchas unikt, behåller appen dessa rader och lämnar deras hastigheter tomma så att matchande tvetydighet inte visas som en trafikökning.

Fjärranslutningar och ICMP-observationer

Övervakning av appanslutningar behåller första och senast sett tider, tillståndsändringar och trafikdelta, och sonderar oberoende upptäckta fjärr-IP:er med ICMP. Trafik, anslutningsaktivitet och ICMP-resultat är anpassade efter tid. Latensavläsningen kommer från mål-IP:s ICMP-svar.

Ping- och TCP-sonder

ICMP Echo och andel uteblivna svar

Ping slår upp måladressen och håller den fast under mätningen för sonden och skickar sedan en IPv4 ICMP Echo eller IPv6 ICMPv6 Echo begäran. Kontinuerlig övervakning upprepas enligt konfiguration, registrerar faktiska sändningar, svar, uteblivna svar och returnerade tider för tur och retur.

Andel uteblivna svar = Sonder utan svar ÷ Faktiskt skickade sonder × 100 %

Beräkningen använder antalet sändningar som bekräftats av systemets utdata. Fel vid namnuppslagning, nekad behörighet och förfrågningar som inte kunde skickas behåller sin status och räknas inte som skickade sonder i nämnaren. Latensstatistiken använder giltiga svarstider (RTT).

TCP-portanslutningar

Efter att ha löst målet försöker TCP-portövervakning en anslutning till den valda porten och använder en monoton klocka för att mäta tiden fram till framgång eller ett fel. DNS-upplösningen avslutas först, och TCP-anslutningens timing mäts separat. Framgång, anslutningsvägran, timeout och andra systemfel behålls separat för att visa hur samma serviceport beter sig över tiden.

DNS-frågor och svarsvalidering

DNS-övervakning frågar efter den valda servern och posttypen, såsom A, AAAA, CNAME, MX, TXT, NS, SOA eller PTR. Systemupplösning och explicita serverfrågor följer separata vägar. Automatisk routing använder systemupplösning eller dig enligt begäran; frågor bundna till ett valt gränssnitt utbyter paket över UDP-port 53.

Direkta frågor genererar ett transaktions-ID och bygger frågenamn, typ och IN-klass. Svar kontrolleras för paketlängd, transaktions-ID, svarsflagga, antal frågor, namn, typ och klass innan svarskoder, resursposter och TTL:er analyseras. Pakettolkaren expanderar komprimerade domännamnpekare.

NOERROR med poster av den valda typen, NOERROR utan dessa poster, NXDOMAIN, trunkerade paket och transportfel registreras separat. PTR-frågor konverterar först IPv4- eller IPv6-adressen till dess omvända sökningsnamn. Timing täcker fråge- och svarsanalys, och resultaten behåller det faktiska server- och postinnehållet.

HTTP-svar och stegtiming

Webbplatsövervakning skickar HTTP- eller HTTPS HEAD-förfrågningar och registrerar den returnerade statuskoden, slutlig URL och varaktighet. Automatisk routing använder URLSession transaktionsstatistik. Med ett explicit gränssnitt eller upplösningssökväg använder den direkta HTTP-implementeringen Network.framework-anslutningsrapporter och begärande tidsstämplar.

Etappens varaktighet är skillnaden mellan slut- och starttidsstämplar. En återanvänd anslutning kanske inte har något nytt DNS-, TCP- eller TLS-steg; steg utan giltiga tidsstämplar förblir tomma. Omdirigeringar behåller tidpunkten för varje begäran. Den totala kontrolltiden mäts separat eftersom den också inkluderar upplösning, omdirigeringar, schemaläggning och andra faktiska omkostnader.

HTTPS använder förtroendevalidering av systemcertifikat och extraherar ämnet, utfärdaren, giltighetsperioden och SHA-256-fingeravtrycket från giltiga certifikat. HTTP-statuskoder beskriver serverns svar; transportfel beskriver anslutningsprocessen. Båda lagras separat.

Nätverksväg och hopp-för-hopp-sonder

Nätverkssökvägsövervakning slår upp måladressen och håller den fast under mätningen och skickar sedan ICMP-sonder med IPv4 TTL eller IPv6 Hop Limit som ökar från 1. Mellanliggande routrar kan returnera tidsöverskridna svar, medan destinationen kan returnera ett Echo Reply. Appen använder dessa svar för att organisera hoppadresser och tillgängliga tider.

Varje runda sonderar för närvarande upp till 16 hopp. Om ett hopp inte svarar, kontrolleras fortfarande senare hopp. Ett målsvar avslutar omgången. Otillgängliga och avvisade svar behåller sina ursprungliga resultat. Om en adress är tillgänglig utan giltig varaktighet, behålls adressen och tidpunkten förblir tom.

Genomströmning och svarsförmåga under belastning

Aktuellt nätverk: Apple networkQuality

Aktuellt nätverk kör macOS networkQuality och analyserar dess strukturerade resultat, inklusive nedladdning, uppladdning, inaktiv latens och respons under belastning i RPM. RPM betyder tur och retur per minut, mätt med Apples verktyg; appen behåller det returnerade värdet. Råa nedladdnings- och uppladdningsbithastigheter divideras med 1 000 000 för visning i Mbps.

När ett gränssnitt väljs inkluderar hastighetstestkommandot dess gränssnittsargument och kontrollerar gränssnittsnamnet som returneras i resultatet. Om systemet bara tillhandahåller vissa mätvärden, behålls dessa fält och de andra förblir tomma.

Övervakning: hastighetstester via server och system

Varje monitorhastighetstestomgång kör nedladdnings- och uppladdningstester mot den valda Cloudflare- eller LibreSpeed-slutpunkten och kör sedan Apple networkQuality. De två metoderna behåller sin egen källa, tid och faktiska resultat. Slutpunktsnedladdningar läser testnyttolaster; uppladdningar använder tillfällig data som genereras av appen. Genomsnittlig genomströmning beräknas från de byte som faktiskt överförs och den förflutna tiden för det steget:

Genomströmning (Mbps) = Bytes som faktiskt överförts × 8 ÷ Förfluten tid (sekunder) ÷ 1 000 000

Förfrågningar använder explicita testnyttolaster, timeouts och cache-policyer, bibehåller överföringsförlopp, målbyteantal och faktisk överförda byte separat. Etappresultat särskiljer genomförda, partiella och misslyckade överföringar. Poster behåller servern och gränssnittet för att stödja jämförelser under samma förhållanden.

Kontinuerlig övervakning, diagram och statistik

Oberoende provtagning på en delad tidslinje

Övervakning innehåller tio verktygstyper: Ping, TCP, DNS, webbplatser, nätverksvägar, hastighetstester, trådlös signal, gränssnittstrafik, apptrafik och appanslutningar. Varje uppgift behåller sitt eget mål, parametrar och provtider. Ett delat tidsfönster anpassar observationer för att jämföra latens, trådlösa avläsningar, trafik och servicesvar över tid.

Aktiva sonder och bandbreddsöverföringar begär separata resurskvoter. Den nuvarande standardbudgeten tillåter 8 samtidiga sondoperationer och 2 samtidiga överföringar. Operationer utöver budgeten väntar tills en kvot frigörs. Vid avbrott väntar appen på att den faktiska operationen avslutas innan dess kvot frigörs. Kvoter gäller för varje enskild sond eller överföring; upprepade uppgifter begär dem igen för nästa omgång.

Diagramsegment och relativa förändringar

Diagram kopplar samman punkter genom provtid och segmentidentitet, håller avbrott åtskilda och visar fel individuellt. Interpolation vid vyportsgränser används endast för ritning; statistik använder faktiska observationer.

När markeringar för relativa latenstoppar är aktiverade beräknar appen medianen m av de föregående 5 mätvärdena i samma segment. Latens över max(3 × m, m + 5 ms) markeras. För den trådlösa signalen markeras avvikelser på minst 8 dB från den senaste medianen. Markeringarna visar förändringar jämfört med en aktuell referensnivå.

Median, P95 och variation

Statistiken använder giltiga, ändliga värden i tidsfönstret, sorterade i stigande ordning. Vid ett udda antal är medianen det mittersta värdet; vid ett jämnt antal är den medelvärdet av de två mittersta värdena. Utan giltiga mätvärden lämnas statistiken tom. P95 använder metoden med närmaste rang:

P95 = Värdet på position ceil(0.95 × n) bland mätvärden sorterade i stigande ordning
Andel uteblivna ICMP-svar = Sonder utan svar ÷ Faktiskt skickade sonder
ICMP-latensvariation = Summan av absoluta RTT-skillnader mellan giltiga intilliggande svar ÷ Antal giltiga intilliggande par

ICMP-sessioner för appanslutningar beräknar percentiler med ett histogram med 0,1 ms upplösning, oberoende av hur länge råhistoriken sparas. Giltiga svar från 0 till 2000 ms placeras i histogrammets intervall. Större värden räknas som överflöden och tas med i maxvärdet; percentiler i överflödesområdet lämnas tomma. Latensvariationen använder bara giltiga intilliggande svar i samma segment med högst 2,5 sekunders mellanrum.

Övervakningsposter och rapportexport

Övervakningsposter sparar uppgiftsparametrar, mål, provtider, faktiska resultat och stödjande bevis. Diagram visar förändringar över tid, medan rapporter organiserar observationer för läsning eller vidare bearbetning.

HTML

En läsbar rapport med uppgiftssammanfattningar, resultat och detaljer.

CSV

Bevis organiserat i kolumner som tid, kategori, objekt, mål, metod, status, värde, enhet och detaljer för kalkylbladsanalys.

JSON

Strukturerade register, konfiguration och resultat för vidare bearbetning.

Långa appanslutningssessioner använder segmenterade arkiv. Exporten låser först arkivets läsintervall, strömmar sedan arkiverad data och de data som fortfarande finns i minnet så att en export använder konsekventa datagränser. Saknade värden, misslyckanden och annulleringar behåller sina egna tillstånd för att stödja konsekvent tolkning under granskning.