Última parada del recorrido: la capa 7 o capa de aplicación, la cima del modelo OSI. Es la capa donde la red deja de ser un mecanismo de transporte y se convierte en algo útil para las personas: páginas que se abren, correos que llegan, ficheros que se comparten. También es la capa peor entendida, empezando por su nombre: la capa de aplicación no son las aplicaciones — el navegador de Marta no "es capa 7" — sino los servicios y protocolos de red que las aplicaciones usan para comunicarse. En esta lección precisaremos esa distinción, entenderemos qué significa exactamente que HTTP, DNS o SMTP (viejos conocidos del módulo 2) sean "protocolos de capa 7", veremos cómo las capas 5-6-7 conviven fundidas dentro del software real usando el navegador de Marta como ejemplo integrador, y cerraremos el módulo con la vista completa del modelo ya recorrido — lista para compararla, en el módulo que viene, con la pila que de verdad gobierna Internet.

1. La función de la capa de aplicación dentro del modelo
2. Qué significa que HTTP, DNS o SMTP sean "capa 7"
3. APIs y servicios de red desde la perspectiva OSI
4. Las capas 5-7 juntas en el software real: el navegador de Marta
5. El diagnóstico en la cima: problemas de capa 7
6. El modelo completo: tabla-resumen de las 7 capas

El contrato OSI de la capa 7 es especial, porque es el final de la escalera:

• Qué recibe de arriba: ya no hay capa superior — arriba están los procesos de usuario (el navegador, el cliente de correo, la aplicación de escritorio). La capa 7 es su interfaz con la red: el conjunto de servicios que un programa invoca cuando necesita comunicarse.
• Qué servicio ofrece: servicios de red con semántica útil para los programas: "trae este documento", "resuelve este nombre", "entrega este mensaje a este buzón", "transfiere este fichero".
• Qué usa de abajo (capa 6): datos ya representados de forma común (codificados, serializados, cifrados si procede), viajando por un diálogo vivo (5) y un transporte entre procesos (4).
• Su PDU: datos.

La distinción crucial, dicha sin rodeos: la aplicación usa la capa de aplicación, no la constituye. El navegador de Marta hace muchísimas cosas que no son red — dibujar la página, gestionar pestañas, recordar marcadores —; solo cuando necesita algo de otro equipo habla un protocolo de capa 7 (HTTP, o DNS para resolver el nombre). Del mismo modo, la hoja de cálculo con la que Ana edita un fichero del servidor no es capa 7, pero el protocolo de ficheros en red con el que lo abre y guarda, sí. La capa 7 es la ventanilla de servicios de red; el programa es el cliente de la ventanilla.

En el módulo 2 (02-05) estudiaste HTTP, DNS, SMTP, FTP/SFTP y DHCP como protocolos concretos. Ahora podemos decir con precisión OSI qué comparten para merecer la etiqueta "capa 7". Un protocolo es de capa de aplicación cuando cumple esto:

1. Su vocabulario habla el idioma del problema, no el de la red. Las cabeceras de capas 2-4 hablan de MACs, IPs, puertos, secuencias — mecánica de transporte. HTTP habla de documentos, métodos y códigos de estado; SMTP habla de remitentes, destinatarios y buzones; DNS habla de nombres y registros. Cada uno modela un problema humano concreto.
2. Define el diálogo entre un programa cliente y un programa servidor: qué se puede pedir, cómo se responde, qué significa cada error. El GET y el 404 de HTTP, o el DORA de DHCP, son gramática de capa 7.
3. Delega todo lo demás hacia abajo. HTTP no sabe encaminar, ni retransmitir, ni cifrar: pide un transporte fiable (capa 4), viaja cifrado si hay TLS (5-6) y jamás mira una IP de ruta. Esa delegación limpia es el modelo de capas funcionando.

Visto así, la tabla de protocolos de 02-05 adquiere su lectura definitiva: cada protocolo de aplicación es un servicio especializado de la ventanilla de capa 7, y todos comparten la misma infraestructura de las capas 1-6:

Merece un apunte el caso curioso de DHCP y DNS: son capa 7 por estructura (diálogo cliente-servidor con vocabulario propio), pero su propósito es dar servicio a las capas de abajo — DHCP configura direcciones de capa 3, DNS traduce nombres a direcciones de capa 3. Son la "administración interna" de la red construida, con toda naturalidad, como servicios de aplicación. Que esto sea posible —usar la cima de la pila para gestionar sus cimientos— es una elegancia del diseño en capas.

Si trabajas en desarrollo, cloud o devops, tu contacto diario con la capa 7 tiene un nombre concreto: APIs. Una API web (esos servicios que responden JSON que viste en la lección anterior) es, en términos OSI, capa de aplicación en estado puro: un contrato cliente-servidor, montado sobre HTTP, cuyo vocabulario modela un dominio de negocio.

El ejemplo de Meridiano: la intranet expone una pequeña API interna. Cuando la aplicación de escritorio del equipo de administración necesita la lista de proyectos, hace una petición como:

Léelo con lentes OSI y verás tres pisos apilados dentro de la propia capa de aplicación y sus vecinas:

• El contrato de la API ("existe /api/proyectos, acepta el filtro estado, devuelve proyectos") es puro dominio: el escalón más alto de la capa 7.
• HTTP es el protocolo de capa 7 que le presta la mecánica de petición-respuesta.
• El JSON de la respuesta es representación: capa 6. El token de sesión que autentica a la aplicación: capa 5 conceptual. Y de la capa 4 hacia abajo, la infraestructura que ya dominas.

La lección de fondo: la frontera superior del modelo OSI es un andamio de contratos apilados — cada servicio de red moderno se construye montando vocabularios sobre vocabularios (API sobre HTTP sobre TLS sobre TCP...), y el modelo te da el lenguaje para señalar en qué piso está cada cosa. Cuando un compañero diga "el balanceador es de capa 7", ya sabes qué significa: un equipo que no se limita a repartir conexiones (capa 4), sino que entiende HTTP y decide leyendo sus cabeceras.

Tres lecciones seguidas han terminado igual: "esta capa vive dentro del software". Es el momento de verlas todas juntas en el ejemplo integrador del curso: qué pasa dentro del navegador de Marta al abrir la intranet. El navegador es un solo programa, pero ejecuta él solito los papeles de las capas 5, 6 y 7:

El diagrama cuenta la verdad completa sobre las capas altas del modelo:

• Nítidas hacia abajo: la frontera entre el navegador y el sistema operativo (entre la capa 5 y la 4) es real y tangible — el programa pide un socket y el SO pone TCP/IP. Por eso las capas 1-4 tienen protocolos, dispositivos y herramientas tan identificables.
• Fundidas hacia arriba: dentro del navegador, los papeles 5-6-7 no son módulos separados sino funciones entretejidas (TLS cruza la 5 y la 6; HTTP y sus librerías tocan la 6 y la 7). Ningún desarrollador del navegador programó "la capa de sesión": programó funcionalidades que, analizadas con OSI, caen en esas casillas.

Y esta es la respuesta definitiva a la pregunta que arrastramos desde 03-01: ¿por qué el módulo 2 pudo tratar las capas 5-7 como una sola "familia de aplicación" sin que pasara nada? Porque en el software real están fundidas — la separación en tres es analítica, no física. OSI las distingue porque son tres problemas distintos (mantener diálogos, acordar representaciones, servir a los programas), y distinguir problemas es exactamente para lo que sirve un modelo de referencia; pero las soluciones viven juntas en cada aplicación. Mapa y territorio, una vez más.

Completemos la escalera de diagnóstico del módulo. Un problema es "de capa 7" cuando toda la infraestructura funciona — enlace, IP, transporte, sesión, formato — y aun así el servicio responde mal en su propio vocabulario. La buena noticia: la capa 7 es la única que te explica sus errores con palabras:

Compara con las capas de abajo: un cable roto no emite mensajes, un paquete perdido muere en silencio, un puerto filtrado ni contesta. En la capa 7, en cambio, leer el error es la mitad del diagnóstico — un 403 y un 500 apuntan a lugares completamente distintos con total claridad. Por eso la escalera completa se recorre tan rápido cuando se domina: física → enlace → red → transporte → sesión/presentación → y, si todo eso está bien, deja que la capa 7 te lo cuente con sus códigos.

Recorrido terminado. Esta es la tabla de la lección 03-01, pero ya no como promesa sino como repaso — cada fila es ahora una lección que has trabajado:

Guárdala: es el resumen del módulo y tu chuleta de diagnóstico para siempre.

• Decir que "el navegador es capa 7". El navegador es un proceso de usuario que usa protocolos de capa 7 (y asume papeles de la 5 y la 6). La capa 7 son los servicios y protocolos, no los programas. La distinción parece pedante hasta que hay que decidir si un fallo es del programa o del servicio de red.
• Tratar los códigos de error de aplicación como "fallos de red". Un 404 o un 500 demuestran que la red funciona: la petición llegó y fue respondida. Escalar un 500 al equipo de redes es el clásico ticket mal dirigido.
• Buscar fronteras físicas entre las capas 5, 6 y 7 en el software. No existen: son distinciones analíticas. Úsalas para clasificar problemas (¿diálogo? ¿formato? ¿servicio?), no para diseccionar programas.
• Olvidar que DNS puede ser el culpable silencioso. Es capa 7, pero de él depende que todo lo demás empiece. "No funciona nada por nombre pero sí por IP" es la firma inconfundible de un problema DNS.
• Consejo: en un ticket de soporte, acostúmbrate a anotar la capa sospechosa y la evidencia ("capa 7: el servidor responde 500; capas 1-4 verificadas con ping y conexión al 443"). Convierte diagnósticos vagos en informes profesionales.
• Consejo: la tabla-resumen de arriba, memorizada con la columna de "lo esencial", vale más que cualquier mnemotecnia. Las siglas se olvidan; los problemas de cada capa, una vez entendidos, no.

Ejercicio 1. Clasifica cada elemento como proceso de usuario, protocolo de capa 7, o función de capas 5/6 dentro del software: (a) el cliente de correo que usa Jon; (b) SMTP; (c) la deserialización del JSON de la API de proyectos; (d) la cookie de sesión de la intranet; (e) DNS; (f) la hoja de cálculo de Ana.

Ejercicio 2. La aplicación de escritorio de administración falla al pedir GET /api/proyectos. Indica qué capa (aproximada) señala cada uno de estos resultados alternativos y qué harías en cada caso: (a) la conexión al puerto 443 expira en silencio; (b) conecta, pero responde 403 Forbidden; (c) conecta y responde 200 OK, pero la aplicación dice "formato de respuesta no válido"; (d) nslookup del nombre de la intranet no resuelve, aunque con la IP directa todo funciona.

Ejercicio 3. Como cierre del módulo: Marta pulsa Enviar en un formulario de la intranet y el navegador muestra un error. Sin más datos, escribe la secuencia de preguntas (una por capa o grupo de capas, de abajo arriba) con la que acotarías el problema, e indica junto a cada una la evidencia rápida que la responde. (Autoevaluación: compárala con la solución; el objetivo es que la escalera te salga ya de memoria.)

Solución 1. (a) Proceso de usuario (usa SMTP/IMAP, pero él no es capa 7). (b) Protocolo de capa 7. (c) Función de capa 6 dentro del software (representación). (d) Función de capa 5 dentro del software (estado del diálogo). (e) Protocolo de capa 7 (aunque sirva a la capa 3 traduciendo nombres a IPs). (f) Proceso de usuario (el protocolo de ficheros en red que use por debajo sí sería capa 7).

Solución 2. (a) El silencio con timeout apunta a capas 1-4: host caído, ruta rota o firewall que descarta — verificar con ping y desde otra red/equipo (¿recuerdas el trío de 03-05? esto es "me ignoran"). (b) Capa 7, autorización: la infraestructura entera funciona (la respuesta lo demuestra); revisar permisos/credenciales de la aplicación en la intranet. (c) Capa 6: transporte y servicio correctos, acuerdo de representación roto — comparar el JSON actual con el que la aplicación espera (el caso de la lección 03-07). (d) Capa 7, DNS: el servicio funciona pero el nombre no resuelve — revisar el registro A de intranet.grupomeridiano.example en el DNS interno.

Solución 3. Secuencia razonable: (1) Capa 1: ¿tiene red el PC de Marta? — icono de red/LED de enlace. (2) Capas 2-3 local: ¿alcanza su red? — ping 192.168.10.1 (gateway). (3) Capa 3 extremo a extremo: ¿alcanza el servidor? — ping 192.168.10.10. (4) Capa 7-DNS: ¿resuelve el nombre? — nslookup intranet.grupomeridiano.example. (5) Capa 4: ¿acepta el puerto 443? — ¿conecta, rechaza o ignora? (6) Capas 5-6: ¿sesión válida y sin errores de certificado/formato? — ¿le pide login? ¿avisa del certificado? (7) Capa 7: ¿qué código devuelve el servidor al enviar el formulario? — un 4xx/5xx localiza el fallo en permisos, en el dato enviado o en el software del servidor. Cada paso que pasa en verde descarta todo lo anterior; el primer rojo delimita la capa y el equipo responsable.

La capa de aplicación corona el modelo: es la ventanilla donde los programas piden servicios de red con vocabularios que modelan problemas humanos — documentos (HTTP), nombres (DNS), correo (SMTP), y encima de ellos las APIs que apilan contratos sobre contratos. Con ella queda respondida la pregunta pendiente desde 03-01: las capas 5, 6 y 7 son tres problemas distintos que OSI separa con razón, pero cuyas soluciones el software real funde en cada aplicación, como el navegador de Marta demuestra papel a papel. Y con ella se cierra el recorrido completo: siete capas, siete lecciones, una tabla-resumen que es a la vez mapa del módulo y chuleta de diagnóstico de por vida. Ahora bien: a lo largo del camino lo hemos repetido — OSI es el mapa teórico, el lenguaje con el que la profesión piensa y se entiende. Pero el territorio, la Internet real por la que viajan los paquetes de Meridiano, se construyó con otra pila: más pragmática, de menos capas, nacida de los protocolos que ya dominas — IP, TCP, UDP y compañía. Esa pila es el modelo TCP/IP, y a conocerla — primero por dentro, capa a capa, y solo al final frente a frente con OSI — dedicamos el módulo 4, empezando por la próxima lección: Introducción al Modelo TCP/IP.