Modelos de capas y encapsulación en redes de computadoras

Por qué pensar en capas simplifica los problemas de red

En redes, muchos síntomas se parecen ("no carga", "se corta", "no responde"), pero las causas pueden estar en lugares distintos. El enfoque por capas sirve para separar responsabilidades: cada capa ofrece un servicio a la de arriba y se apoya en la de abajo. Así puedes razonar con orden: si una capa falla, las superiores suelen fallar también, pero no al revés.

En este capítulo usaremos un modelo práctico de 4 capas (muy usado en operación diaria): enlace, red, transporte y aplicación. No es el único modelo, pero es suficiente para diagnosticar y diseñar comunicaciones en servidores.

Funciones de cada capa (modelo de 4 capas)

Capa de enlace (Link)

Se encarga de mover datos dentro del mismo medio o red local (por ejemplo, Ethernet o Wi‑Fi). Trabaja con direcciones físicas (MAC) y define cómo se accede al medio, cómo se detectan errores básicos y cómo se forman las tramas.

• Unidad de datos: trama (p. ej., trama Ethernet).
• Identificadores típicos: MAC origen/destino, VLAN (si aplica).
• Problemas típicos: cable desconectado, interfaz down, VLAN incorrecta, Wi‑Fi débil, errores/colisiones, MTU mal configurada en el enlace.

Capa de red (Internet/Network)

Permite que los datos viajen entre redes distintas. Define el direccionamiento lógico (IP) y el enrutamiento. Aquí se decide por dónde sale el tráfico (gateway) y cómo llega a otra subred o a Internet.

• Unidad de datos: paquete (p. ej., paquete IP).
• Identificadores típicos: IP origen/destino, TTL, rutas.
• Problemas típicos: IP/máscara incorrecta, gateway incorrecto, ruta faltante, NAT mal aplicado, ICMP bloqueado (afecta diagnósticos), fragmentación por MTU.

Capa de transporte

Provee comunicación extremo a extremo entre procesos (aplicaciones) usando puertos. Puede ofrecer confiabilidad (TCP) o baja latencia y simplicidad (UDP). Es donde aparecen conceptos como conexión, retransmisión, control de congestión y orden de entrega (en TCP).

Continúa en nuestra aplicación.

• Escuche el audio con la pantalla apagada.
• Obtenga un certificado al finalizar.
• ¡Más de 5000 cursos para que explores!

O continúa leyendo más abajo...

Descargar la aplicación

• Unidades de datos: segmento TCP o datagrama UDP (en la práctica se suele decir “segmento” para TCP y “datagrama” para UDP).
• Identificadores típicos: puerto origen/destino, flags TCP (SYN/ACK/FIN), ventana.
• Problemas típicos: puerto bloqueado por firewall, servicio no escuchando, timeouts, resets, pérdida de paquetes (más visible en UDP), saturación.

Capa de aplicación

Define el “idioma” que hablan cliente y servidor: HTTP(S), DNS, SSH, SMTP, etc. Aquí viven los formatos de mensajes, autenticación, sesiones y semántica del intercambio (por ejemplo, “GET /index.html”).

• Unidad de datos: datos/mensajes de aplicación (por ejemplo, una petición HTTP, una respuesta DNS).
• Problemas típicos: DNS mal configurado, certificados TLS inválidos, credenciales, rutas de API, errores 4xx/5xx, incompatibilidad de versiones.

Encapsulación: cómo viajan los datos realmente

Cuando una aplicación envía datos, cada capa agrega su propia información de control (cabeceras y, a veces, tráiler). A esto se le llama encapsulación. En el receptor ocurre lo inverso: desencapsulación.

Ejemplo de encapsulación (HTTP sobre TCP/IP sobre Ethernet)

Imagina que un navegador pide una página:

HTTP (datos de aplicación) -> TCP (segmento) -> IP (paquete) -> Ethernet (trama)

Una forma de visualizarlo:

Lo importante para operar servidores: si ves un problema en “HTTP”, no asumas que es HTTP; puede ser que TCP no conecte, que IP no enrute o que el enlace esté caído. El modelo te obliga a comprobar por niveles.

Qué cambia al pasar de HTTP a HTTPS (capa de aplicación)

HTTP y HTTPS comparten la misma idea de aplicación (solicitudes/respuestas), pero HTTPS agrega TLS para cifrado y autenticación. Aunque TLS suele describirse “entre aplicación y transporte”, operativamente lo tratamos como parte del comportamiento de aplicación porque cambia el flujo y los requisitos (certificados, SNI, ciphers, etc.).

Cambios prácticos observables

• Puerto por defecto: HTTP suele usar 80/TCP, HTTPS 443/TCP.
• Handshake adicional: antes de enviar HTTP “en claro”, el cliente y servidor negocian TLS (versiones, cifrados) y validan el certificado.
• Contenido cifrado: intermediarios ya no ven URLs/cabeceras/cuerpo (salvo metadatos como IP/puerto y, en algunos casos, SNI).
• Nuevos puntos de falla: certificado expirado, CN/SAN no coincide, cadena incompleta, hora del sistema incorrecta, TLS bloqueado por inspección, ciphers incompatibles.

Mini guía paso a paso: comprobar HTTP vs HTTPS desde un servidor

Objetivo: distinguir si el problema está en conectividad TCP o en TLS/aplicación.

1. Verifica que el puerto esté accesible (transporte):

   # TCP connect test (si está disponible en tu entorno)  nc -vz ejemplo.com 80 nc -vz ejemplo.com 443

   Si 443 no conecta pero 80 sí, el cambio no es “HTTP vs HTTPS” como protocolo, sino puerto/ACL/firewall/servicio.

2. Si 443 conecta, prueba el handshake TLS (aplicación/TLS):

   openssl s_client -connect ejemplo.com:443 -servername ejemplo.com

   Busca errores de certificado, protocolos no soportados o fallos de negociación.

3. Comprueba la respuesta HTTP sobre TLS:

   curl -I https://ejemplo.com

   Si el TLS funciona pero recibes 401/403/404/500, ya estás en un problema de aplicación (autenticación, rutas, backend, etc.).

Qué cambia al pasar de TCP a UDP (capa de transporte)

TCP y UDP usan puertos, pero se comportan distinto. Cambiar de TCP a UDP no cambia IP ni Ethernet, pero sí cambia la forma en que se entrega (o no) la información.

Diferencias operativas clave

• Conexión: TCP establece conexión (SYN/SYN-ACK/ACK). UDP no: envía y listo.
• Confiabilidad: TCP retransmite, ordena y controla congestión. UDP no garantiza entrega ni orden.
• Latencia: UDP puede ser más rápido en escenarios donde la aplicación tolera pérdida o implementa su propia recuperación.
• Diagnóstico: en TCP es común ver “connection refused”, “timeout”, resets. En UDP, muchas fallas se ven como “silencio” (no hay respuesta).

Ejemplo práctico: DNS (UDP) vs un servicio web (TCP)

DNS típicamente usa 53/UDP para consultas rápidas. Si el firewall bloquea UDP/53, el síntoma puede ser “no resuelve nombres”, aunque el resto de la conectividad IP esté bien. En cambio, un sitio web típico usa TCP/443; si bloqueas 443/TCP, el navegador no podrá establecer conexión.

Mini guía paso a paso: distinguir un problema TCP de uno UDP

1. Identifica protocolo y puerto del servicio: por ejemplo, DNS = UDP/53, syslog = UDP/514 (común), HTTP = TCP/80, HTTPS = TCP/443.

2. Para TCP, prueba conexión:

   nc -vz servidor 443

   Si falla, revisa firewall, servicio escuchando, rutas.

3. Para UDP, prueba con una consulta real del protocolo (mejor que “ping”):

   # DNS query (UDP por defecto) dig @8.8.8.8 ejemplo.com

   Si no hay respuesta, puede ser bloqueo UDP, pérdida, o que el servidor no atiende.

Usar la lógica por capas para aislar fallas (guía práctica)

La idea es ir de abajo hacia arriba: si una capa inferior no funciona, no tiene sentido depurar la superior todavía. A continuación, un flujo práctico para un servidor que “no llega” a un servicio.

Paso 1: Enlace — ¿hay portadora y configuración básica del interfaz?

• Síntomas típicos: interfaz down, sin link, muchos errores.
• Comprobaciones: estado del NIC, cable/switch, VLAN asignada, contadores de errores.
• Ejemplos de comandos:

# Linux (ejemplos comunes) ip link show ethtool eth0  # si está disponible

Si el enlace está caído, todo lo demás fallará: DNS, HTTP, SSH, etc.

Paso 2: Red — ¿hay IP correcta y ruta hacia el destino?

• Síntomas típicos: no hay salida a otra red, solo funciona local, o no hay retorno.
• Comprobaciones: IP/máscara, gateway, tabla de rutas, conflicto de IP.
• Ejemplos de comandos:

ip addr show ip route ping -c 3 <gateway> ping -c 3 <ip_destino>

Si puedes hacer ping al gateway pero no al destino, suele ser ruta/ACL/NAT en el camino. Si ni siquiera llegas al gateway, es configuración local o enlace.

Paso 3: Transporte — ¿el puerto/protocolo está permitido y el servicio escucha?

• Síntomas típicos: timeouts (bloqueo o pérdida), connection refused (no hay servicio escuchando o rechazo explícito), resets.
• Comprobaciones: firewall local/remoto, security groups, ACLs, servicio levantado, puertos en escucha.
• Ejemplos de comandos:

# Ver puertos en escucha en el servidor local ss -lntup  # lista TCP/UDP escuchando # Probar conectividad TCP al puerto remoto nc -vz <host> 443

Un caso clásico: “la web no abre” pero IP responde. Si IP funciona y el puerto 443 no, el problema está en transporte/filtrado o en el servicio.

Paso 4: Aplicación — ¿DNS, TLS y el protocolo de aplicación están bien?

• Síntomas típicos: DNS no resuelve, HTTP 500, TLS handshake falla, credenciales inválidas.
• Comprobaciones DNS:

dig ejemplo.com nslookup ejemplo.com

• Comprobaciones HTTP/HTTPS:

curl -I http://ejemplo.com curl -I https://ejemplo.com

Ejemplo de aislamiento: si curl -I https://IP funciona pero curl -I https://nombre falla, el problema suele ser DNS (o SNI/certificado si el servidor requiere nombre).

Mapa rápido de síntomas a capa probable