Capítulo 2 — Redes y servicios de internet
Mapa de la lección
Lección 02 publicada. Mapa, ejemplo, EX004.
flowchart TD
N0["Resultados de aprendizaje"]
N1["2.1 El recorrido de la petición"]
N2["2.2 El papel de los protocolos"]
N3["2.3 Controles de pasarela"]
N4["2.4 Abuso de red"]
N5["Síntesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX004"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje"]
N1["2.1 El recorrido de la petición"]
N2["2.2 El papel de los protocolos"]
N3["2.3 Controles de pasarela"]
N4["2.4 Abuso de red"]
N5["Síntesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX004"]
[Resultados de aprendizaje]
|
v
[2.1 El recorrido de la petición]
|
v
[2.2 El papel de los protocolos]
|
v
[2.3 Controles de pasarela]
|
v
[2.4 Abuso de red]
|
v
[Síntesis]
|
v
[Ejemplo resuelto] --> [Ejercicio EX004]
Resultados de aprendizaje
Usted podrá (1) seguir una petición de IA a través de redes y protocolos; (2) explicar el papel de TLS, DNS y HTTP en los servicios de IA; (3) configurar controles de pasarela como la limitación de tasa; y (4) reconocer el abuso de los puntos de acceso de IA a nivel de red.
2.1 El recorrido de la petición
El navegador de un cliente resuelve el dominio de la tienda mediante DNS, abre una conexión TLS y envía una petición HTTP. La aplicación web llama a servicios internos por la red privada y llama a la API del proveedor del modelo por internet, de nuevo con TLS y una clave de API. Cada salto es un lugar donde autenticar, cifrar y registrar. En Ask Brightwell, el salto interno del orquestador a la herramienta de pedidos y el salto externo a la API del proveedor transportan datos de clientes, así que ambos necesitan TLS y registro. La clave del proveedor en esa llamada externa es una credencial como cualquier otra y debe permanecer en el servidor.
2.2 El papel de los protocolos
DNS asigna nombres a direcciones; si se secuestra, los usuarios pueden acabar en un asistente falso. TLS protege la confidencialidad y la integridad en tránsito y autentica a los servidores mediante certificados. HTTP transporta peticiones y respuestas; las respuestas en flujo continuo (server-sent events o WebSockets) son habituales en el chat y necesitan tiempos de espera para que las conexiones inactivas no se acumulen. Ask Brightwell transmite las respuestas al navegador en flujo continuo, de modo que un atacante que abre muchos flujos y nunca los lee puede acaparar las conexiones del servidor. Los tiempos de espera sobre los flujos inactivos los cierran, y la pasarela cuenta los flujos abiertos por sesión como uno de sus límites. Las comprobaciones de certificado en la llamada al proveedor también importan, porque la clave de API viaja en ella.
2.3 Controles de pasarela
Una pasarela de API o un proxy inverso se sitúa delante de los puntos de acceso de IA. Autentica a quienes llaman, impone un tamaño máximo de petición y aplica límites de tasa. Un cubo de tokens permite una tasa constante con ráfagas cortas: se atiende a los usuarios que se comportan bien mientras se recortan las avalanchas.
"""Lab R: token-bucket limits against unbounded consumption (synthetic).
Simulates 60 seconds of requests from a normal client and a flooding client
against a model endpoint with a per-client token bucket."""
import random
rng = random.Random(4)
def simulate(rate_per_s, burst, reqs):
tokens, last, ok = burst, 0.0, 0
for t in reqs:
tokens = min(burst, tokens + (t - last) * rate_per_s); last = t
if tokens >= 1: tokens -= 1; ok += 1
return ok
normal = sorted(rng.uniform(0, 60) for _ in range(90))
flood = sorted(rng.uniform(0, 60) for _ in range(3000))
for rate, burst in ((5, 20), (2, 10), (1, 5)):
print(f"limit={rate}/s burst={burst:2d} normal_served={simulate(rate, burst, normal):3d}/90 "
f"flood_served={simulate(rate, burst, flood):4d}/3000")
Salida esperada:
limit=5/s burst=20 normal_served= 90/90 flood_served= 319/3000
limit=2/s burst=10 normal_served= 90/90 flood_served= 129/3000
limit=1/s burst= 5 normal_served= 62/90 flood_served= 64/3000
El laboratorio de Jonas prueba exactamente este diseño, con una tasa de 2 peticiones por segundo y una ráfaga de 10, frente a una avalancha y a un conjunto de usuarios normales. La pasarela también rechaza los mensajes que superan una longitud fijada antes de que lleguen al orquestador, de modo que una sola petición enorme no puede consumir todo el presupuesto de tokens de una sesión.
2.4 Abuso de red
Los patrones de abuso incluyen avalanchas para elevar el coste, la extracción masiva de respuestas para copiar el comportamiento de un modelo (extracción del modelo) y claves de API robadas usadas desde redes inesperadas. Señales: tasas de peticiones por clave, geografías inusuales, muchas consultas distintas desde un mismo cliente. En Ask Brightwell, las señales útiles son las tasas de peticiones por sesión, el uso de tokens por cuenta y cuántas preguntas distintas hace un mismo cliente. Una clave de socio que de repente envía miles de llamadas de puntuación variadas a ReturnGuard es el patrón que más tarde resultó ser una extracción.
2.5 Ejemplo resuelto (caso sintético de Brightwell)
El punto de acceso de Ask Brightwell no tenía límite de tasa. Jonas ejecuta el laboratorio sobre una copia: a 2 peticiones por segundo con ráfaga 10, se atienden las 90 peticiones normales mientras solo pasan 129 de las 3000 peticiones de la avalancha. A 1 por segundo, los usuarios normales empiezan a fallar (62/90). Propone 2/s con ráfaga 10 por sesión, más un presupuesto diario de tokens por cuenta. Las cifras del laboratorio hacen concreto el compromiso. Un límite lo bastante holgado para atender todas las peticiones normales sigue reduciendo la avalancha a una pequeña fracción, mientras que reducir la tasa a la mitad empieza a hacer fallar a usuarios reales. Limitar por sesión y no por dirección evita también bloquear a clientes que comparten una red.
2.6 Errores y límites
- Limitar la tasa solo por IP (redes compartidas, botnets).
- Límites tan estrictos que bloquean a usuarios reales.
- Claves de API del proveedor en el código del front-end.
La propuesta de Jonas responde a cada uno. Limita por sesión y por cuenta y no por dirección, se eligió a partir de las mediciones del laboratorio de modo que las 90 peticiones normales siguieran atendiéndose, y mantiene la clave del proveedor en el servidor. Un límite que bloquea a usuarios reales empujaría al negocio a eliminarlo, así que medir ambos lados importa más que elegir una cifra estricta.
Ejercicios
- EX004 — Recorrido. Enumere cada salto de protocolo de una petición a Ask Brightwell y un control por salto. Rúbrica: 3 = DNS, TLS, HTTP, interno, API del proveedor, con controles; 2 = tres o cuatro; 1 = uno o dos; 0 = ninguno.
- EX005 — Laboratorio. Justifique con el laboratorio el límite elegido. Rúbrica: 3 = los normales se atienden por completo, la avalancha se reduce, un límite más estricto perjudica a los usuarios; 2 = dos; 1 = uno; 0 = erróneo.
- EX006 — Fuga de la clave. Una clave de API del proveedor aparece en el JavaScript del navegador. ¿Qué ocurre y cuál es la solución? Rúbrica: 3 = cualquiera puede usarla, coste y abuso; rotarla, llevarla al servidor, acotar su alcance; 2 = parcial; 1 = vago; 0 = ninguno.
Síntesis
Los puntos de acceso de IA son servicios de internet: proteja DNS, TLS y HTTP, ponga una pasarela delante y ajuste los límites de tasa para atender a los usuarios mientras se frena el abuso.
Siga estudiando — capítulo 02 de 30
← Capítulo 01 (borrador) · Índice de capítulos del curso · Capítulo 03 (borrador) →