Nowadays, di erent entities are making efforts for standardizing application protocols oriented to Internet of Things (IoT). In this work, the CoAP and HTTP/2 response times in an IoT web environment are evaluated experimentally, varying the channel's tra c and the signal's quality. We explain the motivation to evaluate HTTP2 in IoT environments and describe related works that provide comparisons for IoT protocols. Next, we describe the scenarios employed in our comparisons and analyze the results under variable channel conditions.
Poco tiempo despues de la aparicion del termino Internet de las Cosas (IoT) en 1999, diferentes entidades y consorcios iniciaron la tarea de crear estandares para este nuevo campo de accion. A diferencia del tradicional modelo de conexion entre computadoras, en IoT las maquinas se comunican entre ellas (Machine-toMachine communications o M2M), dichas maquinas pueden tener limitaciones en cuanto a su alimentacion energetica, procesamiento, almacenamiento y potencia de transmision [Ker14]. Las anteriores restricciones han llevado a re-pensar el uso de los protocolos mas difundidos en Internet, como lo son HTTP/1.1 y TCP, y a la creacion de nuevos protocolos optimizados para estos escenarios [Ler12], tales como Constrained Aplication Protocol (CoAP) y Message Queue Telemetry Transport (MQTT).
Por otro lado, siguiendo una logica de no \reinventar la rueda", existen propuestas para hacer las adaptaciones necesarias a escenarios IoT de protocolos ampliamente difundidos en Internet, como HTTP,
Se podr a esperar que por sencillez y su disen~o espec co para IoT, CoAP tenga mejor desempen~o en cuanto a tiempos de respuesta que HTTP/2, dado que este ultimo fue pensado para la web en general y no necesariamente para ambientes restringidos. Surge, entonces, el interrogante >que tan lejos esta HTTP/2 de CoAP? Si HTTP/2 con adaptaciones llegara a tener un desempen~o cercano a CoAP, es decir, aceptable en un escenario restringido de IoT, y dadas las ventajas que ofrece, podr a ser usado masivamente en este campo. Para responder a dicho interrogante, en este trabajo se realizan dos implementaciones, en la primera se tiene un cliente y un servidor HTTP/2. En la segunda, se tiene un cliente CoAP, un proxy CoAP/HTTP y un servidor HTTP1.1. El objetivo es hacer una comparacion de desempen~o teniendo en cuenta los tiempos de respuesta de ambos casos.
En trabajos previos [Tha14, Col14] se comparo el desempen~o de algunos protocolos orientados a IoT, pero no directamente HTTP/2 con CoAP. Los resultados han mostrado como principal conclusion que no hay un protocolo que se desempen~e mejor en todos los escenarios, sino que esto depende de las condiciones de la red. En [Sax15] se demuestra que HTTP/2 tiene mejor desempen~o que HTTP/1.1 en cuanto a tiempos de respuesta.
Este trabajo es un acercamiento a los protocolos de IoT, de cara a una posible adaptacion de HTTP/2 para escenarios restringidos. A partir de este trabajo se espera sentar las bases para de nir los cambios pertinentes que podran incorporarse a una nueva version de HTTP/2. 2
Para la comparacion de desempen~o entre HTTP/2 y CoAP se hizo un montaje experimental, con el n de recopilar la informacion de los tiempos de respuesta promedio de metodos GET y POST en HTTP/2 y CoAP, variando el tra co en el canal y la calidad de la sen~al inalambrica. El numero de peticiones a analizar es de 30 para cada caso.
El montaje para el experimento consiste en dos escenarios, uno para probar el desempen~o de HTTP/2 y otro para una solucion CoAP/HTTP1.1. En el primer caso, el navegador Mozilla Firefox 47.0 se conecta v a WiFi (IEEE 802.15n) a un Acces Point (AP) Cisco WRT160NL. El AP se conecta v a FastEthernet a un PC con una maquina virtual Ubuntu 16.04 en el cual se ejecuta un servidor web Apache 2.4.20.
En el caso del escenario para CoAP/HTTP, se usa como cliente CoAP, Copper 0.18.4.1, un complemento de Mozilla Firefox [Cop16]. Este se conecta v a WiFi al AP, que a su vez se conecta v a FastEthernet al PC donde hay dos maquinas virtuales: una de ellas es un Proxy CoAP/HTTP1.1 llamado Crosscoap [Ibm16] y la otra es un servidor web Apache HTTP1.1. Para ambos escenarios las capturas de tra co se realizan en el computador portatil del cliente utilizando Wireshark. En la gura 1 se muestra un diagrama con las implementaciones.
En cuanto a la calidad de la sen~al, en un primer momento los equipos portatiles tienen l nea de vista con el AP y la potencia recibida en el cliente es de alrededor de -27dBm. Para forzar una reduccion en la calidad de la sen~al, los clientes se ubican fuera de l nea de vista del AP de tal manera que se reduzca la potencia recibida a aproximadamente -85dBm. 3
Los tiempos de respuesta obtenidos del metodo GET para todos los escenarios se muestran en la tabla 1 y los del metodo POST en la tabla 2.
Para crear congestion en el canal inalambrico se emplean otros dos computadores portatiles que inyectan tra co TCP a la red, con ayuda de Iperf [Ipe16]. Uno actua como cliente y otro como servidor. El nivel de congestion se va aumentando gradualmente hasta llegar a 20 solicitudes simultaneas con paquetes de taman~os variables, segun la condicion del canal, y los mismos tres equipos involucrados generan paquetes PING de 2000 KB cada uno, de forma sostenida hacia el AP. En la gura 2 se ilustra el escenario de congestion.
Para ambos metodos cuando la sen~al es buena, CoAP tiene signi cativamente mejores tiempos de respuesta respecto a HTTP/2, independiente del nivel de congestion; esto se debe principalmente a dos razones, la primera es la sencillez de la estructura de los paquetes CoAP frente a los de HTTP/2, lo que agiliza la comunicacion. La segunda razon es porque al utilizar UDP no necesita establecer una conexion de un stream, ni hacer uso de ACKs en la capa de transporte, lo que agiliza el env o de la informacion de capa de aplicacion.
Se debe tener en cuenta que parte del tiempo de respuesta de las peticiones CoAP corresponden al tiempo que se demora el servidor Proxy en hacer la respectiva peticion al servidor Web y que este a su vez responda. En los escenarios implementados, la comunicacion entre estos dos servidores no se ve afectada por la congestion en el canal inalambrico. El servidor Proxy no esta haciendo caching.
Cuando la calidad de la sen~al se deteriora, en todos los casos HTTP/2 tiene mejores tiempos de respuesta, sin embargo hay peticiones GET no respondidas. La razon por la que CoAP reduce signi cativamente su desempen~o es porque la implementacion utilizada de CoAP env a las peticiones GET y POST sobre un mensaje con rmable (CON) con un back-o exponencial que inicia en 2s. El cliente hara hasta cuatro retransmisiones, esperando 2, 4, 8 y 16 segundos respectivamente. Estos tiempos de back-o , si bien aumentan la probabilidad de que el canal se recupere, tambien aumentan considerablemente los tiempos de respuesta de las solicitudes, mientras que las retransmisiones de HTTP/2 son mas rapidas.
La principal afectacion en el desempen~o de HTTP/2 cuando el canal presenta fallas, se da porque se pierden las conexiones TCP, obligando a que se haga el handshaking varias veces, y a que nalmente los tiempos de respuesta aumenten. Esta es una desventaja de HTTP/2 frente a CoAP, en cuanto a procesamiento y tiempos de respuesta, debido a que en este ultimo el handshaking no existe. Una posible solucion a este punto es hacer que HTTP/2 tambien corra sobre UDP [Qui16]. Cabe anotar que Mozilla Firefox tiene implementado HTTP/2 solo sobre TLS, lo cual an~ade una capa de complejidad adicional que impacta en el tiempo de respuesta.
En los experimentos, el tipo de informacion que se transmite tanto del servidor al cliente como del cliente al servidor, simula de manera sencilla la informacion arrojada en texto plano por un nodo-sensor. Debido a esto, en un primer momento no se explotan todas las funcionalidades y ventajas que ofrece HTTP/2. Esto lleva a pensar que si se quiere adaptar este protocolo a un escenario de IoT, se debera tener en cuenta que la informacion manejada puede ser mas sencilla y esporadica que la de las paginas web tradicionales de la Internet. Por otro lado, los tiempos de respuesta de CoAP podr an mejorar si los tiempos de espera para retransmitir se hacen mas pequen~os, en cuyo caso depende de la implementacion del cliente que se utilice. 4
Los resultados muestran que no hay un protocolo que sea el mejor en todos los escenarios, la eleccion del mas conveniente dependera de las condiciones de los equipos y de la red. En el caso del presente estudio, se obtiene que si el canal es con able, CoAP tiene mejores tiempos de respuesta y cuando el canal tiene perdidas, los tiempos de respuesta son mejores con HTTP/2.
Adicionalmente se determino que el handshaking de TCP aumenta los tiempos de respuesta. Si la sen~al es mala y las conexiones se pierden, el desempen~o de HTTP/2 empeora. Respecto a este tema, hay soluciones propuestas y probadas como QUIC [Qui16], donde HTTP/2 corre sobre UDP. Corresponde a trabajos futuros determinar si esta opcion se desempen~a bien en un ambiente restringido. Esta claro es que la capa de transporte debera tener cambios en IoT.
Tambien se determino que el desempen~o de CoAP se ve deteriorado en redes con perdidas debido al uso de mensajes con rmables (CON) que generan tiempos de espera prolongados para hacer la retransmision.
Si bien el objetivo de este trabajo es evidenciar el desempen~o de CoAP y HTTP/2 de manera experimental frente a escenarios restringidos de IoT, en el escenario web descrito aun no se han utilizado escenarios restringidos. Como trabajo futuro se deberan hacer pruebas de desempen~o similares, pero con equipos con capacidades limitadas y utilizando tecnolog as t picas de redes de sensores y dispositivos IoT, como IEEE 802.15.4. Adicionalmente, en este trabajo se utilizo un Proxy CoAP/HTTP1.1. En un trabajo futuro se espera poder evaluar el desempen~o cuando todo el escenario es CoAP, es decir, sin la existencia de un Proxy.
Los trabajos futuros serviran para poder establecer que adaptaciones o mejoras se le pueden hacer a HTTP/2 de cara a una implementacion en una red con nodos restringidos en sus capacidades, como es de esperarse en un escenario t pico de dispositivos IoT.