Modelos OSI y TCP/IP

El Modelo OSI Explicado #

El modelo de Interconexión de Sistemas Abiertos (OSI) es un marco conceptual que divide la comunicación de red en siete capas distintas. Para ingenieros QA, este modelo proporciona una forma sistemática de diagnosticar dónde ocurren los problemas de red — en lugar de decir “no funciona,” puedes identificar la capa exacta que causa la falla.

Piensa en el modelo OSI como un sistema postal. Cuando envías una carta, pasa por múltiples etapas: escribes el contenido (Aplicación), lo pones en un sobre con dirección (Presentación/Sesión), la oficina postal lo enruta (Transporte/Red), el camión lo entrega (Enlace de Datos), y el camino físico lleva al camión (Física). Cada capa tiene un trabajo específico.

Capa 7: Aplicación #

La capa más cercana al usuario. Protocolos como HTTP, HTTPS, FTP, SMTP y DNS operan aquí. Cuando obtienes un 404 Not Found o 500 Internal Server Error, estás lidiando con un problema de capa de Aplicación.

Relevancia QA: API testing, web testing y la mayoría del testing funcional ocurren en esta capa.

Capa 6: Presentación #

Maneja el formato de datos, cifrado y compresión. El cifrado SSL/TLS opera en esta capa. Los problemas de codificación de caracteres (UTF-8 vs. ASCII) son problemas de la capa de Presentación.

Relevancia QA: Bugs de encoding, errores de certificados SSL y desajustes de formato de datos.

Capa 5: Sesión #

Gestiona sesiones entre aplicaciones — establecer, mantener y terminar conexiones. Los tokens de sesión y sesiones de autenticación se relacionan con esta capa.

Relevancia QA: Testing de timeout de sesión, persistencia de sesión entre balanceadores de carga.

Capa 4: Transporte #

Proporciona comunicación de extremo a extremo entre procesos. TCP y UDP son los protocolos principales. Los números de puerto viven aquí. Los errores “Connection refused” y “connection timeout” se originan en esta capa.

Relevancia QA: Problemas de conexión, disponibilidad de puertos, configuraciones de timeout.

Capa 3: Red #

Maneja el direccionamiento lógico (direcciones IP) y enrutamiento. Ping y traceroute operan aquí. “Destination unreachable” y errores de enrutamiento son problemas de la capa de Red.

Relevancia QA: Conectividad IP, resolución DNS (parcialmente), problemas de enrutamiento de red.

Capa 2: Enlace de Datos #

Gestiona el direccionamiento físico (direcciones MAC) y la entrega de frames en una red local. Ethernet y WiFi operan aquí.

Relevancia QA: Problemas de conectividad WiFi durante testing móvil, problemas de switches de red.

Capa 1: Física #

El hardware real — cables, señales inalámbricas, tarjetas de interfaz de red. La intensidad de señal y problemas de conectividad física están aquí.

Relevancia QA: Raramente relevante directamente, pero importante al testear en entornos de hardware o IoT.

El Modelo TCP/IP #

Mientras el modelo OSI es un marco teórico, el modelo TCP/IP refleja cómo funciona realmente internet. Condensa las siete capas OSI en cuatro capas prácticas:

El modelo TCP/IP es lo que ejecuta cada red con la que interactúas. Al depurar problemas del mundo real, encontrarás terminología TCP/IP más seguido que terminología OSI. Sin embargo, el modelo OSI proporciona mayor granularidad que ayuda al explicar problemas a ingenieros de red.

La diferencia clave: OSI es un modelo de referencia para entender; TCP/IP es la implementación que impulsa internet. Ambos son valiosos para ingenieros QA — OSI para comunicación precisa sobre problemas, TCP/IP para entender qué sucede realmente en la red.

Capas de Red y QA #

Como ingeniero QA, no necesitas experiencia profunda en cada capa. La mayor parte de tu trabajo ocurre en tres capas:

Capa de Aplicación (HTTP, API Testing) #

Aquí es donde ocurre el 80% de la depuración de red en QA. Códigos de estado HTTP, payloads de respuesta API, valores de headers y content types son todos problemas de la capa de Aplicación. Herramientas como Postman, curl y DevTools del navegador inspeccionan esta capa.

Síntomas comunes: Datos de respuesta incorrectos, status codes erróneos, headers faltantes, fallos de autenticación.

Capa de Transporte (TCP/UDP, Problemas de Conexión) #

Cuando no puedes conectarte a un servicio en absoluto, el problema generalmente está en la capa de Transporte. “Connection refused” significa que el puerto no está escuchando. “Connection timed out” significa que los paquetes no están llegando.

Síntomas comunes: No se puede conectar, conexiones caídas, transferencia de datos lenta, conflictos de puertos.

Comandos de diagnóstico:

# Verificar si un puerto está abierto
nc -zv hostname 8080

# Ver conexiones activas y puertos escuchando
ss -tlnp

# Probar conectividad TCP
telnet hostname 443

Capa de Red (Enrutamiento IP, DNS) #

Cuando un host es completamente inalcanzable, el problema probablemente está en la capa de Red. Fallos de ping, traceroute sin respuesta y fallos de resolución DNS apuntan aquí.

Síntomas comunes: Host inalcanzable, alta latencia, paquetes perdidos en tránsito.

Comandos de diagnóstico:

# Probar conectividad básica
ping hostname

# Rastrear la ruta a un host
traceroute hostname

# Verificar resolución DNS
nslookup hostname
dig hostname

Análisis Avanzado de Capas #

Entender las Unidades de Datos de Protocolo (PDU) en cada capa ayuda a los ingenieros QA a leer capturas de red y diagnosticar problemas complejos:

Encapsulación y Tamaño de Paquete #

Mientras los datos descienden por las capas, cada capa agrega su propio header. Esta encapsulación incrementa el tamaño total:

• Datos de aplicación: tamaño variable
• Header TCP: 20-60 bytes
• Header IP: 20-60 bytes
• Header de frame Ethernet: 14 bytes + 4 bytes trailer

La Unidad Máxima de Transmisión (MTU) — típicamente 1500 bytes para Ethernet — limita el tamaño de un frame individual. Cuando un paquete excede el MTU, debe fragmentarse. Los problemas de fragmentación causan fallos parciales misteriosos que son difíciles de diagnosticar sin entender la encapsulación.

Escenario QA: Un endpoint de API funciona para payloads pequeños pero falla para los grandes. La causa puede ser fragmentación relacionada con MTU donde algunos fragmentos son descartados por un firewall que no reensambla paquetes fragmentados.

Bugs Comunes por Capa que QA Encuentra #

Bugs de capa de aplicación:

• API devuelve header Content-Type incorrecto
• Headers CORS faltantes en endpoints específicos
• Headers de caching causan datos obsoletos

Bugs de capa de transporte:

• Agotamiento del pool de conexiones bajo carga
• Desajuste de timeout de TCP keepalive entre cliente y servidor
• Conflictos de puertos entre servicios en entornos de prueba

Bugs de capa de red:

• Caché DNS devuelve IP obsoleta después del despliegue
• Tablas de enrutamiento no actualizadas después de cambio de infraestructura
• TTL muy bajo causando que los paquetes expiren en tránsito

Ejercicio Práctico #

Dados los siguientes cinco escenarios de error de red, identifica la capa OSI donde ocurre cada uno y la herramienta de diagnóstico que usarías:

1. Escenario: curl: (7) Failed to connect to api.example.com port 443: Connection refused
2. Escenario: ping: cannot resolve api.example.com: Unknown host
3. Escenario: curl: (60) SSL certificate problem: certificate has expired
4. Escenario: HTTP/1.1 502 Bad Gateway devuelto por el balanceador de carga
5. Escenario: traceroute muestra paquetes con timeout después del salto 5

Pro Tips #

• Al depurar, trabaja de abajo hacia arriba: ¿puedes hacer ping al host? ¿Puedes conectarte al puerto? ¿Puedes obtener una respuesta HTTP? Este enfoque sistemático ahorra tiempo.
• La mayor parte del trabajo QA ocurre en las capas 4 (Transporte) y 7 (Aplicación), pero entender las capas inferiores te ayuda a comunicarte con precisión con ingenieros de red y DevOps.
• “Connection refused” es un problema de capa de Transporte; “404 Not Found” es un problema de capa de Aplicación. Conocer la diferencia inmediatamente reduce el área de investigación.
• Los problemas de MTU causan fallos parciales misteriosos — cuando las respuestas API grandes fallan pero las pequeñas funcionan, considera la fragmentación.
• Usa traceroute para identificar qué salto de red está causando latencia — la salida muestra exactamente dónde los paquetes se ralentizan o se pierden.

Puntos Clave #

1. Los modelos OSI/TCP-IP proporcionan un marco para diagnosticar sistemáticamente problemas de red durante el testing
2. La mayoría de los problemas relevantes para QA ocurren en las capas de Aplicación (errores HTTP) y Transporte (problemas de conexión)
3. La resolución de problemas de abajo hacia arriba (ping, luego conectar, luego solicitar) es el enfoque de diagnóstico más eficiente
4. Entender las capas de red ayuda a QA a comunicarse efectivamente con ingenieros de red y equipos DevOps