# Los protocolos son cómo hablan los programas Curso exprés sobre los protocolos de intercambio de datos con los que funcionan las apps modernas. 21 conceptos — TCP, UDP, HTTP, TLS, HTTP/2 y HTTP/3, REST, GraphQL, gRPC, SOAP, Polling, SSE, WebSocket, Webhook, Message Broker, colas (AMQP), Kafka, MQTT, JSON, Protobuf, XML — cada uno con su nombre en inglés, un diagrama, una ficha (qué es → cómo funciona → ejemplo → coste) y enlaces a los demás. Al final, una hoja de referencia de una página. - **Author:** Fedor Chishchin - **Level:** intro - **Reading time:** ~30 minutos de lectura - **Published:** 2026-06-02 - **Source:** https://fedorthinks.com/es/learn/data-protocols-express --- ## 1. Qué es un protocolo 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. #### Protocol (el acuerdo) - **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 responde `200 OK` con 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. _Diagram: La pila de protocolos: bytes abajo, significado arriba. Cada capa se apoya en la de abajo._ #### Protocol stack (capas) - **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). _Diagram: Cinco grupos de conceptos — los capítulos 2–6 los siguen._ ### 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. > **Antes de elegir un protocolo:** «¿Quién necesita hablar, con qué frecuencia, y qué tan rápido — y quién está del otro lado?» > Un protocolo es un acuerdo. Elegilo por la forma de la conversación, no por lo que está de moda. ## 2. Los cimientos 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. _Diagram: TCP: el handshake SYN → SYN-ACK → ACK, y después los datos con confirmaciones. ¿Se perdió? Se reenvía._ #### TCP (Transmission Control Protocol) - **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. _Diagram: UDP: el paquete 3 se perdió — y nadie lo va a reenviar. A cambio, nada espera._ #### UDP (User Datagram Protocol) - **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. _Diagram: HTTP: un pedido, una respuesta. El método dice qué hacer; el código de estado dice cómo salió._ #### HTTP (HyperText Transfer Protocol) - **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 OK` con 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. _Diagram: HTTPS = HTTP dentro de TLS. Un atacante en el mismo Wi-Fi solo ve bytes cifrados._ #### TLS / HTTPS (Transport Layer Security) - **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. _Diagram: HTTP/1.1 — de a uno. HTTP/2 — en paralelo, pero una pérdida los frena a todos. HTTP/3 — una pérdida solo afecta a su propio stream._ #### HTTP/2 · HTTP/3 (multiplexing, QUIC) - **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**. > **La pregunta de los cimientos:** «¿Necesito cada byte garantizado (TCP) — o velocidad donde una pérdida ocasional no importa (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. ## 3. Pregunta y respuesta 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.** _Diagram: REST: un recurso, una dirección, cuatro verbos para todo. El punto débil — muchas llamadas para una pantalla._ #### REST (Representational State Transfer) - **Qué es:** Un estilo de API: recursos en URLs + verbos HTTP + normalmente JSON. - **Ejemplo:** `GET /users/42` lo lee, `DELETE /users/42` lo 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. _Diagram: GraphQL: el cliente lista los campos, un endpoint los junta de varias fuentes y devuelve exactamente eso._ #### GraphQL (un lenguaje de consulta para APIs) - **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.** _Diagram: gRPC: un contrato .proto compartido genera el código. El servicio A llama al método de B como si fuera local._ #### gRPC (Remote Procedure Call de Google) - **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. _Diagram: SOAP: cada llamada es un sobre XML con cabecera y cuerpo, y el WSDL describe qué se puede llamar._ #### SOAP (Simple Object Access Protocol) - **Qué es:** Un protocolo de llamadas XML estricto con un contrato formal. - **Ejemplo:** Una integración bancaria: `GetBalance` dentro de un `soap: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**. > **La pregunta de las APIs:** «¿Es una API pública que consumen muchos clientes (REST), un cliente hambriento que elige campos (GraphQL), o dos servicios míos hablando rápido (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. ## 4. Tiempo real y push 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. _Diagram: Arriba, polling: tres «no» vacíos por un «sí». Abajo, long-polling: el servidor se queda callado hasta que hay novedades._ #### Polling / Long-polling (preguntar con un temporizador) - **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. _Diagram: SSE: el servidor manda eventos por una respuesta HTTP abierta. El cliente no puede contestar por esa línea._ #### SSE (Server-Sent Events) - **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.** _Diagram: WebSocket: un pedido HTTP con Upgrade, una respuesta 101 — y desde ahí los dos lados escriben cuando quieran._ #### WebSocket (canal full-duplex) - **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. _Diagram: Webhook: entregás tu URL una sola vez — de ahí en adelante Stripe te hace POST cuando un pago sale bien._ #### Webhook (callback HTTP) - **Qué es:** Un servicio te envía un pedido HTTP cuando algo pasa de su lado. - **Ejemplo:** Stripe hace `POST` a 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**. > **La pregunta del tiempo real:** «¿El servidor solo necesita empujar al cliente (SSE), hablan los dos lados (WebSocket), o es un servicio avisándole a otro (webhook)?» > Si el servidor tiene que hablar primero, dejá de hacer polling. Stream de una vía con SSE, de dos vías con WebSocket. ## 5. Mensajería y asincronía 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. _Diagram: Un broker en el medio: el emisor entrega y se va, los receptores retiran a su propio ritmo._ #### Message broker (el intermediario) - **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. _Diagram: Una cola: la app web le responde al usuario de inmediato, y el worker que esté libre toma el siguiente trabajo._ #### Message queue (AMQP, RabbitMQ) - **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. _Diagram: Kafka: los eventos se agregan al final del log, y cada consumidor lee desde su propia posición._ #### Kafka (log de eventos, event streaming) - **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. _Diagram: MQTT: los sensores publican en topics, el broker entrega cada mensaje a todos los suscritos._ #### MQTT (pub/sub para IoT) - **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**. > **La pregunta de la mensajería:** «¿El receptor puede trabajar después, a su propio ritmo — y el evento necesita un solo manejador (cola) o muchos lectores a lo largo del tiempo (log)?» > No hagas esperar al que llama por un trabajo lento. Entregáselo a un broker y seguí. ## 6. Los datos que viajan por el cable 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. _Diagram: Un registro {id: 42, name: Ann}: JSON son 22 bytes, XML 40, Protobuf 7._ #### JSON (JavaScript Object Notation) - **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. _Diagram: Protobuf: el esquema dice que el campo 1 es id y el campo 2 es name. Sin él, los 7 bytes son solo números._ #### Protobuf (Protocol Buffers, MessagePack, Avro) - **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. #### XML (eXtensible Markup Language) - **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**. > **La pregunta del formato:** «¿Valoro leerlo y depurarlo a ojo (texto) — o el tamaño y la velocidad en crudo (binario)?» > 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. ## 7. Elegir bien 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». _Diagram: A la izquierda, la forma de la conversación; a la derecha, el protocolo afinado para ella._ ### 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. _Diagram: Cómo se conecta: formato → estilo de API → protocolo → TLS → transporte. gRPC se apoya en HTTP/2 y Protobuf, HTTP/3 en UDP._ #### Antes de elegir un protocolo - **¿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? #### Señales de que te pasaste de rosca - 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. #### Señales de que elegiste bien - **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 - **Protocol** (el acuerdo): Un contrato entre dos programas: forma del mensaje + orden de la charla. - **Protocol stack** (capas): Capas: el transporte mueve bytes, el protocolo de aplicación les da sentido. ### Cimientos - **TCP** (Transmission Control Protocol): Entrega confiable y en orden: handshake, confirmaciones, reenvíos. - **UDP** (User Datagram Protocol): Dispará y olvidate: rápido pero con pérdidas. Video, juegos, DNS. - **HTTP** (HyperText Transfer Protocol): Pedido–respuesta sin estado: métodos y códigos de estado. - **TLS / HTTPS** (Transport Layer Security): Cifrado + identidad del servidor. HTTPS = HTTP dentro de TLS. - **HTTP/2 · HTTP/3** (multiplexing, QUIC): Muchos pedidos por una conexión; HTTP/3 sobre QUIC encima de UDP. ### Pregunta y respuesta - **REST** (Representational State Transfer): Recursos en URLs + verbos HTTP + JSON. El estándar de las APIs públicas. - **GraphQL** (un lenguaje de consulta para APIs): Un endpoint; el cliente pide exactamente los campos que necesita. - **gRPC** (Remote Procedure Call): Llamar a la función de otro servicio: HTTP/2 + Protobuf, contrato estricto. - **SOAP** (Simple Object Access Protocol): Sobres XML estrictos y WSDL. Sigue vivo en bancos y empresas. ### Tiempo real y push - **Polling** (long-polling): El cliente sigue preguntando «¿hay algo nuevo?». Un plan B. - **SSE** (Server-Sent Events): Un stream del servidor al cliente por una respuesta HTTP. Streaming de tokens de LLM. - **WebSocket** (canal full-duplex): Una línea abierta, ambos lados hablan cuando quieren. Chat, juegos. - **Webhook** (callback HTTP): Un servicio hace POST a tu URL cuando ocurre un evento. ### Mensajería - **Message broker** (el intermediario): Desacopla al emisor y al receptor en el tiempo y en el conocimiento. - **Message queue** (AMQP, RabbitMQ): Un trabajo espera en fila; exactamente un worker lo toma. - **Kafka** (log de eventos): Un log durable: muchos lectores, cada uno con su posición, el historial se queda. - **MQTT** (pub/sub para IoT): Mensajes livianos por topics para dispositivos y redes débiles. ### Formatos - **JSON** (JavaScript Object Notation): Texto legible, el estándar de la web. Un poco verboso. - **Protobuf** (Protocol Buffers): Binario compacto según un esquema. Rápido, pero ilegible a ojo. - **XML** (eXtensible 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. Fin del curso exprés · 7 capítulos · 21 conceptos Lo que sigue es la profundidad: las especificaciones de HTTP y TLS, la documentación de gRPC y GraphQL, _High Performance Browser Networking_ de Ilya Grigorik. Pero antes de los detalles — imaginá la conversación. Quién habla, con qué frecuencia, qué tan rápido y con quién. El protocolo es solo el acuerdo que hace posible esa conversación.