INTRODUCCION
Calcular el consumo de ancho de banda de un canal, permite a los administradores de red tomar decisiones que permitan optimizar el enlace y a los usuarios establecer la cantidad de ancho de banda que realmente requieren y por la que deberían pagar al proveedor del servicio. Por ejemplo, muchos usuarios de redes de “banda ancha” ya sean ADSL, Frame Relay, RDSI, etc; emplean simultáneamente la misma conexión para realizar varias tareas a la vez o para permitir la conexión de varias personas a través de ellas en el caso de redes con reuso del enlace. Con frecuencia las aplicaciones no interactivas consumen la mayor parte del ancho de banda, dicho de otra forma, la navegación o la lectura del correo deben competir contra una descarga cualquiera.
Una aplicación que permita determinar la cantidad de ancho de banda consumida en un enlace en tiempo real, permitiría una mejor administración de dicho enlace, asignando a cada fuente la cantidad de canal que realmente requiere en un momento dado. Esta aplicación, propósito de este proyecto, fue desarrollado con herramientas de software libre la cual tiene una licencia GPL[1], por lo que es un aporte a la comunidad de desarrolladores de software libre, como a diferentes investigadores que deseen aportar mejoras a la misma. La aplicación utiliza la librería PCAP que permite capturar paquetes de la red y analizarlos para realizar los cálculos de ancho de banda esperados. Para la evaluación de la aplicación se utiliza un generador de tráfico denominado MGEN.
El trabajo comprende aspectos relacionados con el efecto del encapsulamiento, filtrado de paquetes, mecanismos de generación de tráfico, sniffers, ingeniería de software, Metodología y desarrollo del sistema, Arquitectura general del sistema, herramienta desarrollada, análisis de resultados, conclusiones y recomendaciones.
El desarrollo de
este proyecto permite además, profundizar en diferentes conceptos relacionados
con la transmisión de datos,
implementación y uso de plataformas hardware y software de experimentación, así
como la filosofía del software libre.
1.
ANTECEDENTES
El proyecto de investigación está enmarcado y apoyado por
la línea de investigación de Redes y tecnologías Web del Grupo de
Tecnologías de Información (GTI), de la Maestría en
Software libre de la Universidad Oberta de Cataluña (UOC) y la Universidad
Autónoma de Bucaramanga (UNAB).
Este proyecto está enmarcado dentro de la investigación realizada por el director en el área de estimación de ancho de banda disponible en redes de comunicaciones.
El proyecto estudia, experimenta y aplica diferentes
herramientas de software libre para la adecuada medición y administración de
anchos de banda en un enlace en donde la aplicación desarrollada, tiene una
licencia de tipo GPL cumpliendo con las
libertades que dicta la Free Software
Foundation, orientándolo a la comunidad académica y empresarial.
2.
OBJETIVOS
2.1 OBJETIVO GENERAL
Desarrollar
una herramienta de software bajo licencia GPL
que mediante captura y análisis de paquetes, permita estimar la utilización en bits por segundo de un enlace de red.
2.2 OBJETIVOS ESPECIFICOS
1. Estudiar
e identificar las estructuras de la librería Libpcap para capturar y analizar paquetes en sistemas Linux.
2. Determinar
los criterios de selección y establecer el lenguaje de programación en el cual se va a implementar la aplicación.
3. Establecer
un testbed que permita de manera controlada generar tráfico de un host
hacia un enlace para que sea leído y analizado en otro host dentro del mismo enlace.
3.
MARCO TEORICO
El análisis en tiempo real del ancho de banda, tiene como función brindar algunas herramientas, que permitan medir la cantidad de bits por segundo que pasan por un canal de transmisión durante un periodo de tiempo especificado (del orden de milisegundos). Generalmente cuando se va a realizar este tipo de pruebas, es necesario que no existan aplicaciones innecesarias en ejecución. Es importante anotar que el propósito de este proyecto no es medir el throughput de la conexión, que es determinado por la cantidad de bits que el protocolo de transporte coloca en el canal, dependiendo de la congestión existente en el mismo. El objetivo es medir el tráfico proveniente de cualquier conexión que pase por un canal en un periodo de tiempo.
Actualmente existen diferentes herramientas que permiten analizar los paquetes que viajan por la red y proporcionan información de tiempos y longitud de paquete que posibilitan el cálculo del consumo de ancho de banda a través de scripts generados por ejemplo por awk. Sin embargo, una herramienta que genere exclusivamente trazas de consumo ancho de banda sin necesidad de post-procesamiento, está aún por desarrollar y constituye la motivación del presente proyecto.
La gran mayoría de herramientas que hacen análisis de encabezados de paquetes, utilizan un API (Application Programming Interface) denominado PCAP generalmente basado en el lenguaje de programación C, que permite a las aplicaciones desarrolladas capturar, hacer rastreo de paquetes y/o enviar los paquetes a la red. Según sea la aplicación, existe una versión del API para Java llamada Jpcap, así como otra para plataforma Windows denominado winpcap. En Linux se denomina libpcap. (Cartens. 2002). Entre las principales herramientas y aplicaciones (Skwarek:45) que emplean la librería PCAP están: nmap, wireshark, ethereal, tcpdump, snort, p0f y natdet.
La estimación en tiempo real del consumo de ancho de banda en un enlace, implica por una parte establecer la longitud exacta de los paquetes que viajan a través del enlace físico. Para ello es necesario conocer con exactitud la arquitectura de capas de Internet y la cantidad de bits que son adicionados al paquete de datos original por efectos de lo que se denomina encapsulamiento. Por otra parte, es necesario conocer la manera en que se puede realizar filtrado de paquetes que se capturan del canal de transmisión para poder extractar de su información de encabezado el valor exacto de longitud de paquete y tiempo requerido para su transmisión. Finalmente, y para efectos de experimentación en una red real, es necesario establecer un mecanismo de generación de tráfico sintético que permita evaluar la funcionalidad del estimador. El presente capitulo aborda los tres conceptos que se acaban de mencionar.
3.1
ENCAPSULAMIENTO TCP/IP
La arquitectura de Internet ubica protocolos de comunicaciones en cuatro capas [7]: aplicación, transporte, red y de enlace. Cada capa tiene funciones específicas que posibilitan el viaje de datos de una máquina origen a una destino a lo largo de diferentes sistemas de comunicaciones. Como se observa en la Figura 1, el proceso de encapsulamiento consiste en adicionar información correspondiente a la funcionalidad de cada capa. Esto implica que la información que originalmente se desea transmitir, va a ser incrementada en 54 bytes para el caso de paquetes TCP: 20 bytes de encabezado TCP, 20 bytes de encabezado IP y 14 bytes de encabezado Ethernet. Si el paquete es UDP en lugar de 20 bytes en la capa de transporte, se sustituye por 8 bytes para un total de 42 bytes. Estos valores se especifican a continuación para cada una de las capas.
Figura 1. Encapsulamiento de datos en TCP/IP.
Fuente: El Autor
3.1.1 Trama Ethernet
La cantidad de información que finalmente viaja por el canal de comunicaciones es determinada por la capa de enlace, que se encarga de determinar la manera en que se va a accesar al medio de transmisión. El protocolo de enlace más común a nivel LAN es Ethernet. Este protocolo establecido en el estándar IEEE 802.3, tiene versiones según su velocidad de transmisión como Fast Ethernet (100 Mbps) y GigaEthernet (1/10 Gbps).
Mediante Ethernet, se debe tener en cuenta que existe un envió de tramas en un medio compartido, por lo que es necesario establecer mecanismos especiales de acceso al medio definidos como MAC (Control de Acceso al Medio), que según Ordinas [2], se pueden clasificar en tres grandes grupos: Control de acceso al medio estático, Control de acceso al medio dinámico y control de acceso al medio aleatorios. Pero según el tipo de topología que se use, se aplica uno u otro. Por ejemplo, en redes con topología en anillo, se usa uno de control dinámico distribuido conocido como Token Passing, si es una red con topología en bus se usa uno de tipo aleatorio como CSMA/CD (Acceso múltiple por detección de portadora / detección de colisiones), y en redes inalámbricas en entornos LAN se utilizaría uno que combina el control estático y el aleatorio.
En la Figura 2, se observa el formato de la trama siguiendo el estándar IEEE 802.3 que contiene los siguientes campos [1][3]:
• Preámbulo (7 bytes): Permite establecer la sincronización entre el emisor y el receptor.
• Delimitador del comienzo de Trama SFD (1 byte): Indica el comienzo real de la trama y permite al receptor localizar el primer bit del resto de la trama.
• Dirección MAC de destino (6 bytes): Especifica la estación o estaciones a las que va dirigida la trama.
• Dirección MAC de Origen (6 bytes): Especifica la estación que envió la trama.
• Longitud (2 bytes): Contiene la longitud del campo de datos LLC (control lógico de enlace) o el campo tipo Ethernet.
• Datos LLC (Variable): Es la unidad de datos proporcionado por el LLC.
• Relleno: Son octetos que se añaden para asegurar que la trama sea lo suficientemente larga de manera , que la técnica de detección de colisiones CD funcione correctamente.
• Secuencia de Comprobación de trama FCS (4 bytes): Comprobación redundante cíclica
de 32 bits que se calcula desde el
preámbulo, el SFD y el FCS.
Figura 2. Contenido de la Trama Ethernet
Fuente: El autor
3.1.2 Protocolo IP
En la capa de red se encuentra el protocolo de Internet o IP. Este protocolo se encarga de determinar la ruta que van a seguir los datos del origen al destino. Este no realiza control de errores ni de flujo de datos. Es un protocolo no orientado a conexión, que intenta que la información llegue a su destino de la mejor forma posible en lo que se conoce como estrategia del mejor esfuerzo. El encabezado IP tal como se presenta en la Figura 3, tiene una longitud de 20 bytes definidos de la siguiente manera [10]:
• Versión (4 bits): Indica el número de la versión. Su valor es 4
• Longitud de Cabecera (4 bits): Es la longitud de la palabra de la cabecera llamado también IHL.
• Tipo de servicio (8 bits): Esta definido en el RFC 1349, y sirve de orientación a los módulos IP de los sistemas finales y a los encaminadores existentes a lo largo de la ruta de los datagramas.
• Longitud Total (16 bits): Es la longitud del fragmento
• Identificación (16 bits): Es un número de secuencia que se une con la dirección origen, destino y el protocolo del usuario, para identificar un datagrama.
• Banderas (3 bits): Cuando se fragmenta un datagrama, el bit indica si este es el único fragmento del datagrama original, en cambio el bit no fragmentar prohíbe la fragmentación si esta activo.
• Desplazamiento de Fragmento (13 bits): Indica a que parte del datagrama original pertenece este fragmento.
• Tiempo de Vida (8 bits): Indica el tiempo en segundos que se le permite a un datagrama permanecer en la interred.
• Protocolo (8 bits): Indica el siguiente protocolo de alto nivel que recibirá el campo de datos en el destino.
• Suma de verificación del encabezado (16 bits): Es el código de corrección de errores y se calcula en cada router.
• Dirección IP de Origen (32 bits): Especifica la dirección de origen y varía según su tipo de dirección IP.
• Dirección IP de Destino (32 bits): Especifica la dirección de destino y varía según su tipo de dirección IP.
• Opciones (variable): Codifica las opciones requeridas por el usuario emisor.
• Relleno (Variable): Garantiza que la cabecera del datagrama tiene una longitud múltiplo de 32 bits.
• Datos (Variable): El campo de datos debe tener una longitud que sea múltiplo entero de 8 bits, donde la longitud máxima del datagrama es de 65535 octetos.
Figura 3. Estructura de un
paquete IP
Fuente: El autor
La mayoría de protocolos de nivel de enlace [2], fijan una longitud máxima de datos a transmitir en una trama, que se conoce con el nombre de MTU (Maximum Transfer Unit). En el caso de Ethernet el MTU es de 1500 bytes. Cuando una estación transmite un paquete IP, conoce la MTU de su interfaz de red y esta restringida a transmitir paquetes IP cuya longitud sea inferior o igual a esta MTU. Caso contrario, el paquete debe fragmentarse. Una descripción más detallada de este protocolo se encuentra en [7]; en cuanto a los protocolos de la capa de transporte de TCP/IP, existen básicamente dos protocolos gobernantes. TCP y UDP.
3.1.3 Protocolo TCP
TCP es un protocolo orientado a la conexión que permite el intercambio fiable de información entre dos extremos de la aplicación.
Este protocolo esta definido con los RFC 793 [1][32],1122,1323,2018 y 2581. La cabecera TCP tiene un tamaño de 20 bytes, y a diferencia del datagrama UDP, es más complejo (ver Figura 4). A continuación se presenta los campos de los que se compone [1]:
• Número de Puerto Origen (16 bits): Identifica la aplicación en la terminal origen
• Número de Puerto Destino (16 bits): Identifica la aplicación en la terminal destino.
• Número de Secuencia (32 bits): Identifica el primer byte del campo de datos que envía el segmento.
• Número de ACK (32 bits)
• Longitud de Cabecera (4 bits): Es la longitud de la cabecera que puede ser variable. Si se usa el campo opciones la longitud puede crecer hasta 60 bytes.
• Reservado (6 bits): Es un campo reservado y se inicializa en cero.
• Control o Flags (6 bits): Tiene 6 indicadores cada uno con una función especifica entre los que están: URG: Segmento urgente. Salta otros segmentos en cola. ACK: Cuando hay acuse de recibido el campo Número de ACK, indica el byte siguiente que espera recibir la conexión TCP. PHS: Los datos deben ser pasados al receptor lo antes posible. Es decir que se le indica a la pila TCP que limpie todos los buferes y transmita cualquier dato pendiente o reenvié aquellos datos a la aplicación apropiada. RST: Restaura la conexión. SYN: Sincroniza los números de secuencia para iniciar una conexión. FIN: El emisor ha terminado el envió de todos los datos [17].
• Tamaño de la Ventana (16 bits): Indica cuantos bytes componen la ventana de transmisión del protocolo de control de flujo por ventana deslizante. Hay que recordar que en TCP la ventana es variable.
• Checksum (16 bits): Esta operación sirve para detectar errores, y la realiza el emisor y la verifica el receptor.
• Puntero de segmento urgente (16 bits): Es usado cuando la bandera URG esta activado, y se usa para hacer que todos los segmentos urgentes salten todas las colas que se puedan formar tanto en el origen como en el destino.
• Opciones TCP (32 bits): Opciones especiales como marcar el timestamp, aumentar el tamaño de la ventana e indicar el tamaño máximo del segmento MSS.
Figura 4. Estructura paquete TCP
Fuente: El autor
Cuando se transmiten datos por el protocolo TCP, es necesario identificar dos tipos de tráfico principales, los cuales se denominan Tráfico Interactivo y tráfico Masivo según Menendez [14], “ por un lado existe un trafico caracterizado por el envió de unidades lógicas de información, cada una de las cuales esta incluida íntegramente en un segmento. Además un segmento sólo contiene una unidad de información y con una relación: tiempo de envío/tiempo no envío baja. A este tipo de tráfico se le denomina interactivo y es propio de las sesiones telnet, rexec, rlogin. El caso contrario es el tráfico Masivo, que se caracteriza por unidades de información dividida en varios segmentos, y una relación tiempo de envío / tiempo no envío alta, es decir alto consumo del ancho de banda del medio de transmisión. Estudios realizados sobre el tráfico TCP dan cuenta de que aproximadamente un 50% de los segmentos TCP son interactivos y el otro 50% es masivo. Pero si se cuenta el número de octetos transmitidos, las estadísticas dicen que el 90% de los octetos que viajan por una red son de tráfico masivo y el resto, es decir el 10% de tráfico interactivo.”
3.1.4 Protocolo UDP
El otro protocolo a nivel de transporte especificado en el RFC 768 [6] es UDP (User Datagram Protocol). Según Stalling [4], “este protocolo es básicamente un servicio no seguro en el que la entrega y la protección contra duplicados no están garantizadas. En contrapartida se reduce la información suplementaria del protocolo, lo que puede ser adecuado en muchos casos”.
Estos casos son generalmente la transmisión de datos en tiempo real como la voz y el video, así como aplicaciones que transmiten información en modo multicast o broadcast. Kurose [1], menciona la poca sobrecarga debida a cabeceras dado que UDP solo añade 8 bytes. UDP omite parámetros como búferes de envío y recepción, control de congestión y el número de secuencia y reconocimiento de paquetes. El encabezado UDP tal como se presenta en la Figura 5, esta definido de la siguiente manera:
• Puerto Origen y destino (16 bits): Identifica las aplicaciones en los terminales origen y destino.
• Longitud (16 bits): Indica la longitud en bytes del datagrama UDP incluyendo su cabecera. La longitud máxima de un datagrama UDP es de 65515 bytes.
• Checksum (16 bits): Es opcional y protege tanto la cabecera como los datos UDP. En caso de algún error se descarta el datagrama y no lo entrega a ninguna aplicación.
Figura 5. Estructura
de Datagrama UDP
Fuente:
El
autor
3.2
TAMAÑO DE LOS PAQUETES
El protocolo IP permite
fragmentar los paquetes si estos exceden el máximo tamaño de transmisión de un
enlace, aunque esta situación no siempre es deseable, y puede generar cierta
degradación en el rendimiento o inclusive problemas en la transmisión.
Generalmente se utiliza un mecanismo que permite controlar esta situación
en el envío de información entre hosts que se denomina MTU (Unidad Máxima de Transferencia). Este fue inicialmente
propuesto en el RFC1063 en 1988, y
tuvo una actualización en el RFC1191
en el año de 1993[2]. El MTU
funciona cuando se envían paquetes y verifica si esta activo el Flag (DF) o do not fragment, cuando el MTU
es muy grande el receptor retorna un mensaje de error ICMP (Tipo 3 Código 4)[3],
que indica que el paquete requiere de fragmentación, por lo tanto el emisor
reduce el tamaño del MTU y
retransmite el paquete al host destino para que lo acepte.
Tener un
optimo MTU no es solo importante en
la transmisión de paquetes sin fragmentación, también en enlaces pequeños estos
pueden generar un mayor impacto en el rendimiento de la red. El MTU por defecto utilizado por los hosts
es de 576 bytes[4].
Este MTU puede variar dependiendo del tipo de
enlace a utilizar, además para poder obtener una alta tasa de throughput posible, el MTU debe ser configurado con un valor
grande, típicamente de 1500 bytes, en
enlaces Ethernet o en enlaces Dialup por Modems. La desventaja es que la latencia se incrementa generando
sobrecarga al momento de encapsular el paquete, por lo tanto es un factor a
tener en cuenta en cualquier tipo de red.
En el RFC2923 se puede encontrar varios problemas y las
soluciones posibles para tener un MTU
óptimo.
3.3 ENVIO
DE DATOS EN LINUX
Las
comunicaciones entre redes se realizan mediante el uso de modelos estructurados
en capas (OSI o Modelo TCP/IP), pero desde el punto de vista de
una aplicación, la comunicación se realiza mediante el uso de sockets,
los cuales definen los dos extremos de una comunicación y permiten el
intercambio de información entre estos dos extremos. Para permitir el uso de la
red a una aplicación, Linux ofrece la interfaz BSD socket interface
(Berkeley Sockets). La interfaz BSD Socket ofrece a los procesos las
funciones necesarias para la comunicación vía red por medio del uso de varias
primitivas. Generalmente los sockets son
puntos de conexión lógicos, los cuales pueden tener asociado un puerto
generalmente definido en el RFC1700.
Debajo de la
Interfaz BSD Socket se encuentra la capa INET Socket, que maneja
los puntos extremos de la comunicación para los protocolos TCP y UDP. Esta capa se
encuentra representada por la estructura de datos sock. A los sockets
de la capa INET Socket se les conoce como INET Sockets. La capa que se encuentra debajo de la
Capa INET Socket viene determinada por el tipo de socket que se
haya utilizado en la Capa INET Socket.
Concretamente
se pueden encontrar las capas TCP, UDP o la capa IP directamente. La capa TCP
implementa el Protocolo TCP, la capa UDP hace lo propio con el Protocolo UDP y en la capa IP se encuentra el código del Protocolo IP. En la Capa IP
confluyen todos los flujos de comunicación de las capas superiores.
Por debajo
de la Capa IP se encuentran los
dispositivos de red, a los cuales la Capa IP
les pasa los paquetes. Estos dispositivos son los que se encargan del
transporte físico de la información. En la figura 6 puede verse que existen diferentes protocolos
de nivel 2 en función del tipo de red a la que quiera conectarse. El dibujo
muestra protocolos y dispositivos físicos para los Puertos Serie y Paralelo y
para Redes Ethernet. Existen
numerosos tipos de redes a las que Linux es capaz de conectarse, ya que
implementa los protocolos de nivel 2 necesarios para utilizar estas redes y
existen drivers para manejar los dispositivos físicos que permiten la conexión
a estas redes. Algunos de estos tipos de redes son IEEE 802.11x, también llamadas redes WiFi (Wireless Fidelity), Fibra Óptica (FDDI), Infrarrojos (IrDa),
Bluetooth, etc.
Figura 6. Estructura de
capas desde el punto de vista de Linux.
Fuente: M. Beck, H. Böme, M. Dziadzka, U Kunitz, R.
Magnus, D. Verworner. Linux Kernel Internals 2nd Ed., Addison-Wesley Eds.,
pp. 1-379. (1997).
3.4 FILTRADO DE PAQUETES
Para realizar la captura de paquetes del canal de comunicaciones se utiliza una librería denominada PCAP. Esta es una API (Application Programming Interface) bajo licencia open source que permite a las aplicaciones desarrolladas capturar, hacer rastreo de paquetes y/o enviar los paquetes a la red. Según sea la aplicación existe una versión del API para Java llamada Jpcap, así como otra para plataforma Windows denominado winpcap. En Linux se conoce como libpcap. Esta librería desarrollada en lenguaje C permite la captura de los siguientes tipos de paquetes: Ethernet, IPv4, IPv6, ARP/RARP, TCP, UDP, e ICMPv4 sin importar el sistema operativo. Ella captura los paquetes directamente desde la tarjeta de red utilizando métodos como los descritos en BPF (Berkeley Packet Filter) [8], DLPI (Data Link Provider Interface) y SOCKET_PACKET type sockets (Solamente en Linux).
En Libpcap la captura real de datos tiene lugar en las capas más bajas del sistema operativo, en la llamada zona Kernel (Kernel area) [26], por lo tanto debe existir un mecanismo capaz de traspasar esta frontera, y hacerlo además de un modo eficiente y seguro, ya que cualquier fallo en capas tan profundas degradará el rendimiento de todo el sistema. Por ejemplo si se programa una aplicación capaz de monitorizar la red en tiempo real en busca de paquetes cuyo puerto TCP origen sea el 135, si no existiese ningún mecanismo de filtrado, el Kernel no sabría cuales son los paquetes en los que esta interesada la aplicación, por lo que tendría que traspasar la frontera Kernel - User space por cada paquete que transite por la red. La solución es que la aplicación establezca un filtro en la zona Kernel y que sólo deje pasar los paquetes cuyo puerto TCP destino sea el 135. Esta es la principal labor de un Packet/Socket Filter.
Para entender el funcionamiento de PCAP, [20] indica 5 pasos esenciales para el desarrollo de cualquier aplicación:
1. Se debe empezar por determinar cual seria la interfaz que se activará para el modo sniffer, esta debe estar en modo promiscuo para facilitar la captura de los paquetes. En Linux se identificaría con algo parecido a eth0, en sistemas BSD con xl1, etc. Es además necesario definir el dispositivo en un string o dar el nombre de la Interfaz durante su ejecución.
2. Se debe iniciar pcap. Cuando se ingresa el identificador de la NIC, se abre un archivo que leería o escribiría los datos durante el escaneo.
3. Si solo se busca la captura de un tráfico especifico (e.g.: Solo paquetes TCP/IP, solo un Puerto especifico, etc) se debe crear un set de reglas, compilarlas y aplicarlas durante la ejecución. Las reglas se deben mantener en un string y estas serían convertidas en un formato que pcap pueda leer. También se leerían desde una función dentro del programa.
4. Cuando pcap entre en el ciclo de ejecución primario, la aplicación recibiría los paquetes de la red cada cierto tiempo. Después se llamara una función que analizara el paquete y lo mostrara al usuario, el cual podrá guardarlo o no.
5. Después de que ya se haya realizado el sniffing se cerrara la sesión.
Resumiendo Lopez Mongue [26] indica la esquematización (Ver Figura 7 ) que cualquier programa basado en pcap debería tener: Inicialización, Configuración de Filtros, Bucle de captura, Extracción de datos, procesado de datos y Terminación o salida, cada una con sus propias funciones y parámetros especiales.
Figura 7 . Esquematización de un programa con Libpcap [26]
Fuente: LOPEZ MONGE, Alejandro. Aprendiendo a Programar con Libpap. 2005
3.4.1 Funciones Principales de Libpcap
3.4.1.1 Selección de la Interfaz de Red.
El primer paso necesario es la selección de la interfaz por la que se desean capturar los paquetes. Para esto se emplea la función char *pcap_lookupdev(char * errbuf), la cual, encuentra la primer interfaz de red y la devuelve en forma de caracteres. El argumento errbuf es un bufer donde se almacena en caso de fallo el error cuando no falla la función.
Si se desea determinar los parámetros de la tarjeta
de red como la dirección IP o la
máscara de red se requiere de la estructura struct
in_addr addr; y después se utiliza la función int pcap_lookupnet(const char
*dev, bpf_u_int32 *net, bpf_u_int32 *mask, char *errbuf) que devolverá dichos valores. El primer
argumento corresponde a la cadena de la
interfaz de red, el segundo y tercer parámetro son índices que respectivamente
serán la dirección IP y la máscara de
red. El último argumento es el índice del búfer del eventual error. En caso de
falta de éxito de la función llamada, allí se introducirá el mensaje. En tal
caso la función devuelve el valor exec (-1).
3.4.1.2 Funciones para Sniffing y Captura [16]
Para poder escuchar la información que circula por una red, se deben de reunir, como mínimo, dos requisitos. El primero es que la red sea de tipo broadcast. El segundo es que la tarjeta de red del usuario que quiera realizar la escucha se encuentre en modo promiscuo.
En la figura
8 puede observarse un escenario que cumple las
dos condiciones anteriores. Por un lado la red de la figura es un medio broadcast
ya que todas las máquinas conectadas reciben la trama de información
enviada y sólo la máquina destinataria de la trama la procesa. Por otro lado,
la máquina que está monitorizando el tráfico puede recibir tramas que no van
dirigidas a ella ya que trabaja en modo promiscuo.
Figura 8. Red en la que un Host
monitoriza el tráfico que fluye por esta
Fuente: El autor.
Cuando una
máquina recibe una trama Ethernet,
ésta se procesa y se entrega a las capas superiores hasta llegar a la capa de
aplicación. A partir de esta capa, la aplicación correspondiente procesa los
datos recibidos. En el caso de un monitor de red, la información que éste
procesa no sólo son los datos de aplicación, sino todos los datos recibidos
incluyendo las cabeceras de las capas de Enlace, Red, Transporte y Aplicación.
De esta manera se puede obtener información sobre quien envía datos en una red,
de que tipo son, a que puertos van dirigidos, etc.
Para iniciar la sesión de captura y rastreo de paquetes, es necesario emplear la función pcap_t *pcap_open_live(char *device, int snaplen, int promisc, int to_ms, char*errbuf). La misma devuelve el índice a la estructura pcap_t. El primer argumento de la función se encarga de usar el dispositivo de red. El siguiente parámetro, es el tamaño máximo del paquete capturado, expresado en bytes. El tercer argumento cuando es 1 indicará a la tarjeta de red que funcione en modo promiscuo, es decir, que capture todos los paquetes de la red disponibles (lo cual hace un sniffer), cuando es igual a 0 la interfaz de red simplemente funcionará en forma estándar. El cuarto parámetro indica el tiempo de espera de los paquetes en milisegundos. Finalmente, el último argumento, es un puntero al búfer del eventual error en caso de cualquier falla, el mensaje se introducirá allí.
3.4.1.3 Filtrado de paquetes en Libpcap
En la mayoría de aplicaciones que utilizan la
librería pcap, se requiere del
filtrado especial de paquetes de acuerdo a algún criterio del usuario. Para
esto se utiliza generalmente la función int
pcap_compile(pcap_t *p, struct bpf_program *fp, char *str, int optimize,
bpf_u_int32 netmask).
Su primer parámetro es el puntero de la interfaz, el segundo argumento, es el índice del filtro, el tercer parámetro es el filtro (en forma de título) guardado por convención de la aplicación tcpdump, por ejemplo: puerto 80 o IP host 192.168.0.1. Si en el cuarto argumento se da el valor 1 la expresión será optimizada, en caso de introducir 0 solamente se compilará. El último parámetro es la máscara de red de la interfaz . La función devuelve -1 en caso de error. Ahora se procede a enlazar el filtro dado con el puntero del dispositivo de red, por lo cual es útil la función int pcap _ setfilter(pcap _ t *p, struct bpf _ program *fp). Su primer argumento es el puntero hacia la interfaz y el siguiente es el índice del filtro (el mismo que el empleado como segundo argumento de la función int pcap_compile( ). La función devuelve -1 en caso de error.
3.4.1.4 Rastreo de paquetes
Según Skwarek [16] y Lopez Mongue [26] para el rastro de paquetes se dispone de dos formas:
• Rastrear paquetes individuales por medio de la función u_char *pcap_next(pcap_t *p, struct pcap _ pkthdr *h). Esta función lee un único paquete y devuelve un puntero a u_char con su contenido sin necesidad de declarar ninguna función Callback y devuelve el índice del contenido del paquete rastreado. El primer argumento es el puntero a la interfaz de red y el segundo es el índice de la estructura pcap_pkthdr. Esta estructura incluye tres campos: tiempo, cuando el paquete ha sido rastreado, su tamaño total y duración de una porción concreta rastreada. A continuación se presenta esta estructura:
struct pcap pkthdr {
struct timeval ts; // time stamp (marca de
tiempo)
bpf u int32 caplen; // tamaño del paquete al
ser capturado
bpf u int32 len; // tamaño real del paquete
en el fichero;
};
• Rastreo de paquetes en el nudo, por ejemplo, por
medio de la función int pcap_ loop(pcap_t
*p, int cnt, pcap_handler callback, u_char *user). El primer argumento es el
puntero del dispositivo de red, el siguiente parámetro es la cantidad de
paquetes que se desea rastrear (el valor negativo significará un rastreo
infinito). El tercero es la función callback, la cual se llama cuando el
paquete dado coincide con el filtro. La función devuelve -1 en caso de
error.
Generalmente
la función callback se programa según el prototipo:
void my_callback(u_char
*args, const struct pcap_pkthdr *header, const u_char *packet)
En donde el
primer argumento se da en NULL, el
siguiente es el índice de la estructura pcap_pkthdr,
explicada antes, y el último parámetro, es el índice del contenido del paquete
rastreado.
3.4.1.5 Extracción de la Información
Cuando
ya se termine el proceso de recolección y captura de paquetes, se debe proceder
a su respectivo análisis para lo cual se requiere del uso de estructuras
especiales, así como el entendimiento de los diferentes RFC (Request
For Comment)[5] mas importantes como el RFC 793 para TCP, RCF 791
para IP, RFC 768 para UDP, RFC 826 para ARP y el RFC 792 para
ICMP. En los sistemas Linux las estructuras
están ubicadas en los directorios /usr/include/netinet/
y en /usr/include/net/, los cuales se presentan en la figura
9.
Figura 9. Principales estructuras de red contenidas en Linux
Fuente: El autor
3.4.1.5.1 Cabecera Ethernet
Para
poder hacer la captura de las tramas Ethernet
y su posterior análisis es necesario entender el contenido del header Ethernet.h ubicado en el
directorio /usr/include/net/ el cual
tiene el siguiente contenido:
#ifndef
__NET_ETHERNET_H
#define
__NET_ETHERNET_H 1
#include
<sys/cdefs.h>
#include
<sys/types.h>
#include
<linux/if_ether.h> /* IEEE
802.3 Ethernet constants */
__BEGIN_DECLS
/* This
is a name for the 48 bit ethernet address available on many
systems.
*/
struct
ether_addr
{
u_int8_t ether_addr_octet[ETH_ALEN];
}
__attribute__ ((__packed__));
/* 10Mb/s
ethernet header */
struct
ether_header
{
u_int8_t
ether_dhost[ETH_ALEN]; /*
destination eth addr */
u_int8_t
ether_shost[ETH_ALEN]; /*
source ether addr */
u_int16_t ether_type;
/* packet type ID field */
}
__attribute__ ((__packed__));
/*
Ethernet protocol ID's */
#define ETHERTYPE_PUP 0x0200
/* Xerox PUP */
#define ETHERTYPE_IP 0x0800 /*
IP */
#define ETHERTYPE_ARP 0x0806 /*
Address resolution */
#define ETHERTYPE_REVARP 0x8035 /*
Reverse ARP */
#define ETHER_ADDR_LEN ETH_ALEN /* size of ethernet addr */
#define ETHER_TYPE_LEN 2 /* bytes in type field
*/
#define ETHER_CRC_LEN 4 /*
bytes in CRC field */
#define ETHER_HDR_LEN ETH_HLEN /*
total octets in header */
#define ETHER_MIN_LEN (ETH_ZLEN + ETHER_CRC_LEN) /* min packet length */
#define ETHER_MAX_LEN (ETH_FRAME_LEN + ETHER_CRC_LEN) /* max packet length */
/* make
sure ethenet length is valid */
#define ETHER_IS_VALID_LEN(foo) \
((foo) >= ETHER_MIN_LEN
&& (foo) <= ETHER_MAX_LEN)
/*
* The ETHERTYPE_NTRAILER packet types starting
at ETHERTYPE_TRAIL have
* (type-ETHERTYPE_TRAIL)*512 bytes of data
followed
* by an ETHER type (as given above) and then
the (variable-length) header.
*/
#define ETHERTYPE_TRAIL 0x1000 /* Trailer packet */
#define ETHERTYPE_NTRAILER 16
#define ETHERMTU ETH_DATA_LEN
#define ETHERMIN (ETHER_MIN_LEN - ETHER_HDR_LEN - ETHER_CRC_LEN)
__END_DECLS
#endif /* net/ethernet.h */
Se
puede observar que la estructura que contiene las cabeceras Ethernet es ether_header que contiene la
dirección Ethernet de origen
(ether_shost), la dirección Ethernet
de destino (ether_dhost) y el tipo que puede ser los siguientes[6]:
ETHERTYPE_PUP Xerox PUP
ETHERTYPE_IP Es un paquete de tipo IP
ETHERTYPE_ARP Es
un paquete de tipo ARP (traducción de
direcciones ethernet a IP)
ETHERTYPE_RARP Es un paquete de tipo RARP (traducción de direcciones IP
a ethernet)
Las cabeceras
ethernet tienen un tamaño de 14 bytes que se calculan con la rutina int size_eth
= sizeof (struct eth_hdr); y los siguientes
dependen del tamaño que tome el campo ether_type. A continuación se
realiza la siguiente asignación ethernet
= (struct eth_hdr*)(packet)) y se tendrá acceso a la dirección MAC mediante la estructura Ethernet del remitente y del
destinatario y el tipo del paquete.
3.5
GENERADORES DE TRÁFICO
Existen herramientas de software libre que permiten generar tráfico UPD o TCP utilizando distribuciones de probabilidad tipo Poisson, Normal, Uniforme, Exponencial, entre otras. Algunos de estos generadores son [22]:
• Distributed Internet Traffic Generator (D-ITG): Utiliza distribución constante, uniforme, exponencial, pareto, cauchy, normal, poisson, y Gamma.
• Poisson Generator: Utiliza Poisson
• Self-similar Generator: Genera tráfico self-similar
• MGEN: Utiliza periódica, poisson, y a ráfagas (bursty)
• Traffic Generator: Trafico UDP y TCP / constante, uniforme, exponencial y utiliza cadenas de Markov.
• Harpoon: Genera flujos usando parámetros distribuidos, sacados de trazas de Netflow.
• Tcpreply: Genera tráfico desde trazas generadas con tcpdump.
3.5.1 Mgen (NRL
Multi-Generator)
En este proyecto, se utilizo MGEN [19] y [28], por ser uno de los generadores de tráfico más conocidos y utilizados en el ámbito científico. Esta es una herramienta de software libre basada en comandos desarrollada por el Laboratorio de Investigación Naval de Estados Unidos, el cual fue concebido por el grupo PROTEAN (PROTocol Engineering Advanced Networking), que permite hacer mediciones y pruebas de rendimiento sobre una red IP, utilizando tráfico UDP/IP. La herramienta puede generar patrones de tráfico en tiempo real que se pueden usar en variedad de formas. Es posible usar archivos de scripts especiales para cargar dichos patrones en el tiempo. También permite emular patrones de tráfico en aplicaciones de tipo unicast o multicast usando los protocolos UDP/IP; permite además soporte a IPv6, inclusive en ambientes de simulación de redes como OPNET y ns-2. El log de datos de MGEN se puede usar para calcular tasas de pérdida de paquetes, estadísticas de rendimiento, retardos en la comunicación entre otras. MGEN que actualmente esta en la versión 4.2, tiene otra ventaja y es que funciona en variedad de sistemas operativos de red como sistemas basados en UNIX, MacOS X y plataformas Windows.
3.6 SNIFFERS
Estas aplicaciones se encargan de capturar e interpretar tramas y datagramas en entornos de red basados en difusión, conocidos como escuchas de red o sniffers, en donde es posible hacer un análisis de la información contenida en los paquetes TCP/IP que se interceptan, para poder extraer todo tipo de información.
La información a obtener puede ser de todo tipo, desde el contenido de las cabeceras de los paquetes hasta el payload (datos de los paquetes). Estas herramientas permiten además la captura de diferentes tipos de protocolos de red como ARP,RARP, UDP, ICMP, HTTP, etc, lo cual permite a los administradores de red obtener información valiosa y útil.
Según Gontt [12], “para poder capturar paquetes, el sistema en el cual se está ejecutando el sniffer debe tener acceso a aquellos paquetes que se desean capturar. Esto implica que dicho sistema deberá estar en alguna de las redes a través de las cuales dichos paquetes circulan. En el caso de las redes de Área Local (LAN) que utilizan tecnología Ethernet, generalmente se construyen utilizando alguno de estos equipos: HUBs (concentradores) o switches (conmutadores). Los Hubs básicamente enviaran aquellos paquetes enviados por un equipo, a todos los demás equipos conectados al hub. Así cualquier sistema conectado a un hub tiene acceso a todos los paquetes transferidos a través de dicha LAN. Los switches, por el contrario, al recibir un paquete, envían el mismo solamente al equipo destinatario….”
3.6.1
Desactivación de Filtro MAC
Una de las técnicas más usadas por la mayoría de sniffers de redes Ethernet,
se basa en la posibilidad de configurar la interfaz de red, para que desactive
su filtro MAC poniendo la tarjeta de
red en modo promiscuo, es decir que se pueda capturar tanto los paquetes
destinados a la máquina como el resto de tráfico de la misma red.
Con el uso adecuado de expresiones regulares y otros filtros de texto,
se podrá visualizar o almacenar únicamente la información que más interesa. El entorno en el que suele ser más efectivo
este tipo de escuchas son las redes LAN
configuradas con una topología en bus. En
este tipo de redes, todos los equipos están conectados a un mismo cable. Esto
implica que todo el tráfico transmitido y recibido por los equipos de la red
pasa por este medio común. Debido a
esto, lo más recomendable por seguridad es que el administrador realice una
segmentación de la red y de los equipos haciendo uso de switches, con esto se minimizarán algunos peligros.
3.6.2
Herramientas para hacer Sniffing
Ettercap, que funciona desde consola, ofrece un entorno más interactivo y muestra
conexiones accesibles desde la máquina donde se encuentra instalado y que
permite seleccionar cualquiera de ellas para la captura de paquetes.
Otra herramienta es Ethereal (Actualmente se llama Wireshark), que es un analizador de
protocolos (soporta 480 protocolos) utilizado para realizar análisis y
solucionar problemas en redes de comunicaciones para desarrollo de software y
protocolos, y como una herramienta didáctica para educación.
La funcionalidad
que provee es similar a la de tcpdump,
pero añade una interfaz gráfica y muchas opciones de organización y filtrado de
información.
Para el desarrollo de este proyecto se utilizo TCPDUMP, la cual se explica a continuación:
3.6.3 Tcpdump
Esta herramienta es una de las más utilizadas por administradores de red, es tipo open source y además es multiplataforma. Es un sniffer (simplemente captura el tráfico que circula por las redes a las cuales se encuentra conectado y decodifica dicha información para que sea inteligible al usuario) fue escrito por: Van Jacobson, Craig Leres y Steven McCanne, todos ellos del Lawrence Berkeley Laboratory de la UCLA. Esta herramienta ha sido utilizada desde hace varios años para obtener los registros de los paquetes incluidos en los protocolos TCP y UDP. Esta herramienta funciona en modo consola y se basa en una serie de comandos muy completos (Menendez: 69-76) y (Gont.[7]: 44).
3.6.3.1
Sintaxis de TCPDUMP
Este programa se lanza mediante una Shell de comandos y la sintaxis general de tcpdump es la siguiente:
tcpdump opciones expresión
Las opciones determinaran como será la salida, es decir, que campos se mostrarán, con que formato, el número de puerto, etc, y la expresión indica cuales son los paquetes que se desean capturar, por ejemplo, los paquetes de un determinado protocolo o con un determinado contenido, etc. Es importante anotar que dependiendo del protocolo elegido la salida será diferente y con campos específicos.
Un parámetro importante para especificarle a tcpdump es la interfaz en la que se desea capturar los paquetes. Para esto se utiliza la opción –i y el nombre de la interfaz. El comando es el siguiente: tcpdump – i <interfaz de red>
Figura 10. Salida estándar de TCPDUMP
Fuente: El Autor
En la anterior salida cada línea representa un paquete, en donde el primer campo indica la hora, el segundo la dirección IP, luego viene un carácter que representa gráficamente el sentido de los datos, seguido por la dirección IP. A continuación aparecen flags que pueden tener distintos valores de acuerdo al tipo de protocolo.
Por defecto tcpdump intentará convertir las direcciones IP de los sistemas origen y destino a nombres de dominio, si no es posible hacerlo mostrará solo las direcciones IP tal como fueron encontradas en los paquetes capturados. Si se utiliza la opción –n se le puede indicar que no realice la conversión de direcciones IP a nombres de dominio.
A continuación se presenta el uso del comando con un ejemplo:
tcpdump –i eth0 –n icmp
Este comando indica que capture tráfico ICMP por la interfaz eth0 pero sin hacer la conversión de las direcciones IP de Origen y Destino.
3.6.3.2
Información extendida
Tcpdump siempre mostrará aquella información de los paquetes capturados que supone imprescindible para poder entender el tráfico en cuestión. Sin embargo en ocasiones es necesario tener más información para su respectivo análisis, por lo que esta herramienta trae una opción que permite al usuario que tcpdump muestre información extendida sobre los paquetes capturados. Esta opción se conoce como verbose y para esto se utiliza la opción –v.
Por ejemplo si se utiliza el comando tcpdump –i eth0 –n –v icmp se obtendría la siguiente salida:
Figura 11. Salida de TCPDUMP con Verbose
Fuente: El Autor
En esta salida se puede observar información adicional como el número de identificación del paquete ICMP (que corresponde al número del proceso PID de la instancia del ping en cuestión), el número de secuencia del paquete (utilizado para identificar las distintas peticiones y respuestas), el TTL (time to live) y el ID o número de identificación de cada uno de los paquetes IP. Además es posible utilizar la opción
–vv que mostraría información aun más detallada.
3.6.3.3
Salida del Sniffer
Tcpdump soporta la opción –w que permite especificar un archivo en el cual se guardaran los paquetes capturados. Esto permitirá al usuario tener a disposición los paquetes originales, por si en un futuro se desea analizar el contenido de los mismos. El siguiente es un ejemplo del uso de esta opción:
tcpdump –i eth0 –w archivo.extension icmp
Una vez realizado este procedimiento se puede indicar a tcpdump que decodifique los paquetes almacenados en dicho archivo mediante la opción –r así:
tcpdump –r archivo.extension
3.6.3.4
Direcciones de la capa de enlace
Cuando se desean transferir paquetes de información mediante tecnologías de red, en las cuales todas las estaciones comparten el mismo medio de enlace (como por ejemplo Ethernet, Token Ring, etc), se utilizan direcciones de red en la capa de enlace, para identificar el origen y el destino de dichos paquetes. La opción –e de la herramienta tcpdump permite especificar que se desea visualizar las direcciones de capa de enlace que fueron utilizadas para la transmisión de los paquetes capturados. A continuación se presenta un ejemplo de este caso:
tcpdump –i eth0 –e <protocolo>
Por defecto tcpdump, no captura la totalidad de los paquetes recibidos, sino que captura solamente los primeros 96 bytes[7]. Esto permite que se utilice menos memoria para almacenar los paquetes capturados, permitiéndose igualmente la decodificación de los mismos. Sin embargo, si el protocolo a decodificar utilizara información mas allá de los primeros 96 bytes del paquete capturado, o bien si se desea tener acceso a la totalidad del mismo, es necesario utilizar la opción –s que permite especificarle a tcpdump la máxima cantidad de bytes que se desea capturar por cada paquete. Para especificarle a tcpdump que capture un MTU típico de una trama Ethernet es decir 1500 bytes se utilizaría el siguiente comando:
tcpdump –i eth0 –s 1500
Figura 12. Salida de TCPDUMP con Snaplength
Fuente: El Autor
3.6.3.5 Filtros con TCPDUMP[8]
Un filtro es una expresión especial que permite seleccionar los paquetes que se están buscando. En ausencia de ésta, tcpdump volcará todo el tráfico que vea el adaptador de red seleccionado.
La expresión que se usa para definir el filtro tiene una serie de primitivas y tres posibles modificadores a las mismas. Esta expresión será verdadera o falsa y hará que se imprima o no el paquete de datos.
Los 3 modificadores posibles son:
3.7 INGENIERÍA DE SOFTWARE
La
Ingeniería del Software se podría definir como el establecimiento y la
aplicación de principios de ingeniería para obtener software, teniendo en
cuenta factores tan importantes como el factor económico, la fiabilidad del
sistema y un funcionamiento que satisfaga las necesidades del usuario. [9]
En el
desarrollo de un proyecto intervienen diferentes etapas que se interrelacionan
y complementan con la finalidad de alcanzar los objetivos iníciales. Estas
etapas pueden variar dependiendo del ciclo de vida que se haya decidido para el
sistema, pero las principales fases son el análisis de requerimientos, la
especificación, el diseño, el desarrollo e implementación y por último el
mantenimiento.
Los
proyectos de desarrollo de software se diferencian de los otros proyectos de
ingeniería tradicional en la naturaleza lógica del producto software.
Recordemos
que “el software se desarrolla, no se fabrica en un sentido clásico”. En
todos los proyectos de ingeniería la
buena calidad se adquiere mediante un buen diseño, pero en el caso del
software, la etapa de construcción poco incide en su calidad, no así en la
construcción de hardware o de una obra civil. Otra diferencia es que el
“software no se estropea” [10],
el paso del tiempo o males del entorno no inciden en el aumento de la tasa de
fallas. Así, no se puede gestionar un proyecto de desarrollo de software como
si se tratara de un proyecto de fabricación.
En la actualidad
el desarrollo del software exige aplicaciones que cuenten con toda la calidad
posible, y esta depende de la forma en la que el mismo desarrollo se lleve a
cabo. Por lo cual la Ingeniería de Software se encarga de tener un seguimiento
de todo el ciclo de vida del mismo, con el fin de garantizar dicha calidad a un
costo accesible.
Fairley define a la ingeniería de software : “La ingeniería
de software se define como la disciplina técnica preocupada de la
producción sistemática y del mantenimiento de los productos de software que son
desarrollados y modificados en tiempo y dentro de un presupuesto definido” [11].
La ingeniería de
software cuenta con tres elementos importantes:
·
Los métodos
comprenden la parte de la planificación, análisis de los requisitos del
sistema, diseño de estructuras de datos, procedimientos, algoritmos,
codificación, pruebas y mantenimiento, es decir, “indican como construir
técnicamente el software”
·
Las herramientas suministran el soporte automático o
semiautomático para cada uno de los métodos. “Cuando se integran las
herramientas de forma que la información creada por una herramienta pueda ser utilizada por otra,
se establece un sistema para el soporte del desarrollo del Software, llamado Ingeniería
del Software Asistida por Computadora (en inglés, CASE) [12]
·
Los procedimientos
definen la secuencia en la que se aplican los métodos, las entregas que se
requieren y las herramientas que se deben utilizar, los controles que se deben
tener y los controles que ayudan a
asegurar la calidad, o sea, las directrices para llevar a término el proceso.
En la
construcción y desarrollo de proyectos se aplican métodos y técnicas para
resolver los problemas, la informática es la que se encarga de aportar estos
recursos sobre los que se apoya la ingeniería de software. Dentro de los objetivos que podemos enunciar tenemos:
·
Mejorar
la calidad de los productos de software
·
Aumentar
la productividad y trabajo de los ingenieros del software.
·
Facilitar
el control del proceso de desarrollo de software.
·
Suministrar
a los desarrolladores las bases para construir software de alta calidad en una
forma eficiente.
·
Definir
una disciplina que garantice la producción y el mantenimiento de los productos
software desarrollados en el plazo fijado y dentro del costo estimado.
3.7.2 Planificación de un Proyecto
de Ingeniería De Software.
La
planificación involucra la especificación de objetivos y metas para un proyecto
y las estrategias, políticas, planes y procedimientos para alcanzarlos.
Todo
proyecto de ingeniería de software debe partir con un buen plan. La
planificación es necesaria por la existencia de pocas certezas sobre el
ambiente del proyecto software y sobre fuentes externas. La planificación
enfoca su atención en las metas del proyecto, riesgos potenciales y problemas
que puedan interferir con el cumplimiento de esas metas.
Los principales
problemas en la planificación de un proyecto de ingeniería de software incluyen
los siguientes:
•
Requerimientos incorrectos e incompletos.
• Muchas
especificaciones de requerimientos son inestables y sujetas a cambios mayores.
• La
planificación no se lleva a cabo por la creencia errónea de que es una pérdida
de tiempo y los planes cambiarán de todos modos.
• La
planificación de costos y plazos no es actualizada y se basa en necesidades de
mercadeo y no de los requerimientos del sistema.
• Es
difícil estimar el tamaño y complejidad del proyecto de software de modo de
realizar una estimación de costos y plazos realista.
• Los
costos y plazos no son estimados cuando los requerimientos del sistema o el
ambiente de desarrollo cambian.
• No se
manejan factores de riesgo.
• La mayoría
de las organizaciones de desarrollo de software no recolectan datos de
proyectos pasados.
• Las
compañías no establecen políticas o procesos de desarrollo de software.
Las actividades que se derivan de la planificación son:
• Fijar
los objetivos y metas
•
Desarrollar estrategias
• Anticipar
futuras situaciones
• Conducir
un establecimiento de riesgos
•
Determinar posibles cursos de acción
• Tomar
decisiones de planificación
• Fijar
procedimientos y reglas
•
Desarrollar los planes del proyecto
• Preparar
presupuestos
•
Documentar los planes del proyecto.
Involucra
desarrollar una estructura organizacional efectiva y eficiente para asignar y
completar las tareas del proyecto y establecer las relaciones de autoridad y
responsabilidad entre las tareas.
Las
actividades que se deben tener en cuenta en la organización son:
•
Identificar y agrupar las funciones, actividades y tareas del proyecto.
•
Seleccionar estructuras organizacionales
• Crear
posiciones organizacionales
• Definir
responsabilidades y autoridades.
•
Establecer el perfil de cada puesto
•
Documentar las decisiones organizacionales
“La ingeniería del software está compuesta por una
serie de pasos que abarcan los métodos,
las herramientas y los procedimientos antes mencionados. Estos pasos se
denominan frecuentemente paradigmas
de la ingeniería del software.
La elección de un paradigma para la ingeniería del software se lleva a cabo de
acuerdo con la naturaleza del proyecto y de la aplicación, los métodos y
herramientas a usar y los controles y entregas requeridos” [13]
3.7.4
Modelo de Desarrollo Incremental
Los
riesgos asociados con el desarrollo de sistemas largos y complejos son enormes.
Una forma de reducir los riesgos es construir sólo una parte del sistema,
reservando otros aspectos para niveles posteriores. El desarrollo es un proceso
de construcción siempre incrementando subconjuntos de requerimientos del
sistema. Típicamente, un documento de requerimientos es escrito al capturar
todos los requerimientos para el sistema completo.
El
desarrollo incremental es 100% compatible con el modelo cascada y no demanda
una forma específica de observar el desarrollo de algún otro incremento. Así,
el modelo cascada puede ser usado para administrar cada esfuerzo de desarrollo,
como se muestra en la figura 13 y 14.
El modelo
de desarrollo incremental provee algunos beneficios significativos para los
proyectos:
•
Construir un sistema pequeño es siempre menos riesgoso que construir un sistema
grande.
• Al ir
desarrollando parte de las funcionalidades,
es más fácil determinar si los requerimientos planeados para los niveles
subsiguientes son correctos.
• Si un
error importante es detectado, sólo la última iteración necesita ser descartada.
•
Reduciendo el tiempo de desarrollo de un sistema (en este caso en incremento
del sistema) decrecen las probabilidades que esos requerimientos de usuarios
puedan cambiar durante el desarrollo.
• Si un
error importante es detectado, el incremento previo puede ser usado.
• Los
errores de desarrollo detectados en un incremento, pueden ser arreglados antes
del comienzo del próximo incremento.
Figura 13. Modelo de Desarrollo Incremental
Fuente: El autor
Figura 14. Modelo de Desarrollo Incremental
con desarrollo en cascada de los incrementos
Fuente: El autor
4.
METODOLOGIA DE LA INVESTIGACION
Este proyecto se realizo combinando los diferentes
paradigmas usados en la Ingeniería de Software,
e incluye etapas como el análisis y diseño, desarrollo, y pruebas.
Para el software,
se utilizo una metodología de desarrollo incremental con sucesivas iteraciones
en cada etapa hasta llegar a la versión final de la herramienta. Esta
metodología permite que el software
sea probado por el usuario por etapas refinadas sucesivamente a lo largo del
proyecto, de manera que se sabe exactamente que es lo que se va a construir
realizando mejoras o correcciones al sistema en un menor tiempo.
Se escogió esta metodología para el desarrollo de este
proyecto, porque es importante que la entrega de la herramienta no se haga
hasta el final del proyecto; reduciendo así el riesgo de hacer modificaciones
después de tener el software terminado.
Se desarrollaron inicialmente 5 etapas las cuales se
describen a continuación:
4.1 CONCEPTUALIZACION
-
Conocer y estudiar las
herramientas de software empleadas para el desarrollo del proyecto.
-
Conocer los estándares
de desarrollo que se pueden aplicar al proyecto
-
Establecer los requerimientos
de hardware necesarios para el sistema.
-
Estudiar el
funcionamiento y arquitectura de los protocolos de red TCP, ARP, IP, ICMP y UDP.
Producto: Identificación de los requerimientos del sistema.
4.2 ANÁLISIS DE
REQUERIMIENTOS Y DISEÑO
-
Establecer la arquitectura del software.
-
Redactar y acordar los
requerimientos del sistema.
-
Diseñar el ambiente de
pruebas (testbed)
-
Modelar el software
por medio de los diferentes diagramas de UML.
Producto: Documento de requerimientos establecidos para el sistema.
4.3 CODIFICACIÓN, DEPURACIÓN Y PRUEBAS (INCREMENTO
1)
-
Instalación y
configuración de las herramientas de Software
a utilizar
-
Codificación de la
herramienta según el análisis y el diseño realizados.
-
Realizar las
validaciones necesarias para la herramienta.
-
Refinar y documentar
el código.
-
Configurar el testbed.
-
Hacer pruebas al prototipo
inicial.
-
Realizar
las correcciones necesarias al prototipo inicial.
-
Documentación de la
herramienta, elaborando los manuales necesarios.
Producto: prototipo Beta de la herramienta.
4.4 CODIFICACIÓN,
DEPURACIÓN Y PRUEBAS (INCREMENTO 2)
-
Evaluación del prototipo.
-
Mejora y optimización
del código
-
Creación de archivo INSTALL y Makefile
Producto: Prototipo final de la herramienta.
4.5 ENTREGA DEL SISTEMA
-
Análisis de Resultados
-
Realizar la entrega
formal de la herramienta.
-
Redacción e impresión
del documento final
Producto: Herramienta
de estimación en tiempo real de consumo de ancho de banda con licencia GPL.
5. DESARROLLO DEL SISTEMA
5.1 REQUERIMIENTOS
GENERALES
Los requerimientos generales del sistema se desglosan a partir de la identificación y definición de datos y la estructura de la información en la que se va a componer la herramienta.
A continuación se presentan los principales requisitos establecidos en el proyecto:
q La herramienta tiene licencia GPL (General Public License), por lo cual respetará las libertades que da la Free Software Foundation.
q La herramienta funciona bajo plataforma GNU/Linux
q Es necesario el uso de la librería libpcap para la captura de tráfico.
q Será utilizada por línea de comandos.
q La herramienta se desarrollará con el lenguaje de programación C, para lo cual se empleo el compilador gcc (GNU Compiler C)
q El usuario puede seleccionar la tarjeta de red que desea.
q El sistema será utilizado siguiendo el esquema Cliente / Servidor.
q Se considera la reutilización de código.
q Se requiere la captura del timestamp de los paquetes enviados, la longitud de la trama Ethernet y por último el ancho de banda calculado.
q La herramienta tendrá un proceso de instalación típico de las herramientas libres bajo sistemas *NIX, como el uso de un MakeFile.
q El usuario podrá cancelar la captura de tráfico en cualquier momento.
q El software deberá sincronizarse contra el tráfico generado por MGEN
q La herramienta generada deberá tener su correspondiente documentación.
5.2 ANÁLISIS
En primera instancia el modelo utilizado fue el desarrollo
incremental. Este modelo permitió un control total
para el desarrollo del sistema, desde su conceptualización, pasando por la recolección de requerimientos
iníciales, los que fueron complementados mediante asesorías realizadas en el
transcurso del desarrollo del sistema por parte del director del mismo; además
facilitó los cambios, permitiendo la entrega de los distintos avances a través
de versiones y prototipos, que se evaluaron y aprobaron a satisfacción.
Es importante destacar que la herramienta desarrollada
realizará tres etapas importantes que son, la captura, el análisis de los
paquetes y la presentación de resultados.
5.2.1
Casos De Uso
Para un mejor análisis se han generado varios casos de uso generales los cuales se explicarán a continuación:
Figura 15. Caso de Uso Envío y Captura de Tráfico
Fuente: El autor
En la herramienta se utilizarán dos Actores denominados Sender y Receiver, los cuales tendrán las siguientes funciones:
Sender: Será el encargado de generar tráfico UDP o TCP a la red, el cual llegará al Receiver para posterior análisis. Esta máquina será ejecutada bajo ambiente Linux.
Receiver: Será el encargado de capturar el tráfico generado por el Sender y realizará por medio de la herramienta desarrollada el respectivo análisis y generación de la salida deseada. Esta máquina será ejecutada bajo ambiente Linux.
Figura 16. Caso de Uso Generación de tráfico por el Sender.
Fuente: El autor
Para uso del equipo sender (el cual genera el tráfico a analizar); se tiene instalada la aplicación MGEN, en la cual como se describió anteriormente se deberá configurar un script especial, así como elegir el tipo de tráfico a generar como Poisson, Bursty (Ráfaga) o periodic, y por último ejecutar el demonio del aplicativo. Luego se enviará todo el tráfico a la dirección IP del Receiver escogido.
Figura 17:
Caso de Uso Captura y Análisis de paquetes en el Receiver
Fuente: El autor
En la figura 17 el receiver apenas recibe y captura el paquete (debe hacerse en un loop y con la tarjeta de red en modo promiscuo), procede a realizar el respectivo análisis, para generar la salida deseada al usuario final.
Figura 18. Caso de Uso Análisis de Tráfico
Fuente: El autor
Como resultado de las especificaciones, la información gira en torno a los paquetes que se capturan en tiempo real especialmente los que vienen de la capa 2 del modelo OSI. Cuando el kernel de Linux vea el paquete y tome del encabezado de capa 2 la longitud del campo de datos que corresponde a la longitud del paquete en capa 3 que tiene encapsulado a su vez los headers de la capa de transporte más el payload.
Para el análisis
de tráfico en el receiver se procede una vez capturado cada paquete a
identificar su Timestamp esto con el fin de poder calcular la diferencia de envío
entre paquetes para calcular el ancho de banda. Además se requiere capturar la
longitud del paquete en bytes.
Es
importante tener en cuenta que durante el proceso de captura y dependiendo del tipo
de trafico se pueden almacenar una gran cantidad de datos, sobre todo en redes
de alta velocidad, por lo que en tiempos de medición cortos se podrían tener
datos de un de cercano a los GigaBytes.
Antes de
continuar es necesario revisar cual es el procedimiento para el cálculo de los
anchos de banda. Las bases para esto se
pueden encontrar en el RFC1323[14], en un
documento denominado “TCP: Extensions for
High Performance”, en el cual se indica que el rendimiento de una conexión TCP está dada por el retardo (latencia)
entre el envió de dos paquetes medida en segundos y el cual se rige por la
siguiente fórmula:
Bandwidth (bits/sec) x delay(second)= data (bits)
El resultado
de este cálculo será el tamaño total de datos que se transmitirán en un
determinado tiempo por la red.
El campo Bandwidth se calcula en bps, por lo que se requerirá de la siguiente fórmula:
Bandwidth=(longitud Packet (bytes)* 8) / (diferencia de tiempos entre
paquete n+1 y paquete n)
Para ilustrar el proceso, se utilizará en el siguiente ejemplo el comando
tcpdump -s 0 -eNi eth0
en donde la
opción –s 0 imprime la longitud requerida de los paquetes, -e imprime la información de las cabeceras
de la capa de enlace, -N no imprime el nombre del dominio
y –
i permite elegir la interfaz por la cual se capturarán los paquetes que
será la eth0.
La siguiente es una salida típica de este comando:
21:01:11.591329 00:00:0c:13:dd:ff
(oui Cisco) > 00:04:e2:fb:e7:a3 (oui Unknown), ethertype IPv4 (0x0800), length 1066: US172.64374
> China172.commplex-link: UDP, length 1024
21:01:11.592928 00:00:0c:13:dd:ff
(oui Cisco) > 00:04:e2:fb:e7:a3 (oui Unknown), ethertype IPv4 (0x0800), length 1066: US172.64374
> China172.commplex-link: UDP, length 1024
21:01:11.594528 00:00:0c:13:dd:ff
(oui Cisco) > 00:04:e2:fb:e7:a3 (oui Unknown), ethertype IPv4 (0x0800), length 1066: US172.64374
> China172.commplex-link: UDP, length 1024
21:01:11.596224 00:00:0c:13:dd:ff
(oui Cisco) > 00:04:e2:fb:e7:a3 (oui Unknown), ethertype IPv4 (0x0800), length 1066: US172.64374
> NChina172.commplex-link: UDP, length 1024
En la anterior salida se observa primero el Timestamp, luego la MAC Address de origen, la MAC Address de destino, el tipo de paquete ETHERTYPE que en este caso es 0x0800 lo que indica que es de tipo IP y la longitud del paquete en bytes.
Ahora el primer paquete fue capturado a las 21:01:11.591329 el cual tiene una longitud de 1066 bytes y el segundo fue capturado 21:01:11.592928, esto indica que en 0.001599 segundos o 1,599 milisegundos se transmitió un paquete de 1066 bytes. Aplicando la fórmula se tendría que:
BW=(1066 bytes * 8) / 0.001599seg =
5333333,33 bits/seg
Este resultado indica que el ancho de banda calculado es de aproximadamente 5Mbps. Ahora se presenta cual es el proceso con MGEN.
En el equipo "Receiver" se coloca el PC a “escuchar” tráfico en un puerto definido por el usuario por ejemplo el puerto 5001 (El uso de los puertos debe corresponderse con el estándar RFC 1700 y no se pueden utilizar los puertos entre 1 y 1024):
Figura 19. Apertura de Puerto 5001 desde MGEN en PC Receiver.
Fuente: El Autor
En la anterior figura se observa el uso del comando ./mgen event “listen udp 5001” output listen.log & el cual indica que se debe activar el evento de escuchar de tráfico UDP por el puerto asignado y generar la salida en el archivo listen.log. El símbolo & en sistemas UNIX indica que se ejecute el comando en background.
Para comprobar que se ha activado el puerto 5001 se utiliza el comando netstat de la siguiente forma:
Figura 20. Puerto UDP/5001 abierto por MGEN
Fuente: El Autor
A continuación se ejecuta tcpdump y se le indica que todo el tráfico capturado se almacene en el archivo traza.txt, utilizando la siguiente instrucción:
tcpdump -s 0 -eNi eth0 > traza.txt
En el equipo "Sender" ahora se procede a crear un archivo especial el cual se llamará xtraf.txt con el siguiente contenido:
0.0 ON 1 UDP DST 192.168.1.1/5001 PERIODIC [1000 1024] INTERFACE eth0
[<eventTime>] <eventType> <parameters
...> [<options ...>]
El evento ON tiene la
siguiente sintaxis:
<eventTime> ON <flowId><protocol>
DST <addr>/<port> <pattern [params]> [<options ...>]
Este evento es
utilizado para iniciar un nuevo flujo según el tiempo dado en eventTime. El cuarto campo indica el protocolo de
transporte a utilizar, generalmente MGEN
utiliza el protocolo UDP el cual
encapsula los mensajes generados por MGEN
en el paquetes de tipo UDP/IP que se transmiten a la red. A continuación se presenta un ejemplo
0.0 ON 1 UDP DST 127.0.0.1/5000 PERIODIC [1.0 1024]
Esta línea indica que se origine a la interfaz loopback un flujo de tráfico UDP por el puerto 5000 el cual comienza
inmediatamente apenas se ejecute el script. El mensaje en este caso será de tipo Periódico
y se generará mensajes de 1024 bytes
a una taza de 1 por segundo.
Las direcciones de
destino del flujo que se especifican para los eventos ON pueden ser alteradas por el evento MOD. Las direcciones además
pueden ser de tipo IPv4 o IPv6 además de que se pueden configurar
como unicast o multicast. A continuación se
presenta un ejemplo:
#Inicia el
flujo hacia una interfaz loopback por el
Puerto 5000
0.0
ON 1 UDP DST 127.0.0.1/5000 PERIODIC [1.0 1024]
#Modifica
el flujo 1 a un puerto de destino diferente
0.0
MOD 1 DST 127.0.0.1/5001
El tráfico generado por MGEN consiste en una serie de mensajes con secuencias numeradas.
Los mensajes generados pueden variar en tamaño y frecuencia de transmisión
hacia la red. El patrón de generación se especifica mediante los eventos ON
aunque puede alterarse con eventos MOD.
MGEN soporta tres tipos de patrones
que se crean a través de múltiples flujos.
5.2.2.1 Patrón Periódico
Este tipo de patrón genera mensajes de un tamaño fijo
en bytes a una tasa regular medida en
mensajes/segundo. El tamaño del campo puede ser mayor o igual al mínimo del
tamaño de los mensajes de MGEN y
menor o igual al máximo del tamaño de los mensajes UDP que son de 8192 bytes.
La sintaxis es la siguiente: PERIODIC
[<rate> <size>]
A continuación se presenta un ejemplo del uso
de este tipo de patrón:
#Inicia
el envío de mensajes de 1024 byte a una taza de 10 por segundo
0.0 ON 1 UDP DST
127.0.0.1/5000 PERIODIC [10.0 1024]
5.2.2.2 Patrón Poisson
Este patrón genera mensajes de tamaño fijo en bytes utilizando una variación estadística de promedios de los
intervalos de mensajes enviados a una taza medida en mensajes/segundo.
La sintaxis es la siguiente:
POISSON
[<aveRate (msg/sec)> <size (bytes)>]
El ejemplo que se presenta a continuación ilustra este patrón:
#Inicia el envío de mensajes de 1024 bytes a una tasa
promedio de 10.0 por segundo
0.0 ON 1 UDP DST
127.0.0.1/5000 POISSON [10.0 1024]
5.2.2.3 Patrón
Ráfaga (BURST)
Este patrón genera ráfagas de tráfico de otros tipos de patrones en intervalos
promedios. La sintaxis es la siguiente:
BURST [REGULAR|RANDOM
<aveInterval (sec)> <patternType> [<patternParams>]
FIXED|EXPONENTIAL <aveDuration (sec)>]
El primer parámetro se denomina REGULAR
y resulta en ráfagas periódicas uniformemente distribuidas en el tiempo dado
por el valor <aveInterval> , o RANDOM (Aleatorio) con distribución
exponencialmente distribuida La
característica de los mensajes generados durante las ráfagas se obtienen del
parámetro <patternType> y de <patternParams>.
El tipo de parámetro puede ser cualquiera (PERIODIC,
POISSON, o BURST). Cuando la generación de ráfagas ocurre, se
puede configurar la duración a través de 2 valores denominados FIXED y EXPONENTIAL, si se escoge el primero se obtiene el valor dado
en <aveDuration>
y si es el segundo la duración varia aleatoriamente.
Una vez
entendido el método de funcionamiento general de MGEN, ahora se procede a ejecutar el siguiente comando: ./mgen ipv4 input xtraf.txt interface eth0
Su ejecución indica que se utilice el script creado en el archivo xtraf.txt y que genere el tráfico por la interfaz eth0 del sender.
5.3 TESTBED
Para la implantación de la herramienta se realizaron varias actividades que comprendieron la puesta a punto (instalación y configuración) del equipo Sender y del Receiver, esto incluyo la utilización de la distribución GNU/ Linux Knoppix 5.0.1, que es basada en Debian, y es el CD-Live más utilizado en la actualidad. Además se realizaron pruebas utilizando la distribución BackTrack y Ubuntu.
5.3.1 Arquitectura General Del Sistema
El Sistema cuenta con dos entornos físicos: el sender y el receiver, para el primero se dispone de un equipo portátil Dell Inspiron 6000 Pentium Centrino de 1.3 GHz con 512 MB de memoria RAM y 1 DD de 40 GB, el receiver es un Portatil Dell Inspiron 1525 con procesador Pentium Dual Core de 1.6GHz con 2 GB de memoria RAM y Disco Duro de 120 GB. Ambos tienen una tarjeta de red FastEtherent de 100Mbps. Los equipos fueron conectados por medio de un conjunto de Switches , Hubs y un Router Cisco 2514 realizar las respectivas pruebas.
El software que se instaló y configuró en la infraestructura antes mencionada se distribuyó de la siguiente forma:
Tabla 1 : Software utilizado
SENDER |
RECEIVER |
Generador de Trafico MGEN Ver 4.2 |
TCPDUMP Sniffer |
TCPDUMP Sniffer |
Librería libpcap |
ETHEREAL Sniffer |
Compilador GCC 4.1.2 |
IPTRAF |
IPTRAF |
Fuente: El Autor
5.3.1.1
Configuración del Sender
Para configurar el PC sender se realizaron los siguientes pasos:
En la
siguiente figura se muestra el entorno de pruebas del proyecto:
Figura 21. Entorno de pruebas para el Testbed
Fuente: El Autor.
Como se observa en la figura 21 el esquema de direccionamiento privado es de Clase B (172.16.X.Y), por lo que la máscara que se utiliza por default es 255.255.0.0 (16 bits). En el ejemplo se supondrá que el equipo tiene una tarjeta de red interna tipo 10/100 Mbps. En Linux está identificada como eth0.
El comando más importante es el ifconfig (Figura 22) el cual retorna inicialmente la información sólo de la interfaz Loopback (127.0.0.1), identificada como lo, esto indica que está configurada las funciones iníciales TCP/IP dentro de la máquina.
Figura 22. Comando Ifconfig
Fuente: El Autor
A continuación se configura y sube la tarjeta para el equipo Sender de esta forma:
ifconfig interface dirección_IP netmask mascara_subred up.
Luego como se ve en la siguiente
gráfica quedo configurada la interfaz eth2.
Figura 23. Parámetros para la Tarjeta de Red
Fuente: El Autor
A continuación se comprueba con el comando ping que la interfaz de red eth2 está respondiendo:
Figura 24. Ejecución del comando Ping
Fuente: El Autor
Los mismos pasos se realizan para el equipo Receiver.
Ahora se procede a instalar el generador de tráfico MGEN siguiendo los siguientes pasos.
tar –xzvf src-mgen-4.2b6.tgz
Figura 25. Proceso de instalación de MGEN
Fuente: El Autor
Figura 26. Ejecución inicial de MGEN
Fuente: El Autor
5.3.1.2
Configuración del Receiver
Para configurar el PC receiver se realizaron los siguientes pasos:
Figura 27. Comprobación de Dependencias de GCC
Fuente: El Autor.
6.
TESTBW
6.1
DESCRIPCION
La herramienta desarrollada fue denominada TESTBW, el cual funciona mediante la shell de comandos de Linux, y permite la captura y el cálculo de anchos de banda medidos en bps, de un enlace de red. Esta herramienta posee licencia GPL, y está desarrollada en su totalidad en lenguaje C.
Testbw, captura la información de la trama Ethernet, la cual analiza y genera información como el Timestamp (Formato Segundos . microsegundos), la longitud del paquete medido en bytes, y el ancho de banda calculado que resulta del retardo entre el par de paquetes capturados en un intervalo de tiempo.
6.1.1
Log De
Cambios
En el desarrollo de la herramienta se han realizado desde la creación del primer binario (Versión 0.0.1), varios cambios importantes que han permitido cumplir con los requerimientos iníciales del software. A continuación se presentan los principales cambios que ha sufrido la herramienta, presentando su evolución en los diferentes incrementos desarrollados hasta el momento (Versión 0.0.5):
0.0.5:
2008/06/22: Se Genera Makefile inicial y documentación para instalación.
2008/06/20: Se modifica la manera de realizar el cálculo de los retardos en el tiempo.
2008/06/19: Se Agrega en la salida el campo Bandwidth.
2008/06/09: Se cambia la salida de las direcciones de origen y destino a direcciones IP
2008/06/05: Se agrega lectura de interfaces
de red con la opción -l i
0.0.4:
2008/06/02: Se cambia la forma de ejecución del programa agregando -i para lectura
de la interfaz
2008/05/26: Compilación bajo Backtrack Ver 3 y Ubuntu 7
0.0.3:
2008/05/17: Se Modifica formato de salida del Timestamp a HH:MM:SS
2008/05/10: Se agrega cabecera IP_hdr.
Compilación bajo Knoppix 5.0.1
0.0.2:
2008/04/28: Lectura de direcciones MAC desde cabecera Ethernet
2008/04/25: Compilación bajo Knoppix 3.9
0.0.1:
2008/04/18: Implementación de librerías inet.h e if_ether.h
2000/04/10: Compilación inicial bajo Knoppix 3.8
6.1.2
Plataformas
Probadas
La herramienta se probó con el último binario compilado en las siguientes plataformas Linux y Unix, de forma exitosa:
* Knoppix 5.0.1
* Knoppix 3.9
* Knoppix 3.8
* Ubuntu 8
* Backtrack 3
* SuSe Linux 10.1
* FreeBSD
Lo anterior indica que podría funcionar sobre otras plataformas como, CentOS, Red Hat o Fedora.
6.2
INSTALACION
Antes de instalar Testbw se requiere que esté previamente instalado en la máquina receiver la librería PCAP[15]. Además es deseable la siguiente configuración de hardware y software mínima:
Tabla 2. Requerimientos mínimos para la instalación de la
herramienta
Componente |
Especificación
mínima |
Procesador |
Pentium II de 450 MHz |
Memoria RAM |
256 MB |
Disco Duro |
80 GB |
Tarjetas de Red |
10/100 Mbps FastEthernet |
Sistema Operativo |
GNU/Linux (Deseable Debian, Ubuntu, Knoppix) |
Librería |
libpcap Ver 0.9.8 |
Compilador |
GCC Ver 4.1.2 o superior |
Generador de Tráfico |
MGEN Ver 3.0 o Superior |
Fuente: El Autor
Para realizar la instalación de la herramienta es necesario descomprimir y desempaquetar el archivo testbw-0.0.5.tar.gz utilizando el comando tar-xzvf testbw-0.0.5.tar.gz estando previamente ubicado en el directorio de instalación del usuario por ejemplo /home/dbotia/.
Al momento de descomprimir la herramienta, entrar al directorio testbw-0.0.5 y en este se encontrará la estructura mostrada en la siguiente figura 28:
Figura 28. Estructura del Programa Testbw
Fuente: El Autor
A continuación se describe su principal contenido:
El siguiente paso se divide en 3 partes mostradas en la figura 29:
Figura 29. Instalación de Testbw
Fuente: El Autor
A continuación se verifica la existencia del binario testbw dentro del directorio src, el cual se muestra en la figura 30:
Figura 30. Verificación del Binario compilado
Fuente: El Autor
6.3 EJECUCION DE LA HERRAMIENTA
La herramienta una vez instalada, se ejecutará desde
el Shell de comandos del usuario de la siguiente forma:
1. La herramienta tiene como
sintaxis esta forma:
a. ./testbw –i <interfaz>
donde interfaz debe ser un nombre de NIC valido. Ejemplo eth0 o eth1.
b. ./testbw –l i
Este comando permite ver el listado de las interfaces de red detectadas
por la herramienta.
2. Una vez se ejecute la herramienta
aparecerá el siguiente mensaje:
Figura
31: Ejecución
Inicial de Testbw
Fuente: El Autor
3. Para comprobar su correcta
ejecución se procede a realizar un ping (enviando tráfico ICMP), desde el sender. A
continuación se presenta la captura de los paquetes ICMP enviados hacia el equipo receiver utilizando IPTRAF:
Figura
32: Captura con
IPTRAF
Fuente: El Autor
4. A continuación aparece la salida
de una captura realizada por la herramienta:
Figura 33. Captura de tráfico con testbw
Fuente: El Autor
En la Figura
33, se presenta la salida con el Timestamp, la longitud del paquete IP (bytes) y el Bandwidth
(bps) calculado.
Es indispensable que se verifique previamente que el
equipo tenga conexión a la red y que este correctamente configuradas las NICs como se mostro en la sección
5.3.1.1.
7.
ANALISIS DE RESULTADOS
Mediante el Testbed desarrollado, se procedió a generar tráfico desde MGEN (De tipo Periódico y Poisson) primero de un 30%
(Aproximadamente 381 paquetes/seg) y luego de un 60% (Aproximadamente 742
paquetes/seg) del total del canal, el cual tiene un Ancho de Banda de 10 Mbps
(Canal disponible de la red LAN
probada).
Para el primer caso utilizando tráfico
periódico desde MGEN por el puerto
5001; se procedió a ejecutar el siguiente comando desde Ubuntu:
./mgen event "ON 1 UDP DST 172.16.2.2/5001 PERIODIC [381 982]"
./mgen event "ON 1 UDP DST 172.16.2.2/5001 PERIODIC [742 982]"
A continuación se presenta la respectiva
salida:
Figura 34: Generación de Tráfico Periódico al 30% y 60%
del tamaño del canal
Fuente: El Autor
En el primer comando se enviaría un tráfico promedio
de 2.993.136 bits es decir 3 Mbps. En el segundo comando se enviaría un tráfico
de 5.829.152 bits es decir 5.8 Mbps.
Es importante tener en cuenta que la variable
dependiente (Bandwidth), fue generada
en una escala de x106 es decir en el orden de los Mbps, mientras que la variable
independiente (tiempo) se generó en segundos como unidad de medida principal.
A continuación se presentan gráficamente los
resultados generados por la traza del tráfico Periódico del primer comando
durante un tiempo de 10 Segundos, para 1892 paquetes capturados (Ver anexo3):
Figura 35. Bandwidth calculado del 30% del canal usando
distribución Periodic
Fuente: El Autor
La anterior salida indica que durante un
periodo de captura de 10 Segundos, el ancho de banda se mantuvo estable como se
esperaba, es decir, alrededor de los 3 Mbps,
también se puede apreciar la gran cantidad de paquetes que se recibieron entre
cada segundo, lo cual, podría ser más visible en redes multiprotocolo del orden
de Gbps. Se presenta una captura en un lapso de 10
segundos, para presentar de forma más clara los datos.
En la figura 36 se aprecia durante el mismo
tiempo, la captura del bandwidth
usando el 60% de la capacidad del canal (Ver Anexo 4):
Figura 36: Bandwidth calculado del 60% del canal
usando distribución Periodic
Fuente: El autor
En la anterior figura, el rango del ancho de banda
comparado con la Figura 35, es un poco más
separado, el cual esta aproximadamente entre 5.8 Mbps y 6.2 Mbps.
Aunque existen más puntos dispersos, son tráficos mínimos y
no afectan los cálculos globales, mientras que los puntos ubicados cerca a la
abscisa de cero Mbps, representan tráfico normal de control entre los Host.
Otra característica importante es que entre cada segundo se realizo una
mayor captura de paquetes que en el caso de la Figura 35, lo cual indica que en cada segundo se incrementa
sensiblemente el tráfico, ocupando más el canal, por lo que se requeriría un manejo
adecuado del QoS (Calidad de
Servicio) en la red y más cuando se puedan tener cientos o miles de usuarios
concurrentes en ella.
El segundo caso fue utilizando tráfico con
patrón Poisson desde MGEN por el puerto 5001; para lo cual se
procedió a ejecutar el siguiente comando desde Ubuntu:
./mgen event "ON 1 UDP DST 172.16.2.2/5001 POISSON [381 982]"
./mgen event "ON 1 UDP DST 172.16.2.2/5001 POISSON [742 982]"
A continuación se presenta la respectiva
salida:
Figura 37: Generación de Tráfico Poisson al 30% y 60%
del tamaño del canal
Fuente: El Autor
Cuando se realiza la gráfica con la traza de tráfico
capturado del 30% de la ocupación del canal (Ver Anexo 5), se obtiene lo
siguiente:
Figura 38: Bandwidth calculado del 30% del canal usando
distribución Poisson
Fuente: El Autor
La anterior gráfica presenta datos dispersos,
debido a que el planificador de procesos del Sistema operativo está dando mayor
prioridad a otros procesos y el Kernel
puede no haber capturado algunos paquetes durante el filtrado de datos. Otra
posible razón es debido al tiempo de tránsito entre los switches hacia el router
utilizado, o a errores de configuración de los IOS de estos equipos. En este
caso como se observa en la figura la mayor cantidad de datos se encuentra aproximadamente
entre 1 Mbps y los 3Mbps.
En la figura 39 se presenta, la captura del bandwidth usando el 60% de la capacidad
del canal (Ver Anexo 6):
Figura 39. Bandwidth calculado del 60% del canal usando
distribución Poisson
Fuente: El Autor
Al igual que en el caso anterior en esta figura se observa
que la mayor cantidad de tráfico se encuentra entre los 3 Mbps y los 5 Mbps.
Aunque el ancho de banda es disperso, también podría indicar que se ha
presentado mayor consumo de canal en las aplicaciones en tiempo real con
respecto a otras aplicaciones que consumen menos ancho de banda.
En el Siguiente capítulo se analizará estadísticamente
estas mediciones, para confirmar los resultados.
8. ANÁLISIS ESTADÍSTICO
El análisis estadístico permite
recopilar, manejar, interpretar, analizar, agrupar, y presentar datos en
cuadros o gráficas para su interpretación. En este trabajo, para las mediciones
obtenidas de tráfico en la red, se realizaron a través de los métodos de
distribución estadísticos Periódicos y Poisson. Los resultados logrados
muestran que a un mayor nivel de tráfico, se obtiene mayor número de muestras
del ancho de banda utilizado. No obstante, el análisis de error de los datos,
se realizará estimando los errores medios, absolutos, relativos y cuadráticos,
para encontrar un error total de las medidas. Lo anterior permite comprender
los siguientes puntos: Qué porcentaje de tráfico es o no permisible de error?,
Cuál método estadístico proporciona menor y/o mayor error?, Qué tan exacto y
preciso son los datos?, Se está aprovechando o desperdiciando ancho de banda?.
Para resolver estas incógnitas se
utilizarán herramientas computacionales como Microsoft Excel 2007 para los
cálculos de error, y Matlab 7.1.0.256 para representar los gráficos de las funciones
de Gauss empleando la función stem
(gráficos discretos secuenciales), como estrategia para observar la campana de
Gauss en forma de histograma.
A continuación, se realizará el
análisis respectivo a cada uno, siguiendo un procedimiento estricto y riguroso.
8.1 DISTRIBUCIÓN PERIÓDICA
8.1.1 DISTRIBUCIÓN PERIÓDICA PARA EL 30% DE ANCHO DE BANDA DEL ENLACE DE
RED
De acuerdo a los datos adquiridos
del ancho de banda con respecto al tiempo, se realizó un seguimiento en tiempo
real de su comportamiento, entre 0 y 10 s. Se obtuvieron alrededor de 1891
muestras con un tiempo de muestreo promedio de 0,0052493 s o 5,2493 ms.
Siguiendo una serie de pasos para el
análisis estadístico de estos datos, se calculan en primer lugar la media
aritmética o media, la mediana y la moda.
Según Spiegel [36], la media aritmética es un valor
representativo de un conjunto de datos, el cual suele situarse en el centro del
conjunto de datos. Por lo general, la media se conoce habitualmente como el
promedio de tendencia central, cuya expresión matemática está dada por:
(1)
Por otro lado, la mediana es el valor central más próximo a la media, o la media que divide en dos partes la distribución de los datos. Su expresión matemática está dada por:
Como se aprecia en la ecuación (2), L es el límite inferior de los datos, n es el número de muestras, Σf es la suma de datos, fmediana es el valor de la clase de la mediana o la frecuencia de la clase de la mediana y c es el ancho del intervalo de los datos (límite superior – límite inferior). Según Lind, Marchal y Mason [37], la moda es el valor de la observación que aparece con más frecuencia, el cual cumple la siguiente ecuación matemática:
(3)
De acuerdo a la ecuación (3), Δ1 y Δ2 son los excesos de los datos inferior y superior con respecto a la media, respectivamente. Teniendo en cuenta las ecuaciones (1), (2) y (3), por medio del Microsoft Excel 2007 se realizaron los respectivos cálculos. Los resultados que se encontraron son: Media = 3.02743037 Mbps, Mediana = 3.154409 Mbps y Moda = 3.155624 Mbps.
Teniendo en cuenta estos valores calculados, el siguiente punto es calcular los errores generados en la adquisición de datos durante los 10 s de muestreo en tiempo real. Estos errores se explican de acuerdo a las desviaciones de los datos con respecto a la media, y las variaciones mismas.
Según Creuss [38], el error es la diferencia algebraica entre el valor leído o transmitido y el valor real de la variable medida. Esta suma suele tomarse como un error total de las mediciones, como la raíz cuadrada de la suma algebraica de los cuadrados de los errores presentados en la medición. Matemáticamente se expresa como:
(4)
Los errores más comunes que se desarrolla en este tipo de mediciones son variadas, pero se van a considerar tres fundamentales, muy comunes para este tipo de adquisición de información. Según Creuss [38], el error medio o em es la media aritmética de los errores en cada punto de la medida determinados para valores crecientes y decrecientes de la variable medida. Esta clase de error es también llamado error promedio, que suele generarse para este caso por pérdidas de la línea de transmisión (UTP-5), retardos en el envío y recepción de datos, velocidad de procesamiento de los datos, variaciones pequeñas del ancho de banda, entre otras posibles causas. Este error, debido a su complejidad matemática, se calcula con una función especial de estadística de Microsoft Excel 2007 llamada ERROR.TIPICO.XY.
Según Spiegel [36], el error absoluto o desviación media es la variación de los datos con respecto a la media, como un valor absoluto de la resta de ambos valores. Por lo general, se expresa en términos de sumatoria de todas las restas, cuya ecuación característica es:
(5)
Este tipo de error va a representar como el máximo error de las mediciones en el peor de los casos. Por último, el error relativo es el mínimo error de las mediciones obviando algunas consideraciones, que en algunos casos, suele llamarse zona muerta o campo de valores de la variable que no se puede variar o no produce una medición fija, que es muy pequeña pero significante para el cálculo de errores. Según Cooper y Helfrick [39], el error relativo se expresa como una desviación promedio para indicar la precisión de los datos con respecto a la media. Su expresión matemática así:
(6)
A partir de las ecuaciones (5) y (6), y empleando el software mencionado, los resultados de los errores son las siguientes: em = 2,866397361% o 0,028663974 bps, MD = 0,67000066 bps o 0,0067000066 % y D = 0,00035431 bps o 0,03543102%. Con base a estos errores, se calcula el error total de la ecuación (4), cuyo resultado es 0,670613628 bps o 0,00670613628%. Este error total es muy bajo, lo cual satisface las condiciones deseadas con un 30% de tráfico de la red.
Existe una clase de error muy utilizado denominado error cuadrático o desviación estándar, empleado para analizar los posibles errores aleatorios de la medida. Según Cooper – Helfrick [39], la desviación estándar de un número infinito de datos es la raíz cuadrada de la suma de todas las desviaciones cuadradas individuales, divididas entre el número de lecturas. Sin embargo, en la práctica, el número posible de datos es finito, lo cual está dado por:
(7)
Según Spiegel [36], cuando el número de muestras son mayores a 30, se debe considerar un número de muestras (n – 1) para una mejor estimación de los cálculos. La ecuación (7), debido a la anterior aclaración es llamada habitualmente desviación típica. Por lo tanto, al dividir la desviación típica por la raíz cuadrada del número de muestras, se encuentra la desviación estándar con estimación, para grandes cantidades de muestras, cuya ecuación característica es la siguiente:
(8)
Teniendo en cuenta las ecuaciones (7) y (8), los resultados obtenidos con el software mencionado son las siguientes: σn-1 = 607554,4968 bps y σx = 13971,38548 bps. En la tabla 3 se presenta el resumen de los resultados de cálculos estadísticos que se obtuvieron.
Tabla 3. Resultados de cálculos estadísticos para, distribución
periódica del 30% de ancho de banda de enlace de red
Media |
3027430,37 bps |
Mediana |
3154409 bps |
Moda |
3155624 bps |
Error Medio |
0,028663974 bps (2,8663974 %) |
Error Absoluto |
0,670000664 bps (0,00670000664%) |
Error Relativo |
0,00035431 bps (3,5431x10-6 %) |
ERROR TOTAL |
0,670613628 bps (0,00670613628 %) |
Desviación Típica |
607554,4968 bps |
Desviación Estándar |
13971,38548 bps |
Fuente: El Autor
Para poder observar el efecto de la desviación estándar en las mediciones obtenidas, se realiza una grafica de la función de Gauss o distribución normal en forma de un histograma o diagramas de bloques. Según Spiegel [36], la función de distribución normal o gaussiana esta expresado en términos de la desviación estándar y la media, como se muestra a continuación:
(9)
Teniendo en cuenta que los valores de x son del ancho de banda en cada lapso de tiempo, reemplazamos los valores en la ecuación (9). Por medio de Matlab, se obtiene una gráfica de Función Gaussiana vs Ancho de Banda, como se observa a continuación:
Figura 40. Distribución periódica para un 30% de ancho de banda del
enlace de red
Fuente: Autor
En la figura 40, la media está muy cercana al ancho de banda de 3 Mbps que se realizó para las mediciones respectivas. Debido a lo anterior, se puede decir que tiene una buena exactitud y precisión, por lo cual, la media está muy próxima al valor verdadero o real del ancho de banda; esto muestra que el margen de error es muy pequeño.
En la siguiente tabla, se observa el comportamiento de las distribuciones normales de la figura 40.
Tabla 4. Distribuciones Normales para 30% de ancho de banda de enlace de red
Media
- Desviación Estándar |
3013458,984 bps |
Media
+ Desviación Estándar |
3041401,755 bps |
Media
- Doble Desviación Estándar |
2999487,599 bps |
Media
+ Doble Desviación Estándar |
3055373,141 bps |
Media
- Triple Desviación Estándar |
2985516,213 bps |
Media
+ Triple Desviación Estándar |
3069344,526 bps |
Fuente: El Autor
Cuando se muestra la media +/- desviación estándar, se está considerando al 68,27 % del área de la campana de Gauss; entre la media +/- doble de la desviación estándar se considera al 95,45 %; entre la media +/- triple de la desviación estándar se considera el 99,73%. Al observar la tabla, se puede apreciar que el ancho de la campana es muy pequeño, porque los valores están muy próximos a la media, en los casos que se analizaron. Además el error total (0,00670613628 %) es muy pequeño.
8.1.2 DISTRIBUCIÓN PERIÓDICA PARA EL 60% DE ANCHO DE BANDA DEL ENLACE DE RED
Siguiendo los mismos pasos del anterior caso, se analiza los datos con 3701 muestras, tomada en un tiempo de muestreo aproximado de 0,0027027 s o 2,7027 ms. De acuerdo a los cálculos realizados en Microsoft Excel 2007, se determinaron cada uno de los valores que se explicaron anteriormente, que se resume en la siguiente tabla:
Tabla 5. Resultados de cálculos estadísticos para distribución
periódica, del 60% de ancho de banda de enlace de red.
Media |
8478187,494 bps 8,478187494x106 bps 0,008478187494x109 bps |
Mediana |
5872401 bps |
Moda |
5859800 bps |
Error Medio |
0,028804878 bps (2,880487817 %) |
Error Absoluto |
0,706084177 bps (0,00706084177 %) |
Error Relativo |
0,000190782 bps (1,90782x10-6 %) |
ERROR TOTAL |
0,706671509 bps o (0,007066715 %) |
Desviación Típica |
79132798,33 bps |
Desviación Estándar |
1300759,424 bps |
Fuente: El Autor
De acuerdo a la anterior tabla, el error total de las mediciones es mayor que el error total calculado para el 30% del ancho de banda. Sin embargo, un error total de 0,007066715% se considera pequeño. Una de las razones por el cual el error total es muy bajo se debe a que la mediana (5,872401 Mbps) y la moda (5,8598 Mbps) están muy próximas al valor verdadero (6 Mbps).
En la figura 41, se muestra la gráfica obtenida en Matlab.
Figura 41. Distribución Periódica para 60% de ancho de banda del enlace
de red, ( Media = 0,008478187494x109 bps).
Fuente: Autor
En la figura 42, se muestra la gráfica para la media, moda y mediana, en escala x106 bps para ancho de banda.
Figura 42. Distribución Periódica para 60% de ancho de banda de enlace
de red, (en escala x106 bps para ancho de banda)
Fuente: El Autor
Aunque la media está por encima del valor real de 6 Mbps, el ancho de la distribución es muy estrecho, garantizando de esta manera una aceptable exactitud y buena precisión de los datos.
En la tabla 6, se aprecia la distribución normal para 60% de ancho de banda.
Tabla 6. Distribuciones Normales para 60% del ancho de banda del
enlace de red
Media
- Desviación Estándar |
7177428,07 bps |
Media
+ Desviación Estándar |
9778946,919 bps |
Media
- Doble Desviación Estándar |
5876668,646 bps
(≈5,88Mbps) |
Media
+ Doble Desviación Estándar |
11079706,34 bps |
Media
- Triple Desviación Estándar |
4575909,221 bps |
Media
+ Triple Desviación Estándar |
12380465,77 bps |
Fuente: El Autor
La mejor aproximación es la región comprendida entre la media – doble de la desviación estándar porque su valor está muy próximo al valor real del ancho de banda de 6 Mbps.
8.2 DISTRIBUCIÓN DE POISSON
8.2.1 Distribución de Poisson Para 30% de Ancho de Banda de Enlace de
Red
Siguiendo el mismo procedimiento explicado anteriormente, se obtuvo 1864 muestras; el tiempo de muestreo que se desarrollo para obtener está cantidad de muestras es aproximadamente 0,0053673 s o 5,3673 ms.
En la tabla 7, se muestra los cálculos estadísticos obtenidos a través de Microsoft Excel 2007.
Tabla 7. Resultados de cálculos estadísticos para distribución de
Poisson, para 30% de ancho de banda del enlace de red.
Media |
6976918,399 bps 6,976918399x106 bps 0,006976918399x109 bps |
Mediana |
5126408 bps |
Moda |
10252816 bps |
Error Medio |
0,028778007 bps (2,877800667%) |
Error Absoluto |
0,263975117 bps (0,00263975117 %) |
Error Relativo |
0,000141618 bps (1,41618x10-6 %) |
ERROR TOTAL |
0,26553918 bps (0,002655392 %) |
Desviación Típica |
63219272,31 bps |
Desviación Estándar |
1464288,119 bps |
Fuente: Autor
El error total de las mediciones para una distribución de Poisson para el 30% de ancho de banda, es más pequeño que los obtenidos para la distribución periódica para 30% y 60% de ancho de banda.
En la figura 43, se muestra la gráfica obtenida en Matlab, para una distribución de Poisson, para 30% de ancho de banda.
Figura 43. Distribución de Poisson para 30% de ancho de banda de
enlace de red (Media = 0,006976918399x109 bps).
Fuente: El Autor
En la figura 44, se muestra la gráfica para la media, la moda y mediana en escala x106 bps para ancho de banda.
Figura 44. Distribución de Poisson para 30% de ancho de banda de
enlace de red, ( en escala x106 bps para ancho de banda)
Fuente: El Autor
Al analizar el comportamiento de la campana de Gauss, se puede apreciar que esta sesgada a la izquierda (el sesgo es el grado de asimetría de una distribución o cuánto se aparta de la simetría). Para comprobar la anterior afirmación, según Spiegel [36], el sesgo se define matemáticamente como la resta entre la media y la moda, dividido por la desviación típica.
(10)
Reemplazando los valores de la tabla, el sesgo calculado es -0,0518 que es un sesgo negativo muy pequeño, lo cual indica que esta algo corrida la media hacia la izquierda con respecto a la moda. Por esta razón, existen algunos valores dispersos en la función de distribución de Poisson durante la adquisición de datos del ancho de banda.
En la tabla 8, se muestra la distribución de Poisson para un 30% de ancho de banda.
Tabla 8. Distribución de Poisson, para 30% de ancho de banda del
enlace de red.
Media
- Desviación Estándar |
5512630,28 bps |
Media
+ Desviación Estándar |
8441206,518 bps |
Media
- Doble Desviación Estándar |
4048342,162 bps |
Media
+ Doble Desviación Estándar |
9905494,637 bps |
Media
- Triple Desviación Estándar |
2584054,043 bps (≈2,584
Mbps) |
Media
+ Triple Desviación Estándar |
11369782,76 bps |
Fuente: El Autor
La mejor aproximación es la región comprendida entre la media – triple de la desviación estándar, porque su valor es próximo al valor real de ancho de banda de 3 Mbps.
8.2.2 Distribución de Poisson Para el 60% de Ancho de Banda de Enlace de
Red
Para este último caso, se obtuvieron cerca de 3800 muestras con tiempo de muestreo del ancho de banda aproximado de 0,00263219 s o 2,63219 ms. En la tabla 9, se muestran los cálculos estadísticos obtenidos con Microsoft Excel 2007.
Tabla 9. Resultados de cálculos estadísticos para distribución de
Poisson, para 60% de ancho de banda del enlace de red
Media |
8497384,581
bps 8,447384581x106
bps 0,008497384581x109
bps |
Mediana |
9112347 bps |
Moda |
10252816 bps |
Error Medio |
0,02880327 bps (2,880327%) |
Error Absoluto |
0,800044119 bps
(0,00800044119%) |
Error Relativo |
0,000210538 bps o (2,10538x10-6
%) |
ERROR TOTAL |
0,800562468 bps (0,0080562468 %) |
Desviación Típica |
44296999,66 bps |
Desviación Estándar |
718592,2237 bps |
Fuente: El Autor
El valor de error total (0,0080562468 %), es relativamente más alto comparado con los resultados obtenidos para los tres casos anteriores. Sin embargo, el error total sigue considerándose pequeño y aceptable.
En la figura 45, se muestra la gráfica obtenida en Matlab, para una distribución de Poisson, para 60% de ancho de banda.
Figura 45. Distribución de Poisson para 60% de ancho de banda del
enlace de red (Media = 0,008497384581x109 bps).
Fuente: El Autor
En la figura 46, se muestra la gráfica para la media, moda y mediana, en escala x106 bps para ancho de banda.
Figura 46. Distribución de Poisson para 60% de ancho de banda del
enlace de red, ( en escala x106 bps para ancho de banda)
Fuente: El Autor
Aplicando la ecuación (10), el sesgo calculado es -0,396 que es un sesgo negativo pequeño, lo cual, indica que la media esta corrida a la izquierda con respecto a la moda y que existen algunos valores dispersos.
En la tabla 10, se muestra la distribución de Poisson para un 60% de ancho de banda.
Tabla 10. Distribución de Poisson, para 60% de ancho de banda del
enlace de red
Media
- Desviación Estándar |
7778792,357 bps |
Media
+ Desviación Estándar |
9215976,804 bps |
Media
- Doble Desviación Estándar |
7060200,133 bps |
Media
+ Doble Desviación Estándar |
9934569,028 bps |
Media
- Triple Desviación Estándar |
6341607,91 bps (≈6,34
Mbps) |
Media
+ Triple Desviación Estándar |
10653161,25 bps |
Fuente: Autor
Como en el caso de la distribución de Poisson, para 30% de ancho de banda de enlace, la mejor aproximación es la región comprendida entre la media – triple de la desviación estándar, porque su valor es próximo al real de ancho de banda de 6 Mbps.
Gracias al
uso del software libre, se generan aplicaciones realmente interesantes además
de que permite la reutilización de código para adaptar los aplicativos a las
necesidades del programador y esto se comprobó en el desarrollo del proyecto.
La librerías
PCAP son fundamentales para el
desarrollo de software para redes en ambientes multiplataforma que lo hacen
necesario para el éxito de este tipo de proyectos.
Se puso en práctica todos los
conocimientos y teorías dadas en la maestría, lo cual hizo que los objetivos
propuestos en el proyecto se alcanzaran con éxito.
La medición de Anchos de Banda en un
enlace de red en tiempo real, permite optimizar los canales de transmisión, así
como permiten determinar cuáles Host pueden generar mayor saturación de tráfico
en una red.
El ancho de banda calculado mediante
la distribución de Poisson, genera
valores dispersos, los cuales se deben a diferentes causas entre las que se
destacan, la planificación de procesos en el kernel, tiempos de retardo pequeños entre los nodos de transito,
configuración del IOS del router o switches utilizados, entre otros.
El uso del lenguaje C permite el
desarrollo de aplicaciones flexibles, las cuales pueden aprovechar las
características del Kernel de Linux.
Se comprobó cómo se puede procesar
de una mejor forma las Tramas Ethernet,
analizando y entendiendo su cabecera, para deducir la información que se
deseaba generar.
El análisis de los datos de salida
calculados, indican que a menor retardo entre
paquetes, mayor ancho de banda se consume.
Las gráficas indican la importancia de la configuración de
prioridades de tráfico, sobre todo en servicios no orientados a la conexión
(Ejem: UDP, RTP, SIP, etc), en donde
la transmisión de Voz y Video son muy sensibles tanto a los retardos como a los
Jitters que se puedan encontrar en la
Red.
Los errores de medición se deben a pérdidas de las líneas de transmisión, latencia, velocidad de procesamiento de datos, y variaciones pequeñas de ancho de banda, entre otras, que contribuyen a la dispersión de datos.
Según el análisis estadístico, los errores totales de las mediciones son relativamente pequeños para la distribución periódica y de Poisson, para 30% y 60% de ancho de banda del enlace de red, lo cual, índica la exactitud y precisión de las mediciones con respecto al valor real de 3 Mbps y 6 Mbps.
Para la distribución de Poisson, para 30% y 60% de ancho de banda de enlace de red, los sesgos calculados son negativos, pero pequeños, lo cual, muestra que existen valores dispersos, aunque muchos valores están muy cerca al valor real.
Un parámetro que caracteriza la
dispersión de los datos es la incertidumbre que generan los errores, debido a
las imperfecciones naturales de la medida, el principio, método y procedimiento
de las mediciones del ancho de banda, y a la baja repetibilidad de la lectura
de los valores
El uso de Generadores de Tráfico
especializados, facilita el análisis de la información, por parte de la
herramienta desarrollada.
El campo de estimación de Anchos de
Banda es muy amplio y pueden generarse muchos proyectos de investigación
interesantes, relacionados con la optimización del enlace y el ancho de banda
realmente requerido.
Profundizar en el estudio de las mediciones de anchos de banda especialmente aplicando teoría de colas.
Actualización continúa de los avances en el desarrollo de nuevos protocolos de red.
Tener conocimientos del sistema operativo Linux y en el uso del API Libpcap
Realizar mediciones de Anchos de Banda por medio de redes VPN y / o redes WAN.
Mejorar la función de captura de los timestamps de los paquetes enviados para el tráfico con patrón Poisson.
Aplicar modificaciones a la herramienta para la medición de anchos de banda sobre redes WLAN (Utilizando estándar IEEE 803.11).
Generar soporte hacia el Protocolo IPv6.
Generar compatibilidad de la herramienta con Sistemas Operativos Windows por medio de la librería WinPap.
Adaptar la herramienta a un entorno gráfico utilizando el lenguaje de programación JAVA por medio del API JPCAP.
Generar mediciones a dispositivos activos como Access Points y Routers
11. BIBLIOGRAFÍA
11.1 LIBROS
[1] KUROSE, James F. ROSS, Keith. Redes de Computadores. Un Enfoque descendente basado en Internet. Segunda Edición. Ed Pearson. 2004. Madrid - España. 739p.
[2] ORDINAS, José Maria. Otros. Redes de Computadores. Ed. UOC. Master Software Libre. Barcelona – España. 2004. 351p.
[3] STALLING, William. Comunicaciones y redes de computadores, sexta edición. Editorial Prentice Hall, Madrid - España, 2001.
[4] ___________,_______. Redes e Internet de alta Velocidad: Rendimiento y Calidad de Servicios. Segunda Edición. Ed Pearson Educación. Madrid - España. 2004. 729p.
[5] TANENBAUM, Andrew S. Redes de Computadoras, Cuarta edición. Editorial Pearson, México, 2003. 891p
[6] ALFARO, Joaquin. PERRAMAN TORNIL,
Xavier. Aspectos avanzados de seguridad en Redes. Ed. UOC. Master Software Libre. Barcelona –
España. 2004. 410p.
[7] R. Braden. Rfc 1122: Requirements for internet
hosts - communication layers info. Technical report, Internet Engineering Task
Force, October 1989.
[8] C. S. McCane and V. Jacobson. The bsd packet filter: A new
architecture for user-level packet capture. In Proceedings of the Winter
USENIX Conference, volume 93, pages 259–269, San Diego, California, 1993
[9] J. Postel. Rfc 768: User datagram protocol.
Technical report, August 28 1980.
[10]
_______. Rfc
791: Internet protocol. Technical report, September 1981.
[11] _______. Rfc 793: Transmission control
protocol. Information Sciences Institute, University of Southern California,
page 91, 1981.
11.2
REVISTAS
[12] GONT, Fernando. Sniffeando redes con tcpdump. Revista @rroba. Nro 104. Año IX. Pag 44-50. ISSN: 1138-1655. España. Mayo de 2006.
[13] GONT, Fernando. Sniffeando redes con tcpdump II. Revista @rroba. Nro 108. Año IX. Pag 14-19. ISSN: 1138-1655. España. Septiembre de 2006.
[14] MENENDEZ, Juan Manuel.
Estudio Práctico del TCP. Revista Solo Programadores. Nro 54. Año VI. Pag 68-77. ISSN: 1134-4892. España. Mayo
de 1999.
[15] PALAZZOLI, Pierpaolo. Utilizando Snort-inline. Revista Haking9. Nro 19. Pag 30-43. ISSN: 1731-2930. Varsovia, Polonia. Diciembre 2006.
[16] SKWAREK, Lujasz. Descifrando los paquetes de Jabber – librería PCAP. Revista Haking9. Nro 19. Pag 44-49. ISSN: 1731-2930. Varsovia, Polonia. Diciembre 2006.
[17] WEGENER, Christoph. DOLLE, Wilhelm. Entendiendo y Evitando los Ataques TCP. TCP Hijacking. Revista Linux Magazine. Nro 11. Pag 71-76. ISSN: 1576-4079. España. 2004.
11.3 INVESTIGACIONES
[18] Information Systems
Laboratory. [on-line] http://www.csee.usf.edu/islab/ . Department of Computer Science and
Engineering. University of South
Florida. 2007
11.4 INFOGRAFIA
[21] CERT ADVISORY CA-2001-09. Statistical Weaknesses in TCP/IP Initial Sequence Numbers. [on-line] http://www.cert.org/advisories/CA-2001-09.html. Septiembre de 2001.
[22] GUERRERO, Cesar.
Herramientas para Generación de Trafico TCP y UDP. [on-line].
http://www.csee.usf.edu/~guerrerc/links/traf_gen.htm. University of South
Florida. 2007
[23] IPTRAF. descripción
de la herramienta IPTraf. [on-line]
http://es.wikIPedia.org/wiki/IPTraf.
Febrero 2007
[24] JACOBSON,
Van. LERES, Craig. McCANNE, Steven. pcap - Packet Capture library. [on-line]
http://www.tcpdump.org/pcap3_man.html Lawrence Berkeley National Laboratory,
University of California, Berkeley, CA. 27 February 2004
[25] JONCHERAY,
Laurent. Simple Active Attack Against TCP. [on-line].
http://www.usenix.org/publications/library/proceedings/security95/full_papers/joncheray.ps.
[26] LOPEZ MONGE, Alejandro. Aprendiendo a programar con Libpcap. [On-line]. http://www.e-ghost.deusto.es/docs/2005/conferencias/pcap.pdf. 20 de Febrero de 2005
[27] NMAP. Descripción de la herramienta NMAP. [on-line]. http://es.wikIPedia.org/wiki/Nmap. 28 de Octubre 2007
[28] NRL. Naval Research Laboratory. Multi Generator MGEN. [on-line]
http://cs.itd.nrl.navy.mil/work/mgen/index.php. 2007
[29] M. Gerla, M. Y. Sanadidi, R. Wang, A. Zanella, C. Casetti, S.
Mascolo, "TCP
Westwood: Congestion Window Control Using Bandwidth Estimation",
[on-line]. http://www.cs.ucla.edu/NRL/hpi/tcpw/tcpw_papers/TCPWGlobecomBasicPaperFinalDraft.pdf.
In Proceedings of IEEE Globecom 2001, Volume: 3, pp 1698-1702, San Antonio,
Texas, USA, November 25-29, 2001
[32] RFC 793.
Transmission Control Protocol. [on-line] http://rfc.net/rfc793.html.
[33]. TCPDUMP: the Protocol
Packet Capture and Dumper Program.. [on-line]. http://es.wikIPedia.org/wiki/Tcpdump.
4 Septiembre 2007.
[34] WARREN, Paul. Herramienta
IFTOP. [on-line]
http://ex-parrot.com/~pdw/iftop/. Febrero de 2006.
[29] WIRESHARK.
Description Wireshark network tool. [on-line] http://en.wikIPedia.org/wiki/Wireshark. 21 de Septiembre de 2007).
[35] ZALEWSKI, Michal. Herramienta p0f. [on-line]. http://www.stearns.org/p0f/README. 2004
11.5 BIBLIOGRAFÍA PARA ANÁLISIS
ESTADÍSTICO
[36] SPIEGEL, Murray R. Estadística, Editorial McGraw-Hill. 2°Edición, España, 1991, p. 60-64 y 91-93.
[37] LIND, Douglas A; MARCHAL, William G; MASON, Robert D. Estadística para Administración y Economía, Editorial Alfaomega, 11°Edición, Colombia, 2004, p. 74.
[38] CREUS, Antonio. Instrumentación Industrial, Editorial Alfaomega, 6°Edición, Colombia, 1998, p 4-5.
[39] COOPER, William D; HELFRICK, Albert D. Instrumentación Electrónica Moderna y Técnicas de Medición, Editorial Prentice Hall, Primera Edición, México, 1996, p. 11-12.
ANEXOS
ANEXO 1.
CÓDIGO FUENTE DE LA HERRAMIENTA TESTBW
/*
Este archivo es parte de Testbw.
Copyright (C) 2008 DIEGO BOTIA
Este
programa es software libre; puede redistribuirse y/o ser modificado
bajo
los términos de la Licencia Pública General de GNU tal como es
publicada por la Free Software Foundation; ya
sea por la versión 3 de la Licencia,
o(a su elección) cualquier versión posterior.
Este
programa se distribuye; aún sin la garantía implícita de
COMERCIABILIDAD
o IDONEIDAD PARA UN FIN DETERMINADO. Vea
la
Licencia
Pública General de GNU para más detalles.
Debió
haber recibido una copia de la Licencia Pública General de GNU
junto
con este programa; si no es así, escriba a la Free Software Foundation,
Inc., 51 Franklin Street, Quinto
Piso, Boston, MA 02110-1301, USA.
http://www.gnu.org/licenses/
*/
/*===============================================
file = testbw.c ===========
Estimador
de Anchos de Banda. Este programa permite estimar a traves de la
captura
de las cabeceras ethernet el ancho de banda en bps de un enlace.
=============================================================================
Creacion : 10-Abr-2008
Ultima
Modificacion : 22-Jun-2008
Version : 0.0.5
Licencia : Gplv3
-----------------------------------------------------------------------------
Modo de
ejecucion:
Para
capturar paquetes en una interfaz de red:
./testbw -i <Interfaz de Red>
Para
detectar las interfaces de red existentes en el equipo:
./testbw -l I
-----------------------------------------------------------------------------
Salida:
El
programa genera 5 columnas con la siguiente informacion:
<tiempo>
<longitud del paquete IP> <bandwidth> <IP origen> <IP
destino>
-----------------------------------------------------------------------------
Autor: : Diego Jose Luis Botia Valderrama
Maestria En Software Libre
Universidad Autonoma De Bucaramanga
(Colombia)
Universidad Oberta De Catalunya
(España)
Asesor
Y Director : Ph.D.(c) Cesar Dario Guerrero Santander
-----------------------------------------------------------------------------
Nota:
Este programa es software libre. para mejoras, correcciones de bugs, o
recomendaciones favor enviar un email a
su autor: diego.botia@gmail.com
===========================================================================*/
//-----
Seccion Include y Define --------------------------------------------
//DEFINICION
DE LIBRERIAS
#include <stdlib.h> // exit
#include <unistd.h> // exit
#include
<pcap.h> // Libreria
para la captura de paquetes
#include <arpa/inet.h> // Sirve para inet_ntoa NETWORK TO
ADDRESS
// Funciones de conversion de direcciones
#include
<stdio.h> // Entrada
salida Estandar de C
#include
<time.h> // Funciones
de Tiempo
#include
<errno.h> // Para
manejo de errores
#include
<netinet/in.h> //
Estructuras de las direcciones de red
#include <sys/socket.h> // Funciones de sockets para networking
#include
<netinet/if_ether.h> // ETHER_ADDR_LEN
#define
ETHERTYPE_IP 0x0800 // Define si el tipo de paquete ETHERNET es
IP con 0x0800.
// Revisar el
archivo/usr/includes/net/ethernet.h
//-----
Prototipos de functiones ---------------------------------------------
int
mostrar_interfaces_disponibles(void);
void pcap_handler2(u_char *args,
const struct pcap_pkthdr *header,
const u_char *packet);
double timeval_diff(const struct
timeval *t_now, const struct timeval *t_prev);
//-----
Variables globales ---------------------------------------------------
int*
first_pck; // para indicar si se capturo el primer paquete
pcap_t*
handler; // enlaza el objeto pcap
// Estructura de la cabecera Ethernet
struct eth_hdr {
u_char ether_dhost[ETHER_ADDR_LEN]; // Direccion
de destino
u_char ether_shost[ETHER_ADDR_LEN]; //
Direccion de origen
u_short ether_type; // Tipo de paquete
};
//Estructura
de la cabecera IP --->>>> RFC791
struct
ip_hdr{
#if __BYTE_ORDER==__LITTLE_ENDIAN // Estandar POSIX manejo por arquitecturas
unsigned int ip_hl:4; //Longitud de la cabecera
unsigned
int ip_v:4; //Version
#endif
#if __BYTE_ORDER==__BIG_ENDIAN
unsigned int ip_v:4; //Version
unsigned int ip_hl:4; //Longitud de la cabecera
#endif
u_int8_t ip_tos; //Tipo de Servicio
u_short ip_len; //Longitud Total
u_short ip_id; //Identificacion
u_short ip_off; //Fragment Offset
Field
#define IP_RF 0x8000 //Bandera para Fragmento reservado
#define IP_DF 0x4000 //Bandera No Fragmente
#define IP_MF 0x2000 //Bandera de Mas
fragmentos
#define IP_OFFMASK 0x1fff //Mascara para
fragmentacion de Bits
u_int8_t ip_ttl; //Tiempo de Vida
u_int8_t ip_p; //Protocolo
u_short ip_sum; //Checksum
struct in_addr ip_src,ip_dst; //Direccion de origen y destino
};
/*=============================================================
Programa principal
=============================================================*/
int main(int argc,char **argv)
{
const u_char *packet;
char *DEVICE; //Para la captura de la
interfaz de red
struct pcap_pkthdr hdr; //Llamado a la
estructura header de pcap
struct pcap *handle; // enlaza el objeto pcap
char errbuf[PCAP_ERRBUF_SIZE]; // pcap coloca
los mensajes de error aca por medio de un arreglo
bpf_u_int32 mask, net; //Mascara de red y
direccion IP de la interfaz
if(argc <= 2){
fprintf(stderr,
"Sintaxis:\n\t%s -i <interfaz de
red>\n\t%s -l i <Solo -l i lista de interfaces>\n",
argv[0],argv[0]);
return -1;
}
switch(argv[1][1]){
case 'i': if(argc>=3) {
DEVICE=argv[2]; // Interfaz de red
entrada por el usuario
printf("dispositivo seleccionado:
%s\n", DEVICE);
/*pcap_lookupnet determina los parametros
de la tarjeta de red:
Argumentos: primero es la interfaz de
red, el segundo es la
direccion IP,
el tercero la mascara de red y el último es el
índice del
búfer del eventual error. */
if (pcap_lookupnet(DEVICE, &net,
&mask, errbuf) == -1){
fprintf(stderr,
"Error de lectura de datos del
dispositivo %s: %s\n",
DEVICE,errbuf);
return 1;
}
/* Con pcap_open_live se inicia la
captura y rastreo de paquetes.
Argumentos:
1.
Dispositivo de red.
2. Tamaño
máximo del paquete capturado, expresado en bytes.
3. Es igual a
1 para que la NIC funcione en modo promiscuo
Es igual a 0 para que la NIC funcione en
modo estándar.
4. Tiempo de
espera de los paquetes en milisegundos.
5. Puntero al
búfer del eventual error en caso de cualquier falla*/
if ((handler = pcap_open_live(DEVICE, 8096, 1,
1000, errbuf)) == NULL) {
perror("Error:
No se puede abrir el dispositivo\n");
_exit(0);
}
//Mensaje de salida antes de iniciar captura
printf("\n** Activo para recibir paquetes,
ctrl-c para exit **\n");
//Llamado a pcap_loop pasando por
parametro la funcion callback.
first_pck = malloc(sizeof(int));
*first_pck=1;
while (1) {
pcap_loop(handler, -1, pcap_handler2, NULL);
// callback pcap_handler2 on new packet
usleep(1);
}
}
break; //Termina primer case
case 'l':
if(argc>=3) return mostrar_interfaces_disponibles();
break;
default:
//Si no es ningun case entonces opcion invalida
fprintf(stderr,"Error: opción -%c no
válida.\n",argv[1][1]);
return 1;
break;
} //Fin del Switch
return 0;
} //Fin
del Main
/*===========================================================================
Definicion
de funciones
===========================================================================*/
//---------------------------------------------------------------------------
// Funcion callback
//---------------------------------------------------------------------------
void pcap_handler2(u_char *args,
const struct pcap_pkthdr *header,
const u_char *packet)
{
u_char *ptr; // Imprime informacion de
cabecera para las direcciones del HW
struct pcap_pkthdr hdr; // Llamado a
estructura pcap_pkthdr
const struct ip_hdr *ip; // Puntero a mi
estructura IP
const struct eth_hdr *ethernet; // Almacena los
headers de Ethernet
struct timeval tstamp, inistamp; //
Timestamp Actual para calculo de intervalos de tiempo
double Bps;
// Almacena el resultado del calculo de los Anchos de Banda
double sec_acum, sec_diff; // Tiempos en
segundos
double period=0.050; // Periodicidad de la
estimacion
// Definir posicion de los datos
packet=pcap_next(handler,&hdr);
if(packet==NULL){
printf("No puede tomar el
paquete\n");
exit(1);
}
//Determina el header del paquete capturado
ethernet = (struct eth_hdr *)(packet);
if (*first_pck==1) {
*first_pck=0;
sec_acum=0;
tstamp=header->ts;
inistamp=header->ts;
}
sec_diff=timeval_diff(&header->ts, &tstamp);
sec_acum+=sec_diff;
printf("%11.6f\t",sec_acum); //Se
imprime la estructura del tiempo...
printf("%8d\t",hdr.len); // Imprime
numero de bits observados cada period
Bps=(hdr.len*8)/(sec_diff); // Calculo del
BandWidth
printf("%10.0f\n",Bps); //Bandwidth
por cada paquete en bps
tstamp=header->ts; //Asigna el contenido
de la estructura a tstamp....para un nuevo paquete
} //Fin
de funcion callback
//---------------------------------------------------------------------------
//
Muestra las interfaces de red disponibles
//---------------------------------------------------------------------------
int
mostrar_interfaces_disponibles(void){
int i; // contador
int n_interfaces=0; // Me cuenta el numero de
interfaces detectadas
pcap_if_t *nics; // Permite extraer informacion de las
interfaces
pcap_if_t *d; // Para la lista enlazada.....
char errbuf[PCAP_ERRBUF_SIZE]; // Buffer de
almacenamiento de error
if(pcap_findalldevs(&nics,errbuf)==-1){
printf("Error en la captura de las
NICs %s\n",errbuf);
exit(-1);
}
printf("Las NICs encontradas
son:\n\n");
for(i=0,d=nics;d;d=d->next,i++)
//d->next permite que vaya a la siguiente definicion de la interfaz
{
printf("\t- [%s]", d->name);
//Me imprime el nombre de la interfaz
if (d->description) //Si hay datos
Imprime la descripcion de la interfaz si existe
printf(" (%s)\n", d->description);
else
printf(" (No hay descripción
disponible)\n");
}
if(i==0) //En caso de no encontrar
dispositivos
{
printf("\nNo se encontraron dispositivos
válidos. Asegurese que este instalado Libpcap\n");
return;
}
return n_interfaces;
}
//---------------------------------------------------------------------------
//
Calcula la diferencia en segundos estre dos valotes timeval
//---------------------------------------------------------------------------
double timeval_diff(const struct
timeval *t_now, const struct timeval *t_prev)
{
double
usecs_now;
if
(t_prev->tv_sec == 0 && t_prev->tv_usec == 0) return 0;
usecs_now = (t_now->tv_sec - t_prev->tv_sec) * 1000000;
usecs_now += (t_now->tv_usec - t_prev->tv_usec);
return (double)usecs_now/(double)1000000.0;
}
ANEXO 2.
LICENCIA GPL
GNU GENERAL PUBLIC LICENSE
Version 3, 29 June
2007
Copyright (C) 2007 Free Software Foundation,
Inc. http://fsf.org/ Everyone is permitted to copy and distribute
verbatim copies of this license
document, but changing it is not allowed.
Preamble
The GNU General Public License is a free,
copyleft license for software and other kinds of works.
The licenses for most software and other
practical works are designed to take away your freedom to share and change the
works. By contrast, the GNU General
Public License is intended to guarantee your freedom to share and change all
versions of a program--to make sure it remains free software for all its
users. We, the Free Software Foundation,
use the GNU General Public License for most of our software; it applies also to any other work released this way by its
authors. You can apply it to your
programs, too.
When we speak of free software, we are
referring to freedom, not price. Our
General Public Licenses are designed to make sure that you have the freedom to
distribute copies of free software (and charge for them if you wish), that you
receive source code or can get it if you
want it, that you can change the software or use pieces of it in new free
programs, and that you know you can do these things.
To protect your rights, we need to prevent
others from denying you these rights or asking you to surrender the
rights. Therefore, you have certain
responsibilities if you distribute copies of the software, or if you modify it:
responsibilities to respect the freedom of others.
For example, if you distribute copies of such
a program, whether gratis or for a fee, you must pass on to the recipients the
same freedoms that you received. You
must make sure that they, too, receive or can get the source code. And you must show them these terms so they know
their rights.
Developers that use the GNU GPL protect your
rights with two steps:
(1)
assert copyright on the software, and (2) offer you this License giving you
legal permission to copy, distribute and/or modify it.
For the developers' and authors' protection,
the GPL clearly explains that there is no warranty for this free software. For both users' and authors' sake, the GPL
requires that modified versions be marked as changed, so that their problems
will not be attributed erroneously to authors of previous versions.
Some devices are designed to deny users
access to install or run modified versions of the software inside them,
although the manufacturer can do so.
This is fundamentally incompatible with the aim of protecting users'
freedom to change the software. The
systematic pattern of such abuse occurs in the area of products for individuals
to use, which is precisely where it is most unacceptable. Therefore, we have designed this version of
the GPL to prohibit the practice for those products. If such problems arise substantially in other
domains, we stand ready to extend this provision to those domains in future
versions of the GPL, as needed to protect the freedom of users.
Finally, every program is threatened
constantly by software patents. States should not allow patents to restrict
development and use of software on general-purpose computers, but in those that
do, we wish to avoid the special danger that patents applied to a free program
could make it effectively proprietary.
To prevent this, the GPL assures that patents cannot be used to render
the program non-free.
The precise terms and conditions for copying,
distribution and modification follow.
TERMS AND CONDITIONS
0. Definitions.
"This License" refers to version 3
of the GNU General Public License.
"Copyright" also means
copyright-like laws that apply to other kinds of works, such as semiconductor
masks.
"The Program" refers to any
copyrightable work licensed under this License.
Each licensee is addressed as "you". "Licensees" and "recipients"
may be individuals or organizations.
To "modify" a work means to copy
from or adapt all or part of the work in a fashion requiring copyright
permission, other than the making of an exact copy. The resulting work is called a "modified
version" of the earlier work or a work "based on" the earlier
work.
A "covered work" means either the
unmodified Program or a work based on the Program.
To "propagate" a work means to do
anything with it that, without permission, would make you directly or
secondarily liable for infringement under applicable copyright law, except
executing it on a computer or modifying a private copy. Propagation includes copying, distribution
(with or without modification), making available to the public, and in some
countries other activities as well.
To "convey" a work means any kind
of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer
network, with no transfer of a copy, is not conveying.
An interactive user interface displays
"Appropriate Legal Notices" to the extent that it includes a
convenient and prominently visible feature that (1) displays an appropriate
copyright notice, and (2) tells the user that there is no warranty for the work
(except to the extent that warranties are provided), that licensees may convey
the work under this License, and how to view a copy of this License. If the interface presents a list of user
commands or options, such as a menu, a prominent item in the list meets this
criterion.
1. Source Code.
The "source code" for a work means
the preferred form of the work for making modifications to it. "Object code" means any non-source form
of a work.
A "Standard Interface" means an
interface that either is an official standard defined by a recognized standards
body, or, in the case of interfaces specified for a particular programming
language, one that is widely used among developers working in that language.
The "System Libraries" of an
executable work include anything, other than the work as a whole, that (a) is
included in the normal form of packaging a Major Component, but which is not
part of that Major Component, and (b) serves only to enable use of the work
with that Major Component, or to implement a Standard Interface for which an
implementation
is available to the public in source code form.
A "Major Component", in this context, means a major essential
component (kernel, window system, and so on) of the specific operating system (if
any) on which the executable work runs, or a compiler used to produce the work,
or an object code interpreter used to run it.
The "Corresponding Source" for a
work in object code form means all the source code needed to generate, install,
and (for an executable work) run the object code and to modify the work,
including scripts to control those activities.
However, it does not include the work's System Libraries, or
general-purpose tools or generally available free
programs
which are used unmodified in performing those activities but which are not part
of the work. For example, Corresponding
Source includes interface definition files associated with source files for the
work, and the source code for shared libraries and dynamically linked
subprograms that the work is specifically designed to require, such as by
intimate data communication or control flow between those subprograms and other
parts of the work.
The Corresponding Source need not include
anything that users can regenerate automatically from other parts of the
Corresponding Source.
The Corresponding Source for a work in source
code form is that same work.
2. Basic Permissions.
All rights granted under this License are
granted for the term of copyright on the Program, and are irrevocable provided
the stated conditions are met. This
License explicitly affirms your unlimited permission to run the unmodified
Program. The output from running a covered
work is covered by this License only if the output, given its content,
constitutes a covered work. This License
acknowledges your rights of fair use or other equivalent, as provided by
copyright law.
You may make, run and propagate covered works
that you do not convey, without conditions so long as your license otherwise
remains in force. You may convey covered
works to others for the sole purpose of having them make modifications
exclusively for you, or provide you with facilities for running those works,
provided that you comply with the terms of this License in conveying all
material for which you do not control copyright. Those thus making or running the covered
works for you must do so exclusively on your behalf, under your direction and
control, on terms that prohibit them from making any copies of your copyrighted
material outside their relationship with you.
Conveying under any other circumstances is
permitted solely under the conditions stated below. Sublicensing is not allowed; section 10 makes
it unnecessary.
3. Protecting Users' Legal Rights From
Anti-Circumvention Law.
No covered work shall be deemed part of an
effective technological measure under any applicable law fulfilling obligations
under article 11 of the WIPO copyright treaty adopted on 20 December 1996, or similar
laws prohibiting or restricting circumvention of such measures.
When you convey a covered work, you waive any
legal power to forbid circumvention of technological measures to the extent
such circumvention is effected by exercising rights under this License with
respect to the covered work, and you disclaim any intention to limit operation
or modification of the work as a means of enforcing, against the work's users,
your or third parties' legal rights to forbid circumvention of technological
measures.
4. Conveying Verbatim Copies.
You may convey verbatim copies of the Program's
source code as you receive it, in any medium, provided that you conspicuously
and appropriately publish on each copy an appropriate copyright notice; keep
intact all notices stating that this License and any
non-permissive
terms added in accord with section 7 apply to the code; keep intact all notices
of the absence of any warranty; and give all recipients a copy of this License
along with the Program.
You may charge any price or no price for each
copy that you convey, and you may offer support or warranty protection for a
fee.
5. Conveying Modified Source Versions.
You may convey a work based on the Program,
or the modifications to produce it from the Program, in the form of source code
under the terms of section 4, provided that you also meet all of these
conditions:
a) The work must carry prominent notices
stating that you modified it, and
giving a relevant date.
b) The work must carry prominent notices
stating that it is released under this
License and any conditions added under section
7.
This requirement modifies the requirement in section 4 to "keep
intact all notices".
c) You must license the entire work, as a
whole, under this License to anyone who
comes into possession of a copy. This License will therefore apply, along with any
applicable section 7 additional terms,
to the whole of the work, and all its parts, regardless of how they are
packaged. This License gives no
permission to license the work in any other way, but it does not invalidate
such permission if you have separately received it.
d) If the work has interactive user
interfaces, each must display Appropriate Legal Notices; however, if the
Program has interactive interfaces that do not display Appropriate Legal
Notices, your work need not make them do
so.
A compilation of a covered work with other
separate and independent works, which are not by their nature extensions of the
covered work, and which are not combined with it such as to form a larger
program, in or on a volume of a storage or distribution medium, is called an "aggregate"
if the compilation and its resulting copyright are not used to limit the access
or legal rights of the compilation's users beyond what the individual works
permit. Inclusion of a covered work in
an aggregate does not cause this License to apply to the other parts of the
aggregate.
6. Conveying Non-Source Forms.
You may convey a covered work in object code
form under the terms of sections 4 and 5, provided that you also convey the machine-readable
Corresponding Source under the terms of this License, in one of these ways:
a) Convey the object code in, or embodied
in, a physical product including a physical distribution medium), accompanied
by the Corresponding Source fixed on a durable physical medium customarily used for software interchange.
b) Convey the object code in, or embodied
in, a physical product (including a physical distribution medium), accompanied
by a written offer, valid for at least three years and valid for as long as you
offer spare parts or customer support for that product model, to give anyone
who possesses the object code either (1) a copy of the Corresponding Source for
all the software in the product that is covered by this License, on a durable
physical medium customarily used for software interchange, for a price no more
than your reasonable cost of physically performing this conveying of source, or
(2) access to copy the Corresponding Source
from a network server at no charge.
c) Convey individual copies of the object
code with a copy of the written offer to provide the Corresponding Source. This alternative is allowed only occasionally
and noncommercially, and only if you received the object code with such an
offer, in accord
with subsection 6b.
d) Convey the object code by offering
access from a designated place (gratis or for a charge), and offer equivalent
access to the Corresponding Source in the same way through the same place at no
further charge. You need not require
recipients to copy the Corresponding
Source along with the object code. If
the place to copy the object code is a network server, the Corresponding Source
may be on a different server (operated by you or a third party) that supports equivalent copying facilities,
provided you maintain
clear
directions next to the object code saying where to find the Corresponding Source. Regardless of what server hosts the
Corresponding Source, you remain obligated to ensure that it is available for
as long as needed to satisfy these requirements.
e) Convey the object code using
peer-to-peer transmission, provided you inform other peers where the object
code and Corresponding Source of the work are being offered to the general
public at no charge under subsection 6d.
A separable portion of the object code, whose
source code is excluded from the Corresponding Source as a System Library, need
not be included in conveying the object code work.
A "User Product" is either (1) a
"consumer product", which means any tangible personal property which
is normally used for personal, family, or household purposes, or (2) anything
designed or sold for incorporation into a dwelling. In determining whether a product is a consumer
product, doubtful cases shall be resolved in favor of coverage. For a particular product received by a
particular user, "normally used" refers to a typical or common use of
that class of product, regardless of the status of the particular user or of
the way in which the particular user actually uses, or expects or is expected
to use, the product. A product is a
consumer product regardless of whether the product has substantial commercial,
industrial or non-consumer uses, unless such uses represent the only
significant mode of use of the product.
"Installation Information" for a
User Product means any methods, procedures, authorization keys, or other
information required to install and execute modified versions of a covered work
in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that
the continued functioning of the modified object code is in no case prevented
or interfered with solely because modification has been made.
If you convey an object code work under this
section in, or with, or specifically for use in, a User Product, and the
conveying occurs as part of a transaction in which the right of possession and
use of the User Product is transferred to the recipient in perpetuity or for a fixed
term (regardless of how the transaction is characterized), the Corresponding
Source conveyed under this section must be accompanied by the Installation
Information. But this requirement does
not apply if neither you nor any third party retains the ability to install modified
object code on the User Product (for example, the work has been installed in
ROM).
The requirement to provide Installation
Information does not include a requirement to continue to provide support
service, warranty, or updates for a work that has been modified or installed by
the recipient, or for the User Product in which it has been modified or
installed. Access to a network may be
denied when the modification itself materially and adversely affects the
operation of the network or violates the rules and protocols for communication
across the network.
Corresponding Source conveyed, and
Installation Information provided, in accord with this section must be in a
format that is publicly documented (and with an implementation available to the
public in source code form), and must require no special password or key for unpacking,
reading or copying.
7. Additional Terms.
"Additional permissions" are terms
that supplement the terms of this License by making exceptions from one or more
of its conditions. Additional permissions that are applicable to the entire
Program shall be treated as though they were included in this License, to the
extent that they are valid under applicable law. If additional permissions
apply only
to part of the Program, that part may be used separately under those
permissions, but the entire Program remains governed by this License without
regard to the additional permissions.
When you convey a copy of a covered work, you
may at your option remove any additional permissions from that copy, or from
any part of it. (Additional permissions
may be written to require their own removal in certain cases when you modify
the work.) You may place additional
permissions on material, added by you to a covered work, for which you have or
can give appropriate copyright permission.
Notwithstanding any other provision of this
License, for material you add to a covered work, you may (if authorized by the
copyright holders of that material) supplement the terms of this License with
terms:
a) Disclaiming warranty or limiting
liability differently from the terms of sections 15 and 16 of this License; or
b) Requiring preservation of specified
reasonable legal notices or author attributions in that material or in the
Appropriate Legal Notices displayed by
works containing it; or
c) Prohibiting misrepresentation of the
origin of that material, or requiring that modified versions of such material
be marked in reasonable ways as
different from the original version; or
d) Limiting the use for publicity purposes
of names of licensors or authors of the
material; or
e) Declining to grant rights under
trademark law for use of some trade names, trademarks, or service marks; or
f) Requiring indemnification of licensors
and authors of that material by anyone who conveys the material (or modified
versions of it) with contractual assumptions of liability to the recipient, for
any liability that these contractual assumptions directly impose on those licensors and authors.
All other non-permissive additional terms are
considered "further restrictions" within the meaning of section
10. If the Program as you received it,
or any part of it, contains a notice stating that it is governed by this License
along with a term that is a further restriction, you may remove that term. If a license document contains a further
restriction but permits relicensing or conveying under this License, you may
add to a covered work material governed by the terms of that license document,
provided that the further restriction does not survive such relicensing or
conveying.
If you add terms to a covered work in accord
with this section, you must place, in the relevant source files, a statement of
the additional terms that apply to those files, or a notice indicating where to
find the applicable terms.
Additional terms, permissive or
non-permissive, may be stated in the form of a separately written license, or
stated as exceptions; the above requirements apply either way.
8. Termination.
You may not propagate or modify a covered
work except as expressly provided under this License. Any attempt otherwise to propagate or modify
it is void, and will automatically terminate your rights under this License
(including any patent licenses granted under the third paragraph of section
11).
However, if you cease all violation of this
License, then your license from a particular copyright holder is reinstated (a)
provisionally, unless and until the copyright holder explicitly and finally
terminates your license, and (b) permanently, if the copyright holder fails to
notify you of the violation by some reasonable means prior to 60 days after the
cessation.
Moreover, your license from a particular
copyright holder is reinstated permanently if the copyright holder notifies you
of the violation by some reasonable means, this is the first time you have received
notice of violation of this License (for any work) from that
copyright
holder, and you cure the violation prior to 30 days after your receipt of the
notice.
Termination of your rights under this section
does not terminate the licenses of parties who have received copies or rights
from you under this License. If your
rights have been terminated and not permanently reinstated, you do not qualify
to receive new licenses for the same material under section 10.
9. Acceptance Not Required for Having Copies.
You are not required to accept this License
in order to receive or run a copy of the Program. Ancillary propagation of a covered work occurring
solely as a consequence of using peer-to-peer transmission to receive a copy
likewise does not require acceptance.
However, nothing other than this License grants you permission to
propagate or modify any covered work. These
actions infringe copyright if you do not accept this License. Therefore, by modifying or propagating a covered
work, you indicate your acceptance of this License to do so.
10. Automatic Licensing of Downstream
Recipients.
Each time you convey a covered work, the
recipient automatically receives a license from the original licensors, to run,
modify and propagate that work, subject to this License. You are not responsible for enforcing
compliance by third parties with this License.
An "entity transaction" is a
transaction transferring control of an organization, or substantially all
assets of one, or subdividing an organization, or merging organizations. If propagation of a covered work results from
an entity transaction, each party to that
transaction
who receives a copy of the work also receives whatever licenses to the work the
party's predecessor in interest had or could give under the previous paragraph,
plus a right to possession of the Corresponding Source of the work from the
predecessor in interest, if the predecessor has it or can get it with
reasonable efforts.
You may not impose any further restrictions
on the exercise of the rights granted or affirmed under this License. For example, you may not impose a license
fee, royalty, or other charge for exercise of rights granted under this
License, and you may not initiate litigation (including a cross-claim or
counterclaim in a lawsuit) alleging that any patent claim is infringed by
making, using, selling, offering for sale, or importing the Program or any
portion of it.
11. Patents.
A "contributor" is a copyright
holder who authorizes use under this License of the Program or a work on which
the Program is based. The work thus
licensed is called the contributor's "contributor version".
A contributor's "essential patent
claims" are all patent claims owned or controlled by the contributor,
whether already acquired or hereafter acquired, that would be infringed by some
manner, permitted by this License, of making, using, or selling its contributor
version, but do not include claims that would be infringed only as a consequence
of further modification of the contributor version. For purposes of this definition,
"control" includes the right to grant patent sublicenses in a manner
consistent with the requirements of this License.
Each contributor grants you a non-exclusive,
worldwide, royalty-free patent license under the contributor's essential patent
claims, to make, use, sell, offer for sale, import and otherwise run, modify
and propagate the contents of its contributor version.
In the following three paragraphs, a
"patent license" is any express agreement or commitment, however
denominated, not to enforce a patent (such as an express permission to practice
a patent or covenant not to sue for patent infringement). To "grant" such a patent license to
a party means to make such an agreement or commitment not to enforce a patent
against the party.
If you convey a covered work, knowingly
relying on a patent license, and the Corresponding Source of the work is not
available for anyone to copy, free of charge and under the terms of this
License, through a publicly available network server or other readily
accessible means, then you must either (1) cause the Corresponding Source to be
so available, or (2) arrange to deprive yourself of the benefit of the patent
license for this particular work, or (3) arrange, in a manner consistent with
the requirements of this License, to extend the patent license to downstream
recipients. "Knowingly
relying" means you have actual knowledge that, but for the patent license,
your conveying the covered work in a country, or your recipient's use of the
covered work in a country, would infringe one or more identifiable patents in
that country that you have reason to believe are valid.
If, pursuant to or in connection with a
single transaction or arrangement, you convey, or propagate by procuring
conveyance of, a covered work, and grant a patent license to some of the
parties receiving the covered work authorizing them to use, propagate, modify or
convey a specific copy of the covered work, then the patent license you grant
is automatically extended to all recipients of the covered work and works based
on it.
A patent license is
"discriminatory" if it does not include within the scope of its
coverage, prohibits the exercise of, or is conditioned on the non-exercise of
one or more of the rights that are specifically granted under this
License. You may not convey a covered work
if you are a party to an arrangement with a third party that is in the business
of distributing software, under which you make payment to the third party based
on the extent of your activity of conveying the work, and under which the third
party grants, to any of the parties who would receive the covered work from
you, a discriminatory patent license (a) in connection with copies of the
covered work conveyed by you (or copies made from those copies), or (b)
primarily for and in connection with specific products or compilations that contain
the covered work, unless you entered into that arrangement, or that patent
license was granted, prior to 28 March 2007.
Nothing in this License shall be construed as
excluding or limiting any implied license or other defenses to infringement that
may otherwise be available to you under applicable patent law.
12. No Surrender of Others' Freedom.
If conditions are imposed on you (whether by
court order, agreement or otherwise) that contradict the conditions of this
License, they do not excuse you from the conditions of this License. If you cannot convey a covered work so as to
satisfy simultaneously your obligations under this License and any other
pertinent obligations, then as a consequence you may not convey it at all. For example, if you agree to terms that
obligate you to collect a royalty for further conveying from those to whom you
convey
the
Program, the only way you could satisfy both those terms and this License would
be to refrain entirely from conveying the Program.
13. Use with the GNU Affero General Public
License.
Notwithstanding any other provision of this
License, you have permission to link or combine any covered work with a work
licensed under version 3 of the GNU Affero General Public License into a single
combined work, and to convey the resulting work. The terms of this License will continue to
apply to the part which is the covered work, but the special requirements of
the GNU Affero General Public License, section 13, concerning interaction
through a network will apply to the combination as such.
14. Revised Versions of this License.
The Free Software Foundation may publish
revised and/or new versions of the GNU General Public License from time to
time. Such new versions will be similar
in spirit to the present version, but may differ in detail to address new
problems or concerns.
Each version is given a distinguishing
version number. If the Program specifies
that a certain numbered version of the GNU General Public License "or any
later version" applies to it, you have the option of following the terms
and conditions either of that numbered version or of any later version
published by the Free Software Foundation.
If the Program does not specify a version number of the GNU General
Public License, you may choose any version ever published by the Free Software
Foundation.
If the
Program specifies that a proxy can decide which future versions of the GNU
General Public License can be used, that proxy's public statement of acceptance
of a version permanently authorizes you to choose that version for the Program.
Later license versions may give you
additional or different permissions.
However, no additional obligations are imposed on any author or
copyright holder as a result of your choosing to follow a later version.
15. Disclaimer of Warranty.
THERE IS NO WARRANTY FOR THE PROGRAM, TO THE
EXTENT PERMITTED BY APPLICABLE LAW.
EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR
OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY
KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND
PERFORMANCE OF THE PROGRAM IS WITH YOU.
SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY
SERVICING, REPAIR OR CORRECTION.
16. Limitation of Liability.
IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW
OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO
MODIFIES AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR
DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES
ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT
LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED
BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.
17. Interpretation of Sections 15 and 16.
If the disclaimer of warranty and limitation
of liability provided above cannot be given local legal effect according to
their terms, reviewing courts shall apply local law that most closely
approximates an absolute waiver of all civil liability in connection with the
Program,
unless a warranty or assumption of liability accompanies a copy of the Program
in return for a fee.
END OF TERMS AND
CONDITIONS
How to Apply These Terms to Your
New Programs
If you develop a new program, and you want it
to be of the greatest possible use to the public, the best way to achieve this
is to make it free software which everyone can redistribute and change under
these terms. To do so, attach the
following notices to the program. It is
safest o attach them to the start of each source file to most effectively state
the exclusion of warranty; and each file should have at least the
"copyright" line and a pointer to where the full notice is found.
<one line to give the program's name and
a brief idea of what it does.>
Copyright (C) <year> <name of author>
This program is free software: you can
redistribute it and/or modify it under the terms of the GNU General Public
License as published by the Free Software Foundation, either version 3 of the
License, or (at your option) any later
version.
This program is distributed in the hope
that it will be useful, but WITHOUT ANY WARRANTY; without even the implied
warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more
details.
You should have received a copy of the GNU
General Public License along with this program.
If not, see <http://www.gnu.org/licenses/>.
Also add
information on how to contact you by electronic and paper mail.
If the program does terminal interaction,
make it output a short notice like this when it starts in an interactive mode:
<program> Copyright (C) <year> <name of author>
This program comes with ABSOLUTELY NO
WARRANTY; for details type `show w'. This is free software, and you are welcome
to redistribute it under certain conditions; type `show c' for details.
The
hypothetical commands `show w' and `show c' should show the appropriate parts
of the General Public License. Of course,
your program's commands might be different; for a GUI interface, you would use
an "about box".
You should also get your employer (if you
work as a programmer) or school, if any, to sign a "copyright
disclaimer" for the program, if necessary.
For more
information on this, and how to apply and follow the GNU GPL, see <http://www.gnu.org/licenses/>.
The GNU General Public License does not
permit incorporating your program into proprietary programs. If your program is a subroutine library, you may
consider it more useful to permit linking proprietary applications with the
library. If this is what you want to do,
use the GNU Lesser General Public License instead of this License. But first, please read <http://www.gnu.org/philosophy/why-not-lgpl.html>.
ANEXO 3.
MUESTRA DE CAPTURA DE TRAFICO PERIODICO DEL 30% DEL CANAL
0.000000 1024 inf
0.081377 1024 100667
0.083973 1024 3155624
0.086569 1024 3155624
0.089266 1024 3037449
0.091862 1024 3155624
0.094458 1024 3155624
0.097055 1024 3154409
0.099751 1024 3038576
0.102348 1024 3154409
0.104943 1024 3156840
0.107540 1024 3154409
0.110237 1024 3037449
0.112833 1024 3155624
0.115429 1024 3155624
0.118126 1024 3037449
0.120722 1024 3155624
0.123318 1024 3155624
0.125914 1024 3155624
0.128610 1024 3038576
0.131207 1024 3154409
0.133803 1024 3155624
0.136500 1024 3037449
0.139096 1024 3155624
0.141695 1024 3151982
0.144290 1024 3156840
0.146988 1024 3036323
0.149582 1024 3158057
0.152178 1024 3155624
0.154874 1024 3038576
0.157470 1024 3155624
0.238857 1024 100655
0.241454 1024 3154409
0.244050 1024 3155624
0.246747 1024 3037449
0.249343 1024 3155624
0.251942 1024 3151982
0.254536 1024 3158057
0.257232 1024 3038576
0.259828 1024 3155624
0.262425 1024 3154409
0.265121 1024 3038576
0.267717 1024 3155624
0.270314 1024 3154409
0.272910 1024 3155624
0.275606 1024 3038576
0.278202 1024 3155624 |
0.280799 1024 3154409
0.283397 1024 3153195
0.286094 1024 3037449
0.288689 1024 3156840
0.291285 1024 3155624
0.293881 1024 3155624
0.296577 1024 3038576
0.299173 1024 3155624
0.301870 1024 3037449
0.304466 1024 3155624
0.307062 1024 3155624
0.309659 1024 3154409
0.312754 1024 2646850
0.314952 1024 3727025
0.396339 1024 100655
0.398935 1024 3155624
0.401531 1024 3155624
0.404127 1024 3155624
0.406824 1024 3037449
0.409420 1024 3155624
0.412017 1024 3154409
0.414713 1024 3038576
0.417309 1024 3155624
0.419906 1024 3154409
0.422501 1024 3156840
0.425198 1024 3037449
0.427798 1024 3150769
0.430391 1024 3159275
0.433087 1024 3038576
0.435684 1024 3154409
0.438380 1024 3038576
0.440877 1024 3280737
0.443573 1024 3038576
0.446169 1024 3155624
0.448765 1024 3155624
0.451461 1024 3038576
0.454058 1024 3154409
0.456654 1024 3155624
0.459251 1024 3154409
0.461947 1024 3038576
0.464544 1024 3154409
0.467145 1024 3149558
0.469836 1024 3044221
0.472432 1024 3155624 0.553819 1024
100655
0.556416 1024 3154409
0.559012 1024 3155624 |
ANEXO 4. MUESTRA DE CAPTURA DE TRAFICO
PERIODICO DEL 60% DEL CANAL
0.000000 1024 inf
0.041837 1024 195808
0.043137 1024 6301538
0.044533 1024 5868195
0.045831 1024 6311248
0.047129 1024 6311248
0.048527 1024 5859800
0.049925 1024 5859800
0.051223 1024 6311248
0.052621 1024 5859800
0.053920 1024 6306390
0.055318 1024 5859800
0.056616 1024 6311248
0.058014 1024 5859800
0.059312 1024 6311248
0.060710 1024 5859800
0.062008 1024 6311248
0.063406 1024 5859800
0.064704 1024 6311248
0.066003 1024 6306390
0.067400 1024 5863994
0.068699 1024 6306390
0.070097 1024 5859800
0.071395 1024 6311248
0.072793 1024 5859800
0.074193 1024 5851429
0.075493 1024 6301538
0.076890 1024 5863994
0.078186 1024 6320988
0.079484 1024 6311248
0.080883 1024 5855611
0.122624 1024 196258
0.124022 1024 5859800
0.125320 1024 6311248
0.126718 1024 5859800
0.128017 1024 6306390
0.129414 1024 5863994
0.130713 1024 6306390
0.132111 1024 5859800
0.133409 1024 6311248
0.134807 1024 5859800
0.136105 1024 6311248
0.137503 1024 5859800
0.138802 1024 6306390
0.140200 1024 5859800
0.141497 1024 6316114
0.142896 1024 5855611 |
0.144193 1024 6316114
0.145592 1024 5855611
0.146894 1024 6291859
0.148288 1024 5876614
0.149587 1024 6306390
0.150985 1024 5859800
0.152283 1024 6311248
0.153681 1024 5859800
0.154979 1024 6311248
0.156377 1024 5859800
0.157675 1024 6311248
0.159073 1024 5859800
0.160371 1024 6311248
0.161770 1024 5855611
0.203511 1024 196258
0.204909 1024 5859800
0.206208 1024 6306390
0.207605 1024 5863994
0.208904 1024 6306390
0.210302 1024 5859800
0.211600 1024 6311248
0.212998 1024 5859800
0.216693 1024 2217050
0.217494 1024 10227216
0.218391 1024 9132664
0.219191 1024 10240000
0.219989 1024 10265664
0.221087 1024 7460838
0.222385 1024 6311248
0.223683 1024 6311248
0.225081 1024 5859800
0.226479 1024 5859800
0.227777 1024 6311248
0.229076 1024 6306390
0.230473 1024 5863994
0.231772 1024 6306390
0.233170 1024 5859800
0.234568 1024 5859800
0.235866 1024 6311248
0.237164 1024 6311248
0.238562 1024 5859800
0.239861 1024 6306390
0.241259 1024 5859800
0.242557 1024 6311248
0.284399 1024 195784
0.285697 1024 6311248
0.287095 1024 5859800 |
ANEXO 5.
MUESTRA DE CAPTURA DE TRAFICO POISSON DEL 30% DEL CANAL
0.000000 1024 inf
0.079780 1024 102682
0.080579 1024 10252816
0.081378 1024 10252816
0.082376 1024 8208417
0.089966 1024 1079315
0.095658 1024 1439213
0.097159 1024 5457695
0.105145 1024 1025795
0.109539 1024 1864360
0.110637 1024 7460838
0.112235 1024 5126408
0.113034 1024 10252816
0.119725 1024 1224331
0.120823 1024 7460838
0.121921 1024 7460838
0.129311 1024 1108525
0.130609 1024 6311248
0.133011 1024 3410491
0.134504 1024 5486939
0.140096 1024 1464950
0.142992 1024 2828729
0.144889 1024 4318397
0.147985 1024 2645995
0.150981 1024 2734312
0.151780 1024 10252816
0.166860 1024 543236
0.168858 1024 4100100
0.169955 1024 7467639
0.170754 1024 10252816
0.171952 1024 6838063
0.257233 1024 96059
0.259630 1024 3417605
0.260429 1024 10252816
0.261328 1024 9112347
0.262126 1024 10265664
0.265022 1024 2828729
0.265921 1024 9112347
0.270515 1024 1783195
0.274109 1024 2279354
0.283696 1024 854490
0.285094 1024 5859800
0.286792 1024 4824499
0.299475 1024 645904
0.300273 1024 10265664
0.301671 1024 5859800 |
0.302470 1024
10252816
0.303968 1024 5468625
0.315253 1024 725919
0.316051 1024 10265664
0.317649 1024 5126408
0.318548 1024 9112347
0.319446 1024 9122494
0.320245 1024 10252816
0.324040 1024 2158630
0.325738 1024 4824499
0.334626 1024 921692
0.335524 1024 9122494
0.337621 1024 3906533
0.341616 1024 2050563
0.342515 1024 9112347
0.417414 1024 109374
0.418314 1024 9102222
0.423003 1024 1747068
0.423801 1024 10265664
0.424700 1024 9112347
0.425499 1024 10252816
0.426598 1024 7454049
0.431691 1024 1608482
0.432888 1024 6843776
0.434387 1024 5464977
0.437182 1024 2930948
0.441976 1024 1708803
0.444472 1024 3282051
0.445571 1024 7454049
0.446569 1024 8208417
0.449969 1024 2409412
0.450863 1024 9163311
0.451963 1024 7447273
0.455956 1024 2051590
0.457555 1024 5123202
0.462347 1024 1709516
0.463246 1024 9112347
0.465343 1024 3906533
0.466142 1024 10252816
0.468938 1024 2929900
0.469837 1024 9112347
0.470637 1024 10240000
0.471435 1024 10265664
0.472333 1024 9122494
0.473132 1024 10252816
0.583679 1024 74104 |
ANEXO 6.
MUESTRA CAPTURA DE TRAFICO POISSON DEL 60% DEL CANAL
0.000000 1024 inf
0.034742 1024 235795
0.035540 1024 10265664
0.036439 1024 9112347
0.041232 1024 1709159
0.043130 1024 4316122
0.043929 1024 10252816
0.048323 1024 1864360
0.049820 1024 5472278
0.052120 1024 3561739
0.053618 1024 5468625
0.054418 1024 10240000
0.055313 1024 9153073
0.056113 1024 10240000
0.057011 1024 9122494
0.057811 1024 10240000
0.058711 1024 9102222
0.059507 1024 10291457
0.060306 1024 10252816
0.061205 1024 9112347
0.066198 1024 1640697
0.067097 1024 9112347
0.067895 1024 10265664
0.070492 1024 3154409
0.071291 1024 10252816
0.072189 1024 9122494
0.072988 1024 10252816
0.075385 1024 3417605
0.076284 1024 9112347
0.077083 1024 10252816
0.077981 1024 9122494
0.112134 1024 239862
0.112932 1024 10265664
0.116628 1024 2216450
0.117526 1024 9122494
0.120422 1024 2828729
0.121520 1024 7460838
0.122419 1024 9112347
0.123219 1024 10240000
0.124719 1024 5461333
0.126116 1024 5863994
0.127013 1024 9132664
0.128911 1024 4316122
0.131308 1024 3417605
0.132206 1024 9122494 |
0.133005 1024 10252816
0.133905 1024 9102222
0.135002 1024 7467639
0.135801 1024 10252816
0.136700 1024 9112347
0.141393 1024 1745579
0.142192 1024 10252816
0.143090 1024 9122494
0.143889 1024 10252816
0.144788 1024 9112347
0.146785 1024 4102153
0.147584 1024 10252816
0.148983 1024 5855611
0.149881 1024 9122494
0.150680 1024 10252816
0.151479 1024 10252816
0.184034 1024 251636
0.184833 1024 10252816
0.185731 1024 9122494
0.186530 1024 10252816
0.187429 1024 9112347
0.188228 1024 10252816
0.189026 1024 10265664
0.189925 1024 9112347
0.192821 1024 2828729
0.195817 1024 2734312
0.197715 1024 4316122
0.200012 1024 3566391
0.200812 1024 10240000
0.201609 1024 10278545
0.202508 1024 9112347
0.203307 1024 10252816
0.204206 1024 9112347
0.205005 1024 10252816
0.205903 1024 9122494
0.206702 1024 10252816
0.207501 1024 10252816
0.208400 1024 9112347
0.209897 1024 5472278
0.212794 1024 2827753
0.214791 1024 4102153
0.216888 1024 3906533
0.217787 1024 9112347
0.219184 1024 5863994
0.221182 1024 4100100 |
[1] General Public License. [online] http://en.wikIPedia.org/wiki/Gpl
[2] MOGUL, J., AND DEERING, S. RFC1191: Path MTU
discovery. Internet RFC, Nov. 1990.
[3] STEVENS, W. TCP/IP Illustrated: The Protocols,
Vol. I. Ed. Addison-Wesley, Jan. 1994.
[4] BRADEN, R. RFC1122: Requirements for Internet Hosts – Communication Layers. Internet RFC, IETF, Oct. 1989. Editor, Standard.
[5] PANIAGUA. Javier Gonzalo. Documentos RFC en Español. [online] http://www.rfc-es.org/ Ultima Actualización: 14 Febrero de 2008.
[6] LOPEZ
MONGE, Alejandro. Aprendiendo a programar con Libpcap. [On-line].
Pag 27. http://www.e-ghost.deusto.es/docs/2005/conferencias/pcap.pdf. 20 de Febrero de 2005
[7] Tutorial de Tcpdump y WinDump. [online] http://www.arrakis.es/~terron/tcpdump.html. 2007
[8] WIKILEARNING. Pequeño tutorial de TCPdump. [online] http://www.wikilearning.com/tutorial/pequeno_tutorial_de_tcpdump-filtros/6424-8. Última Actualización: 27 de Octubre de 2005.
[9] Microsoft Corp [on line] <Http://www.microsoft.com/spanish/MSDN/estudiantes/ingsoft/default.asp>
[10] Pressman Roger S. 1994. Ingeniería del Software un enfoque Práctico. Editorial McGraw Hill. Tercera Edición. Pág 11 y 25.
[11] Ingeniería de software [on line] http://www.itcg.edu.mx/ingsoft/diseno.htm
[12] Ibid, p.p. 25
[13] Ibid, pp 26
[14] JACOBSON, V., BRADEN, R.,
AND BORMAN, D. RFC1323: TCP Extensions for High Performance. Internet RFC, May
1992.
[15] LIBRERÍA LIBPCAP [online].
http://www.tcpdump.org/release/ 2008