Aplicaciones de Red y Protocolos

Aplicaciones de Red vs. Protocolos de Capa de Aplicación

• Una aplicación de red proporciona un servicio específico a usuarios, máquinas u otras aplicaciones.
• Los protocolos de la capa de aplicación son normas que rigen el intercambio de información entre procesos de la aplicación.
• Una aplicación puede usar diferentes protocolos de capa de aplicación, incluso en diferentes procesos.

Modelo Cliente/Servidor

• Para dar un servicio, se necesita una aplicación:
  • Servidor: proporciona el servicio.
  • Cliente: solicita el servicio.
• Normalmente se da la relación:
  • Un servidor.
  • Muchos clientes.
• El servidor debe estar en ejecución continua en una red para que los clientes accedan al servicio cuando lo necesiten.
• Una aplicación servidora puede ofrecer varios servicios.
• Varios dispositivos servidores pueden ser necesarios para dar un servicio de forma adecuada.
• El Servidor es un programa que se ejecuta en una máquina remota, proporcionando un servicio a los clientes.
• Al iniciarse el servidor, establece un mecanismo para recibir y atender peticiones de los clientes.
• El servidor no suele iniciarse hasta que es requerido.
• El Cliente es un programa ejecutado localmente que solicita un servicio específico a un servidor remoto.
• El Cliente es un programa finito que está activo hasta que el servicio se completa o se apaga.

Proceso de Solicitud de Servicio en Internet

• Paso 1: El cliente establece un canal de comunicación con el servidor usando su dirección IP y un puerto "bien conocido".
• Paso 2: El cliente envía su petición a través de ese canal.
• Paso 3: Normalmente, el cliente recibe una respuesta, repitiendo esto hasta completar el servicio.
• Este proceso está normalmente acotado en tiempo y tiene un final establecido.

Aplicaciones Peer-to-Peer (P2P)

• Algunas aplicaciones no son solo clientes o servidores, sino ambos a la vez debido a su naturaleza distribuida.
• Todos los participantes actúan como proveedores y consumidores del servicio.
• Ejemplos de funcionalidades: Compartición de archivos e impresoras y multi-conferencias.
• Algunos ejemplos: BitTorrent, uTorrent, Shareaza y el protocolo Gnutella.
• Formando una nueva red que solo da servicios a sus miembros.
• El mayor problema es descubrir a los otros miembros, a menudo apoyándose en servidores o listas iniciales.

Protocolos de Transporte en Internet

• Los niveles de transporte y aplicación son los más cercanos para el diseño de servicios en IoT.
• Protocolos de transporte comunes: UDP y TCP.
• Protocolo de aplicación típico: HTTP (Hyper-Text Transfer Protocol).
• El uso de TLS (Transport Layer Security) entre transporte y aplicación da más seguridad, creando HTTPS.

Protocolos Extremo a Extremo

• Implementados normalmente en el núcleo del sistema operativo.
• El rendimiento afecta de manera importante a las comunicaciones.
• Son muy complejos de modificar o estandarizar.
• Algunos protocolos recientes usan UDP como base: RTP o QUIC.

Protocolos de la Capa de Aplicación

• Definen cómo los procesos de una aplicación específica intercambian mensajes.
• Usan servicios de una capa de transporte subyacente, normalmente un solo tipo.
• El protocolo DNS suele usar UDP, pero a veces usa TCP.
• Se pueden definir protocolos propietarios para servicios concretos.

Definición de un Protocolo de la Capa de Aplicación

• El tipo de mensajes intercambiados (petición, respuesta, error, etc.).
• Sintaxis de los mensajes (campos, longitud, etc.).
• La semántica de los campos (significado de la información).
• Reglas sobre cuándo enviar/responder mensajes y cómo tratarlos.

Ejemplos de Protocolos y Aplicaciones en Internet

• Correo Electrónico: SMTP (envío), POP3/IMAP (lectura), todos sobre TCP.
• Transferencia de Ficheros: FTP (sobre TCP) y TFTP (sobre UDP o TCP según el tamaño).
• Nombres de Dominio: DNS (sobre UDP y TCP).
• World Wide Web: HTTP (sobre TCP, HTTP/3 va sobre QUIC).

Normalización de Protocolos en Internet

• La mayoría de los protocolos de aplicación se desarrollan dentro del IETF.
• Los documentos que describen Internet son los "Request for Comments" (RFC).
• Se puede consultar el estado de cualquier documento en: https://www.rfc-editor.org/.
• UDP permite una conexión con una sobrecarga baja para protocolos que no necesitan TCP.
• UDP se usa en aplicaciones de difusión y multidifusión y requiere tiempos cortos para obtener información.
• Su identificador de protocolo es 17.
• El protocolo UDP está definido en el RFC 768.

Protocolo de Datagrama de Usuario (UDP)

• El usuario transmite mensajes sin conexión y con baja sobrecarga (8 bytes), sin garantía de entrega ni secuenciación.
• Otras RFCs relevantes para UDP incluye la 1122 (Host Network Requirements)
• Transporta unidades de datos entre PUERTOS de sistemas.
• Adecuado para aplicaciones que implementan sus propios controles de errores (DNS, streaming, multimedia, multicast).
• UDP agrupa los datos en un solo datagrama, con un tamaño de 8 a 64.000 bytes.
• Si el datagrama UDP es leído por el destinatario, éste está seguro que el datagrama está completo.
• Si un datagrama UDP es fragmentado en IP y uno de estos fragmentos se pierde, todo el datagrama será descartado.
• Normalmente, para depurar efectivamente los problemas con la transmisión de paquetes UDP, es necesario delegar en otros protocolos como ICMP (Internet Control Message Protocol).
• Si se desea implementar corrección de errores, ésta debe relegarse a la aplicación.
• Las aplicaciones que usen UDP comenzarán a notar problemas antes que aquellas que usen protocolos como TCP, en entornos de red con altas tasas de pérdidas de paquetes.
• El tráfico UDP suele estar bloqueado por muchos firewalls, salvo aquellos servicios más importantes, como DNS.

Ejemplos de Puertos UDP

• Puerto 53: DNS (sencillo sistema de preguntas y respuestas).
• Puertos 67 y 68: BOOTP/DHCP (protocolos de configuración de host).
• Puerto 69: TFTP (envío rápido de ficheros pequeños).
• Puerto 137: NetBIOS (interfaz de IBM para PCs conectados en red).
• Puertos 161 y 162: SNMP/SNMP trap (gestión de red con mensajes cortos).

Protocolo de Control de Transmisión (TCP)

• Proporciona un servicio fiable, orientado a conexión.
• TCP es usado prácticamente por todos los protocolos de aplicación que existen hoy en día en Internet.
• Identificador de protocolo: 6.
• Estándar: 7 (RFC 9293 de 2022).
• Establece conexiones de transporte entre puertos de diferentes sistemas mediante el protocolo “Ida - vuelta - ida” o “a tres vías”.
• Control de flujo mediante ventana deslizante y control de congestión.
• Separa los datos de capas superiores y los fragmenta en unidades de 64 KBytes como máximo, denominadas segmentos.
• Utiliza temporizadores y retransmisiones para la recuperación de segmentos perdidos o dañados.
• Secuenciado de la información: numeración de bytes por su índice en la comunicación.
• Posibilidad de incluir comportamientos opcionales.
• Todos los servicios hacen a TCP un protocolo de transporte muy robusto y proporciona circuitos virtuales.
• También la gestión de entrada/salida a la aplicación o a la red y Confiabilidad.

Protocolo de Transferencia de Hipertexto (HTTP)

• HTTP comenzó como un protocolo muy simple para enviar sólo documentos HTML.
• HTTP es el protocolo de aplicación sobre TCP/IP para la World Wide Web.
• Ahora posibilita transferencia de todo tipo de ficheros, streaming y uso de proxy, entre otras funciones sofisticadas.
• Los URIs (Identificadores Uniformes de Recursos) se usan para acceder a un recurso en el servicio web.

Sintaxis Genérica de los URIs

• Esquema (scheme).
• Autoridad (authority).
• Ruta (path).
• Petición (query).
• Fragmento (fragment).

Formato de una URL

• La URL (Localizador Uniforme de Recursos) normalmente es sencilla, pero en detalle sería: http://:@:/?#
• El puerto por defecto para el servicio web es el 80 (esquema HTTP) y el 443 para conexiones seguras con TLS (HTTPS).
• Las peticiones comunican aspectos adicionales al servidor.
• URL de ejemplo:
  • Página web: http://labtelema.ujaen.es/index.html
  • Aplicación web en puerto 8083: http://labtelema.ujaen.es:8083/index.html
  • Página web con TLS: https://labtelema.ujaen.es/index.html
  • Búsqueda con formulario: https://www.ujaen.es/search?s=matricula
• Caracteres inseguros en URLs se sustituyen por % seguido del código ASCII en hexadecimal.
• Caracteres seguros: alfanuméricos (A-Z, a-z, 0-9) y especiales ($,-,_,.,+,!,*,´,(,)).

HTTP: Protocolo Cliente/Servidor

• Está basado en peticiones y respuestas.
• El cliente HTTP es llamado agente de usuario (ej: navegador).
• El servidor HTTP o servidor web es el que responde.
• El principal objetivo es intercambiar recursos con un URI.
• Las peticiones que son formateadas según la especificación HTTP, incluyen:
• Un método (GET, HEAD, POST, etc.).
• Información para procesar la petición (cabeceras).
• En peticiones POST, incluye un recurso o entidad.
• El servidor interpreta la petición del cliente toma acciones relevantes y elabora un mensaje de respuesta.
• La respuesta contiene:
• Un código de estado (éxito o fallo).
• Nuevos campos para completar la respuesta y/o el recurso incluido.
• Generalmente un recurso.

HTTP: Funcionamiento y Versiones

• Versiones actuales:
• HTTP/1.1 (1999): Mensajes en texto plano, evoluciona el rendimiento pero manteniendo la compatibilidad.
• HTTP/2 (2015): Cambio radical al intercambiar mensajes, rompiendo compatibilidad pero manteniendo funcionalidades.
• HTTP/3 (2022): Usa el protocolo QUIC (sobre UDP), cambio más significativo con respecto a HTTP/2.
• Una aplicación sobre HTTP puede usar cualquier versión de manera transparente.

HTTP: Evolución, Acutalizaciones y RFCs

• En 2022, la estandarización de HTTP/3 unifica muchas RFCs en la RFC 9110 HTTP Semantics.
• La RFC 9110 HTTP Semantics deja obsoletas: las RFC 2818, 7230, 7231, 7232, 7233, 7235 y 7238.
• Tres versiones siguen estando vigentes y cuál usar dependerá de la propia evolución de Internet.

HTTP/2: Mejoras de Rendimiento

• Era mejorar el rendimiento del protocolo HTTP/1.1 en el entorno del servicio web de la época:
• Las peticiones se tienen que resolver en orden.
• Cabeceras repetitivas y demasiado largas.
• Algunas funcionalidades aportadas son:
• Mezcla de mensajes de petición y respuesta en forma de streams.
• Codificación eficiente de los cabeceras.
• Priorización de peticiones se realiza antes.
• Se usará una sola conexión TCP.

HTTP/3: Motivaciones

• Surge de la necesidad de conseguir una menor latencia en las comunicaciones y solventar algunos problemas que presenta TCP.
• HTTP/3 comienza como HTTP-over-QUIC y el primer borrador data de noviembre de 2016.
• Actualmente ya es soportado en la mayoría de navegadores.
• Permite un mayor número de streams. La concurrencia de streams la aporta QUIC, que considera cerrado un stream cuando todos los datos han sido recibidos y asentidos por el par.

Métodos HTTP

• Existen 8 métodos definidos que siempre debes escribirse en mayúsculas:
• Los más usados: GET, POST y HEAD.
• Los otros cinco: OPTIONS, PUT, DELETE, TRACE y CONNECT.
• También existen los metodos PATCH y los métodos de WebDav, pero no son parte de la definición estándar de HTTP.

Métodos HTTP: Acciones

• GET: Obtiene el recurso especificado en la URL del servidor web.
• HEAD: Como GET, sin enviar el recurso, sino solo las cabeceras, para verificar la existencia, estado o tamaño de un recurso.
• POST: Envía información al servidor para que sea procesada por el recurso en la URL.

Métodos HTTP: Acciones Adicionales

• OPTIONS: Obtiene información sobre las capacidades de comunicación del servidor.
• PUT: Envía un fichero al servidor especificado en la URI (no suele estar permitido).
• DELETE: Borra un recurso en el servidor (tampoco suele estar permitido).
• TRACE: Para que el cliente solicite los datos de la petición enviada al servidor, usualmente se usa para diagnostico
• CONNECT: Para que el uso del servidor con un proxy se transforme dinámicamente a modo túnel.

Códigos de Estado HTTP

• 1yy: Mensaje de información.
• 2yy: Éxito.
• 3yy: Redirección.
• 4yy: Error del cliente.
• 5yy: Error del servidor.

Protocolo Websocket

• Permite comunicación bidireccional asíncrona sobre una sola conexión TCP.
• Utiliza los puertos 80 y 443 y facilita la creación de aplicaciones cliente interactivas.
• Se negocia su activación como una petición HTTP con la cabecera UPGRADE.

Tecnologías Front-End

• Ejecutan aplicaciones en un navegador, a través de la información que este proporciona.
• Usualmente requieren aplicaciones back-end.
• 3 pilares fundamentales:
• HTML: Lenguaje de marcas que configura el contenido y estructura del documento.
• CSS: Lenguaje para personalizar los elementos visualizados.
• JavaScript: Lenguaje para añadir comportamientos complejos en el lado cliente.

HTML

• Lenguaje de marcas para crear páginas web y proporciona la estructura y el contenido.
• La versión 5 aporta nuevos elementos para esta estructura además de soporte a mejores aplicaciones gráficas (Canvas) y permite separar el contenido de la presentación (CSS).

XML

• Un lenguaje de marcas para la definición de cualquier tipo de información, creando nuevos tipos de documentos.
• Es más estricto que HTML y debe seguir una sintaxis concreta.
• Tiene un elemento raiz que abarca a los demás elementos, con marcas de apertura y cierre.
• Los elementos pueden tener otros elementos, atributo y texto, sintaxis de la información XML.
• Puede contar con documentos de especificación o VOCABULARIOS que permiten definir las marcas, jerarquía y atributos para construir el XML.
• Si respeta lo especificado en un vocabulario se dice que el XML es válido.

Lenguajes De Definición De Vocabularios Son

• DTD
• Schema

Ventajas de XML

• Facilidad de procesamiento, tanto por máquinas como por humanos.
• Separa la información (contenido) de su presentación (formato).
• Un documento puede tener varias formas de presentación.

JSON

• Es un formato de datos para representar objetos y se utiliza para serializar y transmitir estructuras de datos.
• Generalmente, es empleado en el intercambio de datos entre aplicaciones web y posee una sintaxis ligera y compacta.
• Con JSON se especifican datos simples, objetos y Arrays y Validador de sintaxis.

JavaScript

• Lenguaje para crear aplicaciones cliente, interpretado y sin requerir compilación.
• Sintaxis similar a Java y C que mejora la apariencia, con gráficos e interacción para el usuario.
• Se pueden implementar cálculo de funciones, utilizado principalmente en páginas web.
• Es posible insertar en páginas HTML y también agregar como referencia a un archivo externo para validación de datos de entrada.

JavaScript en la Actualidad

• JavaScript cuenta con múltiples APIs y frameworks (Vue.js, REACT, Angular, jQuery) que permiten aumentar la productividad y la calidad de las aplicaciones de cliente.

Back-End

• Back-end también se puede definir como la aplicación del lado del servidor que recibe los datos del agente de usuario y proporciona una salida a éste.
• El comportamiento debe se modela por arquitectura MVC.

Arquitectura MVC

• El modelo define la información que se gestiona en la aplicación.
• La vista define cómo se representa.
• El controlador gestiona las peticiones del usuario y la interacciones entre el modelo y la vista.
• Hoy en día, se utilizan tecnologías de persistencia para el ORM que permite adaptar los datos abstractos al controlador o base de datos. Algunos ejemplos son: Hibernate, Spring, Laravel, Django.

Bases de datos

• Existen multitud de motores de base de datos, fundamentalmente de dos tipos:
  • Bases de datos relacionales : Oracle, MySQL, PostgreSQL, Ms SQL Server.
  • Bases de datos no SQL: Redis, Amazon DynamoDB, Couchbase, Google Cloud Datastore, MongoDB, e IBM Cloudant.
• Suelen emplear tecnología basada en plantillas para una generación que mezcle partes fijas con partes dependientes del modelo, entre ellos tenemos: "Java Server Pages (JSP), Jade, PUG, JSX (empleado por Vue o REACT) ο Mustache".
• El controlador se encarga de recibir las peticiones de los usuarios y las envía a la vista para generar la salida al agente del usuario. Algunos son

Tecnologías Empleadas

• Java EE
• PHP
• ASP.NET
• Node JS
• Python
• Ruby
• Perl
• Los servicios de una aplicación servidora o back-end debe ser mediante HTTP.

SOAP

• Define un protocolo basando en XML para el intercambio de mensajes que permitan la ejecución remota de métodos.
• Está basado en XML.
• La última versión es SOAP Version 1.2.

REST

• Ejemplo SOAP vs REST con REST las operaciones y los objetos sobre los que operar no tienen por qué estar predefinidos.
• Manipular los objectos a partir de la URI.
• Aplicar acciones concretas sobre los recursos, siempre y cuando estén identificados con una URI:
  • POST (crear/actualizar)
  • GET (leer y consultar), PUT (actualizar/crear),
  • DELETE (eliminar)
  • PATCH* (actualizar parcialmente)
• Con todo ello podemos utilizar los códigos de estados.
• Además incluye la arquitectura jerárquica con diferentes capas entre los componentes.

Ejemplos de Petciones en REST

• Obtener el usuario con ID 1 GET /users/1
• Crear un nuevo usuario POST /users
• Modifica el usuario con ID 1 PUT/users/1
• Actualizar datos del usuario con ID 1 PATCH /users/1
• Borra el usuario con ID 1 DELETE /users/1

IoT Introducción

• Es importante tener en cuenta la comunicación M2M, la variedad para acceso a la red y la interacción con el entorno.

Contexto del IoT

• Falta de inter-operabilidad, necesidad de APIs independientes con tecnologías existentes, web semántica o Efficient XML Ingerchange que se definen con recomendaciones.

Organismos del IoT

• Web of Things Working Group
• Open Mobile Alliance.
• OneM2M Objetivo
  • Construir especificaciones técnicas que aborden la necesidad de una capa unificada de servicio M2M entre hardware y software.
  • Atraer a organizaciones relacionadas con telemáticas, transporte inteligente, atención médica, automatización, hogares inteligentes, etc.

CoAP

• Es un protocolo software a nivel de aplicación pensado para ser usado en dispositvos más simple con un modelo de uso REST de HTTP

Smart Energy

• Protocolo estándar e interoperable que conecta los diferentes dispositivos de energía inteligente en el hogar con la red inteligente, además utiliza la red WiFi.

LwM2M

• Protocolo de administración de dispositivos diseñados para redes de sensores y las demandas de un entorno de máquina a máquina.
• La versión 1.2 permite también ir sobre MQTT y HTTP y se basa en los estándares de protocolo y seguridad del IETF

XMPP

• Tecnologías abiertas para mensajería instantánea, charla multiusuario, llamadas de voz, colaboración, enrutado generalizado de datos.
• Lo principales es intercambiar la información entre las streams formateadas en XML, con servicios similares al correo electrónico mejorado y con comportamientos en tiempo real.

AMQP Eficaz Confiable Flexible

• Codifican los mensajes para tener una mayor garantía que sea compatible con los diferentes tipos intercambiables.
• Usa una codificación binaria con estructura con componentes, capas independientes y se pueden agregar fácilmente nuevos a agentes de mensajes existentes.

DDS

• El primer estándar internacional abierto de middleware que aborda directamente las comunicaciones de publicación y suscripción para sistemas en tiempo real e integrados.
• Permite la comunicación a través de un nuevo procolo, el IPv6, que construye nuevos aparatos y conecta de manera confiable.

Otros

• También tenemos el
• Thread, solución de IBM
• Servicios de la nube con ThingsBoard
• MQTT, HTTPs, AMQP y MQTT.
• Emplea un API REST O MQTT
• NodeRED que tiene integración con AWS y Azure