=Paper=
{{Paper
|id=Vol-1727/ssn16-final5
|storemode=property
|title=Performance Evaluation of CoAP and HTTP/2 in Web Applications
|pdfUrl=https://ceur-ws.org/Vol-1727/ssn16-final5.pdf
|volume=Vol-1727
|authors=Diego Londoño,Sandra Céspedes
|dblpUrl=https://dblp.org/rec/conf/ssn/LondonoC16
}}
==Performance Evaluation of CoAP and HTTP/2 in Web Applications==
https://ceur-ws.org/Vol-1727/ssn16-final5.pdf
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