El protocolo HTTP/1.1 fue pensado en su momento para proporcionar
simplicidad de implementación y accesibilidad sin tener en cuenta el
rendimiento de la aplicación. Por ello, le fue asignado al grupo de
trabajo HTTPbis del IETF (Internet Engineering Task Force) el
desarrollo de la nueva versión de este protocolo. Este grupo para dicho
desarrollo tuvo en cuenta el protocolo SPDY de Google, además de la
propuesta de HTTP Speed+Mobility de Microsoft basada en SPDY y el
documento Network-Friendly HTTP Upgrade de este mismo grupo presentado
en marzo de 2012.
Los objetivos propuestos para HTTP/2.0 abarcan la multiplexación de la conexión de forma asíncrona, la compresión de cabeceras y la posibilidad de realizar múltiples peticiones HTTP en una única conexión TCP, sin necesidad de esperar la respuesta correspondiente a cada petición (HTTP Pipelining).
Tras dos reuniones del grupo de trabajo HTTPbis y de la publicación del cuarto borrador del documento de la propuesta para HTTP/2.0, el grupo de trabajo de Katana Project de Microsoft ha desarrollado y ha hecho público el proyecto del primer prototipo de servidor HTTP/2.0 basándose en lo establecido en dicho documento.
También han habilitado para pruebas dos servidores en el Microsoft cloudapp. Uno de ellos dedicado a conexiones http y otro a conexiones https. El acceso a dichos servidores para poder colaborar con las pruebas de esta nueva implementación puede hacerse a través de las siguientes URL:
Estas URL solo responderán a clientes HTTP/2.0. Para participar en
estas pruebas es necesario descargar el código publicado por Katana
Project en GitHub.
En él se puede encontrar tanto el cliente como el servidor de esta
versión por si quisieran hacerse pruebas locales, pero siempre
utilizando el cliente contenido en el proyecto.
Una vez ejecutado el servidor solo mostrará el siguiente mensaje.
Una vez ejecutado el servidor solo mostrará el siguiente mensaje.
Imagen 1: Consola del servidor.
Una vez ejecutado el cliente se obtiene la siguiente consola de comandos.
Imagen 2: Consola del cliente.
Si se realiza una petición sencilla, como por ejemplo solicitar la información de los ficheros contenidos en el servidor con la instrucción DIR, se puede observar información relevante a la solicitud realizada. En este caso concreto esta información son mensajes acerca de si el proceso de negociación tuvo o no éxito, el final del proceso de transferencia y los bytes recibidos como respuesta.
Imagen 3: Petición del contenido del servidor.
La petición anterior (DIR http://localhost:8080/) recibe el fichero index.html que está almacenado en el servidor. Este no es más que una lista de archivos contenidos en el directorio root del servidor. De igual manera, en la consola de comandos del servidor puede observarse cómo es recibida la petición y el intercambio de información que ésta genera.
Imagen 4: Petición recibida por el servidor.
Si se captura la comunicación entre el cliente y el servidor pueden
observarse las tramas generadas en dicha comunicación. El proceso de
negociación es el siguiente:
-
En la primera petición HTTP/1.1 el cliente solicita al servidor actualizar a HTTP-DRAFT-04/2.0 (Punto 1 de la siguiente imagen).
-
Luego el servidor responde a la solicitud de actualización con un código 101 – Switching Protocols (Punto 2 de la siguiente imagen).
Una vez finalizado el proceso de negociación se observa cómo el resto
de la comunicación se lleva a cabo bajo el protocolo HTTP/2.0 (Punto 3
de la siguiente imagen).
Imagen 5: Comunicación HTTP/2.0.
La petición anterior es distinta de un proceso normal de una petición
HTTP/1.1 en la cual no se realiza ningún proceso de negociación y en
cada una de las peticiones/respuestas es incluida la cabecera
correspondiente a este protocolo.
Imagen 6: Comunicación HTTP/1.1.
Fuente: Windows Técnico
0 comentarios:
Publicar un comentario