1.
Cliente (Front-End)
Representa el navegador web del usuario o una aplicación móvil que interactúa
con la aplicación web.
Tecnologías: HTML, CSS, JavaScript, React, Angular, etc.
2. Servidor Web
El servidor que gestiona las solicitudes de los clientes y entrega los recursos
estáticos o redirige las peticiones al servidor de aplicaciones.
Ejemplos: Nginx, Apache.
3. Servidor de Aplicaciones (Back-End)
Procesa la lógica de la aplicación web, ejecuta la lógica del negocio y maneja las
solicitudes.
Lenguajes o Tecnologías: Node.js, Python (Django, Flask), Java (Spring), Ruby
on Rails.
4. Base de Datos
Almacena los datos de la aplicación web.
Tipos:
o Relacional (SQL): MySQL, PostgreSQL.
o NoSQL: MongoDB, Cassandra.
5. Balanceador de Carga
Distribuye las solicitudes de los usuarios entre múltiples servidores de
aplicaciones para garantizar el rendimiento y la disponibilidad.
Ejemplo: HAProxy, AWS Elastic Load Balancer.
6. Servicios de Terceros (Opcional)
Servicios que pueden integrarse con la aplicación como:
o API de pago (Stripe, PayPal).
o Servicios de autenticación (OAuth, Auth0).
7. Firewall
Protege los servidores y la red de posibles amenazas externas.
1. Usuario introduce una URL en el navegador
Ejemplo: El usuario ingresa https://www.ejemplo.com.
Tecnología involucrada:
o Navegador web (Google Chrome, Firefox, Safari).
o Protocolo: HTTP o HTTPS (según si la URL es segura o no).
2. Resolución DNS (Domain Name System)
El navegador necesita convertir la URL en una dirección IP. Para esto, realiza una
solicitud DNS.
Proceso:
o El navegador consulta primero su caché local o caché del sistema
operativo para ver si ya tiene la dirección IP de ese dominio.
o Si no la encuentra, se envía una solicitud a un servidor DNS (protocolo
UDP en el puerto 53).
Resultado: El servidor DNS responde con la dirección IP correspondiente al
dominio (www.ejemplo.com → 192.168.1.1).
3. Establecimiento de Conexión TCP/IP
El navegador establece una conexión con el servidor web utilizando el protocolo
TCP (Transmission Control Protocol) en el puerto correspondiente:
o HTTP usa el puerto 80.
o HTTPS usa el puerto 443.
Proceso:
o Se realiza un handshake TCP de tres pasos:
1. El navegador envía un mensaje SYN (synchronize) al servidor.
2. El servidor responde con un SYN-ACK (synchronize-acknowledge).
3. El navegador envía un ACK (acknowledge) al servidor, completando
la conexión.
4. Negociación TLS (si es HTTPS)
Si se está usando HTTPS, ocurre un paso adicional para establecer una conexión
segura mediante el protocolo TLS (Transport Layer Security).
Proceso:
o El navegador y el servidor intercambian certificados y claves para cifrar la
comunicación.
o Esto garantiza que los datos enviados entre el navegador y el servidor
están protegidos.
5. Envío de la solicitud HTTP
Una vez establecida la conexión, el navegador envía una solicitud HTTP al
servidor.
Formato de la solicitud:
o Método: GET (solicitud de página), POST (envío de datos), entre otros.
o URL: www.ejemplo.com/index.html.
o Cabeceras: Información adicional como tipo de navegador, cookies, etc.
o Protocolo: HTTP/1.1 o HTTP/2.
Protocolo: HTTP o HTTPS.
6. Servidor Web recibe la solicitud
El servidor web (por ejemplo, Apache, Nginx o IIS) recibe la solicitud HTTP.
Tecnologías involucradas:
o Servidor Web: Procesa las solicitudes y entrega los archivos estáticos
(HTML, CSS, JS) o redirige las peticiones al servidor de aplicaciones.
o Lenguajes de backend (si se usa una aplicación dinámica): PHP,
Python, Node.js, Java, etc.
7. Interacción con el Servidor de Aplicaciones (si es necesario)
Si la página solicitada requiere lógica de negocio o datos dinámicos, el servidor
web pasa la solicitud al servidor de aplicaciones.
Proceso:
o El servidor de aplicaciones puede ejecutar código del lado del servidor
para generar contenido dinámico.
o Si es necesario, el servidor de aplicaciones interactúa con la base de
datos para recuperar información.
Protocolo entre el servidor web y la base de datos: SQL (para bases de
datos relacionales como MySQL o PostgreSQL) o consultas específicas para bases
de datos NoSQL como MongoDB.
8. El servidor genera una respuesta HTTP
El servidor (o servidor de aplicaciones) prepara una respuesta HTTP que incluye:
o Código de estado HTTP: 200 (OK), 404 (Not Found), 500 (Internal Server
Error), etc.
o Cabeceras: Tipo de contenido (Content-Type: text/html), caché, cookies,
etc.
o Cuerpo: El contenido de la página (HTML, JSON, etc.).
Protocolo: HTTP/1.1, HTTP/2 o HTTP/3 (si soporta QUIC, lo cual mejora la
latencia).
9. Transmisión de la respuesta al navegador
La respuesta se envía de vuelta al navegador a través de la conexión TCP
establecida.
Tecnologías:
o Si es HTTP/2 o HTTP/3, las respuestas pueden transmitirse de forma más
eficiente mediante multiplexación (envío simultáneo de múltiples recursos
en una única conexión).
10. Renderizado de la página en el navegador
El navegador procesa la respuesta y comienza a renderizar la página.
Proceso:
o HTML: El navegador interpreta el contenido HTML.
o CSS: El navegador aplica estilos CSS.
o JavaScript: Si el HTML contiene código JavaScript, este es ejecutado.
o Si hay recursos adicionales como imágenes, hojas de estilo CSS o archivos
JavaScript externos, el navegador realiza nuevas solicitudes HTTP para
obtener esos recursos.
Durante el renderizado, el navegador realiza múltiples tareas:
Parsers: Interpreta HTML, CSS y JS.
Rendering Engine: Convierte el código en una representación visual en
pantalla.
Motor de JavaScript: Ejecuta scripts, como en V8 (Chrome) o SpiderMonkey
(Firefox).
11. Interacción con el usuario y peticiones posteriores
Una vez que la página está cargada, el usuario puede interactuar con ella.
Cualquier interacción que requiera datos nuevos, como formularios o botones
que cargan más contenido, se manejará mediante nuevas solicitudes HTTP o
AJAX (para actualizar solo partes de la página sin recargar todo).
Resumen de Tecnologías y Protocolos:
DNS: Convierte el nombre de dominio en una dirección IP (protocolo UDP).
TCP/IP: Establece una conexión confiable entre cliente y servidor.
TLS (en HTTPS): Proporciona cifrado y seguridad en la conexión.
HTTP/HTTPS: Protocolo de comunicación entre el navegador y el servidor web.
Servidor Web: Apache, Nginx, etc.
Servidor de Aplicaciones: Node.js, Python (Django/Flask), Java (Spring), etc.
Base de Datos: MySQL, PostgreSQL, MongoDB.
Motor de Renderizado y JavaScript del Navegador: Interpreta el contenido
y scripts.
Este es el ciclo completo desde que un usuario realiza una solicitud hasta que recibe la
página renderizada en su navegador.
Voy a explicarte el proceso desde que un sistema hace una solicitud a una API REST o
API basada en HTTP hasta que recibe una respuesta.
1. El sistema cliente realiza una solicitud HTTP a la API
Cliente: Aquí el cliente es otro sistema (o microservicio), una aplicación móvil, o
cualquier otra aplicación que necesita consumir la API.
Ejemplo: El cliente envía una solicitud GET a
https://api.ejemplo.com/usuarios/123.
Protocolo: HTTP o HTTPS.
La solicitud HTTP incluye:
Método HTTP: GET, POST, PUT, DELETE, etc.
URL de la API: https://api.ejemplo.com/usuarios/123.
Cabeceras HTTP: Información adicional como tokens de autenticación (Bearer
Token o JWT), formato aceptado (por ejemplo, Accept: application/json), etc.
Cuerpo de la solicitud (en el caso de métodos POST o PUT): Aquí van los datos
que el cliente quiere enviar.
2. Resolución DNS
Similar a las solicitudes del navegador, el cliente primero debe obtener la
dirección IP del servidor de la API.
Esto implica una solicitud DNS para convertir el dominio (api.ejemplo.com) en
una dirección IP.
Protocolo DNS: UDP en el puerto 53.
3. Establecimiento de conexión TCP/IP
Después de obtener la IP del servidor, el cliente y el servidor de la API establecen
una conexión TCP.
Proceso de handshake TCP: Similar al navegador.
o El cliente envía un mensaje SYN.
o El servidor responde con SYN-ACK.
o El cliente responde con ACK.
Puertos:
o HTTP usa el puerto 80.
o HTTPS usa el puerto 443.
4. Establecimiento de conexión TLS (si es HTTPS)
Si la API usa HTTPS, se establece una conexión segura utilizando TLS (Transport
Layer Security).
El cliente y el servidor intercambian claves y certifican su identidad para
garantizar que los datos transmitidos estén encriptados y no puedan ser
interceptados.
5. Envío de la solicitud HTTP
Una vez establecida la conexión, el sistema cliente envía la solicitud HTTP a la
API.
Formato: La solicitud incluye el método HTTP (GET, POST, etc.), la URL, las
cabeceras HTTP y, si es necesario, el cuerpo con los datos en JSON o XML.
6. Servidor de la API recibe la solicitud
El servidor de la API (por ejemplo, un servidor con Node.js, Python con
Flask/Django, Java con Spring, etc.) recibe la solicitud HTTP.
Servidor Web o API Gateway: Podría estar usando un servidor web como
Nginx o Apache, o pasar por un API Gateway que se encarga de enrutar la
solicitud a un servicio específico (en sistemas de microservicios).
Autenticación: El servidor primero verifica si la solicitud tiene una cabecera de
autenticación válida. Esto podría incluir un Bearer Token o un JWT (JSON
Web Token).
o Si la autenticación es inválida, el servidor responde con un código de
estado 401 Unauthorized o 403 Forbidden.
7. Procesamiento de la solicitud en el backend
Una vez autenticado, el servidor de la API pasa la solicitud al servicio o
controlador correspondiente para procesarla.
Dependiendo del tipo de solicitud (GET, POST, PUT, DELETE), el backend hará
cosas como:
o Consultar la base de datos (para solicitudes GET).
o Crear o modificar recursos en la base de datos (para solicitudes POST o
PUT).
o Eliminar recursos (para solicitudes DELETE).
Base de Datos:
o El servidor podría interactuar con una base de datos relacional (como
MySQL, PostgreSQL) o una base de datos NoSQL (como MongoDB).
o El backend usa ORMs (Object-Relational Mappers) como Sequelize (para
Node.js) o SQLAlchemy (para Python) para facilitar la interacción con las
bases de datos.
8. El servidor genera una respuesta HTTP
Después de procesar la solicitud, el servidor prepara una respuesta HTTP para
enviarla de vuelta al cliente.
La respuesta incluye:
o Código de estado HTTP: Como 200 (OK), 201 (Created), 400 (Bad
Request), 404 (Not Found), 500 (Internal Server Error), entre otros.
o Cabeceras HTTP: Como Content-Type: application/json.
o Cuerpo de la respuesta: Los datos solicitados, generalmente en JSON o
XML (aunque JSON es el formato más común en APIs REST).
9. Envío de la respuesta al sistema cliente
La respuesta es enviada de vuelta al cliente a través de la conexión TCP que se
estableció al principio.
Si es HTTPS, la respuesta también estará cifrada usando TLS.
HTTP/2 o HTTP/3: Si se usa una de estas versiones del protocolo HTTP, la
respuesta puede aprovechar las optimizaciones de multiplexación, lo que
permite una comunicación más eficiente entre el cliente y el servidor.
10. Sistema cliente procesa la respuesta
El cliente (otro sistema, una aplicación móvil, etc.) recibe la respuesta y procesa
los datos.
Dependiendo de la implementación, puede hacer cosas como:
o Actualizar su base de datos local.
o Mostrar los datos en una interfaz gráfica.
o Realizar otra operación en función de la respuesta de la API.
11. Conexión opcionalmente cerrada o reutilizada
Dependiendo de la configuración, la conexión TCP puede cerrarse después de la
respuesta o mantenerse abierta para otras solicitudes, especialmente si se usa
HTTP/2 o HTTP/3, que permiten mantener la conexión abierta para múltiples
solicitudes/respuestas.
Resumen de Tecnologías y Protocolos involucrados:
1. DNS: Para resolver el dominio de la API en una dirección IP (protocolo UDP en el
puerto 53).
2. TCP/IP: Para establecer la conexión entre el cliente y el servidor de la API.
3. TLS (si es HTTPS): Para asegurar la comunicación mediante cifrado.
4. HTTP/HTTPS: Protocolo de comunicación utilizado entre el cliente y la API.
5. API REST:
o Métodos HTTP: GET, POST, PUT, DELETE.
o Formato de datos: Normalmente JSON.
6. Autenticación: Puede usar Bearer Tokens, JWT u otros métodos.
7. Backend: Servidor web (Nginx, Apache) o servidor de aplicaciones (Node.js,
Python, Java, etc.).
8. Base de Datos: Relacional (SQL) o NoSQL.
Voy a detallar el proceso cuando un sistema cliente hace una solicitud SOAP a un
servidor SOAP.
1. El sistema cliente realiza una solicitud SOAP
Cliente: Aquí el cliente puede ser otro sistema, una aplicación de software o
incluso un servicio web que quiere interactuar con la API SOAP.
Formato SOAP: SOAP es un protocolo basado en XML. El cliente envía una
solicitud SOAP que sigue un formato específico, llamado SOAP envelope (sobre
SOAP), que contiene el cuerpo de la solicitud.
Ejemplo de solicitud: La solicitud SOAP es un mensaje XML que incluye el
método de la operación y los parámetros que se envían al servidor.
En esta solicitud, se utiliza el método POST, pero a diferencia de REST, siempre se usa
POST en SOAP, ya que las solicitudes deben enviarse en el cuerpo del mensaje XML.
2. Resolución DNS
Similar al caso REST, el cliente debe resolver el dominio de la API
(api.ejemplo.com) para obtener la dirección IP del servidor mediante una
solicitud DNS (protocolo UDP en el puerto 53).
3. Establecimiento de conexión TCP/IP
El cliente y el servidor SOAP establecen una conexión TCP siguiendo el mismo
proceso de tres pasos que en REST:
o SYN, SYN-ACK, ACK.
Los puertos usados son los mismos: 80 para HTTP y 443 para HTTPS.
4. Establecimiento de conexión TLS (si es HTTPS)
Si la API SOAP usa HTTPS, se establece una conexión segura mediante TLS
(Transport Layer Security) para cifrar los datos intercambiados.
5. Envío de la solicitud SOAP
Una vez establecida la conexión, el cliente envía la solicitud SOAP en formato
XML dentro de un SOAP envelope.
SOAP requiere que el mensaje siga un formato rígido, que incluye:
o Envelope: Encapsula todo el mensaje.
o Header (opcional): Se utiliza para información adicional como seguridad,
autenticación, transacciones, etc.
o Body: Contiene la solicitud real, es decir, el método llamado (operación) y
los parámetros que se están enviando.
6. Servidor SOAP recibe la solicitud
El servidor de la API recibe el mensaje SOAP y lo procesa.
Servidor Web o SOAP Gateway: Como en REST, puede haber un servidor web
que enruta las solicitudes o un SOAP Gateway. También puede haber
autenticación usando estándares SOAP como WS-Security (para firmas y
cifrados en la capa de mensaje).
El servidor SOAP valida el envelope y el contenido XML.
o Si hay un problema con la estructura del mensaje SOAP o el envelope, el
servidor responde con un error SOAP estructurado.
o Errores SOAP: SOAP tiene un mecanismo estándar para reportar errores
a través de la sección Fault (falla), que puede incluir detalles sobre el tipo
de error.
7. Procesamiento de la solicitud en el backend
Una vez recibida la solicitud, el servidor procesa la operación especificada (en
este caso, ObtenerUsuario).
El backend, como en REST, podría interactuar con una base de datos (SQL,
NoSQL) para consultar la información solicitada.
SOAP no requiere un patrón de interacción en particular con la base de datos,
pero generalmente se usa con sistemas más estructurados y legados.
8. Servidor genera la respuesta SOAP
Después de procesar la solicitud, el servidor crea una respuesta SOAP en
formato XML y la encapsula dentro de otro SOAP envelope.
La respuesta incluye:
o Header: Similar al header de la solicitud (opcional).
o Body: Contiene los datos que el cliente solicitó o un mensaje de error si
hubo algún problema.
Si la operación fue exitosa, el cuerpo del mensaje incluirá el resultado de la
operación.
9. Envío de la respuesta al sistema cliente
La respuesta se envía al cliente a través de la misma conexión TCP que se
estableció inicialmente.
Si se usó HTTPS, los datos estarán cifrados con TLS.
10. Sistema cliente procesa la respuesta
El cliente recibe el SOAP envelope con la respuesta y extrae la información que
se encuentra en el cuerpo del mensaje.
El cliente procesa los datos, ya sea mostrando la información solicitada o
tomando decisiones según los resultados devueltos.
11. Conexión opcionalmente cerrada o reutilizada
Como en REST, la conexión puede cerrarse o reutilizarse dependiendo de la
configuración de la API y del cliente.