Performance Evaluation of HTTP/2 Window Size in the Internet of Things Diego Londoño1,2 , Maite González1,3 , Sandra Céspedes1,2 , Javier Bustos1,3 , Gabriel Montenegro4 NIC Chile Research Labs1 Departamento de Ingenierı́a Eléctrica, Universidad de Chile2 Departamento de Ciencias de La Computación, Universidad de Chile3 Microsoft4 [diegolondono, maite]@niclabs.cl por cada solicitud, la utilización de una estructura AS- Resumen CII, entre otras. Lo anterior llevó a la publicación de HTTP/2 [Bel15], en 2015, que no sólo suple las caren- Constrained devices are a common factor in cias de la versión previa del protocolo, sino que agrega the Internet of Things (IoT). These devices nuevas funcionalidades con el fin de agilizar la transfe- have limited RAM and ROM memory, redu- rencia de información en las aplicaciones web actuales. ced battery, processing capacity, and trans- Entre las principales caracterı́sticas de HTTP/2 están: mission power. In consequence, these devices La estructura binaria del protocolo, compresión de ca- may not work properly with traditional Inter- beceras, multiplexión de streams, control de flujo, es- net protocols like TCP and HTTP, which we- tablecimiento de prioridades, y Server Push, una nue- re not created for constrained scenarios. Ho- va funcionalidad que permite enviar anticipadamente wever, in 2015 the Internet Engineering Task recursos al cliente, ahorrando ası́ tiempo entre peticio- Force (IETF) published the newest version of nes. the most popular application protocol on the Actualmente, según la IoT Developer Survey 2017, Internet: HTTP/2. It has significant improve- HTTP/1.1 es el protocolo de aplicación más utilizado ments over the previous version, such as bi- en Internet of Things (IoT) [IoT17], campo donde son nary frames, multiplexing of streams, priori- tı́picas la comunicaciones Machine to Machine (M2M) ties, flow control, among others. In this work, entre dispositivos restringidos (con limitada capacidad the parameter of HTTP/2 window size is eva- de procesamiento, poca memoria y/o alimentados por luated in terms of use of CPU, use of memory, baterı́as). Ante tales limitaciones, distintas entidades response times, and energy consumption for han hecho esfuerzos para crear protocolos livianos que constrained devices in IoT. With this work, se adapten a ese tipo de ambientes restringidos. Es ası́ we expect to promote the discussion about the como fueron creados los protocolos de aplicación para utilization of HTTP/2 for IoT and to contri- IoT: Constrained Application Protocol (CoAP) y Mes- bute to an eventual standardization. sage Queue Telemetry Transport (MQTT). A pesar de Key index: Application Layer Protocol, Cons- los esfuerzos de creación de protocolos adecuados a las trained devices, HTTP/2, IETF. necesidades, HTTP sigue siendo el protocolo de comu- nicación más utilizado en el campo, por lo que se ha 1. Introducción llevado a proponer una adaptación de HTTP/2 para IoT. Hypertext Transfer Protocol (HTTP) es un protoco- lo de capa de aplicación que permite la transferencia Dado lo anterior, la propuesta en [Mon17] señala de información a través de la Web. Aunque el pro- que a pesar de que HTTP/2 no fue creado para utili- tocolo existe desde principios de los años noventa, la zarse en dispositivos IoT, es compacto, flexible y con- versión HTTP/1.1, publicada en 1999, ha sido la más figurable, por lo que variando algunos valores en los difundida. Con el paso de los años esta versión em- parámetros de configuración se lograrı́a un funciona- pezó a evidenciar algunas falencias, tales como cabe- miento adecuado del protocolo en condiciones restrin- ceras repetitivas, necesidad de crear una conexión TCP gidas. El Internet draft no define valores exactos, por lo cual se requiere una evaluación de desempeño que lleve Copyright c by the paper’s authors. Copying permitted for pri- a la definición de los valores que tendrı́an los paráme- vate and academic purposes. tros en una versión adaptada a IoT. En este trabajo se evalúa el desempeño de HTTP/2 ventana desde 256 hasta 65535 (el valor por defecto en al variar el tamaño de la ventana de control de flujo, HTTP/2). en términos de uso de CPU, uso de memoria, consumo Considerando la fórmula para calcular el tamaño de energético y tiempos de respuesta, con miras a encon- la muestra en una población infinita, los resultados ob- trar los primeros valores que servirı́an para adaptar tenidos tienen un 90 % de confianza, aunque hay que HTTP/2 a un entorno restringido. Cabe destacar que resaltar que los resultados dependen en buena medida aunque HTTP/2 no define un algoritmo especı́fico pa- de la implementación de HTTP/2 utilizada. Otras im- ra el control de flujo, el funcionamiento respecto a las plementaciones con mejor o peor desempeño podrı́an ventanas deslizantes es similar al de TCP. La contri- arrojar valores resultantes diferentes, aunque el com- bución de este trabajo radica en describir el compor- portamiento general deberı́a ser similar al del presente tamiento del protocolo en un escenario IoT e ilustrar trabajo. los valores para los cuales se usan mejor los recursos restringidos de los dispositivos empleados en el expe- 3. Resultados rimento. La implementación de HTTP/2 utilizada es Nghttp/2 [Ngh17] y se corre sobre una Raspberry Pi Los resultados de las pruebas experimentales dejan 3 Modelo B. ver el comportamiento de las métricas en el cliente y servidor. En la figura 1 se muestra el comportamien- to de los tiempos de respuesta, tiempo de CPU y el 2. Metodologı́a trabajo requerido por el cliente ante la variación del En el perfil de configuración propuesto en [Mon17], tamaño de la ventana. S e puede ver que cuando la se identifican los parámetros que deberı́an cam- ventana es muy pequeña (256 Bytes), el largo tiem- biar sus valores para un correcto funcionamien- po en el que el servidor recibe paquetes provocan un to del protocolo en entornos de IoT. En este mayor uso de la CPU, y esto se traduce en un mayor trabajo el tamaño de la ventana inicial (SET- trabajo. En la medida que el tamaño de la ventana TINGS INITIAL WINDOW SIZE) es variado y eva- aumenta, los tiempos de respuesta disminuyen al igual luado en términos de uso de CPU, tiempos de res- que el tiempo de CPU. A partir de 4096 Bytes como puesta y consumo energético. tamaño de ventana, el trabajo requerido se estabiliza alrededor de 120 mJ. Nghttp2, una implementación cliente/servidor de HTTP/2 desarrollada en C, ha sido utilizada en este 30 600 trabajo. Esta aplicación se corrió sobre dos Raspberry Pi 3 modelo B, una para el cliente y otra para el ser- Tiempo CPU vidor. Las dos Raspberry se conectaron a través de un Tiempo Resp. Trabajo (mJ) 20 400 Tiempo (s) switch utilizando FastEthernet, formando ası́ una red Trabajo local. El objetivo de usar un medio cableado es concen- trar la evaluación en los dispositivos restringidos y no en el desempeño de una posible red inalámbrica. Por 10 200 otro lado, el consumo energético del cliente se mide utilizando un módulo ACS712 y una Arduino Mega. Este módulo permite medir la corriente del cable que 0 0 suple energéticamente a la Raspberry Pi. Asumiendo 28 210 212 214 216 que el voltaje de alimentación se mantiene en 5 V, la Tamaño Ventana (Bytes) potencia fue calculada como el producto de la corriente y el voltaje. Con los datos de la potencia instantánea Figura 1: Tiempo de Respuesta, Tiempo de CPU y y la duración de cada proceso, se calculó el trabajo Trabajo versus tamaño de ventana en el cliente. requerido para cada caso, tomando como base que la potencia instantánea utilizada por la Raspberry en es- En la figura 2 se muestran los datos obtenidos en el tado de reposo es de 80 mW 0 a 900 mW. servidor. Los tiempos de respuesta y tiempos de uso El servidor web a consultar aloja una página web de CPU tienen un comportamiento similar al del clien- con un index html que contiene un archivo css, dos ar- te. Ambas métricas tienen una tendencia decreciente chivos javascript y cuatro imágenes jpg. Los archivos a medida que aumenta el tamaño de la ventana, has- en conjunto suman alrededor de 7 MB. La metodologı́a ta llegar a 427 ms en el tiempo de CPU y 627 ms en se basa en un cliente que realiza una serie de peticiones tiempo de respuesta cuando la ventana es 65535 Bytes. al servidor (68 en total), mientras se miden datos de En la figura 3 se muestra el porcentaje de uso de uso de CPU, uso de memoria y tiempo de CPU tanto CPU tanto en cliente como en el servidor ante la va- del lado del cliente como del servidor. Además se mide riación de la ventana. La gráfica muestra un comporta- el tiempo de respuesta real y el consumo energético del miento similar en las dos partes, aunque en diferentes cliente variando en cada iteración el parámetro evalua- magnitudes. Hay una relativa estabilidad hasta 4096 do. En el caso del tamaño de la ventana, se evaluó la Bytes, y después de esto el uso aumenta significativa- mente, siendo mayor en el cliente, donde llega a ocu- Según la información recopilada en este estudio, en par el 60 % de capacidad de CPU cuando la ventana términos energéticos el valor sugerido para el tamaño es 65.535 Bytes, mientras que en el servidor es aproxi- de la ventana es 4096 Bytes. Este tamaño puede cam- madamente de un 26 %. biar dinámicamente según las condiciones de la comu- nicación. De esta manera cuando un dispositivo tiene Tiempo Resp una alta carga de trabajo, no tiene suficiente capacidad 20 Tiempo CPU en cuanto a hardware o el canal tiene muchas pérdi- das, el tamaño de la ventana podrı́a reducirse. Si por Tiempo (s) el contrario las condiciones son buenas, el tamaño de la ventana podrı́a aumentar. 10 En este estudio, la variación del número de streams concurrentes también fue evaluada, sin embargo, no se observó una tendencia clara en cuanto a las métri- cas utilizadas. Esto puede deberse a la forma como 0 está constituida la página web. Corresponde a traba- 28 210 212 214 216 jos futuros hacer las pruebas necesarias que permitan Tamaño de ventana evidenciar mejor el efecto de la cantidad de streams concurrentes, ası́ como el impacto de redes inalámbri- Figura 2: Tiempo de Respuesta y Tiempo de CPU ver- cas con pérdidas en el desempeño del protocolo. sus tamaño de ventana en el servidor 5. Trabajo Futuro 60 En futuros trabajos realizaremos una evaluación de Servidor los demás parámetros mencionados en el Internet draft Cliente del perfil de HTTP/2 para IoT [Mon17]. De igual ma- % uso CPU nera se harán pruebas similares en dispositivos tipo 2 40 y 1 según la clasificación de dispositivos restringidos que hace el RFC 7228 [Ker14]. En particular se debe evaluar el desempeño ante la variación de la cantidad de streams con una página web que tenga recursos de 20 tamaños similares cuando los objetos a transmitir son similares en carga. 28 210 212 214 216 Tamaño de ventana 6. Acknowledgements Figura 3: Porcentaje CPU versus tamaño de ventana Este trabajo es parcialmente financiado por el en cliente y servidor proyecto FONDECYT Iniciación 11140045 Institu- to de Sistemas Complejos de Ingenierı́a (CONICYT: De las gráficas 1 y 3 se puede observar que el tra- FB0816). bajo realizado por el cliente y el porcentaje de uso de CPU en el servidor y cliente tienen un punto de quie- Referencias bre alrededor de 4096 Bytes. En ese punto, según los [Ker14] C. Bormann, M. Ersue, and A. Keranen, Terminology datos del cliente, el trabajo es muy similar al que ha- for Constrained-Node Networks, RFC 7228, May 2014. Dis- ce el dispositivo en el valor por defecto del protocolo ponible: http://www.rfc-editor.org/info/rfc7228. (65535 Bytes), sin embargo, el tiempo de CPU aumen- [Bel15] M. Belshe, R. Peon, and M. Thomson, Ed., Hyper- ta un 42.17 % y los tiempos de respuesta aumentan un text Transfer Protocol Version 2 (HTTP/2), RFC 7540, May 299.5 %. 2015. Disponible: https://tools.ietf.org/html/rfc7540. [Mon17] G. Montenegro, S. Cespedes, S. Loreto and R. Simpson., HTTP/2 Configuration Profile for the Internet 4. Conclusiones of Things, Mar 2017. Disponible: https://github.com/h2ot- El tamaño de la ventana tiene un impacto significa- wg/h2ot-profile/blob/master/draft-montenegro-httpbis- h2ot-profile-00.txt. tivo en el desempeño del protocolo HTTP/2 en entor- nos IoT. A medida que aumenta su tamaño, los tiem- [IoT17] IoT Eclipse, IEEE Internet of Things, IoT pos de respuesta y de CPU se acortan, mientras que la Developer Survey 2017, April 2017. Disponible: https://www.slideshare.net/IanSkerrett/iot-developer- potencia instantánea consumida aumenta; sin embar- survey-2017. go, al realizarse los procesos de manera más rápida, el trabajo es menor que cuando la ventana es pequeña. [Ngh17] Nghttp2, HTTP/2 C library and Tools. [Online]. Dis- ponible en: https://github.com/nghttp2/nghttp2. Este comportamiento se evidencia tanto en el cliente como en el servidor.