Performance Evaluation of CoAP and HTTP/2 in Web Applications Diego Londoño Sandra Céspedes Departamento de Ingenierı́a Eléctrica Departamento de Ingenierı́a Eléctrica NIC Chile Research Labs NIC Chile Research Labs Universidad de Chile Universidad de Chile diegolondono@niclabs.cl scespedes@ing.uchile.cl o su sucesor HTTP/2 [Mon16]. Los argumentos princi- pales que respaldan esta propuesta son tres: seguridad, Abstract interoperabilidad y conocimiento de la tecnologı́a. En cuanto a la seguridad, crear nuevos protocolos y nuevas Nowadays, different entities are making ef- pilas sugiere también nuevas formas de ataques, con el forts for standardizing application protocols agravante de que IoT es un escenario de alto riesgo oriented to Internet of Things (IoT). In this debido a las restricciones de los dispositivos, su am- work, the CoAP and HTTP/2 response times plia distribución geográfica y la posibilidad de fácil in an IoT web environment are evaluated ex- acceso fı́sico por parte de los atacantes. Respecto a perimentally, varying the channel’s traffic and la interoperabilidad, tener muchas pilas y protocolos the signal’s quality. We explain the motiva- puede dificultar este pilar de la Internet. Por último, tion to evaluate HTTP2 in IoT environments utilizar la tecnologı́a mejor conocida tiene ventajas en and describe related works that provide com- cuanto a que hay más implementaciones hechas, am- parisons for IoT protocols. Next, we describe pliamente probadas y mejoradas con el tiempo, al- the scenarios employed in our comparisons gunas de ellas Open Source; también hay más gente and analyze the results under variable channel con los conocimientos necesarios para trabajar con ella conditions. [Mon16]. Se podrı́a esperar que por sencillez y su diseño es- 1 Introducción pecı́fico para IoT, CoAP tenga mejor desempeño en cuanto a tiempos de respuesta que HTTP/2, dado que Poco tiempo después de la aparición del término Inter- este último fue pensado para la web en general y no net de las Cosas (IoT) en 1999, diferentes entidades y necesariamente para ambientes restringidos. Surge, consorcios iniciaron la tarea de crear estándares para entonces, el interrogante ¿qué tan lejos está HTTP/2 este nuevo campo de acción. A diferencia del tradi- de CoAP? Si HTTP/2 con adaptaciones llegara a tener cional modelo de conexión entre computadoras, en IoT un desempeño cercano a CoAP, es decir, aceptable las máquinas se comunican entre ellas (Machine-to- en un escenario restringido de IoT, y dadas las ven- Machine communications o M2M), dichas máquinas tajas que ofrece, podrı́a ser usado masivamente en pueden tener limitaciones en cuanto a su alimentación este campo. Para responder a dicho interrogante, en energética, procesamiento, almacenamiento y poten- este trabajo se realizan dos implementaciones, en la cia de transmisión [Ker14]. Las anteriores restricciones primera se tiene un cliente y un servidor HTTP/2. han llevado a re-pensar el uso de los protocolos más di- En la segunda, se tiene un cliente CoAP, un proxy fundidos en Internet, como lo son HTTP/1.1 y TCP, CoAP/HTTP y un servidor HTTP1.1. El objetivo y a la creación de nuevos protocolos optimizados para es hacer una comparación de desempeño teniendo en estos escenarios [Ler12], tales como Constrained Apli- cuenta los tiempos de respuesta de ambos casos. cation Protocol (CoAP) y Message Queue Telemetry En trabajos previos [Tha14, Col14] se comparó el Transport (MQTT). desempeño de algunos protocolos orientados a IoT, Por otro lado, siguiendo una lógica de no “rein- pero no directamente HTTP/2 con CoAP. Los resul- ventar la rueda”, existen propuestas para hacer las tados han mostrado como principal conclusión que no adaptaciones necesarias a escenarios IoT de protoco- hay un protocolo que se desempeñe mejor en todos los los ampliamente difundidos en Internet, como HTTP, escenarios, sino que esto depende de las condiciones de la red. En [Sax15] se demuestra que HTTP/2 tiene Copyright c by the paper’s authors. Copying permitted for mejor desempeño que HTTP/1.1 en cuanto a tiempos private and academic purposes. de respuesta. This work is partially funded by Project FONDECYT Iniciación No. 11140045. Proceedings of the Spring School of Networks, Este trabajo es un acercamiento a los protocolos Santiago, Chile, November 2016. de IoT, de cara a una posible adaptación de HTTP/2 para escenarios restringidos. A partir de este trabajo se espera sentar las bases para definir los cambios per- tinentes que podrán incorporarse a una nueva versión de HTTP/2. 2 Descripción de la implementación Para la comparación de desempeño entre HTTP/2 y CoAP se hizo un montaje experimental, con el fin de recopilar la información de los tiempos de respuesta promedio de métodos GET y POST en HTTP/2 y CoAP, variando el tráfico en el canal y la calidad de la Figure 2: Escenario de HTTP/2 con equipos adi- señal inalámbrica. El número de peticiones a analizar cionales generando tráfico es de 30 para cada caso. En cuanto a la calidad de la señal, en un primer El montaje para el experimento consiste en dos es- momento los equipos portátiles tienen lı́nea de vista cenarios, uno para probar el desempeño de HTTP/2 y con el AP y la potencia recibida en el cliente es de otro para una solución CoAP/HTTP1.1. En el primer alrededor de -27dBm. Para forzar una reducción en caso, el navegador Mozilla Firefox 47.0 se conecta vı́a la calidad de la señal, los clientes se ubican fuera de WiFi (IEEE 802.15n) a un Acces Point (AP) Cisco lı́nea de vista del AP de tal manera que se reduzca la WRT160NL. El AP se conecta vı́a FastEthernet a un potencia recibida a aproximadamente -85dBm. PC con una máquina virtual Ubuntu 16.04 en el cual se ejecuta un servidor web Apache 2.4.20. 3 Resultados y discusión En el caso del escenario para CoAP/HTTP, se usa como cliente CoAP, Copper 0.18.4.1, un complemento Los tiempos de respuesta obtenidos del método GET de Mozilla Firefox [Cop16]. Este se conecta vı́a WiFi para todos los escenarios se muestran en la tabla 1 y al AP, que a su vez se conecta vı́a FastEthernet al PC los del método POST en la tabla 2. donde hay dos máquinas virtuales: una de ellas es un Proxy CoAP/HTTP1.1 llamado Crosscoap [Ibm16] y Table 1: Tiempos de respuesta promedio - método la otra es un servidor web Apache HTTP1.1. Para am- GET bos escenarios las capturas de tráfico se realizan en el computador portátil del cliente utilizando Wireshark. En la figura 1 se muestra un diagrama con las imple- mentaciones. Table 2: Tiempos de respuesta promedio - método POST Figure 1: Escenarios implementados para las pruebas Para ambos métodos cuando la señal es buena, CoAP tiene significativamente mejores tiempos de re- Para crear congestión en el canal inalámbrico se em- spuesta respecto a HTTP/2, independiente del nivel plean otros dos computadores portátiles que inyectan de congestión; esto se debe principalmente a dos ra- tráfico TCP a la red, con ayuda de Iperf [Ipe16]. zones, la primera es la sencillez de la estructura de los Uno actúa como cliente y otro como servidor. El paquetes CoAP frente a los de HTTP/2, lo que ag- nivel de congestión se va aumentando gradualmente iliza la comunicación. La segunda razón es porque al hasta llegar a 20 solicitudes simultáneas con paquetes utilizar UDP no necesita establecer una conexión de de tamaños variables, según la condición del canal, y un stream, ni hacer uso de ACKs en la capa de trans- los mismos tres equipos involucrados generan paque- porte, lo que agiliza el envı́o de la información de capa tes PING de 2000 KB cada uno, de forma sostenida de aplicación. hacia el AP. En la figura 2 se ilustra el escenario de Se debe tener en cuenta que parte del tiempo de congestión. respuesta de las peticiones CoAP corresponden al tiempo que se demora el servidor Proxy en hacer la bien en un ambiente restringido. Está claro es que la respectiva petición al servidor Web y que este a su vez capa de transporte deberá tener cambios en IoT. responda. En los escenarios implementados, la comu- También se determinó que el desempeño de CoAP nicación entre estos dos servidores no se ve afectada se ve deteriorado en redes con pérdidas debido al uso por la congestión en el canal inalámbrico. El servidor de mensajes confirmables (CON) que generan tiempos Proxy no está haciendo caching. de espera prolongados para hacer la retransmisión. Cuando la calidad de la señal se deteriora, en todos Si bien el objetivo de este trabajo es evidenciar el los casos HTTP/2 tiene mejores tiempos de respuesta, desempeño de CoAP y HTTP/2 de manera experimen- sin embargo hay peticiones GET no respondidas. La tal frente a escenarios restringidos de IoT, en el esce- razón por la que CoAP reduce significativamente su nario web descrito aún no se han utilizado escenarios desempeño es porque la implementación utilizada de restringidos. Como trabajo futuro se deberán hacer CoAP envı́a las peticiones GET y POST sobre un men- pruebas de desempeño similares, pero con equipos con saje confirmable (CON) con un back-off exponencial capacidades limitadas y utilizando tecnologı́as tı́picas que inicia en 2s. El cliente hará hasta cuatro retrans- de redes de sensores y dispositivos IoT, como IEEE misiones, esperando 2, 4, 8 y 16 segundos respectiva- 802.15.4. Adicionalmente, en este trabajo se utilizó mente. Estos tiempos de back-off, si bien aumentan un Proxy CoAP/HTTP1.1. En un trabajo futuro se la probabilidad de que el canal se recupere, también espera poder evaluar el desempeño cuando todo el es- aumentan considerablemente los tiempos de respuesta cenario es CoAP, es decir, sin la existencia de un Proxy. de las solicitudes, mientras que las retransmisiones de Los trabajos futuros servirán para poder estable- HTTP/2 son más rápidas. cer qué adaptaciones o mejoras se le pueden hacer a La principal afectación en el desempeño de HTTP/2 HTTP/2 de cara a una implementación en una red cuando el canal presenta fallas, se da porque se pier- con nodos restringidos en sus capacidades, como es de den las conexiones TCP, obligando a que se haga el esperarse en un escenario tı́pico de dispositivos IoT. handshaking varias veces, y a que finalmente los tiem- pos de respuesta aumenten. Esta es una desventaja de References HTTP/2 frente a CoAP, en cuanto a procesamiento [Ker14] C. Bormann, M. Ersue, and A. Keranen, Terminology y tiempos de respuesta, debido a que en este último for Constrained-Node Networks, RFC 7228, May 2014. el handshaking no existe. Una posible solución a este Disponible: http://www.rfc-editor.org/info/rfc7228. punto es hacer que HTTP/2 también corra sobre UDP [Ler12] C. Lerche, N. Laum, F. Golatowski, D. Timmermann, [Qui16]. Cabe anotar que Mozilla Firefox tiene im- and C. Niedermeier, Connecting the web with the web plementado HTTP/2 sólo sobre TLS, lo cual añade of things: lessons learned from implementing a CoAP- HTTP proxy, in 2012 IEEE 9th International Confer- una capa de complejidad adicional que impacta en el ence on Mobile Ad-Hoc and Sensor Systems (MASS tiempo de respuesta. 2012), pp. 1–8, 2012. En los experimentos, el tipo de información que se [Mon16] G. Montenegro, S. Céspedes, S. Loreto, and R. transmite tanto del servidor al cliente como del cliente Simpson, H2oT: HTTP/2 for the Internet of al servidor, simula de manera sencilla la información Things, IETF Internet-draft (work in progress), July 2016. Online: https://tools.ietf.org/html/draft- arrojada en texto plano por un nodo-sensor. Debido a montenegro-httpbis-h2ot-00 esto, en un primer momento no se explotan todas las [Tha14] D. Thangavel, X. Ma, A. Valera, H. X. Tan, and C. funcionalidades y ventajas que ofrece HTTP/2. Esto K. Y. Tan, Performance evaluation of MQTT and lleva a pensar que si se quiere adaptar este protocolo CoAP via a common middleware, in 2014 IEEE Ninth International Conference on Intelligent Sensors, Sensor a un escenario de IoT, se deberá tener en cuenta que Networks and Information Processing (ISSNIP), pp. la información manejada puede ser más sencilla y es- 1–6, 2014. porádica que la de las páginas web tradicionales de la [Col14] M. Collina, M. Bartolucci, A. Vanelli-Coralli, and G. Internet. Por otro lado, los tiempos de respuesta de E. Corazza, Internet of Things application layer pro- CoAP podrı́an mejorar si los tiempos de espera para tocol analysis over error and delay prone links, in 2014 7th Advanced Satellite Multimedia Systems Confer- retransmitir se hacen más pequeños, en cuyo caso de- ence and the 13th Signal Processing for Space Com- pende de la implementación del cliente que se utilice. munications Workshop (ASMS/SPSC), pp. 398–404, 2014. 4 Conclusiones y trabajo futuro [Sax15] H. de Saxcé, I. Oprescu, and Y. Chen, Is HTTP/2 really faster than HTTP/1.1?, in 2015 IEEE Confer- Los resultados muestran que no hay un protocolo que ence on Computer Communications Workshops (IN- FOCOM WKSHPS), pp. 293–299, 2015. sea el mejor en todos los escenarios, la elección del [Cop16] Copper (Cu). [Online]. Available más conveniente dependerá de las condiciones de los in: https://addons.mozilla.org/en- equipos y de la red. En el caso del presente estudio, se US/firefox/addon/copper-270430/. [Accessed: 06-jul- obtiene que si el canal es confiable, CoAP tiene mejores 2016]. tiempos de respuesta y cuando el canal tiene pérdidas, [Ibm16] Ibm-security-innovation/crosscoap, GitHub. [Online]. los tiempos de respuesta son mejores con HTTP/2. Available in: https://github.com/ibm-security- innovation/crosscoap. [Accessed: 06-jul-2016]. Adicionalmente se determinó que el handshaking de [Ipe16] iPerf - The TCP, UDP and SCTP network band- TCP aumenta los tiempos de respuesta. Si la señal width measurement tool. [Online]. Available in: es mala y las conexiones se pierden, el desempeño de https://iperf.fr/. [Accessed: 06-jul-2016]. HTTP/2 empeora. Respecto a este tema, hay solu- [Qui16] QUIC, a multiplexed stream transport over UDP ciones propuestas y probadas como QUIC [Qui16], - The Chromium Projects. [Online]. Disponible en: donde HTTP/2 corre sobre UDP. Corresponde a tra- https://www.chromium.org/quic. [Accessed: 06-jul- 2016] bajos futuros determinar si esta opción se desempeña