En aplicaciones web, existen dos programas distintos que se comunican entre sí: el navegador que se ejecuta en el host del usuario (ordenador, portátil, tableta, smartphone, etc.) y el servidor web que se ejecuta en el host del servidor web. Por ejemplo, en un sistema de intercambio de archivos P2P, cada host tiene un programa que participa en la comunidad de intercambio de archivos. En este caso, los programas en los distintos hosts pueden ser similares o idénticos.

No es necesario desarrollar software que se ejecute en dispositivos como routers o link-layer switches. Incluso si quisieras, no podrías hacerlo. Estos dispositivos no funcionan en la capa de aplicación, sino que funcionan en capas inferiores, específicamente en la network-layer y demás.

image.png

Desde la perspectiva del desarrollador de aplicaciones, la arquitectura de red es fija y proporciona un conjunto específico de servicios a las aplicaciones. La arquitectura de la aplicación, por otro lado, la diseña el desarrollador y dicta cómo se estructura la aplicación en los distintos sistemas finales.

Client-server architecture

Existe un host siempre activo, llamado servidor, que atiende solicitudes de muchos otros hosts, llamados clientes. Cuando un servidor web recibe una solicitud de un objeto de un host cliente, responde enviándolo a dicho host. Cabe destacar que, con la arquitectura cliente-servidor, los clientes no se comunican directamente entre sí. El servidor tiene una dirección fija y conocida (llamada dirección IP) un cliente siempre puede contactar con él enviando un paquete a su dirección IP. Un host con un solo servidor no puede gestionar todas las solicitudes de los clientes. Por ello, se suele utilizar un data center que alberga una gran cantidad de hosts para crear un potente servidor virtual (puede tener cientos de miles de servidores, que requieren alimentación y mantenimiento). Además, los proveedores de servicios deben asumir costes recurrentes de interconexión y ancho de banda para el envío de datos desde sus data centers.

image.png

P2P architecture

La dependencia de servidores dedicados en los data centers es mínima (o nula). En su lugar, la aplicación aprovecha la comunicación directa entre pares de hosts conectados intermitentemente, llamados pares. Estos pares no son propiedad del proveedor de servicios, sino computadoras de escritorio y portátiles controladas por los usuarios, y la mayoría residen en hogares, universidades y oficinas. Dado que los pares se comunican sin pasar por un servidor dedicado, la arquitectura se denomina peer-to-peer. Una de las características más atractivas de las arquitecturas P2P es su autoescalabilidad. Por ejemplo, en una aplicación de intercambio de archivos P2P, aunque cada par genera carga de trabajo al solicitar archivos, también añade capacidad de servicio al sistema al distribuir archivos a otros pares. Las arquitecturas P2P también son rentables, ya que normalmente no requieren una infraestructura de servidor ni un ancho de banda significativos (a diferencia de los diseños cliente-servidor en centros de datos). Sin embargo, las aplicaciones P2P enfrentan desafíos de seguridad, rendimiento y confiabilidad debido a su estructura altamente descentralizada.

image.png

Los procesos en dos sistemas finales diferentes se comunican entre sí intercambiando mensajes a través de la red informática. Un proceso emisor crea y envía mensajes a la red; un proceso receptor recibe estos mensajes y posiblemente responde enviándolos de vuelta.

Una aplicación de red consta de pares de procesos que se envían mensajes entre sí a través de una red. Por ejemplo, en una aplicación web, un proceso cliente-navegador intercambia mensajes con un proceso servidor web. En un sistema de intercambio de archivos P2P, un archivo se transfiere de un proceso de un par a otro de otro. Para cada par de procesos que se comunican, normalmente se etiqueta a uno como cliente y al otro como servidor. En el contexto de una sesión de comunicación entre dos procesos, el proceso que inicia la comunicación (es decir, contacta inicialmente con el otro proceso al inicio de la sesión) se denomina cliente. El proceso que espera ser contactado para iniciar la sesión es el servidor.

Un proceso envía mensajes a la red y recibe mensajes de ella a través de una interfaz de software denominada socket. Un socket es la interfaz entre la capa de aplicación y la capa de transporte dentro de un host. También se conoce como Interfaz de Programación de Aplicaciones (API) entre la aplicación y la red, ya que el socket es la interfaz de programación con la que se crean las aplicaciones de red. El desarrollador de aplicaciones tiene control total en la capa de aplicación del socket, pero tiene poco control en la capa de transporte. El único control que el desarrollador de aplicaciones tiene en la capa de transporte es (1) la elección del protocolo de transporte y (2) quizás la capacidad de fijar algunos parámetros de la capa de transporte, como el tamaño máximo del búfer y del segmento. Para que un proceso que se ejecuta en un host envíe paquetes a un proceso que se ejecuta en otro, el proceso receptor debe tener una dirección. Para identificar el proceso receptor, se deben especificar dos datos: (1) la dirección del host y (2) un identificador que especifica el proceso receptor en el host de destino. En Internet, el host se identifica por su dirección IP, una cantidad de 32 bits que podemos considerar como su identificador único. Además de conocer la dirección del host al que se destina un mensaje, el proceso emisor también debe identificar el proceso receptor (más específicamente, el socket receptor) que se ejecuta en el host. Esta información es necesaria porque, en general, un host puede ejecutar muchas aplicaciones de red. Un número de puerto de destino cumple esta función. A las aplicaciones más populares se les han asignado números de puerto específicos. Por ejemplo, un servidor web se identifica con el puerto 80. Un proceso de servidor de correo (que utiliza el protocolo SMTP) se identifica con el puerto 25.

image.png

La aplicación del lado emisor envía los mensajes a través del socket. En el otro lado del socket, el protocolo de la capa de transporte se encarga de hacer llegar los mensajes al socket del proceso receptor. ¿Qué servicios ofrece un protocolo de la capa de transporte a las aplicaciones que lo invocan? Podemos clasificar los posibles servicios en cuatro dimensiones: