Validación de arquitecturas de provisión de servicios TCP escalables con dispositivos de recursos limitados en el paradigma de la computación en la niebla

Resumen

Desde su creación, Internet ha evolucionado hasta convertirse en una herramienta esencial de comunicación y progreso. Actualmente Internet es considerada como una red global diseñada para acceder principalmente a fuentes de información generadas por personas. Uno de los paradigmas dentro de la Internet del futuro --denominado como Internet de las Cosas (IoT)-- pretende transformar Internet y sus modelos de interacción. La convergencia de personas, objetos y procesos tendrá un gran impacto a nivel social e industrial. Desde una perspectiva simplificada, la estructura de IoT se compone de tres elementos conceptuales: dispositivos finales, como sensores o actuadores que a menudo realizan una función dedicada; dispositivos de interconexión, como puertas de enlace o routers que se ubican en los puntos de unión clave de la topología de red para conectar una red local con Internet; y por último, la nube. El concepto de la nube se refiere al uso de servicios bajo demanda a través de Internet, como el almacenamiento y procesamiento de datos en granjas de servidores web. Para el año 2020 se prevé que el número de dispositivos finales supere los 28.000 millones. Gestionar ese crecimiento de datos supondría una demanda cada vez mayor de ancho de banda, pero también de capacidad de cómputo en la nube. Además, para aplicaciones sensibles a la latencia, el retardo causado por la transferencia de datos a la nube y la espera de la respuesta correspondiente es inaceptable. IoT necesita una forma más eficiente y escalable de trabajar con el volumen de datos generado. La computación en la niebla (Fog computing) es un modelo de computación distribuido propuesto por algunas de las empresas tecnológicas más importantes (ARM, Cisco, Dell, Intel y Microsoft son los miembros fundadores del consorcio OpenFog). Este modelo representa un cambio en la infraestructura de computación en la que los recursos y servicios se distribuyen a lo largo de la topología de red que une las fuentes de datos con la nube, es decir, en los dispositivos de interconexión. Este modelo puede distribuirse aún más, utilizando las capacidades de computación, almacenamiento y comunicación de los dispositivos finales. Trasladar parte de la inteligencia a los dispositivos finales se traduce en una mayor autonomía, tiempos de respuesta predecibles y una reducción de la congestión de red en los dispositivos de interconexión. Cada uno de estos dispositivos finales requerirá, como mínimo, un procesador para añadir inteligencia al dispositivo, un sensor para capturar alteraciones del entorno, una interfaz de comunicación para la transmisión y recepción de datos, y un componente de memoria. No obstante, la necesidad de reducir consumos y costes en IoT provoca que la mayoría de estos dispositivos tengan restricciones de recursos. El RFC 7228 define que el conjunto de protocolos de Internet se utiliza cada vez más en microcontroladores de recursos limitados, y establece una clasificación en 3 clases atendiendo a sus restricciones de memoria. En el modelo de la computación en la niebla, incluso estos dispositivos con restricciones podrían prestar un servicio a otros dispositivos locales. Los dispositivos clase 2 son moderadamente limitados, y por tanto son los mejores candidatos para ofrecer esos servicios locales. El RFC 7547 describe la necesidad de un transporte fiable de mensajes para determinados servicios, y que esa fiabilidad puede conseguirse sobre la base de un protocolo de transporte como TCP. Sin embargo, las limitaciones en computación y memoria de un dispositivo clase 2 hacen que solamente sea posible gestionar un número muy limitado de conexiones TCP al mismo tiempo. Ante una alta demanda --ya sea puntual o deliberada-- el servicio podría verse interrumpido. Esta circunstancia ofrece oportunidades para la colaboración de estos dispositivos. Combinando un número de dispositivos clase 2 en un clúster de balanceo, las limitaciones individuales pueden compensarse parcialmente. Esta arquitectura distribuida y transparente para el cliente debe tener cierta tolerancia a ataques de denegación de servicio (DoS), y ser capaz de distribuir las conexiones TCP entre los dispositivos disponibles. El objetivo es aplicar en los dispositivos clase 2 las técnicas de balanceo de carga y defensa ante ataques de inundación SYN existentes en los sistemas operativos de propósito general (como Linux), y por tanto, para procesadores con unas características muy superiores a las definidas en el RFC 7228. En definitiva, este trabajo quiere demostrar que es posible trasladar conceptos de la computación en la nube, como la alta disponibilidad y la escalabilidad, al borde más extremo de la red, a los dispositivos de recursos limitados. Al igual que en la nube se configuran varios servidores detrás de un balanceador de carga para procesar el tráfico y hacerlos parecer como una sola unidad, el mismo concepto puede aplicarse a la computación en la niebla. La propuesta ha sido evaluada mediante el despliegue de un pequeño clúster de dispositivos clase 2, y se ha comparado su rendimiento de red con tres tipos de balanceadores en un experimento real. Los resultados demuestran que un dispositivo clase 2 puede distribuir tráfico TCP a un clúster de hasta cinco servidores clase 2 y veinte clientes concurrentes sin reducir el rendimiento de red respecto a balanceadores de carga de capacidades muy superiores a las definidas en el RFC 7228. Se demuestra por tanto que los dispositivos clase 2 pueden formar por sí mismos arquitecturas de balanceo de carga. Este concepto permitiría crear bajo demanda clústeres de dispositivos limitados con el objetivo de ofrecer servicios TCP escalables y flexibles. Por otra parte, el método de balanceo de carga seleccionado hace que el tráfico de retorno no pase por el balanceador. Esto significa que deben aplicarse mecanismos de defensa ante ataques DoS en los servidores clase 2. Se han analizado dos mecanismos de mitigación de ataques SYN definidos en el RFC 4987: SYN cookies y reciclar las conexiones semiabiertas más antiguas. Tras analizar las dos implementaciones de SYN cookies disponibles en dos sistemas operativos de tipo Unix, se demuestra que la implementación de Linux es más lenta pero más robusta que la de FreeBSD. Se propone una implementación híbrida que combina el rendimiento de FreeBSD y la robustez de Linux, y se aplica a un dispositivo clase 2. La experimentación demuestra que el rendimiento de red de un dispositivo clase 2 en presencia de un ataque SYN de baja tasa se ve menos afectado con el mecanismo SYN cookies que utilizando una estrategia de reemplazo de conexiones semiabiertas en memoria.