Principles of network applications

De Departamento de Informatica
Saltar a: navegación, buscar
nube

Las redes de computadores existen para dar soporte a las aplicaciones de red. El desarrollo de una aplicación de red implica escribir programas que se ejecutan en distintos sistemas y que se comuniquen entre sí a través de la red.

Ejemplos de aplicaciones: correo electrónico de texto, acceso remoto a computadores, transferencia de archivos y los chats de texto, World Wide Web, navegación y búsqueda web y comercio electrónico. Y las estrellas: Mensajería instantánea con listas de contactos e intercambio de archivos P2P (Peer to Peer), al igual que telefonía por internet, intercambio y flujo de videos, radio por internet y televisión IP.

Contenido

Arquitecturas de las aplicaciones de red

Arquitectura de una aplicación es diferente a arquitectura de red. Para el desarrollador de aplicaciones la arquitectura de la red es fija y proporciona servicios, él diseña la arquitectura de la aplicación y establece cómo debe estructurarse en los distintos sistemas terminales. Luego de seleccionar la arquitectura de la aplicación, debe seleccionar uno de los paradigmas arquitectónicos: Arquitectura Cliente-Servidor o Arquitectura P2P. Sin embargo hay aplicaciones que poseen una arquitectura híbrida que combina a ambas.

cliente-servidor y peer to peer

Arquitectura Cliente-Servidor

Aquí, siempre existe un host activo (Servidor), que da servicio a las solicitudes de los demás host (Clientes), éstos no siempre están activos de forma permanente.

Características de esta arquitectura:

  • Los clientes no se comunican entre sí directamente, por ejemplo, en la aplicación web, dos navegadores no se comunican entre sí.
  • El servidor posee una dirección fija y conocida denominada IP. De esta manera, un cliente siempre puede conectarse con él enviando paquetes a su dirección.

Como un único servidor puede que no sea capaz de responder a todas las solicitudes, ya que llegan muchas peticiones y el servidor “colapsa”, para esto se usa un conjunto de host (Cluster) llamados centro de datos, que aparentan un servidor virtual de gran capacidad.

Ejemplos de aplicaciones en arquitectura C-S: Aplicaciones web, correo electrónico.

Los servidores para estas aplicaciones poseen una infraestructura intensiva (compra, instalación y mantención de granjas de servidores), lo que hace su suministro costoso.

Ejemplos de servidores: Google, Amazon, Facebook, YouTube.

cliente-servidor

Arquitectura Peer-to-Peer

No se necesita un único servidor siempre activo. Hay comunicación directa entre host conectados de forma intermitente llamados Peers (pares), estos peers corresponden a computadoras o móviles manejados por usuarios, ubicados en su mayoría en oficinas, hogares o universidades. Se usa principalmente en distribución de archivos y telefonía por internet, por el alto nivel de tráfico.

Características de esta arquitectura:

  • Administra y optimiza los recursos de ancho de banda.
  • Es auto-escalable (peers piden paquetes y a la vez entregan paquetes a otros peers).
  • Posee una buena relación entre coste-presentaciones (no requiere un gran ancho de banda ni una infraestructura significativa de servidor).

Ejemplos de aplicaciones en arquitectura P2P: Bittorrent, Skype.

Retos para aplicaciones P2P:

  • Orientadas al ISP: Se desplaza el tráfico de carga a los servidores ISP residenciales, ejerciendo una gran presión sobre éstos.
  • Seguridad: Reto en seguridad debido a su naturaleza extremadamente distribuida y abierta.
  • Incentivos: Reto en convencer a los usuarios a ofrecer recursos de ancho de banda, almacenamiento y computación a las aplicaciones.
peer to peer

Procesos de comunicación

Los procesos de dos sistemas terminales diferentes se comunican entre ellos intercambiando mensajes a través de la red de computadoras, un proceso emisor envía mensajes a la red y un proceso receptor recibe estos mensajes y puede o no responder devolviendo mensajes, esto mediante la capa de aplicaciones.

capa de aplicación

Procesos Cliente-Servidor

Independiente de la arquitectura de aplicación usada, siempre hay un host que actúa como servidor (espera a ser contactado) y otro como cliente (el que inicia la comunicación), interactuando a través de mensajes. En P2P se da entre 2 peers.

Ejemplos:

  • Arquitectura C-S: Un proceso de navegador web (cliente) inicia el contacto con un proceso de servidor web (servidor).
  • Arquitectura P2P: En intercambio de archivos, un peer A (cliente) pide a peer B (servidor) que le envíe un archivo. Esto se podría invertir si luego el peer B le pide un archivo al peer A.

Interfaz entre el proceso y la red de computadoras

Cualquier mensaje que se envíe de un proceso a otro, debe pasar por la red, la que los recibe a través de una interfaz de software denominada socket (que análogamente cumple la función de una puerta por la que pasa el mensaje para entrar al proceso que se ejecuta en el host receptor). Socket es la interfaz entre la capa de aplicación y la capa de transporte, también se dice que es la interfaz de programación de aplicaciones (API).

Control del desarrollador de la aplicación sobre el lado de la capa de aplicación del socket:

  • Control sobre todos los elementos.

Control del desarrollador de la aplicación sobre el lado de la capa de transporte del socket:

  • Elección del protocolo de transporte.
  • Fijar un pocos parámetros de la capa de transporte (tamaño máximo del buffer).
  • Elegido el protocolo de transporte, la aplicación se crea utilizando los servicios de la capa de transporte proporcionados por el protocolo.
intercambio de mensajes entre procesos

Servicios de transporte disponibles para las aplicaciones

Muchas redes proporcionan más de un protocolo de la capa de transporte, los que se eligen según los servicios que proveen para permitirnos enviar y recibir mensajes de un host a otro.

Los servicios se pueden clasificar de acuerdo a cuatro parámetros:

  • Transferencia de datos fiable
  • Tasa de transferencia
  • Temporización
  • Seguridad.

Transferencia de datos fiable

En una red de computadores siempre se pueden perder paquetes, y en algunos casos las consecuencias son graves (aplicaciones financieras). Por lo que se necesita dar un soporte para garantizar que el envío de datos sea correcto. Una garantía absoluta de entrega de datos correctos es lo que se denomina transferencia de datos fiable. En otros casos la pérdida de datos no es grave y se puede aceptar, llamándose así aplicaciones tolerantes a pérdidas (aplicaciones multimedia audio/video)

trasferencia de datos

Tasa de transferencia

Tasa a la que el proceso emisor puede suministrar bits al proceso de recepción. Durante una conexión, existirán otras sesiones que compartirán ancho de banda a lo largo de una ruta de red, esto provocará que la transferencia de datos pueda fluctuar con el tiempo. Existe otro protocolo que es capaz de proporcionar una tasa de transferencia específica, que es capaz de garantizar que al menos se entreguen r bits/segundo por cada transferencia. Las aplicaciones que poseen un requisito de tasa de transferencia son conocidas como aplicaciones sensibles al ancho de banda.

En la actualidad existen muchas aplicaciones multimedia que son sensibles al ancho de banda, pero algunas de ellas pueden emplear técnicas de codificación adaptativa para realizar la codificación a una velocidad que se adapte a la tasa de transferencia disponible actualmente. Por otro lado, también existen aplicaciones elásticas que pueden hacer uso de la tasa de transferencia, mucha o poca, que haya disponible. Por ejemplo, el correo electrónico.

Temporización

También existe un protocolo que es capaz de proporcionar garantías de temporalización. Estas pueden darse de varias formas, por ejemplo, que cada bit que el emisor empuja por su socket para que llegue al del receptor, no lo haga en más de 100 milisegundos. Esto sería útil para aplicaciones en tiempo real, como los juegos multijugador. Por otro lado, en las aplicaciones que no se ejecutan en tiempo real, no es estrictamente necesario que no exista

Seguridad

El protocolo de transporte puede proporcionar seguridad ya sea:

  • Cifrando la información que envía a través de los paquetes (dando confidencialidad entre procesos)
  • Garantizando la integridad de los datos
  • Proporcionando mecanismos de autenticación.

Servicios de transporte proporcionados por internet

Al crear una nueva aplicación de red el desarrollador debe escoger entre los protocolos de transporte UDP o TCP, los cuales poseen un conjunto de servicios diferentes a las diversas aplicaciones.

TCP v/s UDP

Servicios TCP

Cuando una aplicación invoca TCP como su protocolo de transporte, la aplicación recibe estos dos servicios:

Servicio orientado a conexiones

Implementa handshaking, alertando al cliente y al servidor de que se viene una transferencia de paquetes. La conexión es full-duplex: los dos procesos pueden enviarse mensajes mutuamente al mismo tiempo. Los dos procesos están conectados “débilmente”, por eso se dice que es un servicio orientado a conexiones, en vez de ser un servicio de conexiones.

Servicio confiable de transferencia de datos

Los procesos pueden confiar en que TCP enviará todos los datos sin errores y en el orden correcto. TCP enviará los flujos de datos sin bytes duplicados ni ausentes.

TCP posee un mecanismo de control de congestión que reduce la transferencia cuando la red está congestionada. Es por esto que las aplicaciones que funcionan en tiempo real prefieren usar UDP en vez de TCP.

Servicios UDP

UDP es un proceso de transporte liviano, que provee los mínimos servicios. No hay handshaking, y no hay ninguna garantía de que los mensajes enviados llegarán en algún momento a destino. Es más, podrían llegar en el orden incorrecto.

No hay mecanismos de control de congestión, entonces la parte que envía los mensajes puede hacerlo a la rapidez que desee. Esto lo hace conveniente para aplicaciones en tiempo real que pueden funcionar sin recibir todos los paquetes. Por otra parte, muchos firewalls bloquean el tráfico UDP, entonces para algunos casos, como la transferencia de video, se sigue usando TCP.

Servicios no proporcionados por los protocolos de transporte de Internet

El Internet de hoy generalmente puede proveer servicios aceptables para aplicaciones que dependen del tiempo (como la telefonía), pero no puede proveer garantías de tiempo o de ancho de banda. Email, acceso remoto por terminal, la Web y transferencias de archivos usan TCP, principalmente por la garantía de que toda la información llegará a su destino tarde o temprano. La telefonía por Internet generalmente funciona sobre UDP, porque pueden tolerar pérdidas y necesitan enviar paquetes a un flujo constante.

Direccionamiento de procesos

Al configurar un cliente de correo, podemos establecer los puertos que utilizará para enviar y recibir mensajes.

Hasta ahora nos hemos enfocado en los servicios de transporte entre dos procesos pero, ¿cómo un proceso indica con qué proceso se quiere comunicar, usando estos servicios? ¿Cómo un proceso en Valparaíso especifica que quiere comunicarse con un proceso específico que está corriendo en un host de Viña del Mar? Para identificar el proceso receptor, se deben especificar dos cosas: 1) el nombre o dirección del host, y 2) un identificador que especifica el proceso receptor en el host de destino.

En Internet, el host es identificado con su dirección IP. Esto es una cantidad de 32-bit que, en teoría, es única para cada host (con la popularidad de las NAT ya no se puede garantizar esto).

Para identificar al proceso receptor que recibirá el mensaje, se usa el número de puerto. Aplicaciones conocidas tienen un número de puerto asignado, por ejemplo: 80 para un servidor web. Un servicio de envío de email tiene el puerto 25 (SMTP). Cuando un desarrollador crea una nueva aplicación de red, se le debe asignar un nuevo número de puerto.

Otros puertos comúnmente usados:

20 - FTP (protocolo de transferencia de archivos, usado generalmente para transferir archivos desde y hacia un servidor web)

110 - POP3 (para recibir email)

443 - HTTPS (para conexiones encriptadas en la web)

Protocolos de la capa de aplicación

Un protocolo de la capa de aplicación define cómo los procesos de una aplicación, que se ejecutan en distintos sistemas terminales se pasan los mensajes entre sí.

Protocolo de la capa de aplicación define:

  • Los tipos de mensajes intercambiados (mensajes de solicitud o respuesta).
  • La sintaxis de los diversos tipos de mensajes, es decir, los campos que posee el mensaje y cómo se delimitan estos campos.
  • La semántica de los campos (el significado de la información que contienen).
  • Las reglas para determinar cuándo y cómo un proceso envía mensajes y responde a los mismos.

Existen protocolos de:

  • Dominio público especificados en documentos RFC, como HTTP (si un navegador usa estas reglas puede recuperar páginas desde cualquier servidor web que también las use).
  • Propietarios (intencionalmente no son de dominio público), como los sistemas que usan P2P.

Un protocolo de la capa de aplicación de red es sólo un elemento de una aplicación de red. Un ejemplo de interacción entre aplicación y protocolo sería una aplicación de correo electrónico, la que entre sus componentes incluye servidores de correo que almacenan los buzones de los usuarios, los lectores de correo (permiten leer y crear mensajes), un estándar para definir la estructura del mensaje, y los protocolos que definen como se pasan los mensajes entre servidores. Un protocolo importante en el envío de correos electrónicos es SMTP, pero es sólo un componente de la aplicación.


Referencias

Herramientas personales
Espacios de nombres
Variantes
Acciones
Navegación
Herramientas