Laboratorio Implementación de Servidores TCP y UDP (1)

7/24/2019 Laboratorio Implementacin de Servidores TCP y UDP (1)

1/11

Laboratorio #6- Implementacin de servidores TCP y UDP

Infraestructura de comunicaciones

Ana Mara Crdenas (

am.cardenas926

), Andrea Navas(

a.navas380

)

201213021 - 201125090

Universidad de los Andes, Bogot, Colombia

Fecha de presentacin: Octubre 11 de 2015

1. Introduccin

En el siguiente informe se presentar el desarrollo de implementaciones de servicios

soportados por protocolos tanto TCP como UDP. Para el servicio se utilizar unaarquitectura cliente servidor donde el cliente estar implementado en Java y el

servidor en Java. Para la ejecucin del servicio se asumir que tanto el servidor como

el cliente estn en una misma red y la IP del servidor as como los puertos donde se

expone el servicio son conocidos por el cliente. De igual manera se asume que el

cliente conoce la direccin multicast en donde obtener los canales de streaming.

En cada uno de los casos se realizar un anlisis del desempeo y capacidad de un

servicio segn cada protocolo. El informe buscar relacionar la informacin obtenida

sobre el desempeo con la arquitectura desarrollada para la aplicacin y para el

servidor as como los protocolos que se utilizaron en las pruebas. El informe tambin

buscar aproximarse a escenarios de prueba que sean efectivos para medir tanto el

desempeo como la capacidad del servidor.

2. Desarrollo Servidor y cliente TCP y UDP

2.1. Estructura del programa

Figura 2.1.1 Estructura del servidor


2/11

Figura 2.1.2 Estructura del cliente

En las grficas 2.1.1 y 2.1.2 se muestra la implementacin del cliente y del servidor.

El Servidor cuenta con 3 clases: TCPThread

son los threads de TCP que se abren porcada cliente para prestar los servicios de autenticacin y de subida de videos.

StreamingChannel es un thread con una direccin de multicast que hace un loop

infinito para el stream del video del canal asignado a la direccin. ChannelSelector es

un thread que est enviando a travs de un canal multicast las direcciones de los

canales disponibles. Se actualiza cada N segundos con odos los vdeos subidos por los

usuarios y crea los StreamingThreads necesarios cada vez que un usuario sube un

video.

El cliente posee una estructura ms sencilla ya que implementa en una sola clase tanto

las solicitudes de TCP para autenticar y subir videos como de UDP para recibir elstreaming y renderizar el video.

3. Pruebas sobre los servidores

3.1. Pruebas TCP

En el servidor se implement una funcionalidad adicional que permite responder

inmediatamente al request de hellopara medir el tiempo de respuesta del servidor.

En este caso el tiempo de espera en la cola se ve manifestado en la grfica del tiempo

de respuesta ya que el tiempo de procesamiento es nfimo. Para el caso de las

pruebas de TCP se llev a cabo con JMETER el siguiente escenario de pruebas:


3/11

Figura 4.1.1 escenario de pruebas de TCP

Se determin un RAMPUP de 1000 ms y se realizaron pruebas con 10, 50,

100, 200 y 300 threads de acuerdo a lo estipulado en la gua.

Como muestreadores se agregaron una grfica de tiempo de respuesta, reportede arbol y reporte agregado,

Tiempos de Respuesta:

10 threads:


4/11

50 threads:

100 threads:

200 threads:


5/11

300 threads:

Tras observar los resultados de la tabla se puede observar que el tiempo mximo de

espera se altera significativamente al aumentar el nmero de threads lo cual indica

que la capacidad del servidor se puede ver rebasada al aumentar estos. Sin embargo

se puede observar que el % de error es 0 ya que 300 es un nmero muy pequeo de

threads como para rebasar la cola del servidor.

Etiqueta # Muestras Media Mediana Mn Mx % Error Rendimiento Kb/sec

Muestrea

dor TCP 10 4 4 3 6 0 10.97694841 0.04287870472

Muestrea

dor TCP 50 3 3 2 30 0 48.59086492 0.1898080661

Muestrea

dor TCP 100 5 2 1 53 0 241.5458937 0.9435386473

Muestrea

dor TCP 200 4 2 1 57 0 160.1281025 0.6255004003

Muestrea

dor TCP 300 11 3 1 105 0 86.88097307 0.339378801

3.2. Pruebas UDP

En el servidor no fue necesario de una funcionalidad adicional ya que el streaming

de canales permiti evaluar el tiempo de respuesta del servidor para el caso de la

descarga de un paquete sencillo (los canales disponibles en el servidor). Para el caso

de las pruebas de TCP se llev a cabo con JMETER (a travs de un plugin que

permite realizar pedidos y muestreo de UDP) el siguiente escenario de pruebas:


6/11

10 threads:

50 threads:


7/11

100 threads:

200 threads:

300 threads:


8/11

Al analizar la tabla de resultados de los request UDP se puede observar que el

incremento del tiempo de espera por un paquete por cada thread es menor que en

TCP esto es fcilmente explicable gracias al uso de multicast que se vera afectado

por gran nmero de threads solo en la medida en la que estos llegaran a saturar la red

ya que el servidor no requiere alocar memoria para el procesamiento de estos. El

porcentaje de error al igual que en TCP es 0 ya que el nmero de threads es muypequeo como para saturar la red o el servidor.

Etiqueta # Muestras Media Mediana Mn Mx % Error Rendimiento

jp@gc - UDP

Request 10 1 1 1 1 0 11.0619469

jp@gc - UDP

Request 50 0 1 0 13 0 49.16420846

jp@gc - UDP

Request 100 1 1 0 14 0 98.23182711

jp@gc - UDPRequest 500 0 1 0 42 0 25.89063795

jp@gc - UDP

Request 300 1 1 0 54 0 359.4536305

3.3. Comparacin de resultados

4. Anlisis aplicaciones del mercado

4.1. Proteccin contra un ataque de denegacin de servicio

Un ataque de denegacin de servicio consiste en an attack that renders a network,

host, or other piece of infrastructure unusable by legitimate users. . The attacker

establishes a large number of half-open or fully open TCP connections

. Dada1

esta definicin resulta evidente que la vulnerabilidad se encuentra en el servidor

TCP en el cual se pueden realizar requests TCP al servidor con el fin de que este

aloque espacio en memoria para la informacin del socket. Para el caso de esta

implementacin tambin cuentan los recursos destinados a la creacin de un thread

para atender a la solicitud.

Existen otros tipos de ataque DOS como inundar la red y la explotacin de

vulnerabilidades del servidor. El primero requerira de redundancia de redes lo cual

se puede lograr con varias instancias del servidor ubicadas en redes distintas lo cual

no est en el scope del laboratorio. En el segundo se busca que el desarrollo del

servidor no cuente con vulnerabilidades de implementacin que puedan ser

explotadas.

Para el primer caso que se mencion se determin que un atacante es un cliente que

abre una conexin de TCP para login y sin embargo esta conexin se encuentra

vaca. El servidor cierra todas las conexiones que contienen informacin de registro

1J.Kurose & K.Ross, Computer networking. 6.Ed. United States: Pearson, 2013.


9/11

de manera que slo los clientes que se deseen autenticar puedan tener un thread y

una conexin de control abierta con el servidor TCP. Adicionalmente se modific

el firewall para impedir los ICMP echo, que se utilizan con el comando PING y

TRACEROUTE. Con esta medida se evita que se sature al servidor con una gran

cantidad de mensajes ICMP, degradando el servicio o impidiedo que usuarios

legtimos lo utilicen.

Se podra considerar la necesidad de replicar los servidores y utilizar un

balanceador de carga como posible solucin arquitectural para aumentar la

capacidad del servidor en caso de que el nmero mnimo de threads fuera mucho

mayor a 300 pero para las especificaciones del laboratorio se muestra en el

porcentaje de error de las solicitudes que la capacidad actual es ms que suficiente.

4.2. Anlisis de las medidas de desempeo realizadas al servidor TCP

Anlisis del comportamiento del tiempo de espera (media) del servidor TCP enrelacin con el nmero de threads:

Como se puede observar en la grfica a medida que el nmero de clientes

conectados simultneamente al servidor en un tiempo determinado (rampup

)

aumenta se puede observar un incremento en el tiempo medio de espera que tienen

los clientes. Esto se corresponde con la teora ya que se deberan producir mayores

tiempos de cola (en este caso todo el tiempo est representado por el tiempo de cola

ya que para las pruebas el servidor no realiza procesamiento alguno).

Se puede observar tambin como el tiempo mximo de espera aumenta aunque se

presentan datos con alta varianza debido al reducido nmero de experimentos.


10/11

El caso del porcentaje de error (siempre 0) puede darse gracias a los pocos threads

no suficientes para saturar el servidor sin embargo se esperara, en teora, que

mientras ms saturado estuviera el servidor el porcentaje de error aumente.

4.3. Login con UDP y streaming con TCP

Si se hiciera login con UDP existira la posibilidad de que se perdieran los paquetes

o de que no llegara un usuario con su correspondiente contrasea sino la de otro

usuario. Sera necesario enviar toda la tupla de usuario y contrasea en un mismo

paquete para evitar inconsistencias. Normalmente se espera que un login est

implementado sobre algn tipo de protocolo seguro como SSL pero esto slo sera

posible en TCP. Por lo tanto una implementacin en UDP no slo hara necesario

manejar en el cliente o en el servidor la prdida de mensajes (ya que un cliente s leimporta que se pierda la informacin de su autenticacin) sino que tambin

impedira la implementacin de protocolos ms seguros,

Para el caso del streaming sera necesario tener una conexin con cada cliente para

cada canal lo cual hara mucho ms costoso el servicio para el servidor que tan slo

mandar los paquetes de video a travs de UDP. Sera mucho ms difcil para el

servidor mantener elstreamingpara varios clientes. TCP tambin es mucho ms

lento que UDP lo cual hara que la experiencia del usuario que est viendo el video

se viera afectada con un video que probablemente se interrumpa constantemente a

pesar de no tener prdidas ni de audio ni de imagen esto no es de inters para el

usuario ya que dichas prdidas en el caso de UDP pueden ser difcilmente

percibidas o ignoradas por el usuario.

5. Conclusiones

5.1. Para implementar proteccin contra ataques de denegacin de servicio es

necesario tener mecanismos redundantes ya que por ms que se pueda

reconocer un atacante en trminos de sockets TCP basura los recursos

consumidos por abrir una conexin ya son bastante significativos de por s.


11/11

5.2. Se pudo observar a lo largo del laboratorio que el nmero de threads que

atiende el servidor afecta significativamente ms a los servicios soportados por

TCP que a los servicios soportados por UDP.

5.3. Se podra considerar la necesidad de manejar un balanceador de carga a partir

de la estimacin del porcentaje de error a partir de un determinado nmero declientes. Sin embargo, dado que en este laboratorio no se alcanz un nmero

de clientes que aumente el porcentaje de error este nmero es desconocido.

5.4. Gracias al multicast se puede enviar de manera ms eficiente el streaming de

video a varios clientes de manera simultnea sin comprometer una gran

cantidad de recursos por parte del servidor.

6. Bibliografa

1. J.Kurose & K.Ross, Computer networking. 6.Ed. United States: Pearson, 2013.

2. Xuggler, streming video. [En lnea] [Citado el: 10 de Oct de 2015.]

http://www.xuggle.com/xuggler/

3. Cisco, Multicast addressing [En lnea] [Citado el: 10 de Oct de

2015.]http://www.cisco.com/c/en/us/products/ios-nx-os-software/ip-multicast/index.html

4. The Chromium Project. QUIC, a multiplexed stream transport over UDP. [En lnea] [Citado

el: 10 de Oct de 2015.] https://www.chromium.org/quic
https://www.chromium.org/quichttp://www.cisco.com/c/en/us/products/ios-nx-os-software/ip-multicast/index.htmlhttp://www.xuggle.com/xuggler/

Laboratorio Implementación de Servidores TCP y UDP (1)

Documents

Transcript of Laboratorio Implementación de Servidores TCP y UDP (1)