Constrained devices are a common factor in the Internet of Things (IoT). These devices have limited RAM and ROM memory, reduced battery, processing capacity, and transmission power. In consequence, these devices may not work properly with traditional Internet protocols like TCP and HTTP, which were not created for constrained scenarios. However, in 2015 the Internet Engineering Task Force (IETF) published the newest version of the most popular application protocol on the Internet: HTTP/2. It has signi cant improvements over the previous version, such as binary frames, multiplexing of streams, priorities, ow control, among others. In this work, the parameter of HTTP/2 window size is evaluated in terms of use of CPU, use of memory, response times, and energy consumption for constrained devices in IoT. With this work, we expect to promote the discussion about the utilization of HTTP/2 for IoT and to contribute to an eventual standardization.
Hypertext Transfer Protocol (HTTP) es un protocolo de capa de aplicacion que permite la transferencia de informacion a traves de la Web. Aunque el protocolo existe desde principios de los an~os noventa, la version HTTP/1.1, publicada en 1999, ha sido la mas difundida. Con el paso de los an~os esta version empezo a evidenciar algunas falencias, tales como cabeceras repetitivas, necesidad de crear una conexion TCP Copyright c by the paper's authors. Copying permitted for private and academic purposes. por cada solicitud, la utilizacion de una estructura ASCII, entre otras. Lo anterior llevo a la publicacion de HTTP/2 [Bel15], en 2015, que no solo suple las carencias de la version previa del protocolo, sino que agrega nuevas funcionalidades con el n de agilizar la transferencia de informacion en las aplicaciones web actuales. Entre las principales caracter sticas de HTTP/2 estan: La estructura binaria del protocolo, compresion de cabeceras, multiplexion de streams, control de ujo, establecimiento de prioridades, y Server Push, una nueva funcionalidad que permite enviar anticipadamente recursos al cliente, ahorrando as tiempo entre peticiones.
Actualmente, segun la IoT Developer Survey 2017, HTTP/1.1 es el protocolo de aplicacion mas utilizado en Internet of Things (IoT) [IoT17], campo donde son t picas la comunicaciones Machine to Machine (M2M) entre dispositivos restringidos (con limitada capacidad de procesamiento, poca memoria y/o alimentados por bater as). Ante tales limitaciones, distintas entidades han hecho esfuerzos para crear protocolos livianos que se adapten a ese tipo de ambientes restringidos. Es as como fueron creados los protocolos de aplicacion para IoT: Constrained Application Protocol (CoAP) y Message Queue Telemetry Transport (MQTT). A pesar de los esfuerzos de creacion de protocolos adecuados a las necesidades, HTTP sigue siendo el protocolo de comunicacion mas utilizado en el campo, por lo que se ha llevado a proponer una adaptacion de HTTP/2 para IoT.
Dado lo anterior, la propuesta en [Mon17] sen~ala que a pesar de que HTTP/2 no fue creado para utilizarse en dispositivos IoT, es compacto, exible y congurable, por lo que variando algunos valores en los parametros de con guracion se lograr a un funcionamiento adecuado del protocolo en condiciones restringidas. El Internet draft no de ne valores exactos, por lo cual se requiere una evaluacion de desempen~o que lleve a la de nicion de los valores que tendr an los parametros en una version adaptada a IoT. ventana desde 256 hasta 65535 (el valor por defecto en HTTP/2).
Considerando la formula para calcular el taman~o de la muestra en una poblacion in nita, los resultados obtenidos tienen un 90 % de con anza, aunque hay que resaltar que los resultados dependen en buena medida de la implementacion de HTTP/2 utilizada. Otras implementaciones con mejor o peor desempen~o podr an arrojar valores resultantes diferentes, aunque el comportamiento general deber a ser similar al del presente trabajo. 3.
Los resultados de las pruebas experimentales dejan ver el comportamiento de las metricas en el cliente y servidor. En la gura 1 se muestra el comportamiento de los tiempos de respuesta, tiempo de CPU y el trabajo requerido por el cliente ante la variacion del taman~o de la ventana. S e puede ver que cuando la ventana es muy pequen~a (256 Bytes), el largo tiempo en el que el servidor recibe paquetes provocan un mayor uso de la CPU, y esto se traduce en un mayor trabajo. En la medida que el taman~o de la ventana aumenta, los tiempos de respuesta disminuyen al igual que el tiempo de CPU. A partir de 4096 Bytes como taman~o de ventana, el trabajo requerido se estabiliza alrededor de 120 mJ.
En este trabajo se evalua el desempen~o de HTTP/2 al variar el taman~o de la ventana de control de ujo, en terminos de uso de CPU, uso de memoria, consumo energetico y tiempos de respuesta, con miras a encontrar los primeros valores que servir an para adaptar HTTP/2 a un entorno restringido. Cabe destacar que aunque HTTP/2 no de ne un algoritmo espec co para el control de ujo, el funcionamiento respecto a las ventanas deslizantes es similar al de TCP. La contribucion de este trabajo radica en describir el comportamiento del protocolo en un escenario IoT e ilustrar los valores para los cuales se usan mejor los recursos restringidos de los dispositivos empleados en el experimento. La implementacion de HTTP/2 utilizada es Nghttp/2 [Ngh17] y se corre sobre una Raspberry Pi 3 Modelo B. 2.
En el per l de con guracion propuesto en [Mon17], se identi can los parametros que deber an cambiar sus valores para un correcto funcionamiento del protocolo en entornos de IoT. En este trabajo el taman~o de la ventana inicial (SETTINGS INITIAL WINDOW SIZE) es variado y evaluado en terminos de uso de CPU, tiempos de respuesta y consumo energetico.
Nghttp2, una implementacion cliente/servidor de HTTP/2 desarrollada en C, ha sido utilizada en este trabajo. Esta aplicacion se corrio sobre dos Raspberry Pi 3 modelo B, una para el cliente y otra para el servidor. Las dos Raspberry se conectaron a traves de un switch utilizando FastEthernet, formando as una red local. El objetivo de usar un medio cableado es concentrar la evaluacion en los dispositivos restringidos y no en el desempen~o de una posible red inalambrica. Por otro lado, el consumo energetico del cliente se mide utilizando un modulo ACS712 y una Arduino Mega. Este modulo permite medir la corriente del cable que suple energeticamente a la Raspberry Pi. Asumiendo que el voltaje de alimentacion se mantiene en 5 V, la potencia fue calculada como el producto de la corriente y el voltaje. Con los datos de la potencia instantanea y la duracion de cada proceso, se calculo el trabajo requerido para cada caso, tomando como base que la potencia instantanea utilizada por la Raspberry en estado de reposo es de 80 mW 0 a 900 mW.
El servidor web a consultar aloja una pagina web con un index html que contiene un archivo css, dos archivos javascript y cuatro imagenes jpg. Los archivos en conjunto suman alrededor de 7 MB. La metodolog a se basa en un cliente que realiza una serie de peticiones al servidor (68 en total), mientras se miden datos de uso de CPU, uso de memoria y tiempo de CPU tanto del lado del cliente como del servidor. Ademas se mide el tiempo de respuesta real y el consumo energetico del cliente variando en cada iteracion el parametro evaluado. En el caso del taman~o de la ventana, se evaluo la 600 400 200 0 ) J m ( o j a b a r T 30 )s 20 ( o p m e iT10 0 28 210 212 214
216
Figura 1: Tiempo de Respuesta, Tiempo de CPU y Trabajo versus taman~o de ventana en el cliente.
En la gura 2 se muestran los datos obtenidos en el servidor. Los tiempos de respuesta y tiempos de uso de CPU tienen un comportamiento similar al del cliente. Ambas metricas tienen una tendencia decreciente a medida que aumenta el taman~o de la ventana, hasta llegar a 427 ms en el tiempo de CPU y 627 ms en tiempo de respuesta cuando la ventana es 65535 Bytes.
En la gura 3 se muestra el porcentaje de uso de CPU tanto en cliente como en el servidor ante la variacion de la ventana. La gra ca muestra un comportamiento similar en las dos partes, aunque en diferentes magnitudes. Hay una relativa estabilidad hasta 4096 Bytes, y despues de esto el uso aumenta signi cativamente, siendo mayor en el cliente, donde llega a ocupar el 60 % de capacidad de CPU cuando la ventana es 65.535 Bytes, mientras que en el servidor es aproximadamente de un 26 %. Figura 2: Tiempo de Respuesta y Tiempo de CPU versus taman~o de ventana en el servidor Figura 3: Porcentaje CPU versus taman~o de ventana en cliente y servidor
De las gra cas 1 y 3 se puede observar que el trabajo realizado por el cliente y el porcentaje de uso de CPU en el servidor y cliente tienen un punto de quiebre alrededor de 4096 Bytes. En ese punto, segun los datos del cliente, el trabajo es muy similar al que hace el dispositivo en el valor por defecto del protocolo (65535 Bytes), sin embargo, el tiempo de CPU aumenta un 42.17 % y los tiempos de respuesta aumentan un 299.5 %.
El taman~o de la ventana tiene un impacto signi cativo en el desempen~o del protocolo HTTP/2 en entornos IoT. A medida que aumenta su taman~o, los tiempos de respuesta y de CPU se acortan, mientras que la potencia instantanea consumida aumenta; sin embargo, al realizarse los procesos de manera mas rapida, el trabajo es menor que cuando la ventana es pequen~a. Este comportamiento se evidencia tanto en el cliente como en el servidor.
20
0 60 U P C40 o s u % 20
Segun la informacion recopilada en este estudio, en terminos energeticos el valor sugerido para el taman~o de la ventana es 4096 Bytes. Este taman~o puede cambiar dinamicamente segun las condiciones de la comunicacion. De esta manera cuando un dispositivo tiene una alta carga de trabajo, no tiene su ciente capacidad en cuanto a hardware o el canal tiene muchas perdidas, el taman~o de la ventana podr a reducirse. Si por el contrario las condiciones son buenas, el taman~o de la ventana podr a aumentar.
En este estudio, la variacion del numero de streams concurrentes tambien fue evaluada, sin embargo, no se observo una tendencia clara en cuanto a las metricas utilizadas. Esto puede deberse a la forma como esta constituida la pagina web. Corresponde a trabajos futuros hacer las pruebas necesarias que permitan evidenciar mejor el efecto de la cantidad de streams concurrentes, as como el impacto de redes inalambricas con perdidas en el desempen~o del protocolo. 5.
En futuros trabajos realizaremos una evaluacion de los demas parametros mencionados en el Internet draft del per l de HTTP/2 para IoT [Mon17]. De igual manera se haran pruebas similares en dispositivos tipo 2 y 1 segun la clasi cacion de dispositivos restringidos que hace el RFC 7228 [Ker14]. En particular se debe evaluar el desempen~o ante la variacion de la cantidad de streams con una pagina web que tenga recursos de taman~os similares cuando los objetos a transmitir son similares en carga. 6.
Este trabajo es parcialmente nanciado por el proyecto FONDECYT Iniciacion 11140045 Instituto de Sistemas Complejos de Ingenier a (CONICYT: FB0816).