¡Hola todos! En el último video vimos cómo Internet está organizado en capas. En este video, vamos a hablar de la primera capa: la capa de aplicación. 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 hicieron su aparición un montón de aplicaciones muy diferentes como VoIP, streaming de películas, juegos online 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 brindando información a los clientes Entonces los clientes nunca se comunican directamente entre ellos, siempre lo hacen a través de un servidor Por otro lado, en un aplicación peer-to-peer todos los hosts son del mismo tipo: peers Entonces 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 ventajas y desventajas algunas aplicaciones funcionan mejor con un arquitectura cliente-servidor y otras mejores con una arquitectura peer-to-peer ahora vamos a ver 2 ejemplos de aplicaciones cliente-servidor y 1 ejemplo de aplicación peer-to-peer.
Empecemos por la aplicación más famosa: la web. La 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 quiere 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 (iniciar sesión, por ejemplo), utilizará la palabra clave ' POST' De esta manera 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 informarle cómo fue la solicitud. Si todo salió bien, enviará un 200 Código de estado Ok Si la página solicitada por el cliente no existe, enviará un 404 no encontrado que probablemente ya hayas visto, hay muchos códigos de estado HTTP, 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 lado del servidor 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 mediante correos electrónicos. Si Didier quiere enviar un correo electrónico a Oscar pero la computadora de Oscar está apagada. No puede hacerlo directamente, por lo que 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.
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 correo. servidor, yo estoy usando el servidor de correo de epfl con telnet en el puerto 25, luego explicaré que es un número de puerto Empezamos con el comando HELO para presentarnos, yo uso HELO informateur Una vez hecho debemos decir con a 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 electrónico, usamos el comando RCPT TO Una vez hecho el servidor responde nuevamente con un 250 Ok Ahora usamos el comando DATOS para decir el contenido del correo electrónico Responde con un 354 adelante y enviamos el contenido del correo electrónico, yo solo escribo "hola" " Cuando hayamos terminado ponemos un punto y usamos el comando SALIR.
Después de este ejemplo concreto, si estuviste atento habrás notado una falla de seguridad en SMTP pero te contaré más en el módulo de seguridad. Pasemos ahora a un peer- Aplicación to-peer: intercambio distribuido de archivos con BitTorrent Probablemente todos conozcáis este protocolo y estoy seguro de que lo usáis de forma totalmente legal. Esta aplicación permite compartir un archivo entre usuarios sin necesidad de un servidor. El protocolo BitTorrent es muy complejo, con varios mecanismos Así que lo presentaré aquí de una manera muy superficial. Cuando descargas un archivo torrent de un sitio web, comienzas registrándote en una computadora llamada "rastreador". Te enviará una lista de todos los pares que desean compartir este archivo. está dividido 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é pares tiene qué fragmentos, elegirá un fragmento que no tiene.
No lo tienes y solicítalo a un par que lo tenga. Como par, también recibirás solicitudes de otros pares que te piden fragmentos. Según el protocolo BitTorrent, enviarás fragmentos solo a aquellos que te envíen la mayor cantidad de datos. Y de vez en cuando. vez, enviarás un fragmento a un interlocutor aleatorio incluso si él no te envía nada. Ahora introduciré un protocolo algo especial: DNS. No es una aplicación como las demás porque no la usas directamente, incluso si úsalo todos los días DNS es responsable de traducir los nombres de los sitios web a direcciones IP. Por ahora no necesitas saber exactamente qué es una dirección IP, te contaré más en el video de la capa de red. Por ahora, solo necesitas saber eso. es una secuencia de dígitos que identifica 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 saberlo.
la dirección IP de este sitio web. Entonces envía una solicitud 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 Utilizará 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 correspondientes direcciones IP. Pero tendría enormes problemas, como puedes imaginar, todos los usuarios se conectarán a esta misma computadora. Estaría sobrecargado, segundo: no puede estar cerca de todos, ya que tiene que estar en algún lugar del planeta y tercero: si esta computadora falla, Internet no estará disponible para todos. Podemos imaginarnos 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 que conocen esa dirección IP. La solución es organizar DNS en jerarquía Tenemos 3 tipos de servidores DNS: raíz, TLD, autoritativo Actualmente tenemos 13 servidores DNS raíz, la mayoría de ellos ubicados en los Estados Unidos.
Estos servidores DNS raíz conocen las direcciones IP de los servidores DNS de TLD, cada uno de los cuales es responsable. para 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, comience por contactando a un servidor DNS raíz Le preguntas cuál es la dirección IP del servidor TLD responsable del nombre de dominio .com. Él te dará una dirección IP y ahora puedes contactar al servidor TLD para .com. Le preguntas cuál es la dirección IP. del servidor DNS responsable de amazon.com. Te dará la dirección IP de ese servidor DNS y ahora puedes contactar con este servidor DNS y preguntarle cuál es la dirección IP del sitio web www.amazon.com.
Él te responderá con un Dirección IP y puede usar esa dirección IP para realizar 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, entonces 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 accedo a página de bienvenida de Facebook Hay un último aspecto de la capa de aplicación del que quiero hablarte: proxys y cachés Un servidor proxy es un relé al que envías tus solicitudes y luego realiza tus solicitudes por ti.
El punto es almacenar en la memoria. las solicitudes ya ejecutadas, eso es lo que llamamos 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 la memoria y se la 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. 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. quién resuelve todas estas preguntas Ese será el tema de nuestro próximo video ¡ Ahora es el final de este video! Espero que hayas entendido y hayas disfrutado de esta introducción a la capa de aplicación. Por supuesto que tuve que seleccionar entre las aplicaciones, así que no dudes en preguntar en los comentarios si quieres 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!.