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.
21 conceptos · un diagrama para cada uno · hoja de referencia al final
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í.
Protocol — 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.
Un protocolo fija dos 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.
- Qué es
Un contrato entre dos programas: forma del mensaje + orden de la charla.
- Ejemplo
HTTP: el cliente envía
GET /users/42, el servidor responde200 OKcon JSON. Nadie habla fuera de turno.- Ojo
- Si los lados leen el contrato distinto, obtenés ruido, no un error.
- Relaciones
Todos los demás conceptos de este curso son un protocolo o un formato concreto.
Protocol stack — 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 está un protocolo de transporte — TCP o UDP — que solo mueve bytes entre máquinas. Encima está un protocolo de aplicación — HTTP, gRPC, MQTT — que le da sentido a esos bytes. En el medio suele ir TLS, que sella el sobre. Casi siempre trabajás arriba — pero cuando las cosas se ponen lentas o inestables, la capa de abajo se filtra.
- Qué es
Los protocolos se apilan: el transporte mueve bytes, la capa de aplicación les da sentido.
- Ejemplo
- HTTP va sobre TLS, TLS sobre TCP, TCP sobre IP.
- Ojo
La lentitud y las caídas suelen venir de abajo — no se arreglan mirando fijo HTTP.
- Relaciones
TCP / UDP abajo, HTTP, gRPC, MQTT arriba, TLS en el medio.
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.
El mapa: 21 conceptos en cinco grupos
Un mapa del metro: primero ves las líneas enteras, después recorrés estación por estación.
Cada concepto del curso cae en uno de cinco grupos: los cimientos (sobre lo que va todo), pregunta–respuesta (preguntás, recibís una respuesta), tiempo real (el servidor habla primero), mensajería (un intermediario entre los lados) y formatos (la forma de los datos adentro).
Cómo leer cada concepto
Un pasaporte: los mismos campos para todos, así que es fácil compararlos.
Cada protocolo de abajo recibe el mismo tratamiento: su nombre en inglés (el término con el que vas a buscar en la documentación), una imagen de la vida real, un diagrama y una ficha con campos: qué es, cómo funciona, ejemplo, coste (lo que pagás), cuándo usarlo y relaciones. La regla principal: 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 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 hay unos pocos protocolos que rara vez tocás directamente pero de los que siempre dependés. Conocelos — deciden qué es 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 lento, pero no se pierde ni se mezcla nada.
TCP (Transmission Control Protocol) primero establece una conexión — el handshake. Después garantiza que cada byte llegue, en orden: el receptor confirma lo que recibió, y lo que se pierde se reenvía. Es el caballito de batalla debajo de la web, el correo y la mayoría de las APIs.
- Qué es
- Un transporte con garantía: todo llega, en orden, sin pérdidas.
- Cómo funciona
- Handshake, confirmaciones (ACK), reenvío de lo que se perdió.
- Ejemplo
Debajo de HTTP/1.1 y HTTP/2, el correo, las bases de datos, la mayoría de las APIs.
- Coste
Un poco de latencia por el establecimiento y por esperar los reenvíos. Casi siempre es un gran trato.
- Cuándo usarlo
- Cuando cada byte importa — casi siempre.
- Relaciones
- Lo opuesto es UDP. Encima van HTTP, TLS, los brokers.
UDP — dispará y olvidate, rápido y con pérdidas
Gritar a través de una sala ruidosa — rápido, pero si se pierde una palabra no parás a repetirla, seguís nomás.
UDP (User Datagram Protocol) envía paquetes sin handshake y sin garantía de llegada ni de orden. Suena mal hasta que querés velocidad antes que perfección: videollamadas, juegos en vivo, consultas DNS. Ahí, un frame perdido es mejor que un tirón mientras esperás un reenvío.
- Qué es
- Un transporte sin garantías: enviás y te olvidás.
- Cómo funciona
- Sin conexión, sin confirmaciones, sin reenvíos, sin orden.
- Ejemplo
Una videollamada: un frame viejo no sirve — mejor mostrar el siguiente.
- Coste
- Las pérdidas y el desorden quedan de tu lado (manejarlos o tolerarlos).
- Cuándo usarlo
Cuando lo fresco vale más que lo completo: voz, video, juegos, DNS.
- Relaciones
- QUIC está construido sobre él, y HTTP/3 sobre QUIC.
HTTP — el idioma de pregunta y respuesta de la web
El mostrador de un comercio: pedís una cosa, recibís una respuesta, y el empleado se olvida de vos apenas te vas.
HTTP (HyperText Transfer Protocol) va sobre TCP y define el conocido pedido/respuesta: los métodos GET, POST, PUT, DELETE y los códigos de estado 200, 404, 500. Es sin estado (stateless) — cada pedido se sostiene solo — que es justo lo que le permite a la web escalar a miles de millones de llamadas.
- Qué es
- El protocolo de aplicación de «preguntás, recibís una respuesta».
- Cómo funciona
Pedido = método + ruta + cabeceras + cuerpo. Respuesta = código de estado + cabeceras + cuerpo.
- Ejemplo
GET /users/42→200 OKcon el usuario en JSON.- Coste
- El servidor no puede hablar primero — solo puede responder.
- Cuándo usarlo
- Casi toda API que vas a tocar lo habla.
- Relaciones
La base de REST, GraphQL, SSE, Webhook; WebSocket arranca desde él.
TLS y HTTPS — lo mismo, pero sellado
La misma carta, ahora dentro de un sobre a prueba de manipulación y con la firma verificada del remitente por fuera.
TLS (Transport Layer Security) envuelve HTTP (y otros protocolos) en cifrado e identidad: nadie en el medio puede leer ni falsificar el tráfico, y un certificado prueba que el servidor es quien dice ser. Es la «S» de HTTPS — y ya no es opcional: los navegadores, las tiendas de apps y las APIs lo dan por hecho.
- Qué es
- Una capa de cifrado e identidad encima del transporte.
- Cómo funciona
Un certificado avala al servidor; después todo el tráfico va cifrado.
- Ejemplo
- El candado en la barra de direcciones de tu navegador es TLS.
- Coste
- Hay que emitir y renovar certificados (hoy casi gratis).
- Cuándo usarlo
Si los datos salen de tu máquina, deberían ir dentro de TLS.
- Relaciones
- Envuelve HTTP, gRPC, WebSocket, los brokers.
HTTP/2 y HTTP/3 — la misma tubería, más ancha
Un camino de un solo carril que se volvió autopista de varios carriles — y después se reconstruyó para que un auto parado ya no bloquee todos los carriles.
HTTP/1.1 manejaba un pedido a la vez por conexión. HTTP/2 corre muchos sobre una sola conexión — eso es el multiplexing. Pero va sobre TCP, así que un solo paquete perdido frena todos los streams — eso es el head-of-line blocking. HTTP/3 pasa a QUIC (sobre UDP): una pérdida frena solo a su propio stream, las conexiones se abren en más o menos un viaje de ida y vuelta, y un celular puede pasar de Wi-Fi a datos móviles sin cortarse.
- Qué es
Versiones nuevas de HTTP: los mismos pedidos, un camino más rápido por debajo.
- Cómo funciona
HTTP/2 — muchos streams en una conexión TCP. HTTP/3 — streams independientes sobre QUIC encima de UDP.
- Ejemplo
Una página con cien imágenes las carga en paralelo por una sola conexión.
- Coste
- Casi ninguno para vos — se activa en el servidor o en el CDN.
- Cuándo usarlo
Por defecto, donde esté soportado. El código de tu app no cambia.
- Relaciones
- gRPC corre sobre HTTP/2; HTTP/3 corre sobre UDP.
Construís en lo alto de la pila, pero lo de abajo decide qué es posible. Y el cifrado no es una capa que se agrega después.
Casi toda la charla entre app y servidor, o entre servicios, es «hacés una pregunta, recibís una respuesta». Dominan tres estilos, que cambian simplicidad por potencia de maneras distintas. Más un veterano con el que todavía te vas a cruzar.
REST — recursos sobre verbos HTTP simples
Una biblioteca bien organizada donde cada libro tiene una dirección fija, y usás las mismas cuatro acciones en todos lados: mirarlo, agregar uno, cambiarlo, sacarlo.
REST (Representational State Transfer) modela todo como recursos en URLs como /users/42, sobre los que se actúa con verbos HTTP, y que normalmente devuelven JSON. Es simple, cacheable, depurable en un navegador y se entiende en todos lados — el estándar para las APIs públicas.
- Qué es
- Un estilo de API: recursos en URLs + verbos HTTP + normalmente JSON.
- Ejemplo
GET /users/42lo lee,DELETE /users/42lo borra.- Coste
A menudo recibís más datos de los que necesitás (over-fetching), o hacés varias llamadas para llenar una pantalla (under-fetching).
- Cuándo usarlo
Una API pública para muchos clientes. Casi siempre el punto de partida.
- Relaciones
Va sobre HTTP, habla JSON. GraphQL cierra sus puntos débiles.
GraphQL — pedí exactamente los campos que querés
Un buffet donde, en vez de menús fijos, le das a la cocina una lista precisa y te traen exactamente eso — ni más ni menos.
GraphQL ofrece un solo endpoint donde el cliente escribe una consulta con justo los campos que necesita, en un único viaje — y se acaban el over-fetching y el under-fetching de REST. Brillante cuando muchos clientes distintos (web, móvil, partners) necesitan porciones distintas de un grafo de datos complejo.
- Qué es
- Un endpoint; el cliente describe la forma de la respuesta.
- Ejemplo
Una pantalla móvil necesita un nombre y los totales de los pedidos — pide solo eso.
- Coste
El caché es más difícil, y la flexibilidad le pasa complejidad real a tu servidor.
- Cuándo usarlo
Muchos clientes distintos y un grafo de datos complejo y conectado.
- Relaciones
Una respuesta a los puntos débiles de REST; normalmente va sobre HTTP con JSON.
gRPC — llamá a una función remota como si fuera local
Un intercomunicador entre dos habitaciones del mismo edificio — escueto, rápido y privado, porque ambos lados ya comparten la misma jerga.
gRPC es un framework de RPC (Remote Procedure Call) — llamar a una función a través de la red. Usa Protocol Buffers (binario compacto) sobre HTTP/2 para que un servicio pueda llamar directamente a los métodos de otro, con un contrato tipado y streaming incluido. Rápido y estricto — ideal para el tráfico interno entre servicios.
- Qué es
Llamar a la función de otro servicio por la red, con un contrato estricto.
- Ejemplo
El servicio de pedidos llama a
inventory.Reserve(item, 2)en el servicio del almacén.- Coste
No es nativo para navegadores; el payload binario no es legible para humanos, así que depurás con herramientas, no a ojo.
- Cuándo usarlo
- Tus propios servicios hablando mucho entre sí, y rápido.
- Relaciones
- Va sobre HTTP/2, habla Protobuf.
SOAP — el veterano
Un contrato formal por triplicado, sellado y notariado — pesado, pero sin ambigüedades.
Antes de REST, SOAP (Simple Object Access Protocol) envolvía las llamadas en sobres XML estrictos con un contrato formal WSDL. Es verboso y anticuado, pero su rigor sigue vivo en la banca, los pagos y las integraciones empresariales.
- Qué es
- Un protocolo de llamadas XML estricto con un contrato formal.
- Ejemplo
- Una integración bancaria:
GetBalancedentro de unsoap:Envelope. - Coste
- Verboso, pesado, con poca herramienta moderna.
- Cuándo usarlo
Probablemente no construyas uno nuevo — pero quizás tengas que hablar con uno.
- Relaciones
Habla XML; en los sistemas nuevos su lugar lo tomaron REST y gRPC.
REST para que lo entienda todo el mundo. GraphQL para dejar que los clientes elijan. gRPC para ser rápido entre tus propios servicios.
El pedido/respuesta simple tiene un hueco: el servidor no puede hablar primero. Cuando el cliente necesita enterarse de las cosas a medida que pasan, recurrís a una de estas.
Polling — seguir preguntando «¿hay algo nuevo?»
Un chico en un viaje en auto preguntando «¿ya llegamos?» cada dos minutos. Simple — y casi todo aliento desperdiciado.
Polling es la opción más tosca: el cliente repite el pedido con un temporizador. El Long-polling la mejora: el servidor mantiene cada pedido abierto hasta que realmente hay algo que decir, y entonces el cliente vuelve a preguntar de inmediato. Funciona en todos lados y no necesita ningún protocolo especial.
- Qué es
- El cliente le pregunta al servidor por novedades, una y otra vez.
- Ejemplo
Una página de estado del pedido que le pregunta al servidor cada 10 segundos.
- Coste
- Derrochador y con retraso al lado de un stream de verdad.
- Cuándo usarlo
- Un buen plan B, un mal plan por defecto.
- Relaciones
- Los reemplazos de verdad son SSE y WebSocket.
SSE — un stream de una sola vía desde el servidor
Una transmisión de radio — la emisora te transmite de forma continua; vos solo escuchás, no contestás por el mismo canal.
SSE (Server-Sent Events) mantiene abierta una respuesta HTTP y deja que el servidor empuje un stream de actualizaciones al cliente, con reconexión automática y casi sin sobrecarga. Perfecto para feeds de una sola vía: resultados en vivo, notificaciones, un dashboard que late — y así es como un LLM transmite tokens a una interfaz de chat.
- Qué es
Un stream de eventos de una sola vía, del servidor al navegador, sobre HTTP común.
- Ejemplo
La respuesta de un chatbot aparece palabra por palabra mientras el modelo la escribe.
- Coste
- Una sola dirección; las respuestas del cliente van como pedidos aparte.
- Cuándo usarlo
Si el cliente no necesita contestar por la misma línea, SSE es la herramienta de tiempo real más simple.
- Relaciones
- Va sobre HTTP; su hermano de doble vía es WebSocket.
WebSocket — una línea de doble vía, abierta en ambos sentidos
Una línea telefónica abierta con el tubo descolgado — cualquiera de los dos habla apenas tiene algo que decir, sin volver a marcar.
Un WebSocket actualiza (upgrade) una conexión HTTP a un canal persistente y full-duplex donde cliente y servidor envían mensajes con libertad, con la latencia más baja y una sobrecarga minúscula por mensaje. La herramienta correcta cuando los dos lados hablan sin parar: chat, juegos multijugador, edición colaborativa, trading en vivo.
- Qué es
Un canal persistente donde los dos lados pueden hablar en cualquier momento.
- Ejemplo
Chat: el «escribiendo…», los mensajes nuevos y los cursores de tus compañeros viajan en ambos sentidos.
- Coste
Más para operar que SSE: conexiones de larga vida, reconexiones, balanceo de carga.
- Cuándo usarlo
- Cuando de verdad necesitás doble vía.
- Relaciones
- Arranca desde HTTP; la alternativa de una sola vía es SSE.
Webhook — no nos llames, te llamamos nosotros
Dejarle tu número a un comercio para que te llamen cuando llegue tu pedido — en vez de volver caminando cada hora a ver.
Un webhook invierte la dirección: registrás una URL, y el otro servicio hace un pedido HTTP a ella cuando ocurre un evento. Es la forma estándar de que los servicios se avisen entre sí sin que nadie esté en un bucle de polling.
- Qué es
- Un servicio te envía un pedido HTTP cuando algo pasa de su lado.
- Ejemplo
Stripe hace
POSTa tu endpoint en el momento en que un pago sale bien; GitHub avisa a tu servidor en cada push.- Coste
Tu endpoint tiene que ser alcanzable desde afuera y aguantar reintentos y fallos.
- Cuándo usarlo
- Un servicio avisándole a otro: «pasó un evento».
- Relaciones
- HTTP común, solo que al revés; reemplaza al Polling.
Si el servidor tiene que hablar primero, dejá de hacer polling. Stream de una vía con SSE, de dos vías con WebSocket.
A veces A no debería llamar a B directamente. Poné un broker entre los dos, y el emisor puede enviar y olvidarse mientras el receptor trabaja a su propio ritmo.
Message broker — un intermediario que guarda los mensajes
Una oficina de correos entre el remitente y el destinatario — dejás la carta y te vas; el otro la retira cuando está listo. Ninguno tiene que estar presente al mismo tiempo.
En lugar de una llamada directa, el productor le entrega un mensaje a un message broker, que lo hace llegar a uno o más consumidores. Eso los desacopla en el tiempo (el receptor puede ser lento, o estar caído un rato) y en el conocimiento (el emisor no necesita saber quién escucha). Es la columna vertebral de los sistemas asincrónicos, resilientes y con picos de carga.
- Qué es
- Un intermediario que acepta, guarda y reparte mensajes.
- Ejemplo
El servidor web deja «pedido creado»; el almacén y el correo lo retiran.
- Coste
- Un sistema más para operar; ya no existe el «respondeme ahora».
- Cuándo usarlo
- Trabajo lento, picos de tráfico, muchos receptores.
- Relaciones
Sus formas son la cola (AMQP), el log (Kafka), el pub/sub (MQTT).
Message queue (AMQP / RabbitMQ) — un trabajo, un worker
Un pico de pedidos en una parrilla — los tickets se acumulan en el riel, y el cocinero que esté libre agarra el siguiente.
Una message queue guarda tareas hasta que un worker toma una, la procesa y la confirma (ack). Protocolos como AMQP (el que habla RabbitMQ) agregan enrutamiento inteligente, reintentos y garantías de entrega.
- Qué es
- Los trabajos esperan en fila; cada uno lo toma exactamente un worker.
- Ejemplo
Dejar «enviar correo de bienvenida» o «generar factura» en una cola para que el pedido web vuelva al instante mientras un worker se ocupa de la parte lenta.
- Coste
Un trabajo ya procesado desaparece — no podés volver a leer el historial.
- Cuándo usarlo
- Trabajo en segundo plano que no debe hacer esperar al usuario.
- Relaciones
Una forma de broker; si hay muchos lectores y necesitás historial — Kafka.
Kafka — un log durable que muchos pueden reproducir
Un archivo de diario — cada edición guardada en orden, y cualquier cantidad de lectores puede empezar donde quiera y leer hacia adelante a su propia velocidad.
Kafka es menos una cola que un log de eventos durable y ordenado que muchos consumidores leen de forma independiente, y que sigue ahí después de leído. Cada lector recuerda su propia posición — su offset. Está hecho para un throughput enorme.
- Qué es
Un diario de eventos, conservado y leído por muchos de forma independiente.
- Ejemplo
Un único stream de «pedido realizado» alimentando analítica, indexado de búsqueda y correo a la vez.
- Coste
- Un sistema pesado; excesivo para unos cientos de mensajes por día.
- Cuándo usarlo
Volúmenes enormes de eventos y muchos lectores que necesitan el historial.
- Relaciones
Una cola: el mensaje desaparece una vez procesado. Kafka: el historial se queda.
MQTT — pub/sub diminuto para redes poco confiables
Un canal de walkie-talkie para una flota de camionetas de reparto — ráfagas cortas, poca batería, no pasa nada si una cruza un túnel un rato.
MQTT es un protocolo de publicación/suscripción (pub/sub) ultraliviano pensado para IoT: los dispositivos publican mensajes en topics, y el broker se los entrega a los suscriptores. Mensajes diminutos, mínimo consumo de batería y ancho de banda, y tolerancia a enlaces inestables.
- Qué es
Un protocolo pub/sub liviano para dispositivos débiles en redes débiles.
- Ejemplo
Miles de sensores, dispositivos de casa inteligente o vehículos reportando telemetría por red celular.
- Coste
Necesita un broker; la herramienta equivocada para la web de todos los días.
- Cuándo usarlo
Cuando el «cliente» es un chip barato en una red débil, MQTT encaja donde HTTP no.
- Relaciones
- Una forma de broker; su transporte es TCP.
No hagas esperar al que llama por un trabajo lento. Entregáselo a un broker y seguí.
El protocolo es el sobre; la carga de adentro todavía necesita una forma que ambos lados acuerden. Esa elección es un intercambio silencioso entre legibilidad y velocidad.
JSON — legible, universal, el estándar
Una nota escrita a mano que cualquiera lee de un vistazo — un poco larga, pero sin necesidad de decodificador.
JSON (JavaScript Object Notation) es texto, legible para humanos y soportado en todos lados — el cuerpo por defecto de las APIs web y REST. Lo podés revisar a ojo en un navegador y depurar leyendo. Abajo está el mismo registro en tres formatos: la diferencia de tamaño se ve a simple vista.
- Qué es
- Un formato de texto clave–valor que puede leer cualquier persona o máquina.
- Ejemplo
{"id": 42, "name": "Ann"}- Coste
Verboso y no el más rápido de parsear — normalmente da igual, ocasionalmente es el cuello de botella a gran escala.
- Cuándo usarlo
- Por defecto para la web y las APIs públicas.
- Relaciones
- El idioma de REST y GraphQL; la alternativa binaria es Protobuf.
Protocol Buffers y compañía — chicos, rápidos, binarios
Un código de barras — ilegible para vos, pero se escanea al instante y viene compacto. Necesitás el esquema para decodificarlo.
Los formatos binarios como Protocol Buffers (Protobuf) — usado por gRPC — más MessagePack y Avro, serializan los datos contra un esquema compartido en una carga compacta y rápida. La ganancia es tamaño y velocidad; el costo es que no se puede leer a ojo, y ambos lados tienen que compartir el esquema.
- Qué es
- Un formato binario compacto definido de antemano por un esquema.
- Ejemplo
message User { int32 id = 1; string name = 2; }→ 7 bytes por el cable.- Coste
- Ilegible a ojo; ambos lados deben mantener el esquema sincronizado.
- Cuándo usarlo
- Tráfico de alto volumen, interno y crítico para el rendimiento.
- Relaciones
- El idioma de gRPC; la alternativa legible es JSON.
XML — verboso, formal, todavía presente
Un documento legal — cargado de etiquetas y estructura, preciso, y la primera opción de nadie para una nota rápida.
XML (eXtensible Markup Language) es anterior a JSON y trae esquema y validación ricos, al precio de ser voluminoso — cada valor va entre una etiqueta de apertura y una de cierre. Te lo vas a encontrar en servicios SOAP, formatos de documentos y configuración.
- Qué es
- Un formato de texto basado en etiquetas con un esquema estricto.
- Ejemplo
`
42 Ann `
- Coste
- Voluminoso: el mismo registro es casi el doble de largo que en JSON.
- Cuándo usarlo
Rara vez para algo nuevo — pero todavía sostiene un montón de sistemas más viejos.
- Relaciones
- El idioma de SOAP; en la web fue reemplazado por JSON.
Texto para que se entienda, binario para que sea rápido. La mayoría de las APIs hacen bien en usar por defecto lo legible.
No elegís un protocolo para un sistema — elegís el correcto para cada conversación. Las apps reales usan 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 la mejor — mirás el trabajo que tenés enfrente.
Decidí por la forma de la charla. La pregunta nunca es «qué protocolo» sino «cuál, para esta línea».
Empezá simple; recurrí a lo exótico solo cuando duela
No tendés una vía de tren para llevar un saco de harina al otro lado del patio.
La mayoría de los productos llegan muy lejos con REST + JSON sobre HTTPS, más una cola para los trabajos en segundo plano. gRPC, GraphQL, Kafka y los WebSockets son respuestas a dolores específicos — latencia entre servicios, clientes hambrientos, volúmenes enormes de eventos, interacción en vivo. Adoptalos cuando sientas ese dolor exacto, no porque suenen modernos. El protocolo más simple que encaje con la conversación suele ganar.
Cómo se conecta todo
Una torta de capas: cada capa descansa sobre la de abajo, y desde arriba solo ves el glaseado.
Los formatos van dentro de los estilos de API, los estilos van sobre HTTP o sobre brokers, todo está envuelto en TLS, y debajo está TCP o UDP. Una sola app real fácilmente usa la mitad de este cuadro a la vez.
- ¿Quién inicia la conversación — el cliente, o el servidor?
- ¿Con qué frecuencia y de qué tamaño son los mensajes?
- ¿Uno a uno, o uno a muchos a lo largo del tiempo?
- ¿Tiene que ser legible, o lo más chico y rápido posible?
- ¿Quién es el cliente — un navegador, una app móvil, otro de mis servicios, un dispositivo diminuto?
- ¿Alcanza con REST + JSON simple antes de recurrir a algo más sofisticado?
- Elegiste gRPC para una API pública a la que tienen que llamar los navegadores.
- WebSockets donde alcanzaba con un botón de actualizar.
- Kafka para mover unos cientos de mensajes por día.
- GraphQL para un solo cliente que pide los mismos tres campos cada vez.
- Un formato binario para datos que constantemente necesitás leer y depurar a mano.
- Cliente y servidor se entienden sin código pegamento que traduzca entre ellos.
- El protocolo encaja con el tráfico — streaming para streams, pedido/respuesta para preguntas.
- Lo podés depurar con las herramientas que el protocolo espera — un navegador, logs, o herramientas de proto.
- El cifrado está activado por defecto, en todos lados.
- Cada conversación usa el protocolo más simple que le encaja, y nada más.
Hoja de referencia: los 21 conceptos
Básicos
- Protocolel acuerdo
Un contrato entre dos programas: forma del mensaje + orden de la charla.
- Protocol stackcapas
Capas: el transporte mueve bytes, el protocolo de aplicación les da sentido.
Cimientos
- TCPTransmission Control Protocol
Entrega confiable y en orden: handshake, confirmaciones, reenvíos.
- UDPUser Datagram Protocol
Dispará y olvidate: rápido pero con pérdidas. Video, juegos, DNS.
- HTTPHyperText Transfer Protocol
Pedido–respuesta sin estado: métodos y códigos de estado.
- TLS / HTTPSTransport Layer Security
Cifrado + identidad del servidor. HTTPS = HTTP dentro de TLS.
- HTTP/2 · HTTP/3multiplexing, QUIC
Muchos pedidos por una conexión; HTTP/3 sobre QUIC encima de UDP.
Pregunta y respuesta
- RESTRepresentational State Transfer
Recursos en URLs + verbos HTTP + JSON. El estándar de las APIs públicas.
- GraphQLun lenguaje de consulta para APIs
Un endpoint; el cliente pide exactamente los campos que necesita.
- gRPCRemote Procedure Call
Llamar a la función de otro servicio: HTTP/2 + Protobuf, contrato estricto.
- SOAPSimple Object Access Protocol
Sobres XML estrictos y WSDL. Sigue vivo en bancos y empresas.
Tiempo real y push
- Pollinglong-polling
El cliente sigue preguntando «¿hay algo nuevo?». Un plan B.
- SSEServer-Sent Events
Un stream del servidor al cliente por una respuesta HTTP. Streaming de tokens de LLM.
- WebSocketcanal full-duplex
Una línea abierta, ambos lados hablan cuando quieren. Chat, juegos.
- Webhookcallback HTTP
Un servicio hace POST a tu URL cuando ocurre un evento.
Mensajería
- Message brokerel intermediario
Desacopla al emisor y al receptor en el tiempo y en el conocimiento.
- Message queueAMQP, RabbitMQ
Un trabajo espera en fila; exactamente un worker lo toma.
- Kafkalog de eventos
Un log durable: muchos lectores, cada uno con su posición, el historial se queda.
- MQTTpub/sub para IoT
Mensajes livianos por topics para dispositivos y redes débiles.
Formatos
- JSONJavaScript Object Notation
Texto legible, el estándar de la web. Un poco verboso.
- ProtobufProtocol Buffers
Binario compacto según un esquema. Rápido, pero ilegible a ojo.
- XMLeXtensible Markup Language
Etiquetas y un esquema estricto. Voluminoso; vive en sistemas viejos y en SOAP.
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.