Web 101
Introducción
Toda aplicación que usamos desde un navegador —desde una red social hasta la banca en línea— descansa sobre dos capas de decisiones: cómo está organizado el software que la sirve (su arquitectura) y cómo viaja la información entre el navegador y el servidor (el protocolo de comunicación y su capa de seguridad). Este documento cubre ambos temas: primero las arquitecturas web más usadas actualmente, y después el trío HTTP/HTTPS/TLS que protege esas comunicaciones.
1. Arquitecturas web
1.1 ¿Qué es una arquitectura web?
Una arquitectura web es el diseño estructural que define cómo se organizan, comunican y distribuyen los distintos componentes de una aplicación (interfaz de usuario, lógica de negocio, bases de datos, servicios externos) para que funcione a través de Internet. No es solo “cómo se ve el código”, sino una decisión que determina qué tan fácil es escalar el sistema, cuánto cuesta operarlo y qué tan complicado es darle mantenimiento con el paso del tiempo.
1.2 Principales tipos de arquitectura
Arquitectura monolítica Toda la aplicación (interfaz, lógica y acceso a datos) se construye y se despliega como una sola unidad indivisible. Todos los módulos comparten el mismo proceso y los mismos recursos de cómputo (CPU, RAM), por lo que un cambio pequeño en el código obliga a reconstruir y volver a desplegar el sistema completo.
Arquitectura de microservicios En lugar de un solo bloque, la aplicación se divide en servicios pequeños e independientes, cada uno responsable de una función de negocio concreta (pagos, usuarios, catálogo, etc.), que se pueden desplegar, escalar y actualizar por separado.
Arquitectura serverless (sin servidor) Aquí no se piensa en “servicios” sino en funciones que se ejecutan bajo demanda en una infraestructura administrada por un proveedor en la nube (por ejemplo AWS Lambda). El equipo de desarrollo no aprovisiona ni mantiene servidores; solo paga por el tiempo de ejecución real. Es importante notar que microservicios y serverless resuelven problemas distintos: uno es un patrón de división de la aplicación y el otro es un modelo de ejecución del código, por lo que en la práctica pueden combinarse.
Arquitectura orientada a eventos (event-driven) Los componentes se comunican de forma asíncrona a través de eventos que pasan por un intermediario (broker), como Kafka o RabbitMQ, en lugar de llamarse directamente unos a otros. Esto desacopla los servicios entre sí y mejora la resiliencia del sistema ante fallos parciales.
Arquitectura en capas (cliente-servidor / N capas) Modelo clásico en el que la aplicación se separa en capas horizontales: presentación, lógica de negocio y datos. Es la base conceptual sobre la que luego se construyen tanto monolitos como microservicios.
1.3 ¿Cuáles son las más usadas hoy?
En la práctica actual conviven principalmente tres enfoques:
- Monolítica, que sigue siendo el estándar para proyectos nuevos (MVPs) y para la mayoría de aplicaciones pequeñas o medianas, gracias a su simplicidad para depurar y desplegar.
- Microservicios, adoptada por empresas con alto tráfico y equipos grandes que necesitan escalar partes específicas del sistema de forma independiente; Netflix es el caso de referencia de esta migración.
- Serverless, cada vez más común para cargas de trabajo variables, equipos pequeños o funciones puntuales activadas por eventos, ya que elimina la gestión de infraestructura.
La elección real casi nunca es “una u otra” de forma pura: muchas organizaciones combinan estos modelos en arquitecturas híbridas según las necesidades de cada componente.
1.4 Tabla comparativa
| Criterio | Monolítica | Microservicios | Serverless |
|---|---|---|---|
| Estructura | Un solo código base y un solo proceso desplegado como unidad | Varios servicios independientes, cada uno con su propia base de código y, normalmente, su propia base de datos | Funciones individuales ejecutadas bajo demanda, sin gestión directa de servidores |
| Ventajas | Simplicidad para desarrollar, depurar y desplegar; ideal para equipos pequeños y proyectos iniciales | Despliegue independiente por servicio; escalabilidad selectiva; equipos autónomos por dominio | Sin gestión de servidores; pago solo por uso real; escalado automático |
| Desventajas | Un cambio pequeño exige reconstruir y redesplegar todo; alto acoplamiento al crecer | Mayor complejidad operativa; requiere orquestar múltiples servicios y bases de datos; exige cultura DevOps madura | “Cold starts” (latencia al arrancar funciones inactivas); dependencia del proveedor (vendor lock-in) |
| Escalabilidad | Se escala la aplicación completa aunque solo una parte lo necesite | Se escala cada servicio de forma independiente según su demanda | Escalado automático y granular, gestionado por el proveedor cloud |
| Complejidad | Baja al inicio, crece rápidamente conforme el proyecto se hace grande | Alta desde el principio: red, comunicación entre servicios, consistencia de datos | Media: se delega infraestructura, pero se añade complejidad de integración entre funciones/eventos |
| Costos | Predecibles, infraestructura fija (servidores propios o instancias dedicadas) | Más altos en infraestructura y operación (contenedores, orquestador, monitoreo) | Variables, ligados al uso real; pueden ser muy bajos en tráfico intermitente y altos en tráfico constante |
| Casos de uso | MVPs, aplicaciones de negocio internas, proyectos con equipo pequeño | Plataformas de gran escala con múltiples dominios de negocio (streaming, e-commerce grande) | APIs con tráfico variable, procesamiento de eventos, automatizaciones puntuales |
2. HTTP y HTTPS
2.1 ¿Qué es HTTP y cómo participa en la comunicación cliente-servidor?
HTTP (Hypertext Transfer Protocol) es un protocolo de la capa de aplicación diseñado para transmitir documentos como HTML, y es la base de cualquier intercambio de datos en la Web. Sigue el modelo cliente-servidor: el cliente (normalmente el navegador) abre una conexión, envía una petición y espera una respuesta del servidor. Es un protocolo sin estado: el servidor no conserva por sí mismo información de peticiones anteriores del mismo cliente entre una petición y otra.
Una sesión HTTP típica ocurre en tres pasos: el cliente establece una conexión (habitualmente TCP), envía su petición y espera; el servidor procesa esa petición y responde con un código de estado (por ejemplo 200 para éxito, 301 para redirección o 404 cuando no encuentra el recurso) más los datos correspondientes. Desde HTTP/1.1 la conexión puede mantenerse abierta para varias peticiones seguidas, en vez de cerrarse después de cada una. Por defecto, un servidor HTTP escucha en el puerto 80.
Una página web completa casi nunca llega en un solo mensaje: se compone de varios sub-documentos (HTML, hojas de estilo CSS, imágenes, scripts) que el navegador solicita y ensambla.
2.2 ¿Qué es HTTPS?
HTTPS (HTTP Secure) es, en esencia, HTTP transmitido sobre una capa de cifrado (TLS o, históricamente, SSL). La estructura de peticiones y respuestas es la misma que en HTTP; lo que cambia es que, antes de que viaje cualquier dato, el cliente y el servidor negocian una conexión cifrada mediante un “saludo” o handshake que valida la identidad del servidor y establece claves de sesión. Por defecto, HTTPS usa el puerto 443.
2.3 Comparación HTTP vs. HTTPS
| Criterio | HTTP | HTTPS |
|---|---|---|
| Funcionamiento | Petición-respuesta en texto plano sobre TCP | Igual que HTTP, pero encapsulado dentro de una sesión TLS/SSL cifrada |
| Seguridad | Ninguna: los datos viajan legibles y son vulnerables a intercepción o manipulación | Cifrado de extremo a extremo entre cliente y servidor, con verificación de identidad del servidor mediante certificado |
| Puerto habitual | 80 | 443 |
| Cifrado | No aplica | Sí, mediante el protocolo TLS (o SSL en implementaciones muy antiguas) |
| Escenarios de uso | Contenido público sin datos sensibles (poco recomendado hoy en día incluso ahí) | Cualquier sitio actual, especialmente los que manejan contraseñas, pagos, datos personales o formularios de inicio de sesión |
En la práctica, los navegadores modernos marcan como “no seguro” a los sitios que solo usan HTTP, por lo que HTTPS se ha vuelto el estándar mínimo esperado en la Web, no una opción extra.
3. SSL y TLS
3.1 ¿Qué son y para qué sirven?
SSL (Secure Sockets Layer) fue el primer protocolo diseñado para cifrar comunicaciones en Internet. TLS (Transport Layer Security) es su sucesor directo: fue desarrollado por el IETF (Internet Engineering Task Force) para tener un estándar abierto y neutral, ya que SSL había nacido como un protocolo propietario de Netscape. La función de ambos es la misma: establecer un canal cifrado entre cliente y servidor mediante un handshake en el que se negocia qué versión del protocolo y qué conjunto de algoritmos criptográficos (cipher suite) van a usarse, y en el que el servidor demuestra su identidad usando un certificado y criptografía de clave pública.
3.2 Diferencias y relación con HTTPS
TLS 1.0 se lanzó en 1999 y estaba basado en SSL 3.0, pero deliberadamente no era compatible con él. Después llegaron TLS 1.1 (2006), TLS 1.2 (2008) y TLS 1.3 (2018), cada versión corrigiendo vulnerabilidades encontradas en la anterior. HTTPS es, literalmente, HTTP corriendo sobre una de estas dos capas de seguridad; por eso en la industria todavía se habla de “certificado SSL” de forma coloquial, aunque el protocolo que realmente cifra la conexión en cualquier sitio actual es TLS.
3.3 Por qué TLS es el estándar y SSL está obsoleto
SSL fue quedando fuera de uso por vulnerabilidades graves descubiertas con el tiempo (como POODLE), y ya en 2015 se consideraba oficialmente en desuso; hacia 2020 ningún navegador ni servidor moderno lo soportaba. Incluso TLS 1.0 y 1.1 fueron retirados por los principales navegadores y proveedores (Microsoft, Apple, Google, Mozilla, Cloudflare, Cisco) hacia marzo de 2020, después de que se identificaran ataques como los de degradación de protocolo (downgrade attacks) o Heartbleed. Hoy en día solo se consideran seguras y en uso activo TLS 1.2 y TLS 1.3; todo lo anterior se trata como un riesgo, no como una alternativa legítima.
Conclusión
La arquitectura de una aplicación web y el protocolo que protege su comunicación son decisiones independientes pero complementarias: una define cómo se organiza y escala el software, y la otra define si los datos que viajan entre cliente y servidor pueden ser leídos o alterados por terceros. En 2026, el estándar mínimo esperado es HTTPS sobre TLS 1.2/1.3, sin importar si la aplicación detrás está construida como monolito, microservicios o funciones serverless.
Referencias
- Comparación entre la arquitectura monolítica y la arquitectura de microservicios — Atlassian
- Arquitectura de microservicios sencilla en AWS — Amazon Web Services (AWS)
- Generalidades del protocolo HTTP — MDN Web Docs (Mozilla)
- Una típica sesión de HTTP — MDN Web Docs (Mozilla)
- ¿Qué es el TLS (Transport Layer Security)? — Cloudflare
- ¿Por qué utilizar TLS 1.3? — Cloudflare
- SSL vs TLS: What Are the Differences and Why Does It Matter? — Keyfactor