Primeros pasos con HTTP

1. ¡Bienvenido a esta clase!: Hola chicos y bienvenidos a este curso sobre el protocolo HTTP. Mi nombre es Alex y soy ingeniero de software que ha estado escribiendo código utilizado dentro de este protocolo durante los últimos tres años. Cuando oí hablar de la posibilidad de crear un curso para explicar cómo funciona esto, estaba bastante ansioso por desarrollar uno. Esta clase se estructurará en diez lecciones que contienen pasos prácticos para que usted tome con el fin de entender qué es el protocolo HTTP y cómo se puede aprovechar este conocimiento con codificación. A ritmo propio de onda T, te mostraré cómo puedes ver todas las peticiones hechas desde y hacia tu máquina, pero no antes. Voy a explicar lo que nuestros métodos HTTP devuelven códigos manejados de otras cosas. Si te interesa cómo funciona Internet, considera este curso para ti. No hay otros requisitos entonces una conexión a Internet para el proyecto de esta clase, será extremadamente práctico y te implicará seguir los pasos presentados en el curso. Para que puedas empezar en tu viaje de escribir código con un enorme bloque de conocimientos debajo de tu cinturón. Ese es el protocolo HTTP. Pensamos en el set, creo que rara vez nos vemos en la primera lección. 2. Códigos de estado HTTP: Hola chicos, y bienvenidos de nuevo al discurso. En esta conferencia, vamos a echar un vistazo a los códigos de estado HTTP, también llamados códigos de retorno. Estas son una parte fundamental de la comunicación web. La razón por la que estos códigos de datos son tan importantes es porque son emitidos por un servidor en respuesta a la solicitud de un cliente realizada a ese servidor específico y son los datos más relevantes y cortos sobre cómo fue la solicitud. El primer dígito del código de estado especifica una de las cinco clases estándar de respuestas. Las frases de mensaje mostradas son típicas, pero se puede proporcionar cualquier alternativa legible por humanos. Como decía, los códigos de retorno HTTP tienen tres dígitos. Si estos tres dígitos empiezan por uno, el estado que está recibiendo es informativo, es decir, que se recibió la solicitud Si comienza con dos, significa que la solicitud fue una operación exitosa, es decir, fue recibida, entendida y aceptada satisfactoriamente . Con tres, significa una redirección, ya que en nuevas acciones, se necesita tomar para completar la solicitud Si comienza con cuatro, significa que su solicitud tuvo un error de cliente. Algo salió mal en el lado del cliente y la solicitud contiene mala sintaxis o simplemente no se puede cumplir. Por último, si tu código de tres dígitos comienza con el dígito cinco, significa que tu solicitud tuvo un error en el servidor. Algo salió mal en el lado del servidor, como en, el servidor puede no cumplir con una solicitud aparentemente válida. Ahora vamos a abrirnos paso a través de las diferentes categorías de respuestas y enumeremos algunos ejemplos para cada una de ellas. Para respuestas informativas, tenemos el código 100 con la palabra clave continue Esto significa que el servidor ha recibido los encabezados de solicitud y el cliente debe proceder a enviar el cuerpo de la solicitud. Este código se utiliza en situaciones en las que el servidor necesita confirmar que está dispuesto a aceptar la solicitud. Por ejemplo, un usuario puede enviar un archivo grande para subirlo a un servicio de intercambio de archivos. Piensa en transferimos, el servidor responde con 100 continuum para indicar que está listo para recibir este archivo grande y el usuario puede proceder con la subida real At respuestas informativas También tenemos 11 con las palabras clave de protocolos de conmutación. El servidor está indicando aquí un cambio en el protocolo como el cambio de HTTP a socket web. El cliente debe seguir este nuevo protocolo para una mayor comunicación. Para la siguiente categoría, tenemos respuestas exitosas, y aquí tenemos un código muy conocido, que es 200, seguido de la palabra clave de bien. Este es el código de éxito más común, indicando que la solicitud fue exitosa, el servidor ha cumplido con la solicitud y la respuesta contiene los datos o información solicitados. Por ejemplo, piense en un usuario que accede a una entrada de blog, y el servidor responde con un código de estado de 2000 K entregando el contenido del blog solicitado con éxito. También tenemos 21, lo que significa creado. Este código de estado indica que la solicitud resultó en la creación de un nuevo recurso. A menudo se usa con solicitudes post o put. Se puede pensar en un usuario que envía un formulario de registro en un sitio web y el servidor responde con 21 creados, ojalá para indicar que una nueva cuenta de usuario ha sido creada con éxito También en los mensajes de éxito, tenemos 24 para ningún contenido mientras el servidor procesó satisfactoriamente la solicitud. En este caso, no tiene cuerpo de respuesta para enviar de vuelta al cliente. Esto se usa a menudo para las solicitudes de eliminación. Si un usuario elimina un comentario en una plataforma de redes sociales y el servidor responde con 24 sin contenido, confirma la eliminación sin devolver ningún dato redundante adicional Pasando a los mensajes de redirección, tenemos 31 con las palabras clave de movido permanentemente El recurso solicitado se ha movido permanentemente a una nueva URL. El cliente debe actualizar sus marcadores o enlaces en consecuencia Se puede pensar en un sitio web de comercio electrónico que cambie su estructura de URL y el usuario intente acceder a una antigua. Página del producto. El servidor responde con 31 movidos, redirigiendo permanentemente al usuario a la nueva URL del producto También tenemos aquí el código de 34 no modificado. Este estado se utiliza para indicar que la versión del recurso en caché del cliente sigue siendo válida y no es necesario volver a descargarlo Si un usuario accede a un sitio web Us visitado frecuentemente, el servidor, reconociendo que la caché del navegador del usuario está actualizada, responde con estos tres o cuatro no modificados, indicando que la versión en caché sigue siendo válida y no se requieren nuevos datos Para las respuestas de error del cliente, tenemos 400 lo cual es mala solicitud. El servidor no pudo entender la solicitud aquí debido a una sintaxis no válida, parámetros faltantes o tal vez otros problemas en el sitio del cliente. Piense en un usuario que envía una consulta de búsqueda con parámetros no válidos en un sitio de reservas de viajes, y el servidor responde con 400 solicitudes incorrectas para indicar que la solicitud carece de información esencial Además, tenemos 41 para no autorizados. La solicitud requiere autenticación de usuario. El cliente que envía esta solicitud deberá proporcionar credenciales válidas, por ejemplo, un nombre de usuario y contraseña o un token. Todo ello con el fin de acceder al recurso. Por ejemplo, un usuario intenta acceder a un documento privado en un servicio de almacenamiento en la nube sin la autenticación adecuada, el servidor responderá naturalmente con 41 no autorizados pidiéndole al usuario que proporcione credenciales de registro válidas antes recuperar toda la respuesta Por último, tenemos 43 prohibidos. El servidor entendió la solicitud pero se niega a cumplirla. La solicitud del cliente es válida, pero el servidor ha decidido no dar servicio al recurso. Si un usuario intenta acceder a una sección de solo administración de una aplicación web, y el servidor responde con 43 prohibidos, indica que el usuario no cuenta los permisos necesarios para esa acción. Se puede ver que 41 no autorizados se reciben cuando no proporciona ninguna credencial y 43 prohibido se recibe cuando proporciona credenciales, pero no tienen los permisos necesarios adjuntos. También tenemos 44 no se encuentran aquí. El recurso solicitado no se pudo encontrar en el servidor. Indica que la URL no es válida o que el recurso ya no existe. Si un usuario hace clic en un enlace roto que condujo a una página de producto eliminada en un sitio web de comercio electrónico, el servidor responderá con 44 no encontrados, el fin de notificar al usuario que el recurso solicitado ya no existe. Para las respuestas de error del servidor, tenemos 500, que significa Error interno del servidor. Este es un mensaje de error genérico e indica que una condición inesperada impidió que el servidor cumpliera con la solicitud. Es una captura para todos los errores del lado del servidor. Puedes pensar aquí en un usuario que intenta enviar un pedido en una tienda en línea, pero debido a un problema inesperado en el servidor, esta solicitud da como resultado un error interno del servidor 500. Se aconseja al usuario que vuelva a intentarlo más tarde. Además, tenemos 52 para puerta de enlace mala. Este código de estado indica que un servidor que actúa como puerta de enlace o proxy recibió una respuesta no válida de un servidor ascendente, a menudo indica problemas de red. Se puede pensar en un usuario que accede a un servidor web o una API que actúa como puerta de enlace u otro servicio. El servidor de puerta de enlace encuentra un problema al reenviar la solicitud al servidor ascendente, lo que lleva a una respuesta de puerta de enlace de 52 camas. Por supuesto, hay muchos más códigos de retorno que los que enumeré, pero en caso de que te encuentres con uno que no se menciona aquí, puedes buscarlo en Google y estarás seguro de entender exactamente qué pasó con tu solicitud Cuando se trata de la distinción entre métodos HTTP seguros e inseguros, esto no está directamente relacionado con el código de estado HTTP. Los métodos seguros como get and hand están diseñados para no tener un impacto significativo en los recursos. Generalmente se asocian con respuestas exitosas o informativas Mientras que los métodos inseguros como put o post pueden tener una variedad de respuestas dependiendo de la situación específica, incluyendo errores de éxito, cliente y servidor. Como conclusión para esta lección, códigos de retorno HTTP son esenciales para comprender los resultados de las solicitudes HTTP. Proporcionan información sobre el éxito, la redirección, los errores del cliente e incluso los errores del servidor asociados con una solicitud determinada Estos códigos son una parte fundamental del desarrollo web y la resolución de problemas, ya que ayudan tanto a desarrolladores como usted como usuarios a diagnosticar problemas e interpretar los resultados de sus interacciones con Con todo esto dicho, les agradezco chicos que se hayan quedado conmigo hasta el final de esta conferencia, y espero verlos en la siguiente. 3. Métodos de solicitud HTTP: Hola chicos, y bienvenidos de nuevo a este curso. En esta conferencia, veremos un concepto muy importante y que son los métodos HTTP. A menudo se les conoce como verbos HTVP, y son la base de la comunicación entre clientes y servidores en la web mundial Definen las acciones que un cliente puede solicitar a un servidor, que van desde la recuperación de datos hasta la modificación de recursos En esta lección, exploraremos los diversos métodos HTTP, sus ejemplos prácticos y su papel en la comunicación web, así como su clasificación como seguros o inseguros, y el concepto fundamental clave de la potencia del ítem. Para comenzar, primero entremos en el acrónimo C RD. Representa las cuatro operaciones fundamentales para administrar datos en una base de datos o sistema de almacenamiento de datos. Se utiliza comúnmente en el contexto de las bases de datos API y desarrollo de software para describir las acciones básicas que se pueden realizar en los datos. Cada letra en el acrónimo corresponde a una operación específica es para crear. La operación de creación implica agregar nuevos datos, registros o recursos a una base de datos o un almacén de datos. Es la acción de insertar una nueva pieza de información o una nueva entidad. En el contexto de una API, esto generalmente significa enviar una solicitud para crear un nuevo recurso. La letra R es para lectura. Esta operación implica recuperar o acceder a datos de una base de datos o almacén de datos Esta operación no modifica los datos. Se trata de obtener y ver la información existente en las API. Esto suele corresponder al envío una solicitud para recuperar datos de un recurso. U significa actualización. Esto implica modificar los datos existentes en una base de datos. Es la acción de realizar cambios en un registro existente, como actualizarlo, atributos o contenido. En una API, la actualización suele requerir enviar una solicitud para modificar un recurso. D significa eliminación, y esta operación es la acción de eliminar datos, registros o recursos de una base de datos o un almacén de datos. Se traduce en la eliminación permanente de la información especificada en el contexto de las API. Esto corresponde al envío una solicitud para eliminar un recurso. Las operaciones CRUD son fundamentales en la gestión y manipulación de datos Sirven como base para construir e interactuar con bases , servicios web y aplicaciones que realicen estas tareas esenciales. Al diseñar API o trabajar con bases de datos, las operaciones CRUD son un concepto crucial para desarrolladores como usted, ya que proporcionan una forma estandarizada administrar los datos de manera eficiente y precisa Hablamos primero de las operaciones CRUD ya que se entrelazaron con los verbos HTTP de post, desde create, get from read, put from update, and delete, como veremos a continuación Volvamos ahora a los métodos HTTP. En primer lugar, tenemos Get It se utiliza para recuperar los datos de un recurso que probablemente sea identificado por un parámetro ID o una lista general que contenga todos los elementos de ese recurso. Algunas notas sobre las solicitudes de obtención son que se pueden almacenar en caché y marcar como marcadores Permanecen en el historial del navegador y nunca deben usarse cuando se trata de datos confidenciales. Además, tienen algunas restricciones en cuanto a la longitud, como he dicho al definirlos. Se utilizan únicamente para recuperar datos y no modificarlos en ninguna forma o forma. Imagine que está utilizando un navegador web para acceder a un sitio web de noticias en línea. Al hacer clic en un artículo de noticias, su navegador envía una solicitud de obtención al servidor de sitios web solicitando el contenido del artículo. El servidor responde enviando de vuelta el artículo solicitado, permitiéndole a usted, el cliente, leerlo. A continuación tenemos post. Este método HTTP crea un nuevo recurso y lo envía para que sea procesado por el servidor. No es seguro y puede tener efectos secundarios en el servidor o en el recurso. Algunas observaciones cuando se trata de métodos post son que a diferencia de los métodos get, no se pueden almacenar en caché, marcar, o incluso en el historial del navegador Y además no tienen ninguna restricción en la longitud. Además, el botón Atrás, si se pulsa en la solicitud posterior, volverá a enviar los datos A diferencia de una solicitud Get donde no hará daño para un escenario de la vida real. Aquí imagina que estás usando una aplicación de redes sociales y decides crear una nueva publicación. Al hacer clic en el botón de publicación real, la aplicación envía una solicitud de publicación al servidor, incluyendo el texto y cualquier medio adjunto. El servidor procesa tu solicitud, guarda la publicación y Visible para tus seguidores. A continuación tenemos el método HTTP put. Esto actualiza un recurso especificado, lo que significa que reemplaza todas las representaciones actuales del recurso de destino con la carga útil de la solicitud. La principal diferencia a la hora de los métodos post y put son los resultados que obtienes al hacerlos repetidamente una y otra vez. Si bien el método put siempre producirá el mismo resultado ya que actualiza un recurso una y otra vez, el método post tendrá efectos secundarios si se intenta introducir dos veces la misma entidad en un sistema. Imagina que tienes un blog personal y notas un error tipográfico en uno de tus artículos publicados Utiliza un sistema de gestión de contenido y haces correcciones al contenido de los artículos. Al guardar los cambios, el CMS envía una solicitud put para actualizar el artículo en el servidor, asegurando que ahora se muestre la versión corregida. A continuación, tenemos delete. Este método solicita la eliminación de un recurso en la URL especificada. Debería eliminar el recurso si existe. Digamos que tienes una aplicación de correo electrónico abierta, como el correo, y quieres desordenar tu bandeja de entrada eliminando un correo electrónico obsoleto Cuando selecciona ese correo electrónico específico y hace clic en eliminar, la aplicación envía una solicitud eliminada al servidor de correo electrónico, que elimina el correo electrónico de su bandeja de entrada. En lo que respecta al parche del método HTTP, se utiliza para aplicar modificaciones parciales a un recurso. A menudo se usa cuando se desea actualizar solo un subconjunto de los datos de recursos. Imagine que está utilizando una aplicación de administración de tareas para realizar un seguimiento de su trabajo. Te das cuenta de que la fecha de vencimiento o una tarea ha cambiado, por lo que abres la aplicación y actualizas solo la fecha de vencimiento sin alterar ningún otro detalle de la tarea. La aplicación enviará una solicitud de parche al servidor que modifica solo la fecha de vencimiento de la tarea A continuación tenemos cabeza. Head es similar a Get, pero solo solicita los encabezados del recurso. Sin los datos reales, se utiliza para verificar los recursos hechos a datos o existencia sin transferir todo el contenido real. Esto podría usarse por ejemplo, si estarías navegando por un sitio web de compras y quieres comprarle producto. Antes de ver los detalles del producto, hace clic en el botón Verificar Disponibilidad. El sitio web envía por adelantado una solicitud al servidor solicitando datos formalizados como disponibilidad del producto, precio e información de stock, sin cargar toda la página del producto y todos sus detalles correspondientes Por último, tenemos el método HTTP de opciones. Este método recupera información sobre las opciones de comunicación disponibles para un recurso Permite a un cliente descubrir qué métodos HTTP son compatibles con el servidor. Si estás construyendo una aplicación web y necesitas determinar qué acciones son compatibles con un servicio web, entonces este método HTTP es crucial para ti. La aplicación envía una solicitud de opciones al servicio preguntando qué métodos están disponibles para recursos específicos. Esto ayuda a que su aplicación se adapte a las capacidades de los servicios y conozca qué tipo de solicitud puede enviarle. Estos fueron todos los métodos HTTP, pero hay más conceptos clave que hay que entender aquí. A continuación, veamos cómo podemos clasificar un método HTTP. Cuando se trata de estos verbos HTTP, se pueden categorizar ampliamente en dos. En primer lugar, los métodos seguros son aquellos métodos HTTP que están diseñados para no tener un impacto significativo en los recursos a los que se dirigen. decir, cuando se utiliza un método seguro, no debe causar ningún cambio o efectos secundarios en el servidor o en el propio recurso. Los siguientes métodos HTTP se consideran seguros, et no debe alterar el estado del recurso o servidor. Es únicamente para la recuperación de datos. Además, head recupera metadatos sin transferir todo el contenido, haciéndolo de nuevo seguro También tenemos métodos HTTP inseguros. Estos, en contraste, son métodos HTTP que potencialmente pueden conducir a cambios en el estado del recurso o del servidor. No son seguros en el sentido de que pueden tener efectos secundarios como la creación, modificación o eliminación de recursos. Los siguientes métodos HTTP se consideran inseguros. Post no se considera seguro porque a menudo conduce a la creación de un nuevo recurso o a la modificación de uno existente. Ponlo directamente, modifica o crea recursos, y por lo tanto no es un método seguro Eliminar, conduce a la eliminación del recurso especificado, haciéndolo inherentemente inseguro Por último, el parche, aunque es más dirigido que publicar o poner, aún puede alterar los datos de los recursos, convirtiéndolo en un método inseguro. Entremos ahora en el muy importante término de idempotencia en el contexto de los métodos HTTP, idempotensión se refiere a la propiedad de una operación donde realizar la misma acción múltiples veces tiene el mismo efecto Esto significa que si envías una solicitud idempotente varias veces, el estado del sistema y el recurso con el que interactúa deben permanecer sin cambios después de la Echemos un vistazo a algunos ejemplos de métodos HTTP idempotentes El método get, es idempotente cuando se recupera información con una solicitud get Hacer la misma solicitud una y otra vez no debe cambiar el estado del servidor o el recurso que está buscando. El método put también es artículo potente. Si usa put para actualizar un recurso con ciertos datos, enviar la misma solicitud de put varias veces dará como resultado que el recurso contenga los mismos datos cada vez. Por último, tenemos que borrar aquí. Es un método idempotente porque si solicita la eliminación de un recurso usando delete, enviar la solicitud repetidamente no cambiará hecho de que el recurso ha sido eliminado En contraste con los métodos idempotentes, los métodos no idempotentes y tienen diferentes resultados tienen diferentes Por ejemplo, el método post no es idempotente, y las repetidas solicitudes de publicación para crear un recurso pueden conducir a la creación de múltiples recursos idénticos Cada solicitud da como resultado que se agregue un nuevo recurso. Por lo general, la solicitud de parche no es potente para el artículo también. Repetir una solicitud de parche puede actualizar un recurso diferente cada vez si los cambios son incrementales o dependen del estado actual del recurso. Veamos ahora por qué importa la potencia de los artículos. En primer lugar, los métodos potentes del ítem contribuyen a la resiliencia del sistema. En escenarios donde ocurren problemas de red, tiempos de espera o fallas de comunicación, las operaciones potentes de elementos se pueden volver a intentar de manera segura sin causar efectos secundarios no deseados o La potencia del artículo también está estrechamente relacionada con el almacenamiento en caché. Cuando se almacena en caché una respuesta a una solicitud potente de elemento, las solicitudes posteriores se pueden satisfacer desde la caché, lo que reduce la carga en el servidor y mejora el rendimiento Los métodos potentes del ítem aseguran un comportamiento predecible. Los desarrolladores y usuarios pueden confiar en el hecho de que repetir una solicitud no dará lugar a resultados diferentes o cambios inesperados en el estado del sistema. Por último, la potencia del artículo simplifica el manejo de errores. Cuando una solicitud falla o se interrumpe, reintento no introduce inconsistencia ni resultados inesperados En general, a la hora de diseñar APIs, es esencial elegir los métodos HTTP adecuados para diferentes operaciones y documentar el potente comportamiento de su ítem. Esto ayuda a clientes y desarrolladores como tú, entender cómo deben manejarse las solicitudes y qué esperar cuando interactúan con la API. Con todo esto dicho, realmente espero que parte del concepto presentado en esta conferencia te ayude en el futuro. Y espero verte en las próximas conferencias. 4. Depuración de solicitudes HTTP: Hola chicos y bienvenidos de nuevo a este curso HTTP. En esta conferencia, vamos a discutir problemas y la depuración de solicitudes HTTP Porque en mi opinión, al menos como desarrollador, es muy importante entender cómo solucionar y depurar las solicitudes HTTP de manera efectiva Esta habilidad es esencial para garantizar que las aplicaciones web funcionen sin problemas, diagnosticar y solucionar problemas y brindar una experiencia de usuario perfecta Las solicitudes Http están en el centro de cada interacción web, ya sea cargando una página web, enviando un formulario, recuperando datos de un AP I o incluso transmitiendo contenido multimedia Todo comienza con una solicitud HTTP. Sin embargo, estas solicitudes no siempre están libres de errores. Varios factores pueden provocar problemas como errores de configuración del servidor, problemas de red, errores en el sitio del cliente o conflictos entre diferentes componentes Y aquí es exactamente donde entra esta conferencia para ayudarlo a comprender primero los problemas comunes que pueden surgir en solicitudes HTTP es la primera solución de problemas ineficaces. Aquí tenemos cosas como errores del servidor porque los servidores pueden encontrar varios errores como 44, que es el código para no encontrado, 500 para error interno del servidor, o 53, que es el servicio no disponible. Estos errores pueden ser el resultado de servidores mal configurados o problemas de aplicaciones También tenemos errores en el lado del cliente. Los clientes como los navegadores web también pueden generar estos errores, como 400 por mal pedido o 43 para prohibido. Estos suelen ocurrir debido a problemas con la solicitud o permisos del cliente. Los problemas de red son otro factor que puede interrumpir la comunicación entre el cliente y el servidor. Esto incluye problemas como DNS, fallas de resolución, conexiones lentas o incluso interrupciones completas de la red Las violaciones de uso compartido de recursos de origen cruzado también pueden bloquear solicitudes a un dominio diferente. Si no se configura correctamente, esto puede generar problemas de seguridad y funcionalidad. Por último, tenemos errores SSL y TLS. Estas dos capas de seguridad pueden provocar errores. Pueden ocurrir cuando las conexiones HTTP no están establecidas correctamente. Estos errores pueden interrumpir la transferencia segura de datos. Ahora la parte más importante de la lección, la depuración de solicitudes HTTP Esto puede ser un proceso sistemático para identificar y resolver los problemas de manera efectiva. Estos son los pasos a seguir. Primero, revisa las herramientas del desarrollador del navegador. La mayoría de los navegadores web modernos ofrecen herramientas para desarrolladores que le permiten inspeccionar las solicitudes de red. Puede ver solicitudes y encabezados de respuesta, cargas útiles y mensajes de error Esto sucederá en Google Chrome, por ejemplo, si presionas el control F 12 o la función F 12 si estás en una Mac y luego vas a la red. A continuación, debes revisar los códigos de estado HTTP. Estos códigos en la respuesta proporcionan información valiosa sobre el resultado de la solicitud. Familiarícese con los códigos de estado comunes para identificar el problema rápidamente También puede inspeccionar los encabezados de solicitud y respuesta. Preste mucha atención a los encabezados de solicitud y respuesta. Pueden revelar detalles críticos sobre el problema, como tokens de autenticación faltantes, tipos de contenido incorrectos o problemas del curso. A continuación se puede examinar los datos de carga útil es la solicitud implica la transferencia de datos. Inspeccione las anomalías o problemas de carga útil. Los formatos de datos no coincidentes, los datos corruptos o los parámetros faltantes pueden causar problemas También debe verificar los registros del servidor. Los registros del servidor pueden ofrecer información sobre lo que sucede en el lado del servidor. Pueden revelar errores, problemas de rendimiento o, nuevamente, configuraciones erróneas A continuación, puede verificar la conectividad de red, Asegúrese de que su conexión de red en la máquina desde la que está enviando solicitudes sea estable. A veces, los problemas de conectividad intermitentes pueden provocar fallas en las solicitudes. Por último, puede utilizar herramientas de depuración en línea. Varias herramientas en línea están disponibles para probar y depurar solicitudes HTTP Estas herramientas pueden ayudar a simular solicitudes, verificar encabezados y validar respuestas. Aquí algo digno de mencionar es que si estás desarrollando la aplicación web donde está ocurriendo el error HTTP, puedes volver a presionar la función F 12 para entrar en las herramientas del desarrollador del navegador y luego presionar el comando P y buscar el script donde creas que está ocurriendo el error, pon ahí un punto de quiebre, y luego continuar con la depuración lo que puedes hacer refrescando la página. Cuando se trata de herramientas de depuración comunes, hay varias que pueden ayudar depurar solicitudes HTTP Primero, tenemos por supuesto, Cartero. Esta popular herramienta de prueba de API le permite enviar y recibir solicitudes HTTP, inspeccionar encabezados y ver respuestas. A continuación tenemos Curl. La herramienta de línea de comandos es excelente para enviar solicitudes HTTP y ver respuestas en un terminal. También tenemos a Hitler, que es un proxy de depuración web que registra e inspecciona el tráfico HTTP y HTTPS entre la computadora la que está instalada e Por último, tenemos Wireshark, que es un analizador de protocolo de red y puede ayudarlo a solucionar problemas a nivel de red que afectan que es un analizador de protocolo de red y puede ayudarlo a solucionar problemas a nivel de red que afectan las solicitudes HTTP. Cuando se trata de solución de problemas y depuración, colaboración efectiva con su equipo es vital para resolver problemas complejos de solicitudes HTTP Mantenga una documentación exhaustiva de sus hallazgos, incluidos mensajes de error, registros y pasos de depuración Comparta esta información con colegas que puedan ayudar a diagnosticar y solucionar el problema En conclusión, la resolución de problemas y depuración solicitudes HTTP es una habilidad fundamental para los desarrolladores web, ya que HTTP es el protocolo fundamental de las interacciones web Ser capaz de identificar y resolver problemas de manera rápida y efectiva es esencial para ofrecer aplicaciones web confiables y una experiencia de usuario perfecta. Mediante el uso de herramientas para desarrolladores, examinando códigos de estado, inspeccionando encabezados y cargas útiles, comprobando los registros del servidor y utilizando herramientas de depuración Los desarrolladores como tú pueden diagnosticar y solucionar problemas de solicitudes HTTP mientras mantienen sus aplicaciones funcionando sin problemas. Con todo esto dicho, les agradezco muchísimo a ustedes que se hayan quedado conmigo hasta el final de esta conferencia. Espero que esto te haya dado una ventaja en la resolución de problemas y depuración de solicitudes HTTP que vendrán de la mano en el futuro Yo era X y espero verte en la siguiente. 5. ¿Qué es HTTP?: Hola chicos y bienvenidos de nuevo a este curso HTTP. En esta primera conferencia, vamos a echar un vistazo al protocolo HTTP y discutir qué es y tener una visión básica también de cómo funciona al comenzar, HTTP es un protocolo que se utiliza principalmente para transferir información en forma de datos a través de la World Wide Web. Forma parte del traje de Protocolo de Internet. Define comandos y servicios utilizados para transmitir datos de páginas web. Se puede pensar en HTTP como la base de la comunicación de datos o la Web mundial. Por supuesto aquí, los documentos de hipertexto incluyen hipervínculos a otros recursos a los que el usuario que los ve puede acceder fácilmente Por ejemplo, con un clic del mouse o tocando la pantalla en un navegador web. El protocolo HTTP está funcionando por un servidor. Modelo de cliente. Un cliente aquí puede ser una computadora doméstica, una computadora portátil o incluso un dispositivo móvil. El servidor HTTP suele ser un host web que ejecuta software de servidor web como IIS Por ejemplo, cuando accede a un sitio web, su navegador envía una solicitud al servidor web correspondiente, y responde con un código de estado HTTP Si la URL es válida y se crea la conexión, el servidor enviará a su navegador la página web en el formato HTML estándar, y también junto con ella, otros archivos relacionados. Otra nota, digna de observación aquí, sería que el HTTP es un sistema de respuesta a solicitudes sin estado La conexión se mantiene entre el cliente y el servidor solo para la solicitud inmediata. Entonces después de que se cumpla esa solicitud, se cierra la conexión. Después de que el cliente HTTP establezca una conexión TCP con el servidor y le envíe un comando request, el servidor devuelve su respuesta y cierra la conexión. Ahora, los códigos de retorno HTTP más comunes se encuentran entre los de 200. Eso significa que existe una solicitud exitosa, también conocida como la página web también conocida como la página web a la que intentas acceder. Entonces tenemos el código de estado 31, que significa movido permanentemente, y que a menudo se reenvía a una nueva URL cuando se recibe este código. Entonces tenemos 41, que significa la solicitud no autorizada, y básicamente necesitas autorización para superar este punto. Si estás intentando acceder a esa URL, también puedes tener un cuatro oh tres lo cual está prohibido, lo que significa que el acceso no está permitido a la página o directorio al que intentas acceder a través de URL. Y por último, también hay 500 que representan el error del Servidor Interno, y eso suele ser utilizado por una configuración incorrecta del servidor. Http también define comandos, y esto puede ser en la línea de get y post, que se utilizan para manejar el envío de formularios en sitios web. Las conexiones HTTP cifradas se realizan a través de HTTPS, una extensión de HTTP diseñada para la transmisión segura de datos. Esta conexión segura se pone a disposición mediante cifrado utilizando el certificado SSL. El SSL proviene de capa de sockets seguros y también tiene un sucesor hoy en día, que se llama LS, también conocida como la seguridad de la capa de transporte. Se trata de protocolos para establecer enlaces autenticados y cifrados entre redes y computadoras Aunque el protocolo SSL quedó desaprobado con el lanzamiento de la primera versión de LS, todavía es común referirse a esta tecnología relacionada como SSL o SSL Hoy en día, la versión más actual es TLS 13. te preocupes por SSL y HTTPS por ahora, ya que esta conferencia es solo una visión general y en una conferencia posterior, vamos a tomar un enfoque más detallado de todo el protocolo HTTPS. Las diferencias entre el HTTP y HTTPS y así sucesivamente, para que entiendas en profundidad estas nociones. Por ahora, vamos a iterar a través de las nociones una vez más En el protocolo de HTTP, hay dos entidades. El cliente, que es su navegador web de inicio, y el servidor web real. Estos dos pueden comunicarse, más específicamente por el cliente haciendo solicitudes al servidor web y el servidor enviando respuestas de vuelta. Esta comunicación está estructurada en trozos, llamados mensajes en contraposición a un flujo continuo de datos En la próxima conferencia, vamos a echar un vistazo al HTTP, los componentes clave y la estructura del mismo. Entonces, si eso suena interesante, espero verlos ahí, chicos. Y muchas gracias por seguir conmigo hasta el final de esta conferencia. 6. Componentes de HTTP: Hola chicos, y bienvenidos de nuevo al curso HTTP. En esta conferencia, vamos a un vistazo más de cerca a cuáles son exactamente los principales componentes clave en el protocolo HTTP. Considero que este es un factor clave para que podamos entender exactamente cómo está funcionando todo este protocolo. Ahora, por supuesto, hay más entidades que solo el cliente y el servidor. En esta conferencia, vamos a echarles un vistazo ya sea si hay otros servidores de autorización como es el caso en el protocolo 00 a ese O, o si hay otros routers o módems y así sucesivamente Como colectivo, estas entidades entre el cliente y el servidor web que son después de todo, los dos actores principales en este protocolo HTTP. Todas las demás entidades se denominan proxies. Ahora, la entidad más importante del protocolo HTTP es el usuario, también llamado cliente. Este usuario accede a un sitio web en Internet y lo hace mediante el uso de una herramienta que está actuando en nombre de él y se llama navegador web, como ya sabrás. O un agente de usuario en términos específicos. En este usuario puedes pensar en ti mismo en casa operando en tu propia máquina. Cuando abres Google Chrome y escribas cualquier URL de Facebook o alguna plataforma de redes sociales a la que intentas acceder, eres el usuario la parte más importante de este protocolo HTTP. Ahora bien, en todo este proceso, cada vez que el navegador es el que inicia la solicitud y nunca el servidor web al que le haces la solicitud. Ahora, puede observar que usted es el que hizo la cuenta de redes sociales y usted es el que la está revisando. Todo el proceso viene de usted, del cliente, y también de la herramienta que está utilizando. Es decir, como he mencionado antes, el navegador web de su máquina. Ahora, cuando se le dé la tarea de mostrarle la página de Internet que solicitó con su navegador. Su navegador tiene la tarea de recuperar el documento HTML que representa este sitio web que solicitó del servidor. Incluso puede hacer solicitudes adicionales si esa página tiene referencias de otros recursos que necesitan ser recuperados. Por ejemplo, puedes pensar en imágenes, PNGs y demás, pero la respuesta tiene toda la información y el navegador la pondrá todo junto en un documento de HTML que te será mostrado Mirando ahora al otro lado de este intercambio de información que se lleva a cabo en este protocolo, tenemos el servidor web, entidad que proporciona los documentos solicitados por el cliente como respuesta a su solicitud. Lo que hay que entender aquí es que aunque en nuestra conferencia representamos a este servidor web como una sola entidad, en la mayoría de los casos hoy en día, dada la gran cantidad de datos almacenados por las empresas en sus servidores, definitivamente no será así No será una sola entidad detrás del servidor web. Se puede pensar en los datos de las empresas de redes sociales de todos los usuarios que tienen una cuenta con ellas. Y si los usuarios están en millones, puede pensar que sería bastante imposible que todos los datos se guardaran en una sola máquina. El servidor del que estamos hablando que aloja toda la información de los usuarios en realidad está compuesto por una abundancia de máquinas servidor. Entonces, si alguna vez viste almacenes de la empresa donde almacenan sus servidores, pueden estar en películas o simplemente puedes buscar en la web servidores, te mostrará esas enormes salas llenas de servidores web. Entonces sabrás de lo que estoy hablando. Comparten entre ellos la información que almacenan. Por lo que comparten y equilibran toda la carga que tienen entre ellos. Esta multitud de servidores además puede realizar solicitudes a bases de datos que son remotas con el fin de proporcionar el documento final que está siendo solicitado por el cliente. Y en esa base de datos, esa podría ser alguna otra información que puedan interrogar respecto a los usuarios o algún otro campo relacionado con ellos. El último actor en este protocolo son los proxies reales que son, como he mencionado antes, muchas otras máquinas que transmiten a lo largo los mensajes enviados por estos dos actores principales, el cliente y el servidor Estos proxies pueden ser no transparentes o transparentes No transparente significa que pueden alterarlo, y transparente significa que solo están reenviando y no lo están alterando de ninguna forma o forma si lo alteran, por lo que no son transparentes. Pueden hacer muchas cosas como filtrarlo, almacenarlo en caché en tu navegador. O incluso equilibrar la solicitud que hizo el cliente permitiendo que diferentes servidores comiencen a atender diferentes partes de la solicitud. Entonces estos son los componentes clave y los actores principales que están disponibles en el protocolo HTTP. En la próxima conferencia, vamos a echar un vistazo más de cerca a todos los flujos HTTP, cómo este protocolo está funcionando exactamente paso a paso. Gracias chicos por seguir conmigo hasta el final de esta conferencia, y tengo muchas ganas de verles en la siguiente. 7. El flujo de trabajo de HTTP: Hola chicos, y bienvenidos de nuevo a este curso HTTP. En esta conferencia, vamos a echar un vistazo más de cerca al flujo de trabajo HTTP para entender exactamente cómo funciona este protocolo. Podemos hablar sobre el flujo de trabajo que tiene lugar cuando un cliente está haciendo una solicitud hacia el servidor web con el fin de entender mejor el protocolo HTTP. En primer lugar, como he dicho, el cliente abriría una nueva conexión o tal vez re, usaría una abierta al servidor web Esta conexión puede ser de tipo TCP y se utilizará, como habrás adivinado, para realizar la solicitud real al servidor Como puedes ver aquí, nuevamente, el cliente es el que inicia todo el flujo de trabajo como ya comentamos en una conferencia anterior El siguiente paso es enviar el mensaje HTTP, que especifica el recurso desea recuperar como cliente, es decir, la página web a la que está intentando acceder. Una vez que obtenga una respuesta del servidor web, su navegador la leerá y la analizará en un documento HTML que será legible por humanos y estético para que la vea. Por último, la conexión se puede cerrar o utilizar. Además, para otros flujos como el que acabamos de mencionar, claro. Ahora bien, al pensarlo, una observación aquí puede ser que este flujo puede ser ligeramente diferente si estamos familiarizados con el concepto de canalización HTTP y lo que significa la canalización HTTP. Y así es que permite al cliente realizar múltiples solicitudes a diferentes servidores sin tener que esperar primero las respuestas anteriores. Porque este proceso se enseñaba como lineal antes. Pero la canalización HTTP encuentra una solución para todo eso Esta fue una amplia visión general del flujo de trabajo HTTP. En la siguiente conferencia, vamos a discutir qué es una URL y posteriormente cuál es su estructura exacta. Si eso suena interesante, espero verlos ahí, chicos. Muchas gracias por seguir conmigo hasta el final de esta conferencia. 8. Almacenamiento en caché: Hola chicos, y bienvenidos de nuevo al discurso sobre el protocolo HTTP. En esta conferencia, vamos a hablar una estrategia fundamental para optimizar el rendimiento de una aplicación web, y que es el almacenamiento en caché Esto implica almacenar datos y recursos a los que se accede con frecuencia para reducir la necesidad de recuperación de datos redundantes. El resultado es tiempos de carga más rápidos, experiencias de usuario mejoradas y reducción de la carga del servidor. Cuando se trata de la optimización del rendimiento web, caché juega un papel clave Y es un concepto que todo desarrollador web debe entender. Pero antes de entenderlo, hablemos de la necesidad e importancia del almacenamiento en caché Las aplicaciones web se basan en la transferencia de datos entre clientes que suelen ser navegadores web y servidores. Ya hablamos todo este flujo en una lección anterior. Cada solicitud de un recurso como una página HTML, un archivo Javascript o una imagen, requiere un viaje del cliente al servidor y de El tiempo que lleva. Este viaje de ida y vuelta puede afectar significativamente la percepción del usuario sobre la velocidad y la capacidad de respuesta de un sitio web caché aborda este desafío al almacenar copias de recursos en varias ubicaciones, reduce la necesidad de obtener los mismos datos repetidamente Acelera la entrega de contenido al usuario y minimiza la carga en los servidores caché puede ocurrir en diferentes niveles dentro de la arquitectura web Desde el lado del cliente hasta servidores intermediarios y redes de entrega de contenido, también llamadas CDNs Echemos un vistazo ahora a los tipos de almacenamiento en caché que existen. Primero y ante todo, tenemos el almacenamiento en caché del navegador. Los navegadores web mantienen sus cachés locales, donde almacenan recursos como hojas de estilo, imágenes y scripts Cuando un usuario vuelve a visitar un sitio web, el navegador puede recuperar estos recursos de su caché, ahorrando tiempo y también ancho de banda Se puede pensar en una imagen de una página web y se almacena en caché por el navegador del usuario Cuando el usuario navega a otra página del mismo sitio, la imagen se carga desde la caché local, reduciendo la necesidad de una solicitud del servidor El segundo tipo de caché se llama almacenamiento en caché de CDN, o red de entrega de contenido cdns son redes distribuidas de servidores estratégicamente ubicados en diversas ubicaciones geográficas Ellos almacenan en caché y sirven contenido desde ubicaciones cercanas al usuario. Al almacenar y entregar contenido desde servidores H, los CDN pueden reducir significativamente latencia y mejorar los tiempos de carga que experimentará el usuario Un sitio web utiliza una CDN para distribuir sus imágenes. Digamos que cuando un usuario en Europa accede al sitio, las imágenes se entregan desde un servidor CDN cercano en lugar del servidor origen reduciendo el tiempo de carga En tercer lugar, contamos con el almacenamiento en caché de servidores proxy en redes corporativas Los servidores proxy a menudo se emplean para almacenar en caché sitios web externos a los que se accede con frecuencia. Esto no solo mejora el rendimiento, sino que también conserva el ancho de banda al reducir la cantidad de datos obtenidos repetidamente de servidores externos Como ejemplo, el servidor proxy de una empresa almacena en caché sitios web externos a los que se accede con frecuencia, mejorando el rendimiento y por más que eso, ahorrando ancho de banda En HTTP, hay encabezados de caché, SCTP, el protocolo que sustenta La web mundial incluye varios encabezados de almacenamiento en caché que instruyen a clientes e intermediarios sobre cómo almacenar en caché y validar recursos Estos encabezados son cruciales para controlar y optimizar el almacenamiento en caché de los recursos web Estos encabezados son igual que los otros encabezados de los que hablamos, encabezados de autorización y así sucesivamente, encabezados de autorización y así sucesivamente, pero se llaman etiqueta de control de caché y se modifican por última vez, El encabezado de control de caché define directivas para el almacenamiento en caché Como max H para establecer el tiempo máximo que un recurso se considera fresco. Una etiqueta de entidad, representada por el encabezado de etiqueta, es un identificador único para un recurso. Cuando un recurso cambia, la etiqueta cambia, permitiendo a los clientes verificar si el recurso sigue siendo válido. El último encabezado modificado indica el tiempo de última modificación de un recurso. Esto ayuda a los clientes a validar si su copia en caché sigue siendo actual y relevante Cuando se trata de almacenamiento en caché, hay varias estrategias que los desarrolladores podrían aplicar El primero se llama busting de caché, y se emplea cuando los recursos cambian con frecuencia Los desarrolladores pueden Bund números de versión o parámetros de consulta únicos a URL de recursos, lo que obliga a los navegadores a obtener el contenido más reciente A continuación, puede aprovechar las cachés del navegador. Los desarrolladores pueden optimizar las URL de recursos y establecer encabezados de control de caché apropiados para maximizar los beneficios del almacenamiento en caché del navegador Por último, puedes usar CDN. Las redes de distribución de contenido son altamente efectivas para cargar recursos de servidor y entregar contenido para servidores cercanos, mejorando así el rendimiento Hay bastantes beneficios del almacenamiento en caché y la optimización del rendimiento Incluyen una latencia reducida porque el almacenamiento en caché reduce significativamente el tiempo que lleva cargar los recursos, lo que resulta en una experiencia de usuario más rápida Además, minimizan la carga del servidor al servir recursos de almacenamiento en caché Los servidores son relevados de la carga de manejar solicitudes repetidas para el mismo cliente También tendrás ahorro de ancho de banda. almacenamiento en caché conserva el ancho de banda al reducir la cantidad de datos transferidos entre servidores y clientes También hemos mejorado la experiencia del usuario porque los tiempos de carga más rápidos y las aplicaciones más receptivas mejoran la experiencia y satisfacción del usuario. Si bien el almacenamiento en caché y las optimizaciones de rendimiento son altamente ventajosas, existen desafíos y consideraciones a tener en cuenta al implementarlo Primero, debes prestar atención a la experiencia del usuario. Lograr un equilibrio entre la seguridad y la comodidad del usuario es esencial aquí. Las estrategias complejas de almacenamiento en caché a veces pueden disuadir a los usuarios. También es necesario tener en cuenta la complejidad de la implementación adecuadamente. La implementación del almacenamiento en caché, la optimización de las URL de recursos y configuración de encabezados requieren una cuidadosa planificación y consideración En resumen, el almacenamiento en caché es una técnica predominante para optimizar el rendimiento con HTTP Reduce la latencia, conserva el ancho de banda y mejora la experiencia del usuario al aprovechar varios tipos de almacenamiento en caché, encabezados de almacenamiento en caché y estrategias de control de caché Los desarrolladores web pueden crear aplicaciones web rápidas y receptivas que satisfagan las demandas de los usuarios web modernos. En un mundo donde el rendimiento web es un factor crítico en el éxito de aplicaciones como la que vivimos hoy en día, es indispensable dominar el arte del almacenamiento en caché Es una habilidad que puede transformar un sitio web lento en una plataforma rápida y receptiva, plataforma rápida y receptiva, satisfaciendo a los usuarios y reduciendo la carga de los servidores. Tal vez lo encuentres en tu sitio web y espero escuchar las experiencias de tu chico a medida que Internet sigue creciendo y evolucionando. El papel de esta captura en las optimizaciones de rendimiento sigue siendo tan importante como siempre Pero con eso dicho, les agradezco chicos que se hayan quedado conmigo hasta el final de esta conferencia. De veras espero que hayas sacado algo de ello, y espero verte en la próxima. 9. Intercambio de recursos de orígenes cruzados: Hola chicos y bienvenidos de nuevo a este curso HTTP. En esta conferencia, vamos a hablar sobre el intercambio de recursos de origen cruzado. Esta es una característica de seguridad muy importante de las aplicaciones web modernas, permitiendo el acceso controlado a recursos de diferentes dominios. En una era en la que las aplicaciones web interactúan con varios servicios y API a través de Internet, el curso juega un papel fundamental en mantenimiento de la seguridad al tiempo que permite intercambio de datos entre orígenes En los primeros días de la web, los navegadores aplicaban una estricta política de origen mismo. Esto significó que las páginas web sólo podían hacer solicitudes al mismo dominio desde el que se cargaron. Si bien esta política era esencial para la seguridad, se convirtió en una limitación significativa medida que evolucionaron las aplicaciones web. Las aplicaciones web modernas, por otro lado, suelen requerir el acceso a recursos alojados en diferentes dominios. Esto incluye cargar fondos de scripts de Google Images y datos de servidores de terceros y API para abordar esta limitación y habilitar solicitudes de origen cruzado controladas. El curso se introdujo como una característica de seguridad. El curso permite a los servidores web especificar quién puede acceder a los recursos y bajo qué condiciones. Es parte del protocolo HTTP y funciona agregando encabezados HTTP a las respuestas enviadas por servidores web. Estos encabezados transmiten las políticas de los servidores con respecto a las solicitudes de origen cruzado. Echemos un vistazo ahora a los componentes clave. Por supuesto, primero tenemos origen. Qué término se refiere a la combinación de dominio de protocolo y Puerto desde la que se cargó una página web. Por ejemplo, Http, example.com es un origen, mientras que Http example.com y Http sub example.com son orígenes diferentes A continuación tenemos encabezados HTTP. El curso los utiliza para comunicar permisos para solicitudes de origen cruzado. Los encabezados más críticos son el encabezado de origen que es enviado por el cliente para indicar el origen de la página solicitante. control de acceso permite que el encabezado de origen establecido por el servidor especifique qué orígenes están permitidos para acceder a sus recursos. Control de acceso permiten métodos. Encabezado especifica los métodos HTTP get post, put, delete permitidos para solicitud de origen cruzado. Y el control de acceso permite encabezados que enumera los encabezados HTTP que se pueden usar en la solicitud real. Ahora que los encabezados están fuera del camino, echemos un vistazo más de cerca al proceso del curso y qué pasos implica realmente. El primer paso es la solicitud de verificación previa. Cuando una página web realiza una solicitud de origen cruzado con ciertas condiciones, por ejemplo, encabezados o credenciales personalizadas, el navegador envía una solicitud de verificación previa, es decir, una solicitud de opciones HTTP, al servidor de destino Esta solicitud de verificación previa solicita permiso para realizar la solicitud de origen cruzado real A continuación, el servidor de destino responde a la solicitud de verificación previa con encabezados de curso apropiados Si el servidor aprueba la solicitud, incluye encabezados como acceso permiten métodos de control de acceso de origen permiten, y el control de acceso permite encabezados. Por último, si la respuesta del servidor a la solicitud de verificación previa es positiva, el navegador envía la solicitud real al servidor de destino El servidor puede incluir encabezados de curso en la respuesta para indicar si se permite la solicitud de origen cruzado. Elegí hablar de curso en esta conferencia porque es esencial en diversos escenarios del mundo real. Puedes pensar en las API de terceros aquí. Las aplicaciones web a menudo integran servicios de terceros y API para diversas funcionalidades como compartir redes sociales, procesamiento de pagos o servicios de mapeo. El curso permite que estas integraciones ocurran de forma segura. Es posible que los sitios web necesiten cargar recursos como fuentes o scripts de redes de entrega de contenido o servir datos desde servidores remotos. El curso garantiza que el intercambio de datos de origen cruzado sea seguro y controlado. Inicio de sesión único y autenticación. Muchos proveedores de identidad implementan el curso cuatro, soluciones de inicio de sesión único. Permite una experiencia de registro perfecta y segura incluso si el proveedor de identidad reside en un dominio diferente. Por último, el curso también es una parte fundamental de la seguridad web. Al permitir que los servidores definan qué orígenes acceden a su solicitud, ayuda a evitar solicitudes de origen cruzado no autorizadas. Si bien Course mejora la seguridad web, su implementación debe abordarse con cuidado porque en primer lugar, las políticas del curso mal configuradas pueden inadvertidamente vulnerabilidades Por lo que es muy importante validar y probar las configuraciones de los cursos a fondo. Además, no todos los navegadores soportan totalmente curso. Algunos navegadores más antiguos pueden no manejarlo correctamente o tener limitaciones. Los desarrolladores deben ser conscientes de estas limitaciones a la hora de usar el curso. Las solicitudes de verificación previa agregan un viaje de ida y vuelta adicional a las solicitudes de origen cruzado, lo que puede afectar Minimizar las solicitudes de verificación previa es crucial para aplicaciones eficientes. Dicho todo esto, el intercambio de recursos de origen cruzado es una parte integral de la seguridad y funcionalidad web modernas. Permite que las aplicaciones web accedan a recursos y servicios de diferentes dominios manteniendo interacciones controladas y seguras. Los desarrolladores y administradores de servidores necesitan una comprensión sólida, por supuesto, para garantizar que sus aplicaciones web puedan aprovechar todo el potencial de las solicitudes de origen cruzado mientras protegen contra las amenazas de seguridad. Muchas gracias chicos por seguir conmigo hasta el final de esta conferencia. Espero que hayas sacado algo de ello y estés usando intercambio de recursos de origen cruzado en tus futuras solicitudes HTTP. Yo era Ox y espero verte en la próxima conferencia. 10. ¿Qué es una URL?: Hola chicos, y bienvenidos de nuevo a este tutorial de HDDP. En esta conferencia, vamos a discutir las URL y ¿qué son exactamente Un acrónimo de URL proviene del localizador de recursos Uniform. Una URL no es más que la dirección de un recurso en la World Wide Web. Por supuesto, este recurso puede ser una página Web real, una imagen, o cualquier otro tipo de datos que junten se pueden encontrar en Internet. Una observación aquí es que cada valor de la URL apunta en la web mundial a un recurso único. Dichos recursos pueden ser una página HTML, un documento CSS, una imagen, etc. Incluso pueden ser un agregado Json que cuando abres, solo contiene datos entre llaves Algunos de estos podrían ser movidos o eliminados. De ahí que Internet se esté moviendo tan rápido hoy en día. Si ese es el caso, podría apuntar directamente a un código de retorno HTTP de cuatro o cuatro no encontrado, preocupe por los códigos de retorno. Tendremos una sección futura que será enteramente sobre ellos y los discutiremos a detalle. La forma en que accederíamos a una URL sería ingresarla en la barra de nuestro navegador y presionar Enter. Lo que sucedería en el back end de este proceso que el usuario básico no conoce y desconoce, básicamente cómo funciona sería ese navegador UR, por lo que el navegador del usuario haría una solicitud en el servidor especificado en la URL para recuperar exactamente la información especificada en la ruta de esa URL. Podemos ver que estas URL son una herramienta que nos hace posible la solicitud al servidor desde nuestros navegadores locales Por lo tanto, son muy útiles. Ahora, dependiendo del contexto en el que nos encontremos, solo existen dos tipos de URLs que se clasifican como URLs absolutas y URLs relativas La diferencia es bastante sutil entre estos dos, pero merece ser conocido como, es un concepto bastante básico con el que podrías encontrarte Si te metes en desarrollo web o simplemente ingresas una F 12 en Google Chrome e intentas leer el recurso de una página web, Podrías encontrarte con este concepto. Y es mejor tenerlo cubierto para que lo entiendas profundamente cuando te encuentras con él. Una URL absoluta se usa mejor cuando no se tiene contexto. Por ejemplo, en la página de inicio de nuestro navegador. Absoluto significa que necesitas especificar la ruta completa a la solicitud que estás realizando. Ahora, en el otro extremo del espectro cuando se trata de URL relativas, si se usa una URL dentro de un documento HTML, por ejemplo, solo puedes especificar la ruta relativa desde donde estás y ahora tendrá que llevarte allí Esto puede suceder porque el navegador en ese punto tiene la URL de los documentos en la que se encuentra y puede usarla para rellenar el vacío de la ruta relativa que está ingresando. Puede usar eso como punto intermedio para llevarte a donde quieras ir relativo a ese punto. Si ve una ruta que comienza con barra diagonal, el navegador colocará la ruta restante después de que la barra inclinada relativa a la ruta esté en ese punto, es decir, después Y te llevaremos al destino elegido si es válido. Es por ello que se escogió el nombre relativo de URL. Al pensarlo, las URL son una forma muy sencilla, legible por el ser humano en la que podemos navegar rápidamente y también simplemente por Internet sin demasiados conocimientos tecnológicos Además, dada la falta de experiencia de la mayoría de los usuarios de Internet, la propiedad semántica de las URL debe mantenerse como una buena práctica para tal vez mantener esta claridad en para tal vez mantener esta claridad en manipulación de los caminos de las solicitudes por parte de los usuarios promedio En las próximas conferencias, echaremos un vistazo más de cerca a los elementos clave exactos en la estructura de una URL y la descompondremos para ver qué hace cada uno de ellos en detalle Si eso suena interesante, espero verlos ahí, chicos. Muchas gracias por seguir conmigo hasta el final de esta conferencia. 11. La estructura de una URL: Hola chicos, y bienvenidos de nuevo a este HTTP tutorville. En esta conferencia, vamos a echar un vistazo más de cerca cuando se trata de la estructura de una URL. Algo en lo que quizás nunca se te haya pensado ya que lo acabas de escribir en la barra de tu navegador de inicio. Pero estas URL en realidad tienen una estructura, y cada parte de ellas significa algo En cuanto a cuando los pones juntos, nos pueden llevar exactamente a donde queremos ir, tal vez una parte específica en un documento HTML de la web que aloja el servidor. Una URL está compuesta, como he dicho, de diferentes partes, y algunas de ellas son obligatorias, mientras que otras son opcionales. La primera parte de una URL es el esquema de la misma. Esto indica el protocolo que debe usar el navegador, solicitar el recurso, generalmente para sitios web, el protocolo es HTTPS o HTTP. Abordar páginas web requiere una de las dos. Esto es básicamente bastante sencillo, y es posible que hayas visto el esquema en algunas URL que has escrito, o tal vez si has hecho clic en la URL de la página web en la que estás ahora, puedes ver que comienza con HTTP o HTTPS No creo que eso sea extraño para ti en absoluto ahora, solo sabes más sobre el nombrarlo A continuación, después del esquema, tenemos la parte de autoridad que está separada del esquema por un patrón de caracteres, que es la columna y luego dos barras En esta autoridad, tenemos el nombre de dominio, por ejemplo. Eso podría ser www.thenameofyoursite.com Este es el dominio, la dirección real en la que Podría incluir incluso el puerto, aunque esto no es muy habitual ya que veremos por qué en un momento. Y estos dos están separados de nuevo por una columna. Entonces iría así columna site.com. Y luego el Puerto 88 tal vez. Ahora el dominio indica qué servidor web se está solicitando, como ves en tu día a día cuando escribes W y luego el sitio web al que intentas acceder, ese servidor web está siendo solicitado. Ahora el Puerto indica la puerta técnica como para hablar, utilizada para acceder al recurso en el servidor web. Por lo general, se omite si el servidor web utiliza los puertos estándar del protocolo HTTP. Por eso casi nunca lo vemos. El servidor web casi siempre usa los puertos estándar del protocolo HTTP. En cuanto a mí, rara vez vi algún puerto después del dominio. Ahora después de que la autoridad parte en la estructura de una URL, viene la ruta del recurso en el servidor web. Ahora, en los primeros días de la web, un camino como este representaba una ubicación física en el servidor web. Pero ahora es sobre todo una abstracción manejada por servidores web sin ninguna realidad física en absoluto. Esta ruta de la que estamos hablando aquí podrían ser algunas barras que indiquen, por ejemplo, el usuario, luego el ID de un usuario especificado, y luego nuevamente, algún dato sobre ese usuario puede ser su página de información Entonces cada una de estas palabras clave están separadas, como he dicho, por barras oblicuas después de la autoridad, y apuntan a una ubicación muy específica en ese servidor web Por lo que viene con información adicional. A pesar de que estas son las partes principales, también podemos tener parámetros. Son una lista de pares de valores clave separados con el símbolo final. Esto también podría aparecer en las URL con bastante frecuencia, y el servidor web puede usar esos parámetros para agregar personal adicional entre devolver el recurso Por último, podríamos tener un ancla. Y esto representa una especie de marcador dentro del recurso, dando al navegador las indicaciones para mostrar el contenido ubicado en ese punto de marcador en un documento HDML Por ejemplo, lo que haría un ancla es que el navegador se desplazaría hacia abajo automáticamente hasta el punto donde se define el ancla. Y en un documento de video o audio en el navegador, intentará ir al tiempo que representa el ancla. Vale la pena señalar que la parte posterior la H t también se conoce como el identificador de fragmento, y esa es básicamente la sintaxis de un ancla. Esta era más o menos la estructura de una URL en detalle. Espero que ustedes hayan sacado algo de ello. Y a partir de ahora, cada vez que ingreses URL, vas a poder separar muy bien cada de sus partes en tu cabeza y entender el nombre de cada una, y más importante que eso, lo que hace cada una de ellas Ahora en la siguiente sección, vamos a hablar un proceso que se llama codificación URL, que es bastante interesante y útil cuando se trata de Internet. Entonces, si eso suena interesante, espero verlos ahí, chicos. Muchas gracias por seguir conmigo hasta el final de esta conferencia. 12. Codificación de URL: Hola chicos, y bienvenidos de nuevo a este curso HTTB. En esta conferencia, vamos a discutir el proceso de codificación de URL. Qué es, por qué y cuándo es útil a la hora de codificar URL, también conocida como codificación porcentual. Lo que hace todo este proceso es que convierte los caracteres en un formato que puede transmitirse en URL a través de la World Wide Web Cómo lo hace es básicamente procesando el juego de caracteres G. En este punto, podría preguntarse, ¿cuál es el punto de tener esta codificación? Bueno, es necesario porque la mayoría de las veces, las URL tienen dentro de ellas caracteres que no están dentro del conjunto G y necesitan ser convertidos a ese formato para que esa URL específica funcione al ingresar a un navegador web Toda la forma en que funciona esta codificación es bastante simple y directa. Por cada carácter que no sea un carácter SG, está siendo reemplazado por un signo de porcentaje seguido de dos dígitos hexadecimales. Esto quiere decir que para cada personaje ese no es un personaje de Asch Básicamente mapea ese carácter a una estructura de tres caracteres de la cual el primero es siempre el porcentaje, y los dos siguientes son dígitos hexadecimales. Ahora para los espacios en particular, si pensaste en eso, tampoco están permitidos dentro de una URL. Y se reemplazan en la URL con el signo más si alguna vez intentaste representarlos. Hay en Internet tablas enteras donde se puede ver a qué se asigna cada carácter cuando se trata de la codificación URL. O tienes un enfoque aún más sencillo que eso. Si caes en la situación de querer codificar una URL de tu texto no Asch Hay sitios web como URL Encoder.org y si pega texto UR allí, puede codificarlo automáticamente como URL codificada para Entonces este es un proceso bastante básico y directo que es muy sencillo de entender, pero es clave para que sepas que se usa para escribir prácticamente cualquier cosa en un nuevo RL que otra manera no se hubiera permitido estar allí. Gracias chicos por quedarse conmigo hasta el final de esta conferencia. En la siguiente, vamos a mirar la sesión HTTP y también las cookies para comprender mejor además este protocolo. Entonces, si eso les suena interesante, espero verlos ahí, chicos. 13. Sesiones y cookies: Hola chicos, y bienvenidos de nuevo al tutorial HTTP. En esta conferencia, vamos a discutir la sesión HTTP y también las cookies que están disponibles aquí para entender mejor este protocolo y cómo funciona. La forma en que funcionan las sesiones HTTP es mediante el uso de estas cosas llamadas cookies y también técnicas criptográficas para mantener fecha sin almacenar tantos datos en el servidor Al presentar una página web dinámica, el servidor envía los datos del estado actual al cliente, es decir, el navegador web, en forma de cookie. Esto lo que es una cookie, el cliente guarda esta cookie en memoria que recibió o en disco. De esta manera el servidor web no necesita hacerlo. Con cada solicitud sucesiva, el cliente vuelve a poner la cookie en el servidor. El servidor utiliza los datos para recordar el estado de la aplicación para ese cliente específico y también generar una respuesta adecuada. Este mecanismo puede funcionar bien en casi todos los contextos, pero hay algunas excepciones que puede haber visto al ingresar un nuevo sitio web que requiere que acepte todas las cookies. Esto es lo que significa. Te enviará partes de la información para que no tengan que almacenarla en sus servidores web. Información relativa a la sesión en la que se encuentra. Y sin embargo información al respecto, si haces clic en ese sitio web más tarde, sabrá de dónde sacarte. Sin embargo, los datos almacenados en un cliente, es decir, en usted, son vulnerables a usar sesiones del lado del cliente donde se requiere confidencialidad e integridad. Debe garantizarse lo siguiente. Necesitamos tener confidencialidad. Datos, integridad y autenticidad. confidencialidad viene del hecho que nada aparte del servidor debe ser capaz de interpretar los datos de la sesión, es decir, ningún tercero o hacker. La integridad significa que nada aparte del servidor debe manipular los datos accidental o maliciosamente Y la autenticidad significa que nada aparte del servidor debería poder iniciar sesiones válidas. Ahora para lograr estas tres propiedades y asegurarse de que se respetan, el servidor necesita cifrar los datos de la sesión antes de enviarlos al cliente Y la modificación de dicha información por cualquier otra parte debe ser prevenida a través de este medio criptográfico Transmitir el estado de ida y vuelta con cada solicitud solo es práctico si el tamaño de la Coca-Cola es pequeño. En esencia, las sesiones del lado del cliente negocian el espacio en disco del servidor o el ancho de banda adicional que requerirá cada solicitud web. Además, el navegador web limita el número y tamaño de las cookies que puede almacenar un sitio web para mejorar la eficiencia y permitir más datos de cese. El servidor puede comprimir los datos antes de crear la cookie, descomprimiéndola posteriormente cuando la cookie sea devuelta por el cliente Esto puede funcionar con herramientas de compresión como programas Win Sip o Seven P que ustedes podrían estar familiarizados Al hacer que las cookies sean demasiado grandes en tamaño, la compensación ya no valdría la pena, ya que el ancho de banda para enviarlas sería obviamente enorme Se trata de la sesión HTTP, cómo se ve mejorada por las cookies Espero que ustedes hayan sacado algo de esta conferencia. En la siguiente, vamos a ver en detalle todos los métodos de solicitud HTTP, ver qué son, qué hacen, y cómo pueden ser útiles en nuestro viaje para entender mejor el protocolo HTTP. Si eso suena interesante, espero verlos ahí, chicos. Gracias por quedarse conmigo hasta el final de esta conferencia. 14. Sockets web: Hola chicos y bienvenidos de nuevo a este curso sobre el protocolo HTTP. En esta conferencia, vamos a echar un vistazo a los sockets web. Son muy importantes en la comunicación en tiempo real cuando se trata del protocolo HTTP. En el panorama moderno de la tecnología web, las expectativas de los usuarios para la comunicación en tiempo real han alcanzado nuevas alturas. Como puedes ver, a tu alrededor el clima es platicar con amigos en Whatsapp, monitorear datos de vida, o colaborar con compañeros en el trabajo. La demanda de interacción instantánea y fluida en la web nunca ha sido mayor. Para satisfacer esta demanda, los desarrolladores web en general recurren a Web Sockets, una tecnología que facilita la comunicación en tiempo real a través del protocolo HTTP. En esta lección, profundizaremos en el mundo de los sockets web Y cómo permiten la comunicación en tiempo real sin necesidad de constantes solicitudes HTTP. Realmente son una parte esencial de este protocolo. Pero antes de eso, echemos otro vistazo al modelo de respuesta a solicitudes HTTP que ya hablamos. Sólo refrescar en él. Antes de explorar los sockets web, es esencial comprender la base sobre la que operan. El protocolo de transferencia de hipertexto o escorto. Http ha sido durante mucho tiempo la columna vertebral de la World Wide Web, sirviendo como mecanismo para el intercambio de datos entre clientes, típicamente navegadores web y servidores. En el modelo tradicional de respuesta a solicitudes HTTP, el cliente envía una solicitud al servidor que procesa la solicitud y devuelve una respuesta. Si bien este modelo funciona bien para muchas interacciones web, tiene limitaciones cuando se trata de comunicación en tiempo real. En el modelo HTTP tradicional, se requiere una nueva solicitud para cada interacción entre el cliente y el servidor. Esto significa que para recuperar nuevos datos o mensajes, el cliente debe enviar repetidamente solicitudes, lo que resulta en una serie de intercambios de ida y vuelta. Este enfoque no es muy adecuado. Aplicaciones en tiempo real donde los datos necesitan fluir forma continua e instantánea en sockets web Se introdujeron como una solución a la limitación del HTTP tradicional. Proporcionan un canal de comunicación bidireccional plex completo canal de comunicación bidireccional plex través de una sola conexión de larga duración con sockets web Tanto el cliente como el servidor pueden iniciar la comunicación de forma independiente. Esto significa que los datos pueden ser empujados desde el servidor al cliente, o viceversa, sin necesidad una nueva solicitud HTTP cada vez como era el caso antes. Ahora veamos las características clave de los sockets web y también las principales razones por las que deberías considerar implementarlo en tus propias aplicaciones. Primero, tenemos conexión persistente. Los sockets web mantienen una conexión persistente entre el cliente y el servidor. Una vez establecida la conexión, permanece abierta, permitiendo que los datos fluyan continuamente sin la sobrecarga de abrir y cerrar conexiones para cada interacción. En segundo lugar, tenemos demandas de comunicación en tiempo real de baja latencia . Baja latencia, y los sockets web ofrecen en este frente. Dado que la conexión siempre está abierta, los datos pueden transmitirse con un retraso mínimo, haciendo que los sockets web sean ideales para aplicaciones donde las actualizaciones instantáneas son esenciales. La tercera característica clave del socket web es el protocolo ligero. El protocolo Web socket está diseñado para ser ligero, lo que reduce la sobrecarga de la transferencia de datos. Esta eficiencia contribuye a la velocidad y capacidad de respuesta de las aplicaciones en tiempo real Por último, tenemos comunicación de origen cruzado, que es compatible con sockets web, lo que significa que los clientes pueden conectarse a servidores web socket en diferentes dominios. Esto lo hace adecuado para varios casos de uso, incluyendo aplicaciones de chat y feeds de datos en vivo. Ahora vamos a echar un vistazo a algunos casos de uso del mundo real solo para que entiendas mejor todo el concepto de websocket Las ventajas de los sockets web son evidentes en diversas aplicaciones del mundo real. Para el primer escenario, consideremos las aplicaciones de chat. Estos se benefician de las capacidades de mensajería instantánea de los sockets web. Los usuarios pueden intercambiar mensajes en tiempo real sin necesidad actualizar la página continuamente. Aquí puedes pensar tu aplicación de chat favorita, ya sea en el móvil o en la web. A continuación tenemos juegos online. Estos a menudo requieren actualizaciones en tiempo real , como movimientos de jugadores y cambios en el estado del juego. Los sockets web permiten la sincronización perfecta de los datos del juego entre los jugadores. Además, si estás invirtiendo. Se podría pensar en el mercado de valores y las plataformas financieras. En los servicios financieros, los datos en tiempo real son críticos. Las plataformas bursátiles utilizan sockets web para proporcionar precios de acciones en vivo, tendencias del mercado y ejecuciones comerciales a los comerciantes. Por último, las herramientas de colaboración como las pizarras compartidas y los editores de documentos se basan en actualizaciones en tiempo real para garantizar que todos los participantes vean los últimos cambios al instante Cuando se trata de implementar sockets web, tanto el cliente como el servidor necesitan soporte de socket web. Java Script a través de la API de socket web se usa comúnmente en el lado del cliente. Los marcos y bibliotecas del lado del servidor como ningún JS con la biblioteca YS o el patrón con socket web permiten este soporte de websocket en el lado del servidor Este es un muy buen punto de partida de bibliotecas para echar un vistazo si ya tienes una situación de servidor cliente en la que quieres implementar sockets web. Si bien los sockets web ofrecen una solución poderosa para la comunicación en tiempo real, existen algunos desafíos y consideraciones. Primero, tenemos escalabilidad. manejo de una gran cantidad de conexiones de socket web puede ser un desafío. El equilibrio de carga y la administración eficiente de la conexión son cruciales para las aplicaciones de socket web escalables. A continuación, tenemos problemas de firewall y proxy. Algunas redes y configuraciones de seguridad pueden restringir el tráfico de socket web En tales casos, las conexiones de socket web podrían necesitar ser tunelizadas a través de HTTP u otros protocolos O incluso podría implementar una solución alternativa en caso de que su implementación de socket web falle En tercer lugar, tenemos seguridad habilitar la seguridad de las conexiones web socket es vital. Implementar conexiones seguras de socket web, que son dobles YSS, y validar datos para evitar vulnerabilidades de seguridad es esencial En resumen, los sockets web han revolucionado comunicación en tiempo real en la web al superar las limitaciones del HDDP tradicional Proporcionan una baja latencia por conexión direccional que sirve como columna vertebral de numerosas aplicaciones en tiempo real, desde plataformas de chat hasta juegos en línea y herramientas colaborativas. Los desarrolladores web equipados con conocimiento de socket web son posición real para crear la próxima generación de aplicaciones web en tiempo real que satisfagan las crecientes demandas de los usuarios para interacción instantánea y fluida. Gracias chicos por seguir conmigo hasta el final de esta conferencia. Realmente espero que hayas sacado algo de ello. Y los websockets serán a partir de ahora un concepto que comprenderás a fondo Espero verte en la siguiente lección. 15. HTTP: Hola chicos, y bienvenidos de nuevo al curso HTTP. En esta conferencia, vamos a discutir el protocolo HTTPS, qué hace mejor que el HTTP, si debemos usarlo y también entender a un nivel básico e incluso más que eso en un nivel más avanzado, cómo funciona. Al comenzar con él, el protocolo HTTPS y acrónimo significa el protocolo de transferencia de hipertexto que proviene de asegurado Es más o menos lo mismo que HTTP, pero este tiene la S y la palabra clave segura adjunta a él. Y repasar el principal problema de seguridad con el protocolo HTTP del que hablamos hasta este punto es que la información que fluye de servidor a cliente no está encriptada en absoluto. Además, el problema con esta falta de encriptación es que puede ser visto por cualquiera exactamente en la forma que tiene. Lo que significa que, por supuesto, puede ser robada fácilmente, pero también reemplazada por un hacker o un tercero que esté asistiendo a este intercambio, él puede intervenir en él. El protocolo HTTPS soluciona esto mediante el uso de un certificado SSL. El acrónimo SSL proviene de Security Sockets Layer, y este certificado ayuda a crear una conexión encriptada segura entre el servidor web y el navegador del cliente. De este modo, además protege la información sensible de ser robada al ser transferida entre el servidor y el navegador. Cifrar esta información significa que está mapeada a alguna otra forma que un tercero o atacante no pueda entender, y además, incluso verla, acceder a ella o robarla La diferencia más importante entre los protocolos de HTTP y HTTPS es obviamente el certificado SSL. De hecho, HTTPS es básicamente un protocolo HTTP simple del que hablamos hasta este momento con solo alguna capa de seguridad adicional, lo cual es muy importante. Sin embargo, esta seguridad adicional puede ser extremadamente importante, especialmente para los sitios web que almacenan información sensible para sus usuarios, como la información de tarjetas de crédito. Por ejemplo, si compraste algo en un sitio web, es posible que hayas visto eso o solo tu contraseña. Entonces, si no ves un candado la izquierda de la URL y estás intentando acceder a tu cuenta ingresando tu contraseña o intentando comprar algo que te indique tu tarjeta de crédito. Solo debes parar porque no es seguro y tus datos podrían ser robados a un atacante que está viendo este proceso. Ahora, el certificado SSL cifra la información, como he dicho, que los usuarios suministran al sitio, lo que básicamente significa que traduce los datos en un código Aunque alguien logre robar los datos que se están comunicando entre el servidor y el destinatario, no podría entenderlo gracias a este cifrado que aplica el certificado de celda S. Además, además de aplicar esta capa extra, HTTPS también se asegura a través del protocolo TLS Ahora el protocolo TLS y acrónimo proviene de la seguridad de la capa de transporte Y lo que hace, ayuda a proporcionar integridad de datos que ayuda a evitar que la transferencia de datos sea modificada o incluso corrupta. También otra cosa que hace, proporciona autenticación que prueba a los usuarios que realmente se están comunicando con los sitios web reales. Esto significa al final del día, que el tercero no puede venir y cambiar el contenido que se transmite entre el cliente y el servidor. Eso es muy importante, los usuarios pueden identificar si un sitio está utilizando el protocolo HTTPS por la dirección web, la primera parte de la dirección web, o la URL como vimos en la conferencia previa, que se llama la autoridad antes del inicio del nombre principal. Esa parte de ahí indica si el sitio está usando HTTP o el protocolo HTTPS. Solo debes mirar tu URL y ver eso. O también puedes verificar el candado que está presente en la parte izquierda de la URL. Eso también te dirá si estás accediendo a una página que está asegurada con el HTTPS o no. Ahora, para hacer un resumen rápido, la principal diferencia entre el protocolo HTTP y el HTTPS es simplemente la presencia del certificado innecesario. Http no tiene el certificado SSL y el HTTPS lo tiene. Ese certificado de asesor encripta tu información para que tu conexión esté segura y la información que estás transmitiendo no pueda ser robada o modificada por un tercero o hacker Esto fue sobre ello con el protocolo HTTPS. Dps es obviamente un protocolo que se prefiere hoy en día y casi siempre se implementa en las páginas web Además, si te gusta el desarrollo web y estás tratando de crear un sitio web, te sugiero encarecidamente que uses este protocolo más seguro, especialmente si estás tratando de obtener algún dato sensible de los usuarios. Entonces este protocolo te va a hacer menos susceptible a un texto de eventuales hackers. Muchas gracias chicos por seguir conmigo hasta el final de esta conferencia. En la siguiente, vamos a echar un vistazo a algunas herramientas muy útiles con las que podremos ver las peticiones HTTP reales que se realizan desde nuestra máquina a otros servidores web y capturarlas para ver qué información se envía o recibe y así sucesivamente. Entonces esa va a ser la parte más concreta y procesable de nuestro tutorial aquí Entonces, si eso suena interesante, espero verlos ahí, chicos. 16. Direcciones IP: Hola chicos, y bienvenidos de nuevo al curso HTTP. En esta conferencia, vamos a aprender más sobre qué es una dirección AP y cómo podemos usarla en nuestros esfuerzos con el protocolo HTTP La dirección AP significa una dirección de Protocolo de Internet. De ahí viene el NP, Protocolo de Internet. Lo que es, es una etiqueta numérica como 1902121. Esta etiqueta representa tu conexión a una red informática que utiliza el Protocolo de Internet para la comunicación, por eso es una dirección de Protocolo de Internet. Una dirección AP cumple dos funciones principales. La función de identificación de la interfaz de red y la función de direccionamiento de ubicación. En solo un momento, hablaremos más ampliamente sobre estas dos funciones en términos más fáciles de entender. Pero mientras vayan las versiones del Protocolo de Internet, hubo dos versiones principales del Protocolo de Internet. El primero, cuando se inició por primera vez, se llama la versión cuatro, también conocida como IPV cuatro, y define una dirección AP como un número de 32 bits No obstante, debido al crecimiento de Internet ocurrió y al agotamiento de las cuatro direcciones IPV disponibles, una nueva versión de IP Porque no se puede pensar que un número de 32 bits sólo puede almacenar tantas direcciones. esta necesidad, creamos el IPV six, que es la versión seis del protocolo de Internet Estas direcciones IP están usando 128 bits en lugar de solo 32. Ahora, otra mención notable aquí es que el espacio de direcciones IP es administrado globalmente por la autoridad de números asignados por Internet. Estas direcciones IP están escritas y mostradas en anotaciones legibles por humanos Como ejemplo que te di, una dirección IP válida es 1902120 Los administradores de red de Internet asignaron números, autoridad, o simplemente en general, asignan una dirección IP a cada dispositivo conectado a una red. Dichas asignaciones pueden realizarse sobre una base estática o dinámica. Lo que esto significa es que pueden ser fijos o pueden ser permanentes. Todo depende de las prácticas de red en las que estés y de las características del software de la máquina desde la que estés trabajando. Ahora entrando en el propósito de la dirección AP y por qué exactamente, es importante que sepas cosas al respecto. Es porque una dirección IP identifica al host. Y se puede ver que si escribe en la dirección IP de Google. Algunos sitios están dispuestos a mostrar su propia dirección IP y también mostrarán exactamente dónde se encuentra en un mapa global. Eso por supuesto, si no estás usando una VPN o algo así, eso redirigirá tu acceso a Internet a algún otro La dirección IP identifica el host o más específicamente su interfaz de red con él. Como dije, proporciona la ubicación del host en la red. Y de esta manera tiene la capacidad de establecer un camino hacia ese host. Se ha caracterizado a la fila como un nombre que indica lo que vemos. Una dirección indica dónde se encuentra y la ruta indica cómo llegar. El encabezado de cada paquete IP contiene la dirección AP del host emisor y la del host de destino, que vamos a ver en tan solo un momento en el que vamos a ver algunas solicitudes HDTP que se están realizando ya sea en Fiddler Como conclusión, en esencia, las direcciones IP son el identificador que permite enviar información entre dispositivos en una red. Contienen información de ubicación y también hacen que los dispositivos sean accesibles para la comunicación. Internet necesita una forma de diferenciar entre diferentes computadoras, enrutadores y sitios web. Esto es exactamente lo que proporciona la dirección IP, una forma de hacerlo y forman parte esencial de cómo funciona Internet en la actualidad. Realmente espero que ustedes hayan sacado algo útil de esta conferencia. Muchas gracias por seguir conmigo hasta el final de la misma, y espero verte en la siguiente. 17. Solicitudes HTTP en la práctica: Ayuda chicos y bienvenidos de nuevo al tutorial HTTP. En esta primera conferencia de la sección donde tenemos más experiencia práctica con herramientas reales que nos ayudarán no sólo entender mejor todo el protocolo HTTP y sus peticiones, sino también tal vez incluso hacer algunas cosas al respecto. No sólo entenderlos como para ver exactamente cómo se hace una solicitud, la información al respecto en la práctica, e incluso ver si algo le pasa o algo así. Para esta primera conferencia, vamos a echar un vistazo a una pieza de software desarrollada por una compañía llamada Alaric Se llama Violinista. Puedes preguntarte ahora, ¿para qué se utiliza esta herramienta Fiddler Bueno, se trata de una entidad proxy, que si recuerdas, hablamos en conferencia anterior. La entidad proxy era una entidad que estaba entre la entidad servidor y la entidad cliente. Y ejecutó la solicitud real entre estas dos entidades principales a través de ella. Y era transparente o no transparente en base a si manipulaba o no los datos de la solicitud Esto lo que es violinista, es un servidor proxy que te mostrará, por supuesto, todo el tráfico web en tu máquina local con el que lo tienes instalado a varios servidores web Por ejemplo, si ingresas un sitio web de redes sociales desde tu computadora, te mostrará esa solicitud que hiciste hasta ahora, y podrás verla con mucho más detalle. Ahora bien, la razón por la que se utiliza esta herramienta es para depurar el tráfico web para aplicaciones en navegadores. Y lo que eso significa es, por ejemplo, digamos que creaste el sitio web y querías ver exactamente cómo se hace tu solicitud al sitio web. Si algo sale mal con ello, querrías mirar esa solicitud específica para ver qué le va mal. Y los dos realmente te ayudarán a hacerlo mostrándote mucha información sobre cada solicitud específica que se hizo desde tus máquinas locales o desde tu máquina cliente a servidor web. Ahora, para poder descargar la pieza de software de Fiddler, puedes ir a Google, justo Fiddler, claro, la versión bare es una versión aún más básica y puedes elegir Pero cuando lo consigas debes escribir tu correo electrónico y luego seleccionar también el país en el que te encuentras y algunas cosas así. Directamente descárgalo. Además si estás en el entorno Apple o Linux, debes usar uno de estos botones de descarga. Pero estamos en Windows. En las máquinas, elegí la descarga estándar, solo descargará un ejecutable para ti. Eso sería bastante sencillo, y una vez que lo abres, puedes ver que solo te muestra un acuerdo de licencia. Entonces, una vez que hagas clic en Aceptar, comenzará a instalarlo en tu máquina local. Una vez realizada la instalación, vamos a obtener una visión general de esta herramienta para ver exactamente cómo se muestran las solicitudes y cómo podemos avanzar en la comprensión de este protocolo mediante el uso de esta herramienta. Una vez que lo abras, podrás iniciar sesión con tu cuenta. Lo haré en un momento y me pondré contigo una vez que esté en la aplicación. ¿Bien? Entonces, estoy de vuelta después de crear mi cuenta con Fiddler Una vez que abramos la aplicación, vas a ver que esto te va a ejecutar a través de un tutorial rápido. En primer lugar, básicamente te dicen que no rastreará tu tráfico HTTPS ya que ese es encriptado y no rastreado. Pero puedes dar click en el icono de disuadir para poder cambiar eso Después te mostrará toda la parte izquierda de la herramienta donde aparecerá el tráfico y cada una de estas filas significa algo. Por supuesto el resultado como en el código de estado de la solicitud de la que hablamos. El, el método como en get post y así sucesivamente. El proceso, la IP remota y luego la URL siguiente aquí, una vez que hagas clic en una solicitud desde la parte izquierda aquí, vas a ver la respuesta real y el contenido real de la respuesta ya sea en HTML, Json, y algunas otras formas en las que se puede mostrar aquí, puedes capturar el tráfico en vivo o no. Entonces, por supuesto, podemos tener algunas sesiones seguras. Una vez que hayas terminado con el tutorial, puedes hacer clic en el botón Me y luego hacer clic en ese signo rojo de exclamación después del símbolo de URL Y una vez que hagas clic en eso, comenzará a rastrear también las solicitudes y respuestas reales que están pasando por HTTPS. Porque vas otorgándole ese certificado para permitirle ver aquellas solicitudes que se hacen de manera segura. Por ejemplo, abrí mi cromo aquí y abrí mi cuenta de Instagram. Se puede ver que una vez que hice eso, aquí obtuve muchas fotos que obtuve de mi feed de Instagram y por supuesto, alguna otra para acceder a tokens que me dieron a través de la autenticación a través de Facebook, en Instagram y así sucesivamente Por lo que se puede ver también en la primera parte, no sólo el número de la solicitud que se hizo en función del tipo sino también el tipo de la respuesta que obtuvo. Por ejemplo, se trata de imágenes que viste. Esta es una respuesta de Jason. Estos son métodos de publicación que se utilizan para crear cosas y así sucesivamente y así sucesivamente. Por supuesto, puedes agruparlos por resultados. En primer lugar, si quieres tener las solicitudes de resultados bien, puedes hacerlo y luego en realidad aumentarán. Por ejemplo, aquí está el último que tuvo una respuesta de 43. Entonces tenemos el método si quieres primero obtener tipos de solicitudes y así sucesivamente. Después los procesos de IP y también los tamaños de cuerpo o comentarios. También puedes ordenarlos por eso. Ahora, al recibir esta solicitud, se pueden ver algunas cosas. Aquí tenemos un avance. Lo podemos ver en el formato raw. Se puede ver el cuerpo de la solicitud y también los encabezados que vinieron con ella. Aquí tenemos, por supuesto, alguna información bastante general al respecto, como el último día en que se modificó, el tipo de conexión, la longitud del contenido, y así sucesivamente y así sucesivamente. Nuevamente, aquí también se muestra la respuesta. Puedes guardar la sesión. Entonces una sesión es una vez que empiezas a ver algunas solicitudes, entonces puedes iniciar la sesión y tienes algunas solicitudes al finalizar y luego guardarla. Debajo de lo de la sesión aquí, también puedes eliminarlos todos si quieres tener una pizarra limpia. Como dije, sesión de seguridad puede compartir la sesión. De hecho, puedes hacer algunos filtros avanzados como los encabezados de respuesta y los encabezados de solicitud para solo ver algunas de las solicitudes que tienen lugar. Aquí tienes algunas notificaciones, tu perfil, la configuración. Esto es más o menos cosas básicas, pero esto puede ser muy útil como he dicho, si quieres hacer un sitio web o tal vez solo expongas algunas APIs a tu servicio web y quieres ver cómo van a quedar las solicitudes que se hacen para obtener puntos finales API Esta es la herramienta que querrías usar. Por supuesto, también hay otra herramienta llamada Wireshark, y vamos a pasar por esa herramienta a continuación y echarle un vistazo más profundo también, pero por ahora, esto fue sobre eso con la Les agradezco muchísimo a ustedes que se hayan quedado conmigo hasta el final de esta conferencia. 18. Wireshark: Hola chicos y bienvenidos de nuevo a este tutorial HTTP. En esta última conferencia, vamos a profundizar en otra herramienta que mejorará nuestro conocimiento sobre el protocolo HTTP y las solicitudes que se hacen más exactamente. Esto también se llama Wireshark, como se puede ver en la pantalla Y es otra aplicación muy similar a la última aplicación que estaba en esta área, y hablamos de ello en la conferencia anterior, que fue Fiddler Esta aplicación también le permite capturar e investigar en detalle el tráfico de red que tiene, es decir, las solicitudes que se realizan, y las respuestas que se reciben entre el cliente, es decir, el navegador web que tiene en la máquina local donde instaló esto también, y el servidor web al que realiza solicitudes. Y eso puede variar en función del sitio web que ingreses y lo que recibiste de él. Nuevamente, aquí solo podemos buscar en Google Wireshark. Es una herramienta gratuita, y una vez que estás en WireShark.org básicamente puedes comenzar descargándola comenzar Estoy en Windows, voy a instalar este bit 64 también. Pero nuevamente, también tienen el cos, si estás en el producto Apple, puedes elegir eso para que lo instales. Y una vez que hagas clic en él, como puedes ver, también descargará el ejecutable. Entonces también te pasaré por la configuración. Como es bastante sencillo, solo puedes instalarlo con todas las cosas con las que Caes. También te pediremos asociar todas estas extensiones de diferentes archivos con Wireshark Lo vamos a instalar en unidad C. No voy a usar este MP 1102, ni el USB, solo voy a no dar click en eso Realmente no necesitas esas herramientas para que solo observen estas peticiones que se hacen y ver exactamente cuáles son los detalles sobre ellas. Como puedes ver aquí, el cable hark está instalando. Y me pondré en contacto con ustedes una vez que la herramienta esté instalada y abierta en mi máquina para que veamos qué está pasando y cómo podemos usarla chicos. Una vez que abras el cable, puedes seleccionar la conexión que Elegí el Internet para entonces, como se puede ver en la pantalla, simplemente lo paré por ahora. Así que vas a tener una mejor mirada a lo que está pasando exactamente aquí. Pero claro, aquí se usa señal de tiburón para iniciar la captura real de la solicitud. Y este es el botón de parada en la primera parte superior aquí. A diferencia del fuego que tenía estas partes verticalmente, esta las tiene horizontalmente. Pero aquí se puede ver la solicitud real que se realizó, el protocolo, la fuente en las IPs de destino. Lo cual puede ser muy útil si solo quieres, por ejemplo, ver una solicitud que salió de tu computadora en la red. Puedes ordenar desde la fuente y mostrará las IPs en orden ordenado. Entonces por supuesto la duración de la respuesta, el número de ellas. Si quieres entrar en más detalles a petición real, necesitas hacer clic en él. Y luego te mostrará en la segunda y tercera ventanas reales más información sobre esa solicitud específica. En la tercera ventana , te mostrará la respuesta real en lenguaje decimal. En la segunda, te mostrará como la solicitud es cuerpo y una respuesta real en XML o cualquier formato que tenga. También las respuestas y todas esas cosas buenas aparecerán en el segundo tipo de ventana. Esto también se trata de Wireshark. No es mucha diferencia entre estos dos. Normalmente trabajo con Wireshark como me pareció, más simple y directo Pero ambos son lo suficientemente buenos en este trabajo. puedas elegir con cuál te sientes más cómodo en base a lo que viste en estas dos conferencias. Esto fue sobre eso con los chicos del tutorial HTTP. Espero que hayas sacado algo de ello y entiendas ahora mejor el protocolo HTTP, qué son las solicitudes, cuáles son las entidades en un flujo de trabajo cliente servidor y todas las demás cosas de las que hablamos, códigos de estado y métodos de solicitud HTP Si tienes alguna duda sobre el protocolo HTTP, puedes contactarme y enviarme un mensaje. Y me aseguraré de responderles en la menor cantidad posible. Pero una vez más, muchas gracias por quedarte conmigo hasta el final del tutorial y verlo, y espero verte en más tutoriales que voy a crear.