Hemos subido toda la pila: el enlace de datos cruza el segmento local, IP une las redes, TCP y UDP entregan a la aplicación correcta con las garantías justas. Todo ese engranaje existe para servir al último piso, el único que los usuarios ven: los protocolos de aplicación, los "idiomas" concretos con los que los programas hacen cosas útiles. Cuando Marta abre la intranet, cuando el servidor de Bilbao recibe un correo o cuando un portátil recién encendido consigue su dirección IP sin que nadie configure nada, hay un protocolo de aplicación trabajando. En esta lección recorreremos los imprescindibles: HTTP/HTTPS (la web), DNS (la guía telefónica de Internet), los protocolos de correo (SMTP, IMAP, POP3), la transferencia de ficheros (FTP/SFTP) y DHCP (la asignación automática de direcciones). Con ella completamos el catálogo de familias del módulo 2 y quedaremos listos para el siguiente paso: el mapa formal que las ordena a todas.

1. La familia de aplicación: los protocolos que ven los programas
2. HTTP: el protocolo de la web
3. HTTPS y TLS: la web con sobre cerrado
4. DNS: la guía telefónica de Internet
5. Correo electrónico: SMTP, IMAP y POP3
6. Transferencia de ficheros: FTP y SFTP
7. DHCP: direcciones IP automáticas
8. El cuadro completo del módulo

Un matiz importante antes de empezar: protocolo de aplicación no es lo mismo que aplicación (lo advertimos en 02-01 y aquí se ve claro). Chrome, Firefox y curl son aplicaciones distintas; HTTP es el protocolo que las tres hablan. Outlook y Thunderbird son programas; SMTP e IMAP son sus idiomas. El protocolo define los mensajes; el programa, la experiencia.

Todos los protocolos de esta lección comparten tres rasgos:

• Se apoyan en el transporte: cada uno eligió TCP o UDP según sus necesidades (la tabla de la lección anterior cobra vida hoy), y cada uno tiene su puerto bien conocido.
• Casi todos siguen el modelo cliente-servidor que definimos en la lección 01-02: un servidor escucha en su puerto; los clientes inician las peticiones.
• Muchos son legibles: sus mensajes son texto que un humano puede leer, lo que los hace ideales para aprender (y para diagnosticar, como haremos en el módulo 6).

HTTP (HyperText Transfer Protocol) es el protocolo de petición-respuesta sobre el que funciona la web: el cliente (navegador) pide, el servidor responde, y cada intercambio es independiente. Sus mensajes son texto puro con una sintaxis clarísima. Cuando Marta abre la intranet de Meridiano, su navegador envía (sobre una conexión TCP al puerto correspondiente) algo así:

• GET es el método: qué operación se pide.
• /informes/2026 es el recurso solicitado dentro del servidor.
• Las líneas siguientes son cabeceras con metadatos (a qué sitio se pregunta, qué formatos acepta el cliente...). Una línea en blanco cierra la petición.

Y el servidor responde:

La primera línea lleva el código de estado, la semántica del resultado. Los métodos y códigos esenciales que todo profesional debe reconocer:

Una regla mnemotécnica que vale oro en soporte: los códigos 4xx dicen "el problema es de la petición del cliente"; los 5xx, "el problema es del servidor". Un 404 tras cambiar la intranet apunta a un enlace viejo; un 500, a que el servidor de la intranet necesita atención.

HTTP viaja en texto claro: cualquiera que pueda ver el tráfico (por ejemplo, en una Wi-Fi ajena) leería peticiones y respuestas enteras, contraseñas incluidas. HTTPS es exactamente el mismo HTTP, pero transportado dentro de un túnel cifrado llamado TLS (Transport Layer Security), que se establece justo después de la conexión TCP y antes de la primera petición. Conceptualmente, TLS aporta tres garantías:

• Confidencialidad: el contenido va cifrado; un observador solo ve bytes ininteligibles.
• Integridad: cualquier manipulación por el camino se detecta.
• Autenticación: mediante un certificado digital, el servidor demuestra ser quien dice ser (que intranet.grupomeridiano.example es de verdad el servidor de Meridiano y no un impostor). Es lo que el navegador comprueba cuando muestra el candado — o el aviso rojo cuando algo no cuadra.

No entraremos en la criptografía (excede este curso); quédate con el modelo mental: HTTPS = HTTP dentro de un sobre lacrado y firmado, puerto 443 en lugar de 80. Hoy es el estándar: la web pública de Meridiano y su intranet van ambas por HTTPS, y un sitio en HTTP plano es una señal de alarma.

Lo usamos sin nombrarlo desde la lección 02-01: las personas usan nombres (www.grupomeridiano.example) y la red usa IPs (203.0.113.80). El DNS (Domain Name System) es el sistema distribuido que traduce unos en otras. Sin él, Internet seguiría funcionando... pero habría que saberse las IPs de memoria.

Cuando el portátil de Jon en Bilbao necesita resolver un nombre, pregunta (por UDP, puerto 53: consulta corta, respuesta corta — el caso de libro de la lección anterior) a su servidor DNS configurado, llamado resolver. Y aquí está la elegancia del sistema: si el resolver no conoce la respuesta, la averigua recorriendo la jerarquía de nombres de derecha a izquierda:

Dos detalles que hacen viable el sistema a escala planetaria:

• Caché en todos los niveles: cada respuesta lleva un tiempo de validez (TTL, no confundir con el TTL de IP); el resolver —y el propio sistema operativo— la recuerdan y las siguientes consultas se responden al instante, sin repetir el recorrido.
• Delegación: nadie tiene la lista completa; cada nivel solo sabe a quién preguntar por el siguiente. Meridiano administra únicamente los nombres de su dominio.

Los datos que guarda el DNS se organizan en registros de distintos tipos. Los cuatro básicos:

Todo esto se puede consultar a mano con nslookup, disponible en Windows y Linux:

Lectura: primero identifica a qué resolver está preguntando (el configurado en el equipo); "respuesta no autoritativa" significa que salió de la caché del resolver, no del servidor DNS del dominio — perfectamente normal. Se puede pedir un tipo concreto de registro:

Cuando "no va Internet" pero el ping a una IP funciona, el culpable habitual es el DNS: los nombres no se resuelven aunque la red esté perfecta. nslookup es la herramienta que separa ambos mundos en segundos; la retomaremos en el módulo 6.

El correo es el sistema federado más antiguo de Internet y usa protocolos distintos para enviar y para leer — la fuente de confusión clásica que vamos a dejar clara:

• SMTP (Simple Mail Transfer Protocol): el protocolo de envío y encaminamiento. Lo usa tu programa de correo para entregar el mensaje a tu servidor, y los servidores entre sí para hacérselo llegar al servidor del destinatario. Es texto legible: MAIL FROM, RCPT TO, DATA...
• IMAP (Internet Message Access Protocol): el protocolo de lectura moderno. El buzón vive en el servidor; el cliente lo consulta y sincroniza. Lees un correo en el móvil y aparece leído en el portátil.
• POP3 (Post Office Protocol v3): el protocolo de lectura clásico: descarga los mensajes al dispositivo (típicamente borrándolos del servidor). Simple, pero incómodo con varios dispositivos; hoy es minoritario frente a IMAP.

El viaje de un correo de Marta ([email protected]) a un cliente externo ([email protected]):

Fíjate en el paso 2: el registro MX de DNS es la bisagra de todo el sistema — es como los servidores de correo del mundo se encuentran unos a otros sin ningún directorio central. Los protocolos de aplicación no viven aislados: se apoyan entre sí.

FTP (File Transfer Protocol) es el veterano de la transferencia de ficheros: sesiones con usuario y contraseña, comandos para listar, subir y descargar. Merece conocerse porque aún se encuentra en sistemas antiguos y porque su gran defecto enseña una lección: transmite todo en claro, credenciales incluidas (y usa conexiones separadas para control y datos, lo que complica su paso por cortafuegos).

Su sustituto moderno es SFTP (SSH File Transfer Protocol): misma función, pero montada sobre el canal cifrado de SSH (puerto 22), con autenticación robusta y todo el tráfico protegido. Cuando Meridiano necesita intercambiar ficheros con clientes externos, publica un SFTP; el FTP plano quedó vetado por política interna.

Nota para no confundirse: los ficheros del día a día dentro de la oficina de Valencia no van por FTP/SFTP, sino por el protocolo de carpetas compartidas del servidor (SMB, el puerto 445 que asomó en netstat la lección pasada). FTP/SFTP brillan en el intercambio entre organizaciones o con servidores remotos.

Cerramos con el protocolo más invisible y agradecido. En el módulo anterior configuramos mentalmente IPs, máscaras y puertas de enlace; ¿alguien las teclea en cada portátil y móvil de Meridiano? No: lo hace DHCP (Dynamic Host Configuration Protocol), el protocolo que asigna la configuración de red automáticamente cuando un equipo se conecta.

El intercambio se conoce como DORA, por las iniciales de sus cuatro mensajes (sobre UDP, puertos 67/68, porque el cliente aún no tiene IP y necesita difusión — el tercer caso de uso de UDP que vimos):

Detalles que importan:

• La asignación es un alquiler (lease) con caducidad: el equipo debe renovarla periódicamente, y las direcciones de equipos que se van quedan libres para otros.
• El ACK final entrega el paquete completo de configuración: IP, máscara, puerta de enlace y servidor DNS — exactamente los datos cuya función aprendimos en las lecciones 02-03 y en esta. DHCP es el protocolo que reparte lo que ya sabemos interpretar.
• Los equipos que ofrecen servicios llevan IP fija fuera del rango DHCP (en Meridiano: servidor .10, router .1, impresoras .40): un servidor cuya IP cambia cada día sería inencontrable.

Retomaremos DHCP en el módulo 5, cuando estudiemos el direccionamiento a fondo; aquí queda presentado como lo que es: el protocolo de aplicación que pone en marcha a todos los demás.

Con la familia de aplicación termina el catálogo. Este es el módulo 2 en una sola tabla — guárdala, porque es el esqueleto de todo lo que viene:

Y la encapsulación de la lección 02-01 los ensambla: el mensaje HTTP viaja en un segmento TCP, dentro de un paquete IP, dentro de una trama Ethernet. Cada familia con su cabecera, su dirección y su trabajo.

• Confundir el protocolo con el programa (una vez más, porque es el error eterno): "no me funciona el Outlook" puede ser un problema de SMTP (enviar), de IMAP (leer), de DNS (encontrar el servidor) o del programa mismo. Nombrar el protocolo correcto es dar la mitad del diagnóstico.
• Olvidar que la web moderna es HTTPS. Probar un servicio con http:// cuando solo escucha en 443, o extrañarse del aviso de certificado sin mirar qué dice, son tropiezos de primera semana. El candado no es decoración: es la autenticación de TLS.
• Culpar a "Internet" cuando falla el DNS. Si las webs no cargan pero ping 203.0.113.80 responde, la conectividad está bien y lo roto es la resolución de nombres. nslookup lo confirma en diez segundos.
• Ignorar la caché DNS al hacer cambios. Tras cambiar un registro, medio mundo seguirá viendo el valor antiguo hasta que caduquen las cachés. La paciencia (o bajar el TTL del registro antes del cambio) forma parte del oficio.
• Consejo: aprende la tabla de puertos de esta lección (80, 443, 53, 25, 993, 22, 67/68) como vocabulario básico. En netstat, en cortafuegos y en ofertas de trabajo, los servicios se nombran por su puerto.

Ejercicio 1. Jon, desde Bilbao, escribe https://intranet.grupomeridiano.example en un portátil recién encendido que acaba de conectarse a la red. Ordena cronológicamente todos los protocolos de aplicación y transporte que intervienen hasta que ve la página, indicando el papel de cada uno: DHCP, DNS, TCP, TLS, HTTP.

Ejercicio 2. Indica qué tipo de registro DNS (A, AAAA, CNAME o MX) resuelve cada necesidad de Meridiano: a) que www.grupomeridiano.example apunte a la IP pública 203.0.113.80; b) que los correos dirigidos a @grupomeridiano.example lleguen a mail.grupomeridiano.example; c) que intranet.grupomeridiano.example sea un alias del nombre real del servidor, servidor01.grupomeridiano.example; d) que www sea también accesible por IPv6.

Ejercicio 3. En Valencia, un usuario reporta: "no puedo entrar en ninguna web, ni externas ni la intranet". Desde su equipo compruebas: ping 192.168.10.1 responde; ping 203.0.113.80 responde; nslookup www.grupomeridiano.example falla con "tiempo de espera agotado". ¿Qué protocolo/servicio señalarías como averiado y por qué descartas la LAN, el router y la salida a Internet?

Solución 1:

1. DHCP (UDP): el portátil, sin IP aún, hace su DORA y recibe IP, máscara, puerta de enlace y servidor DNS.
2. DNS (UDP): el navegador necesita la IP de intranet.grupomeridiano.example; el resolver la obtiene (o la sirve de caché) y responde, por ejemplo, 192.168.10.10 vía el registro CNAME→A correspondiente.
3. TCP: three-way handshake con 192.168.10.10:443 para abrir la conexión.
4. TLS: sobre esa conexión se negocia el túnel cifrado y el servidor se autentica con su certificado.
5. HTTP: dentro del túnel, GET / y respuesta 200 OK con la página, que el navegador muestra.

Solución 2: a) A (nombre → IPv4). b) MX (dominio → servidor de correo). c) CNAME (alias de otro nombre). d) AAAA (nombre → IPv6).

Solución 3: El averiado es el servicio DNS (o el camino hasta el resolver configurado). Razonamiento por descarte: ping 192.168.10.1 responde → la LAN, el switch y el equipo funcionan; ping 203.0.113.80 responde → el router, la puerta de enlace y la salida a Internet funcionan (¡hasta una IP externa!); pero nslookup no obtiene respuesta → los nombres no se resuelven, y sin resolución el navegador no puede ni empezar (por eso fallan "todas las webs", incluida la intranet, a las que se accede por nombre). Siguiente paso natural: revisar qué servidor DNS tiene configurado el equipo (¿lo entregó bien DHCP?) y si ese servidor está operativo.

Con los protocolos de aplicación el módulo queda completo: HTTP/HTTPS pide y entrega la web con sus métodos y códigos (y TLS le pone sobre lacrado y autenticado), DNS traduce nombres en direcciones recorriendo su jerarquía con caché en cada nivel y registros A, AAAA, CNAME y MX, el correo viaja con SMTP y se lee con IMAP (o el veterano POP3) encontrando su destino gracias al MX, SFTP mueve ficheros cifrados donde FTP los movía en claro, y DHCP arranca la función repartiendo con su DORA la configuración que hace posible todo lo demás. Mira ahora el cuadro completo del módulo: aplicación, transporte, red y enlace — cuatro familias, cada una con su misión, su unidad de datos y sus direcciones, ensambladas por la encapsulación. Ese cuadro no es un resumen cualquiera: es, casi literalmente, un modelo en capas, y no somos los primeros en dibujarlo. La industria lo formalizó hace décadas en un marco de referencia de siete capas que da nombre y número a cada función, ordena el vocabulario de toda la profesión y estructura desde los temarios de certificación hasta las conversaciones de soporte ("es un problema de capa 3"). Ese mapa es el modelo OSI, y a recorrerlo capa a capa dedicamos el módulo 3, empezando por la próxima lección: Introducción al Modelo OSI.