¡Hola todos! En el último video vimos cómo se organiza Internet en capas. En este video, vamos a hablar sobre la primera capa: la capa de aplicaciones. Esta capa contiene las aplicaciones que usas todos los días. Directamente en los años 70 se crearon los correos electrónicos y las aplicaciones de transferencia de archivos. Luego, Internet se hizo muy popular en los años 90 con la aparición de la Web. Y a partir del año 2000, aparecieron muchas aplicaciones muy diferentes, como VoIP, transmisión de películas, juegos en línea y, más recientemente, redes sociales. Todas estas aplicaciones son tan diversas que podemos No dice mucho sobre cómo funcionan en general. Sin embargo, podemos dividirlos en 2 categorías: cliente-servidor y peer-to-peer En una aplicación cliente-servidor, todos los hosts se dividen en 2 tipos: los clientes y los servidores Los clientes son las computadoras y teléfonos inteligentes que usas directamente Los servidores son computadoras constantemente en línea las 24 horas del día, los 7 días de la semana, los 365 días del año y que brindan información a los clientes Para que los clientes nunca se comuniquen directamente entre ellos siempre lo hacen a través de un servidor.
Por otro lado, en una aplicación peer-to-peer, todos los hosts son del mismo tipo: pares. Por lo tanto, su computadora es tanto un cliente como un servidor. Todos los hosts se comunican directamente entre ellos sin pasar por un servidor. cada una de estas arquitecturas tiene pros y contras algunas aplicaciones funcionan mejor con una arquitectura cliente-servidor y otras mejor con una arquitectura peer-to-peer ahora vamos a ver 2 ejemplos de aplicaciones cliente-servidor y 1 ejemplo de peer-to -peer application Comencemos con la aplicación más famosa: la web Esta aplicación permite a los clientes recuperar información de los servidores mediante HTTP El servidor envía archivos en diferentes formatos al cliente HTML para la estructura y el texto de una página web CSS para el estilo de la página y javascript para el código que se ejecutará en su computadora Según HTTP, un cliente que desee conectarse a un servidor Web debe enviar una solicitud bien definida, por ejemplo, si desea leer la página bienvenido.html en un sitio web llamado www.unsite.com Deberá enviar la siguiente solicitud: GET www.unsite.com/welcome.html la palabra clave 'GET' significa que el cliente solicita información al servidor por otro lado, si el cliente desea enviar información al servidor (inicio de sesión, por ejemplo ) utilizará la palabra clave 'POST'.
De esta forma, HTTP define varias palabras clave para las comunicaciones entre el cliente y el servidor. HTTP también define muchos códigos de estado que el servidor enviará al cliente para infórmale de cómo fue la solicitud Si todo salió bien enviará un código de estado 200 Ok Si la página solicitada por el cliente no existe enviará un 404 not found que probablemente ya hayas visto, hay muchos estados HTTP códigos si a veces ves un 500, significa que hiciste que el servidor fallara Para manejar estos comandos HTTP, creamos varias aplicaciones en el lado del cliente, eso es lo que llamamos 'navegadores' como Chrome, Firefox, Safari o Internet Explorer y en el servidor lado los más famosos son Apache, Nginx y más recientemente Node js Pasemos a otra aplicación muy famosa: el correo electrónico Considere 2 usuarios Didier y Oscar que quieren comunicarse con correos electrónicos Si Didier quiere enviar un correo electrónico a Oscar pero la computadora de Oscar está apagada Él puede No lo hará directamente, entonces usará el protocolo SMTP Didier usará SMTP para enviar su correo electrónico a su servidor, este servidor luego transferirá el correo electrónico usando SMTP al servidor de Oscar, que está constantemente encendido una vez que Oscar enciende su computadora , se conectará a su servidor usando otro protocolo Entonces, ya sea POP, IMAP o HTTP para pedir su correo electrónico a su servidor SMTP usa reglas muy precisas para las comunicaciones entre clientes y servidores Ahora veremos un ejemplo muy concreto de cómo enviar un correo electrónico con la línea de comando Entonces comenzamos conectándonos a nuestro servidor de correo, yo estoy usando el servidor de correo de epfl con telnet en el puerto 25, luego explicaré qué es un número de puerto Comenzamos con el comando HELO para presentarse, yo uso Hola en formateur Una vez hecho esto, debemos decir con qué dirección de correo de origen queremos enviar este correo electrónico Usamos el comando MAIL FROM e ingresamos nuestra dirección de correo Una vez hecho esto, el servidor responde con un 250 Ok Y ahora debemos decir a quién queremos enviar este correo, usamos el comando RCPT TO Una vez hecho, el servidor responde nuevamente con un 250 Ok Ahora usamos el comando DATA para decir el contenido del correo electrónico Responde con un 354 adelante y enviamos el contenido del correo electrónico, solo ingreso "hola".
Cuando terminemos, ponemos un punto y usamos el comando SALIR. Después de este ejemplo concreto, si estuvo atento, habrá notado una falla de seguridad en SMTP, pero le diré más en el módulo de seguridad Pasemos ahora a una aplicación peer-to-peer: compartir archivos distribuidos con BitTorrent Probablemente todos conocen este protocolo y estoy seguro de que lo usan de forma completamente legal. Esta aplicación permite compartir un archivo entre usuarios sin la necesidad de un servidor. El protocolo BitTorrent es muy complejo, con varios d diferentes mecanismos Así que lo presentaré aquí de una manera muy superficial.
Cuando descargas un archivo torrent de un sitio web, comienzas por registrarte en una computadora llamada "rastreador". Te enviará una lista de todos los compañeros que quieren compartir este archivo. El archivo se divide en diferentes fragmentos. Cada usuario posee diferentes fragmentos en diferentes momentos. Como usuario, se conectará con cada uno de estos pares y les preguntará qué fragmentos tienen. Una vez que sepa qué par tiene qué fragmentos , elegirá un fragmento que no No tienes y pídeselo a un compañero que lo tenga. Como compañero, también recibirás solicitudes de otros compañeros que te pidan fragmentos.
Según el protocolo BitTorrent, enviarás fragmentos solo a aquellos que te envíen más datos. De vez en cuando, enviarás un trozo a un compañero aleatorio incluso si no te envía nada. Ahora presentaré un protocolo un tanto especial: DNS. No es una aplicación como las demás porque no la usas directamente, incluso si lo usas todos los días DNS es responsi capaz de traducir los nombres de los sitios web a direcciones IP Por ahora no necesita saber exactamente qué es una dirección IP, le diré más en el video de la capa de red Por ahora, solo necesita saber que es una secuencia de dígitos que identifican cada ubicación de la red Dado que no es muy conveniente para los humanos recordar secuencias de números, inventamos nombres para sitios web.
Por ejemplo, cuando envía una solicitud HTTP a www.google.ch, primero debe conocer la dirección IP de este sitio web. Entonces, envía una solicitud de DNS a un sistema DNS, preguntándole cuál es la dirección IP de www.google.ch y los servidores DNS le responden que la dirección IP de www.google.ch es: 187.152.11.2 Luego usará esta dirección IP para conectarse al servidor de google ¿Cómo podemos construir un sistema DNS de este tipo? Podemos imaginar el caso ingenuo: una gran computadora para almacenar todos los nombres y sus direcciones IP correspondientes. Pero tendría enormes problemas, como puede imaginar, cada usuario se conectará a esta misma computadora. Estaría sobrecargado, segundo: no puede estar cerca. todos, ya que tiene que estar en algún lugar del planeta y tercero: si esta computadora falla, Internet no está disponible para todos. Podemos imaginar duplicar esa computadora en todo el mundo. Estos usuarios están cerca del sistema dondequiera que estén. Y si una computadora falla, todavía hay otras computadoras para brindar el servicio Pero ahora, si hay un cambio en una computadora, debemos replicar este cambio en todas las computadoras Además, es un desperdicio almacenar toda la información en cada computadora Podemos concebir distribuir la base de datos entre las diferentes Servidores DNS De esta manera no hay necesidad de replicar los cambios, pero esto crea nuevos problemas.
Si un servidor DNS no conoce la dirección IP de un sitio web, debe preguntar a todos los demás servidores DNS. rs quién sabe esa dirección IP La solución es organizar DNS en jerarquía Tenemos 3 tipos de servidores DNS: raíz, TLD, autorizado Actualmente tenemos 13 servidores DNS raíz, la mayoría de ellos ubicados en los Estados Unidos Estos servidores DNS raíz conocen la IP direcciones de los servidores DNS de TLD, cada uno de los cuales es responsable de un nombre de dominio. Entonces, por ejemplo, tenemos servidores TLD para .com .net .org y cada uno de estos servidores TLD conoce las direcciones IP de algunos servidores DNS autorizados. Entonces, por ejemplo, si desea conectarse a www.amazon.com Comienza contactando a un servidor DNS raíz Le pregunta cuál es la dirección IP del servidor TLD responsable del nombre de dominio .com Él le dará una dirección IP y ahora puede contactar al servidor TLD para .com Le preguntas cuál es la dirección IP del servidor DNS responsable de amazon.com Él te dará la dirección IP de ese servidor DNS y ahora puedes contactar a este servidor DNS y preguntarle cuál es la dirección IP del sitio web www .amazon.com te contestará con una IP y puede usar esa dirección IP para hacer su solicitud HTTP .
Ahora veremos cómo realizar una solicitud DNS para luego acceder a un sitio web. Entonces, por ejemplo, en Linux podemos usar el comando 'nslookup' Aquí tomo el ejemplo de facebook , así que quiero saber la dirección IP de www.facebook.com. Me comuniqué con mi servidor DNS, quien me dice que la dirección IP de Facebook es 31.13.91.36. Ahora puedo copiar esta dirección IP y pegarla en mi navegador y acceder a Facebook. página de bienvenida Hay un último aspecto de la capa de aplicación del que quiero hablarles: proxys y cachés.
Un servidor proxy es un relé al que envía sus solicitudes, luego realiza sus solicitudes por usted. El punto es almacenar en la memoria el solicitudes ya ejecutadas, eso es lo que llamamos un caché Entonces, por ejemplo, si Oscar quiere enviar una solicitud HTTP al servidor www.google.ch Primero envía su solicitud a su servidor proxy, luego el proxy envía la solicitud al servidor de google Cuando recibe la respuesta, la guarda en memoria y envía a Oscar Ahora si Didier quiere ver el mismo sitio web www.google.ch También envía su solicitud al servidor proxy, pero el servidor proxy ya conoce la respuesta guardada en la memoria Por lo tanto, no necesita contactar al servidor de Google y envía directamente la respuesta a Didier en esta presentación de la capa de aplicación, asumimos que cada solicitud llega mágicamente cada vez al destino Eso es porque abstrajimos la siguiente capa, la capa de transporte, que resuelve todas estas preguntas Ese será el tema de nuestro próximo video ¡Ahora es el final de este video! Espero que hayan entendido y disfrutado esta introducción a la capa de aplicación.
Por supuesto, tuve que seleccionar entre las aplicaciones, así que no dude en preguntar en los comentarios si desea un complemento sobre una aplicación que no se presentó o más información sobre una aplicación que fue presentado De lo contrario, ¡nos vemos pronto para otro video sobre la capa de transporte!.