Documentación técnica de NetQuickCheck
Fuentes de datos, cálculos y métodos de supervisión: análisis inalámbrico, tráfico de apps, pruebas de red e informes.
Fuentes de datos y selección de interfaz
NetQuickCheck combina muestreo del sistema, pruebas activas y estadísticas derivadas. El muestreo aporta interfaces, señal inalámbrica y conexiones de procesos. Las pruebas activas registran la respuesta de un destino. Las estadísticas convierten las observaciones en velocidades, percentiles y gráficos.
| Datos | Método de obtención | Uso |
|---|---|---|
| Interfaces de red | Configuración de interfaces y redes de macOS y contadores de enrutamiento | Estado, direcciones, rutas, DNS, bytes transferidos y errores de interfaces |
| Redes inalámbricas | Lecturas de conexión y resultados de escaneo de CoreWLAN | RSSI, ruido, canal, ancho de canal, detalles de puntos de acceso y cobertura de frecuencias |
| Conexiones de procesos | Estadísticas nettop e información de procesos del sistema | App propietaria, direcciones remotas, estados, bytes y sus variaciones |
| Respuestas de destinos | ICMP, TCP, DNS, HTTP y transferencias de prueba | Latencia, resultados DNS, estado de servicios, rutas y rendimiento |
Las tareas con una interfaz seleccionada vinculan sus solicitudes a ella. TCP, UDP y HTTP directo usan Network.framework; ICMP usa el argumento de interfaz del comando del sistema. En modo automático, macOS elige la ruta y HTTP sigue las políticas de sesión y proxy del sistema. La interfaz se guarda con los resultados para comparar Wi-Fi, Ethernet y otras conexiones.
Red actual y comprobaciones rápidas
Lecturas de interfaces y velocidades
Red actual obtiene estado, direcciones, puerta de enlace y DNS, además de las lecturas Wi-Fi. Los bytes transferidos proceden de contadores de interfaz de enrutamiento de 64 bits. Los errores de recepción, envío y descartes de cola se conservan por separado.
Recepción (B/s) = Incremento de bytes recibidos ÷ Intervalo entre muestras (s)
Envío (B/s) = Incremento de bytes enviados ÷ Intervalo entre muestras (s)
Velocidad (Mbps) = Bytes por segundo × 8 ÷ 1,000,000
Las velocidades son promedios del intervalo de muestreo. MiB/s equivale a 1,048,576 bytes por unidad y Mbps a un millón de bits por segundo. Los contadores de interfaz y los agregados por app abarcan conjuntos de tráfico diferentes.
Secuencia de la comprobación rápida
La comprobación confirma la conexión local, prueba la puerta de enlace, consulta DNS, comprueba Internet, solicita HTTPS y obtiene información de salida. El límite actual es de 8 segundos en total. Cada paso activo usa hasta 2 segundos del presupuesto restante y muestra su resultado al terminar.
La puerta de enlace se prueba mediante TCP al puerto 443. Tanto una conexión exitosa como un rechazo explícito confirman que respondió; se conserva el resultado original. DNS, Internet y HTTPS registran sus propias respuestas para examinar cada tramo.
Escaneo Wi-Fi y métricas inalámbricas
El escaneo usa CoreWLAN para obtener SSID, BSSID, canal principal, banda, ancho y señal de puntos de acceso cercanos. El catálogo de canales procede de la interfaz actual. Los elementos de información emitidos añaden seguridad, estándares Wi-Fi, país y otros detalles. Los identificadores SSID y BSSID dependen de los permisos de ubicación de macOS.
RSSI, ruido y relación señal/ruido
RSSI y ruido se expresan en dBm, una medida logarítmica respecto a 1 milivatio. Un RSSI más cercano a 0 indica mayor señal recibida. Cuando ambas lecturas son válidas, se calcula:
SNR (dB) = RSSI (dBm) − Ruido (dBm)
Por ejemplo, −55 dBm de RSSI y −92 dBm de ruido producen 37 dB de SNR. Se aceptan lecturas entre −127 y −1 dBm. Si falta una, la SNR queda vacía.
La supervisión de señal tiene dos fuentes: el modo local lee periódicamente la conexión Wi-Fi y el modo cercano escanea los puntos de acceso seleccionados. Los gráficos conservan los tiempos y distinguen cada punto de acceso.
Utilización de canal anunciada
Si un punto de acceso emite un elemento BSS Load válido, el campo de utilización de 0–255 se convierte a porcentaje: valor × 100 ÷ 255. Se conserva el significado del dato anunciado. El gráfico de solapamiento usa el modelo de cobertura y potencia descrito a continuación.
Cobertura y evaluación de canales
Conversión de canales a frecuencias
La evaluación construye rangos según banda, canal principal y ancho. En 2.4 GHz, los canales 1–13 tienen frecuencia central 2407 + 5 × canal, en MHz; el 14 corresponde a 2484 MHz. En 5 GHz se usa 5000 + 5 × canal. Un canal de 20 MHz se extiende 10 MHz a cada lado; los más anchos combinan subcanales del catálogo.
Los candidatos se generan por banda y ancho, y todos sus subcanales deben existir en el catálogo. Se evalúan 20 y 40 MHz en 2.4 GHz, y 20, 40, 80 y 160 MHz en 5 y 6 GHz. Los registros se fusionan por banda y BSSID; si falta BSSID, se usa el identificador del registro para no contar dos veces el mismo punto de acceso.
Si faltan el ancho o la dirección, se conservan por separado las coberturas confirmada y posible. La intersección de todas las posiciones posibles es cobertura confirmada; el resto es posible. Cada punto de acceso se cuenta una vez.
Potencia de solapamiento a partir de la señal logarítmica
La señal en dBm se convierte a potencia lineal relativa y se pondera por la fracción de frecuencia solapada. Para el punto i y el candidato c:
Pᵢ = 10 ^ ((RSSIᵢ + 100) ÷ 10)
wᵢ,c = Ancho solapado total ÷ Ancho total modelado del punto de acceso
Poverlap,c = Σ (Pᵢ × wᵢ,c)
El término +100 establece una referencia común. Si el ancho es incierto y puede solaparse con el candidato, el peso se fija conservadoramente en 1. Influyen tanto la señal como el ancho de cobertura. Una diferencia de 10 dB equivale a multiplicar por diez la potencia lineal.
Clasificación de candidatos
Si se identifica el punto de acceso actual, se excluye para evaluar las señales vecinas. La clasificación actual descarta candidatos DFS. En 2.4 GHz y 20 MHz se prioriza el grupo 1, 6 y 11; después se comparan puntos sin RSSI, potencia estimada de interferencia, número total de puntos y orden de canales.
Si todos los candidatos tienen ruido comparable, se convierte a potencia lineal y se incluye. En caso contrario, solo se compara la potencia de las señales solapadas. Cada subcanal usa la lectura central de ruido válido ordenado; el candidato completo toma el mayor de esos valores.
Con igual banda y ancho, se prefiere la configuración actual si comparte el grupo prioritario y el número de puntos sin RSSI con la mejor opción y su potencia estimada no supera el doble. El doble de potencia equivale aproximadamente a 3 dB. Esto reduce cambios de clasificación por diferencias pequeñas.
Representación de curvas de solapamiento
Las curvas calculan la potencia ponderada en una ventana de 20 MHz alrededor del centro de cada canal y la comprimen logarítmicamente a un rango relativo de 0–1:
Intensidad mostrada = min(1, max(0, log₁₀(1 + Poverlap) ÷ 7))
El eje vertical expresa intensidad relativa derivada del escaneo. Si un punto solapado no tiene RSSI válido, se deja un hueco y se divide la curva. La cobertura confirmada y la posible siguen separadas.
Descubrimiento de dispositivos locales
El descubrimiento combina Bonjour, WS-Discovery, SSDP y pruebas TCP. Bonjour aporta servicios anunciados; WS-Discovery y SSDP añaden respuestas de equipos compatibles. TCP comprueba servicios en las direcciones del rango explorado.
Los puertos TCP actuales son 80, 443, 445, 22, 631 y 9100, para web, archivos, acceso remoto e impresión. Se usa la interfaz seleccionada y se conservan la fuente, la dirección y la respuesta real.
Las observaciones se fusionan por lotes y se organizan mediante direcciones y evidencias de servicio. Interfaces no disponibles, permisos denegados, tiempos agotados y respuestas se registran por separado. Cancelar o reiniciar aísla las respuestas tardías de la exploración anterior.
Tráfico de apps y atribución de conexiones
Atribución de apps desde la tabla de conexiones
Tráfico de apps obtiene de nettop procesos, protocolos, extremos locales y remotos, interfaces, estados y bytes. Combina apps en ejecución, relaciones entre procesos y rutas ejecutables para atribuir procesos auxiliares a su app.
Se comprueba primero el propio proceso y después hasta 16 procesos padre. Sin coincidencia, se usa el paquete de app que contiene el ejecutable. La identidad incluye la hora de inicio para distinguir PID reutilizados.
Cálculo por conexión y agregación por app
Se emparejan muestras consecutivas por proceso, protocolo, extremo local, extremo remoto e interfaz. Solo se calculan velocidades para contadores de una misma conexión comparable y luego se agregan por app.
Descarga por conexión = (Bytes recibidos actuales − anteriores) ÷ Diferencia de tiempo
Subida por conexión = (Bytes enviados actuales − anteriores) ÷ Diferencia de tiempo
Velocidad por app = Suma de velocidades válidas de sus conexiones y procesos asociados
Las conexiones nuevas establecen una base. Un reinicio del contador, cambio de interfaz o intervalo superior a 15 segundos exige nuevas muestras comparables. Si varias filas idénticas no pueden emparejarse de forma única, se conservan con velocidades vacías para evitar picos falsos.
Conexiones remotas y observaciones ICMP
La supervisión conserva primera y última detección, cambios de estado y diferencias de tráfico, y prueba por ICMP las IP remotas descubiertas de forma independiente. Tráfico, actividad e ICMP se alinean temporalmente. La latencia procede de la respuesta ICMP de cada IP.
Pruebas Ping y TCP
ICMP Echo y proporción sin respuesta
Ping resuelve y fija el destino, y envía ICMP Echo IPv4 o ICMPv6 Echo. La supervisión repite según la configuración y registra envíos reales, respuestas, ausencias y tiempos de ida y vuelta.
Sin respuesta = Pruebas sin respuesta ÷ Pruebas realmente enviadas × 100%
El denominador usa envíos confirmados por la salida del sistema. Fallos DNS, permisos denegados y solicitudes no enviadas conservan su estado y no se cuentan como envíos. La latencia usa RTT de respuestas válidas.
Conexiones a puertos TCP
Tras resolver el destino, se intenta conectar al puerto elegido y se mide con reloj monotónico hasta el éxito o el error. La resolución DNS se completa primero; el tiempo de conexión TCP se mide por separado. Éxitos, rechazos, tiempos agotados y otros errores se conservan como estados distintos.
Consultas DNS y validación de respuestas
DNS consulta el servidor y tipo elegidos: A, AAAA, CNAME, MX, TXT, NS, SOA o PTR. La resolución del sistema y las consultas explícitas usan rutas diferentes. El modo automático usa resolución del sistema o dig; las consultas vinculadas a interfaz intercambian paquetes UDP por el puerto 53.
Las consultas directas generan un ID y construyen nombre, tipo y clase IN. Antes de interpretar códigos, registros y TTL, se comprueban longitud, ID, indicador de respuesta, número de preguntas, nombre, tipo y clase. El analizador expande punteros de compresión de nombres.
Se distinguen NOERROR con registros del tipo pedido, NOERROR sin ellos, NXDOMAIN, paquetes truncados y errores de transporte. PTR transforma primero IPv4 o IPv6 en nombre inverso. El tiempo incluye consulta y análisis; se conservan servidor real y registros.
Respuesta HTTP y tiempos por fase
La supervisión web envía HEAD HTTP o HTTPS y registra código, URL final y duración. El modo automático usa métricas URLSession; con interfaz o resolución explícitas, HTTP directo usa informes de conexión de Network.framework y marcas de tiempo.
| Fase | Inicio | Fin |
|---|---|---|
| DNS | Comienza la resolución del nombre | Termina la resolución |
| TCP | Comienza el intento de conexión | TCP conectado; TLS se mide aparte |
| TLS | Comienza el establecimiento seguro | Termina el establecimiento seguro |
| Envío de solicitud | Comienza la transmisión | Termina la transmisión |
| Espera del primer byte | Termina la transmisión | Llega el primer byte de respuesta |
| Recepción de respuesta | Llega el primer byte de respuesta | Termina la recepción de HEAD |
La duración de cada fase es fin menos inicio. Una conexión reutilizada puede no necesitar DNS, TCP o TLS nuevos; sin tiempos válidos, la fase queda vacía. Las redirecciones conservan tiempos por solicitud. La duración total se mide aparte e incluye resolución, redirecciones, planificación y otros costes reales.
HTTPS usa la validación de confianza del sistema y extrae sujeto, emisor, validez y huella SHA-256 de los certificados válidos. Los códigos HTTP describen la respuesta del servidor y los errores de transporte la conexión; se guardan por separado.
Ruta de red y pruebas por salto
La ruta de red fija la dirección resuelta y envía ICMP aumentando desde 1 el TTL IPv4 o Hop Limit IPv6. Los routers pueden responder con tiempo excedido y el destino con Echo Reply. Así se organizan direcciones y tiempos por salto.
Cada ronda prueba hasta 16 saltos. La ausencia de respuesta no impide probar los siguientes. Una respuesta del destino termina la ronda. Se conservan los resultados de inaccesibilidad o bloqueo. Si hay dirección pero no tiempo válido, se guarda la dirección y se deja el tiempo vacío.
Rendimiento y respuesta bajo carga
Red actual: Apple networkQuality
Red actual ejecuta networkQuality y analiza descarga, subida, latencia en reposo y respuesta bajo carga en RPM. RPM son viajes de ida y vuelta por minuto medidos por Apple; se conserva el valor original. Las velocidades en bits se dividen por 1,000,000 para mostrar Mbps.
Con una interfaz elegida, el comando la especifica y comprueba el nombre devuelto. Si el sistema solo aporta algunas métricas, se conservan y las demás quedan vacías.
Monitor: pruebas de nodo y del sistema
Cada ronda ejecuta descarga y subida contra el nodo Cloudflare o LibreSpeed elegido y después Apple networkQuality. Ambos métodos conservan fuente, hora y resultados reales. Las descargas leen cargas de prueba y las subidas usan datos temporales generados por la app. La velocidad media se calcula con los bytes realmente transferidos y la duración de la fase:
Rendimiento (Mbps) = Bytes transferidos × 8 ÷ Duración (s) ÷ 1,000,000
Las solicitudes usan cargas de prueba, límites de tiempo y políticas de caché explícitos. Se guardan por separado progreso, bytes previstos y transferidos, distinguiendo transferencias completas, parciales y fallidas. Los registros conservan servidor e interfaz para comparar condiciones equivalentes.
Supervisión continua, gráficos y estadísticas
Muestreo independiente en una línea de tiempo común
El monitor incluye diez tipos: Ping, TCP, DNS, web, rutas, velocidad, señal inalámbrica, tráfico de interfaz, tráfico de apps y conexiones de apps. Cada tarea conserva destino, parámetros y tiempos de muestra. Una ventana común alinea latencia, señal, tráfico y respuestas de servicios.
Las pruebas activas y las transferencias solicitan cuotas separadas. El presupuesto predeterminado permite 8 pruebas y 2 transferencias simultáneas. Las demás esperan. Al cancelar, la cuota solo se libera cuando la operación termina realmente. Las tareas repetidas solicitan de nuevo la cuota en cada ronda.
Segmentos de gráficos y cambios relativos
Los gráficos unen puntos según tiempo y segmento, separan interrupciones y muestran fallos individualmente. La interpolación en los bordes solo sirve para dibujar; las estadísticas usan observaciones reales.
Con marcadores de picos relativos, se calcula la mediana m de las 5 muestras anteriores del mismo segmento. Se marca latencia superior a max(3 × m, m + 5 ms). En señal inalámbrica, se marca una diferencia de al menos 8 dB frente a la mediana reciente.
Mediana, P95 y variación
Las estadísticas ordenan valores válidos y finitos de la ventana. Con un número impar se toma el central; con uno par, la media de los dos centrales. Sin muestras válidas quedan vacías. P95 usa el método de rango más próximo:
P95 = Valor en la posición ceil(0.95 × n) de las muestras ordenadas
Sin respuesta ICMP = Pruebas sin respuesta ÷ Pruebas enviadas
Variación ICMP = Suma de diferencias absolutas entre RTT adyacentes válidos ÷ Número de pares válidos
Las sesiones ICMP de conexiones de apps acumulan percentiles en un histograma de 0.1 ms, independientemente de la retención del historial. Entre 0 y 2000 ms se usan intervalos; valores mayores van al desbordamiento y al máximo. Los percentiles en ese rango quedan vacíos. La variación solo empareja respuestas válidas del mismo segmento separadas como máximo 2.5 segundos.
Registros y exportación de informes
Los registros guardan parámetros, destinos, tiempos de muestra, resultados reales y evidencias. Los gráficos muestran cambios y los informes organizan observaciones para su lectura o procesamiento.
- HTML
- Informe legible con resumen de tareas, resultados y detalles.
- CSV
- Evidencias en columnas de tiempo, categoría, objeto, destino, método, estado, valor, unidad y detalles para hojas de cálculo.
- JSON
- Registros estructurados, configuración y resultados para procesamiento posterior.
Las sesiones largas de conexiones se archivan por segmentos. La exportación fija primero el rango del archivo y luego lee en flujo el archivo y la cola en memoria, manteniendo límites coherentes. Los valores ausentes, fallos y cancelaciones conservan sus estados.