Visualiza cómo funciona internet: TCP/IP, DNS, Routing BGP y CDN — con animaciones interactivas
Haz clic en cada capa para ver sus protocolos, PDU y función. Luego usa el simulador de encapsulamiento.
Así viajan los datos cuando tu navegador pide una página web:
| Capa OSI | Nombre OSI | Capa TCP/IP | PDU |
|---|---|---|---|
| 7 | Aplicación | Aplicación | Datos/Mensaje |
| 6 | Presentación | ||
| 5 | Sesión | ||
| 4 | Transporte | Transporte | Segmento/Datagrama |
| 3 | Red | Internet | Paquete IP |
| 2 | Enlace de Datos | Enlace | Trama / Bits |
| 1 | Física |
TCP/IP, DNS, Routing BGP, CDN y protocolos de internet explicados con ejemplos prácticos
El protocolo HTTP ha evolucionado enormemente desde 1991. Cada versión resuelve problemas de rendimiento que la anterior no podía abordar. Comprender las diferencias ayuda a entender por qué las webs modernas cargan tan rápido.
| Versión | Año | Multiplexación | Compresión headers | Protocolo base | Ventaja principal |
|---|---|---|---|---|---|
| HTTP/1.1 | 1997 | No (una req. por conexión) | No | TCP | Conexiones persistentes (Keep-Alive) |
| HTTP/2 | 2015 | Sí (múltiples streams sobre un TCP) | Sí (HPACK) | TCP | Elimina head-of-line a nivel de aplicación; reduce latencia hasta un 50 % |
| HTTP/3 (QUIC) | 2022 | Sí (streams QUIC independientes) | Sí (QPACK) | UDP / QUIC | Elimina el head-of-line TCP; handshake 0-RTT; ideal en redes móviles |
Estudia el modelo TCP/IP para un examen de redes. El visualizador de capas con encapsulamiento animado le permite entender de forma visual cómo se añaden y eliminan las cabeceras en cada capa, algo que los libros de texto describen pero pocas veces muestran en movimiento.
Su aplicación tarda 3 segundos en cargar en móvil aunque en el PC va bien. Con la pestaña CDN descubre la diferencia de latencia entre regiones y entiende por qué necesita distribuir los assets estáticos. Con la comparativa HTTP/2 vs HTTP/3 decide activar HTTP/3 en su servidor.
Necesita entender el flujo completo de resolución DNS para depurar por qué un cambio de registro no se propaga. El diagrama paso a paso del resolver iterativo le muestra exactamente dónde puede estar el problema: caché del ISP, TTL demasiado alto, o configuración del servidor autoritativo.
Escucha hablar de "DNS", "TCP/IP" y "CDN" y quiere saber qué significan en la práctica. El visualizador le permite seguir el viaje de una petición desde que escribe "google.com" en el navegador hasta que aparece la página, sin necesidad de conocimientos técnicos previos.
En menos de 200 milisegundos ocurren docenas de pasos. Aquí están los más importantes:
El navegador comprueba su caché interna. Si no hay entrada válida, pregunta al resolver del sistema operativo, que a su vez consulta al resolver del ISP. Este sigue la cadena Root Server → TLD .com → servidor autoritativo de Google, y obtiene la IP (142.250.184.46). Todo esto ocurre en 20-100 ms gracias a las cachés en cada nivel.
El navegador abre una conexión TCP con el servidor: envía SYN → recibe SYN-ACK → envía ACK. Este proceso de 3 mensajes establece los números de secuencia que garantizan el orden y la detección de pérdidas. Con HTTP/3 sobre QUIC, este paso se integra con TLS y se reduce a 0 o 1 RTT en conexiones repetidas.
Sobre la conexión TCP se negocia TLS 1.3: el cliente y servidor acuerdan cifrado (ECDHE), intercambian certificados y generan las claves de sesión. Con TLS 1.3 solo hace falta 1 RTT adicional. A partir de aquí toda la comunicación va cifrada —nadie entre medias puede leer el contenido de la petición.
El navegador envía GET / HTTP/2 con cabeceras comprimidas (HPACK). El servidor de Google responde con el HTML (código 200 OK). Si el servidor tiene HTTP/2 Server Push activado, puede enviar CSS y JS sin que el navegador los pida. El navegador comienza a parsear el HTML y hace nuevas peticiones DNS + TCP para los recursos externos.
El navegador construye el DOM, aplica CSS, ejecuta JS y pinta la página. La conexión TCP puede mantenerse abierta (Keep-Alive) para reutilizarla en futuras peticiones. Los recursos estáticos (imágenes, fuentes, scripts) se sirven desde la CDN más cercana, no desde los servidores de Google en EEUU.
En Chrome/Firefox, abre DevTools (F12) → pestaña Red. Verás cada petición con su tiempo de DNS, handshake TCP, TLS y transferencia. El diagrama de cascada revela cuellos de botella al instante. Filtra por tipo (XHR, Fetch, JS, CSS) para encontrar recursos lentos.
ping google.com mide la latencia RTT y detecta pérdida de paquetes.traceroute google.com (o tracert en Windows) muestra cada router intermedio y su latencia. Son las primeras herramientas para diagnosticar si el problema está en tu red local, en el ISP, o en el servidor destino.
dig meskeia.com A muestra el registro A (IPv4) y el TTL actual.dig meskeia.com MX muestra los servidores de correo.nslookup meskeia.com 8.8.8.8 consulta directamente al resolver de Google, útil para comparar si tu ISP tiene la caché desactualizada tras un cambio DNS.
Haz clic en el candado del navegador para ver el certificado: quién lo emite, cuándo caduca y qué dominios cubre. Un certificado caducado provoca error de conexión a todos los usuarios. Herramientas como ssllabs.com analizan la configuración TLS de tu servidor y detectan vulnerabilidades como TLS 1.0/1.1 o suites de cifrado débiles.
Herramientas como speedtest.net o fast.com miden el ancho de banda, pero también puedes usarping 1.1.1.1 (Cloudflare), ping 8.8.8.8 (Google) oping 9.9.9.9 (Quad9) para comparar latencias a distintos resolvers DNS públicos y elegir el más cercano para tu ubicación.
traceroute te muestra exactamente en qué salto aparece la latencia.