Abres una web y parece sencillo.
Escribes una dirección, pulsas Enter y aparece una pantalla.
Pero entre esas dos acciones pueden intervenir DNS, balanceadores, firewalls, servidores web, aplicaciones, cachés y bases de datos.
Entender ese recorrido te ayuda a diagnosticar problemas que el código por sí solo no explica.
Primero hay que encontrar el servidor
El navegador necesita convertir el nombre del dominio en una dirección IP.
Esa tarea la realiza DNS.
La respuesta puede apuntar directamente a un servidor o a un balanceador que distribuye las peticiones.
Si DNS está mal configurado, la aplicación puede funcionar perfectamente y seguir siendo inaccesible.
El balanceador decide dónde enviar la petición
Cuando existen varios servidores, un balanceador reparte el tráfico.
Puede utilizar estrategias como:
- Round robin: distribuye peticiones de forma rotativa.
- Menor número de conexiones: elige el servidor menos ocupado.
- Persistencia: mantiene al usuario en un mismo servidor.
- Peso: envía más tráfico a los servidores con mayor capacidad.
Además puede terminar HTTPS, comprobar la salud de los nodos y retirar temporalmente un servidor que no responde.
La DMZ separa zonas de confianza
Los componentes expuestos a Internet suelen situarse en una red intermedia o DMZ.
La idea es evitar que una petición externa llegue directamente a la red interna.
Los firewalls permiten únicamente las comunicaciones necesarias.
Por ejemplo, Internet puede llegar al balanceador, el balanceador al servidor web y el servidor de aplicaciones a la base de datos.
No todo debe hablar con todo.
Servidor web y servidor de aplicaciones
IIS y Apache pueden recibir peticiones HTTP, servir contenido estático y actuar como proxy hacia la aplicación.
En .NET, IIS puede alojar o reenviar peticiones al proceso de ASP.NET Core.
En otros entornos, Apache o Nginx pueden realizar una función similar.
La aplicación ejecuta la lógica: valida usuarios, procesa pedidos y decide qué datos necesita.
La base de datos
SQL Server, MySQL o MariaDB almacenan información estructurada.
La aplicación abre una conexión, ejecuta una consulta y transforma el resultado en una respuesta.
La base de datos no debería estar expuesta directamente a Internet.
Tampoco conviene que la aplicación utilice una cuenta con más permisos de los necesarios.
Una aplicación web no es una página. Es una conversación entre componentes.
En la nube
La infraestructura puede ejecutarse en máquinas virtuales, contenedores o servicios administrados.
IaaS ofrece máquinas y redes que tú administras. PaaS reduce esa carga y permite centrarse más en la aplicación.
La nube no elimina redes, permisos ni servidores.
Los abstrae y los convierte en servicios configurables.
La respuesta vuelve al navegador
La aplicación genera HTML o datos JSON.
La respuesta atraviesa de nuevo el servidor web y el balanceador.
El navegador interpreta el contenido, ejecuta JavaScript y realiza nuevas llamadas para cargar datos adicionales.
Cuando algo falla, identifica el tramo.
¿El nombre resuelve? ¿El balanceador responde? ¿El servidor web recibe? ¿La aplicación ejecuta? ¿La base de datos contesta?
Cuanto mejor entiendas el recorrido, menos dependerás de probar cosas al azar.
