Mapa de la lección
Lección 36 publicada. Mapa, ejemplo, EX071.
flowchart TD
N0["Resultados de aprendizaje y conexión"]
N1["36.1 Colas por todas partes"]
N2["36.2 El coste de la seguridad"]
N3["36.3 Carga de pico, degradada y de ataque"]
N4["36.4 Escala"]
N5["36.6 Actividad práctica: Lab 13"]
N6["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX071"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje y conexión"]
N1["36.1 Colas por todas partes"]
N2["36.2 El coste de la seguridad"]
N3["36.3 Carga de pico, degradada y de ataque"]
N4["36.4 Escala"]
N5["36.6 Actividad práctica: Lab 13"]
N6["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX071"]
[Resultados de aprendizaje y conexión]
|
v
[36.1 Colas por todas partes]
|
v
[36.2 El coste de la seguridad]
|
v
[36.3 Carga de pico, degradada y de ataque]
|
v
[36.4 Escala]
|
v
[36.6 Actividad práctica: Lab 13]
|
v
[Síntesis del capítulo]
|
v
[Ejemplo resuelto] --> [Ejercicio EX071]
Resultados de aprendizaje y conexión
Al terminar este capítulo, usted podrá (1) modelar el rendimiento, la latencia y la utilización con la teoría de colas y la ley de Little; (2) estimar el coste en desempeño de los controles de seguridad; (3) dimensionar sistemas para condiciones de pico y degradadas, incluida la carga provocada por ataques; y (4) diseñar para la escala —flotas de miles de dispositivos— en la gestión de claves, la supervisión y las actualizaciones. Se apoya en los capítulos 11, 19 y 34 y prepara el capítulo 41.
36.1 Colas por todas partes
Los mensajes esperan en colas en pasarelas, servidores y enlaces. La ley de Little, $L = \lambda W$, relaciona el número medio en un sistema $L$, la tasa de llegadas $\lambda$ y el tiempo medio en el sistema $W$, en condiciones muy generales. Para el modelo sencillo M/M/1 (llegadas aleatorias, servicio exponencial, un servidor con tasa de servicio $\mu$), la utilización es $\rho = \lambda/\mu$ y $W = 1/(\mu - \lambda)$. El retardo crece sin límite cuando $\rho \to 1$: con una utilización del 80 %, el mensaje medio pasa cinco tiempos de servicio en el sistema; con el 96 %, veinticinco. Dimensione de modo que la utilización de pico se mantenga muy por debajo de 1, habitualmente por debajo de 0,7 en los caminos críticos para la latencia.
36.2 El coste de la seguridad
Todo control cuesta algo: bytes (la sobrecarga de 22 bytes del Lab 8), CPU (cálculo de MAC, negociaciones TLS), latencia (decisiones de política, inspección) y tiempo de los operadores (reautenticación, aprobaciones). Mídalos en el banco. Los costes suelen ser pequeños en comparación con los tiempos de ida y vuelta de la red, pero importan en enlaces limitados (radio de bajo ancho de banda), en dispositivos limitados (microcontroladores pequeños) y a escala. En el TMRP, los costes medidos incluyen los veintidós bytes adicionales por trama, el cálculo del MAC de cada mensaje en el verificador del lado del SCADA y el tiempo de los operadores para la aprobación por dos personas de los cambios masivos de consignas. Ninguno es grande, pero el límite de rendimiento del verificador es lo que el ejemplo resuelto debe dimensionar.
36.3 Carga de pico, degradada y de ataque
Dimensione para la peor carga creíble: avalanchas de alarmas durante tormentas, ráfagas de reconexión tras cortes (capítulo 34), recuperación del retraso tras una conmutación por error e inundaciones deliberadas. Un atacante que puede enviar tráfico a una pasarela puede llevar la utilización hacia 1 y retrasar las alarmas legítimas; las defensas incluyen límites de frecuencia por origen, colas con prioridad para las alarmas, rechazo temprano del tráfico no autenticado (verifique primero la comprobación barata) y márgenes de capacidad. En el TMRP, la ráfaga de reconexión encontrada en las pruebas de integración es el ejemplo más claro, y la cola con prioridad para las alarmas del verificador es la defensa elegida en el ejemplo resuelto.
36.4 Escala
A escala de flota, los procesos manuales fallan. El registro, la rotación y la revocación de claves deben automatizarse, con auditoría; la supervisión debe agregar y priorizar; las actualizaciones deben hacerse por etapas y ser observables; el inventario debe conciliarse de forma continua. Un procedimiento que lleva 30 minutos por dispositivo consume 500 horas de trabajo del personal, unos tres meses de un ingeniero a tiempo completo, para mil dispositivos. La LRWA tiene hoy solo 42 estaciones de campo, pero el mismo diseño puede usarse más adelante para una flota mucho mayor, de modo que el TMRP automatiza desde el principio los registros de alta y rotación de claves, en lugar de depender de una hoja de cálculo mantenida por un único ingeniero.
36.5 Ejemplo resuelto: dimensionamiento de la pasarela (sintético)
El verificador del lado del SCADA puede procesar 50 mensajes/s. En régimen estacionario, las 42 estaciones de la LRWA generan unos 20 mensajes/s ($\rho = 0.4$, $W \approx 33$ ms). Durante una tormenta, las alarmas elevan las llegadas a 40/s ($\rho = 0.8$, $W = 100$ ms, unos 4 mensajes en el sistema). A 48/s, $W = 500$ ms y hay de media 24 mensajes en el sistema. El sondeo secuencial de 42 estaciones con 180 ms de ida y vuelta más el tiempo de registros dura 7,8 s por ciclo; seis canales en paralelo lo reducen a 1,3 s. Decisiones: duplicar la capacidad del verificador hasta 100 mensajes/s para tener margen; cola con prioridad para las alarmas; notificación por excepción de las alarmas en lugar de esperar al sondeo.
36.6 Actividad práctica: Lab 13
# Lab 13 - is the telemetry gateway fast enough? M/M/1 and a polling cycle (synthetic, offline)
mu = 50.0 # messages/s the gateway can verify and forward
for lam in (20.0, 40.0, 45.0, 48.0):
rho = lam / mu; W = 1 / (mu - lam); L = lam * W
print(f"lambda={lam:>4} rho={rho:.2f} W={W*1000:6.1f} ms L={L:5.1f} msgs")
stations, regs_per_poll, rtt_ms, per_reg_ms = 42, 3, 180, 2
cycle = stations * (rtt_ms + regs_per_poll * per_reg_ms)
print(f"sequential polling cycle: {cycle/1000:.2f} s; with 6 parallel channels: {cycle/6/1000:.2f} s")
Salida esperada:
lambda=20.0 rho=0.40 W= 33.3 ms L= 0.7 msgs
lambda=40.0 rho=0.80 W= 100.0 ms L= 4.0 msgs
lambda=45.0 rho=0.90 W= 200.0 ms L= 9.0 msgs
lambda=48.0 rho=0.96 W= 500.0 ms L= 24.0 msgs
sequential polling cycle: 7.81 s; with 6 parallel channels: 1.30 s
Las cuatro primeras líneas muestran cómo el retardo crece con fuerza a medida que las llegadas se acercan a la capacidad del verificador, de cincuenta mensajes por segundo: a veinte mensajes por segundo, el mensaje medio espera aproximadamente un tercio de décima de segundo, mientras que a cuarenta y ocho espera medio segundo y hay dos docenas de mensajes en el sistema. Las líneas de sondeo muestran por qué la LRWA usa seis canales en paralelo: un ciclo secuencial de casi ocho segundos dejaría las alarmas esperando mucho antes de que llegaran al verificador.
36.7 Errores comunes y límites
- Dimensionar para la carga media.
- Ignorar que el retardo se dispara cerca de la utilización plena.
- Suponer que los costes de seguridad son despreciables sin medirlos en el dispositivo de destino.
- Procedimientos manuales que no escalan.
- Usar M/M/1 cuando las llegadas llegan en ráfagas o el servicio es determinista; trátelo como una primera aproximación.
El dimensionamiento del TMRP evita los dos primeros errores al dimensionar para la carga de tormenta y mantener el verificador duplicado muy por debajo de la utilización plena, y trata los resultados de colas como una primera aproximación que debe contrastarse con mediciones en el banco.
Ejercicios — capítulo 36
EX071 — Duplicar la capacidad. Objetivo: cuantificar el margen. Entradas: Lab 13 con $\mu = 100$. Pasos: calcule $\rho$, $W$ y $L$ a 20, 40 y 48 mensajes/s; compárelos con $\mu = 50$. Evidencia esperada: tabla. Rúbrica: 3 = valores correctos (p. ej., a 48/s: ρ = 0,48, W ≈ 19,2 ms, L ≈ 0,92) y conclusión; 2 = un error; 1 = una sola tasa; 0 = nada.
EX072 — Defensa contra inundaciones. Objetivo: diseñar frente a la carga de ataque. Entradas: un atacante en la red LTE puede enviar 1.000 tramas falsificadas/s al verificador. Pasos: proponga tres defensas en orden de coste y explique cómo protege cada una la latencia de las alarmas. Evidencia esperada: lista. Rúbrica: 3 = filtrado a nivel de red por origen o túnel, comprobaciones previas baratas antes del MAC, límites de frecuencia por origen y colas con prioridad, con razonamiento sobre dónde se descarta la carga; 2 = una sola defensa; 1 = solo «añadir capacidad»; 0 = nada.
Síntesis del capítulo
Las colas gobiernan la latencia; la ley de Little y los modelos de colas sencillos muestran que el retardo se dispara cuando la utilización se acerca a uno. Mida los costes de los controles de seguridad, dimensione para la carga de pico, degradada y de ataque con prioridad para las alarmas, y automatice desde el principio los procesos a escala de flota.