1.ab.1 Modelos de Ejecución y Generación Dinámica

1.1 El modelo cliente-servidor

Las aplicaciones web funcionan normalmente mediante un modelo cliente-servidor. En este modelo, dos sistemas colaboran para atender las acciones del usuario:

• El cliente web es, habitualmente, el navegador. Solicita recursos al servidor, recibe las respuestas y presenta el resultado al usuario.
• El servidor web recibe las peticiones, localiza o genera los recursos solicitados y devuelve una respuesta.

El cliente y el servidor pueden encontrarse en el mismo equipo durante el desarrollo, pero representan responsabilidades distintas. En una aplicación publicada suelen ejecutarse en dispositivos diferentes y comunicarse mediante una red.

1.2 Recorrido de una petición web

Cuando un usuario escribe una dirección, pulsa un enlace o envía un formulario, se inicia un proceso de comunicación entre el navegador y el servidor. De forma simplificada, el recorrido es el siguiente:

1. El usuario realiza una acción en el navegador.
2. El navegador construye una petición HTTP.
3. La petición se envía al servidor indicado por la dirección web.
4. El servidor web analiza la petición y determina qué recurso u operación se ha solicitado.
5. Si es necesario, se ejecuta código de servidor y se consultan datos.
6. El servidor construye una respuesta HTTP.
7. El navegador recibe la respuesta, interpreta sus recursos y muestra el resultado.

Ejemplo: consulta del perfil de un alumno

Supongamos que un alumno accede a la dirección https://campus.example/perfil. El navegador solicita la página al servidor. El servidor identifica al usuario, consulta sus datos y genera una respuesta HTML personalizada.

Petición del navegador
GET /perfil HTTP/1.1
Host: campus.example
Cookie: sesion=abc123

Respuesta del servidor
HTTP/1.1 200 OK
Content-Type: text/html

<h1>Perfil de Ana</h1>
<p>Ciclo: Desarrollo de Aplicaciones Web</p>
				

La petición indica qué recurso se desea obtener y puede incluir información adicional, como datos de formulario, cabeceras o una cookie de sesión. La respuesta contiene un código de estado, cabeceras y, normalmente, un cuerpo con HTML, JSON, una imagen u otro recurso.

1.3 Ejemplo de diagrama cliente-servidor

El siguiente diagrama representa una petición que necesita ejecutar código y consultar una base de datos antes de devolver la respuesta:

┌──────────────────────┐
│       USUARIO        │
└──────────┬───────────┘
           │ Interacción
           ▼
┌──────────────────────┐        1. Petición HTTP        ┌──────────────────────┐
│ NAVEGADOR / CLIENTE  │ ─────────────────────────────► │    SERVIDOR WEB      │
│                      │                                │                      │
│ - Muestra la página  │    6. Respuesta HTTP           │ - Recibe la petición │
│ - Ejecuta HTML, CSS  │ 🞀────────────────────────────  │ - Busca el recurso   │
│   y JavaScript       │                                │ - Ejecuta o delega   │
└──────────────────────┘                                └───┬──────────────────┘
                                                            │               ▲ 
                                                            │ 2. Ejecuta    │5. Genera HTML, JSON...
                                                            ▼               │
                                                         ┌──────────────────┴───┐
                                                         │ CÓDIGO DE SERVIDOR   │
                                                         │ PHP, Java, Python... │
                                                         └──┬───────────────────┘
                                                            │               ▲ 
                                                            │ 3. Consulta   │4. Datos
                                                            ▼               │
                                                         ┌──────────────────┴───┐
                                                         │    BASE DE DATOS     │
                                                         └──────────────────────┘
					

La base de datos no suele comunicarse directamente con el navegador. El código de servidor actúa como intermediario: recibe la información solicitada, impone las reglas de la aplicación y genera la respuesta adecuada.

1.4 Modelos de ejecución de código

Una aplicación web puede ejecutar código en el cliente, en el servidor o en ambos. El lugar de ejecución determina qué recursos están disponibles, qué información puede protegerse y qué tareas puede realizar cada parte.

Ejecución en el cliente

El código se descarga y se ejecuta en el navegador del usuario. Se utiliza principalmente para presentar información, responder de forma inmediata a las acciones del usuario y modificar la interfaz sin recargar toda la página.

• Interpretación y representación de HTML.
• Aplicación de estilos CSS.
• Ejecución de JavaScript en el navegador.
• Validaciones preliminares de formularios.
• Actualización de elementos de la interfaz.

Ejecución en el servidor

El código se ejecuta en la infraestructura del servidor antes de enviar la respuesta al cliente. Se utiliza para acceder a datos protegidos, aplicar reglas de negocio, autenticar usuarios y generar contenido personalizado.

• Procesamiento de formularios.
• Autenticación y autorización.
• Acceso a bases de datos.
• Generación de HTML o JSON.
• Gestión de sesiones y permisos.

1.5 Clasificación de tecnologías según su ejecución

Una tecnología no debe clasificarse únicamente por su nombre, sino por el entorno en el que se está utilizando. JavaScript, por ejemplo, puede ejecutarse en el navegador o en un servidor mediante Node.js.

Ejemplo de colaboración entre tecnologías

Navegador: HTML + CSS + JavaScript
               ↓ petición HTTP
Servidor: Apache/Nginx + PHP
               ↓ consulta
Base de datos: SQL
               ↓ resultados
Servidor: genera HTML
               ↓ respuesta HTTP
Navegador: interpreta y muestra el HTML recibido
				

1.6 Páginas web estáticas

Una página estática se almacena en el servidor como un archivo ya preparado. Cuando el navegador la solicita, el servidor devuelve ese archivo sin tener que generar un contenido diferente para cada petición.

Ejemplo de página estática

<!DOCTYPE html>
<html lang="es">
<head>
    <meta charset="UTF-8">
    <title>Horario del centro</title>
</head>
<body>
    <h1>Horario de atención</h1>
    <p>De lunes a viernes, de 9:00 a 14:00.</p>
</body>
</html>
				

Todos los usuarios que soliciten ese archivo recibirán inicialmente el mismo contenido. Para cambiarlo, normalmente será necesario modificar el archivo almacenado en el servidor.

Usos frecuentes

• Documentación que cambia poco.
• Páginas informativas sencillas.
• Materiales descargables.
• Prototipos o sitios con contenido fijo.

1.7 Generación dinámica de páginas

Una página dinámica se construye durante el procesamiento de la petición. El servidor ejecuta un programa que puede utilizar datos de la petición, de la sesión, de una base de datos o de otros servicios.

Ejemplo de página dinámica con PHP

<?php
$nombre = $_GET['nombre'] ?? 'visitante';
$hora = date('H:i');
?>
<!DOCTYPE html>
<html lang="es">
<head>
    <meta charset="UTF-8">
    <title>Saludo dinámico</title>
</head>
<body>
    <h1>Hola, <?= htmlspecialchars($nombre) ?></h1>
    <p>La hora del servidor es <?= $hora ?>.</p>
</body>
</html>
				

Si se solicita saludo.php?nombre=Ana, PHP ejecuta el programa en el servidor y genera un documento HTML. El navegador no recibe las instrucciones PHP, sino el resultado:

<!DOCTYPE html>
<html lang="es">
<head>
    <meta charset="UTF-8">
    <title>Saludo dinámico</title>
</head>
<body>
    <h1>Hola, Ana</h1>
    <p>La hora del servidor es 10:35.</p>
</body>
</html>
				

1.8 Comparación entre páginas estáticas y dinámicas

¿Cuándo conviene cada opción?

Las páginas estáticas son adecuadas cuando el contenido cambia poco y no necesita personalización. La generación dinámica resulta apropiada cuando la respuesta depende del usuario, de información actualizada, de una búsqueda, de una operación o de datos almacenados.

Un sitio real puede combinar ambos modelos. Por ejemplo, puede servir de forma estática sus hojas de estilo e imágenes y generar dinámicamente el catálogo, el carrito y el perfil del usuario.

1.9 Modelos de ejecución en servidor

El modelo de ejecución define cómo y dónde se ejecuta el código del servidor web cuando llega una petición del cliente. A lo largo de la evolución del desarrollo web han aparecido distintos modelos, cada uno con sus ventajas e inconvenientes en rendimiento, aislamiento y escalabilidad.

CGI (Common Gateway Interface)

El modelo clásico y más antiguo. Por cada petición HTTP, el servidor web lanza un nuevo proceso que ejecuta el script (Perl, C, shell...), devuelve la salida y finaliza.

• Aislado e independiente del lenguaje de programación.
• Muy lento: sobrecoste de crear un proceso por petición.
• No hay persistencia de estado entre peticiones.

FastCGI

Evolución de CGI: el intérprete se queda corriendo como proceso persistente y el servidor web se comunica con él mediante un socket, enviando peticiones y recibiendo respuestas sin crear procesos nuevos por petición.

• Mucho más rápido que CGI.
• Configuración más compleja.
• Ejemplo: PHP-FPM.

Módulo del servidor web (in-process o embebido)

El intérprete se integra dentro del propio servidor web (Apache, IIS...), compartiendo su proceso.

• Ejemplos: mod_php (Apache), mod_wsgi (Python), mod_perl, ISAPI (IIS).
• Máximo rendimiento, sin comunicación externa.
• Si el módulo falla puede caerse todo el servidor.
• Mezcla en el mismo proceso el servicio de contenido estático y el código de aplicación.

Servlets y servidores de aplicaciones

El código se ejecuta dentro de un contenedor de aplicaciones que gestiona el ciclo de vida, hilos, sesiones y conexiones. Utiliza un modelo multi-hilo: un hilo por petición sobre un mismo proceso.

• Ejemplos: Tomcat, Jetty, JBoss/WildFly (Java), IIS con ASP.NET.
• Reutilización de recursos, estado persistente y soporte de transacciones.
• Consumo alto de memoria por hilo y escalado limitado por número de hilos.

Servidor de aplicación independiente con proxy inverso

El servidor web (Nginx, Apache) actúa de frontal y reenvía las peticiones dinámicas a un servidor de aplicación independiente que escucha en un puerto o socket (HTTP, uWSGI, gunicorn, Passenger...).

• Separación de responsabilidades y escalado independiente de cada capa.
• El frontal sirve contenido estático muy rápido.
• Añade una capa de comunicación, aunque el sobrecoste es pequeño.

Modelo asíncrono u orientado a eventos (event loop)

En lugar de un hilo o proceso por petición, un único hilo gestiona miles de conexiones mediante un bucle de eventos y operaciones de entrada/salida no bloqueantes.

• Ejemplo: Node.js.
• Excelente para aplicaciones con muchas conexiones simultáneas y uso intensivo de E/S, con poco consumo de memoria.
• Inadecuado para cálculo intensivo (CPU), ya que un solo hilo puede bloquearse.

Multiproceso pre-forked o workers

El servidor mantiene un conjunto fijo de procesos (workers) que atienden las peticiones por turnos, ya sea con procesos independientes (prefork) o con hilos dentro de cada proceso.

• Ejemplos: Apache prefork y worker/event, workers de uWSGI, Gunicorn.
• Permite controlar la concurrencia y ofrece aislamiento entre procesos.

Serverless o FaaS (Function as a Service)

No hay servidor propio: el código (funciones) se despliega en la nube y se ejecuta bajo demanda ante eventos HTTP; el proveedor escala automáticamente.

• Ejemplos: AWS Lambda, Azure Functions, Google Cloud Functions, funciones de Vercel y Netlify.
• Pago por uso, escalado automático y cero administración de servidores.
• Cold starts (latencia al arrancar funciones inactivas), límites de ejecución y dependencia del proveedor.

Código compilado, interpretado o JIT (transversal)

Independientemente del modelo anterior, el código puede interpretarse en cada petición (PHP clásico, Python), compilarse previamente a binario (C, C++, Go, Rust) con máximo rendimiento, o compilarse Just-In-Time a código máquina en caliente (JVM, .NET CLR, V8).

Ejemplo: evolución de PHP entre modelos

El caso de PHP ilustra la evolución de los modelos de ejecución:

1. CGI: un proceso php por petición, con gran sobrecoste.
2. mod_php (embebido): Apache se convierte en el servidor de aplicaciones, pero cada proceso Apache + PHP mantiene un intérprete completo en memoria aunque sirva solo contenido estático.
3. PHP-FPM (separado): Apache o Nginx quedan como servidor web puro y FPM actúa como servidor de aplicaciones, con un pool persistente de procesos PHP gestionado independientemente. Es el modelo dominante hoy por separar responsabilidades y mejorar el uso de memoria.