‫Instructor: Entonces, nuestro objetivo
‫es desarrollar aplicaciones de back-end con
‫Node y, por lo tanto, probablemente sea
‫una buena idea obtener una comprensión básica de cómo funciona
‫la web detrás de escena, ¿verdad?
‫Y esta será una conferencia realmente completa.
‫Y así que vamos a sumergirnos de lleno.
‫Ahora, para comprender mejor cómo funciona
‫realmente la web, comencemos
‫por hacer la pregunta: ¿Qué
‫sucede realmente cada vez que escribimos
‫una URL en
‫nuestro navegador para abrir una nueva página web?
‫¿O cada vez que solicitamos datos de alguna API?
‫Lo que en realidad es lo
‫mismo, así que centrémonos en un ejemplo simple de un sitio web aquí.
‫Bueno, la respuesta más simple es que nuestro navegador,
‫que también se llama cliente, envía una solicitud al servidor
‫donde está alojada la página web.
‫Y el servidor enviará una respuesta,
‫que contendrá la página web que acabamos de solicitar.
‫Y este proceso se denomina modelo de
‫solicitud-respuesta o también arquitectura cliente-servidor.
‫Y todo lo que vamos
‫a hablar en esta sección gira en torno a este concepto fundamental.
‫Bien, pero demos ahora un paso más porque probablemente
‫esto no sea realmente nuevo para ti
‫en este momento, ¿verdad?
‫Digamos que queremos acceder a Google
‫Maps escribiendo google. com / se asigna a nuestro navegador como URL.
‫Y cada URL obtiene un HTTP o HTTPS, que es
‫para el protocolo que se utilizará
‫en la conexión.
‫Y hablaremos de esto un poco más adelante en este video.
‫Entonces tenemos el nombre de dominio aquí,
‫que es google. com en
‫este caso, y también tras una barra, el llamado recurso
‫al que vamos a
‫acceder, y en este caso, / maps.
‫Ahora, lo que necesita saber aquí es que el nombre
‫de dominio como google. com no es en
‫realidad la dirección real del servidor al que estamos
‫intentando acceder, sino simplemente un bonito nombre que es fácil de memorizar.
‫Entonces necesitamos una forma de convertir el nombre de dominio a
‫la dirección real del servidor
‫y eso sucede a través de un DNS.
‫Entonces, DNS significa Domain Name Server, que
‫son servidores especiales que son básicamente como
‫las guías telefónicas de Internet.
‫Entonces, el primer paso que sucede cuando abrimos un sitio
‫web es que el navegador realiza una solicitud a un DNS
‫y este servidor especial simplemente hará coincidir la
‫dirección web que ingresamos en el navegador con
‫la dirección IP real del servidor.
‫Está bien.
‫Y en realidad, esto
‫sucede a través de su proveedor de servicios de Internet o
‫ISP, pero los detalles completos realmente no nos importan.
‫Lo que debe conservar de
‫esta parte es que el dominio no es la dirección
‫real y que un DNS lo convertirá a esa dirección IP real, a la que
‫un navegador puede llamar después de que se envíe de vuelta
‫a nuestro navegador.
‫Así es como se ve la dirección real,
‫por lo que todavía tiene el protocolo, pero luego viene la dirección IP.
‫Y también el puerto al que accedimos en el servidor.
‫Y el número de puerto es realmente solo
‫para identificar un servicio específico que se ejecuta en un servidor
‫y para que pueda pensar en él como una subdirección.
‫Recuerde cómo escuchamos el puerto 8000 en nuestro
‫servidor web cuando lo configuramos en la intersección que es exactamente
‫lo que es este puerto.
‫También tenga en cuenta que el número de puerto no
‫tiene nada que ver con el recurso de Google Maps
‫al que queremos acceder.
‫Ese recurso realmente se enviará
‫en la solicitud HTTP, como veremos en un momento.
‫Bien, y esto concluye con el primer paso.
‫Entonces, una vez que tenemos la dirección
‫web real, se establece una conexión de socket
‫TCP entre el navegador y
‫el servidor, que ahora finalmente están conectados.
‫Y esta conexión generalmente se mantiene activa durante
‫todo el tiempo que lleva transferir todos
‫los archivos del sitio web.
‫Ahora bien, ¿cuáles son nuestros TCP e IP?
‫Bueno, TCP es el Protocolo de control de transmisión e IP
‫es el Protocolo de Internet,
‫y juntos son protocolos de comunicación que definen
‫exactamente cómo viajan los datos a través de la web.
‫Entonces, son
‫básicamente el sistema de control fundamental
‫de Internet, porque, nuevamente, son ellos quienes establecen las reglas
‫sobre cómo se mueven los datos en Internet.
‫Y no se preocupe, aprenderemos un poco más sobre TCP / IP
‫más adelante en este video.
‫De todos modos, ahora es el momento de hacer finalmente nuestra solicitud.
‫Y la solicitud que hacemos es una
‫solicitud HTTP donde HTTP significa Protocolo de transferencia de hipertexto.
‫Entonces, después de TCP / IP, HTTP es otro protocolo de comunicación.
‫Y, por cierto, un protocolo de comunicación es
‫simplemente un sistema de reglas
‫que permite que dos o más partes se comuniquen.
‫Y en el caso de HTTP, es solo un protocolo
‫que permite a los clientes y servidores web comunicarse
‫enviando solicitudes y mensajes de respuesta de
‫cliente a servidor y viceversa.
‫Ahora, un mensaje de solicitud se verá así.
‫Entonces, el comienzo del mensaje es la parte más
‫importante llamada línea de inicio, que contiene el método HTTP que
‫se usa en la
‫solicitud, luego el destino de la solicitud y la versión HTTP.
‫Entonces, sobre los métodos HTTP, hay muchos disponibles, pero
‫los más importantes son get
‫para simplemente solicitar datos, publicar para enviar datos y
‫poner y parchear para modificar básicamente los datos.
‫Entonces ves que una solicitud HTTP al servidor no
‫es solo para obtener datos, sino que también podemos enviar datos.
‫¿Está bien?
‫Ahora, por favor, no se preocupe si todo esto le
‫suena demasiado en este momento.
‫Por supuesto, usaremos estas cosas
‫durante el resto del curso, que en
‫realidad es la razón por la que les digo esto.
‫De todos modos, sobre el destino de
‫la solicitud, aquí es donde se piensa que el servidor
‫queremos acceder al recurso de mapas en este ejemplo.
‫¿Recuérdalo?
‫Así que teníamos / maps en nuestra URL y ahora se
‫envía como destino en la solicitud HTTP
‫para que el servidor pueda averiguar qué hacer con él.
‫Y si esto está vacío, entonces si fuera solo una barra, básicamente,
‫estaríamos accediendo a la raíz del sitio
‫web, que sería solo Google. com en este ejemplo.
‫Luego, la siguiente parte de la solicitud son los encabezados de
‫la solicitud, que son solo información que
‫enviamos sobre la solicitud
‫en sí, y hay toneladas de encabezados diferentes
‫disponibles, como qué navegador se usa para
‫realizar la solicitud, a qué hora, el idioma del usuario y muchos, muchos otros.
‫Finalmente, en el caso de que enviemos datos al
‫servidor, también habrá un cuerpo de
‫solicitud que contenga esos datos, por ejemplo, provenientes de un formulario HTML.
‫Entonces esa es la solicitud HTTP.
‫Ahora, por supuesto, no somos
‫nosotros los desarrolladores los que escribimos
‫manualmente estas solicitudes, pero sigue siendo extremadamente
‫importante que comprenda cómo se ven una solicitud HTTP y también
‫una respuesta porque trabajará mucho con ellas, ¿de acuerdo?
‫Además, quiero mencionar que también existe HTTPS, como
‫probablemente sepa.
‫Y la principal diferencia entre HTTP y HTTPS es
‫que HTTPS está encriptado usando TLS o SSL, que son algunos
‫protocolos más, pero no
‫los voy a aburrir con estos.
‫Pero además de este cifrado adicional,
‫la lógica entre las solicitudes y respuestas HTTP
‫todavía se aplica a HTTPS.
‫De acuerdo, nuestra solicitud ahora llega al servidor, que estará trabajando
‫en ella hasta que tenga nuestro sitio web listo para
‫enviar de vuelta.
‫Y lo enviará de vuelta usando, como puede
‫adivinar, una respuesta HTTP.
‫Y el mensaje de respuesta HTTP en realidad
‫se parece bastante a la solicitud.
‫Lo mismo ocurre con una línea de salida, encabezados y un cuerpo.
‫La línea de salida tiene, además de la versión HTTP, un
‫código de estado y un mensaje.
‫Entonces, básicamente, para que el
‫cliente sepa si la solicitud ha sido exitosa o no.
‫Este 200, por ejemplo, significa correcto, y
‫el que todos conocen es el código de estado 404,
‫que significa no encontrado.
‫Y aquí es de donde proviene este código
‫404 que ya conocías.
‫Luego, los encabezados de respuesta o información sobre
‫la respuesta en sí.
‫Así que, como antes, hay una tonelada disponible
‫y también podemos crear nuestros propios encabezados.
‫Ahora, lo que es diferente acerca de los encabezados
‫de respuesta es que en realidad es el desarrollador de
‫back-end como usted quien los especifica y los envía de vuelta en la respuesta.
‫Está bien.
‫Finalmente, la última parte de la respuesta
‫es, nuevamente, el cuerpo, que en realidad está presente en la
‫mayoría de las respuestas.
‫Y también es el desarrollador quien envía específicamente
‫el cuerpo en la respuesta.
‫Y de hecho ya hicimos esto en la intersección
‫usando la respuesta. final, recuerdas?
‫Y el cuerpo generalmente debe contener el HTML del
‫sitio web que solicitamos o, por ejemplo, datos JSON
‫provenientes de una API o algo así.
‫Así que hablamos en gran detalle
‫sobre las partes más
‫importantes aquí, que son la solicitud HTTP y la respuesta.
‫Pero en nuestro ejemplo imaginario, solo hicimos una solicitud
‫a Google. com y obtuve una respuesta.
‫Sin embargo, si es un sitio web al
‫que intentamos acceder, habrá muchas, muchas más solicitudes y respuestas.
‫Y eso se debe a que cuando hacemos la
‫primera solicitud, todo lo que obtenemos es solo el archivo HTML
‫inicial, ese archivo luego se escaneará en busca de
‫todos los activos que necesita para construir
‫el sitio web completo, como JavaScripts, archivos CSS, archivos de imagen u otros. activos.
‫Y para cada uno de
‫estos archivos diferentes, el navegador realizará una nueva solicitud HTTP al servidor.
‫Entonces, básicamente, todo este intercambio entre
‫el cliente y el servidor que acabo de
‫explicar ocurre para cada
‫archivo que se incluye en el sitio web.
‫Sin embargo, puede haber varias solicitudes y respuestas
‫al mismo tiempo.
‫Pero la cantidad es realmente
‫limitada porque, de lo contrario, la conexión comenzaría a ralentizarse.
‫De acuerdo, y finalmente, cuando todos los archivos han llegado, el sitio
‫web se representa en
‫el navegador de acuerdo con las especificaciones HTML, CSS y
‫JavaScript que quizás ya conozca.
‫Y ahora, como pieza final de este rompecabezas,
‫hablemos de nuevo sobre TCP / IP y descubramos
‫cómo se envían realmente los datos de solicitud y respuesta
‫a través de la web.
‫Por eso dijimos antes que TCP e IP son los
‫protocolos de comunicación que definen cómo
‫viajan los datos a través de la web.
‫No voy a entrar en muchos detalles aquí, pero
‫esto es lo que necesita saber.
‫Primero, el trabajo de TCP es dividir las solicitudes
‫y respuestas en miles de pequeños fragmentos llamados paquetes antes de
‫que se establezcan.
‫Luego, una vez que lleguen a su destino,
‫volverá a ensamblar todos los
‫paquetes en la solicitud o respuesta original
‫para que el mensaje llegue al
‫destino lo más rápido posible, lo que no sería
‫posible si enviáramos el sitio web como una gran parte.
‫Así que sería como intentar atravesar
‫el tráfico de baile con el autobús más grande
‫que puedas imaginar.
‫Entonces, no es una buena idea.
‫Ahora, en la segunda parte, el trabajo del protocolo
‫IP es enviar y enrutar todos estos paquetes a
‫través de Internet.
‫Por lo tanto, asegura que todos lleguen al
‫destino al que deben ir utilizando direcciones IP en cada paquete.
‫Y nuevamente, esta es solo una descripción general muy amplia de
‫lo que realmente sucede detrás de la escena de la
‫web, porque en realidad es demasiada información de la
‫que realmente necesita para convertirse
‫en un gran desarrollador de back-end.
‫Pero espero que aún encuentre esta
‫información útil e interesante, y tampoco demasiado confusa.
‫Ahora, en el siguiente video, haremos
‫algunas solicitudes HTTP para que se familiarice un poco con
‫el protocolo.