Lección 2 — Arquitecturas de Red: Cliente-Servidor y Entre Pares

Las arquitecturas de red describen cómo se organizan las funciones y los recursos entre los participantes de una comunicación. Dos modelos fundamentales son cliente-servidor, donde unos participantes solicitan servicios y otros los proporcionan, y entre pares, donde los participantes pueden actuar como solicitantes y proveedores.

En la lección anterior analizaste los componentes y requisitos de una infraestructura. Ahora estudiarás cómo se distribuye el trabajo dentro de ella. Tener computadoras conectadas no determina, por sí solo, dónde se guardan los archivos, quién proporciona una aplicación o cómo se administra el acceso.

Comprender estas arquitecturas te permitirá interpretar servicios cotidianos y comparar distintas formas de compartir recursos. Aprenderás a identificar funciones, reconocer ventajas y limitaciones y justificar decisiones según las necesidades del entorno.

¿Qué significa arquitectura de red en esta lección?

La palabra arquitectura puede utilizarse para describir diferentes aspectos de un sistema. Aquí nos concentraremos en la organización de los participantes que solicitan y proporcionan servicios.

Para reconocer esa organización, pregunta:

• ¿Quién solicita el recurso?
• ¿Quién lo proporciona?
• ¿Dónde se guarda o procesa la información?
• ¿Quién controla el acceso?
• ¿De qué participantes depende el funcionamiento?

Estas preguntas son distintas de “¿cómo están conectados los cables?”.

Arquitectura y topología: conceptos diferentes

La topología describe la disposición de los nodos y enlaces de una red, desde una perspectiva física o lógica.

La arquitectura cliente-servidor o entre pares describe los roles y las relaciones de servicio entre los participantes.

Por ejemplo, varias computadoras conectadas a un switch pueden utilizar un servidor de archivos o compartir carpetas entre ellas. La conexión física puede conservarse mientras cambia la organización del servicio.

La forma de conectar los equipos no basta para identificar la arquitectura de una aplicación.

Arquitectura cliente-servidor

En la arquitectura cliente-servidor, el cliente solicita un servicio y el servidor atiende esa solicitud según sus funciones, configuración y permisos.

Un servicio puede consistir en entregar una página web, proporcionar un archivo, consultar información o procesar una operación.

¿Qué es un cliente?

Un cliente es el programa o participante que solicita un servicio.

Ejemplos:

• Un navegador que solicita una página.
• Una aplicación que consulta un sistema de inventario.
• Un equipo que solicita acceso a una carpeta compartida.
• Una aplicación de correo que se comunica con su servicio.

En el lenguaje cotidiano también llamamos “cliente” al dispositivo que ejecuta ese programa. Sin embargo, el rol depende de la comunicación que estamos analizando.

¿Qué es un servidor?

Un servidor es el programa o sistema que proporciona un servicio a otros participantes.

Puede ejecutarse en:

• Una computadora dedicada.
• Un equipo que también realiza otras tareas.
• Una máquina virtual.
• Infraestructura de un proveedor de servicios en la nube.

Un servidor no se define por tener un gabinete grande ni por estar instalado en un rack. Lo que lo identifica es la función de proporcionar el servicio.

Un mismo equipo puede ejecutar varios servicios, aunque compartir recursos también implica considerar capacidad, administración y disponibilidad.

Cómo funciona el modelo cliente-servidor

Imagina que una computadora administrativa necesita abrir un documento almacenado en un servidor de archivos.

La interacción puede explicarse de esta manera:

1. El usuario solicita abrir el documento.
2. El programa cliente se comunica con el servicio de archivos.
3. El servicio comprueba la identidad y los permisos cuando corresponde.
4. El servidor atiende la solicitud o la rechaza.
5. El cliente presenta el resultado al usuario.

Esta secuencia es una simplificación pedagógica. Los detalles dependen del servicio y del protocolo utilizado.

Que exista conectividad no garantiza autorización. Una computadora puede comunicarse con un servidor y recibir una denegación porque su usuario no tiene permiso para abrir el recurso.

Ejemplo en una pequeña empresa

La empresa del caso práctico utiliza un sistema de inventario en internet.

Las computadoras de operación ejecutan la aplicación cliente o utilizan un navegador. El servicio remoto recibe las solicitudes y proporciona las funciones del sistema.

Aunque el servidor esté fuera de las instalaciones, la relación continúa siendo cliente-servidor.

Además, distintos servicios pueden tener proveedores diferentes: el inventario puede estar en la nube y los archivos compartidos en un servidor local.

Ventajas y límites de cliente-servidor

La concentración de un servicio facilita establecer un punto definido de administración. Sin embargo, sus beneficios dependen del diseño y del trabajo operativo.

Administración y control

Un servicio centralizado puede facilitar:

• Administrar permisos sobre sus recursos.
• Mantener una ubicación de referencia para los archivos.
• Aplicar respaldos del servicio.
• Registrar accesos y operaciones.
• Actualizar componentes bajo una administración definida.

Esto no significa que cualquier sistema cliente-servidor incluya automáticamente una administración centralizada de todos los usuarios y dispositivos.

Las capacidades deben comprobarse en la solución concreta.

Dependencias y disponibilidad

Si un servicio depende de un único servidor y este deja de funcionar, los clientes pueden perder acceso aunque sus computadoras y la red local continúen operativas.

También puede interrumpirse el acceso por problemas de conectividad, autenticación o capacidad.

La arquitectura cliente-servidor no exige un único servidor físico. Una solución puede distribuir funciones o incorporar redundancia para reducir interrupciones, con mayor complejidad y costo.

Recursos y mantenimiento

El servicio necesita recursos de procesamiento, memoria, almacenamiento y comunicación adecuados a su carga.

También requiere administración: actualizaciones, respaldos, supervisión y recuperación.

Utilizar un servicio en la nube cambia quién administra parte de la infraestructura, pero no elimina todas las responsabilidades de la organización.

Arquitectura entre pares

En una arquitectura entre pares, también llamada peer-to-peer o P2P, los participantes pueden proporcionar y solicitar recursos.

No existe necesariamente un servidor dedicado que atienda todas las operaciones del servicio. Los pares colaboran de acuerdo con las reglas de la aplicación.

Esto no significa que todos deban tener idénticas capacidades, permisos o recursos.

Ejemplo de intercambio entre computadoras

Supongamos que dos personas comparten recursos directamente:

• La computadora A ofrece una carpeta que consulta B.
• La computadora B ofrece otra carpeta que consulta A.

A y B pueden actuar como proveedores y solicitantes, según el intercambio.

En una organización sencilla de este tipo, cada computadora puede administrar sus propios recursos compartidos y permisos.

En cada acceso individual siguen existiendo una solicitud y un participante que la atiende. La característica entre pares se aprecia en la organización general: los equipos pueden asumir ambos roles.

Ejemplo de distribución colaborativa

Una aplicación puede permitir que un archivo se obtenga por partes desde varios participantes, mientras cada uno comparte partes que ya tiene.

Este ejemplo ayuda a comprender que el trabajo puede distribuirse entre pares.

Algunas aplicaciones P2P utilizan servicios centrales para descubrir participantes, coordinar conexiones o autenticar usuarios. Por ello, entre pares no significa necesariamente ausencia total de componentes centrales.

Ventajas y límites de las redes entre pares

La organización entre pares puede resultar útil cuando se necesita un intercambio distribuido o una solución sencilla para pocos participantes.

Distribución de recursos

Según la aplicación, puede permitir:

• Aprovechar recursos de varios participantes.
• Compartir información sin un servidor dedicado para ese intercambio.
• Distribuir parte del trabajo o de la transferencia.
• Establecer colaboración directa entre equipos.

Estos beneficios no garantizan un menor costo total. La administración, el soporte y la protección también consumen tiempo y recursos.

Administración de permisos y respaldos

Cuando cada computadora administra sus carpetas y usuarios, mantener criterios consistentes puede volverse difícil.

Pueden aparecer:

• Permisos diferentes entre equipos.
• Copias de un documento cuya versión de referencia no está clara.
• Recursos que dejan de estar disponibles cuando su propietario apaga el equipo.
• Respaldos incompletos.
• Dependencia de configuraciones que solo conoce una persona.

Estos problemas no son inevitables en toda aplicación P2P. Son riesgos que deben analizarse según la forma concreta de compartir y administrar los recursos.

Disponibilidad variable

Si un archivo solo está disponible en una computadora y esta se apaga, el recurso deja de estar accesible.

En cambio, una aplicación que mantiene copias entre varios pares puede conservar disponibilidad aunque alguno se desconecte.

La disponibilidad depende de dónde existen los recursos, cómo se distribuyen y qué participantes siguen funcionando.

Comparación de arquitecturas de red

Ningún modelo garantiza por sí mismo seguridad, rapidez o disponibilidad.

La elección debe relacionarse con los requisitos: usuarios, recursos, control, continuidad, crecimiento y capacidad de administración.

¿Pueden coexistir ambas arquitecturas?

Sí. Una misma infraestructura puede utilizar cliente-servidor para determinados servicios e intercambio entre pares para otros.

Por ejemplo:

• El sistema de inventario funciona mediante un servicio central.
• Las computadoras consultan servicios de nombres y configuración.
• Dos equipos realizan un intercambio directo autorizado.
• Una aplicación distribuye contenido entre participantes.

Por eso, suele ser más preciso preguntar “¿qué arquitectura utiliza este servicio?” que asignar una sola arquitectura a toda la red.

Un equipo puede asumir varios roles

Una computadora puede actuar como cliente de una aplicación y, al mismo tiempo, proporcionar una carpeta compartida.

Un servidor de una aplicación también puede actuar como cliente al consultar otro servicio.

Cliente y servidor son roles; no son categorías permanentes y excluyentes de los equipos.

Entre pares y punto a punto: una diferencia importante

La expresión punto a punto puede describir un enlace entre dos extremos, como una conexión entre dos edificios.

Ese enlace no determina si la aplicación utiliza cliente-servidor o entre pares.

En algunos materiales se utiliza “punto a punto” para referirse a P2P. Para evitar confusiones, en esta especialización utilizaremos:

• Entre pares o P2P: organización de participantes que pueden solicitar y proporcionar recursos.
• Enlace punto a punto: conexión entre dos extremos.

Siempre debes interpretar el término según el contexto.

Aplicación al caso de la pequeña empresa

Retomemos las necesidades identificadas en la lección 1.

La empresa utiliza un sistema de inventario en internet y necesita compartir documentos administrativos e imprimir desde equipos autorizados.

Sistema de inventario

Su funcionamiento corresponde a una relación cliente-servidor: las computadoras solicitan operaciones al servicio remoto.

Debemos identificar sus dependencias, como acceso a internet, resolución de nombres y autenticación.

Documentos administrativos

Podrían compartirse desde computadoras individuales o mediante un servicio de archivos definido.

Antes de decidir, necesitamos conocer:

• Quién debe acceder a cada documento.
• Cuál será la ubicación de referencia.
• Qué disponibilidad se necesita.
• Quién administrará los permisos.
• Cómo se realizarán los respaldos.
• Qué ocurrirá cuando un equipo falle o su usuario esté ausente.

La cantidad de computadoras, por sí sola, no responde estas preguntas.

Impresión

Una computadora puede enviar trabajos directamente al servicio de una impresora de red.

También podría enviarlos a un servidor de impresión que los gestione antes de entregarlos a la impresora.

Ambos ejemplos incluyen relaciones cliente-servidor, aunque cambien los participantes y las dependencias.

Una impresora no necesita un servidor de impresión separado para proporcionar un servicio de impresión en red.

Actividad práctica: identifica roles y dependencias

Propósito: reconocer la arquitectura de varios servicios y justificar tu interpretación.

Utiliza el caso ficticio o un entorno donde tengas autorización para observar. No necesitas cambiar configuraciones.

Instrucciones

1. Selecciona tres servicios o intercambios.
2. Identifica quién solicita y quién proporciona cada recurso.
3. Indica si un participante puede asumir ambos roles.
4. Clasifica la organización como cliente-servidor, entre pares o combinación, según las evidencias.
5. Explica qué ocurriría si se desconecta un participante.
6. Anota la información que necesitarías para confirmar tu análisis.

Ejemplo de entrega

Criterio de revisión: tu explicación debe identificar roles y dependencias. No basta con escribir el nombre de una arquitectura.

Ejercicios de aplicación

¿Una computadora de escritorio puede ser servidor?

Una computadora comparte una carpeta con otros equipos, aunque también se utiliza para trabajo administrativo.

Respuesta orientativa: sí. El servicio de archivos que ejecuta proporciona recursos a clientes. Que pueda desempeñar esa función no demuestra que tenga la capacidad o disponibilidad adecuada para cualquier necesidad.

¿Un switch identifica la arquitectura?

Todas las computadoras están conectadas a un mismo switch. ¿Eso demuestra que trabajan entre pares?

Respuesta orientativa: no. El switch describe parte de la infraestructura de conexión. Debes analizar quién solicita y proporciona cada servicio.

¿Qué sucede cuando un proveedor deja de funcionar?

La computadora A contiene la única copia de una carpeta compartida y está apagada. B necesita abrir uno de sus archivos.

Respuesta orientativa: B no podrá obtenerlo desde A mientras esta permanezca fuera de servicio. El resultado depende de la disponibilidad del recurso y de la existencia de otras copias accesibles.

¿Un componente central descarta P2P?

Una aplicación utiliza un servicio central para localizar participantes y después intercambia datos directamente entre ellos.

Respuesta orientativa: no necesariamente. Puede combinar coordinación central con intercambio entre pares. Es necesario identificar qué función realiza cada componente.

Lo que has aprendido

En esta lección aprendiste a:

• Distinguir arquitectura de servicio y topología de conexión.
• Identificar las funciones de cliente y servidor.
• Explicar cómo se organiza un intercambio entre pares.
• Reconocer que un equipo puede asumir varios roles.
• Comparar administración, disponibilidad y dependencias.
• Diferenciar una arquitectura P2P de un enlace punto a punto.
• Analizar servicios concretos sin asignar una única arquitectura a toda la infraestructura.

Conclusión

Las arquitecturas de red ayudan a comprender quién proporciona los recursos, quién los utiliza y de qué depende cada servicio.

El modelo cliente-servidor establece proveedores definidos para atender solicitudes. La organización entre pares permite que los participantes soliciten y proporcionen recursos. Ambos pueden coexistir y requieren decisiones de administración, seguridad y disponibilidad.

Antes de elegir una arquitectura, identifica los requisitos del servicio y las consecuencias de sus dependencias. Esa relación entre necesidades y funcionamiento te permitirá tomar decisiones mejor fundamentadas.

Lección anterior　　 Índice del programa　　 Siguiente lección