Llegamos a la cima de la pila TCP/IP: la capa de aplicación, el territorio donde viven los protocolos que hacen algo visible para las personas — la web que abre Marta, el correo que envía Jon, la resolución de nombres que ocurre sin que nadie la vea. Sus protagonistas ya los conoces de 02-05 (HTTP, TLS, DNS, correo, SFTP, DHCP), así que no volveremos a diseccionarlos uno a uno. Lo que aporta esta lección es la arquitectura: por qué TCP/IP mete en una sola capa lo que OSI reparte en tres, dónde está la frontera práctica entre "mi aplicación" y "la red" (pista: en las bibliotecas y la API del sistema operativo), y — el plato fuerte — el recorrido completo y ordenado de una petición real, GET /api/proyectos a la intranet de Meridiano, desde la línea de código hasta el socket de la lección anterior. Cerraremos con una idea que suele pasar desapercibida: DNS y DHCP son aplicaciones que sirven a la propia red, y con el panorama completo de puertos de los servicios de Meridiano. Es importante porque aquí es donde el 90 % de los profesionales TI trabaja a diario: por encima del socket, pero necesitando entender lo que hay debajo.

1. Una capa que vale por tres: la fusión de OSI 5-7
2. Los protocolos conocidos, situados en la pila TCP/IP
3. La frontera práctica: bibliotecas y APIs del SO
4. Anatomía de una petición real: GET /api/proyectos, paso a paso
5. Servicios de infraestructura: aplicaciones que sirven a la red
6. El panorama de puertos de Meridiano

En el módulo 3 dedicaste tres lecciones a las capas altas de OSI — sesión (03-06), presentación (03-07) y aplicación (03-08) — y en cada una llegaste a la misma conclusión: sus funciones existen, pero en el software real no viven en capas separadas. TCP/IP simplemente hace oficial esa realidad: por encima del transporte hay una sola capa de aplicación, y cada protocolo resuelve dentro de sí mismo, como le convenga, las funciones de sesión y presentación que necesite.

El ejemplo canónico ya lo trabajaste: HTTPS. En términos OSI, TLS hace cosas de sesión (establecer y reanudar sesiones seguras) y de presentación (cifrar, negociar formatos), y HTTP hace cosas de aplicación... pero también de sesión (cookies, keep-alive) y de presentación (Content-Type, compresión gzip). Intentar trocear HTTPS en las capas 5-6-7 es un ejercicio de taxidermia; TCP/IP renuncia a él:

¿Por qué es la decisión correcta para construir? Porque las necesidades de sesión y presentación varían muchísimo entre aplicaciones: DNS no necesita sesión ninguna; SSH necesita una sesión cifrada persistente con multiplexado propio; HTTP pasó de "una conexión por petición" (HTTP/1.0) a multiplexar decenas de peticiones por conexión (HTTP/2) sin que ninguna otra capa tuviera que cambiar. Estandarizar esas funciones en capas fijas habría sido un corsé. La contrapartida: cuando diagnosticas, el vocabulario fino de OSI sigue siendo útil — "esto falla en presentación" (un JSON mal codificado) es más preciso que "esto falla en aplicación". De ese doble uso hablaremos a fondo en 04-06.

Coloquemos el catálogo de 02-05 en su sitio, con su transporte y su puerto — las dos señas de identidad de un protocolo de aplicación en TCP/IP:

Dos observaciones de arquitecto:

• El puerto es la dirección "social" del protocolo. Que HTTPS sea "el 443" es un convenio (los well-known ports de IANA), no una ley física: la intranet de Meridiano podría escuchar en el 8443 y funcionaría igual — pero todos los clientes tendrían que saberlo. Los convenios existen para no tener que avisar.
• ¿Y TLS? No tiene fila propia porque no es una aplicación: es una capa de seguridad intermedia que se interpone entre el transporte y el protocolo de aplicación que la use (HTTPS = HTTP sobre TLS; IMAPS = IMAP sobre TLS). En el mapa de TCP/IP vive dentro de la capa de aplicación, pegado a su suelo. Es uno de los casos frontera estrella de 04-06.

Aquí está la idea más útil de la lección para un desarrollador: ¿dónde termina "mi programa" y empieza "la red"? La respuesta tiene forma de escalera de abstracciones:

Lecturas de este dibujo:

• La capa de aplicación se ejecuta en espacio de usuario. Todo lo que hay por encima de la línea de sockets es código de programa y bibliotecas; todo lo de abajo es el kernel (04-01). HTTP no está "en el sistema operativo": está en la biblioteca que tu programa carga.
• Cada peldaño te ahorra los de abajo. El programador de la intranet escribe una línea (http_get(...)) y las bibliotecas hacen el resto. Pero cuando algo falla, el error puede nacer en cualquier peldaño — y los mensajes lo delatan: NXDOMAIN (falló el resolutor), certificate verify failed (falló TLS), connection refused (falló el connect del socket, 04-04), 404 Not Found (todo lo de abajo funcionó; falló la conversación HTTP).
• La API de sockets es el punto de encuentro universal. Da igual el lenguaje o la biblioteca: al final, todos acaban llamando a connect, send y recv. Por eso la lección 04-04 es la bisagra del módulo.

Juntemos todas las piezas. El panel de proyectos que Marta tiene abierto en su navegador ejecuta:

Lo que ocurre entre esa línea y el JSON en pantalla, en orden y con su capa:

Paso 1 — Resolución de nombres (aplicación: DNS). La biblioteca extrae el nombre intranet.grupomeridiano.example y llama al resolutor del SO (getaddrinfo). Si el nombre no está en caché, el resolutor envía una consulta DNS — un datagrama UDP al puerto 53 del servidor DNS configurado (en Valencia, el propio router .10.1 hace de DNS de la red y responde con el registro local). Respuesta: 192.168.10.10. Nota fina: para hacer esta consulta ya hubo red por debajo — un socket UDP, un paquete IP, una trama. La primera "aplicación" que trabaja en toda petición web es DNS.

Paso 2 — Conexión (transporte: TCP). Con la IP en la mano, la biblioteca abre un socket y hace connect(192.168.10.10, 443): el three-way handshake de 02-04, tal como lo viste desde el código en 04-04. El kernel de Marta elige puerto efímero de origen (p. ej. 52814); en el servidor, el accept() de nginx recoge la conexión. Estado: ESTABLISHED en ambos lados. (Por debajo, cada segmento viajó en paquetes IP decididos por la tabla de rutas de 04-03 y en tramas de la red de 04-02 — pero eso ya ni lo miramos: las capas de abajo funcionan y punto, que es exactamente su trabajo.)

Paso 3 — Handshake TLS (aplicación: seguridad). Antes del primer byte de HTTP, la biblioteca TLS negocia sobre la conexión recién abierta: versiones y cifrados, el servidor presenta su certificado de intranet.grupomeridiano.example, el cliente lo valida (¿lo firma una autoridad en la que confío? ¿el nombre coincide?) y ambos acuerdan claves de sesión (02-05, ahora en su lugar exacto de la secuencia). Desde aquí, todo lo que pase por el socket va cifrado: quien capture el tráfico verá que Marta habla con la intranet, pero no qué dice.

Paso 4 — Petición y respuesta (aplicación: HTTP). Por fin, la biblioteca escribe en el canal cifrado:

El servidor responde 200 OK con Content-Type: application/json y el cuerpo — la lista de proyectos. La biblioteca comprueba el código de estado, descomprime si hace falta, y devuelve los datos al código de Marta. En total: una línea de código, cuatro conversaciones de red (DNS, TCP, TLS, HTTP), y toda la pila de los módulos anteriores trabajando debajo sin ser vista.

Este guion de cuatro pasos es, además, tu lista de comprobación de diagnóstico para cualquier "no me carga": ¿resuelve el nombre? → ¿conecta el puerto? → ¿valida el certificado? → ¿qué responde HTTP? Cada pregunta aísla un peldaño de la escalera. En el módulo 6 la convertiremos en método con herramientas.

Hay una categoría de protocolos de aplicación con una peculiaridad filosófica deliciosa: técnicamente viven en la capa de aplicación (corren en espacio de usuario, usan transporte, tienen puerto), pero su cliente no es una persona — es la propia red. Sin ellos, las capas de abajo no arrancan:

• DHCP (02-05): cuando el portátil de Ana se une a la Wi-Fi de Valencia, aún no tiene IP, ni máscara, ni gateway, ni servidor DNS. El DORA se los da... usando UDP y difusión, es decir, usando la pila para configurar la pila. Es una aplicación cuyo producto es que las capas 2-3 de los demás funcionen. En Meridiano, el servidor DHCP corre en el router .10.1 y reparte el rango .10.100–.10.199 (los equipos fijos, como el servidor .10.10 o la impresora, tienen IP estática o reserva).
• DNS (02-05): sin él, Internet "funciona" pero es inutilizable — nadie navega por IPs. Cada consulta DNS es una mini-aplicación completa (socket UDP, datagrama, respuesta) que se ejecuta antes de que la aplicación "de verdad" pueda empezar. En Meridiano, el router .10.1 resuelve los nombres internos (intranet.grupomeridiano.example → 192.168.10.10) y reenvía el resto a los DNS del proveedor.
• NTP: sincroniza los relojes. Parece cosmético hasta que recuerdas el paso 3 de la petición: la validación de certificados TLS compara fechas — un servidor con el reloj descuadrado años empieza a rechazar todos los certificados y "se cae Internet" de la forma más desconcertante posible.

La moraleja arquitectónica: en TCP/IP no hay una capa de "gestión" separada — la red se administra a sí misma con aplicaciones normales y corrientes. Es el pragmatismo de 04-01 llevado al extremo: si algo se puede resolver con un protocolo de aplicación sobre UDP, no inventes una capa nueva.

Cerremos con el mapa completo de servicios de la empresa — la tabla que Ana tiene (o debería tener) pegada en la pared, y que es a la vez inventario, guía de diagnóstico y base para las reglas del cortafuegos:

Fíjate en cómo la tabla condensa el módulo entero: cada fila es una aplicación (esta lección) sobre un transporte y puerto (04-04), alcanzable gracias al encaminamiento (04-03) sobre las interfaces de cada sede (04-02). Cuatro capas, una fila por servicio.

• Creer que "capa de aplicación" = "mi aplicación". La capa de aplicación son los protocolos (HTTP, DNS...); tu programa es un usuario de esos protocolos a través de bibliotecas. El navegador no es HTTP: habla HTTP.
• Olvidar que DNS ocurre primero. Media humanidad diagnostica "no funciona la web" reiniciando el router cuando el fallo era de resolución de nombres. Primera pregunta siempre: ¿resuelve el nombre? (En el módulo 6: nslookup/dig.)
• Situar TLS "en el transporte" porque se llama Transport Layer Security. El nombre engaña: TLS corre en espacio de usuario, sobre TCP, dentro de la capa de aplicación de TCP/IP. El matiz completo, en 04-06.
• Asumir que el puerto define el protocolo. El 443 suele ser HTTPS por convenio, pero nada impide servir otra cosa ahí (o HTTPS en el 8443). Los puertos son convención, no comprobación — los cortafuegos serios inspeccionan más allá del número.
• Ignorar los servicios de infraestructura en los diagnósticos. Si DHCP falla, "no funciona nada" en los portátiles pero los equipos con IP fija van bien; si DNS falla, "no funciona nada por nombre" pero el ping a la IP va bien; si NTP se descuadra, falla TLS de formas absurdas. Los tres patrones son oro puro para aislar problemas.
• Consejo: interioriza el guion de 4 pasos (DNS → TCP → TLS → HTTP) hasta que sea reflejo. Es el esqueleto de cualquier diagnóstico de servicio web y la estructura sobre la que montaremos la metodología del módulo 6.

1. Jon, desde Bilbao, abre https://intranet.grupomeridiano.example/api/proyectos y obtiene error. Ana comprueba desde el PC de Jon: nslookup intranet.grupomeridiano.example responde 192.168.10.10; acto seguido, una conexión de prueba al puerto 443 de esa IP se queda en timeout. (a) ¿Qué pasos del guion de 4 fases han funcionado y cuál ha fallado? (b) ¿En qué capa TCP/IP está el problema, probablemente? (c) ¿Qué elemento concreto de la infraestructura de Meridiano es el primer sospechoso?

2. Clasifica estos tres incidentes según qué servicio de infraestructura ha fallado, razonando por el patrón de síntomas: (a) los portátiles de la sala de reuniones de Valencia no acceden a nada, pero el servidor .10.10 y la impresora funcionan con normalidad para el resto; (b) nadie puede abrir la intranet por nombre, pero https://192.168.10.10 (aceptando el aviso del certificado) funciona; (c) desde hace una semana, el servidor de ficheros rechaza todas las conexiones HTTPS con errores de "certificado no válido: aún no es válido", pero solo desde algunos equipos.

3. Ana quiere endurecer el cortafuegos del router de Valencia para el tráfico entrante desde la VPN (Bilbao → Valencia): la sucursal solo necesita usar la intranet, los ficheros compartidos y que Ana pueda administrar por SSH. Usando la tabla de puertos de Meridiano, escribe la lista mínima de reglas "permitir" (destino, transporte, puerto) y explica por qué DNS y DHCP no necesitan regla en esa dirección.

1. (a) El paso 1 (DNS) funciona: el nombre resuelve a la IP correcta. El paso 2 (conexión TCP) falla con timeout: no se llega a TLS ni a HTTP. (b) Un timeout de conexión (03-05, 04-04) apunta a que los SYN no llegan o no vuelven: problema en la capa de Internet (encaminamiento/alcanzabilidad) o un cortafuegos descartando — no es un problema de la aplicación intranet (eso daría "connection refused" o un error HTTP). (c) El primer sospechoso es el túnel VPN Bilbao–Valencia: es el camino obligado de Jon hacia 192.168.10.10. Comprobación rápida: ping 192.168.10.10 desde Bilbao y revisar el estado del túnel en los routers .20.1 y .10.1. (Que DNS respondiera no exculpa a la VPN si el resolutor de Bilbao tiene caché o resuelve localmente.)

2. (a) DHCP: afecta solo a equipos que piden configuración dinámica (portátiles que llegan a la sala), mientras los de IP fija (servidor, impresora) siguen funcionando. Probablemente el rango dinámico agotado o el servicio DHCP del router caído. (b) DNS: el patrón "por nombre no, por IP sí" es su firma inconfundible — la red entera funciona; solo falta el traductor. (c) NTP (reloj): "aún no es válido" significa que el equipo cliente cree estar en una fecha anterior al inicio de validez del certificado — relojes descuadrados en esos equipos concretos. Por eso afecta "solo a algunos": cada máquina lleva su propio reloj mal.

3. Reglas mínimas de entrada desde la VPN: permitir TCP:443 hacia 192.168.10.10 (intranet HTTPS), permitir TCP:445 hacia 192.168.10.10 (SMB), permitir TCP:22 hacia 192.168.10.10 y 192.168.10.1 (SSH de administración; idealmente restringido además a la IP del equipo de Ana), y denegar el resto. DNS no necesita regla en esa dirección porque los equipos de Bilbao preguntan a su DNS (el router .20.1 o el que tengan configurado), no al de Valencia — la consulta no cruza el túnel hacia el .10.1. DHCP tampoco: funciona por difusión dentro de cada red local (02-05) y las difusiones no atraviesan routers ni túneles — Bilbao tiene su propio DHCP en el .20.1.

La capa de aplicación de TCP/IP es la fusión honesta de las OSI 5-7: cada protocolo resuelve sesión y presentación a su manera, y la frontera real entre "programa" y "red" no está en un diagrama sino en la API de sockets, con las bibliotecas (HTTP, TLS, resolutor) como peldaños intermedios que ahorran trabajo — y como sospechosos ordenados cuando algo falla. Ya sabes recorrer el guion completo de una petición real (DNS → TCP → TLS → HTTP), reconocer en DNS, DHCP y NTP a las aplicaciones que sirven a la propia red, y leer el mapa de puertos de Meridiano como lo que es: el módulo 4 entero comprimido en una tabla. Con las cuatro capas ya recorridas de abajo arriba, queda una última tarea antes de cerrar el módulo: poner los dos mapas — OSI y TCP/IP — uno al lado del otro, decidir cuándo usar cada uno y desactivar las confusiones clásicas de frontera (¿dónde va ARP? ¿y TLS?). Esa comparativa es la próxima y última lección del módulo.