Has recorrido dos veces el camino de los bits a las aplicaciones: con el mapa de siete capas de OSI (módulo 3) y con el de cuatro de TCP/IP (este módulo). Toca ponerlos frente a frente y responder las preguntas que todo profesional acaba haciéndose: ¿cómo se corresponden exactamente las capas?, ¿por qué existen dos modelos y no uno?, ¿cuál "es el bueno"? (spoiler: la pregunta está mal planteada), y ¿dónde caen los casos incómodos que no encajan limpio en ninguno — ARP, TLS, las VLANs, la famosa "capa 2.5"? Esta lección cierra el módulo 4 con una tesis práctica: OSI es el idioma para hablar y diagnosticar; TCP/IP es el plano de lo que realmente construyes y configuras. Dominar los dos — y saber traducir entre ellos sin tropezar en las fronteras — es lo que distingue a quien recita capas de quien las usa. Lo pondremos a prueba con mini-casos reales de Meridiano resueltos nombrando la capa en ambos modelos.

1. La tabla de correspondencia, capa a capa
2. Dos orígenes, dos filosofías: comité vs running code
3. Qué usar para qué: hablar con OSI, construir con TCP/IP
4. Los casos frontera: donde los mapas se arrugan
5. Mini-casos de Meridiano: diagnóstico bilingüe
6. Cierre del módulo: el mapa y el territorio

El mapeo canónico, con los protocolos ya conocidos como testigos de cada frontera:

Tres lecturas de la tabla:

• Las capas centrales coinciden una a una. Transporte↔Transporte y Red↔Internet son la zona estable del mapeo: nadie discute dónde va TCP o IP. No es casualidad — son las capas donde los protocolos reales definieron el modelo (TCP/IP) y donde OSI describía lo mismo que ya existía.
• Los extremos se comprimen. Arriba, TCP/IP funde 5-6-7 en Aplicación (razones en 04-05); abajo, funde 1-2 en Acceso a la red porque a IP le da igual la tecnología que tenga debajo (04-02). OSI detalla los extremos; TCP/IP los delega — arriba en cada aplicación, abajo en cada tecnología de red.
• Las PDUs sobreviven al cambio de modelo. Trama, paquete, segmento (03-01) significan lo mismo en ambos mapas: son vocabulario del territorio, no de los mapas. Por eso "el paquete no llega" es una frase inequívoca digas el modelo que digas.

Recordatorio de 04-01: existe también la variante híbrida de 5 capas (Física, Enlace, Red, Transporte, Aplicación) que usan casi todos los libros de texto modernos — es exactamente esta tabla partiendo "Acceso a la red" en dos. Si la ves, ya sabes traducirla.

Los dos modelos no compiten: nacieron para cosas distintas, y sus biografías lo explican todo (parte la conociste en 03-01 y 04-01):

La cultura de Internet lo resumió en un lema célebre atribuido a la IETF (el organismo que estandariza los protocolos de Internet): "we reject kings, presidents and voting; we believe in rough consensus and running code" — rechazamos reyes, presidentes y votaciones; creemos en el consenso aproximado y el código que funciona. Frente al edificio teórico de OSI, diseñado por comité para ser completo, TCP/IP se estandarizó a golpe de implementación: si dos programas interoperaban, era estándar de facto.

De ahí se derivan las dos personalidades:

• OSI es exhaustivo y simétrico: siete capas, cada función en su cajón, aunque el cajón quede casi vacío en la práctica (sesión y presentación, 03-06/03-07). Perfecto para analizar.
• TCP/IP es pragmático y asimétrico: cuatro capas de tamaños desiguales que reflejan dónde hay estandarización real (el centro) y dónde diversidad deliberada (los extremos). Perfecto para construir.

La convivencia de los dos modelos no es una anomalía histórica: es una división del trabajo que conviene explotar conscientemente.

OSI es el idioma. La industria entera numera con OSI, incluso quien jamás implementó un protocolo OSI:

• "switch de capa 2", "switch de capa 3", "balanceador de capa 7", "cortafuegos de capa 4" — todo el catálogo comercial habla OSI.
• "El problema es de capa 1" (un cable), "eso es capa 8" (el usuario — broma gremial incluida).
• El diagnóstico por capas del módulo 3 (03-05): descartar de abajo arriba exige el vocabulario fino — distinguir sesión de presentación te deja decir "el certificado TLS caducó" (≈6) frente a "el servidor corta las conexiones" (≈5) con precisión quirúrgica.

TCP/IP es el plano. Cuando tocas sistemas reales, lo que hay delante es la pila TCP/IP:

• La configuración de red de cualquier SO tiene exactamente las piezas de TCP/IP: interfaz (acceso a la red), IP/máscara/gateway/rutas (Internet), puertos y sockets (transporte), y servicios (aplicación). No hay ningún sitio donde "configurar la capa de presentación".
• Las capturas de tráfico del módulo 6 mostrarán trama → IP → TCP → HTTP: cuatro pisos, no siete.
• El código habla TCP/IP: la API de sockets (04-04) te da transporte; las bibliotecas (04-05) te dan aplicación. Nadie programa "contra la capa de sesión".

La regla mnemotécnica final: piensa en 4, comunica en 7. Diagnosticas y configuras sobre la realidad de cuatro capas, pero cuando abras un ticket, leas una hoja de datos o hables con otro técnico, el número de capa que se espera es el de OSI.

Aquí fallan los exámenes y las entrevistas: protocolos que no caen limpio en una capa. La tabla de los sospechosos habituales, con su veredicto práctico:

La lección de fondo de todos los casos: las capas son cajones de un archivador conceptual, no leyes físicas. Los protocolos reales se diseñan para resolver problemas, y algunos problemas viven en las juntas. Cuando algo no encaje, la pregunta útil no es "¿en qué capa ESTÁ?" sino "¿qué función hace y de qué capas depende?" — esa siempre tiene respuesta.

Practiquemos la traducción con cuatro incidentes, nombrando la capa en ambos modelos:

Caso 1 — "La impresora ha desaparecido". Marta no puede imprimir; nadie de Valencia puede. Ana descubre el conector RJ45 de la impresora medio salido tras una mudanza de mesas. Diagnóstico: OSI capa 1 (física) · TCP/IP capa de acceso a la red. Pista delatora: la interfaz sin enlace (ip link mostraría NO-CARRIER en un PC; en la impresora, el LED del puerto apagado). Ninguna orden de capas superiores podía funcionar.

Caso 2 — "Los invitados ven la intranet". Un portátil conectado a la Wi-Fi de invitados aparece en la red corporativa: el puerto del AP en el switch estaba asignado a la VLAN 10 en lugar de la 20. Diagnóstico: OSI capa 2 (enlace) · TCP/IP acceso a la red. La segmentación 802.1Q (03-03) es cosa de tramas y puertos de switch; las IPs que obtuvieron los invitados eran el síntoma (DHCP de la VLAN equivocada), no la causa.

Caso 3 — "Bilbao no llega a la intranet, pero Internet les va". Jon no abre intranet.grupomeridiano.example; el nombre resuelve bien, el ping a 192.168.10.10 muere. En el router de Bilbao, la ruta hacia 192.168.10.0/24 por el túnel VPN ha desaparecido tras un reinicio. Diagnóstico: OSI capa 3 (red) · TCP/IP capa de Internet. El caso 04-03 por excelencia: sin ruta, no hay entrega; la ruta por defecto (Internet) seguía intacta, por eso "lo demás va".

Caso 4 — "La API va, pero la sincronización de ficheros no". Desde Bilbao funciona la intranet (TCP:443) pero falla la conexión a SMB (TCP:445): rechazo inmediato. Misma máquina destino, mismo camino, un puerto responde y el otro no: una regla nueva del cortafuegos del router de Valencia bloquea el 445 desde la VPN. Diagnóstico: OSI capa 4 (transporte) · TCP/IP capa de transporte. La firma de 03-05/04-04: host vivo + puerto inaccesible = mira servicios y cortafuegos, no cables ni rutas.

Y uno de regalo que ya resolviste en 04-05: certificado "aún no válido" por reloj descuadrado — OSI ≈ capa 6 (presentación: validación TLS) · TCP/IP capa de aplicación. Fíjate en el patrón de los cinco casos: la capa OSI aporta precisión al describir; la capa TCP/IP te dice qué pieza del sistema tocar (interfaz, switch, tabla de rutas, cortafuegos, servicio).

Este embudo — que en el módulo 6 convertiremos en metodología completa con sus herramientas — es la comparativa OSI/TCP-IP hecha músculo.

Balance del módulo 4. Empezaste con la historia y la filosofía (04-01: ARPANET, la cintura de reloj de arena, la pila dentro del SO); bajaste a las interfaces reales (04-02), leíste tablas de rutas línea a línea (04-03), abriste sockets y estados de conexión desde el teclado (04-04) y recorriste una petición completa de la intranet, de la línea de código al datagrama DNS (04-05). Hoy has puesto los dos mapas uno sobre otro y has aprendido a traducir sin tropezar en ARP, TLS ni la capa 2.5.

La conclusión del doble viaje por los módulos 3 y 4: OSI es el mapa detallado; TCP/IP es el territorio con su propio plano de obra. Ninguno sobra. Con los dos dominados, ya no queda arquitectura pendiente — queda el detalle aplazado dos veces (en 02-03 y en 04-03): la anatomía fina de las direcciones IP. ¿Qué significan exactamente esos /24? ¿Cómo se parte una red en subredes, y por qué Meridiano eligió 192.168.10.0/24 y 192.168.20.0/24? ¿Qué hace posible que esas direcciones privadas salgan a Internet? Ese es el módulo 5.

• Preguntar "¿qué modelo es el correcto?" Es como preguntar si es más correcto el plano del metro o el callejero: describen lo mismo con propósitos distintos. OSI para comunicar y analizar; TCP/IP para construir y configurar.
• Mapear de memoria "OSI 5-6-7 = algo concreto de TCP/IP". No hay tres piezas separadas al otro lado: es una sola capa de aplicación donde cada protocolo se organiza como quiere. Forzar el troceo produce respuestas absurdas ("¿en qué puerto escucha la capa de sesión?").
• Dejarse engañar por los nombres. TLS no está en el transporte (pese a su nombre), ICMP no es de capa 4 (pese a viajar dentro de IP), y la capa de "Internet" de TCP/IP funciona igual en una LAN que jamás toque Internet.
• Tratar las capas como ley física. ARP, MPLS, QUIC y compañía existen precisamente en las juntas. Si un protocolo no encaja limpio, describe su función y sus dependencias en lugar de forzarle un número.
• Numerar capas TCP/IP en un contexto OSI (o viceversa) sin avisar. Si dices "capa 3" todo el mundo entenderá red/Internet, pero "capa 4" ya es ambiguo si tu interlocutor cuenta en el modelo de 4 capas. En caso de duda, nombra la capa ("transporte") en vez de numerarla: los nombres son inequívocos.
• Consejo: en tickets y documentación, acostúmbrate a la fórmula síntoma + capa nombrada + pieza sospechosa ("no hay conexión al 445 desde la VPN; transporte; probable regla de cortafuegos"). Obliga a pensar en capas y ahorra un ping-pong de preguntas a quien te lea.

1. Traduce cada elemento a su capa en AMBOS modelos (nombre de capa, no solo número): (a) la etiqueta VLAN 802.1Q de la trama que separa corporativa e invitados en el switch de Valencia; (b) el número de secuencia con el que el servidor de la intranet reordena los segmentos de una subida de fichero; (c) el TTL que se decrementa al cruzar el túnel VPN; (d) la cabecera Content-Type: application/json de la respuesta de /api/proyectos; (e) la negociación de claves del handshake TLS con la intranet.

2. Un fabricante anuncia: "cortafuegos de nueva generación con inspección en capa 7". El cortafuegos actual del router de Valencia filtra por IP y puerto. Explica: (a) en qué capas OSI trabaja el cortafuegos actual; (b) qué puede hacer el de "capa 7" que el actual no puede, con un ejemplo concreto sobre el tráfico HTTPS de la intranet de Meridiano; (c) por qué esa inspección choca con TLS y qué implica.

3. Tres incidentes en Meridiano; para cada uno, nombra la capa en ambos modelos y la primera comprobación que harías: (a) tras cambiar el AP de sitio, los móviles ven la red Wi-Fi con señal débil y van a trompicones, pero por cable todo va perfecto; (b) el servidor .10.10 responde al ping desde Bilbao, pero ssh 192.168.10.10 devuelve "connection refused" al instante; (c) la intranet carga, pero la página de proyectos muestra caracteres corruptos (á donde debería decir á).

1. (a) OSI: enlace de datos (2) · TCP/IP: acceso a la red — la etiqueta vive en la trama Ethernet. (b) OSI: transporte (4) · TCP/IP: transporte — números de secuencia son mecánica TCP (02-04). (c) OSI: red (3) · TCP/IP: Internet — el TTL es campo de la cabecera IP (02-03). (d) OSI: presentación (6), con matices de aplicación · TCP/IP: aplicación — declarar el formato de los datos es función de presentación clásica, transportada en una cabecera HTTP. (e) OSI: ≈ sesión/presentación (5-6) · TCP/IP: aplicación — el caso frontera TLS: establecer la sesión segura y acordar el cifrado.

2. (a) El filtro por IP trabaja en OSI 3 (red) y el filtro por puerto en OSI 4 (transporte) — en TCP/IP, capas de Internet y transporte. Es el cortafuegos clásico "de capa 3/4". (b) Uno de capa 7 inspecciona el contenido de aplicación: podría, por ejemplo, permitir GET /api/proyectos pero bloquear peticiones a /admin desde la VLAN de invitados, o distinguir tráfico web legítimo de otro protocolo camuflado en el puerto 443 — decisiones imposibles mirando solo IPs y puertos (recuerda: el puerto es convenio, no garantía). (c) Con TLS, el contenido HTTP va cifrado: el cortafuegos no puede leerlo salvo que actúe de intermediario TLS (descifrando y recifrando con certificados propios instalados en los equipos), lo que añade complejidad, coste y consideraciones de privacidad. Es la tensión permanente entre inspección y cifrado.

3. (a) OSI: física (1) · TCP/IP: acceso a la red — señal de radio débil es el medio físico puro. Primera comprobación: intensidad de señal/cobertura en la nueva ubicación del AP (y obstáculos). (b) OSI: transporte (4) · TCP/IP: transporte — ping OK (capa 3 sana) + rechazo inmediato = nadie escucha en el 22 o un cortafuegos rechaza (03-05). Primera comprobación: ss -tlnp | grep :22 en el servidor — ¿está el LISTEN de sshd? (c) OSI: presentación (6) · TCP/IP: aplicación — á es la firma de un texto UTF-8 interpretado como Latin-1 (03-07): los bytes llegan perfectos; se decodifican mal. Primera comprobación: la codificación declarada (Content-Type: ...; charset=) frente a la codificación real de los datos que sirve la API.

Ya tienes los dos mapas y el diccionario entre ellos: la correspondencia capa a capa (con el centro estable — transporte y red/Internet — y los extremos comprimidos), las dos filosofías que explican por qué OSI quedó como idioma y TCP/IP como realidad (rough consensus and running code), la regla operativa "piensa en 4, comunica en 7", y el manejo de los casos frontera — ARP en la junta 2/3, TLS como falso habitante del transporte, la capa 2.5 y compañía — que son donde se distingue la comprensión de la memorización. Los mini-casos de Meridiano te han enseñado el uso conjunto: OSI da la precisión del diagnóstico; TCP/IP señala la pieza que hay que tocar. Con esto se cierra el módulo 4: dominas el mapa y el territorio. El siguiente paso es el detalle que hemos aplazado deliberadamente desde el módulo 2: la anatomía de las direcciones IP — qué esconde exactamente un /24, cómo se diseñan subredes como las de Valencia y Bilbao, y cómo salen a Internet las direcciones privadas. Bienvenido al módulo 5: direccionamiento IP y subredes.