HTTP: requests, respuestas y códigos

Un protocolo es un conjunto de reglas que dos programas acuerdan para entenderse: quién habla primero, qué forma tiene cada mensaje y qué significa cada parte. HTTP (HyperText Transfer Protocol, protocolo de transferencia de hipertexto) nació con la web, a principios de los noventa (Tim Berners-Lee lo escribió en el CERN, el laboratorio europeo de física, entre 1989 y 1991), para pedir páginas. Hoy es el idioma por omisión entre programas: apps, APIs, servidores de modelos.

HTTP tiene dos papeles. El cliente pide y el servidor responde. Siempre empieza el cliente, y cada request recibe exactamente una respuesta. En C01, el backend es el cliente y el gateway, el servidor. Pero el gateway es cliente a su vez cuando le pide la predicción a Triton, el servidor del modelo. Ser cliente o servidor no depende de la máquina: depende de quién pide en esa conversación.

La request, letra por letra

Esto es lo que el backend le escribe al gateway por la conexión TCP:

POST /v1/classify?top_k=5 HTTP/1.1
Host: classifier.internal
Authorization: Bearer eyJhbGciOi...
Content-Type: image/jpeg
Content-Length: 214836
X-Request-ID: 9f2c41d0

(aquí siguen los 214,836 bytes de la foto)

Tiene cuatro partes, siempre en este orden:

1. 1

   La línea de la petición

   Request line. Tres cosas separadas por espacios: el método (POST, qué quieres hacer), la ruta con su query (/v1/classify?top_k=5, sobre qué) y la versión del protocolo (HTTP/1.1).

2. 2

   Los headers

   Una línea por dato, con la forma Nombre: valor. Dicen a quién va dirigida, quién la manda, qué trae el body y cuánto mide.

3. 3

   Una línea en blanco

   Marca dónde terminan los headers. Sin ella, el servidor no sabría si viene otro header o ya empezó la foto.

4. 4

   El body

   El cuerpo: los bytes de la foto, tal cual. Puede no haber body, como en una request que solo pide algo.

Cada línea termina con dos caracteres invisibles, \r\n: carriage return y line feed (retorno de carro y salto de línea), un recuerdo de las máquinas de escribir. La línea en blanco es justo eso: un \r\n pegado al de la línea anterior, \r\n\r\n. Cuando el servidor lo encuentra, sabe que lo que sigue es el body.

¿Y dónde termina el body? TCP entrega un chorro de bytes sin orillas: detrás de esta request podría venir otra por la misma conexión. Por eso el header Content-Length dice cuántos bytes mide: el gateway lee exactamente 214,836 y sabe que la request terminó.

La respuesta

El gateway contesta con la misma forma:

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 345
X-Request-ID: 9f2c41d0

{
  "model_version": "2026-09-01-resnet50-fp16",
  "predictions": [
    {"label": "Calzado > Tenis", "score": 0.91},
    {"label": "Calzado > Zapatos casuales", "score": 0.04},
    {"label": "Calzado > Botas", "score": 0.02},
    {"label": "Deportes > Calzado deportivo", "score": 0.01},
    {"label": "Calzado > Sandalias", "score": 0.01}
  ]
}

La primera línea ahora es la línea de estado (status line): la versión, un código de estado de tres cifras (200) y una frase para humanos (OK). Los programas solo leen el número. Después vienen los headers, la línea en blanco y el body: un texto en JSON, un formato para escribir datos con llaves, corchetes y comillas, con las cinco categorías y la versión del modelo que contestó. Los scores son de ejemplo; la forma es la del contrato de C01 en la Ronda.

HTTP no tiene memoria

Cada request es independiente: el servidor no recuerda la anterior. Por eso cada una trae todo lo que hace falta, hasta quién la manda (Authorization). Se dice que HTTP es stateless, sin estado.

Parece un defecto y es una ventaja. Si ninguna request depende de la anterior, cualquier copia del gateway puede atender cualquier request. C01 corre 5 copias, o pods, del gateway, y el reparto entre ellas no tiene que fijarse en quién habló antes con quién.

Pruébalo: un servidor y una request de verdad

La biblioteca estándar de Python trae http.server, un servidor de HTTP pequeño. Sirve para aprender y para pruebas; su propia documentación avisa que no es para producción. El código levanta uno en localhost (127.0.0.1, tu propia máquina) y le escribe una request a mano, con un socket, el objeto con el que un programa manda y recibe bytes por una conexión. Así ves el texto tal cual viaja. Tres detalles para leerlo: b"..." es una cadena de bytes, no de texto, porque eso es lo que viaja; self.rfile y self.wfile son la conexión vista como dos archivos, uno para leer la request y otro para escribir la respuesta; y al final cada \r\n se imprime para que lo veas:

import socket, threading
from http.server import BaseHTTPRequestHandler, HTTPServer

class Gateway(BaseHTTPRequestHandler):
    protocol_version = "HTTP/1.1"
    def do_POST(self):
        foto = self.rfile.read(int(self.headers["Content-Length"]))
        print("el servidor leyó:", self.requestline, "+", len(foto), "bytes de body")
        cuerpo = b'{"label": "Calzado > Tenis", "score": 0.91}'
        self.send_response_only(200)              # sin Date ni Server: así la salida no cambia
        self.send_header("Content-Type", "application/json")
        self.send_header("Content-Length", str(len(cuerpo)))
        self.end_headers()                        # escribe la línea en blanco
        self.wfile.write(cuerpo)
    def log_message(self, *args): pass           # sin bitácora en la pantalla

servidor = HTTPServer(("127.0.0.1", 0), Gateway)   # puerto 0: el sistema elige uno libre
threading.Thread(target=servidor.serve_forever, daemon=True).start()   # atiende en otro hilo

peticion = (b"POST /v1/classify?top_k=5 HTTP/1.1\r\nHost: localhost\r\n"
            b"Content-Type: image/jpeg\r\nContent-Length: 4\r\nConnection: close\r\n"
            b"\r\n" + bytes([0xFF, 0xD8, 0xFF, 0xE0]))   # los 4 primeros bytes de un JPEG
with socket.create_connection(servidor.server_address) as s:
    s.sendall(peticion)
    respuesta = b"".join(iter(lambda: s.recv(4096), b""))
print(respuesta.decode().replace("\r\n", "\\r\\n\n"))

el servidor leyó: POST /v1/classify?top_k=5 HTTP/1.1 + 4 bytes de body
HTTP/1.1 200 OK\r\n
Content-Type: application/json\r\n
Content-Length: 43\r\n
\r\n
{"label": "Calzado > Tenis", "score": 0.91}

El servidor encontró la línea en blanco, leyó los 4 bytes que anunciaba Content-Length y contestó. El body de la respuesta mide 43 bytes: cuenta los caracteres de {"label": "Calzado > Tenis", "score": 0.91} y salen 43. El header Connection: close le pidió al servidor cerrar la conexión al terminar; en la sección de keep-alive vas a ver por qué normalmente no se pide.

La primera línea dice qué quieres y sobre qué: POST /v1/classify?top_k=5 HTTP/1.1. El «sobre qué» es un pedazo de la URL.

La URL, por partes

Una URL (Uniform Resource Locator, localizador uniforme de recursos) es la dirección completa de algo en la red. La del gateway de C01, vista desde el backend, sería https://classifier.internal/v1/classify?top_k=5. Tiene cinco partes:

• El esquema (scheme), https: con qué protocolo se habla. http o https, casi siempre.
• El host, classifier.internal: el nombre de la máquina. El DNS lo convierte en una dirección IP antes de conectarse.
• El puerto, que aquí no aparece. Si falta, se usa el de omisión: 80 para http y 443 para https. Si el servidor escucha en otro, se escribe después de dos puntos: Triton recibe HTTP en http://triton:8000.
• La ruta (path), /v1/classify: qué cosa, dentro del servidor. Parece la ruta de un archivo, pero no tiene por qué haber un archivo: es texto que el servidor interpreta. El /v1 es la versión del contrato de la API, que se presenta en la lección siguiente como versionado.
• La query (query string), top_k=5: parámetros opcionales, después del ?, en pares nombre=valor separados por &.

Fíjate en qué viaja dónde. La ruta y la query van en la primera línea. El host va en el header Host. El esquema y el puerto ni siquiera se escriben: ya los usaste para abrir la conexión. Y si una URL trae un # (un fragmento, como #precio), esa parte nunca sale del navegador: sirve para saltar a un lugar de la página.

Una URL solo admite ciertos caracteres. Los demás se escriben con % y un código: un espacio es %20.

from urllib.parse import parse_qs, quote, urlencode, urlsplit

for url in ("https://classifier.internal/v1/classify?top_k=5", "http://localhost:8000/v2/health/ready"):
    u = urlsplit(url)
    print(u.scheme, "·", u.hostname, "· puerto:", u.port, "·", u.path, "·", parse_qs(u.query))

print(urlencode({"q": "tenis rojos", "talla": "26.5", "marca": "Niño & Co"}))
print(quote("/buscar/tenis niño"))

https · classifier.internal · puerto: None · /v1/classify · {'top_k': ['5']}
http · localhost · puerto: 8000 · /v2/health/ready · {}
q=tenis+rojos&talla=26.5&marca=Ni%C3%B1o+%26+Co
/buscar/tenis%20ni%C3%B1o

Los métodos: el verbo de la request

El método dice qué quieres hacer con la ruta. Los cinco que vas a ver:

• GET: dame esto. No lleva body. Lo usa tu navegador para cada página.
• POST: toma esto y procésalo. Lleva body. Puede crear algo nuevo cada vez.
• PUT: deja esto exactamente así. Manda la versión completa y reemplaza la que hubiera.
• PATCH: cambia solo estas partes.
• DELETE: borra esto.

Hay otros dos que aparecen de vez en cuando: HEAD, igual que GET pero sin body en la respuesta (solo los headers), y OPTIONS, que pregunta qué métodos acepta una ruta.

Los métodos se agrupan por dos propiedades. Un método es seguro (safe) si no cambia nada en el servidor: pedir no tiene efectos. Y es idempotente si hacerlo dos veces deja al servidor igual que hacerlo una. La idempotencia se presenta a fondo en la lección «Timeouts, reintentos e idempotencia», porque decide qué se puede reintentar sin miedo. Aquí basta la idea.

¿Por qué DELETE es idempotente, si la segunda vez contesta distinto? Porque la idempotencia habla del efecto en el servidor, no de la respuesta. El primer DELETE borra el trabajo y responde que salió bien; el segundo no encuentra nada y responde «no existe». Pero después de los dos, el trabajo está borrado, igual que después de uno. Con POST no pasa: dos POST /v1/publicaciones iguales crean dos publicaciones.

Clasificar una foto no cambia nada en el gateway: en la práctica es seguro y se puede repetir. ¿Por qué entonces C01 usa POST y no GET? Porque la foto tiene que ir en el body, y el estándar de HTTP no le da ningún significado al body de un GET: muchos servidores y proxies (los programas intermedios que reenvían requests) lo ignoran o rechazan la request entera. El método describe la forma de la request; que clasificar sea repetible lo dice el contrato de la API, no el verbo.

¿Y si alguien manda GET /v1/classify? La ruta existe, pero no con ese método. El gateway responde 405 Method Not Allowed, con un header Allow: POST que dice qué método sí acepta. La Ronda (C01) lo registra como un error del cliente.

Los headers son los datos sobre el mensaje: van entre la primera línea y la línea en blanco, uno por línea, con la forma Nombre: valor. El nombre no distingue mayúsculas: Content-Type y content-type son el mismo header. Y el orden casi nunca importa.

Los que vas a ver en la Ronda

Un tipo MIME (media type) es una etiqueta de dos partes, tipo y subtipo: image/jpeg es una foto JPEG; application/json, texto en JSON; text/event-stream, una respuesta que llega en pedazos, como el texto de un LLM mientras se escribe (SSE, en la lección siguiente). Si el gateway recibe un tipo que no sabe leer, como application/pdf, responde 415.

Authorization merece su propio párrafo. Bearer quiere decir «al portador»: quien presente este token (la credencial: un texto largo que nadie puede adivinar) es quien dice ser. El token puede ser un JWT, un sobre firmado con la identidad de quien llama, o una llave de API, una contraseña larga para programas; los dos tienen su lección en la fase de identidad. Lo importante aquí: viaja en un header, en cada request, porque HTTP no recuerda quién eres.

Headers inventados

Puedes inventar los tuyos. Por costumbre empezaban con X-; desde 2012 el estándar recomienda ya no hacerlo, pero la costumbre sigue por todas partes.

Para seguir los de la Ronda hace falta conocer a un intermediario que vas a ver mucho en C01: el ALB (Application Load Balancer), el balanceador de carga de AWS (Amazon Web Services, la nube de Amazon donde corre C01). Es el programa que recibe el tráfico de C01 y reparte las requests entre las copias del gateway. Dos headers inventados de la Ronda:

• X-Request-ID une los logs del backend y del gateway para una misma request. Lo pone el backend; el gateway lo respeta (o inventa uno si no llega), lo escribe en cada línea de su log y lo devuelve en la respuesta. El ALB no usa ese header; agrega su propio id, X-Amzn-Trace-Id.
• x-client-source dice si la request viene del celular o de la web. Pero lo escribe quien llama, así que puede mentir: sirve para separar métricas, nunca para decidir permisos (M15). Para eso está el token, que el ALB verifica.

Cookies, de pasada

Si HTTP no recuerda nada, ¿cómo sabe una página que ya iniciaste sesión? Con una cookie. El servidor responde con Set-Cookie: sesion=ab12; HttpOnly; Secure y el navegador la guarda. Desde entonces, cada request a ese sitio lleva Cookie: sesion=ab12, y el servidor busca esa sesión en su base de datos. La memoria no está en HTTP: está en un header que el navegador repite.

Entre servicios, como del backend al gateway, casi no se usan: cada request lleva su Authorization.

El body es todo lo que va después de la línea en blanco. Su formato lo dice Content-Type y su tamaño, Content-Length. Puede estar vacío, como en un GET.

Tres formas de mandar una foto

1. Los bytes crudos. El body es el archivo JPEG tal cual, con Content-Type: image/jpeg. Es lo que hace C01. Lo que llega es exactamente lo que se mandó: nada que traducir, nada que crezca. El código de referencia de la Ronda lo justifica en un comentario: menos trabajo para leerlo y ningún archivo temporal.

2. JSON con base64. Un body en JSON es texto, y un texto no puede llevar bytes cualquiera: el byte 0, por ejemplo, no es una letra. La solución es base64, que reescribe cada 3 bytes como 4 letras de un alfabeto de 64 símbolos seguros (A–Z, a–z, 0–9, + y /). El body queda así:

{"image": "/9j/4AAQSkZJRgABAQ...", "top_k": 5}

Ese /9j/ del principio es como se escriben en base64 los primeros tres bytes de cualquier JPEG, que en hexadecimal son FF D8 FF. El precio es el tamaño:

La Ronda (M07) hace la misma cuenta con el tensor que el gateway le manda a Triton, la tabla de números ya lista para el modelo: 3 × 224 × 224 números de 4 bytes, 602,112 bytes en binario, ≈ 803 KB en base64 y ≈ 3.1 MB si los números van como texto en JSON. JSON sirve para leer y depurar; para mover muchos bytes, no.

3. multipart/form-data. Es la forma en que un formulario web sube archivos. El body se parte en secciones separadas por una frontera, una línea larga y única que no aparece en los datos. Cada sección trae sus propios mini-headers: una lleva la foto en bytes crudos y otra, por ejemplo, el título de la publicación. Agrega unos cientos de bytes, no un tercio. Conviene cuando la foto viaja con otros campos.

El tope: el 413 casi gratis

Un body sin tope es una invitación al abuso. Una foto de 10 GB llenaría la memoria del gateway, y una bomba de descompresión pesa poco pero ocupa muchísimo al abrirse. Por eso C01 acepta fotos de hasta 10 MB.

El tope se revisa antes de leer el body. Content-Length llega en los headers, así que el gateway puede responder 413 («demasiado grande») sin haber recibido la foto: le cuesta casi nada. Cada pieza del camino tiene su propio tope, y el más chico manda:

• El gateway de C01: 10 MB por foto.
• El ALB de C01: no le pone tope al body. Sí a los headers: 64 KB entre todos; si se pasan, responde 400.
• nginx, un servidor web y proxy muy usado: 1 MB por omisión (su opción client_max_body_size). Si un nginx sin configurar queda en el camino, una foto web de 3 MB recibe un 413 de él, no del gateway.
• Amazon API Gateway, un servicio de AWS: un tope duro de 10 MB por request, que no se puede subir. Fue una de las razones por las que la Ronda no lo usó en C01 (M15).
• Un endpoint en tiempo real de SageMaker AI, la plataforma de ML de AWS: 6 MiB (6,291,456 bytes) por request, y 60 segundos para responder (M13).

Las cifras de AWS son las de su documentación en 2026; los servicios en la nube cambian sus topes de vez en cuando, así que se revisan antes de diseñar. Y fíjate en lo que dice el caso de nginx: el 413 lo responde la pieza que tiene el tope. Si una pieza de en medio tiene uno más chico, el gateway nunca ve la request, y buscar ese 413 en sus logs no sirve de nada.

Prueba con la calculadora cuánto pesa la foto en cada forma y cuánto tarda en subir.

El código de estado es el número de tres cifras de la primera línea de la respuesta. La primera cifra dice la familia, y con ella ya sabes casi todo:

• 1xx, informativo: «sigue». Casi no los vas a ver. El 101 aparece cuando una conexión se cambia a WebSocket, una conexión que queda abierta para mandar mensajes en los dos sentidos.
• 2xx, éxito: salió bien.
• 3xx, redirección: lo que buscas está en otro lado; el header Location dice dónde.
• 4xx, error del cliente: tu request está mal. Si la repites igual, va a fallar igual.
• 5xx, error del servidor: yo fallé. Quizá más tarde sí se pueda.

Los códigos de la Ronda

Tres pares se confunden mucho:

• 401 y 403. Al 401 le pusieron «no autorizado», pero quiere decir «no sé quién eres» (sin credencial, o con una vencida). El 403 es «sé quién eres y no te toca».
• 400 y 422. Los dos dicen «tu entrada está mal». FastAPI, el framework de Python con que está escrito el gateway de C01, responde 422 por su cuenta cuando Pydantic, la librería que revisa los tipos de cada parámetro, rechaza uno: top_k=0, si el contrato pide de 1 a 20. El 400 lo usa el gateway para lo que revisa él mismo, como una imagen que no se puede decodificar.
• 429 y 503. Los dos llevan Retry-After y los dos invitan a reintentar, pero la culpa es opuesta. El 429 dice «tú te pasaste de tu cuota; yo estoy bien». El 503 dice «yo estoy saturado; no es culpa tuya». Si respondes 503 por una cuota, tu alarma de disponibilidad se dispara por culpa de un cliente que se pasó (M15).

Los dos con «Gateway» en el nombre, el 502 y el 504, los responde un intermediario cuando el de atrás falla: el gateway cuando Triton no contesta a tiempo, o el ALB cuando el gateway le cierra la conexión. Y hay códigos que no están en ningún estándar: el 499 es una convención de nginx para «el cliente se fue antes de la respuesta». Lo ves en la sección extra que sigue.

Quién responde cada código

El código no siempre lo pone el servidor final. Cada pieza del camino puede contestar por su cuenta, y saber quién lo hizo es la mitad de cualquier diagnóstico.

Para qué sirve saber de quién es la culpa

Quien llama decide con el código. El backend de C01 hace así: con un 4xx no reintenta, porque fallaría igual, y lo anota como un error suyo; con un 503 o un 504, o si no llega nada en 300 ms, muestra el selector de categorías de siempre y Ana elige a mano. Ese plan B es el fallback de C01.

Y la culpa decide qué cuenta contra la promesa. En «Promedios, medianas y percentiles» viste el SLI de disponibilidad de C01: de las requests que cuentan, la fracción que salió sin error del servidor y en menos de 300 ms; su promesa, el SLO, es 99.9 %. Las que cuentan son solo las válidas: las que no fallaron por culpa de quien llama. Una foto de 50 MB que recibe 413 no es una falla del servicio.

Los números del día son un supuesto para el ejemplo; la regla es la de la Ronda: los 4xx no se reintentan y no cuentan contra el SLO.

Los códigos, en tu computadora

Este servidor imita las revisiones del gateway de C01 con un tope de juguete de 1,000 bytes. Revisa en el mismo orden que el gateway: primero lo barato.

import threading, urllib.error, urllib.request
from http.server import BaseHTTPRequestHandler, HTTPServer

class Gateway(BaseHTTPRequestHandler):          # tope de juguete: 1,000 bytes (en C01, 10 MB)
    def do_GET(self): self.responder(405)      # /v1/classify solo acepta POST
    def do_POST(self):
        largo, top_k = int(self.headers["Content-Length"]), int(self.path.split("top_k=")[1])
        if largo > 1000: codigo = 413           # se decide con el header, sin leer el body
        elif self.headers["Content-Type"] != "image/jpeg": codigo = 415
        elif not 1 <= top_k <= 20: codigo = 422
        else: codigo = 200
        self.rfile.read(largo)                  # la demo lo lee igual, para que corra estable
        self.responder(codigo)
    def responder(self, codigo):
        self.send_response(codigo); self.send_header("Content-Length", "0"); self.end_headers()
    def log_message(self, *args): pass

servidor = HTTPServer(("127.0.0.1", 0), Gateway)
threading.Thread(target=servidor.serve_forever, daemon=True).start()
url = f"http://127.0.0.1:{servidor.server_port}/v1/classify?top_k="

def pedir(metodo, top_k, tipo, body):
    req = urllib.request.Request(url + top_k, body, {"Content-Type": tipo}, method=metodo)
    try:
        with urllib.request.urlopen(req, timeout=2) as r: return r.status
    except urllib.error.HTTPError as e: return e.code     # urllib lanza un error con 4xx y 5xx

foto = b"\xff\xd8" + b"x" * 498                             # 500 bytes que empiezan como un JPEG
for caso in [("POST", "5", "image/jpeg", foto), ("GET", "5", "image/jpeg", None),
             ("POST", "5", "image/jpeg", foto * 4), ("POST", "5", "application/pdf", b"%PDF"),
             ("POST", "0", "image/jpeg", foto)]:
    print(f"{caso[0]:<4} top_k={caso[1]}  {caso[2]:<15} {len(caso[3] or b''):>5} bytes → {pedir(*caso)}")

POST top_k=5  image/jpeg        500 bytes → 200
GET  top_k=5  image/jpeg          0 bytes → 405
POST top_k=5  image/jpeg       2000 bytes → 413
POST top_k=5  application/pdf     4 bytes → 415
POST top_k=0  image/jpeg        500 bytes → 422

Fíjate en timeout=2: el cliente espera como máximo 2 segundos. Un cliente sin timeout puede quedarse esperando para siempre, y en Python, la librería requests no trae uno si no se lo pides (M03).

HTTPS: el mismo HTTP, en un sobre cerrado

El HTTP que viste viaja legible. Cualquiera en el camino (el wifi de una cafetería, un router de la ruta) puede leer el token de Authorization y la foto, y hasta cambiarlos. HTTPS es el mismo HTTP metido dentro de TLS, una capa que cifra todo lo que pasa por la conexión y comprueba que el servidor es quien dice ser, con un certificado: un documento digital que dice «este nombre es de este servidor», firmado por una organización en la que tu sistema ya confía. Cómo lo logra es tema de la lección de cifrado, en la fase 9.

Los mensajes de HTTP no cambian en nada: la misma primera línea, los mismos headers, el mismo body. Solo viajan cifrados. Por omisión, HTTPS usa el puerto 443. Por fuera se sigue viendo a qué IP y puerto vas, cuánto pesan los mensajes y, casi siempre, el nombre del host, porque el cliente lo manda sin cifrar al saludar, para que el servidor sepa qué certificado mostrar. Hay una extensión nueva que también lo esconde, pero todavía se usa poco. La ruta, los headers y el body quedan ocultos.

En C01, el ALB termina TLS: descifra la request y la manda al gateway por la red privada del sistema. La Ronda pide además TLS en todo lo que sale de un pod y, dentro del cluster (el grupo de máquinas donde corren los pods), mTLS si hay una malla de servicios (proxies junto a cada pod, en la lección de balanceadores): TLS en los dos sentidos, donde también el cliente muestra su certificado (M15).

Lo que cuesta abrir una conexión

Antes del primer byte de HTTP hay que abrir la conexión. Como viste en la lección anterior, TCP abre con un handshake, un saludo de tres mensajes que cuesta un RTT (round-trip time: lo que tarda un mensaje en ir y volver). Encima va el saludo de TLS: 1 RTT más con TLS 1.3, la versión actual (de 2018), y 2 con TLS 1.2, la anterior. Solo entonces viajan la request y la respuesta: otro RTT, más lo que tarde el servidor.

Keep-alive: dejar la conexión abierta

Keep-alive es no cerrar la conexión después de la respuesta, para mandar por ella la siguiente request. En HTTP/1.1 es lo normal: la conexión queda abierta salvo que alguien mande Connection: close. El servidor la cierra cuando pasa un rato sin uso, su idle timeout (tiempo máximo de inactividad).

Dentro de un centro de datos el RTT es de una fracción de milisegundo, y los saludos cuestan poco en tiempo. Pero cada conexión nueva también cuesta CPU, sobre todo con TLS, y deja rastro en el sistema operativo. El gateway de C01 crea un solo cliente de Triton por proceso y lo reusa en todas las requests: reusa sus conexiones y no hace un handshake por foto.

El pool de conexiones

En HTTP/1.1, una conexión lleva una request a la vez: la segunda espera a que llegue la respuesta de la primera. Si el gateway quiere 16 llamadas a Triton al mismo tiempo, necesita 16 conexiones.

Un pool de conexiones es un grupo de conexiones abiertas que el cliente guarda y presta. Cada request toma una libre, la usa y la devuelve. Si no hay libre y el pool no ha llegado a su tamaño máximo, abre otra; si ya llegó, la request espera su turno. Así el pool también es un tope: limita cuántas llamadas van a la vez hacia un servidor.

En Python, urllib.request.urlopen abre y cierra una conexión cada vez. http.client.HTTPConnection la deja abierta. El servidor de abajo cuenta cuántas conexiones recibe:

import http.client, threading, urllib.request
from http.server import BaseHTTPRequestHandler, ThreadingHTTPServer

class Gateway(BaseHTTPRequestHandler):
    protocol_version = "HTTP/1.1"               # permite dejar la conexión abierta
    conexiones = 0
    def setup(self):                            # corre una vez por cada conexión nueva
        Gateway.conexiones += 1
        super().setup()
    def do_GET(self):
        self.send_response(200); self.send_header("Content-Length", "2"); self.end_headers()
        self.wfile.write(b"ok")
    def log_message(self, *args): pass

servidor = ThreadingHTTPServer(("127.0.0.1", 0), Gateway)   # atiende cada conexión en su hilo
threading.Thread(target=servidor.serve_forever, daemon=True).start()
host, puerto = servidor.server_address

for _ in range(10):                             # urllib abre y cierra una conexión cada vez
    urllib.request.urlopen(f"http://{host}:{puerto}/v2/health/ready").read()
print("10 requests con urllib:          ", Gateway.conexiones, "conexiones")

Gateway.conexiones = 0
con = http.client.HTTPConnection(host, puerto)  # una conexión que se reusa (keep-alive)
for _ in range(10):
    con.request("GET", "/v2/health/ready"); con.getresponse().read()
print("10 requests con una HTTPConnection:", Gateway.conexiones, "conexión")

10 requests con urllib:           10 conexiones
10 requests con una HTTPConnection: 1 conexión

Fuera de la biblioteca estándar, lo mismo hacen requests.Session y httpx.Client: crea uno y reúsalo, en vez de un cliente nuevo por request. Con la calculadora, juega con el RTT y con cuántas requests van por cada conexión.

Los dos lados tienen que estar de acuerdo

Una conexión abierta tiene dos dueños, y cada uno tiene su idle timeout. El ALB cierra las que pasan 60 segundos sin uso; uvicorn, el servidor que corre el gateway, a los 5 si nadie le dice otra cosa (los dos son sus valores por omisión en 2026). Si el de atrás cierra primero, el ALB a veces manda una request por una conexión que acaba de morir, y responde 502. Por eso la Ronda corre uvicorn con --timeout-keep-alive 75: así siempre cierra primero el ALB. Lo desarmas en el último reto.

1. Reintentar un 4xx

Un 400, un 413 o un 415 van a fallar igual la segunda vez: la foto sigue siendo un PDF. Reintentarlos solo agrega carga.

Cómo evitarlo: reintentar solo lo que puede cambiar: 503 y 429 (respetando Retry-After) y, con cuidado, 502 y 504. Nunca un 400, 413 o 415 (M03).

2. Un código que miente

Responder 503 cuando el cliente se pasó de su cuota esconde de quién es la culpa y dispara tu alarma de disponibilidad. Peor aún es un 200 que miente: un plan B que responde 200 sin que nadie lo cuente, o un servidor de modelo roto que devuelve basura con código 200. Los tableros se ven verdes y el modelo no está contestando (M02, M11).

Cómo evitarlo: 429 para la cuota, 503 para la saturación. Si respondes con un plan B, márcalo (un header o un campo del body) y cuéntalo en una métrica aparte.

3. Un cliente sin timeout

Si el servidor se cuelga, un cliente sin timeout se cuelga con él, con su conexión y su memoria. requests de Python no trae timeout por omisión (M03).

Cómo evitarlo: pon siempre un timeout, y que sea menor que el de quien te llama: en C01, el backend espera 300 ms, el gateway se da 250 y a Triton le da 150.

4. Leer el body sin tope

Un gateway que lee el body completo antes de revisarlo puede llenarse de memoria con una sola request de varios GB.

Cómo evitarlo: revisar Content-Length antes de leer (413 casi gratis) y, además, contar mientras se lee, porque un cliente puede mandar el body en pedazos o mentir en el header.

5. Un GET que cambia cosas

GET /v1/borrar?id=7 es una mala idea: los navegadores, los proxies y los reintentos automáticos asumen que un GET no tiene efectos y lo repiten sin preguntar. Al revés, un POST que crea algo y se reintenta por un timeout puede crearlo dos veces.

Cómo evitarlo: GET solo para leer. Para un POST que se reintenta, una llave de idempotencia: un header (Idempotency-Key) con el que el servidor reconoce una request repetida. Lo ves en «Timeouts, reintentos e idempotencia».

6. El de atrás cierra antes que el de adelante

Si el gateway cierra sus conexiones inactivas a los 5 segundos y el ALB las sigue usando hasta los 60, aparecen 502 sueltos que nadie entiende.

Cómo evitarlo: el idle timeout de cada pieza, mayor que el de la pieza que tiene enfrente: uvicorn con --timeout-keep-alive 75 detrás de un ALB de 60 s.

Resuélvelos con lápiz antes de abrir la solución. Los de body y conexiones se pueden comprobar con las calculadoras.

1. 1Fácil

   Desarma esta URL: https://api.tienda.mx/v2/buscar?q=tenis%20rojos&page=2. ¿Qué viaja en la primera línea de la request y qué en el header Host? ¿A qué puerto se conecta?

   Ver la solución paso a paso

   • Esquema: https. Host: api.tienda.mx. Ruta: /v2/buscar. Query: q=tenis%20rojos&page=2, es decir, q = «tenis rojos» y page = 2.
   • No trae puerto, así que se usa el de omisión de HTTPS: 443.
   • Primera línea: GET /v2/buscar?q=tenis%20rojos&page=2 HTTP/1.1. Header: Host: api.tienda.mx. El esquema y el puerto no se escriben: ya se usaron para abrir la conexión.
2. 2Fácil

   Para cada acción, elige método y di si es seguro e idempotente: (a) ver el estado de un trabajo, (b) subir una foto para clasificarla, (c) reemplazar la configuración completa de un modelo, (d) cambiar solo el precio de una publicación, (e) borrar un trabajo.

   Ver la solución paso a paso

   • (a) GET: seguro e idempotente.
   • (b) POST: ni seguro ni idempotente por definición del método, aunque clasificar no cambie nada en el servidor.
   • (c) PUT: no es seguro, pero sí idempotente: mandar la misma configuración dos veces deja lo mismo.
   • (d) PATCH: no es seguro y no se garantiza que sea idempotente.
   • (e) DELETE: no es seguro, pero sí idempotente: después de uno o de dos, el trabajo está borrado.
3. 3Fácil

   ¿Qué código responde el sistema de C01, y de quién es la culpa? (a) Una foto de 14 MB. (b) Un GIF. (c) top_k=50. (d) Triton está caído. (e) Triton tarda 400 ms. (f) Un token vencido.

   Ver la solución paso a paso

   • (a) 413, del cliente: pasa de 10 MB.
   • (b) 415, del cliente: solo JPEG, PNG y WebP.
   • (c) 422, del cliente: FastAPI rechaza el parámetro fuera de 1 a 20.
   • (d) 503 con Retry-After, del servidor.
   • (e) 504, del servidor: el gateway corta a los 150 ms.
   • (f) 401, del cliente: lo responde el ALB, que verifica el token antes de que la request llegue al gateway.
   • Los tres primeros y el último no se reintentan; los del medio sí, y el backend cae al selector manual.
4. 4Fácil

   Una foto de 150,000 bytes va en base64 dentro de un JSON. ¿Cuántos bytes ocupa? ¿Y una de 9 MB, con el tope de 10 MB de C01?

   Ver la solución paso a paso

   • 150,000 ÷ 3 = 50,000 grupos; × 4 = 200,000 bytes, un tercio más.
   • 9,000,000 ÷ 3 × 4 = 12,000,000 bytes: 12 MB. Pasa el tope: 413. En bytes crudos, 9 MB sí entraban.
   • La foto más grande que cabe en 10 MB como base64: 10,000,000 × 3 ÷ 4 = 7.5 MB.
5. 5Medio

   Escribe la request completa (primera línea, headers y body) para preguntar por el trabajo 7f3c con el token abc123, y una respuesta de «todavía no termina». ¿Qué cambia si el trabajo no existe?

   Ver la solución paso a paso

   text

   GET /v1/jobs/7f3c HTTP/1.1
   Host: ocr.internal
   Authorization: Bearer abc123
   Accept: application/json
   

   • Sin body: un GET no lleva. Después de los headers va la línea en blanco, y ahí termina.
   • La respuesta: HTTP/1.1 200 OK, Content-Type: application/json, su Content-Length, la línea en blanco y un body como {"status": "running"}. La request salió bien aunque el trabajo no haya terminado: el estado va en el body.
   • Si el trabajo no existe: 404 Not Found. Si existe pero es de otro cliente, también conviene un 404 y no un 403, para no confirmarle a nadie que ese trabajo existe.
6. 6Medio

   Un cliente hace 20 requests seguidas a un servidor con un RTT de 80 ms. Sin contar el tiempo del servidor, ¿cuánto tarda en total sin keep-alive y con keep-alive, con TLS 1.3 y con TLS 1.2?

   Ver la solución paso a paso

   • Sin keep-alive, cada request paga todo. Con TLS 1.3: (1 + 1 + 1) × 80 = 240 ms; × 20 = 4,800 ms. Con TLS 1.2: (1 + 2 + 1) × 80 = 320 ms; × 20 = 6,400 ms.
   • Con keep-alive, solo la primera paga los saludos. TLS 1.3: 240 + 19 × 80 = 1,760 ms. TLS 1.2: 320 + 19 × 80 = 1,840 ms.
   • Se ahorra ≈ 63 % con TLS 1.3 y ≈ 71 % con TLS 1.2. Con keep-alive, la versión de TLS casi deja de importar.
7. 7Medio

   En un día, el gateway de C01 recibe 8,000,000 requests: 120,000 con 4xx, 9,000 con 5xx y 2,000 lentas (de más de 300 ms, sin error). ¿Cuál es el SLI? ¿Cumple el SLO de 99.9 %? ¿Y si alguien contara los 4xx como fallas?

   Ver la solución paso a paso

   • Válidas: 8,000,000 − 120,000 = 7,880,000.
   • Malas: 9,000 + 2,000 = 11,000.
   • SLI: (7,880,000 − 11,000) ÷ 7,880,000 ≈ 99.86 %. No cumple: el presupuesto del día era 0.1 % de 7,880,000 = 7,880 requests, y se gastaron 11,000.
   • Con los 4xx como fallas: (8,000,000 − 131,000) ÷ 8,000,000 ≈ 98.36 %. Se vería peor de lo que es, y se perdería la pista de que el problema son los 5xx.
8. 8Reto

   Un equipo quiere llamar directo a un endpoint de SageMaker AI, que acepta hasta 6 MiB por request, con las fotos web de C01 en JSON con base64. (a) ¿Cuál es la foto más grande que cabe? (b) ¿Y en bytes crudos? (c) ¿Qué propones para las fotos de hasta 10 MB?

   Ver la solución paso a paso

   • (a) 6 MiB = 6,291,456 bytes. En base64 caben 6,291,456 × 3 ÷ 4 = 4,718,592 bytes, ≈ 4.7 MB, y un poco menos por el resto del JSON.
   • (b) En bytes crudos, casi los 6,291,456: ≈ 6.3 MB. Cualquier foto entre 6.3 y 10 MB no entra de ninguna forma.
   • (c) Dos salidas, las de la Ronda (M13): que el gateway reduzca la foto antes de llamar (a 1024 px, como el celular, pesa ≈ 200 KB), o cambiar al patrón asíncrono: la foto se sube a S3, la request solo lleva su dirección y la respuesta es un 202 con un job_id.
9. 9Reto

   Los 502 aparecen de a poquito: 1 o 2 por cada 100,000 requests, sin relación con el tráfico. Los logs del gateway no muestran ningún error. El ALB cierra conexiones inactivas a los 60 s y uvicorn corre con su valor por omisión, 5 s. Explica qué pasa, por qué el gateway no lo ve y cómo lo arreglas.

   Ver la solución paso a paso

   • El ALB guarda conexiones abiertas hacia cada pod del gateway. Uvicorn cierra las que llevan 5 s sin uso; el ALB las seguiría usando hasta los 60 s.
   • A veces el ALB elige una conexión justo cuando uvicorn la está cerrando. La request llega a una conexión muerta; el ALB no recibe respuesta y contesta 502.
   • El gateway no lo ve porque, para él, esa request nunca llegó: no hay línea de log ni métrica. Solo el ALB la cuenta. Por eso es raro y no depende del tráfico: depende de cuándo coincide una request con un cierre.
   • Arreglo: que el de atrás espere más que el de adelante. --timeout-keep-alive 75 en uvicorn, mayor que los 60 s del ALB: así siempre cierra primero el ALB, que sabe que cerró y no reusa esa conexión.

En la Ronda:

• M02 · Patrones de inferencia usa los códigos como contrato: la API síncrona de C01 con 400, 413, 415, 503 con Retry-After y 504; la asíncrona con POST → 202 + job_id y un GET para preguntar; y el 429 de una cuota.
• M07 · Servidores de modelos abre los protocolos: Triton con HTTP en el 8000 y gRPC en el 8001, la extensión binaria de HTTP contra JSON y base64, HTTP/1.1 con un pool contra una conexión larga de HTTP/2, y los idle timeouts de los proxies.
• M15 · Seguridad y confiabilidad separa el 429 del 503 y pone el Retry-After en segundos; el header Authorization con un JWT verificado en el ALB, y HTTPS en todo lo que sale de un pod.
• También: M03 decide qué códigos se reintentan, M11 vigila la tasa de 5xx de un canary (la versión nueva, probada primero con una parte chica del tráfico) y M13 cuenta los topes de body de cada plataforma.

En el Dojo: la estación 6, «Código de serving», escribe el gateway de C01: la ruta POST /v1/classify, las revisiones en orden y los códigos de esta lección. La estación 11, «La request en vivo», sigue una request de punta a punta. Cuando abran, ahí lo vas a practicar.

En Sensei: «APIs: REST, JSON, gRPC y streaming» diseña la API que va encima de HTTP. «Balanceadores, proxies y gateways» abre las piezas que responden 502, 503 y 429 por su cuenta. «Timeouts, reintentos e idempotencia» decide qué hacer con cada código. Y «Qué tan rápido y cuánto: latencia y throughput» mide lo que cuesta cada viaje.

Estos son los conceptos que presentó esta lección. Cada uno tiene su tarjeta con la definición completa.

Intenta responder en tu cabeza antes de abrir cada respuesta.

1. 1¿Cuáles son las cuatro partes de una request de HTTP, en orden?Ver respuesta

   La línea de la petición (método, ruta con query y versión), los headers, una línea en blanco y el body. La respuesta tiene la misma forma, con la línea de estado en vez de la de la petición.

2. 2¿Cómo sabe el servidor dónde terminan los headers y dónde termina el body?Ver respuesta

   Los headers terminan en la línea en blanco, \r\n\r\n. El body termina cuando se leyeron los bytes que dice Content-Length (o, con chunked, cuando llega un pedazo de tamaño 0).

3. 3¿Qué significa que un método sea idempotente? ¿DELETE lo es?Ver respuesta

   Que hacerlo dos veces deja al servidor igual que hacerlo una. DELETE sí: el segundo puede responder 404, pero el resultado es el mismo, el recurso borrado. POST no.

4. 4¿Qué familia de códigos se reintenta y cuál no? ¿Por qué?Ver respuesta

   Los 4xx no: la request está mal y fallaría igual. Algunos 5xx sí (503, 502, 504, con cuidado), y también el 429 aunque sea un 4xx, siempre después de Retry-After.

5. 5¿En qué se diferencian un 429 y un 503?Ver respuesta

   El 429 dice «te pasaste de tu cuota»: la culpa es del cliente. El 503 dice «estoy saturado o me falta algo»: la culpa es del servidor. Mezclarlos ensucia la alarma de disponibilidad.

6. 6¿Qué ahorra keep-alive y por qué hace falta un pool?Ver respuesta

   Ahorra el handshake de TCP y el de TLS en cada request: 2 o 3 RTT. En HTTP/1.1 cada conexión lleva una request a la vez, así que para varias al mismo tiempo hace falta un pool de conexiones abiertas.