Detecta qué consume ancho de banda en Windows (sin aplicaciones sospechosas)

Siempre hay alguien “descargando un archivo” y de algún modo tu llamada de Teams se convierte en una actuación muda.
Lo peor no es la lentitud: es la incertidumbre. ¿Es Windows Update? ¿OneDrive? ¿Una pestaña del navegador descontrolada?
¿O tu propio PC realizando tareas empresariales en segundo plano?

Así es como encuentras al culpable usando únicamente herramientas integradas de Windows. Sin instaladores misteriosos. Sin “aceleradores de red gratuitos”.
Solo lo que ya tienes—y la disciplina para interpretarlo correctamente.

Guía rápida de diagnóstico

Estás de guardia con tu propio portátil. No tienes tiempo para un seminario de filosofía de redes.
Aquí está el orden de operaciones que obtiene respuestas rápido con mínima fricción.

1) Confirma que es tu PC y no la red

• Si toda la casa/oficina está lenta, para. Tu equipo Windows no está “consumiendo ancho de banda”, el enlace de subida está saturado.
  Comprueba el estado del router/ISP primero.
• Si solo tu PC está lento: continúa.

2) Identifica el proceso principal por E/S de red

• Administrador de tareas → Procesos → ordenar por Red.
• Si es una aplicación normal (navegador, OneDrive, Teams): básicamente ya terminaste; decide si detenerla, limitarla o programarla.
• Si es Host de servicios o “Sistema”: ve al Monitor de recursos y a netstat para encontrar el servicio/conexión real.

3) Decide: ¿consumo de throughput o problema de latencia?

• Si algo está consumiendo 50–500 Mbps y tu llamada muere: consumo de throughput.
  Solución: detener/limitar/programar, o configurar conexión medida / límites de Delivery Optimization.
• Si la columna “Red” está baja pero todo “se siente” lento: busca DNS, pérdida de paquetes, bucles de autenticación de proxy o retransmisiones.
  El Monitor de recursos y los contadores ayudan aquí.

4) Asocia el tráfico a un extremo remoto

• Usa Monitor de recursos (Conexiones TCP) o netstat -b/netstat -ano.
• La IP/puerto remotos te dicen si hablas con el CDN de Microsoft, el proxy corporativo o algo más extraño.

5) Aplica la solución menos peligrosa

• Prefiere limitar y programar antes que matar procesos.
  El ancho de banda es un recurso compartido; la estabilidad es el verdadero SLO.
• Si es tráfico gestionado por la empresa (actualizaciones, agente endpoint): coordina en vez de hacer “whack-a-mole”.

Una cita que llevo años repitiendo, porque es el antídoto contra el pensamiento “estoy seguro de que es X”:
En operaciones, no te dan crédito por adivinar; te lo dan por medir.
(idea parafraseada atribuida a la ingeniería de calidad estilo Deming)

Primero, define la verdad de base (y no te engañes)

Las quejas sobre “ancho de banda” suelen significar una de tres cosas:

1. Saturación real: un proceso consume una porción grande de tu enlace de subida/bajada.
2. Inflación de latencia: retrasos DNS, bucles de proxy, pérdida de paquetes, reintentos Wi‑Fi, bufferbloat. Tu throughput puede estar bien.
3. Contención a nivel de aplicación: túnel VPN, inspección de agentes de seguridad u orquestación de actualizaciones que causan bloqueos.

Si no separas estos, “arreglarás” lo incorrecto. También disfrutarás del clásico corporativo:
alguien desactiva la VPN para “mejorar el rendimiento” y luego se pregunta por qué las aplicaciones internas no funcionan. Verdaderamente un misterio para la posteridad.

Tu objetivo es responder, con recibos:

• ¿Qué proceso está transfiriendo datos?
• ¿Qué servicio (si es un proceso host como svchost.exe)?
• ¿Qué extremo remoto (dominio/IP/puerto)?
• ¿Es continuo o intermitente?
• ¿El problema es de ancho de banda o de latencia/pérdida?

Tarea 1–2: Empieza con el Administrador de tareas (es mejor de lo que recuerdas)

Tarea 1: Ordena por Red en el Administrador de tareas

El Administrador de tareas no hace inspección profunda de paquetes, pero es la forma más rápida de encontrar culpables evidentes.
Si obtienes un comunicador principal claro aquí, no compliques el resto.

cr0x@server:~$ taskmgr.exe
...Task Manager opens. Go to Processes, click the Network column to sort...

Qué buscas:

• Un único proceso mostrando Mbps sostenidos. Navegadores, OneDrive, Teams, Steam, Windows Update son comunes.
• Si el principal es Host de servicios: … o Sistema, necesitas la siguiente herramienta para desambiguar.

Decisión:

• Si es una app de usuario: ciérrala, pausa la descarga o prográmala. Confirma la mejora.
• Si es un proceso host/sistema: procede al Monitor de recursos.

Tarea 2: Usa Historial de aplicaciones para “muerte por mil transferencias en segundo plano”

Algunos problemas de ancho de banda no son un gran flujo: son docenas de pequeños flujos en segundo plano. Historial de aplicaciones te da una vista más amplia.

cr0x@server:~$ cmd /c "start ms-settings:datausage"
...Settings opens at Data usage; inspect per-app usage for the last 30 days...

Qué significa la salida:

• Si una app tiene un uso sorprendentemente alto a lo largo del tiempo, es un contribuidor persistente, no un pico puntual.
• Si “Sistema” domina, probablemente estás viendo actualizaciones, Delivery Optimization o sobrecarga de VPN/proxy.

Decisión:

• Alto uso por OneDrive/Dropbox: revisa configuración de sincronización, sincronización selectiva, límites de subida.
• Alto uso por “Sistema”: evita conjeturas; identifica el servicio con Monitor de recursos y mapeo de servicios.

Tarea 3–4: Monitor de recursos para sockets por proceso y pistas de latencia

Monitor de recursos es la joya infrautilizada. Muestra procesos, conexiones y puertos en escucha en un solo lugar.
No es bonito. Es efectivo. Como un buen SRE.

Tarea 3: Abre Monitor de recursos directamente e inspecciona Red

cr0x@server:~$ resmon.exe
...Resource Monitor opens. Go to the Network tab...

Qué comprobar:

• Procesos con actividad de red: muestra tasas de envío/recepción por proceso.
• Actividad de red: detalles de archivos y endpoints (para algunos procesos).
• Conexiones TCP: la toma decisiva—dirección local/remota, puerto y latencia.

Decisión:

• Si un proceso tiene múltiples conexiones al mismo rango IP remoto (CDN), probablemente esté descargando actualizaciones/contenido.
• Si ves muchas conexiones de corta duración y alta latencia, sospecha de DNS/proxy/autenticación en lugar de throughput bruto.

Tarea 4: Filtra por un proceso sospechoso y anota sus endpoints remotos

En Monitor de recursos, marca la casilla junto al proceso sospechoso. Las tablas inferiores se filtran automáticamente.
Anota direcciones y puertos remotos.

cr0x@server:~$ cmd /c "echo Use Resource Monitor: tick the process checkbox; then read Remote Address/Port in TCP Connections."
Use Resource Monitor: tick the process checkbox; then read Remote Address/Port in TCP Connections.

Qué significa:

• Puerto remoto 443: HTTPS (la mayoría del tráfico moderno). Aquí verás IPs, no dominios.
• Puerto remoto 80: HTTP (más raro, a menudo legado o interno).
• Puerto remoto 53: DNS (si algo está saturando DNS, es una mala señal).
• Puerto remoto 123: NTP sync de tiempo (pequeño, pero frecuente).

Decisión:

• Si los endpoints remotos parecen de Microsoft/CDN y el proceso está relacionado con actualizaciones: salta a la sección de características de Windows.
• Si los endpoints parecen internos/proxy corporativo: sospecha de bucles de proxy, VPN o agentes de seguridad.

Tarea 5–6: netstat + mapeo PID (el clásico que aún funciona)

Cuando las interfaces gráficas mienten por omisión, netstat te da la verdad cruda de sockets. No es glamoroso, pero tampoco la producción.

Tarea 5: Lista conexiones establecidas con PID

cr0x@server:~$ cmd /c "netstat -ano | findstr ESTABLISHED"
TCP    192.168.1.50:51322   52.96.12.34:443      ESTABLISHED     4960
TCP    192.168.1.50:51340   13.107.6.171:443     ESTABLISHED     1348
TCP    192.168.1.50:51355   142.250.72.206:443   ESTABLISHED     17824

Qué significa la salida:

• La última columna es el PID. Ese es tu identificador para identificar el proceso propietario.
• Si ves muchas conexiones establecidas a muchas IPs remotas, el proceso podría ser un navegador, actualizador o herramienta de sincronización.

Decisión:

• Elige los PIDs principales y mapea a nombres de proceso.

Tarea 6: Mapea PID a proceso y línea de comandos

cr0x@server:~$ cmd /c "tasklist /fi "PID eq 4960" /v"
Image Name                     PID Session Name        Session#    Mem Usage Status          User Name          CPU Time Window Title
msedge.exe                     4960 Console                    1    350,000 K Running         CORP\alice         0:12:41  Project - Edge

Tasklist es suficiente para el nombre y una pista. Para la respuesta real, incluye la línea de comandos (especialmente para
svchost.exe, navegadores con múltiples perfiles y agentes empresariales).

cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance Win32_Process -Filter 'ProcessId=4960' | Select-Object ProcessId,Name,CommandLine | Format-List"
ProcessId  : 4960
Name       : msedge.exe
CommandLine: "C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe" --profile-directory=Default

Decisión:

• Si la línea de comandos apunta a un actualizador/programador: a menudo puedes pausarlo de forma limpia.
• Si es un agente corporativo: no lo mates de primeras. Identifica los controles de política y los horarios.

Tarea 7–9: PowerShell para adaptadores, rutas y el momento “¿por qué DNS va lento?”

Los “problemas” de ancho de banda frecuentemente provienen de la interfaz equivocada, la ruta equivocada o la resolución de nombres rota.
PowerShell te da evidencia repetible y copiable que puedes enviar a IT sin sonar como un conspiranoico.

Tarea 7: Comprueba qué interfaz está realmente en uso (y a qué velocidad de enlace)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapter | Sort-Object -Property Status,LinkSpeed -Descending | Format-Table -Auto Name,Status,LinkSpeed,MacAddress"
Name          Status  LinkSpeed   MacAddress
Ethernet      Up      1 Gbps      00-11-22-33-44-55
Wi-Fi         Down    0 bps       AA-BB-CC-DD-EE-FF

Qué significa:

• Si Ethernet está “Up” a 100 Mbps cuando esperabas 1 Gbps, puede haber un problema de negociación de cable/conmutador.
• Si Wi‑Fi está activo a una tasa baja, podrías estar atascado en 2.4 GHz, lejos del AP o sufriendo interferencias.

Decisión:

• Arregla la capa física/enlace antes de cazar procesos. Un enlace saturado de 100 Mbps hará que tareas de fondo normales parezcan criminales.

Tarea 8: Identifica servidores DNS y si estás usando algo extraño

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientServerAddress -AddressFamily IPv4 | Format-Table -Auto InterfaceAlias,ServerAddresses"
InterfaceAlias ServerAddresses
Ethernet        {10.10.0.10, 10.10.0.11}

Qué significa:

• DNS corporativo es normal en VPN. DNS público en un dispositivo corporativo puede ser normal o una violación de política. Conoce tu entorno.
• Incompatibilidad de DNS (servidores equivocados, servidores muertos) causa “todo va lento” sin alto uso de ancho de banda.

Decisión:

• Si los servidores DNS parecen incorrectos o inalcanzables, arregla DNS antes de culpar al “ancho de banda”.

Tarea 9: Mide la latencia y fallos de DNS rápidamente

cr0x@server:~$ powershell -NoProfile -Command "Measure-Command { 1..10 | ForEach-Object { Resolve-DnsName -Name microsoft.com -Type A | Out-Null } } | Select-Object TotalMilliseconds"
TotalMilliseconds
-----------------
842

Qué significa:

• Menos de un segundo para 10 búsquedas está bien en muchos entornos (con efectos de caché).
• Si esto toma varios segundos o lanza errores intermitentes, has encontrado un culpable de latencia que imita la falta de ancho de banda.

Decisión:

• Arregla DNS (alcanzabilidad de servidores, DNS dividido en VPN, política de resolutores) en lugar de intentar “limitar descargas”.

Tarea 10–12: Contadores de Monitor de rendimiento que realmente importan

PerfMon tiene opiniones sobre tus elecciones tipográficas, pero sigue siendo una de las mejores formas
de ver si estás saturando una interfaz o ahogado en retransmisiones y colas.

Tarea 10: Identifica el nombre de la interfaz usado por los contadores

cr0x@server:~$ powershell -NoProfile -Command "Get-Counter -ListSet 'Network Interface' | Select-Object -ExpandProperty Paths | Select-Object -First 8"
\\DESKTOP-7Q9K\Network Interface(Intel[R] Ethernet Connection)\Bytes Received/sec
\\DESKTOP-7Q9K\Network Interface(Intel[R] Ethernet Connection)\Bytes Sent/sec
\\DESKTOP-7Q9K\Network Interface(Intel[R] Ethernet Connection)\Output Queue Length
\\DESKTOP-7Q9K\Network Interface(Intel[R] Ethernet Connection)\Packets Outbound Errors
\\DESKTOP-7Q9K\Network Interface(Intel[R] Ethernet Connection)\Packets Received Errors

Qué significa:

• Las instancias de contador incluyen la cadena del modelo del adaptador. Necesitas la correcta si tienes VPN, Wi‑Fi, Ethernet o switches virtuales.

Decisión:

• Elige la interfaz relevante y muestrea algunos contadores clave durante la ventana “está lento”.

Tarea 11: Muestra bytes/sec y longitud de cola por 30 segundos

cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\Network Interface(Intel[R] Ethernet Connection)\Bytes Total/sec','\Network Interface(Intel[R] Ethernet Connection)\Output Queue Length' -SampleInterval 1 -MaxSamples 10 | Select-Object -ExpandProperty CounterSamples | Select-Object Path,CookedValue | Format-Table -Auto"
Path                                                                 CookedValue
----                                                                 -----------
\\...\Bytes Total/sec                                                8234512
\\...\Output Queue Length                                            0
\\...\Bytes Total/sec                                                9123301
\\...\Output Queue Length                                            0

Qué significa:

• Bytes Total/sec te indica el throughput real. Convierte a Mbps aproximadamente: bytes/sec × 8 ÷ 1,000,000.
• Output Queue Length persistentemente por encima de 0 puede indicar congestión/problemas de buffer (el contexto importa en drivers modernos).

Decisión:

• Si estás cerca de la capacidad del enlace durante largos periodos, necesitas una decisión de política de ancho de banda (limitar/programar), no una caza de brujas.
• Si hay colas altas pero throughput bajo, sospecha problemas de controlador, reintentos Wi‑Fi o congestión aguas arriba.

Tarea 12: Observa retransmisiones TCP (pérdida que se hace pasar por “internet lento”)

cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\TCPv4\Segments Retransmitted/sec','\TCPv4\Segments/sec' -SampleInterval 1 -MaxSamples 10 | Select-Object -ExpandProperty CounterSamples | Group-Object Path | ForEach-Object { $_.Group | Select-Object -First 1 } | Format-Table -Auto"
Path                                   CookedValue
----                                   -----------
\\DESKTOP-7Q9K\TCPv4\Segments/sec       18500
\\DESKTOP-7Q9K\TCPv4\Segments Retransmitted/sec 240

Qué significa:

• Las retransmisiones ocurren. Muchas retransmisiones, de forma consistente, significan pérdida o congestión severa. Eso mata las aplicaciones interactivas.
• Si las retransmisiones aumentan en Wi‑Fi pero no en Ethernet, tienes al culpable sin culpar a Windows Update.

Decisión:

• Problema de pérdida: cambia el medio (Ethernet), mejora la señal, reduce interferencias, actualiza driver/firmware, revisa MTU del VPN.

Los sospechosos habituales: Windows Update, Delivery Optimization, OneDrive, Store, Defender

Si trabajas en una empresa, Windows no es “solo un SO”. Es una plataforma con un sistema de distribución de contenido,
protección endpoint, reporte de cumplimiento y funciones de sincronización. Esas no son opcionales en muchos entornos.
Tu trabajo es hacerlas predecibles.

Delivery Optimization (DoSvc): peer-to-peer y “¿por qué mi subida está ocupada?”

Delivery Optimization es la función integrada de Windows para distribuir contenido. Puede descargar actualizaciones desde Microsoft
y, según la política, desde pares en tu LAN o incluso internet. El lado de subida sorprende a la gente.

cr0x@server:~$ powershell -NoProfile -Command "Get-Service DoSvc | Format-List Name,Status,StartType,DisplayName"
Name       : DoSvc
Status     : Running
StartType  : Manual
DisplayName: Delivery Optimization

Qué significa:

• Si está en ejecución durante una ralentización, podría estar moviendo contenido activamente.
• Inicio manual no significa “inactivo”. Windows lo inicia cuando quiere.

Decisión:

• Si estás en un entorno corporativo, no lo desactives a ciegas—la política puede depender de ello. Limítalo en su lugar.

Para inspeccionar el comportamiento de Delivery Optimization (compatible e integrado):

cr0x@server:~$ powershell -NoProfile -Command "Get-DeliveryOptimizationStatus | Select-Object -First 5 | Format-Table -Auto"
FileId                               SourceURL                          BytesDownloaded BytesUploaded PeerCaching
------                               ---------                          -------------- ------------- -----------
{A1B2C3D4-...}                        https://...                        104857600       5242880       True

Qué significa:

• Muestra descargas/subidas atribuibles a Delivery Optimization.
• Si BytesUploaded es significativo y tienes un enlace de subida limitado, esa es la respuesta a “¿por qué la subida está ocupada?”.

Decisión:

• Establece límites de ancho de banda mediante Configuración o política. Si posees el dispositivo, usa Configuración. Si IT lo gestiona, solicita un cambio de política.

Windows Update (wuauserv): descargas grandes, mal momento

cr0x@server:~$ powershell -NoProfile -Command "Get-Service wuauserv,BITS | Format-Table -Auto Name,Status,StartType,DisplayName"
Name     Status  StartType DisplayName
----     ------  --------- -----------
wuauserv Running Manual    Windows Update
BITS     Running Manual    Background Intelligent Transfer Service

Qué significa:

• BITS es un servicio de transferencia “educado”, pero “educado” es contextual. Aún puede afectar una llamada en un enlace pequeño.
• Windows Update también usará Delivery Optimization según la configuración/política.

Decisión:

• Configura Horas activas correctamente y considera conexión medida si estás en un hotspot.
• En empresa: garantiza anillos de actualización y ventanas de mantenimiento, o te encontrarás con picos aleatorios diurnos.

OneDrive: las tormentas de sincronización existen

OneDrive suele comportarse hasta que no lo hace: movimientos grandes de carpetas, activos CAD, archivos PST,
o un usuario “organizando” una carpeta compartida moviéndola de sitio.

cr0x@server:~$ powershell -NoProfile -Command "Get-Process OneDrive -ErrorAction SilentlyContinue | Select-Object Name,Id,CPU,Path | Format-Table -Auto"
Name    Id    CPU Path
----    --    --- ----
OneDrive 7324  88 C:\Users\alice\AppData\Local\Microsoft\OneDrive\OneDrive.exe

Qué significa:

• Si OneDrive está activo y el Administrador de tareas muestra uso de red, probablemente esté sincronizando.

Decisión:

• Pausa la sincronización durante llamadas. Configura límites de subida/descarga si estás frecuentemente limitado.

Tienda Microsoft / actualizaciones de aplicaciones

Las actualizaciones de apps pueden ejecutarse silenciosamente y repetirse, especialmente después de imaging o cuando muchas apps se actualizan a la vez.

cr0x@server:~$ powershell -NoProfile -Command "Get-Service InstallService | Format-List Name,Status,StartType,DisplayName"
Name       : InstallService
Status     : Running
StartType  : Manual
DisplayName: Microsoft Store Install Service

Decisión:

• Si las actualizaciones de la Tienda son un problema recurrente durante el día, desactiva la actualización automática por política (empresa) o ajusta la configuración de la Tienda (personal).

Microsoft Defender y herramientas de seguridad: escaneos pueden activar red

Defender en sí no suele ser un gran consumidor de ancho de banda, pero los conjuntos de seguridad pueden hacer búsquedas en la nube, comprobaciones de reputación
y telemetría. El “culpable” puede ser un agente endpoint corporativo en lugar de Windows.

cr0x@server:~$ powershell -NoProfile -Command "Get-Process | Where-Object { $_.ProcessName -match 'MsMpEng|Sense|Crowd|Carbon|Sentinel' } | Select-Object ProcessName,Id,CPU | Sort-Object CPU -Descending | Format-Table -Auto"
ProcessName Id    CPU
----------- --    ---
MsMpEng     4100  120

Decisión:

• Si el agente hace trabajo pesado durante horario laboral, la solución es programarlo y definir políticas—no jugar a matar procesos.

Broma #1: Si instalas un “optimizador de ancho de banda”, tu PC irá más rápido—directo a un nuevo ticket de incidente.

Cuando el culpable es svchost.exe: rompe la máscara con seguridad

svchost.exe es un host de servicios, no un “programa” en el sentido de usuario. Muchos servicios de Windows se ejecutan dentro de él.
Si svchost está consumiendo ancho de banda, tu misión es identificar qué servicio dentro es el responsable.

Tarea: Mapea el PID de svchost a los servicios alojados

cr0x@server:~$ cmd /c "tasklist /svc /fi "imagename eq svchost.exe""
Image Name                     PID Services
svchost.exe                   1348 BITS, wuauserv
svchost.exe                   1720 DoSvc
svchost.exe                   1020 Dhcp, NlaSvc

Qué significa:

• Ahora puedes conectar los puntos: si PID 1720 está hablando con muchos endpoints 443 remotos y aloja DoSvc, tienes una historia de Delivery Optimization.
• Si es DHCP/NLA, normalmente no consume mucho ancho de banda, pero puede indicar inestabilidad de red (lo que genera otro tráfico).

Decisión:

• Para BITS/wuauserv/DoSvc: aplica límites y programación de actualizaciones/DO.
• Para servicios extraños: investiga qué hacen antes de deshabilitarlos. “Desactivar servicios al azar” no es estrategia; es un hobby.

Tres mini-historias corporativas desde el campo

Mini-historia 1: El incidente causado por una suposición equivocada

Una empresa mediana desplegó una nueva imagen de Windows 11 a unos cientos de portátiles. Una semana después, la cola de soporte se llenó de
tickets “Wi‑Fi inutilizable”, mayormente entre las 9–11 AM. La primera suposición fue clásica: “El ISP está teniendo una mala semana.”
Esa suposición duró hasta que alguien notó que la oficina de al lado (otro inquilino, mismo ISP) estaba bien.

La segunda suposición fue más confiada: “Es Teams.” Los usuarios estaban en llamadas, las llamadas eran malas, así que la app fue culpada.
La gente recomendó apagar vídeo HD y usar solo audio. Eso ayudó un poco, lo que hizo que todos se sintieran ingeniosos,
pero no abordó la raíz y empeoró las reuniones. Una mitigación parcial sigue siendo un fracaso si dejas de investigar.

La causa real apareció cuando alguien abrió Monitor de recursos en una máquina afectada:
svchost.exe estaba moviendo muchos datos, y netstat mostró sesiones 443 de larga duración a rangos IP de Microsoft.
Mapear PID a servicios apuntó a DoSvc y BITS. Delivery Optimization estaba configurado (por “valores predeterminados útiles”)
para permitir subidas a pares en la LAN. En una oficina con enlaces de subida delgados y muchas máquinas recientemente imagenadas, eso significó churn constante.

La solución no fue desactivar actualizaciones. Fue configurar Delivery Optimization a solo LAN (o desactivar la subida a pares),
limitar ancho de banda de fondo durante horas laborales y repartir descargas en ventanas de mantenimiento.
Las llamadas volvieron a la normalidad. El soporte dejó de diagnosticar el clima.

La lección: “problema del ISP” es una suposición reconfortante porque no requiere acción. También suele estar equivocada.

Mini-historia 2: La optimización que salió mal

Un equipo de la empresa intentó reducir el uso de WAN para sitios remotos. Su idea brillante:
forzar caching agresivo y distribución P2P de actualizaciones en todas partes. La intención era válida—los costes de egress CDN pesan,
y Windows soporta distribución distribuida. El problema fue la restricción que ignoraron: asimetría de enlace.

En sitios pequeños, las descargas eran aceptables pero la subida era mínima. La subida de pares significó que el momento en que un PC tenía una actualización,
se convertía en un mini servidor de contenido en una conexión apenas adecuada para enviar adjuntos. Los usuarios se quejaban de que “internet muere”
cuando el portátil de su colega estaba encendido. Ese colega no estaba haciendo nada malo; era víctima de la política.

El equipo de red respondió añadiendo reglas QoS priorizando voz. Las reglas ayudaron, pero también introdujeron complejidad y
comportamiento inconsistente entre modelos de hardware. Algunos AP respetaban las marcas, otros no. Mientras tanto, los endpoints seguían subiendo.
La “optimización” se convirtió en un impuesto operativo continuo.

Finalmente, reemplazaron la política global por ajustes por niveles: sitios grandes podían usar distribución entre pares; sitios pequeños no.
También limitaron la subida agresivamente y aplicaron ventanas de actualización. El consumo no desapareció, pero se volvió predecible.
Lo predecible vence a lo “sorprendente” siempre.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Un departamento de finanzas tenía un proceso de cierre mensual. Mismo día cada mes, misma energía frenética, mismas quejas de “la red está lenta”.
El equipo de TI no entró en pánico; tenían un hábito aburrido: capturar una línea base ligera cada semana usando contadores integrados
y un script corto de PowerShell almacenado en un runbook compartido.

Cuando llegó la queja, ya sabían cómo se veía lo “normal”: bytes/sec típicos en la interfaz principal,
retransmisiones típicas en Wi‑Fi y los servicios de fondo principales. También tenían una lista que empezaba con:
“¿Estamos saturados, o la latencia es alta?” La respuesta fue inmediata—el throughput no era tan alto, pero las retransmisiones se dispararon.

Recorrieron el espacio y encontraron un switch no gestionado nuevo enchufado en un puerto de uplink que creó un bucle.
La red se estaba ahogando en tráfico broadcast y reintentos, no en “apps comilonas”. Retiraron el switch,
las retransmisiones bajaron y todo se recuperó. Nada de depuración heroica. Solo línea base + método.

Ese es el punto de la práctica aburrida: acorta los problemas emocionantes.

Datos interesantes y contexto histórico

• PerfMon es anterior a la mayoría de herramientas de “observabilidad moderna”. Los contadores de rendimiento de Windows existen desde la era NT y siguen siendo de primera clase.
• BITS fue diseñado para transferencias “educadas”. Intenta usar ancho de banda ocioso, pero “ocioso” no es una verdad universal—especialmente en enlaces asimétricos.
• La consolidación en svchost fue una estrategia de recursos. Alojar múltiples servicios redujo overhead, pero dificultó la atribución hasta que llegaron mejores herramientas.
• Delivery Optimization es esencialmente un sistema de distribución de contenido. No es nuevo en concepto—CDNs y distribución entre pares existen desde hace décadas—pero ahora está integrado en el SO.
• Windows ha separado durante mucho tiempo apps de usuario de la infraestructura de servicios. Por eso aparecen “Sistema” y “Host de servicios”: mucho trabajo ocurre por debajo de la capa de la app.
• Las retransmisiones TCP son el asesino oculto de los enlaces “rápidos”. Puedes tener buena señal y aun así sufrir interferencias o bufferbloat.
• Las conexiones medidas se añadieron porque la gente seguía recibiendo facturas sorpresa. Windows aprendió, lentamente, que no todas las redes son ilimitadas.
• Netstat es más antiguo que la mayoría de los problemas que diagnostica. Sigue siendo útil porque los sockets son la fuente de verdad para conexiones.

Errores comunes: síntoma → causa raíz → solución

Esta sección es deliberadamente directa. La mayoría de la resolución de ancho de banda se tuerce porque la gente trata síntomas como diagnósticos.

1) “Mi calidad de llamada es terrible” → “consumo de ancho de banda” → En realidad pérdida/reintentos Wi‑Fi

• Síntoma: Las llamadas se entrecortan mientras el Administrador de tareas muestra bajo uso de red.
• Causa raíz: Pérdida/retransmisiones, interferencia, driver malo o un AP congestionado.
• Solución: Revisa contadores de retransmisiones TCP; prueba con Ethernet; actualiza el driver Wi‑Fi; acércate al AP; cambia a 5 GHz/6 GHz; revisa problemas de MTU en VPN.

2) “La subida está a tope pero no estoy subiendo nada” → Delivery Optimization subiendo a pares

• Síntoma: Uplink ocupado, especialmente después del patch Tuesday o imaging de dispositivos nuevos.
• Causa raíz: DoSvc subiendo contenido de actualizaciones a pares (dictado por política).
• Solución: Usa Get-DeliveryOptimizationStatus; limita la subida; desactiva subida a pares donde no corresponda; aplica ventanas de actualización.

3) “Todo va lento” → “El ISP es malo” → En realidad DNS/bucles de proxy

• Síntoma: Páginas web se quedan colgadas al inicio, las descargas no aceleran, apps se sienten pegajosas.
• Causa raíz: Respuestas DNS lentas, DNS dividido roto en VPN, bucles de autenticación de proxy generando solicitudes pequeñas repetidas.
• Solución: Mide el tiempo DNS con PowerShell; verifica servidores DNS; revisa configuración de proxy y credenciales; consulta el Visor de eventos si hace falta.

4) “svchost está usando ancho de banda” → “Mátenlo” → Luego Windows se pone raro

• Síntoma: Host de servicios en la cima de la columna Red.
• Causa raíz: Uno de muchos servicios alojados (BITS/wuauserv/DoSvc) haciendo trabajo legítimo.
• Solución: Mapea PID a servicios con tasklist /svc; ajusta configuraciones/políticas; evita matar hosts críticos.

5) “Cubriremos el ancho de banda con QoS y asunto resuelto” → La optimización sale mal

• Síntoma: Algunos usuarios mejoran, otros empeoran; el comportamiento difiere según dispositivo/AP.
• Causa raíz: QoS aplicado de forma inconsistente, o límites sobre la clase de tráfico equivocada; asimetría de uplink ignorada.
• Solución: Empieza por atribución en endpoints y programación sensata; luego aplica QoS como control dirigido, no como sustituto del diagnóstico.

Listas de verificación / plan paso a paso

Checklist A: “Algo está consumiendo ancho de banda ahora mismo” (10 minutos)

1. Administrador de tareas → ordenar por Red. Anota los 3 procesos principales.
2. Abre Monitor de recursos → pestaña Red → filtra proceso sospechoso → anota IPs/puertos remotos.
3. Ejecuta netstat -ano y mapea los PIDs principales a procesos/líneas de comando.
4. Si es svchost.exe: mapea PID a servicios usando tasklist /svc.
5. Si es relacionado con actualizaciones: revisa DoSvc/BITS/wuauserv y estado de Delivery Optimization.
6. Aplica el control menos riesgoso: pausa sincronización, pausa actualizaciones temporalmente, configura conexión medida o limita DO.

Checklist B: “Se siente lento, pero los números de ancho de banda son bajos” (15 minutos)

1. Comprueba adaptador y velocidad de enlace (Get-NetAdapter).
2. Mide rendimiento DNS (Resolve-DnsName en bucle + Measure-Command).
3. Revisa contadores de retransmisiones TCP (Get-Counter).
4. Si estás en Wi‑Fi: prueba con Ethernet o hotspot para aislar problemas RF vs upstream.
5. Si estás en VPN: prueba política de split tunneling y servidores DNS; revisa síntomas de MTU (sitios cargan parcialmente, subidas grandes se atascan).

Checklist C: “Evitar que vuelva a ocurrir” (continuo)

1. Establece ventanas de actualización/horas activas realistas.
2. Configura límites de subida de Delivery Optimization apropiados para tu enlace de subida.
3. Configura alcance de sincronización de OneDrive (sincronización selectiva) y límites de ancho de banda.
4. Baselina contadores clave semanalmente: bytes/sec, retransmisiones/sec, tasa de enlace Wi‑Fi.
5. Documenta los “principales consumidores” esperados en tu entorno (agente endpoint, cliente VPN, parcheo).

Broma #2: La red nunca está “caída”. Simplemente está tomando un descanso profesional no programado.

Más tareas prácticas (con comandos, significado y decisiones)

Ya tienes 12 tareas arriba. Aquí hay otras que rinden en entornos complicados—especialmente builds corporativos.
Úsalas cuando las comprobaciones obvias no den una respuesta limpia.

Tarea: Mostrar conexiones TCP activas con nombre del proceso propietario (requiere admin para -b)

cr0x@server:~$ cmd /c "netstat -abno | more"
...Shows connections plus the executable involved; may prompt for elevation...

Qué significa: -b añade el nombre del binario. Esto puede revelar qué ejecutable auxiliar está haciendo conexiones.

Decisión: Si el binario es inesperado (actualizador, helper, agente), localiza su app padre y revisa su programación/configuración.

Tarea: Comprobar qué procesos están en escucha (útil para “¿por qué este puerto está abierto?”)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetTCPConnection -State Listen | Select-Object -First 10 | Format-Table -Auto LocalAddress,LocalPort,OwningProcess"
LocalAddress LocalPort OwningProcess
------------ --------- -------------
0.0.0.0      445       4
0.0.0.0      135       988
127.0.0.1    49664     1020

Qué significa: Los puertos en escucha no son uso de ancho de banda, pero ayudan a identificar servicios (SMB, RPC, proxies locales) que pueden correlacionarse con tráfico.

Decisión: Si ves un proxy local o un listener inusual, comprueba si tu navegador/VPN/pila de seguridad está tunelizando tráfico a través de él.

Tarea: Mapear un PID propietario de Get-NetTCPConnection a un proceso

cr0x@server:~$ powershell -NoProfile -Command "Get-Process -Id 988 | Select-Object Id,ProcessName,Path | Format-List"
Id          : 988
ProcessName : svchost
Path        : C:\Windows\System32\svchost.exe

Decisión: Si es svchost, mapea a servicios (tasklist /svc) antes de tocar nada.

Tarea: Comprobación rápida de rutas (ruta equivocada = lentitud extraña)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetRoute -AddressFamily IPv4 | Sort-Object RouteMetric | Select-Object -First 12 | Format-Table -Auto DestinationPrefix,NextHop,InterfaceAlias,RouteMetric"
DestinationPrefix NextHop     InterfaceAlias RouteMetric
----------------- -------     -------------- -----------
0.0.0.0/0         192.168.1.1 Ethernet        25
10.0.0.0/8        10.8.0.1    VPN             5

Qué significa: Los metrics de ruta deciden a dónde va el tráfico. Rutas VPN con métricas bajas pueden tirar todo el tráfico por un túnel restringido.

Decisión: Si tu ruta por defecto pasa por VPN inesperadamente, revisa configuración/política del VPN; no la “arregles” borrando rutas al azar.

Tarea: Comprobar proxy WinHTTP (a menudo difiere del proxy del navegador)

cr0x@server:~$ cmd /c "netsh winhttp show proxy"
Current WinHTTP proxy settings:

    Proxy Server(s) : 10.10.0.20:8080
    Bypass List     : (none)

Qué significa: Algunos servicios usan la configuración de proxy WinHTTP. Un proxy mal configurado puede crear reintentos y lentitud.

Decisión: Si el proxy es incorrecto/obsoleto, arréglalo vía política o reinícialo (en entornos gestionados, coordina con IT).

Tarea: Mostrar detalles del enlace Wi‑Fi (señal/tasas indicativas)

cr0x@server:~$ cmd /c "netsh wlan show interfaces"
    Name                   : Wi-Fi
    State                  : connected
    Signal                 : 68%
    Receive rate (Mbps)    : 433.3
    Transmit rate (Mbps)   : 144.4

Qué significa: Una tasa de transmisión baja puede perjudicar llamadas y subidas incluso si las descargas parecen bien.

Decisión: Si las tasas son bajas o fluctuantes, trátalo como un problema RF: congestión de canal, distancia, interferencia.

Preguntas frecuentes

1) ¿Puedo encontrar uso de ancho de banda por proceso sin instalar nada?

Sí. Usa Administrador de tareas (columna Red) para una vista rápida, Monitor de recursos para conexiones y netstat + mapeo PID para atribución.

2) ¿Por qué “Host de servicios” usa ancho de banda en lugar de un nombre de app normal?

Porque muchos servicios de Windows se ejecutan dentro de svchost.exe. Usa tasklist /svc para mapear PID a servicios específicos.

3) ¿Es seguro desactivar BITS o Windows Update para detener el uso de ancho de banda?

Detener temporalmente un servicio puede ser un paso de diagnóstico, pero desactivar la infraestructura de actualizaciones a largo plazo es un riesgo de seguridad.
Prefiere programar, limitar y ventanas de actualización adecuadas.

4) ¿Cuál es la forma más rápida de decir si el problema es saturación de ancho de banda vs latencia?

Revisa throughput de interfaz (PerfMon Bytes Total/sec) y revisa retransmisiones. Throughput alto cerca de la capacidad indica saturación.
Retransmisiones altas con throughput moderado indican pérdida/latencia.

5) ¿Por qué mi subida está ocupada cuando “solo estoy descargando actualizaciones”?

Delivery Optimization puede subir contenido a pares. Confirma con Get-DeliveryOptimizationStatus y ajusta límites/política de subida.

6) Administrador de tareas muestra bajo uso de red, pero los sitios tardan en empezar a cargar. ¿Por qué?

A menudo latencia DNS, problemas de proxy o bucles de autenticación. Mide DNS con repetidos Resolve-DnsName y revisa la configuración de proxy WinHTTP.

7) ¿Puede Windows limitar el ancho de banda de fondo sin herramientas de terceros?

Sí. Usa configuraciones/políticas de Delivery Optimization y conexiones medidas. Muchos servicios Microsoft respetan esos controles.

8) ¿Cómo identifico a qué servidores remotos habla un proceso?

Monitor de recursos y netstat -ano muestran IPs y puertos remotos. Traducir IP a nombre no siempre es fiable por CDNs variables,
pero el rango IP y el mapeo de servicios suelen ser suficientes para decidir.

9) ¿El tráfico “Sistema” siempre es Windows Update?

No. “Sistema” puede incluir actividad de la pila de red, transferencias SMB, drivers VPN y otros componentes a nivel kernel.
Usa tablas de conexión y mapeo de servicios en lugar de asumir.

10) ¿Qué debo enviar a IT si necesito ayuda?

Proporciona: marca temporal, interfaz (Wi‑Fi/Ethernet/VPN), proceso principal por Red, PIDs relevantes, IPs/puertos remotos y si las retransmisiones están elevadas.
Eso es un ticket con el que alguien puede trabajar realmente.

Siguientes pasos que puedes hacer hoy

1. Cuando suceda la ralentización, captura dos capturas: Administrador de tareas ordenado por Red, Monitor de recursos Conexiones TCP filtrado por el proceso principal.
   La evidencia gana sobre las sensaciones.
2. Ejecuta netstat -ano y mapea los PIDs principales. Si es svchost, mapea a servicios con tasklist /svc.
3. Si las actualizaciones son el culpable, no entres en guerra con el parcheo. Configura Horas activas, ajusta Delivery Optimization y limita subidas en enlaces restringidos.
4. Si el uso es bajo pero la lentitud alta, trátalo como problema de latencia/pérdida: revisa tasas Wi‑Fi y retransmisiones TCP.
5. Anota cómo se ve lo “normal” en tu máquina una vez. Las líneas base son baratas. Las interrupciones no lo son.

El truco entero es negarse a adivinar. Windows te da suficiente observabilidad integrada para identificar al culpable,
el servicio detrás del culpable y el tipo de solución que no boomerangeará en el incidente de mañana.