RAI PEC2 2020 2021 2 - Prueba Evaluación Continua PEC 2 RAI Segundo semestre año 2020 - 2021 PDF

Preview

Summary

2020 -21/Estudios de Informática, Multimedia y TelecomunicaciónRedes y Aplicaciones InternetPEC 2 – Segunda Prueba de Evaluación Continua Hay que entregar la solución en un fichero preferiblemente pdf, utilizando la plantilla adecuada, en el registro de evaluación continua. • La fecha límite de entr...

Description

PEC 2 RAI 2020-21/2

Estudios de Informática, Multimedia y Telecomunicación

Redes y Aplicaciones Internet PEC 2 – Segunda Prueba de Evaluación Continua

•

Hay que entregar la solución en un fichero preferiblemente pdf, utilizando la plantilla adecuada, en el registro de evaluación continua.

•

La fecha límite de entrega es el 25 de Abril de 2021

Respuestas 1. HTTP/3 es el nombre oficial de la próxima versión de protocolo de comunicaciones que permite las transferencias en la web. Lo define el ietf y tiene una diferencia muy importante respecto a HTTP/2, pues será la que deje de utilizar por primera vez el protocolo TCP que hasta ahora se ha venido utilizando en el HTTP, y lo sustituirá un nuevo protocolo llamado QUIC (Quick UDP Internet Connections). QUIC Es un protocolo de red perteneciente a la capa de transporte desarrollado inicialmente por Google en el que se utiliza el control de congestión del espacio de usuario. Está utilizado sobre el Protocolo de Datagrama del Usuario (UDP). A diferencia del TCP no requiere del intercambio continuo de información entre el emisor y el receptor del paquete de información. El protocolo de transferencia ya no se encarga de la integridad de los datos, ese peso recaerá de cada aplicación que lo use. Otra de las características clave de QUIC es que está cifrado por defecto con TLS 1.3. Como similitudes podemos destacar que ambos protocolos tienen la función de multiplexación de flujo. Actualmente se encuentra en estado de pruebas, si bien Firefox o Chrome ya lo han implementado en las nuevas versiones de sus navegadores. También Cloudflare ha implementado la compatibilidad de este protocolo, así como en otras grandes empresas en sus librerías de código abierto. 2. NO VÁLIDA - REPETIDA 3. NO VÁLIDA - REPETIDA 4. Hipervisores frente a PaaS. La elección de estas dos plataformas se debe a que son las que me resultan más familiares. De un lado, los hipervisores, que son la primera capa que se debe poner o bien sobre el sistema operativo host o integrado en este y funcionando como un conjunto indivisible. Esta capa, que en el sentido más amplio puede ser software, firmware o hardware, es el responsable de crear y ejecutar máquinas virtuales (llamadas guest) sobre el ordenador base (llamado host). El hipervisor permite (y gestiona) que las máquinas virtuales se puedan ejecutar simultáneamente, cada uno con su sistema operativo, y compartir los recursos hardware base presentando a cada uno de ellos una plataforma virtual. Una característica importante de esta plataforma es que los operativos en cada máquina virtual se ejecutan como si estuvieran sobre un hardware determinado en un entorno cerrado y solo con algunos recursos compartidos con el sistema

PEC 2 RAI 2020-21/2 operativo host. Los SO guest pueden ser de diferentes tipos (Linux, Unix, Windows, etc.) en contraposición con la virtualización del nivel del sistema operativo, donde todas las instancias (contenedores) deben compartir un único núcleo (kernel), aunque los SO guest pueden diferir en el espacio de usuario, como diferentes distribuciones de Linux, pero con el mismo kernel. Del otro, Paas (platform as a service), plataformas que proporcionan a los usuarios herramientas para desarrollar, ejecutar y administrar aplicaciones (generalmente web), y dado que estas se ofrecen como un servicio a través de internet, los desarrolladores pueden trabajar dentro de ellas sin tener que gestionar la infraestructura subyacente, permitiéndoles concentrarse únicamente en desarrollar su aplicación. Las ofertas de plataformas incluyen componentes de muchos servicios utilizados en el desarrollo de software, incluyendo bases de datos, servidores web, sistemas operativos y almacenamiento, permitiendo que en algunas de ellas trabajen múltiples usuarios, facilitando la colaboración y compartición de código y recursos. Alguna de las diferencias principales entre ambas plataformas es que los hipervisores permiten crear y gestionar máquinas virtuales sobre el ordenador base, cada una con su sistema operativo, y compartir los recursos hardware base, disponiendo al usuario de un sistema completo, mientras que Paas se centra en una parte concreta del servicio que es la de proporcionar herramientas de desarrollo de aplicaciones a través de un entorno web. - Ejemplo de empresa que ofrece/utiliza Hipervisor: Parallels - Principalmente hace la competencia a VMware (Fusion) con Paralells Desktop para Mac. - Ejemplo de empresa que ofrece/utiliza Paas: SAP – Con su Cloud PaaS, que es una plataforma empresarial abierta. Fue diseñado para ayudar a los desarrolladores a crear aplicaciones con mayor facilidad, ofreciendo amplitud y profundidad de servicio. 5. La relación que existe entre ambos es que son dos de los protocolos que se utilizan para el correo de internet. SMTP se emplea para transferir correo desde el servidor de correo del emisor al servidor de correo del destinatario; SMTP también se utiliza para transferir correo desde el agente de usuario del emisor al servidor de correo de este. Para transferir los mensajes de correo almacenados en el servidor de correo del destinatario al agente de usuari o de este se emplea un protocolo de acceso a correo, como IMAP. En este sentido, SMTP es el protocolo encargado de enviar y recibir, es decir de realizar la transferencia de todos los mensajes de correo electrónico. Por otra parte, el protocolo IMAP, es el encargado de almacenar todo el correo hasta que este sea leído, después de haber sido recibido mediante el protocolo SMTP.

Comandos SMTP: - MAIL FROM; Para indicar quien envía el mensaje. - SEND; Inicia una transacción en la cual el mensaje se entrega a una terminal. - SAML; El mensaje se entrega a un terminal y a un buzón.

PEC 2 RAI 2020-21/2 Comandos IMAP: - IMAP_GetPrefs; Devuelve las preferencias actuales para los comandos IMAP. - IMAP_Login; Conecta al usuario al servidor de correo IMAP con el nombre de usuario y contraseña dados. - IMAP_MsgLst; Para obtener información específica sobre el contenido de los buzones. A pesar de que el HTTP no se usa exclusivamente para la transferencia de correo, desempeña un papel de vital importancia para los usuarios que utilizan navegadores de Internet para acceder a su correo electrónico (tanto para enviar como recibir). Hotmail y Yahoo! utilizan el protocolo HTTP para acceder a los mensajes de correo electrónico a través de Internet. 6. S: 220 uoc.edu Simple Mail Transfer Service Ready C: EHLO relay.uoc.e

EHLO greeting: Especificación de la extensión SMTP para pedir al servidor qué extensiones SMTP soporta.

S: 250-uoc.edu, I am glad to meet you

250: OK ('-' significa que continúa)

S: 250-8BITMIME

250: OK-soporta transmisión de datos MIME8 bits

S: 250-SIZE

250: OK-soporta Message size declaration

S: 250-DSN

250: OK-soporta Delivery status notification

S: 250 HELP

250: OK-soporta Help

C: MAIL FROM:

El cliente notifica al receptor de las direcciones de correo originadores del mensaje.

S: 250 OK

250: OK

C: RCPT TO:

El cliente envía un forward-path (un buzón y un dominio, entre “”). Para indicar el destinatario del mensaje

S: 250 OK

250: OK

C: RCPT TO:

Para indicar el destinatario del mensaje

S: 250 OK

250: OK

C: DATA

Inicio de transmisión de datos, comienzo del mensaje

S: 354 Start mail input; end with .

354: Inicio mail de entrada

C: Date: Mon, 21 Feb 2022 05:33:29 -0700

Fecha

PEC 2 RAI 2020-21/2 C: From: Lecturers UOC

Emisor

C: Subject: Welcome to the semester

Asunto del mensaje

C: To: [email protected]

Receptor(es)

C:

Separador entre cabecera y cuerpo del mensaje

C: Hello,

Inicio del cuerpo del mensaje

C:

Separador en el cuerpo del mensaje

C: This is a test message with 4 header fields C: and 8 lines C: in the message body. C:

Separador en el cuerpo del mensaje

C: Happy semester, C: UOC Lecturers C: .

.: Final de los datos y del cuerpo del mensaje

S: 250 OK

250: OK

C: QUIT

Petición de cierre de sesión

S: 221 bye Service closing transmission channel

221: OK, operación de cierre de conexión concluida con éxito.

La repetición de la información sobre el emisor y el receptor se debe a que unas líneas de la captura son las peticiones y respuestas que se intercambian entre ellos el cliente y el servidor (siguiendo el protocolo SMTP), donde encontramos el “MAIL FROM” y el “RCPT TO”, y la otra la información que hay dentro del mensaje en sí, donde encontramos los campos “From:” y “To:”. Otra cosa es que los servidores intermedios lean las cabeceras del mensaje para generar las llamadas SMTP. El funcionamiento de SMTP se puede resumir de la siguiente manera: * Cuando un cliente establece una conexión con el servidor SMTP, espera a que este envíe un mensaje “220 Service ready” o “421 Service non available”. * Se envía un HELO desde el cliente. Con ello el servidor se identifica. Esto puede usarse para comprobar si se conectó con el servidor SMTP correcto. * El cliente comienza la transacción del correo con la orden MAIL FROM. Como argumento de esta orden se puede pasar la dirección de correo al que el servidor notificará cualquier fallo en el envío del correo (Por ejemplo, MAIL FROM:). Luego si el servidor comprueba que el origen es válido, el servidor responde “250 OK”.

PEC 2 RAI 2020-21/2 * Ya le hemos dicho al servidor que queremos mandar un correo, ahora hay que comunicarle a quien. La orden para esto es RCPT TO:. Se pueden mandar tantas órdenes RCPT como destinatarios del correo queramos. Por cada destinatario, el servidor contestará “250 OK” o bien “550 No such user here”, si no encuentra al destinatario. * Una vez enviados todos los RCPT, el cliente envía una orden DATA para indicar que a continuación se envían los contenidos del mensaje. El servidor responde “354 Start mail input, end with .” Esto indica al cliente como ha de notificar el fin del mensaje. * Ahora el cliente envía el cuerpo del mensaje, línea a línea. Una vez finalizado, se termina con un . (la última línea será un punto), a lo que el servidor contestará “250 OK”, o un mensaje de error apropiado. * Tras el envío, el cliente, si no tiene que enviar más correos, con la orden QUIT corta la conexión. También puede usar la orden TURN, con lo que el cliente pasa a ser el servidor, y el servidor se convierte en cliente. Finalmente, si tiene más mensajes que enviar, repite el proceso hasta completarlos. 7. a.

Consulta tipo A, Tiempo de respuesta = 44 msec para la consulta de dig y sin especificar para la consulta de nslookup. DIG es un servicio para buscar información en el DNS (Domain Name System [RFC1034, RFC1035]), al igual que nslookup. Básicamente, DNS asigna nombres de dominio a direcciones IP. Dig realiza consultas iterativas para resolver el nombre que se busca. Seguirá las referencias de los servidores raíz, mostrando la respuesta de cada servidor que se utilizó para resolver la búsqueda.

PEC 2 RAI 2020-21/2 b. Se ha utilizado TCP. c. Se encuentran activados los flags dns: qr (query/response), rd (recursion desired) y ra (recursion allowed), como se puede observar en la petición DIG. d. No hay varios registros NS en nuestra consulta. Sin embargo, a menudo el dominio tendrá múltiples registros de NS que pueden indicar servidores de nombres primarios y auxiliares de ese dominio, para aumentar su fiabilidad: si un servidor de nombres se cae o no está disponible, las consultas de DNS pueden ir a otro. Cuando se utilizan varios servidores de nombres (como en la mayoría de los casos), los registros NS deben enumerar más de un servidor. e. Si cambiamos la consulta a “ANY”, para este caso, obtenemos la misma información. La diferencia es que en la consulta realizada los registros consultados pueden ser: - A: IPv4 de un dominio. - ANY: Cualquier tipo de registro. Si se utiliza la opción “ANY” se incluirán en los resultados de la consulta todos los tipos de registros disponibles asociados con un dominio. f. Consulta de tipo de registro “MX” (obtiene solo el intercambio de correo):

PEC 2 RAI 2020-21/2 Ambas consultas reportan la misma información pero con formato diferente. Algunos de los campos que se especifian con el tipo “MX” son: * : nombre de la zona * : clase de red * : tipo de registro * : nombre del master (servidor maestro) * : dirección de correo electrónico del administrador encargado * : número de serie del archivo de zona, que aumenta con cada actualización * : tiempo en el que un servidor esclavo tiene que solicitar al servidor maestro una actualización * : tiempo en el que un esclavo ha de repetir el intento tras una solicitud fracasada * : tiempo a partir del cual un esclavo deja de dar información al exterior si el master sigue sin dar respuesta * : tiempo durante el cual la información puede ser almacenada en la memoria caché g. Consulta: dig www.bancsabadell.com MX Servidor: ns1.as60813.net. 8. NO VÁLIDA – REPETIDA 9. Para poder afrontar el desafío de distribuir cantidades masivas de datos de vídeo a usuarios dispersos por todo el mundo, casi todas las principales empresas de flujos de vídeo utilizan redes de distribución de contenido (CDN, Content Distribution Network). Una CDN gestiona servidores situados en múltiples ubicaciones geográficamente distribuidas, almacenas copias de los vídeos (y de otros tipos de contenido web, como documentos, imágenes y audio) en sus servidores y trata de dirigir cada solicitud de usuario a una ubicación de la CDN que proporcione la mejor experiencia de usuario posible. La CDN puede ser una CDN privada, es decir, propiedad del propio proveedor de contenido; o alternativamente, la CDN puede ser una CDN comercial que distribuya contenido por cuenta de múltiples proveedores de contenido. En el libro de Kurose “Computer networking”, apartado 9.2, se indica que los protocolos utilizados para streaming suelen ser HTTP, HTTP (DASH) y en menor medida UDP. Una característica común a los tres tipos de flujos de vídeo es el uso intensivo de buffers de aplicación en el lado del cliente, para mitigar los efectos de la variabilidad en los retardos extremo a extremo y en el ancho de banda disponible entre el servidor y el cliente. También se ven involucrados los protocolos RTP, RTSP, RTCP. - Con UDP, el servidor transmite el vídeo a una velocidad igual a la velocidad de consumo del vídeo por parte del cliente, transmitiendo los fragmentos sobre UDP a una tasa constante. - Con HTTP, el vídeo simplemente se almacena en un servidor HTTP como un archivo normal, con un URL específico. Cuando un usuario quiere ver el vídeo, el cliente establece una conexión TCP con el servidor y emite la solicitud GET HTTP para ese URL. El servidor envía entonces el archivo de vídeo dentro de un mensaje de respuesta HTTP, tan rápidamente como sea posible, es decir, tan rápido como permitan los mecanismos de control de flujo y control de congestión de TCP. - Con HTTP DASH, el vídeo se codifica en varias versiones diferentes, teniendo cada versión una tasa de bits distinta y, por tanto, un nivel de calidad diferente. El cliente solicita dinámicamente segmentos de vídeo de unos pocos segundos de duración. Cuando el ancho de banda disponible

PEC 2 RAI 2020-21/2 es grande, el cliente selecciona de forma natural los segmentos de una versión de alta tasa de bits; y cuando el ancho de banda disponible es pequeño, selecciona de forma natural los segmentos de una versión con menor tasa de bits. Fuentes consultadas: Libro Computer Networking (7a edición). 10. Servicios web implementados con REST: - Last.fm: Last.fm brinda a los usuarios la capacidad de crear programas utilizando datos de Last.fm, ya sea en la web, el escritorio o dispositivos móviles. La API RESTful permite el acceso de lectura y escritura a la lista completa de recursos de datos musicales de last.fm: álbumes, artistas, listas de reproducción, eventos, usuarios y más. Permite a los usuarios llamar a métodos que responden en XML o JSON. - del.icio.us: del.icio.us es un sitio web de marcadores sociales; el uso principal de del.icio.us es almacenar sus marcadores en línea, lo que le permite acceder a los mismos marcadores desde cualquier computadora y agregar marcadores desde cualquier lugar también. En del.icio.us, puede utilizar etiquetas para organizar y recordar sus marcadores, que es un sistema mucho más flexible que las carpetas. La API proporciona acceso de lectura / escritura a marcadores y etiquetas de Delicious a través de una interfaz basada en HTTP. La API RESTful devuelve respuestas en XML. Otro mecanismo para implementar servicios web es SOAP (Simple Object Access Protocol). Características: - Servicio web que utiliza el protocolo SOAP. La solicitud del cliente del servicio web y la respuesta del servicio web son mensajes SOAP. El lenguaje de descripción de servicios web (web service description language, WSDL) es un lenguaje de definición de interfaz basado en XML que describe la funcionalidad de un servicio web. Los archivos WSDL contienen una descripción sobre el método de invocación del servicio web, los parámetros que espera dicho servicio y las estructuras de datos que devuelve. Es posible crear un servicio web SOAP de Informatica a partir de un archivo WSDL. - Se conecta a un servicio web como un cliente del servicio web para acceder a datos o transformarlos durante un proceso de asignación. Es posible crear una transformación de consumidor de servicio web SOAP a partir de WSDL. 11. Cliente/Servidor: es un modelo de aplicación distribuida en el que las tareas se reparten entre los proveedores de recursos o servicios, llamados servidores, y los demandantes, llamados clientes. Un cliente realiza peticiones a otro programa, el servidor, quien le da respuesta. Esta idea también se puede aplicar a programas que se ejecutan sobre una sola computadora, aunque es más ventajosa en un sistema operativo multiusuario distribuido a través de una red de computadoras. P2P: es una red de computadoras en la que todos o algunos aspectos funcionan sin clientes ni servidores fijos, sino una serie de nodos que se comportan como iguales entre sí. Es decir, actúan simultáneamente como clientes y servidores respecto a los demás nodos de la red. Las redes P2P permiten el intercambio directo de información, en cualquier formato, entre los ordenadores interconectados. A continuación se detallan algunas de las ventajas e inconvenientes que presentan ambas arquitecturas:

PEC 2 RAI 2020-21/2 - En la arquitectura cliente servidor los clientes envían peticiones al servidor y esperan una respuesta. - En la arquitectura P2P, el cliente también puede ser servidor y el servidor puede ser cliente. - El ancho de banda en la arquitectura cliente servidor, es bastante amplio pero tiende a congestionarse ya que hay un servidor y muchos clientes; mientras que en la arquitectura P2P hay muchos servidores y los clientes envían muchas peticiones, todos trabajan simultáneamente. - En caso de que se cargue cualquier tipo de información, en la arquitectura C/S se observa que si el servidor quisiera la información que se está cargando se perdería, mientras que en la P2P esta información quedaría prevalente - En el ámbito de las descargas, en la arquitectura C/S son bastante rapidas aunque a veces son lentas porque el servidor solo tiene una o pocas opciones, mientras que en la arquitectura P2P son más rapidas ya que el servidor encuentra varias opciones. - En cuanto a la seguridad, en las arquitecturas cliente servidor al tener un único servidor, es mucho más eficaz, mientras que en la arquitectura P2P hay personas capaces de perjudicar la cuenta de otro cliente. Ejemplos de aplicaciones computacionales que usen el modelo cliente-servidor son: - El Correo electrónico. - U...