Comunicaciones cliente‑servidor: concurrencia, protocolos y seguridad en redes

Preguntas de la UT4

1. Explica en qué consiste una aplicación cliente‑servidor, qué responsabilidades típicas tiene cada parte y pon un ejemplo real (tipo de aplicación y qué intercambian).

Un modelo cliente‑servidor es una arquitectura en la que las tareas se reparten entre proveedores de recursos (servidores) y demandantes de servicios (clientes). El servidor espera pasivamente peticiones, las procesa y envía una respuesta, mientras que el cliente inicia la comunicación. El servidor suele encargarse de la persistencia, la lógica de negocio y la seguridad; el cliente maneja la interfaz de usuario y la experiencia del usuario.

Roles y flujo típico:

• Cliente: inicia la petición, presenta la información al usuario y valida entradas localmente.
• Servidor: recibe la petición, procesa la lógica, accede a datos persistentes y responde.
• Comunicación: modelo petición–respuesta (request–response).

Ejemplo: En una API REST de una tienda online, el teléfono móvil (cliente) envía GET /productos y el servidor responde con un JSON que contiene el listado de productos y el stock actual.

2. Describe cómo se implementa un servidor concurrente usando hilos (por ejemplo, "un hilo por cliente" o "pool de hilos") y compara ventajas e inconvenientes.

Un servidor concurrente atiende a múltiples usuarios a la vez. Dos modelos habituales son:

• Hilo por cliente: el servidor crea un hilo nuevo para cada conexión. Es sencillo de implementar y de razonar, pero poco escalable en entornos con muchos clientes, porque el consumo de memoria y el coste de conmutación de contexto aumentan linealmente con el número de hilos.
• Pool de hilos: se mantiene un conjunto fijo o adaptable de hilos reutilizables que atienden las peticiones. Ofrece mejor control de recursos, reduce la sobrecarga de crear/destruir hilos y permite limitar el uso de memoria y CPU. Requiere gestionar una cola de peticiones y políticas de rechazo o backpressure si el pool se llena.

Comparación en términos de escalabilidad, consumo y control de concurrencia:

• Escalabilidad: el pool de hilos suele escalar mejor que el hilo por cliente.
• Consumo de recursos: el modelo hilo por cliente puede agotar RAM y recursos del SO; el pool limita ese consumo.
• Control de concurrencia: el pool permite aplicar límites y estrategias (colas, prioridades), mientras que el hilo por cliente ofrece menos control.

3. Explica qué aspectos se suelen depurar en una aplicación en red (cliente‑servidor) y qué técnicas aplicarías para encontrar fallos de conexión, bloqueos o errores de protocolo.

Se suelen depurar fallos de conectividad (timeouts), errores de protocolo (mensajes mal formados) y bloqueos (deadlocks). Las técnicas incluyen:

• Uso de logs detallados en cliente y servidor, con niveles (INFO, DEBUG, ERROR) y trazas de las peticiones y respuestas.
• Seguimiento de trazas de red (p. ej., tcpdump, Wireshark) para inspeccionar paquetes y detectar problemas de formato o secuencia.
• Control riguroso de excepciones para evitar que errores no controlados derriben el servidor.
• Pruebas con clientes simulados y herramientas de estrés para forzar condiciones anómalas (datos inesperados, desconexiones, cargas altas).

4. ¿Qué significa monitorizar tiempos de respuesta en una aplicación cliente‑servidor?

Monitorizar tiempos de respuesta consiste en medir el rendimiento del servicio para garantizar una buena experiencia de usuario. Las métricas clave y su uso:

• Latencia: tiempo que tarda una petición en ser atendida.
• Throughput: número de peticiones procesadas por segundo.
• Tiempo medio y percentiles (p. ej., p95, p99): para detectar casos lentos aislados.
• Uso de recursos: CPU, memoria, I/O, conexiones abiertas.

Con estos datos se identifican cuellos de botella y se toman decisiones como optimizar código, mejorar consultas a la base de datos o escalar horizontalmente añadiendo más servidores.

5. Explica un diseño básico de protocolo de comunicación (formato de mensajes) para una app cliente‑servidor y qué comprobaciones incluirías para evitar errores.

Un protocolo básico debe definir un formato de mensaje claro, usando cabeceras (para indicar tipo de operación, longitud, versión) y delimitadores o estructuras bien definidas (JSON, XML o binario). Para evitar errores se deben incluir:

• Códigos de estado: indicar éxito, error de cliente o error de servidor.
• Números de versión: para manejar compatibilidad hacia atrás y adelante.
• Validaciones: sumas de comprobación, firmas o checksums para detectar corrupción.
• Validación de formato: rechazar mensajes mal formados antes de procesarlos.

Preguntas de la UT5

6. Explica qué se entiende por servicio en red y en qué se diferencia de una simple aplicación cliente‑servidor “ad hoc”.

Un servicio en red es una funcionalidad estable y permanente diseñada sobre protocolos estándar (por ejemplo, HTTP o IMAP), pensada para ser reutilizable por múltiples clientes heterogéneos. A diferencia de una aplicación "ad hoc", que suele ser una solución cerrada y específica con un protocolo propio, un servicio en red está pensado para ser escalable, altamente disponible e interoperable entre diferentes sistemas y plataformas sin necesidad de reprogramar el núcleo de la comunicación.

7. Elige 2 protocolos estándar de aplicación y compara objetivo, tipo de mensajes y uso típico.

HTTP (HyperText Transfer Protocol):

• Objetivo: transferencia de documentos hipermedia y recursos web.
• Tipo de mensajes: petición/respuesta (métodos como GET, POST, PUT, DELETE).
• Uso típico: navegación web y APIs REST.
• Ejemplo: el cliente envía GET /index.html y el servidor responde 200 OK con el contenido.

FTP (File Transfer Protocol):

• Objetivo: transferencia de archivos entre sistemas.
• Tipo de mensajes: comandos y respuestas (USER, PASS, RETR, STOR).
• Uso típico: subir/descargar archivos, administración remota de ficheros.
• Ejemplo: el cliente envía RETR documento.pdf y el servidor abre un canal de datos para transmitir el archivo.

8. Describe el ciclo de vida de una comunicación: establecimiento de conexión → transmisión de información → finalización. Incluye qué fallos son comunes en cada fase.

Toda comunicación sigue tres fases:

• Establecimiento: se negocia la conexión (por ejemplo, el handshake de TCP). Fallos comunes: timeouts por servidor caído o rechazo de conexión.
• Transmisión: intercambio real de datos. Fallos comunes: datos incompletos, corrupción de paquetes o desconexiones repentinas de la red.
• Finalización: cierre ordenado de los sockets. Fallos comunes: cierre incorrecto (half‑close), que puede dejar recursos bloqueados o conexiones "zombi".

Es vital implementar reintentos y gestionar excepciones en cada fase para asegurar la robustez del servicio.

9. ¿Qué estrategias conoces para implementar comunicaciones simultáneas en un servidor? Compara 2 enfoques.

Dos enfoques comunes para gestionar múltiples clientes son:

• Hilo por cliente (thread‑per‑client): el servidor crea un hilo nuevo para cada conexión. Fácil de programar, pero poco escalable ante muchos clientes, ya que muchos hilos consumen memoria y CPU.
• Pool de hilos (thread pool): existe un número fijo de hilos precreados que atienden las peticiones según llegan. Es más eficiente y estable, evita la sobrecarga de crear/destruir hilos y limita el consumo de recursos; sin embargo, requiere gestionar colas y políticas cuando el pool está saturado.

Otras alternativas incluyen I/O asíncrona y modelos basados en eventos, que pueden escalar mejor en escenarios con muchas conexiones ligeras.

10. Describe cómo documentarías y depurarías un servicio en red para que otro programador pueda usarlo sin “adivinar” el protocolo.

Para que un servicio sea utilizable sin ambigüedades, debe documentarse de forma clara y completa:

• Especificación de endpoints o comandos, incluyendo métodos, rutas y parámetros.
• Formato de datos detallado (JSON, XML, binario) y ejemplos de petición/respuesta.
• Listado de códigos de error y sus significados.
• Ejemplos reales de interacción y flujos comunes.
• Proporcionar trazas de log y ejemplos de depuración, además de herramientas para monitorizar tráfico.

Esto facilita que otro programador integre el servicio sin necesidad de adivinar el protocolo ni comportamientos no documentados.

Preguntas de la UT6

11. Define qué son las prácticas de programación segura y explica por qué son especialmente críticas en aplicaciones que exponen servicios en red.

Las prácticas de programación segura son técnicas aplicadas durante el desarrollo para prevenir vulnerabilidades y proteger los datos y la disponibilidad del sistema. Son críticas en servicios en red porque estos exponen una superficie de ataque pública, accesible desde cualquier lugar.

La principal amenaza son las entradas no confiables enviadas por usuarios malintencionados; si no se gestionan correctamente, las consecuencias pueden ir desde el robo de información sensible hasta la ejecución de código remoto o la denegación de servicio.

12. Explica qué es control de accesos y plantea un ejemplo de autorización (roles/permisos) para un servicio en red.

El control de accesos se divide en dos pasos: la autenticación (verificar la identidad del usuario, p. ej., login) y la autorización (determinar qué puede hacer ese usuario). En un servicio en red, esto se gestiona mediante roles y permisos.

Ejemplo: en un sistema de archivos expuesto por un servicio, un usuario con rol "Lector" solo puede ejecutar el comando GET, mientras que un "Admin" tiene permisos de lectura‑escritura y puede ejecutar DELETE o PUT. Así se evita que un usuario común borre datos críticos.

13. ¿Qué significa limitación de privilegios (principio de mínimo privilegio)? Pon un ejemplo de cómo aplicarlo en un servidor.

Este principio establece que cada proceso, usuario o programa debe tener únicamente los permisos estrictamente necesarios para realizar su función, y ninguno más.

Ejemplo de aplicación en un servidor:

• Ejecutar el servicio bajo un usuario sin privilegios (no como root/Administrator).
• Separar procesos (sandboxing, contenedores) para aislar componentes.
• Limitar operaciones peligrosas mediante capacidades o políticas ACL.

De este modo, si un atacante compromete un servicio, su alcance queda restringido y no podrá realizar operaciones críticas en el sistema operativo.

14. Explica cómo harías una validación de entradas correcta en un servicio: qué validarías, qué rechazarías y cómo evitarías inyecciones o datos malformados.

Una validación correcta debe basarse en una lista blanca (permitir solo lo que sabemos que es válido) en lugar de intentar bloquear patrones maliciosos. Elementos clave:

• Verificar longitud y tipo de datos.
• Validar formato con expresiones regulares o validadores específicos.
• Comprobar la codificación y normalizar entradas para evitar bypasses.
• Evitar concatenar entradas directamente en comandos o consultas: usar consultas parametrizadas o sentencias preparadas.
• Rechazar datos malformados de inmediato y devolver mensajes de error genéricos que no revelen internals.

15. Explica diferencias entre criptografía de clave simétrica y asimétrica, y comenta 2 aplicaciones típicas en seguridad (por ejemplo, cifrado y firma).

La criptografía simétrica utiliza la misma clave para cifrar y descifrar y es muy eficiente para grandes volúmenes de datos. La criptografía asimétrica usa un par de claves (pública y privada); es más lenta, pero resuelve el problema del intercambio seguro de claves.

Aplicaciones típicas:

• Cifrado de canal (p. ej., HTTPS): se combina asimétrica para el intercambio de claves y simétrica para el cifrado eficiente de la sesión.
• Firma digital: usa criptografía asimétrica para garantizar la integridad del mensaje y el no repudio, ya que la firma vinculada a la clave privada no puede ser falsificada por terceros.

Preguntas de la UT7

16. Explica qué es la encriptación de información en una comunicación y qué se consigue (confidencialidad) y qué no se consigue por sí sola.

La encriptación es el proceso de transformar información legible en un formato cifrado mediante algoritmos matemáticos. Su principal logro es la confidencialidad, asegurando que solo quien posea la clave pueda leer el mensaje.

No obstante, por sí sola la encriptación no garantiza:

• Integridad: que el mensaje no haya sido alterado.
• Autenticación: identificar de forma fiable al emisor.

Por eso es habitual combinar cifrado con mecanismos de firma, códigos MAC o protocolos que incluyan autenticación e integridad.

17. Describe qué es un protocolo seguro de comunicaciones (por ejemplo, concepto tipo TLS) y qué problemas resuelve frente a un canal sin cifrar.

Un protocolo seguro como TLS (Transport Layer Security) establece un túnel protegido sobre un canal inseguro como Internet. Resuelve problemas como:

• Espionaje (sniffing): impide que terceros lean los datos en tránsito.
• Manipulación: detecta si la información ha sido modificada en el trayecto.
• Autenticación: permite verificar la identidad del servidor (y opcionalmente del cliente) mediante certificados, mitigando ataques Man‑in‑the‑Middle.

18. Explica qué son los sockets seguros y cómo cambia el flujo de conexión respecto a sockets “normales” (idea general del handshake).

Un socket "normal" transmite datos en texto plano inmediatamente tras establecer la conexión. Un socket seguro añade una fase intermedia de establecimiento seguro (handshake) en la que cliente y servidor intercambian certificados, validan identidades y negocian claves de cifrado temporales. Solo tras un handshake exitoso se transmite la información de aplicación cifrada, de forma transparente para el programador.

19. Diseña a alto nivel una aplicación cliente‑servidor con comunicaciones seguras: ¿qué pasos seguirías para configurar, probar y depurar la seguridad?

Pasos recomendados:

• Generar y gestionar certificados digitales (al menos para el servidor) y configurar KeyStore/TrustStore en las aplicaciones.
• Forzar el uso de algoritmos y suites de cifrado fuertes y deshabilitar versiones obsoletas (p. ej., TLS 1.0/1.1).
• Probar escenarios de fallo: certificados caducados, certificados no válidos, nombres comunes (CN) incompatibles, ataques de downgrade.
• Revisar los logs de negociación y errores de handshake para depurar problemas.
• Usar herramientas de verificación y escáneres de configuración TLS (p. ej., SSL Labs) para evaluar la seguridad de la configuración.

20. Explica para qué sirven la firma digital y los certificados digitales en una aplicación con comunicaciones seguras y cómo se usarían en un caso real.

La firma digital garantiza la integridad del mensaje y el no repudio (el emisor no puede negar haberlo enviado). El certificado digital vincula una clave pública a una entidad real mediante una Autoridad de Certificación (CA), aportando confianza sobre la identidad del interlocutor.

Ejemplo real: al acceder a la web de tu banco, el navegador verifica el certificado del servidor. Si la firma del certificado es válida y la CA es de confianza, se establece la conexión segura; de lo contrario, el navegador advierte al usuario de un posible riesgo y evita que la comunicación proceda sin una verificación adecuada.