Generalidades del HTTP<\/a><\/p>\n\n\n\n Descripci\u00f3n de qu\u00e9 es el protocolo HTTP y su funci\u00f3n en la arquitectura de la Web.Evoluci\u00f3n del HTTP<\/a><\/p>\n\n\n\n HTTP fue creado a comienzos de la d\u00e9cada de 1990s y ha sido ampliado con nuevas versiones varias veces. En este art\u00edculo se expone la evoluci\u00f3n de su desarrollo y las versiones HTTP\/0.9, HTTP\/1.0, HTTP\/1.1 y la \u00faltima versi\u00f3n HTTP\/2 as\u00ed como detalles de las funciones que se han ido incluyendo.Negociaci\u00f3n de la versi\u00f3n de HTTP<\/a><\/p>\n\n\n\n Se explica como un cliente y un servidor pueden negociar una versi\u00f3n espec\u00edfica de HTTP y eventualmente actualizar la version usada.Recursos y URIs<\/a><\/p>\n\n\n\n Una breve descripci\u00f3n sobre qu\u00e9 son los recursos, identificadores y localidades en la Web.Identificaci\u00f3n de recursos en la Web<\/a><\/p>\n\n\n\n Descripci\u00f3n de como se referencian recursos en la Web, como son referenciados y como localizarlos.URIs de datos<\/a><\/p>\n\n\n\n Hay un tipo de URIs que permiten integrar directamente el recurso al que se\u00f1alan. Los URIs de datos, son muy ventajosos, pero tambi\u00e9n tienen algunas desventajas.URLs de recursos<\/a><\/p>\n\n\n\n Los recursos URL, prefijados con En la mayor\u00eda de los casos, la identidad y localizaci\u00f3n de un recurso Web, son compartidos, esto se puede modificar con la cabecera de HTTP: Desde la versi\u00f3n HTTP\/1.0, es posible trasmitir distintos formatos de recursos. En este art\u00edculo se explica como se hace, usando la cabecera: Recomendaci\u00f3n sobre el uso de dominios con prefijo www o no. En este art\u00edculo se explican los resultados de la elecci\u00f3n y c\u00f3mo hacerla.Flujo de comunicaci\u00f3n en una sesi\u00f3n HTTP<\/a><\/p>\n\n\n\n En este art\u00edculo se describe una comunicaci\u00f3n t\u00edpica de una sesi\u00f3n HTTP, y lo que sucede internamente cuando se hace click en un hiper-v\u00ednculo.Mensajes HTTP<\/a><\/p>\n\n\n\n \n\n\n<\/ins>\n\n (adsbygoogle = window.adsbygoogle || []).push({});\n\n<\/p>\n\n\n\n Los mensajes HTTP, sean peticiones o respuestas, siguen una estructura muy concreta; en este art\u00edculo se describe su estructura, su prop\u00f3sito y posibilidades.Tramas y estructura de los mensajes en HTTP\/2<\/a><\/p>\n\n\n\n La versi\u00f3n HTTP\/2 encapsula y representa los mensajes de HTTP\/1.x pero en tramas binarias. En este art\u00edculo se explica la estructura y los campos de las tramas, su finalidad y c\u00f3mo se codifica.Proceso de conexi\u00f3n en HTTP\/1.x<\/a><\/p>\n\n\n\n HTTP\/1.1 fue la primera versi\u00f3n de HTTP que soport\u00f3 las conexiones persistentes y el pipelining<\/em>. En este art\u00edculo se explican estos dos conceptos.Proceso de conexi\u00f3n en HTTP\/2<\/a><\/p>\n\n\n\n HTTP\/2 revis\u00f3 completamente, los m\u00e9todos de negociaci\u00f3n, creaci\u00f3n y mantenimiento de conexiones: en este art\u00edculo se explica como se puede consegu\u00edr la multiplexaci\u00f3n de las tramas y resolver el problema de ‘head-of-line’, que ten\u00edan las versiones anteriores de HTTP.Negociaci\u00f3n de contenidos<\/a><\/p>\n\n\n\n HTTP presenta una serie de cabeceras que comienzan con <\/p>\n\n\n\n <\/p>\n\n\n\n HTTP, de sus siglas en ingl\u00e9s: \u00abHypertext Transfer Protocol\u00bb, es el nombre de un protocolo el cual nos permite realizar una petici\u00f3n de datos y recursos, como pueden ser documentos HTML<\/a>. Es la base de cualquier intercambio de datos en la Web, y un protocolo de estructura cliente-servidor, esto quiere decir que una petici\u00f3n de datos es iniciada por el elemento que recibir\u00e1 los datos (el cliente), normalmente un navegador Web. As\u00ed, una p\u00e1gina web completa resulta de la uni\u00f3n de distintos sub-documentos recibidos, como, por ejemplo: un documento que especifique el estilo de maquetaci\u00f3n de la p\u00e1gina web (CSS<\/a>), el texto, las im\u00e1genes, v\u00eddeos, scripts, etc…<\/p>\n\n\n\n Clientes y servidores se comunican intercambiando mensajes individuales (en contraposici\u00f3n a las comunicaciones que utilizan flujos continuos de datos). Los mensajes que env\u00eda el cliente, normalmente un navegador Web, se llaman peticiones<\/em>, y los mensajes enviados por el servidor se llaman respuestas<\/em>.<\/p>\n\n\n\n Dise\u00f1ado a principios de la d\u00e9cada de 1990, HTTP<\/a> es un protocolo ampliable, que ha ido evolucionando con el tiempo. Es lo que se conoce como un protocolo de la capa de aplicaci\u00f3n, y se transmite sobre el protocolo TCP<\/a>, o el protocolo encriptado TLS<\/a>, aunque te\u00f3ricamente podr\u00eda usarse cualquier otro protocolo fiable. Gracias a que es un protocolo capaz de ampliarse, se usa no solo para transmitir documentos de hipertexto (HTML<\/a>), si no que adem\u00e1s, se usa para transmitir im\u00e1genes o v\u00eddeos, o enviar datos o contenido a los servidores, como en el caso de los formularios de datos. HTTP<\/a> puede incluso ser utilizado para transmitir partes de documentos, y actualizar p\u00e1ginas Web en el acto.<\/p>\n\n\n\n HTTP<\/a> es un protocolo basado en el principio de cliente-servidor: las peticiones son enviadas por una entidad: el agente del usuario (o un proxy a petici\u00f3n de uno). La mayor\u00eda de las veces el agente del usuario (cliente) es un navegador Web, pero podr\u00eda ser cualquier otro programa, como por ejemplo un programa-robot, que explore la Web, para adquirir datos de su estructura y contenido para uso de un buscador de Internet.<\/p>\n\n\n\n Cada petici\u00f3n individual se env\u00eda a un servidor, el cu\u00e1l la gestiona y responde. Entre cada petici\u00f3n<\/em> y respuesta<\/em>, hay varios intermediarios, normalmente denominados proxies<\/a>, los cuales realizan distintas funciones, como: gateways o caches<\/a>.<\/p>\n\n\n\n En realidad, hay m\u00e1s elementos intermedios, entre un navegador y el servidor que gestiona su petici\u00f3n: hay otros tipos de dispositivos: como routers<\/em>, modems<\/em> … Es gracias a la arquitectura en capas de la Web, que estos intermediarios, son transparentes al navegador y al servidor, ya que HTTP<\/a> se apoya en los protocolos de red y transporte. HTTP<\/a> es un protocolo de aplicaci\u00f3n, y por tanto se apoya sobre los anteriores. Aunque para diagnosticar problemas en redes de comunicaci\u00f3n, las capas inferiores son irrelevantes para la definici\u00f3n del protocolo HTTP<\/a> .<\/p>\n\n\n\n El agente del usuario, es cualquier herramienta que actu\u00e9 en representaci\u00f3n del usuario. Esta funci\u00f3n es realizada en la mayor parte de los casos por un navegador Web. Hay excepciones, como el caso de programas espec\u00edficamente usados por desarrolladores para desarrollar y depurar sus aplicaciones.<\/p>\n\n\n\n El navegador es siempre<\/strong> el que inicia una comunicaci\u00f3n (petici\u00f3n), y el servidor nunca la comienza (hay algunos mecanismos que permiten esto, pero no son muy habituales).<\/p>\n\n\n\n Para poder mostrar una p\u00e1gina Web, el navegador env\u00eda una petici\u00f3n de documento HTML<\/a> al servidor. Entonces procesa este documento, y env\u00eda m\u00e1s peticiones para solicitar scripts, hojas de estilo (CSS<\/a>), y otros datos que necesite (normalmente v\u00eddeos y\/o im\u00e1genes). El navegador, une todos estos documentos y datos, y compone el resultado final: la p\u00e1gina Web. Los scripts, los ejecuta tambi\u00e9n el navegador, y tambi\u00e9n pueden generar m\u00e1s peticiones de datos en el tiempo, y el navegador, gestionar\u00e1 y actualizar\u00e1 la p\u00e1gina Web en consecuencia.<\/p>\n\n\n\n Una p\u00e1gina Web, es un documento de hipertexto (HTTP<\/a>), luego habr\u00e1 partes del texto en la p\u00e1gina que puedan ser enlaces (links<\/a>) que pueden ser activados (normalmente al hacer click sobre ellos) para hacer una petici\u00f3n de una nueva p\u00e1gina Web, permitiendo as\u00ed dirigir su agente de usuario y navegar por la Web. El navegador, traduce esas direcciones en peticiones de HTTP, e interpretara y procesar\u00e1 las respuestas HTTP, para presentar al usuario la p\u00e1gina Web que desea.<\/p>\n\n\n\n Al otro lado del canal de comunicaci\u00f3n, est\u00e1 el servidor, el cual \u00absirve\u00bb<\/em> los datos que ha pedido el cliente. Un servidor conceptualmente es una unica entidad, aunque puede estar formado por varios elementos, que se reparten la carga de peticiones, (load balancing), u otros programas, que gestionan otros computadores (como cache, bases de datos, servidores de correo electr\u00f3nico, …), y que generan parte o todo el documento que ha sido pedido.<\/p>\n\n\n\n Un servidor no tiene que ser necesariamente un \u00fanico equipo f\u00edsico, aunque si que varios servidores pueden estar funcionando en un \u00fanico computador. En el est\u00e1ndar HTTP\/1.1 y \n\n\n<\/ins>\n\n (adsbygoogle = window.adsbygoogle || []).push({});\n\n<\/p>\n\n\n\n Entre el cliente y el servidor, adem\u00e1s existen distintos dispositivos que gestionan los mensajes HTTP. Dada la arquitectura en capas de la Web, la mayoria de estos dispositivos solamente gestionan estos mensajes en los niveles de protocolo inferiores: capa de transporte, capa de red o capa f\u00edsica, siendo as\u00ed transparentes para la capa de comunicaciones de aplicaci\u00f3n del HTTP, adem\u00e1s esto aumenta el rendimiento de la comunicaci\u00f3n. Aquellos dispositivos, que s\u00ed operan procesando la capa de aplicaci\u00f3n son conocidos como proxies. Estos pueden ser transparentes, o no (modificando las peticiones que pasan por ellos), y realizan varias funciones:<\/p>\n\n\n\n Incluso con el incremento de complejidad, que se produjo en el desarrollo de la versi\u00f3n del protocolo HTTP\/2, en la que se encapsularon los mensajes, HTTP esta pensado y desarrollado para ser le\u00eddo y f\u00e1cilmente interpretado por las personas, haciendo de esta manera m\u00e1s facil la depuraci\u00f3n de errores, y reduciendo la curva de aprendizaje para las personan que empieza a trabajar con \u00e9l.<\/p>\n\n\n\n Presentadas en la versi\u00f3n HTTP\/1.0, las cabeceras de HTTP, han hecho que este protocolo sea f\u00e1cil de ampliar y de experimentar con \u00e9l. Funcionalidades nuevas pueden desarrollarse, sin m\u00e1s que un cliente y su servidor, comprendan la misma sem\u00e1ntica sobre las cabeceras de HTTP.<\/p>\n\n\n\n HTTP es un protocolo sin estado, es decir: no guarda ning\u00fan dato entre dos peticiones en la m\u00edsma sesi\u00f3n. Esto crea problem\u00e1ticas, en caso de que los usuarios requieran interactuar con determinadas p\u00e1ginas Web de forma ordenada y coherente, por ejemplo, para el uso de \u00abcestas de la compra\u00bb en p\u00e1ginas que utilizan en comercio electr\u00f3nico. Pero, mientras HTTP ciertamente es un protocolo sin estado, el uso de HTTP cookies, si permite guardar datos con respecto a la sesi\u00f3n de comunicaci\u00f3n. Usando la capacidad de ampliaci\u00f3n del protocolo HTTP, las cookies permiten crear un contexto com\u00fan para cada sesi\u00f3n de comunicaci\u00f3n.<\/p>\n\n\n\n Una conexi\u00f3n se gestiona al nivel de la capa de trasporte, y por tanto queda fuera del alcance del protocolo HTTP. A\u00fan con este factor, HTTP no necesita que el protocolo que lo sustenta mantenga una conexi\u00f3n continua entre los participantes en la comunicaci\u00f3n, solamente necesita que sea un protocolo fiable o que no pierda mensajes (como m\u00ednimo, en todo caso, un protocolo que sea capaz de detectar que se ha pedido un mensaje y reporte un error). De los dos protocolos m\u00e1s comunes en Internet, TCP es fiable, mientras que UDP, no lo es. Por lo tanto HTTP, se apoya en el uso del protocolo TCP, que est\u00e1 orientado a conexi\u00f3n, aunque una conexi\u00f3n continua no es necesaria siempre.<\/p>\n\n\n\n En la versi\u00f3n del protocolo HTTP\/1.0, habr\u00eda una conexi\u00f3n TCP por cada petici\u00f3n\/respuesta intercambiada, presentando esto dos grandes inconvenientes: abrir y crear una conexi\u00f3n requiere varias rondas de mensajes y por lo tanto resultaba lento. Esto ser\u00eda m\u00e1s eficiente si se mandaran varios mensajes.<\/p>\n\n\n\n Para atenuar estos inconvenientes, la versi\u00f3n del protocolo HTTP\/1.1 present\u00f3 el ‘pipelining’ y las conexiones persistentes: el protocolo TCP que lo transmit\u00eda en la capa inferior se pod\u00eda controlar parcialmente, mediante la cabecera ‘Connection’. La versi\u00f3n del protocolo HTTP\/2 fue m\u00e1s all\u00e1 y usa multiplexaci\u00f3n de mensajes sobre un \u00fanica conexi\u00f3n, siendo as\u00ed una comunicaci\u00f3n m\u00e1s eficiente.<\/p>\n\n\n\n Todav\u00eda hoy se sigue investigando y desarrollando para conseguir un protocolo de transporte m\u00e1s conveniente para el HTTP. Por ejemplo, Google est\u00e1 experimentado con QUIC<\/a>, que se apoya en el protocolo UDP y presenta mejoras en la fiabilidad y eficiencia de la comunicaci\u00f3n.<\/p>\n\n\n\n La caracter\u00edstica del protocolo HTTP de ser ampliable, ha permitido que durante su desarrollo se hayan implementado m\u00e1s funciones de control y funcionalidad sobre la Web: cach\u00e9 o m\u00e9todos de identificaci\u00f3n o autentificaci\u00f3n fueron temas que se abordaron pronto en su historia. Al contrario la relajaci\u00f3n de la restricci\u00f3n de origen solo se ha abordado en los a\u00f1os de la d\u00e9cada de 2010.<\/p>\n\n\n\n Se presenta a continuaci\u00f3n una lista con los elementos que se pueden controlar con el protocolo HTTP:<\/p>\n\n\n\n Cuando el cliente quiere comunicarse con el servidor, tanto si es directamente con \u00e9l, o a trav\u00e9s de un proxy intermedio, realiza los siguientes pasos:<\/p>\n\n\n\n Si est\u00e1 activado el HTTP pipelining<\/em>, varias peticiones pueden enviarse sin tener que esperar que la primera respuesta haya sido satisfecha. Este procedimiento es dif\u00edcil de implementar en las redes de computadores actuales, donde se mezclan software antiguos y modernos. As\u00ed que el HTTP pipelining<\/em> ha sido substituido en HTTP\/2 por el multiplexado de varias peticiones en una sola trama<\/p>\n\n\n\n En las versiones del protocolo HTTP\/1.1 y anteriores los mensajes eran de formato texto y eran totalmente comprensibles directamente por una persona. En HTTP\/2, los mensajes estan estructurados en un nuevo formato binario y las tramas permiten la compresi\u00f3n de las cabeceras y su multiplexaci\u00f3n. As\u00ed pues, incluso si solamente parte del mensaje original en HTTP se env\u00eda en este formato, la sematica de cada mensaje es la misma y el cliente puede formar el mensaje original en HTTP\/1.1. Luego, es posible interpretar los mensajes HTTP\/2 en el formato de HTTP\/1.1.<\/p>\n\n\n\n Existen dos tipos de mensajes HTTP: peticiones y respuestas, cada uno sigue su propio formato.<\/p>\n\n\n\n Un ejemplo de petici\u00f3n HTTP:<\/p>\n\n\n\n Una petici\u00f3n de HTTP, est\u00e1 formado por los siguientes campos:<\/p>\n\n\n\n Un ejemplo de repuesta:<\/p>\n\n\n\n Las respuestas est\u00e1n formadas por los siguientes campos:<\/p>\n\n\n\n El protocolo HTTP es un protocolo ampliable y f\u00e1cil de usar. Su estructura cliente-servidor, junto con la capacidad para usar cabeceras, permite a este protocolo evolucionar con las nuevas y futuras aplicaciones en Internet.<\/p>\n\n\n\n Aunque la versi\u00f3n del protocolo HTTP\/2 a\u00f1ade algo de complejidad, al utilizar un formato en binario, esto aumenta su rendimiento, y la estructura y semantica de los mensajes es la misma desde la versi\u00f3n HTTP\/1.0. El flujo de comunicaciones en una sesi\u00f3n es sencillo y puede ser f\u00e1cilmente estudiado e investigado con un simple monitor de mensajes HTTP<\/a>.<\/p>\n\n\n\n Evoluci\u00f3n del protocolo HTTP<\/a><\/strong><\/p>\n\n\n\nresource:<\/code> en vez de http<\/code> son usados por Firefox y algunas extensiones del navegador para cargar recursos internamente, pero parte de la informaci\u00f3n tambi\u00e9n est\u00e1 disponible para los sitios a los que se conecta el navegador.Separaci\u00f3n de la identidad y la localizaci\u00f3n de un recurso: la cabecera Alt-Svc<\/a><\/p>\n\n\n\nAlt-Svc<\/code><\/a>.Tipos MIME<\/a><\/p>\n\n\n\nContent-Type<\/code><\/a>, y el est\u00e1ndar MIME.Elecci\u00f3n de URLs: www y no-www<\/a><\/p>\n\n\n\nAccept-<\/code> como medio para notificar al navegador, el formato, lenguaje, o codificaci\u00f3n que prefiere. En este art\u00edculo se explica el este proceso, como debe actuar el servidor, y como se elige la respuesta m\u00e1s apropiada.<\/p>\n\n\n\n![\"\"](\"https:\/\/nicolas.cat\/wp-content\/uploads\/2024\/05\/desarrollador-comprobando-codigo-programacion@3x-scaled-1-1024x683.jpg\")
<\/figure>\n\n\n\nGeneralidades del protocolo HTTP<\/h1>\n\n\n\n
![\"A](\"https:\/\/developer.mozilla.org\/es\/docs\/Web\/HTTP\/Overview\/fetching_a_page.png\")
<\/figure>\n\n\n\n![\"HTTP](\"https:\/\/developer.mozilla.org\/es\/docs\/Web\/HTTP\/Overview\/http-layers.png\")
<\/p>\n\n\n\nArquitectura de los sistemas basados en HTTP<\/a><\/h2>\n\n\n\n
![\"Client](\"https:\/\/developer.mozilla.org\/es\/docs\/Web\/HTTP\/Overview\/client-server-chain.png\")
<\/figure>\n\n\n\nCliente: el agente del usuario<\/a><\/h3>\n\n\n\n
El servidor Web<\/a><\/h3>\n\n\n\n
Host<\/code><\/a> , pueden incluso compartir la misma direcci\u00f3n de IP.<\/p>\n\n\n\nProxies<\/a><\/h3>\n\n\n\n
\n
\n
Caracter\u00edsticas clave del protocolo HTTP<\/a><\/h2>\n\n\n\n
HTTP es sencillo<\/a><\/h3>\n\n\n\n
HTTP es extensible<\/a><\/h3>\n\n\n\n
HTTP es un protocolo con sesiones, pero sin estados<\/a><\/h3>\n\n\n\n
HTTP y conexiones<\/a><\/h3>\n\n\n\n
\u00bfQu\u00e9 se puede controlar con HTTP?<\/a><\/h2>\n\n\n\n
\n
\n
WWW-Authenticate<\/code><\/a>, o estableciendo una sesi\u00f3n especifica mediante el uso de HTTP cookies<\/a>.<\/li>\n\n\n\nFlujo de HTTP<\/a><\/h2>\n\n\n\n
\n
\n
GET \/ HTTP\/1.1 Host: developer.mozilla.org Accept-Language: fr<\/code><\/li>\n\n\n\nHTTP\/1.1 200 OK Date: Sat, 09 Oct 2010 14:28:02 GMT Server: Apache Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT ETag: \"51142bc1-7449-479b075b2891b\" Accept-Ranges: bytes Content-Length: 29769 Content-Type: text\/html <!DOCTYPE html... (here comes the 29769 bytes of the requested web page)<\/code><\/li>\n\n\n\nMensajes HTTP<\/a><\/h2>\n\n\n\n
Peticiones<\/a><\/h3>\n\n\n\n
![\"A](\"https:\/\/developer.mozilla.org\/es\/docs\/Web\/HTTP\/Overview\/http_request.png\")
<\/figure>\n\n\n\n\n
\n
GET<\/code><\/a>, POST<\/code><\/a> o un nombre como: OPTIONS<\/code><\/a> o HEAD<\/code><\/a>, que defina la operaci\u00f3n que el cliente quiera realizar. El objetivo de un cliente, suele ser una petici\u00f3n de recursos, usando GET, o presentar un valor de un formulario HTML<\/a>, usando POST, aunque en otras ocasiones puede hacer otros tipos de peticiones.<\/li>\n\n\n\nhttp:\/\/<\/code>), el dominio<\/a> (aqu\u00ed developer.mozilla.org<\/code>), o el puerto<\/a> TCP (aqu\u00ed el 80).<\/li>\n\n\n\nRespuestas<\/a><\/h3>\n\n\n\n
![\"\"](\"https:\/\/developer.mozilla.org\/es\/docs\/Web\/HTTP\/Overview\/http_response.png\")
<\/figure>\n\n\n\n\n
\n
Conclusi\u00f3n<\/a><\/h2>\n\n\n\n