Al final del módulo anterior dejamos una idea en el aire: OSI es el mapa teórico, pero el territorio — la Internet real por la que viajan cada día los paquetes de Grupo Meridiano — se construyó con otra pila, más pragmática y de menos capas. Esa pila es el modelo TCP/IP, y esta lección es tu puerta de entrada a él: de dónde viene, por qué venció a los protocolos que la comunidad OSI intentó imponer, qué filosofía de diseño lo hizo imbatible y cómo se organizan sus cuatro capas. Es importante porque, a diferencia de OSI, TCP/IP no es un modelo que "se estudia": es el software que ahora mismo se está ejecutando en tu portátil, en el servidor de la intranet de Meridiano y en cada router del camino entre Valencia y Bilbao. Entenderlo es entender cómo funciona de verdad lo que configuras y diagnosticas.

1. De ARPANET a Internet: la historia de TCP/IP
2. Por qué TCP/IP ganó a los protocolos OSI
3. La filosofía de diseño: pragmatismo, robustez y la cintura de reloj de arena
4. Las cuatro capas del modelo TCP/IP
5. La variante académica de cinco capas
6. La pila TCP/IP dentro de un sistema operativo real
7. La petición de Marta, ahora en cuatro capas

TCP/IP no nació en un comité de estandarización, sino en un proyecto de investigación con un problema muy concreto que resolver.

• 1969 — ARPANET: la agencia DARPA (Defense Advanced Research Projects Agency, del Departamento de Defensa de EE. UU.) financia una red experimental que conecta cuatro universidades. Su protocolo inicial, NCP, funcionaba, pero solo dentro de esa red homogénea.
• Años 70 — el problema de la interconexión: aparecen otras redes (radio, satélite, redes locales) con tecnologías incompatibles entre sí. Vint Cerf y Bob Kahn se plantean la pregunta fundacional: ¿cómo conectamos redes distintas entre sí? De ahí la palabra Internet: inter-networking, interconexión de redes.
• 1974: Cerf y Kahn publican el diseño de TCP. Poco después se decide separar TCP en dos protocolos: IP (entregar paquetes entre redes, sin garantías) y TCP (fiabilidad extremo a extremo). Esta separación, que ya conoces por los módulos 2 y 3, es una de las decisiones de diseño más influyentes de la historia de la informática.
• 1 de enero de 1983 — el "flag day": ARPANET apaga NCP y enciende TCP/IP. Es la fecha que suele citarse como nacimiento técnico de Internet.
• Años 80-90: universidades, y después empresas y operadores, adoptan TCP/IP en masa. El sistema operativo Unix BSD lo incluye de serie con su API de sockets — si el sistema ya trae la pila gratis, ¿para qué implementar otra?

Aquí conviene deshacer una confusión frecuente. OSI no fue solo el modelo de 7 capas que estudiaste en el módulo 3: la ISO también definió protocolos OSI reales para cada capa (X.400 para correo, X.500 para directorio, TP0-TP4 para transporte...). Durante los años 80 muchos gobiernos —incluido el de EE. UU.— llegaron a exigir protocolos OSI en sus compras. Y aun así perdieron. ¿Por qué?

La comunidad de Internet (el IETF, que publica las RFC) resumió su método en un lema famoso, atribuido a Dave Clark:

"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.)

"Rough consensus and running code" significa: un estándar de Internet no se aprueba por votación política, sino cuando hay acuerdo general y al menos dos implementaciones independientes que funcionan e interoperan. TCP/IP ganó porque cuando las empresas quisieron conectarse en red, ya existía código funcionando, gratuito y probado — mientras los protocolos OSI seguían siendo, en gran parte, documentos.

De ahí la frase que resume toda esta lección: OSI ganó la guerra del vocabulario; TCP/IP ganó la guerra de las redes. Hablamos con las 7 capas de OSI, pero construimos con las 4 de TCP/IP.

TCP/IP no es solo una lista de protocolos: es una manera de pensar que explica por qué Internet escala y sobrevive. Tres principios la definen.

La red (los routers intermedios) solo hace una cosa: mover paquetes IP hacia su destino, sin garantías (best effort, "mejor esfuerzo"). No garantiza entrega, ni orden, ni ausencia de duplicados. Esto, que parece una debilidad, es la clave de su escalabilidad: un router no necesita recordar nada sobre tus conexiones, solo mirar la dirección de destino y reenviar (como viste en 03-04). Menos trabajo por paquete → routers más simples → red más grande y barata.

Si la red no garantiza nada, ¿quién lo hace? Los extremos. El principio extremo a extremo (end-to-end) dice: las funciones complejas (fiabilidad, orden, control de errores) deben implementarse en los equipos finales — el PC de Marta y el servidor .10 —, no dentro de la red. Es exactamente el reparto de trabajo que viste en 03-05: TCP en los extremos reordena, retransmite y controla el flujo; los routers del medio ni se enteran.

Este diseño nació además con la robustez como objetivo explícito: si un router del camino cae, IP simplemente encamina por otro lado y TCP retransmite lo perdido. Nadie tiene que "reparar la sesión" en el centro de la red, porque el centro de la red no guarda sesiones.

Dibuja la pila de protocolos como un reloj de arena:

Arriba, decenas de protocolos de aplicación. Abajo, decenas de tecnologías físicas. Y en el centro, un único protocolo por el que todo pasa: IP. Esa es la "cintura del reloj de arena" (hourglass waist), y sus consecuencias son enormes:

• Cualquier aplicación funciona sobre cualquier tecnología de red, sin conocerla. La intranet de Meridiano no sabe si Jon llega por fibra, por Wi-Fi o por 4G — y no le hace falta.
• Innovar arriba y abajo es independiente: se puede inventar un protocolo de aplicación nuevo (como se inventó HTTP en 1991) o una tecnología de acceso nueva (como el 5G) sin tocar el resto de la pila. Solo hay que hablar IP.
• El precio: cambiar la propia cintura es dificilísimo. Por eso la transición de IPv4 a IPv6 (que solo mencionamos aquí; la veremos en el módulo 5) lleva décadas en marcha.

El modelo TCP/IP organiza todo lo que ya sabes en cuatro capas. No te presenta protocolos nuevos: reagrupa los que dominaste en el módulo 2.

Observa las dos "fusiones" respecto a OSI (las justificaremos a fondo en 04-06):

• Acceso a la red = física + enlace: a TCP/IP no le importa cómo es el medio; le basta con que la trama llegue al siguiente salto. Lo veremos en 04-02.
• Aplicación = sesión + presentación + aplicación: las funciones de las capas 5 y 6 (que en 03-06 y 03-07 viste "disueltas" en TLS y en los formatos de datos) viven dentro de las propias aplicaciones. Lo veremos en 04-05.

Cada lección de este módulo recorre una capa (04-02 a 04-05), y la última (04-06) pone los dos modelos frente a frente.

En muchos libros de texto (Tanenbaum, Kurose & Ross...) verás una pila de cinco capas: aplicación, transporte, red, enlace y física. No es un tercer modelo: es TCP/IP con su capa de acceso a la red dividida en dos, tomando prestada la separación de OSI porque es didácticamente útil (los problemas de un cable roto y los de una tabla MAC son muy distintos, como viste en 03-02 y 03-03).

Consejo práctico: cuando alguien diga "capa 2" o "capa 3" siempre está numerando en OSI, incluso si está trabajando con TCP/IP. Nadie llama "capa 2" a la capa de Internet. Los números son de OSI; los nombres de capa TCP/IP se usan sin número.

Aquí está la diferencia práctica más importante con OSI: TCP/IP no es un diagrama, es código instalado en tu máquina. Veamos quién implementa qué en el PC de Marta (Windows) y en el servidor de la intranet (Linux).

• La aplicación (navegador, servidor de la intranet) implementa la capa de aplicación: construye la petición HTTP, negocia TLS, decide qué host resolver por DNS.
• El kernel (el núcleo del SO) implementa transporte e Internet: cuando el navegador "envía datos", en realidad se los entrega al kernel por la API de sockets (02-04), y es el kernel quien fabrica segmentos TCP y paquetes IP, consulta la tabla de rutas y gestiona retransmisiones. Por eso no existe un programa llamado tcp.exe: TCP es parte del sistema operativo.
• El driver y la tarjeta de red implementan el acceso a la red: tramas, direcciones MAC, señales.

Y los comandos que ya has usado son las ventanas de configuración y consulta de esa pila del kernel:

Fíjate en el detalle conceptual: ipconfig e ip no envían nada por la red; leen y escriben la configuración de la pila TCP/IP que vive dentro del kernel. Cuando en el módulo 6 usemos herramientas de diagnóstico, casi todas serán también conversaciones con esa pila.

En 03-01 recorriste la petición de Marta a la intranet bajando las 7 capas de OSI. Repitámosla en el modelo real, con las PDUs que ya conoces:

Cuatro pasos en lugar de siete, y ni una función nueva: DNS, TLS y HTTP viven juntos en la capa de aplicación (lo que en OSI repartías entre 7, 6 y 5); el resto es idéntico. En el servidor .10, la pila sube en orden inverso y entrega la petición al proceso del servidor web que escucha en el puerto 443. Mismo territorio; mapa más compacto.

• Creer que TCP/IP son solo dos protocolos. "TCP/IP" es el nombre de toda la familia (también llamada Internet protocol suite): incluye UDP, ICMP, DNS, HTTP... Se llama así por sus dos miembros fundadores.
• Pensar que OSI y TCP/IP compiten y hay que elegir. Conviven con papeles distintos: OSI es el vocabulario para pensar y comunicarte; TCP/IP es lo que está implementado. Un buen profesional usa ambos (lo sistematizamos en 04-06).
• Decir "capa 3 de TCP/IP". Los números de capa son jerga OSI. En TCP/IP di "capa de Internet". Si mezclas numeraciones, tu interlocutor no sabrá si tu "capa 4" es transporte (OSI) o aplicación (TCP/IP contando desde abajo).
• Buscar el "programa TCP" en el sistema. TCP e IP los implementa el kernel del sistema operativo. Las aplicaciones solo ven sockets. Si un desarrollador de Meridiano pregunta "¿qué librería HTTP trae el sistema para hablar TCP?", la respuesta es: ninguna librería implementa TCP; todas usan el del kernel.
• Menospreciar el "best effort" de IP como un defecto. Es una decisión deliberada que hace posible la escala de Internet. La fiabilidad no falta: está donde debe, en los extremos.
• Consejo: memoriza el dibujo del reloj de arena. Es la imagen que mejor explica por qué Internet funciona sobre cualquier tecnología y por qué IPv4→IPv6 es tan lento.

Sitúa cada elemento en su capa del modelo TCP/IP (acceso a la red, Internet, transporte o aplicación): (a) el handshake de tres vías, (b) la consulta DNS de intranet.grupomeridiano.example, (c) el TTL que se decrementa en el router de Valencia, (d) la trama con etiqueta 802.1Q de la VLAN 10, (e) el mensaje ICMP "destino inalcanzable", (f) la negociación TLS entre el navegador de Marta y la intranet.

La VPN entre Valencia y Bilbao pasa por Internet, y una tarde un router intermedio del operador se reinicia. Jon estaba descargando un fichero de 200 MB del servidor .10 y la descarga se completó sin errores, solo un poco más lenta. Explica qué principio (o principios) de diseño de TCP/IP acaban de salvar la descarga, y qué hizo cada capa implicada.

Un desarrollador de Meridiano escribe un script que llama a GET /api/proyectos. Para cada una de estas acciones, indica si la realiza su código/librería (espacio de usuario), el kernel o el driver/tarjeta de red: (1) construir la línea GET /api/proyectos HTTP/1.1, (2) retransmitir un segmento perdido, (3) calcular el FCS de la trama, (4) elegir la interfaz de salida consultando la tabla de rutas, (5) cifrar los datos con TLS.

Ejercicio 1: (a) transporte — es TCP (02-04). (b) aplicación — DNS es un protocolo de aplicación (02-05). (c) Internet — el TTL es un campo de la cabecera IP (02-03). (d) acceso a la red — 802.1Q es Ethernet/VLAN (03-03). (e) Internet — ICMP acompaña a IP en su capa (02-03). (f) aplicación — en TCP/IP no hay capas de sesión/presentación; TLS vive con la aplicación (03-06/03-07 explican por qué).

Ejercicio 2: Principios: best effort + robustez de IP y principio extremo a extremo. La capa de Internet no guardaba ningún estado de la descarga en el router caído: en cuanto los protocolos de encaminamiento del operador convergieron, los paquetes fluyeron por otro camino (encaminamiento salto a salto, 03-04). Los paquetes perdidos durante el corte no los recuperó la red: los detectó y retransmitió TCP en los extremos (el servidor .10 reenvió lo no confirmado). La aplicación de Jon ni se enteró: solo vio un flujo de bytes algo más lento. La red hizo lo mínimo; los extremos garantizaron la fiabilidad.

Ejercicio 3: (1) código/librería — capa de aplicación en espacio de usuario. (2) kernel — TCP vive en el kernel. (3) driver/tarjeta — el FCS lo calcula normalmente el hardware de la NIC (03-03). (4) kernel — la tabla de rutas es del kernel (capa de Internet). (5) código/librería — TLS lo implementa una biblioteca en espacio de usuario (p. ej. la librería TLS que usa el lenguaje del script), no el kernel.

Ya conoces el territorio en su conjunto: TCP/IP nació en ARPANET para interconectar redes distintas, venció a los protocolos OSI gracias al running code y a las especificaciones abiertas, y se sostiene sobre tres ideas — una red mínima de mejor esfuerzo, la inteligencia en los extremos y IP como cintura universal por la que todo pasa. Sus cuatro capas (acceso a la red, Internet, transporte y aplicación) no traen protocolos nuevos: reorganizan todo lo que aprendiste en el módulo 2, y viven como código real en el kernel, las bibliotecas y los drivers de cada máquina de Meridiano. En las próximas cuatro lecciones bajaremos a cada capa con mirada práctica — no "qué hace" (eso ya lo sabes), sino "cómo se ve y se toca en un sistema real". Empezamos por abajo, por la capa que TCP/IP dejó deliberadamente abierta para funcionar sobre cualquier cable, onda o fibra: la capa de acceso a la red.