¿Qué es el HTTP?

Todas las di­re­c­cio­nes en Internet comienzan por http:// (o https://). Estas siglas hacen re­fe­re­n­cia al protocolo HTTP, que es el que utiliza el navegador para acceder a una página web. ¿Qué es HTTP, en qué se di­fe­re­n­cian las distintas versiones y qué otros conceptos están re­la­cio­na­dos con el protocolo?

HTTP son las siglas de Hypertext Transfer Protocol, es decir, Protocolo de Tra­n­s­fe­re­n­cia de Hi­pe­r­te­x­to. Este concepto es uno de los que Tim Berners-Lee de­sa­rro­lló en el CERN (Suiza) y formaron la base de la World Wide Web: los otros dos son HTML y URI. Mientras que HTML (Hypertext Markup Language) define la es­tru­c­tu­ra de las páginas web, la dirección URL (Uniform Resource Locator), una forma derivada del URI, define cómo se localiza a un recurso (p. ej., una página web) en Internet. El protocolo HTTP, en cambio, regula cómo el servidor envía este recurso al cliente.

Pero ¿qué significa hi­pe­r­te­x­to, ese término que forma parte de las siglas HTTP y HTML? Se trata de un concepto que en realidad todos conocemos: el enlace a otros archivos, como los hi­pe­re­n­la­ces que se usan en las páginas web para redirigir a otras páginas.

Cuando escribes una dirección web en tu navegador y se abre la página que deseas, es porque tu navegador se ha co­mu­ni­ca­do con el servidor web por HTTP. Dicho de otra manera, el protocolo HTTP es el código o lenguaje en el que el navegador le comunica al servidor qué página quiere vi­sua­li­zar.

Cuando se creó, el protocolo HTTP solo servía para solicitar do­cu­me­n­tos HTML a un servidor web. Hoy en día, en cambio, se usa con gran variedad de fines:

• Los na­ve­ga­do­res usan HTTP para solicitar cualquier tipo de archivo habitual en las webs modernas: de texto, de vídeo, de código de pro­gra­ma­ción, etc.
• Los programas de apli­ca­ción utilizan HTTP para cargar archivos y ac­tua­li­za­cio­nes de se­r­vi­do­res lejanos.
• La API basada en REST es una solución que utiliza HTTP para controlar servicios web.
• Otra te­c­no­lo­gía que se basa en HTTP es WebDAV.
• En la co­mu­ni­ca­ción de máquina a máquina se utiliza HTTP como protocolo de co­mu­ni­ca­ción entre servicios web.
• Los re­pro­du­c­to­res mu­l­ti­me­dia también utilizan HTTP.
• Las ope­ra­cio­nes de acceso a bases de datos en la web y, por lo tanto, también las ope­ra­cio­nes CRUD, pueden rea­li­zar­se también mediante HTTP.

La historia de HTTP empezó en 1989, cuando Tim Berners-Lee y su equipo del CERN (Suiza) empezaron a de­sa­rro­llar la World Wide Web. La versión inicial de HTTP fue bautizada con el número de versión 0.9, consistía en una sola línea y solo permitía solicitar un archivo HTML del servidor cada vez.

El servidor entonces no hacía más que tra­n­s­fe­rir el archivo so­li­ci­ta­do, de manera que esta versión del protocolo solo podía manejar archivos HTML.

En 1996, la Internet En­gi­nee­ri­ng Task Force (IETF) describió, en el memorando RFC1945, la versión HTTP/1 como una simple propuesta. Esta versión incluía un header con el que se podía es­pe­ci­fi­car tanto la solicitud del cliente, como la respuesta del servidor. Entre otras cosas, se introdujo el campo de header llamado Content-Type, que permitía tra­n­s­fe­rir otros tipos de archivos que no fuesen HTML. En resumen, esta nueva versión del protocolo HTTP tenía las si­guie­n­tes ca­ra­c­te­rí­s­ti­cas:

• Conexión efímera: el cliente establece una conexión con el servidor, envía su solicitud y el servidor responde: una vez lo ha hecho, la conexión se termina. Para hacer una nueva solicitud, el cliente ha de volver a es­ta­ble­cer una conexión, lo cual es costoso porque las páginas web suelen estar formadas de numerosos archivos que deben recogerse mediante so­li­ci­tu­des uno a uno.
• Sin estado: ambas partes de la co­mu­ni­ca­ción, el cliente y el servidor, se olvidan enseguida el uno del otro. Así, cuando el cliente vuelve a es­ta­ble­cer contacto con el servidor, este no recuerda que dicho cliente ya le ha enviado so­li­ci­tu­des antes.
• In­de­pe­n­die­n­te del tipo de archivo: HTTP permite tra­n­s­fe­rir todo tipo de archivos, siempre y cuando ambas partes sepan cómo manejar el tipo en cuestión.

En 1997, se publicó la versión HTTP/1.1, descrita en el memorando RFC2068 y co­n­si­de­ra­da como el primer estándar oficial. Esta versión se sigue usando hoy en día y presenta cambios im­po­r­ta­n­tes respecto a HTTP/1:

• Keepalive: el cliente puede decidir mantener la conexión más allá de la solicitud (pe­r­si­s­te­nt co­n­ne­c­tion) añadiendo al header el comando keepalive (mantener con vida).
• HTTP pi­pe­li­ni­ng: esta técnica permite al cliente enviar la siguiente solicitud sin tener que esperar a recibir la respuesta de la primera.
• En chats, el navegador puede ac­tua­li­zar la ventana usando el tipo MIME multipart/replace.
• También se pueden tra­n­s­fe­rir datos del cliente al servidor.
• Con el nuevo método TRACE, puede ra­s­trear­se la ruta entre el cliente y el servidor web.
• Caché: existen nuevos me­ca­ni­s­mos para guardar contenido te­m­po­ra­l­me­n­te.
• Host: La es­pe­ci­fi­ca­ción host en el header permite que la solicitud HTTP funcione también si hay varios dominios alojados en la misma dirección IP, lo cual es el caso ac­tua­l­me­n­te en la mayoría de páginas webs debido al shared hosting.

Según pasaban los años, las páginas web se volvían cada vez más amplias y complejas. Para cargar una web moderna en el navegador, este tiene que solicitar muchos megabytes de datos y enviar hasta cien so­li­ci­tu­des HTTP. HTTP/1.1 está pensado para procesar so­li­ci­tu­des una tras otra en una misma conexión, de manera que cuanto más compleja sea una página web, más tardará en cargarse y mostrarse.

Por esta razón, Google de­sa­rro­lló un nuevo y ex­pe­ri­me­n­tal protocolo, el SPDY o Speedy, que despertó un gran interés entre los de­sa­rro­lla­do­res y permitió que en 2015 se publicara la versión HTTP/2 del protocolo. Este estándar incluye, entre otras, las si­guie­n­tes mejoras, que tienen como objetivo acelerar la carga de las páginas web:

• Datos binarios. El protocolo trabaja con datos binarios en lugar de archivos de texto.
• Multiplex. El cliente y el servidor pueden enviar y procesar varias so­li­ci­tu­des HTTP si­mu­l­tá­nea­me­n­te.
• Co­m­pre­sión. Los headers se comprimen, puesto que suelen ser idénticos en muchas so­li­ci­tu­des HTTP y, de este modo, se evitan las re­du­n­da­n­cias.
• Server Push. Cuando el servidor prevé qué datos le pedirá el cliente, los envía di­re­c­ta­me­n­te a la caché del cliente, sin esperar a recibir la solicitud HTTP co­rre­s­po­n­die­n­te.

La versión HTTP/2 se extendió rá­pi­da­me­n­te y las páginas web con mucho tráfico fueron de las primeras en adoptarla. Ac­tua­l­me­n­te (con fecha de enero de 2020), según W3Techs, un 42 % de las páginas web utilizan la versión HTTP/2.

Un punto débil de todas las versiones de HTTP usadas hasta ahora es el protocolo de control de tra­n­s­mi­sión (TCP) en el que se basan. Este protocolo requiere que el receptor de cada paquete de datos confirme la recepción antes de que pueda enviarse el siguiente paquete. De este modo, basta con que se pierda un paquete para que todos los demás tengan que esperar a que dicho paquete sea tra­n­s­mi­ti­do de nuevo. Entre es­pe­cia­li­s­tas, estos casos son llamados head-of-line blocking.

Para evitarlos, la nueva versión HTTP/3 no fu­n­cio­na­rá con TCP, sino con UDP, que no aplica este tipo de medidas co­rre­c­ti­vas. A partir de UDP, se ha creado el protocolo QUIC (Quick UDP Internet Co­n­ne­c­tio­ns), que será la base de HTTP/3.

Si bien HTTP/3 aún no ha sido aprobado ofi­cia­l­me­n­te por la IETF, según W3Techs el 3 % de las páginas web ya utilizan QUIC, o, por así decirlo, HTTP/3.