Laboratorio #5­ Análisis de comunicación por sockets

TCP y UDP a través de cliente android

Infraestructura de comunicaciones

Ana María Cárdenas (am.cardenas926), Andrea Navas(a.navas380) 201213021 ­ 201125090

Universidad de los Andes, Bogotá, Colombia Fecha de presentación: Septiembre 20 de 2015

Contenido Introducción Desarrollo Servidor TCP y UDP en java

Definición del protocolo Arquitectura del servidor

Desarrollo Cliente Android TCP y UDP Arquitectura Interfaz gráfica Envío de mensajes de posición Envío de mensajes de prueba

Pruebas de JMETER sobre el servidor Diseño de las pruebas Resultados de las pruebas

Pruebas sobre el Cliente Android Diseño de pruebas Resultados Pruebas

Evaluación y análisis de aplicaciones del mercado Waze Netflix Skype

Conclusiones Bibliografía

1. Introducción En el siguiente informe se presentará el desarrollo de implementaciones de servicios soportados por protocolos tanto TCP como UDP. Para el servicio se utilizará una arquitectura cliente servidor donde el cliente estará implementado en Android y el servidor en Java. Para la ejecución del servicio se asumirá que tanto el servidor como el cliente están en una misma red y la IP del servidor así como los puertos donde se expone el servicio son conocidos por el cliente. En cada uno de los casos se realizará un análisis del desempeño y capacidad de un servicio según cada protocolo. El informe buscará relacionar la información obtenida sobre el desempeño con la arquitectura desarrollada para la aplicación y para el servidor así como los protocolos que se utilizaron en las pruebas. El informe también buscará aproximarse a escenarios de prueba que sean efectivos para medir tanto el desempeño como la capacidad del servidor.

2. Desarrollo Servidor TCP y UDP en java 2.1. Definición del protocolo

La funcionalidad de la aplicación que se desea es el registro de informes cada segundo desde un cliente dentro del servidor. Como no se conoce el momento de inicio ni de fin de los mensajes el servidor siempre está esperando por un cliente que se registre y empiece a enviar los mensajes al servidor. Este puede dejar de enviar mensajes en cualquier momento. El protocolo varía según si los mensajes corresponden a las pruebas desde el cliente o a un usuario real que se registra en la aplicación. Ambos protocolos se encuentran implementados en el cliente y se utilizan según lo definido por el usuario. Protocolo de caso de uso real:

Figura 2.1.1 Protocolo de caso de uso real

Figura 2.1.2 Protocolo de caso de pruebas

2.2. Arquitectura del servidor Para el caso del servidor se implementó un servidor en java que ejecuta threads para cada uno de los clientes que se conecta y envía mensajes. Para el caso de UDP se tiene un DatagramPacket sobre el mismo DatagramSocket cada vez que un cliente nuevo se conecta. Para el caso del ThreadTCP se tiene 1 por cada cliente que se conecta con su respectivo BufferedReader.

Figura 2.2.1 Arquitectura del servidor

Para las pruebas de JMETER se realizó una implementación especial del servidor que envía mensajes de respuesta al cliente cada vez que recibe una solicitud de TCP con el fin de poder realizar las medidas de desempeño en este caso.

3. Desarrollo Cliente Android TCP y UDP 3.1. Arquitectura

Para el caso del desarrollo del cliente se hizo uso de threads para manejar el envío de mensajes desde TCP o de UDP así como para la ejecución de Threads. Para el caso del envío de la posición se hizo uso de LocationListener el cual es implementado por main activity. Para la

ejecución de la aplicación se requirieron permisos de Android tanto para internet como para los servicios de ubicación.

Figura 3.1.1 Arquitectura del cliente

3.2. Interfaz gráfica Para el desarrollo de la aplicación se realizó una interfaz que permitiera personalizar la ejecución según el protocolo y si se desea o no hacer pruebas. También se informa al usuario si cambió la posición y se actualiza la interfaz y se le permite iniciar y cancelar el envío de la posición.

Figura 3.2.1 Interfaz gráfica de la aplicación

3.3. Envío de mensajes de posición Para enviar los mensajes de la posición se hizo uso de un timer que cada segundo envía la misma dirección si no se ha modificado o envía una nueva en caso de que se actualice a través del LocationListener. private void sendPosition() Timer timer = new Timer(); timer.schedule(new TimerTask() @Override public void run() if((tcp_sender != null || udp_sender != null) && enviando) Log.e("TCP", "envia mensaje al servidor"); String mensaje = nLatitud + ":" + nLongitud + ":" + nAltitud + ":" + nVelocidad; if (tcp_sender != null) tcp_sender.enviarTCP(mensaje); else udp_sender.enviarUDP(mensaje); ,0,1000);//Update text every second

3.4. Envío de mensajes de prueba Para el envío de los mensajes de prueba se utilizaron threads que envían un mensaje determinado un número determinado de veces. El número de threads y el número de mensajes están determinados por el usuario desde la interfaz. Si no se ingresa un valor se envía por defecto 10 mensajes desde un único thread. Debido a que el rampup es el mismo para todas las pruebas se encuentra el valor dentro del código.

4. Pruebas de JMETER sobre el servidor 4.1. Diseño de las pruebas

Para las pruebas de JMETER se ejecutó con un rampup constante de 1000 ms (1 seg) aumentando el número de threads que se enviaba con un único mensaje. Los resultados se documentaron a través de gráficas de response time y reporte agregado. Para ningún caso se determinó un timeout y 300 threads no fueron suficientes para obtener threads descartados por parte del servidor.

Figura 4.1.1 Configuración de pruebas de TCP y de UDP

4.2. Resultados de las pruebas

En la siguiente gráfica se puede notar la diferencia entre los 2 protocolos donde UDP escala mucho mejor que TCP. Dado que no hay pérdida de paquetes en este caso UDP resulta mejor que TCP ya que llegan de manera mucho más rápida los mensajes. Se debe tener en cuenta que el servicio está corriendo en el mismo computador por lo tanto los tiempos de respuesta no tienen en cuenta el delay de la red.

Figura 4.1.2 Comparación de TCP y de UDP

A continuación se presenta los resultados obtenidos para tcp y udp para el response time y para los promedios.

TCP ­ 50 Threads MEDIA: 1 MEDIANA: 1 % ERROR: 0 KB/SEG: 0.01330342237

TCP ­ 100 Threads MEDIA: 1 MEDIANA: 1 % ERROR: 0 KB/SEG: 0.3799854086

TCP ­ 300 Threads MEDIA: 6 MEDIANA: 2 % ERROR: 0 KB/SEG: 1.059561483

TCP ­ 500 Threads MEDIA: 80 MEDIANA: 26 % ERROR: 0 KB/SEG: 1.673628963

UDP ­ 50 Threads MEDIA: 0 MEDIANA: 0 % ERROR: 0 KB/SEG: 0.0021034124

UDP ­ 100 Threads MEDIA: 0 MEDIANA: 0 % ERROR: 0 KB/SEG: 0.007354009

UDP ­ 300 Threads MEDIA: 0 MEDIANA: 1 % ERROR: 0 KB/SEG: 0.01985221

UDP ­ 500 Threads MEDIA: 0 MEDIANA: 1 % ERROR: 0 KB/SEG: 0.039400231

5. Pruebas sobre el Cliente Android 5.1. Diseño de pruebas

Se replicó la configuración de las pruebas realizadas en JMETER en android a través de la interfaz desarrollada. Para los resultados de las pruebas se muestran los promedios de los resultados obtenidos en ambas iteraciones. Para realizar las pruebas se envía un timestamp desde el cliente y se vuelve a tomar el timestamp cuando llega al servidor de manera que se puede calcular la duración del envío del mensaje. Para determinar el porcentaje de pérdidas se utiliza el número de mensajes enviados, conocidos desde el cliente y se determina el porcentaje según los mensajes depositados en el log.

5.2. Resultados Pruebas

Figura 5.2.1 Comparación de TCP y de UDP (media) en ms

Figura 5.2.2 Comparación de TCP y de UDP (mediana) en ms

Figura 5.2.3 Comparación de TCP y de UDP (moda) en ms

Como se muestra en las gráficas de comparación UDP presenta, en general, un mejor comportamiento que TCP con un tiempo de respuesta menor para las peticiones de los clientes. Se observa una excepción a este comportamiento en el caso de 100 threads pero en este caso la diferencia pudo deberse a condiciones de la red como congestión ya que las pruebas con el celular si están sometidas a las condiciones de la red. Para el caso de pérdida de paquetes, en ambos protocolos, el número de solicitudes atendidas correspondió al 100% de las solicitudes enviadas por lo que se puede determinar que no hay diferencias en cuanto a las pérdidas para estos casos de uso.

Figura 5.2.4 Datos numéricos de resultados en MS

6. Evaluación y análisis de aplicaciones del mercado

6.1. Waze De acuerdo a la página de la aplicación “Waze es la aplicación de tráfico y navegación basada en la comunidad más grande del mundo. Únete a los conductores de tu área que comparten el tráfico e información de ruta en tiempo real ahorrando todos tiempo y dinero en sus desplazamientos diarios.”. De acuerdo a lo que se ha considerado a lo largo del laboratorio una aplicación de tiempo real es sensible a los tiempos de respuesta y throughput en las peticiones sin que pérdidas de reportes en un segundo en específico sean muy consecuentes para la experiencia del usuario. De acuerdo a un artículo de PCWorld en una entrevista a Tobias Jeske, un estudiante doctoral del Institute for Security in Distributed Applications of the Hamburg University of Technology: “Google navigation uses real­time traffic information in Google Maps for mobile. The protocol used to send location information is protected by a TLS (Transport Layer Security) tunnel that ensures the data integrity so that it is impossible for an attacker to monitor a foreign phone or modify information without being detected by Google” . TLS 1

se encuentra implementado sobre la capa TCP. La seguridad es un factor muy importante para aplicaciones como Waze porque la información de la localización de un usuario son datos sensibles y pueden poner en riesgo la privacidad y seguridad de los usuarios de Waze. De acuerdo a otra fuente Floating Car Data from Smartphones: What Google and Waze Know About You and How Hackers Can Control Traffic por Tobias Jeske (entrevistado en la fuente anterior) “Today, navigation devices frequently receive traffic reports on the Traffic Message Channel (TMC). TMC messages have several sources: the police, permanently installed sensors like traffic cameras or inductive loops, and traffic reports of volunteers.” Este protocolo de transmisión se realiza a través de radio y por 2

lo tanto no tiene relación con TCP o UDP “TMC is a specific application of FM RDS used for broadcasting real­time traffic and weather information. Data messages are received silently and decoded by a TMC­equipped navigation system, and delivered to the driver, typically by offering dynamic route guidance – alerting the driver of a problem on the planned route and calculating an alternative route to avoid the incident.” . De acuerdo a esta 3

fuente “Waze is a free GPS application, which also uses FCD of smartphones in order to generate traffic information”. FDC es un tipo de datos de posición generado desde el sistema operativo android “Google uses position data of smartphones with the Android operating system, which results in a significantly faster mapping of the traffic flow. This data is called floating car

1http://www.pcworld.com/article/2030991/researcher­hackers­can­cause­traffic­jams­by­manipulating­real­time­traffic­data.html. Pag 1 2 https://media.blackhat.com/eu­13/briefings/Jeske/bh­eu­13­floating­car­data­jeske­wp.pdf 3 http://tisa.org/technologies/tmc/

data (FCD). Position data is determined by the navigation system or, as in the case of Google Live Traffic, by the smartphone and is transmitted to the service provider via a mobile phone connection. Compared to TMC, this allows the generation of traffic information in real time”. Esta segunda fuente también coincide con el uso de TLS para el envío de información sensible del usuario. “The transmission of login information such as username and password is encrypted using TLS. If the user starts the app, the login information is transferred to the Waze server. The user gets a server ID and a cookie from the server. All subsequent messages sent to the Waze server contain the ID and the cookie, both of which are introduced by the keyword UID” 4

Figura 6.1.1 Waze request message

6.2. Netflix Dado que Netflix consiste en un servicio de streaming se puede determinar, en primera instancia que no es sensible a pérdida de información (puede reducir la calidad del streaming y perder información de algunos píxeles de la imagen). De igual manera se puede pensar que es más importante garantizar una mayor velocidad del servicio que la garantía de llegada del mensaje. Otra vez nuestras hipótesis llegan a estar erradas. Según el artículo Unreeling Netflix: Understanding and Improving Multi­CDN Movie Delivery de Vijay Kumar Adhikari : “Netflix uses the DASH (Dynamic Streaming over HTTP)protocol for streaming. In DASH, each video is encoded at several different quality levels, and is divided into small ‘chunks’ ­ video segments of no more than a few seconds in length. The client requests one video chunk at a time via HTTP. With each download, it measures the received bandwidth and runs a rate determination algorithm to determine the quality of the next chunk to request. DASH allows the player to freely switch between different quality levels at the chunk boundaries.” . El protocolo DASH corre sobre HTTP y por 5

lo tanto hace uso de TCP como protocolo de transporte. El cliente también

4 https://media.blackhat.com/eu­13/briefings/Jeske/bh­eu­13­floating­car­data­jeske­wp.pdf Pag 5 5 http://www­users.cs.umn.edu/~viadhi/netflix.pdf Pag 1

hace las peticiones de cada chunk de video a través de HTTP por lo tanto en este caso también se hace uso de TCP para el envío de mensajes. En el artículo también se confirma el uso de TCP cuando el autor menciona que se envían menSajes de keep alive de TCP “We also send keep­alive messages to each server every second when no data is transferred to make sure that the TCP session is alive and sender window size does not drop” 6

Figura 6.2.1 Waze request message

6.3. Skype

Para el caso de Skype se puede pensar, otra vez, que la transferencia de voz es un servicio que prioriza la velocidad sobre la seguridad de llegada de la información y por lo tanto se debería usar UDP. En este aspecto la Wiki de Wireshark nos da una pista. Se declara que es 7

difícil analizar el protocolo de Skype dado que es un protocolo propietario sin embargo muestra que se puede filtrar un puerto de UDP para capturar datos intercambiados por Skype lo cual indicaría que Skype usa UDP.

Figura 6.3.1 Captura de Wireshark Wiki

6 http://www­users.cs.umn.edu/~viadhi/netflix.pdf Pag 7 7 https://wiki.wireshark.org/Skype

En el artículo de Wikipedia sobre el SkypeProtocol tanto TCP como UDP pueden ser utilizados para una llamada de Skype. Según este artículo la autenticación es realizada por medio de TCP “A TCP connection must be established (i.e. to a supernode) otherwise the login will fail. Here hc means host cache i.e. the information that a skype client stores about the list of supernodes(sc)” 8

Figura 6.3.3 UDP Packets

7. Conclusiones

7.1. Los servicios prestados sobre TCP y UDP presentan diferencias significativas en cuanto al tiempo de respuesta y throughput siendo UDP más eficiente que TCP al no tener que establecer una conexión ni realizar el protocolo de Handshake para asegurar la llegada de paquetes.

7.2. A pesar de que la pérdida de paquetes no pudo observarse en el laboratorio

debido a que una de las pruebas se realizó con JMETER dentro del mismo host del servidor y la otra en una red doméstica poco congestionada, existen diferencias significativas entre la tasa de éxito de servicios que implementan su comunicación a través de TCP y los que usan UDP. Siendo TCP el protocolo que garantiza una llegada segura de los paquetes.

7.3. A pesar de que se puede pensar que aplicaciones como rastreo de GPS en

tiempo real se benefician de una implementación a través de UDP gracias a su velocidad es necesario tener en cuenta que la ubicación es una información sensible de los usuarios que debe ser transportada de manera segura y así mismo existen otros protocolos que utilizan otras capas físicas y de enlace más específicas para estos procedimientos (Como TMC).

7.4. A pesar de que se puede pensar que aplicaciones como streaming de Video se

benefician de UDP se debe considerar que estos servicios pueden garantizar distintos niveles de calidad del video a través de TCP (usando HTTP y protocolos de streaming) y, de esta manera, poder controlar la velocidad de transmisión y garantizar una calidad mínima.

8 https://en.wikipedia.org/wiki/Skype_protocol

7.5. Los servicios pueden correr sobre más de un protocolo como es el caso de Skype para garantizar la ejecución en distintas plataformas y permitir también una configuración óptima del servicio.

8. Videos de DEMO

Los videos de demo de la aplicación desarrollada fueron subidos a Youtube y se encuentran en los siguientes Links: Video de implementación de pruebas: https://youtu.be/0­gE6PY8fyM Video de implementación del servicio: https://youtu.be/bUfBodaUx50

9. Bibliografía [1] Waze (n.d.). Retrieved Sept 20, 2015, from https://www.waze.com/ [2] Unreeling Netflix: Understanding and Improving Multi­CDN Movie Delivery. Vijay Kumar Adhikari∗, Yang Guo †, Fang Hao†, Matteo Varvello †, Volker Hilt †, Moritz Steiner † and Zhi­Li Zhang∗∗ University of Minnesota, † Bell­Labs/Alcatel­Lucent. Retrieved Sept 20, 2015 from http://www.cs.columbia.edu/~library/TR­repository/reports/reports­2004/cucs­039­04.pdf [3] Floating Car Data from Smartphones: What Google and Waze Know About You and How Hackers Can Control Traffic Tobias Jeske. Retrieved Sept 20, 2015 from https://media.blackhat.com/eu­13/briefings/Jeske/bh­eu­13­floating­car­data­jeske­wp.pdf [4] Skype. Retrieved Sept 20, 2015, https://wiki.wireshark.org/Skype [5] Skype Protocol Retrieved Sept 20, 2015, https://en.wikipedia.org/wiki/Skype_protocol