Módulo 2 - Arquitectura Web

Arquitectura Web
Módulo 2
Laura Villena
FUNDACIÓN SOCIEDADES DIGITALES
CURSO DESARROLLADOR WEB
CONTENIDO
Introducción al módulo 2 .......................................................................................... 1
Arquitectura web distribuida .................................................................................... 1
¿Qué es una arquitectura centralizada? .................................................................................................... 1
¿Qué es la arquitectura distribuida? .......................................................................................................... 1
¿Hasta dónde puedo modularizar o distribuir mi sistema? ...................................................................... 7
Proceso de una petición web Modelo OSI ................................................................ 14

Transferencia de datos ........................................................................................... 20
Conceptualización de las estructuras involucradas en la transferencia de datos entre computadoras
.................................................................................................................................................................... 20
¿Cuál es el objetivo de una red? .............................................................................................................. 22
¿Cómo podemos entender una red? ....................................................................................................... 23
HyperText Transfer Protocol (HTTP) ........................................................................ 29
Laura Villena
ARQUITECTURA WEB
Introducción al módulo 2
¡Hola, bienvenido al módulo 2!
En el módulo 2 nos vamos a introducir en los conceptos de Arquitectura web distribuida,

Proceso de una petición web, transferencia de datos y del HyperText Transfer Protocol
(HTTP).
¡Comencemos!
ARQUITECTURA WEB
Como ya mencionamos en el manual anterior la arquitectura web se refiere a la

estructura y el diseño general de una aplicación web, incluyendo cómo se organiza y
divide la funcionalidad, cómo se gestionan los datos, cómo se presenta la interfaz de
usuario y cómo se comunica con el servidor y otros sistemas.
¿Qué es una arquitectura centralizada?
Se presenta cuando todos los componentes de nuestra aplicación web con arquitectura
Cliente/Servidor están centralizados en un único equipo o servidor, lo que implica que
tanto el Back End, Front End, Bases de datos y APIs se encuentran alojados en el mismo
lugar. Esto conlleva a que, en caso de que dicho equipo falle, toda la aplicación se verá
afectada y experimentará un fallo generalizado.
¿Qué es la arquitectura distribuida?
Se considera una arquitectura distribuida cuando tenemos la capacidad de fragmentar

nuestro sistema en diferentes servidores ubicados en la red, ya sea en una red local o
en internet. Al hablar de arquitecturas, nos referimos a una estrategia para construir
Laura Villena 1

nuestro sistema según su tamaño y funcionalidades, con el propósito de pensar en cómo
escalaremos el sistema para soportar un mayor número de usuarios o transacciones.
Ahora bien, ¿cómo identificamos si una aplicación es distribuida? Aquí hay algunas
señales distintivas:
En este punto, la detección de una arquitectura distribuida puede depender del rol que
desempeñes en el proyecto o la aplicación. Aquí te compartimos dos enfoques:
• Como usuario: Si utilizas la aplicación, es posible que no te des cuenta de que el

sistema está distribuido, ya que funciona como un conjunto único y sincronizado
para el usuario final. Desde el punto de vista del usuario, la distribución de los
componentes es transparente.
• Como programador: Si estás involucrado en el desarrollo del proyecto, podrás

conocer si el sistema está distribuido a medida que trabajas en él y a través de
preguntas específicas. Aquí hay algunas formas en las que puedes entender que
te encuentras frente a una arquitectura distribuida:
1. Explicación del líder del proyecto: Al comenzar a trabajar en un proyecto, es

habitual que el líder del equipo proporcione una explicación sobre el tipo de
aplicación en la que están trabajando y dónde se ubicará tu parte del trabajo.
2. Asignación de roles: Al ingresar a una empresa, te especificarán si trabajarás

en el Front End, el Back End o en ambas áreas como Full Stack. De esta
manera, podrás inferir si la arquitectura es distribuida, aunque siempre es
mejor preguntar para estar seguros.
3. Diagramas de aplicación: En la documentación de un sistema, generalmente

se utilizan diagramas para representar la arquitectura. Observando el
diagrama, podrás identificar si el sistema está distribuido en uno o varios
servidores.
Laura Villena 2

A continuación, se presentan algunos diagramas o esquemas de una aplicación que fue
creada y planificada con una arquitectura distribuida, separando el código en Front End
y Back End. Estos diagramas muestran cómo la aplicación puede escalar y distribuirse en
distintos servidores y seguir funcionando de manera efectiva, en cualquier caso.
En este diagrama, observamos que la aplicación se encuentra dividida en Front End, Back
End y bases de datos, todos alojados en el mismo servidor. Es evidente que el diseño de
la aplicación fue realizado de manera modular y separada, con el propósito de facilitar
su distribución. Sin embargo, es importante destacar que, al estar todas las partes del
sistema en un mismo servidor, cualquier fallo en este último afectaría a todo el sistema
en su totalidad.
Laura Villena 3

En este diagrama, es evidente que se ha separado la base de datos del resto del sistema,
lo que ha permitido que el sistema continúe funcionando a pesar de esta separación.
Esto fue posible gracias a que el desarrollador Back End escribió el código teniendo en
cuenta una arquitectura distribuida.
Sin embargo, es importante mencionar que, aunque la base de datos está separada,
tanto la parte del Front End como el Back End siguen estando alojadas en un mismo
servidor. Esta configuración podría implicar que, si se presenta algún fallo o
inconveniente en el servidor, ambas partes del sistema podrían verse afectadas
simultáneamente. A pesar de la separación de la base de datos, aún existiría un punto
de vulnerabilidad en la dependencia del servidor común.
Laura Villena 4

En este diagrama, podemos observar que cada componente del sistema, es decir, Front
End, Back End y Base de datos, se encuentra alojado en servidores diferentes. Esta
configuración representa un claro ejemplo de un diseño con arquitectura distribuida en
los sistemas.
Este enfoque tiene varios beneficios significativos. En primer lugar, al tener cada parte
del sistema en servidores independientes, se reduce significativamente el riesgo de que
una falla en un servidor afecte a todo el sistema, ya que los componentes están aislados
y no comparten la misma infraestructura.
Además, la arquitectura distribuida mejora la escalabilidad, ya que es más fácil agregar

o quitar recursos según las necesidades del sistema, permitiendo un crecimiento flexible
y eficiente.
Laura Villena 5

Asimismo, esta distribución también favorece el rendimiento, ya que los servidores
pueden trabajar de manera concurrente, lo que agiliza el procesamiento de datos y
solicitudes.
En este último diagrama, podemos apreciar que cada componente del sistema se
encuentra alojado en la nube de diferentes empresas. A pesar de esta diversidad de
proveedores de servicios en la nube, el sistema continúa funcionando sin problemas,
gracias a su diseño modular y distribuido.
Este enfoque modular permite que las distintas partes del sistema operen de manera
independiente y se comuniquen entre sí a través de interfaces bien definidas. Al ubicar
cada componente en la nube de diferentes proveedores, se obtienen varios beneficios.
Laura Villena 6

En primer lugar, la redundancia inherente a la distribución en múltiples proveedores de
nube aumenta la resiliencia del sistema. Si uno de los proveedores experimentara una
interrupción o fallo, las demás partes del sistema pueden seguir funcionando sin
interrupciones.
Además, esta estrategia de distribución en la nube facilita la escalabilidad, ya que cada

componente puede adaptarse de forma independiente a las necesidades cambiantes
del sistema sin afectar a los demás. Esto permite un uso más eficiente de los recursos y
una mayor flexibilidad en el crecimiento del sistema.
Asimismo, el diseño distribuido en la nube mejora el rendimiento al permitir un

enrutamiento óptimo de las solicitudes y datos, ya que los usuarios pueden ser dirigidos
al servidor más cercano o con menor carga, mejorando la latencia y la velocidad de
respuesta.
¿Hasta dónde puedo modularizar o distribuir mi sistema?
El cómo distribuir el sistema es una decisión crítica que se aborda durante el diseño de
la aplicación, pero también es una consideración dinámica que puede cambiar a medida
que el sistema evoluciona. En muchos casos, cuando nos incorporamos a un proyecto,
las aplicaciones ya están en funcionamiento y requerirán de nuestro conocimiento para
su mantenimiento y mejora continua.
A medida que una aplicación crece en tamaño, complejidad y número de usuarios, la

modularización del sistema se vuelve aún más importante, ya que simplemente separar
en Front End, Back End y Base de datos puede no ser suficiente.
En esta situación, es esencial pensar en modularizar o separar ciertas funcionalidades

del sistema por diversos motivos:
• Alta demanda: Si una funcionalidad específica del sistema es compleja, consume

muchos recursos del servidor o es ampliamente demandada por diferentes
partes del sistema, es aconsejable modularizarla para gestionar eficientemente
su rendimiento y garantizar una respuesta óptima.
Laura Villena 7

• Interconexión: Cuando un sistema tiene funcionalidades que necesitan ser
accesibles para otros sistemas, modularizar es esencial para facilitar la
interacción y el consumo de datos o procesos entre ellos.
• Segregación de roles: En ocasiones, es necesario separar ciertas funcionalidades

debido a motivos de seguridad o aspectos técnicos. Por ejemplo, separar el
proceso de autenticación del sistema para reforzar la seguridad y proteger los
datos sensibles.
• Escalamiento: Si las proyecciones indican que la demanda del sistema

aumentará considerablemente en el futuro, la modularización permite escalar la
aplicación agregando más servidores con la misma funcionalidad, lo que
garantiza la capacidad para satisfacer la creciente demanda.
Existen diversas estrategias para fragmentar estas funcionalidades, que conocemos

como API REST o Microservicios.
Para ilustrar esto, consideremos un sistema con la siguiente estructura:
Front End:
El diseño se orienta hacia una arquitectura distribuida y comprende las siguientes
funcionalidades:
o Autenticación (Login): Se comunica con el Back End para verificar las

credenciales de usuario.
o Clientes: Se conecta con el Back End para realizar operaciones de consulta,
edición, creación y eliminación de clientes.
o Productos: Se comunica con el Back End para llevar a cabo operaciones de
consulta, edición, creación y eliminación de productos.
o Proveedores: Se conecta con el Back End para realizar operaciones de consulta,
edición, creación y eliminación de proveedores.
Laura Villena 8

Back End:
Ha sido diseñado considerando una arquitectura distribuida y engloba las siguientes
funcionalidades:
o Autenticación (Login): Recibe la solicitud, consulta la base de datos y verifica la

autenticidad del usuario.
o Clientes: Recibe la solicitud, accede a la base de datos y devuelve los datos
relativos a clientes.
o Productos: Recibe la solicitud, consulta la base de datos y proporciona los datos
correspondientes a productos.
o Proveedores: Recibe la solicitud, accede a la base de datos y retorna los datos
relativos a proveedores.
Ahora veamos en un diagrama o esquema cómo estas funcionalidades se pueden ir

distribuyendo en distintos servidores:
CASO 1
En este caso, el sistema se encuentra distribuido en tres servidores, con cada separación
presentando las siguientes características:
o Front End: Todas las funcionalidades relacionadas con el Front End están
agrupadas y se ejecutan en un solo servidor.
Laura Villena 9

o Back End: Todas las funcionalidades del Back End también están reunidas y
operan en un único servidor.
o Base de datos: Todos los datos del sistema son almacenados en una base de
datos que reside en el mismo servidor.
CASO 2
En este caso, podemos observar que cada parte del sistema se encuentra distribuida en
5 servidores diferentes, y el sistema continúa funcionando de manera exitosa debido a
que el desarrollador Back End diseñó el código con una arquitectura distribuida.
Detallaremos la distribución de las funcionalidades en los servidores:
agrupadas y se ejecutan en un solo servidor.
Laura Villena 10

o Back End - Funcionalidad de Login: La funcionalidad de login se encuentra en un
servidor exclusivo. Este servidor se encarga de manejar la autenticación y
validación de usuarios.
o Back End - Funcionalidades de Cliente y Proveedor: Estas funcionalidades están

ubicadas en un servidor dedicado. Aquí se gestionan las operaciones
relacionadas con clientes y proveedores.
o Back End - Funcionalidad de Producto: La funcionalidad de producto también se

encuentra en un servidor exclusivo. En este servidor se llevan a cabo todas las
operaciones referentes a productos.
o Base de Datos: Todos los datos del sistema se almacenan en una base de datos
que reside en el mismo servidor. Esta base de datos es utilizada por los distintos
servidores del Back End para almacenar y recuperar información necesaria para
el funcionamiento del sistema.
CASO 3
Laura Villena 11

En este caso, se puede observar que cada parte del sistema está distribuida en 5
servidores que se encuentran en diferentes nubes de distintos países. A pesar de esta
distribución geográfica, el sistema sigue funcionando de manera eficiente debido a que
el desarrollador Back End diseñó el código con una arquitectura distribuida.
Descripción de la distribución en las diferentes nubes:
agrupadas y se ejecutan en un solo servidor que se encuentra en la nube de
Argentina. Este servidor es responsable de manejar la presentación y la
interacción con los usuarios.
o Back End - Funcionalidad de Login: La funcionalidad de login se encuentra en un

servidor que está ubicado en la nube de España. Este servidor es el encargado
de gestionar la autenticación y validación de los usuarios.
o Back End - Funcionalidades de Cliente y Proveedor: Estas funcionalidades se

encuentran en un servidor que está alojado en la nube de Canadá. Aquí se
gestionan las operaciones relacionadas con clientes y proveedores.
o Back End - Funcionalidad de Producto: La funcionalidad de producto está en un

servidor que se encuentra en la nube de Nueva Zelanda. En este servidor se
llevan a cabo todas las operaciones referentes a productos.
o Base de Datos: Todos los datos del sistema se almacenan en una base de datos
que reside en un servidor propio. Esta base de datos es independiente de las
nubes y se encarga de gestionar y almacenar toda la información necesaria para
el funcionamiento del sistema.
Laura Villena 12

CASO 4
En este último caso, observamos que el sistema se encuentra alojado en una sola nube,
y a pesar de que todas las funcionalidades están reunidas en un mismo servidor de la
nube de Argentina, el sistema sigue funcionando correctamente.
Detallaremos la configuración del sistema en la misma nube:
o Front End: Todas las funcionalidades relacionadas con el Front End se

encuentran agrupadas y se ejecutan en un solo servidor ubicado en la nube de
Argentina. Este servidor se encarga de manejar la interfaz de usuario y la
interacción con los usuarios.
o Back End: Todas las funcionalidades del Back End también están reunidas en la
misma nube de Argentina. En este servidor, se lleva a cabo la ejecución de la
Laura Villena 13

lógica del negocio, el procesamiento de datos y la gestión de las solicitudes
recibidas desde el Front End.
o Base de datos: Todos los datos del sistema se almacenan en una base de datos
que reside en la misma nube de Argentina. Esta base de datos es utilizada por el
Back End para almacenar y recuperar información necesaria para el
funcionamiento del sistema.
Hemos podido observar que existen diversas formas de organizar, distribuir o dividir en
capas una aplicación junto con sus funcionalidades. En algunos casos, la separación
puede limitarse únicamente al Front End y Back End. Sin embargo, también hay otras
estrategias para fragmentar la aplicación en unidades más pequeñas, y lo logramos
mediante el uso de APIs REST.
PROCESO DE UNA PETICIÓN WEB MODELO OSI
Es importante entender los principios básicos de la arquitectura web y algunos de sus

elementos antes de profundizar en el Modelo OSI, también conocido como el Modelo
de Interconexión de Sistemas Abiertos (Open Systems Interconnection). Este modelo es
fundamental para la comunicación en las redes y sirve como base para el flujo de
información a través de internet global, internet local, internet celular, entre otros.
El Modelo OSI se compone de 7 capas, cada una con funciones específicas que
contribuyen al proceso de comunicación. Estas capas son:
Laura Villena 14

1. Capa física (Physical Layer): Es la capa más baja del modelo y se encarga de la
transmisión física de datos en el medio de transmisión, como cables, fibras
ópticas o medios inalámbricos. Esta capa define las características eléctricas,
mecánicas y funcionales de los dispositivos físicos, como los cables y tarjetas de
red.
2. Capa de enlace de datos (Data Link Layer): Esta capa se encarga de la

transmisión de datos entre nodos adyacentes en la red local. Su objetivo
principal es proporcionar un enlace fiable y sin errores entre dos dispositivos
directamente conectados, resolviendo problemas de detección y corrección de
errores.
3. Capa de red (Network Layer): La capa de red se ocupa del enrutamiento de

paquetes de datos a través de la red. Su función principal es determinar la ruta
más eficiente para que los datos lleguen desde el origen hasta el destino,
teniendo en cuenta factores como congestión de la red, prioridad de tráfico y
direccionamiento IP.
Laura Villena 15

4. Capa de transporte (Transport Layer): Esta capa es responsable de la
transferencia de datos extremo a extremo, asegurando que los datos se
entreguen correctamente y en el orden correcto. También maneja el control de
flujo y la corrección de errores.
5. Capa de sesión (Session Layer): La capa de sesión se encarga de establecer,

mantener y finalizar sesiones de comunicación entre dos aplicaciones en
diferentes dispositivos. Permite que las aplicaciones se comuniquen de manera
sincronizada y asegura que la comunicación se restablezca en caso de una
interrupción.
6. Capa de presentación (Presentation Layer): La capa de presentación se ocupa

de la sintaxis y semántica de la información transmitida. Se encarga de la
traducción, compresión y cifrado de los datos para que las aplicaciones puedan
interpretarlos correctamente.
7. Capa de aplicación (Application Layer): Es la capa superior del modelo OSI y

proporciona interfaces para que las aplicaciones de usuario accedan a los
servicios de red. Aquí es donde residen las aplicaciones como navegadores web,
clientes de correo electrónico, etc.
Proceso de una solicitud web:
1. Cliente Web: El cliente web solicita la resolución de nombres al servidor DNS, por
ejemplo, google.com.
2. Servidor DNS: El servidor DNS recibe y atiende la solicitud. Una vez recibida la
petición, realiza las consultas necesarias para resolver y obtener la dirección IP
correspondiente al servidor web.
3. Servidor DNS: A continuación, el servidor DNS devuelve al navegador web la

dirección IP que corresponde al Servidor Web solicitado.
Laura Villena 16

4. Cliente Web: El cliente web se conecta con el servidor web utilizando la dirección
IP y el puerto. Realiza la petición mediante una URL (Método GET) o un
formulario (Método POST). Esta solicitud incluye la dirección IP del servidor web,
el puerto del servidor web, la URL y los parámetros requeridos.
5. Servidor Web: El servidor web realiza el control de acceso, el análisis de la

petición y la localización del recurso solicitado. Si detecta que se accede a un
archivo o ruta de aplicación, traspasa el control al Contenedor de aplicaciones
Web.
6. Paso de la petición del servidor web al contenedor de aplicaciones web: La

petición es transmitida del servidor web al Contenedor de Aplicaciones Web para
continuar con el procesamiento.
7. El contenedor analiza la petición: El Contenedor de Aplicaciones Web analiza la

petición y, basándose en la ruta, traspasa el control a la aplicación web
correspondiente.
8. Paso del control de la petición desde el CAW a la aplicación: El control de la

petición se transfiere desde el Contenedor de Aplicaciones Web a la aplicación
específica.
9. La aplicación recibe la petición y decide qué hacer: La aplicación decide cómo

gestionar la petición, seleccionando la función adecuada según la ruta, el método
HTTP y los parámetros de entrada proporcionados en la URL. Una vez elegida la
función, la ejecuta.
10. La aplicación realiza una petición SQL a la base de datos: Para obtener o
modificar datos, la aplicación realiza una solicitud SQL a la base de datos.
11. La Base de Datos recibe la petición SQL y la procesa: La Base de Datos recibe la
solicitud SQL y la procesa, realizando los cambios necesarios si corresponde.
12. Una vez procesada la petición, devuelve los datos a la aplicación web: La Base de
Datos devuelve los datos solicitados a la aplicación web, generalmente un
conjunto de datos, como los 10 últimos clientes.
13. La aplicación web recibe estos datos y genera una salida: La aplicación web
recibe los datos de la Base de Datos y debe generar una salida, típicamente en
Laura Villena 17

formato HTML. Aquí, se estructura el contenido de los datos devueltos por la
Base de Datos en etiquetas HTML.
14. La aplicación web devuelve una respuesta al Contenedor de Aplicaciones Web:

La aplicación web responde a la petición enviando una respuesta al Contenedor
de Aplicaciones Web.
15. El contenedor procesa la respuesta, controlando la ejecución de la aplicación: El

Contenedor de Aplicaciones Web procesa la respuesta para controlar la
ejecución de la aplicación en caso de que ocurra algún fallo.
16. El Contenedor de Aplicaciones Web devuelve el fichero al servidor web: Tras

procesar la respuesta, el Contenedor de Aplicaciones Web devuelve el archivo al
servidor web.
17. El servidor Web devuelve los datos dentro de la respuesta HTTP al navegador
web: El servidor web incluye los datos dentro de la respuesta HTTP que será
enviada al navegador web.
18. Cliente Web: Presenta (renderiza) el contenido HTML resultante: Finalmente, el

cliente web recibe la respuesta HTTP del servidor web y presenta o renderiza el
contenido HTML resultante en el navegador web.
Laura Villena 18

BACK END
En síntesis, es evidente el enorme potencial presente y futuro de Internet, destacando

su escalabilidad y su capacidad para abarcar diversos mercados, incluyendo la cultura y
el arte, con total libertad.
Sin embargo, al expandirse los límites de la web, surgen nuevos desafíos que exigen
respuestas innovadoras. En la actualidad, las páginas web no se limitan a ser simples
sitios coloridos y dinámicos; han evolucionado hacia sistemas completos y distribuidos,
con compatibilidad multiplataforma y funcionalidades específicas. Un ejemplo de esto
es la plataforma de e-commerce.
Laura Villena 19

Arquitectura web de 3 niveles
TRANSFERENCIA DE DATOS
Conceptualización de las estructuras involucradas en la

transferencia de datos entre computadoras
Para comprender la programación web, es importante tener conocimientos o nociones

sobre las estructuras involucradas en la transferencia de datos entre computadoras. Esta
transferencia de datos, también conocida como comunicación entre computadoras, se
lleva a cabo a través de lo que se denomina una red de computadoras. La red más
conocida y utilizada es Internet, que es comúnmente referida como "la red de redes".
A continuación, exploraremos conceptos fundamentales relacionados con las redes de

computadoras y con Internet, de manera introductoria, para entender cómo funcionan
los elementos que las constituyen y cómo operan los sistemas que dan vida a la Web.
Estos conocimientos proporcionarán una base sólida para adentrarse en el mundo de la
programación web.
Laura Villena 20

Para comenzar, definiremos que una red de computadoras, también conocida como red
de ordenadores, red de comunicación de datos o red informática, es un conjunto de
equipos (nodos) y software que se conectan entre sí mediante dispositivos físicos, como
cables, o inalámbricos, como Wi-Fi. A través de estos medios, se envían y reciben
impulsos eléctricos, ondas electromagnéticas o cualquier otro medio para transportar
datos, con el propósito de compartir información, recursos y ofrecer servicios.
A continuación, se presenta un esquema que ilustra cómo diferentes redes se conectan,

como la red de un hogar con la de una empresa, y cómo el proveedor de Internet facilita
la transmisión y recepción de datos.
En la ilustración previa, se visualizan diferentes escenarios de redes interconectadas:
Red Doméstica: En esta red del hogar, se puede apreciar cómo el cable del proveedor
de Internet se conecta al módem Wi-Fi, permitiendo que los dispositivos o nodos se
conecten de manera inalámbrica. Los equipos que se conectan a esta red incluyen
Laura Villena 21

notebooks, cámaras, celulares e impresoras. Además, hay una conexión por cable desde
el módem hacia una computadora de escritorio, estableciendo una conexión dentro de
la misma red doméstica.
Red Empresarial (Primer y Segundo Edificio): En el ámbito empresarial, un cable entra

al módem principal desde el proveedor de Internet, posibilitando la conexión en red de
equipos como notebooks, computadoras de escritorio, impresoras y servidores en el
primer y segundo edificio. También se observa que desde el módem principal sale un
cable de red que se conecta a un módem Wi-Fi, facilitando la conexión inalámbrica para
algunos equipos.
Red del Proveedor de Internet: En la red del proveedor de Internet, se evidencia cómo
diversas empresas se conectan entre sí para formar una red en la que se transmiten y
reciben datos.
¿Cuál es el objetivo de una red?
El propósito fundamental de las redes en general es permitir el "compartir recursos"

entre computadoras, lo que implica que los programas, datos y equipos estén
disponibles para cualquier solicitud realizada por los equipos de la red, sin importar la
ubicación física o distancia entre ellos. En otras palabras, si una aplicación necesita
acceder a datos de otro equipo, puede hacerlo sin importar que se encuentren a una
gran distancia, incluso a 1000 km, y utilizar esos datos como si estuvieran disponibles
localmente.
La razón principal para crear una red de computadoras es:
Laura Villena 22

• Facilitar el intercambio de recursos e información a largas distancias, lo que
incluye compartir computadoras, impresoras, servidores, cámaras y otros
dispositivos.
• Garantizar la confiabilidad y disponibilidad de la información, aspectos

esenciales que definen lo que se considera información válida y segura.
• Aumentar la velocidad de transmisión de los datos y obtenerlos en milisegundos

para su uso, permitiendo una comunicación rápida y eficiente.
• Reducir los tiempos y costos en actividades como el procesamiento de

información, logrando una mayor eficiencia en el manejo de datos y recursos.
Aunque este no sea un curso específico sobre redes de computadoras, es importante

tener conocimiento sobre los elementos físicos que forman parte de los sistemas que
desarrollamos. Por ende, es útil tener una noción de lo que sucede en el "detrás de
escena".
¿Cómo podemos entender una red?
Para comprender una red, es fundamental entender dos categorías distintas de

comunicación: la capa física y la capa lógica.
La capa física engloba todos los elementos que un equipo utiliza para comunicarse con
otro dentro de la red, como tarjetas de red, cables y antenas. Si deseas profundizar en
este tema, puedes consultar autores como Tanenbaum, quien aborda las redes y el
modelo OSI (modelo de interconexión de sistemas, protocolos de comunicación, entre
otros).
Laura Villena 23

Por otro lado, la capa lógica se rige por normas más rudimentarias que, por sí solas,
pueden tener una utilidad limitada. Sin embargo, al utilizar estas normas, es posible
construir protocolos más complejos (de alto nivel) conocidos como "protocolos de
comunicación", que ofrecen servicios útiles y eficaces para la transmisión de datos en la
red.
Los protocolos son similares al concepto de idiomas utilizados por las personas. Cuando
dos personas hablan el mismo idioma y siguen ciertas reglas de comunicación (como
hablar y escucharse por turnos), pueden intercambiar ideas e información. De manera
similar, en el contexto de las redes, los protocolos son conjuntos de reglas y normas que
permiten a los dispositivos comunicarse entre sí de manera efectiva.
La formación de una red requiere la presencia de elementos de hardware, software y

protocolos. Los elementos físicos se dividen en dos categorías: los dispositivos de
usuario final, también conocidos como "hosts", que incluyen computadoras, impresoras,
escáneres y otros dispositivos que brindan servicios directamente al usuario; y los
dispositivos de red, que son aquellos que conectan los dispositivos de usuario final,
posibilitando su intercomunicación.
Internet, por su parte, es un conjunto descentralizado de redes de comunicación

interconectadas que utilizan la familia de protocolos TCP/IP. Esta familia de protocolos
garantiza que las redes físicas, que pueden ser heterogéneas, formen una red lógica
única de alcance mundial. Esto permite que las computadoras y dispositivos de todo el
mundo puedan comunicarse entre sí y acceder a información y servicios a través de esta
gran red global.
Uno de los servicios más exitosos en Internet es la World Wide Web, también conocida
como WWW o simplemente la web. La WWW es un conjunto de protocolos que facilita
la consulta remota de archivos de hipertexto y utiliza Internet como medio de
transmisión.
Es importante destacar que, además de la web, existen otros servicios y protocolos

utilizados en Internet. Por ejemplo, para el envío de correos electrónicos se emplea el
protocolo SMTP, y para la transmisión de archivos se utiliza el protocolo FTP, entre otros.
Laura Villena 24

La familia de protocolos que sustenta Internet permite la transmisión de datos entre
computadoras, siendo el conjunto de protocolos TCP/IP uno de los más fundamentales.
TCP/IP hace referencia a dos protocolos cruciales que componen Internet y que fueron
los primeros en definirse y ampliamente utilizados.
El protocolo TCP (Protocolo de Control de Transmisión) se emplea para establecer

conexiones entre computadoras, a través de las cuales se puede enviar un flujo de datos.
Una característica esencial de este protocolo es que garantiza que los datos sean
entregados en su destino sin errores y en el mismo orden en el que fueron transmitidos.
Esto se logra mediante una conexión orientada, donde cliente y servidor se anuncian y
aceptan la conexión antes de iniciar la transmisión de datos. Es decir, hay un intercambio
de mensajes para abrir una línea de conexión que permanece abierta durante toda la
comunicación.
Además, el Protocolo de Internet (IP) es una norma que tiene como objetivo principal el
direccionamiento de origen y destino en las comunicaciones para la transmisión de
datos mediante un enfoque no orientado a conexión. Este protocolo permite el envío
de paquetes conmutados a través de diversas redes previamente enlazadas, siguiendo
las pautas establecidas por el modelo OSI.
Laura Villena 25

Un aspecto relevante en el diseño del Protocolo de Internet (IP) es que se concibió
asumiendo que la entrega de los paquetes de datos sería no confiable, por lo tanto, se
enfocó en realizar el enrutamiento de la mejor manera posible mediante técnicas de
enrutamiento sin garantías de alcanzar el destino final. El objetivo era buscar la mejor
ruta entre las conocidas por la máquina que utiliza el protocolo IP.
Para comprender mejor la distinción entre los protocolos TCP e IP, sería necesario
analizar el modelo de capas OSI, pero en este curso no profundizaremos en ese aspecto.
Sin embargo, cabe mencionar que existe una jerarquía entre capas, y el protocolo IP se
encuentra en la capa de red, que está por encima de la capa de transporte, donde se
encuentra el protocolo TCP.
En resumen, la combinación de TCP e IP se utiliza para la comunicación en Internet,

donde TCP proporciona la fiabilidad en la comunicación, mientras que IP se encarga de
la comunicación entre distintas computadoras. Las cabeceras de IP contienen las
direcciones de destino de las máquinas de origen, conocidas como direcciones IP. Estas
direcciones son utilizadas por los routers para determinar la ruta de red por la cual se
enviarán los paquetes de datos.
Para comprender mejor el funcionamiento de Internet, es importante destacar que

dentro de esta red global existe un mecanismo que permite la conexión entre dos
computadoras. Este mecanismo es proporcionado por el Protocolo de Internet (IP), el
cual garantiza que un paquete de datos enviado desde una computadora llegue de
manera segura a la otra computadora a través del protocolo TCP, asegurando así la
entrega correcta.
Laura Villena 26

En este contexto, las direcciones IP juegan un papel fundamental. Una dirección IP es un
número que identifica de forma lógica y jerárquica una interfaz específica de un
dispositivo dentro de una red que utiliza el Protocolo de Internet. Todas las
computadoras presentes en Internet tienen una dirección IP única que les permite ser
identificadas y ubicadas en la red. En la imagen siguiente se muestra un esquema con
dos computadoras y sus respectivas direcciones IP.
Es gracias al trabajo conjunto de los protocolos de Internet, como el TCP e IP, y el uso de
direcciones IP que se logra una comunicación efectiva y segura entre diferentes
dispositivos conectados en la vasta red de redes que es Internet.
Es importante destacar que además del Protocolo de Internet (IP) y el Protocolo de

Control de Transmisión (TCP), existe otro sistema esencial para la comunicación en
Internet, conocido como el Sistema de Nombres de Dominio (DNS). El DNS se encarga
de asociar nombres comunes, como las direcciones de sitios web, con sus
correspondientes direcciones IP. Por ejemplo, la dirección www.cba.gov.ar tiene
asociado un número de IP específico, y gracias al DNS, podemos acceder a esa página
web utilizando su nombre en lugar de tener que recordar el número de IP.
El mecanismo del DNS simplifica la navegación en Internet, ya que nos permite acceder
a los sitios web a través de nombres más intuitivos y fáciles de recordar en lugar de
utilizar direcciones IP numéricas.
Con esta breve introducción, concluimos la explicación sobre la comunicación entre

computadoras en Internet. Aunque pueda parecer complejo, es de gran importancia
comprender estos mecanismos con los que trabajamos diariamente. Por ejemplo, al
Laura Villena 27

interactuar con una base de datos en Internet, si nos solicitan una dirección IP, ahora
sabemos a qué se refiere.
Además, es relevante destacar que la estructura de red se gestiona en capas, como

mencionamos anteriormente. Tenemos la capa de red, donde se encuentra el protocolo
IP, la capa de transporte superior, donde reside el protocolo TCP, y ahora mencionamos
una nueva capa, la capa de aplicación, donde se utiliza el protocolo HTTP para la
transferencia de información entre navegadores web y servidores. Al trabajar en estas
capas, nos abstraemos de la complejidad de los detalles de la comunicación subyacente,
permitiéndonos interactuar con cualquier computadora conectada a la red de forma
sencilla y eficiente.
Capa de aplicación:
Laura Villena 28

HYPERTEXT TRANSFER PROTOCOL (HTTP)
El Hypertext Transfer Protocol (HTTP) o Protocolo de Transferencia de Hipertexto en

español, es un protocolo de la capa de aplicación que se utiliza para la transmisión de
documentos hipermedia, como HTML, a través de Internet. Fue diseñado
específicamente para la comunicación entre navegadores web y servidores, pero
también puede ser empleado para otros propósitos.
HTTP define un conjunto de métodos de petición que indican la acción que se desea
realizar sobre un recurso específico. Estos métodos de solicitud, a veces denominados
verbos HTTP, pueden ser tanto sustantivos como verbos, según la acción que se quiera
llevar a cabo.
Un aspecto muy relevante de HTTP es que se trata de un protocolo sin estado, lo que
significa que no guarda información sobre conexiones anteriores. Cada solicitud que
realiza un cliente al servidor se procesa de manera independiente, sin tener en cuenta
solicitudes anteriores. En otras palabras, el servidor no mantiene un registro de estado
sobre las interacciones previas con un cliente. Las implicancias de esto serán exploradas
más adelante.
Una característica esencial del protocolo es su enfoque en transacciones y su adhesión

a un esquema de interacción de petición y respuesta entre un cliente y un servidor.
Cuando un cliente desea obtener información o realizar una acción en un recurso, envía
una solicitud al servidor mediante un mensaje con un formato específico. A su vez, el
servidor procesa la solicitud y responde al cliente enviándole un mensaje de respuesta
con los datos solicitados o la información relevante.
Para ponerlo de manera más concreta, un cliente puede ser representado por un
navegador web o cualquier otra aplicación que utilice el protocolo, mientras que el
servidor actúa como una aplicación alojada en un servidor web en Internet. Este
intercambio de mensajes de petición y respuesta es fundamental para la comunicación
efectiva entre clientes y servidores en la World Wide Web y facilita la carga de páginas,
el envío de datos y otras interacciones en el entorno en línea.
Laura Villena 29

Para comprender cómo se programa una aplicación web, es necesario entender, en
cierta medida, los mensajes HTTP. Estos mensajes se encuentran en formato de texto
plano, lo que los hace más legibles y fáciles de depurar. Los mensajes HTTP tienen una
estructura básica:
• Línea inicial: En las peticiones, esta línea comienza con el "método de petición",
que es una acción solicitada al servidor, seguido de la URL (Uniform Resource
Locator) del recurso y la versión de HTTP que el cliente admite. Lo esencial aquí
son el método de petición y la URL, que indican qué acción se está solicitando y
en qué recurso se llevará a cabo. En las respuestas, la línea inicial incluye la
versión de HTTP seguida de un "código de respuesta" y una "frase asociada", que
indica el resultado de la solicitud.
• Cabecera: Los mensajes HTTP también incluyen cabeceras, que son metadatos
con información diversa sobre la solicitud o la respuesta. Estos metadatos
pueden contener detalles como el tipo de contenido, las cookies, la codificación
de caracteres, etc.
• Cuerpo de mensaje: El cuerpo de mensaje es una parte opcional y típicamente

contiene los datos que se intercambian entre el cliente y el servidor. En el caso
de peticiones, el cuerpo puede contener información adicional enviada al
servidor, mientras que, en las respuestas, puede contener la información
solicitada o los resultados de una acción.
Existen varios métodos de petición, también conocidos como verbos, que indican la
acción que se desea realizar sobre un recurso identificado, y la interpretación de este
recurso dependerá de la aplicación del servidor.
En este caso, los métodos que vamos a utilizar son "GET" y "POST". Cabe destacar que
existen otras convenciones y estándares, como REST y las API's, que utilizan otros
métodos para diferentes propósitos.
Laura Villena 30

El método "GET" solicita una representación del recurso especificado. Las solicitudes
que utilizan este método están destinadas únicamente a recuperar datos y no deben
tener ningún otro efecto en el servidor.
Por otro lado, el método "POST" envía datos para que sean procesados por el recurso
identificado. Los datos enviados se incluyen en el cuerpo de la petición. Esto puede
resultar en la creación de un nuevo recurso o en la actualización de recursos existentes,
según la implementación específica del servidor.
Para concluir la explicación de HTTP, es importante mencionar algunos códigos de

respuesta que se utilizan para comunicar el resultado de las solicitudes entre el cliente
y el servidor:
1. El código de respuesta "200" indica una respuesta correcta, lo que significa que
la petición ha sido procesada exitosamente y se ha obtenido la información
solicitada de manera adecuada.
2. Por otro lado, el código de respuesta "404" representa errores causados por el
cliente, específicamente que el recurso solicitado no se ha encontrado en el
servidor. Esto puede ocurrir cuando se introduce una URL incorrecta o cuando el
recurso no existe.
3. Por último, los códigos de respuesta que comienzan con "5", como el "500",
indican errores causados por el servidor. Estos códigos reflejan que ha habido un
fallo en el proceso de la petición debido a un error interno en el servidor.
Es cierto que todo lo que hemos discutido sobre HTTP es fundamental para programar
una aplicación web. Al interactuar con una aplicación web, al hacer clic en un enlace, se
realizará una petición "GET" al servidor para obtener otra página. Si la página se
encuentra, se obtendrá una respuesta "200"; de lo contrario, se obtendrá un "404" si la
página no está disponible.
Laura Villena 31

Además, al llenar y enviar un formulario en una aplicación web, la información se enviará
al servidor a través de una petición "POST", lo que permitirá que los datos sean
procesados y utilizados según sea necesario.
Si bien existen otros protocolos en la familia de TCP / IP que son necesarios para
configuraciones de conexiones, a nivel de aplicación, como desarrolladores de
aplicaciones web, nos centraremos principalmente en el uso de HTTP para la interacción
cliente-servidor.
Es cierto que comprender los otros protocolos y niveles de TCP / IP puede ser útil para
solucionar problemas y realizar tareas más avanzadas, como conectarse a una base de
datos desde la aplicación web del servidor. Aunque no los utilicemos directamente en
nuestra programación de aplicaciones web, tener un conocimiento sólido de estos
protocolos nos permitirá entender mejor cómo funcionan las conexiones de red y cómo
abordar problemas complejos en el desarrollo de nuestras aplicaciones.
Laura Villena 32

Verbos y cómo se relacionan con operaciones
Laura Villena 33

FIN
Laura Villena

Módulo 2 - Arquitectura Web

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Módulo 2 - Arquitectura Web

Cargado por

Copyright:

Formatos disponibles

Arquitectura Web

Proceso de una petición web Modelo OSI ................................................................ 14

HyperText Transfer Protocol (HTTP) ........................................................................ 29

¡Hola, bienvenido al módulo 2!

En el módulo 2 nos vamos a introducir en los conceptos de Arquitectura web distribuida,

Como ya mencionamos en el manual anterior la arquitectura web se refiere a la

¿Qué es una arquitectura centralizada?

¿Qué es la arquitectura distribuida?

Se considera una arquitectura distribuida cuando tenemos la capacidad de fragmentar

FUNDACIÓN SOCIEDADES DIGITALES

• Como usuario: Si utilizas la aplicación, es posible que no te des cuenta de que el

• Como programador: Si estás involucrado en el desarrollo del proyecto, podrás

1. Explicación del líder del proyecto: Al comenzar a trabajar en un proyecto, es

2. Asignación de roles: Al ingresar a una empresa, te especificarán si trabajarás

3. Diagramas de aplicación: En la documentación de un sistema, generalmente

FUNDACIÓN SOCIEDADES DIGITALES

FUNDACIÓN SOCIEDADES DIGITALES

FUNDACIÓN SOCIEDADES DIGITALES

Además, la arquitectura distribuida mejora la escalabilidad, ya que es más fácil agregar

FUNDACIÓN SOCIEDADES DIGITALES

FUNDACIÓN SOCIEDADES DIGITALES

Además, esta estrategia de distribución en la nube facilita la escalabilidad, ya que cada

Asimismo, el diseño distribuido en la nube mejora el rendimiento al permitir un

¿Hasta dónde puedo modularizar o distribuir mi sistema?

A medida que una aplicación crece en tamaño, complejidad y número de usuarios, la

En esta situación, es esencial pensar en modularizar o separar ciertas funcionalidades

• Alta demanda: Si una funcionalidad específica del sistema es compleja, consume

FUNDACIÓN SOCIEDADES DIGITALES

• Segregación de roles: En ocasiones, es necesario separar ciertas funcionalidades

• Escalamiento: Si las proyecciones indican que la demanda del sistema

Existen diversas estrategias para fragmentar estas funcionalidades, que conocemos

Para ilustrar esto, consideremos un sistema con la siguiente estructura:

o Autenticación (Login): Se comunica con el Back End para verificar las

FUNDACIÓN SOCIEDADES DIGITALES

o Autenticación (Login): Recibe la solicitud, consulta la base de datos y verifica la

Ahora veamos en un diagrama o esquema cómo estas funcionalidades se pueden ir

FUNDACIÓN SOCIEDADES DIGITALES

Detallaremos la distribución de las funcionalidades en los servidores:

FUNDACIÓN SOCIEDADES DIGITALES

o Back End - Funcionalidades de Cliente y Proveedor: Estas funcionalidades están

o Back End - Funcionalidad de Producto: La funcionalidad de producto también se

FUNDACIÓN SOCIEDADES DIGITALES

Descripción de la distribución en las diferentes nubes:

o Back End - Funcionalidad de Login: La funcionalidad de login se encuentra en un

o Back End - Funcionalidades de Cliente y Proveedor: Estas funcionalidades se

o Back End - Funcionalidad de Producto: La funcionalidad de producto está en un

FUNDACIÓN SOCIEDADES DIGITALES

Detallaremos la configuración del sistema en la misma nube:

o Front End: Todas las funcionalidades relacionadas con el Front End se

FUNDACIÓN SOCIEDADES DIGITALES

PROCESO DE UNA PETICIÓN WEB MODELO OSI

Es importante entender los principios básicos de la arquitectura web y algunos de sus

FUNDACIÓN SOCIEDADES DIGITALES

2. Capa de enlace de datos (Data Link Layer): Esta capa se encarga de la

3. Capa de red (Network Layer): La capa de red se ocupa del enrutamiento de

FUNDACIÓN SOCIEDADES DIGITALES

5. Capa de sesión (Session Layer): La capa de sesión se encarga de establecer,

6. Capa de presentación (Presentation Layer): La capa de presentación se ocupa

7. Capa de aplicación (Application Layer): Es la capa superior del modelo OSI y

Proceso de una solicitud web:

3. Servidor DNS: A continuación, el servidor DNS devuelve al navegador web la

FUNDACIÓN SOCIEDADES DIGITALES

5. Servidor Web: El servidor web realiza el control de acceso, el análisis de la