En el módulo 1 dejamos el plano de la red de Grupo Meridiano terminado: dos estrellas (Valencia y Bilbao) unidas por el enlace lógico de la VPN. Pero un plano no habla. Cuando el PC de una consultora de Valencia pide un fichero al servidor, ¿en qué "idioma" lo pide? ¿Quién decide cómo empieza esa conversación, cómo se trocean los datos, qué pasa si un trozo se pierde por el camino? La respuesta a todas esas preguntas son los protocolos de comunicación: los conjuntos de reglas que hacen que máquinas de fabricantes, sistemas operativos y épocas distintas se entiendan a la perfección. Esta lección explica qué es exactamente un protocolo, de qué elementos se compone, cómo colaboran varios protocolos a la vez mediante la encapsulación, y termina con un ejemplo panorámico: todo lo que ocurre, protocolo a protocolo, cuando una consultora de Meridiano abre una página web. Es la lección-mapa del módulo: las cuatro siguientes recorren en detalle cada familia que hoy solo presentaremos.

1. ¿Qué es un protocolo y por qué hace falta?
2. La analogía de la conversación humana
3. Los tres elementos de un protocolo: sintaxis, semántica y temporización
4. Nadie trabaja solo: familias y pilas de protocolos
5. La encapsulación: cabeceras que se van añadiendo
6. Ejemplo guiado: una consultora de Meridiano abre una página web
7. Errores comunes, ejercicios y conclusión

Un protocolo de comunicación es un conjunto de reglas, acordadas de antemano, que define cómo deben intercambiarse los datos entre dos o más dispositivos: qué formato tienen los mensajes, qué significa cada parte, en qué orden se envían y qué hacer cuando algo falla.

La palabra clave es acordadas de antemano. En la red de Meridiano conviven un servidor con Linux, portátiles con Windows, móviles con Android e iOS, una impresora de red y routers de un fabricante que ni conocemos. Ninguno de esos aparatos fue diseñado pensando en los demás y, sin embargo, todos se comunican sin problemas. Eso solo es posible porque todos implementan los mismos protocolos, que están publicados como estándares abiertos (muchos de ellos en documentos llamados RFC, Request for Comments, mantenidos por el IETF).

Sin protocolos, cada fabricante inventaría su propio formato y solo podrían hablar entre sí equipos de la misma marca. Con protocolos estándar, la interoperabilidad es total: por eso puedes cambiar el router de Bilbao por otro de cualquier marca y la VPN con Valencia seguirá funcionando.

Un protocolo debe responder, como mínimo, a estas preguntas:

• Formato: ¿qué estructura tiene cada mensaje? ¿Dónde va el remitente, dónde el destinatario, dónde los datos?
• Orden: ¿quién habla primero? ¿Hay que "saludar" antes de enviar datos?
• Errores: ¿cómo se detecta que un mensaje llegó corrupto o no llegó? ¿Se reenvía o se ignora?
• Ritmo: ¿a qué velocidad se puede enviar sin saturar al receptor?

La mejor forma de intuir qué hace un protocolo es fijarse en algo que usamos a diario sin darnos cuenta: el protocolo de una llamada de teléfono entre personas.

Fíjate en que la conversación tiene reglas implícitas que ambos respetan: quién inicia, cómo se confirma que el otro escucha, cómo se pide una repetición, cómo se despide uno. Si Jon descolgara y se quedara callado, o si ambos hablaran a la vez sin parar, la comunicación fracasaría aunque los dos hablen el mismo idioma. Los protocolos de red formalizan exactamente este tipo de reglas, con la diferencia de que las máquinas no improvisan: cada paso está definido bit a bit.

Esta analogía nos acompañará todo el módulo: cuando en la lección 02-04 veamos el "apretón de manos" con el que TCP abre una conexión, reconocerás inmediatamente los pasos 1-3 de la llamada de Ana.

Todo protocolo, sea humano o informático, se puede descomponer en tres elementos. Es una clasificación clásica que conviene memorizar porque permite "diseccionar" cualquier protocolo que te encuentres en tu carrera:

Un ejemplo concreto con los tres elementos a la vez: cuando el PC de Ana envía datos al servidor de ficheros y espera confirmación:

• Sintaxis: la confirmación es un mensaje con un formato exacto (campos de tantos bits, en tal orden).
• Semántica: ese mensaje significa "he recibido tus datos hasta el byte N, sigue".
• Temporización: si la confirmación no llega en un tiempo determinado, el PC de Ana da los datos por perdidos y los reenvía automáticamente.

Ana no ve nada de esto. Y esa es la segunda gran virtud de los protocolos: automatizan la comunicación de forma transparente para el usuario.

Aquí llega la idea más importante de la lección: no existe un único "protocolo de Internet" que lo haga todo. Comunicar dos aplicaciones a través de una red implica resolver problemas de naturaleza muy distinta, y se resolvió dividiendo el trabajo entre protocolos especializados que colaboran:

A este conjunto de protocolos que colaboran, cada uno apoyándose en los servicios del anterior, se le llama pila de protocolos (protocol stack). La pila que usa prácticamente todo el planeta —y por supuesto Meridiano— es la pila TCP/IP, llamada así por sus dos protocolos más famosos.

¿Por qué dividir así el trabajo, por funciones? Por las mismas razones por las que en software separamos responsabilidades en módulos:

• Especialización: cada protocolo resuelve un problema y lo resuelve bien.
• Sustituibilidad: puedes cambiar el cable por Wi-Fi (cambia el protocolo de enlace) sin tocar nada más; la web sigue funcionando igual.
• Evolución independiente: HTTP ha cambiado varias veces de versión sin que hubiera que tocar Ethernet, y viceversa.

Esta organización por funciones está tan asentada que existen dos modelos de referencia que la formalizan en "capas" numeradas: el modelo OSI y el modelo TCP/IP. Les dedicamos íntegros los módulos 3 y 4, así que de momento quédate solo con la idea: las familias que veremos en este módulo son, precisamente, las capas de esos modelos. Cuando llegues allí, ya conocerás a todos los protagonistas.

Si cada protocolo de la pila hace un trabajo distinto, ¿cómo colaboran en la práctica sobre un mismo mensaje? Mediante un mecanismo elegantísimo llamado encapsulación: cada protocolo envuelve los datos que recibe del protocolo superior añadiéndoles su propia cabecera (un bloque de información de control con su sintaxis particular), igual que una carta se mete en un sobre, y ese sobre podría ir dentro de una saca del servicio postal.

Veámoslo con el PC de Ana enviando datos de una petición web:

Observa tres cosas importantes:

1. Cada protocolo solo lee y escribe su propia cabecera. Ethernet no sabe (ni le importa) que dentro viaja una petición web; solo sabe que tiene que entregar la trama al equipo con cierta dirección MAC. Es como el cartero: entrega sobres sin leer las cartas.
2. En el destino ocurre el proceso inverso, la desencapsulación: cada protocolo retira su cabecera, comprueba lo que le corresponde y pasa el contenido al protocolo superior, hasta que la petición HTTP "limpia" llega al servidor web.
3. Cada unidad tiene su nombre: a los datos con cabecera TCP se les llama segmento; con cabecera IP, paquete; con cabecera Ethernet, trama. Iremos usando estos nombres con rigor creciente en las próximas lecciones, y son vocabulario obligado en cualquier entrevista técnica.

El diagrama resume la idea: en el emisor los datos bajan por la pila (cada protocolo añade su cabecera) y en el receptor suben (cada protocolo la retira). Los protocolos del mismo nivel "conversan" entre sí a través de sus cabeceras, aunque físicamente todo viaje junto por el cable.

Cerremos la lección con la visión panorámica prometida. Marta, consultora en la oficina de Valencia, escribe www.grupomeridiano.example en su navegador y pulsa Enter. En menos de un segundo, y sin que ella vea nada, intervienen todas las familias de protocolos del módulo. No entraremos en el detalle de ninguno (para eso están las lecciones 02-02 a 02-05); el objetivo es ver el reparto de papeles:

1. Aplicación — resolver el nombre (DNS). El navegador no sabe qué es www.grupomeridiano.example; las máquinas se localizan por direcciones IP. Un protocolo de aplicación llamado DNS traduce el nombre a una dirección IP, por ejemplo 203.0.113.80. (Lección 02-05.)
2. Transporte — abrir la conversación (TCP). El PC de Marta y el servidor web ejecutan un pequeño "apretón de manos" para acordar que van a hablar, y TCP se encargará de que nada se pierda ni llegue desordenado. (Lección 02-04.)
3. Aplicación — pedir la página (HTTP). El navegador formula la petición en el idioma de la web, HTTP: "dame la página principal". El servidor responderá con el contenido. (Lección 02-05.)
4. Red — encaminar los paquetes (IP). La petición, troceada en paquetes, lleva la dirección IP de destino. El PC de Marta ve que 203.0.113.80 no está en su red local, así que entrega los paquetes al router de Valencia, que los encamina hacia Internet salto a salto. (Lección 02-03.)
5. Enlace — cruzar cada tramo local (Ethernet). Para llegar físicamente del PC de Marta al router, la trama viaja por el switch de Valencia usando direcciones MAC. En cada tramo del camino se repite la jugada con el protocolo de enlace que toque (Ethernet, Wi-Fi, fibra del operador...). (Lección 02-02.)
6. El viaje de vuelta. La respuesta del servidor recorre el camino inverso; TCP recompone los trozos en orden, HTTP entrega el contenido y el navegador lo pinta en pantalla.

Fíjate en el patrón: ningún protocolo hace el trabajo de otro. DNS solo traduce nombres; TCP solo garantiza la entrega; IP solo encamina; Ethernet solo cruza el tramo local. Si mañana Marta se conecta por Wi-Fi en vez de por cable, solo cambia el paso 5. Si la web pasa a HTTPS, solo se refuerza el paso 3. Esa modularidad es la que estudiaremos pieza a pieza en el resto del módulo.

• Pensar que "Internet funciona con un protocolo". Craso error de principiante: funciona con una pila de decenas de protocolos coordinados. Cuando alguien dice "la red va por TCP/IP" está nombrando la pila entera por sus dos miembros más famosos.
• Confundir protocolo con programa. HTTP no es el navegador, ni SMTP es Outlook. El protocolo es el conjunto de reglas; el programa es una implementación que las sigue. Por eso Chrome y Firefox, siendo programas distintos, abren las mismas webs.
• Creer que la encapsulación añade "copias" de los datos. No: los datos viajan una sola vez; lo que se añade son cabeceras pequeñas (decenas de bytes) delante de ellos. El coste es mínimo comparado con lo que se gana.
• Saltarse el "para qué" e ir directo a memorizar siglas. En este módulo cada protocolo se presenta siempre con el problema que resuelve. Si sabes el problema, la sigla se recuerda sola; al revés, no.
• Consejo: cuando te encuentres un protocolo nuevo en tu trabajo (y te pasará constantemente), hazle siempre las tres preguntas de esta lección: ¿qué sintaxis usa?, ¿qué significan sus mensajes?, ¿qué reglas de temporización tiene? Es un método de análisis que funciona con cualquier protocolo, del más viejo al más moderno.

Ejercicio 1. Clasifica cada regla de esta "conversación" entre el PC de Marta y el servidor de ficheros según sea sintaxis, semántica o temporización:

1. "Todo mensaje empieza con 6 bytes que contienen la dirección del destinatario."
2. "Si en 3 segundos no recibo confirmación, reenvío los datos."
3. "El mensaje con código 550 significa que no tienes permiso."
4. "Entre mensaje y mensaje hay que esperar a que el receptor confirme que está listo."

Ejercicio 2. El departamento de administración de Meridiano pregunta por qué, al cambiar los portátiles de cable a Wi-Fi, "todo siguió funcionando igual: la web, el correo, los ficheros del servidor". Explícalo en dos o tres frases usando los conceptos de pila de protocolos y sustituibilidad.

Ejercicio 3. Ordena de dentro hacia fuera cómo queda encapsulada una petición HTTP del PC de Marta justo antes de salir por el cable, y nombra la unidad de datos resultante en cada paso: cabecera Ethernet, cabecera IP, cabecera TCP, petición HTTP.

Solución 1:

1. Sintaxis (define formato y posición de un campo).
2. Temporización (define una espera máxima y qué hacer al agotarse).
3. Semántica (define el significado de un mensaje).
4. Temporización (define el ritmo y los turnos del intercambio).

Solución 2: Las aplicaciones (web, correo, ficheros) usan protocolos de aplicación y de transporte que no dependen del medio físico. Al pasar de cable a Wi-Fi solo se sustituyó el protocolo de enlace (Ethernet por 802.11), y como cada familia de la pila trabaja de forma independiente apoyándose en la de abajo, las capas superiores ni se enteraron del cambio. Es exactamente la sustituibilidad que motiva organizar los protocolos por funciones.

Solución 3: De dentro hacia fuera: la petición HTTP (datos de aplicación) se envuelve con la cabecera TCP (formando un segmento), este se envuelve con la cabecera IP (formando un paquete) y este con la cabecera Ethernet más su cola (formando una trama), que es lo que se convierte en bits y sale por el cable. En destino se retiran en orden inverso: Ethernet → IP → TCP → HTTP.

Ya sabemos qué es un protocolo: un conjunto de reglas —sintaxis, semántica y temporización— acordadas de antemano para que máquinas heterogéneas se comuniquen sin ambigüedad, igual que dos personas siguen sin darse cuenta el "protocolo" de una llamada telefónica. Y sabemos algo aún más importante: que ningún protocolo trabaja solo. La comunicación se reparte entre familias especializadas —enlace, red, transporte y aplicación— que colaboran mediante la encapsulación, añadiendo y retirando cabeceras como sobres dentro de sobres, formando la pila TCP/IP que usa todo Internet y, por supuesto, Grupo Meridiano. En el ejemplo de Marta abriendo una página web hemos visto el reparto de papeles completo a vista de pájaro; ahora toca aterrizar en cada familia. Empezamos por abajo, por la que resuelve el problema más inmediato de todos: cómo se hablan dos equipos que comparten el mismo cable, el mismo switch o la misma Wi-Fi. Es el terreno de Ethernet, las direcciones MAC y ARP, y lo exploramos en la próxima lección: Protocolos de Enlace de Datos.