Curso exprés · No. 05
Dos programas solo pueden cooperar si se ponen de acuerdo en las reglas — qué enviar, con qué forma, y quién habla cuándo. El protocolo es ese acuerdo, y elegir el correcto es elegir cómo va a transcurrir la conversación.
Solo la esencia · Una imagen por protocolo · Ejemplos antes que RFCs
Un protocolo es el conjunto de reglas acordadas que dos programas usan para hablar — cómo se ve un mensaje, y quién puede decir qué, cuándo. Acertá con las reglas y sistemas muy distintos se entienden entre sí.
Un protocolo es un idioma más etiqueta
Dos diplomáticos que no comparten lengua materna igual negocian — porque acuerdan de antemano un idioma y el orden para hablar. Rompé cualquiera de los dos y es solo ruido.
Para dos programas, el protocolo fija ambas cosas: el formato del mensaje (para que cada lado pueda leerlo) y la coreografía (quién habla primero, cuándo llega una respuesta, cómo termina). HTTP, gRPC, WebSocket — cada uno es solo un acuerdo distinto sobre esas dos cosas. La misma tarea, distintos modales.
Los protocolos vienen en capas
Una carta: el sistema postal mueve el sobre y no le importa qué hay adentro; el idioma en la página es entre vos y el lector. Dos acuerdos separados, apilados.
Debajo se sienta un protocolo de transporte (TCP o UDP) que solo mueve bytes entre máquinas. Encima se sienta un protocolo de aplicación (HTTP, gRPC, MQTT) que le da sentido a esos bytes. Casi siempre trabajás arriba — pero cuando las cosas se ponen lentas o inestables, la capa de abajo se filtra, así que conviene saber que está ahí.
Todo protocolo responde tres preguntas
Una conversación necesita tres cosas resueltas: quién empieza, qué idioma, y si se turnan o hablan los dos a la vez.
Quién inicia — ¿el cliente pregunta, o el servidor puede hacer push? Qué forma toman los datos — texto JSON, binario compacto, un stream continuo? El timing — un solo disparo, o una línea de larga vida donde cualquiera de los dos lados puede hablar? Casi toda diferencia entre protocolos es una respuesta distinta a esas tres.
No hay un mejor protocolo, solo un encaje
No mandarías una invitación de boda por walkie-talkie, ni coordinarías un rescate por correo.
Un protocolo está afinado para una forma de conversación: rara y confiable, o constante y rápida; uno a uno, o uno a muchos; legible para humanos, o lo más pequeña posible. La habilidad no es conocer el protocolo más nuevo — es emparejar el protocolo con cómo los dos lados realmente necesitan hablar.
Un protocolo es un acuerdo. Elegilo por la forma de la conversación, no por lo que está de moda.
Debajo de casi todo lo que construís se sientan unos pocos protocolos que rara vez tocás directamente pero de los que siempre dependés. Conocelos — deciden qué es siquiera posible arriba.
TCP: una línea confiable que garantiza la entrega
Una llamada telefónica donde la otra persona dice «entendido» después de cada frase — más lenta, pero nada se pierde ni se mezcla.
TCP establece una conexión y garantiza que cada byte llega, en orden, reintentando lo que se pierde. Es el caballo de batalla bajo la web, el email y la mayoría de las APIs. Pagás un poco en setup y latencia a cambio de la promesa de que los datos están completos y correctos — casi siempre un gran trato.
UDP: disparar y olvidar, rápido y con pérdidas
Gritar a través de una sala ruidosa — rápido, pero si se pierde una palabra no te detenés a repetirla, simplemente seguís.
UDP envía paquetes sin garantía de llegada ni de orden. Eso suena mal hasta que querés velocidad por encima de la perfección: videollamadas, juegos en vivo, consultas DNS — donde un frame perdido le gana a un tartamudeo mientras esperás un reenvío. (HTTP/3, más abajo, está construido sobre él.)
HTTP: el idioma de pregunta-respuesta de la web
El mostrador de una tienda: pedís una cosa, te dan una respuesta, y el empleado se olvida de vos en cuanto te vas.
HTTP viaja sobre TCP y define el familiar pregunta/respuesta con verbos (GET, POST, PUT, DELETE) y códigos de estado (200, 404, 500). Es stateless — cada petición vale por sí sola — que es exactamente lo que deja escalar a la web a miles de millones de llamadas. Casi toda API que vayas a tocar lo habla.
HTTPS y TLS: lo mismo, pero sellado
La misma carta, ahora dentro de un sobre a prueba de manipulación con la firma verificada del remitente por fuera.
TLS envuelve a HTTP (y a otros protocolos) en encriptación e identidad, para que nadie en el medio pueda leer ni falsificar el tráfico. Es la «S» de HTTPS — y ya no es opcional: navegadores, app stores y APIs lo dan por hecho. Si los datos salen de tu máquina, deberían ir dentro de TLS.
HTTP/1.1 → 2 → 3: la misma tubería, ensanchada
Un camino de un solo carril que se volvió una autopista de muchos carriles — y después se reconstruyó para que un auto detenido ya no bloquee todos los carriles.
HTTP/1.1 manejaba una petición a la vez por conexión; HTTP/2 multiplexa muchas sobre una; HTTP/3 se muda a QUIC (sobre UDP) para matar el «head-of-line blocking», abrir conexiones en aproximadamente un round trip, y sobrevivir a que un teléfono cambie de Wi-Fi a datos móviles sin cortarse. Las mismas peticiones que ya escribís — un camino más rápido por debajo.
Construís en lo alto del stack, pero el fondo decide qué es posible. Y la encriptación no es una capa que atornillás después.
La mayoría del diálogo app-a-servidor y servicio-a-servicio es «hacé una pregunta, recibí una respuesta». Tres protocolos dominan, cambiando simplicidad por poder de maneras distintas.
REST: recursos sobre verbos HTTP planos
Una biblioteca bien organizada donde cada libro tiene una dirección fija, y usás las mismas cuatro acciones en todas partes: mirarlo, agregar uno, cambiarlo, quitarlo.
REST modela todo como recursos en URLs (/users/42) sobre los que actuás con verbos HTTP, devolviendo normalmente JSON. Es simple, cacheable, depurable en un navegador, y entendido en todas partes — el default para APIs públicas. Los puntos débiles: a menudo recibís más datos de los que necesitás, o tenés que hacer varias llamadas para llenar una sola pantalla.
GraphQL: pedí exactamente los campos que querés
Un buffet donde, en vez de menús fijos, le entregás a la cocina una lista precisa y recibís exactamente eso — ni más, ni menos.
GraphQL da un solo endpoint donde el cliente escribe una query por precisamente los campos que necesita, en un único round trip — terminando con el over- y under-fetching de REST. Brillante cuando muchos clientes distintos (web, mobile, partners) necesitan distintas rebanadas de un grafo de datos complejo. El precio: el caching es más difícil, y la flexibilidad empuja complejidad real a tu servidor.
gRPC: llamá a una función remota como si fuera local
Un intercomunicador entre dos salas del mismo edificio — escueto, rápido y privado, porque ambos lados ya comparten la misma taquigrafía.
gRPC usa Protocol Buffers (binario compacto) sobre HTTP/2 para dejar que un servicio llame a los métodos de otro directamente, con un contrato tipado y streaming incorporado. Es rápido y estricto — ideal para tráfico interno servicio-a-servicio. Los trade-offs: no es nativamente amigable con el navegador, y el payload binario no es legible para humanos, así que depurás con herramientas, no con los ojos.
Y el anciano: SOAP
Un contrato formal por triplicado, sellado y certificado ante notario — pesado, pero inequívoco.
Antes de REST, SOAP envolvía las llamadas en sobres XML estrictos con contratos formales. Es verboso y anticuado, pero su rigor todavía corre en banca, pagos e integraciones empresariales. Probablemente no construyas uno nuevo — pero bien puede que tengas que hablar con uno.
REST para que todos lo entiendan. GraphQL para dejar que los clientes elijan. gRPC para ser rápido entre tus propios servicios.
El pregunta/respuesta plano tiene un hueco: el servidor no puede hablar primero. Cuando el cliente necesita enterarse de las cosas a medida que pasan, echás mano de uno de estos.
Polling: seguir preguntando «¿algo nuevo?»
Un chico en un viaje en auto preguntando «¿ya llegamos?» cada dos minutos. Simple — y casi siempre saliva desperdiciada.
La opción más cruda: el cliente vuelve a pedir con un temporizador. Long-polling lo mejora manteniendo cada petición abierta hasta que realmente hay algo para decir, y entonces el cliente pregunta de nuevo de inmediato. Funciona en todas partes y no necesita un protocolo especial — pero es derrochador y lento al lado de un stream de verdad. Un buen fallback, un pobre default.
Server-Sent Events: un stream de una sola vía desde el servidor
Una transmisión de radio — la emisora te transmite continuamente; vos solo escuchás, no respondés por el mismo canal.
SSE mantiene una conexión HTTP abierta y deja que el servidor empuje un stream de actualizaciones al cliente, con reconexión automática, por casi ningún overhead. Perfecto para feeds de una sola vía: marcadores en vivo, notificaciones, un dashboard que tictaquea — y es cómo un LLM hace streaming de tokens hacia una UI de chat. Si el cliente no necesita responder por la misma línea, SSE es la herramienta de tiempo real más simple.
WebSocket: una línea de dos vías, abierta en ambos sentidos
Una línea telefónica abierta dejada descolgada — cualquiera de los dos lados puede hablar en el instante en que tiene algo, sin volver a discar.
Un WebSocket eleva una conexión HTTP a un canal persistente y full-duplex donde cliente y servidor mandan mensajes libremente, a la latencia más baja y con un overhead mínimo por mensaje. La herramienta correcta cuando ambos lados hablan constantemente: chat, juegos multijugador, edición colaborativa, trading en vivo. Es más para operar que SSE, así que usalo cuando genuinamente necesitás dos vías.
Webhooks: no nos llames, te llamamos nosotros
Dejar tu número en una tienda para que te llamen cuando llegue tu pedido — en vez de volver caminando cada hora a chequear.
Un webhook invierte la dirección: registrás una URL, y el otro servicio le hace una petición HTTP cuando ocurre un evento. Ejemplo: Stripe POSTs a tu endpoint en el momento en que un pago tiene éxito; GitHub pinga tu servidor en cada push. Es la forma estándar en que los servicios se notifican entre sí sin que nadie esté sentado en un loop de polling.
Si el servidor debe hablar primero, dejá el polling. Streameá en una vía con SSE, en ambas con WebSocket.
A veces A no debería llamar a B directamente para nada. Poné un broker entre ellos, y el emisor puede disparar y olvidar mientras el receptor trabaja a su propio ritmo.
La idea: un intermediario que retiene mensajes
Una oficina de correos entre emisor y destinatario — dejás la carta y te vas; ellos la recogen cuando están listos. Ninguno tiene que estar presente en el mismo momento.
En vez de una llamada directa, el emisor le entrega un mensaje a un broker, que lo entrega a uno o más receptores. Eso los desacopla en el tiempo (el receptor puede ser lento, o estar brevemente caído) y en conocimiento (el emisor no necesita saber quién escucha). Es la columna vertebral de los sistemas resilientes, con picos y asíncronos.
Colas de mensajes (AMQP / RabbitMQ): un trabajo, un worker
Un pico de pedidos en un diner — los tickets se amontonan en el riel, y el cocinero que esté libre agarra el siguiente.
Una cola retiene tareas hasta que un worker toma una, la procesa y la confirma. Protocolos como AMQP (RabbitMQ) agregan ruteo inteligente, reintentos y garantías de entrega. Ejemplo: tirar «enviar email de bienvenida» o «generar factura» a una cola para que la petición web regrese al instante mientras un worker maneja la parte lenta.
Kafka: un log durable que muchos pueden reproducir
El archivo de un diario — cada número guardado en orden, y cualquier cantidad de lectores puede empezar en cualquier punto y leer hacia adelante a su propio ritmo.
Kafka es menos una cola que un log durable y ordenado de eventos que muchos consumidores leen de forma independiente, y que sigue ahí después de leído. Está construido para un throughput enorme. Ejemplo: un solo stream de «pedido realizado» alimentando analytics, indexado de búsqueda y email a la vez — cada consumidor llevando su propia posición. Una cola: el mensaje desaparece una vez manejado. Kafka: la historia queda.
MQTT: pub/sub minúsculo para redes poco confiables
Un canal de walkie-talkie para una flota de camionetas de reparto — ráfagas cortas, bajo consumo, sin problema si una atraviesa brevemente un túnel.
MQTT es un protocolo publish/subscribe ultraligero construido para IoT: mensajes minúsculos, batería y ancho de banda mínimos, y tolerancia a enlaces inestables. Ejemplo: miles de sensores, dispositivos de casa inteligente o vehículos reportando telemetría por celular. Cuando el «cliente» es un chip barato en una red débil, MQTT encaja donde HTTP no lo hace.
No hagas esperar a quien llama por trabajo lento. Entregáselo a un broker y seguí adelante.
El protocolo es el sobre; el payload adentro igual necesita una forma que ambos lados acuerden. Esa elección es un trade silencioso entre legibilidad y velocidad.
JSON: legible, universal, el default
Una nota escrita a mano que cualquiera lee de un vistazo — un poco larga, pero sin decodificador necesario.
JSON es texto, legible para humanos, y soportado en todas partes — el cuerpo por defecto para APIs web y REST. Lo podés mirar a ojo en un navegador y depurar leyendo. El costo es tamaño y velocidad de parseo: es verboso y no el más rápido — casi siempre está bien, ocasionalmente el cuello de botella a escala.
Protocol Buffers y compañía: pequeño, rápido, binario
Un código de barras — ilegible para vos, pero escaneado al instante y empaquetado apretado. Necesitás el esquema para decodificarlo.
Formatos binarios como Protocol Buffers (usado por gRPC), más MessagePack y Avro, serializan los datos contra un esquema compartido en un payload compacto y rápido. La ganancia es tamaño y velocidad; el costo es que no lo podés leer a ojo, y ambos lados deben compartir el esquema. Vale la pena para tráfico de alto volumen, interno y crítico en performance.
XML: verboso, formal, todavía dando vueltas
Un documento legal — pesado de tags y estructura, preciso, y la primera elección de nadie para una nota rápida.
XML precede a JSON y carga esquema y validación ricos, al costo de ser voluminoso. Te lo vas a cruzar en servicios SOAP, formatos de documento y configuración. Rara vez la elección para algo nuevo, pero todavía cargando peso en montones de sistemas más viejos con los que vas a tener que integrarte.
Texto para ser entendido, binario para ser rápido. La mayoría de las APIs hace bien en defaultear a lo legible.
No elegís un protocolo para un sistema — elegís el correcto para cada conversación. Las apps reales corren varios a la vez.
Emparejá el protocolo con la conversación
Una caja de herramientas con un martillo, un destornillador, una llave. No discutís cuál es el mejor — mirás el trabajo que tenés enfrente.
Decidí por la forma del diálogo: una API pública que usan muchos clientes es REST; dos servicios internos que necesitan velocidad es gRPC; un cliente eligiendo campos exactos es GraphQL; el servidor streameando actualizaciones es SSE; ambos lados en vivo es WebSocket; trabajo de fondo lento es una cola; un servicio diciéndole a otro que un evento ocurrió es un webhook. La pregunta nunca es «qué protocolo» sino «cuál, para esta línea».
Empezá simple; echá mano de lo exótico solo cuando duele
No tendés una vía de tren para llevar un saco de harina cruzando el patio.
La mayoría de los productos llega muy lejos con REST + JSON sobre HTTPS, más una cola para los jobs de fondo. gRPC, GraphQL, Kafka y WebSockets son respuestas a dolores específicos — latencia servicio-a-servicio, clientes hambrientos, volúmenes enormes de eventos, interacción en vivo. Adoptalos cuando sentís ese dolor exacto, no porque suenan modernos. El protocolo más simple que encaja con la conversación casi siempre gana.
- Quién empieza la conversación — ¿el cliente, o el servidor? - Con qué frecuencia, y qué tan grandes son los mensajes? - Uno a uno, o uno a muchos a lo largo del tiempo? - ¿Necesita ser legible, o lo más pequeño y rápido posible? - Quién es el cliente — ¿un navegador, una app mobile, otro de mis servicios, un dispositivo minúsculo? - **¿Alcanza con REST
- JSON plano** antes de echar mano de algo más elaborado?
- Elegiste gRPC para una API pública que los navegadores tienen que llamar. - WebSockets donde un botón de refrescar alcanzaría. - Kafka para mover unos pocos cientos de mensajes al día. - GraphQL para un solo cliente que trae los mismos tres campos cada vez. - Un formato binario para datos que constantemente necesitás leer y depurar a mano.
- Cliente y servidor concuerdan sin código de pegamento traduciendo entre ellos. - El protocolo encaja con el tráfico — streaming para streams, pregunta/respuesta para preguntas. - Podés depurarlo con las herramientas que el protocolo espera — un navegador, logs, o tooling de proto. - La encriptación está prendida por default, en todas partes. - Cada conversación usa el protocolo más simple que le encaja, y nada más.
Las apps modernas no se construyen sobre un solo protocolo. Se construyen sobre el protocolo correcto para cada conversación — con TLS alrededor de todos ellos.