Falcon está diseñado para ser confiable, de alto rendimiento y baja latencia

Durante la OCP Global Summit (que se llevo a cabo hace unos días) Google dio a conocer mediante un anuncio la decisión de liberar su tecnología de transferencia de datos Falcon y la transferencia de su desarrollo posterior al proyecto Open Compute, cuyo objetivo es el desarrollo conjunto de especificaciones de hardware abiertas para equipar centros de datos.

Falcon (transporte de hardware, capa de transporte acelerado por hardware) se promociona como la próxima generación de Ethernet, ya que Google presume que es capaz de aumentar el rendimiento y la eficiencia de la transferencia de datos en las redes estándar existentes basadas en Ethernet y TCP/IP que son fundamentales para el rendimiento y la latencia, como las redes para computación de alto rendimiento e inteligencia artificial.

Las cargas de trabajo como el almacenamiento han necesitado algunos de estos atributos durante mucho tiempo; sin embargo, con casos de uso más nuevos, como la capacitación de IA/ML a gran escala y la computación de alto rendimiento (HPC), la necesidad ha aumentado significativamente. En el pasado, hemos compartido abiertamente nuestros aprendizajes sobre configuración del tráfico, control de congestión, equilibrio de carga y más con la industria al contribuir con nuestras ideas a la Association for Computing Machinery and Internet Engineering Task Force.

Para lograr este objetivo, desarrollamos Falcon para habilitar una función escalonada en el rendimiento sobre transportes solo de software. 

Sobre Falcon

En la descripción del protocolo se menciona que Falcon está diseñado para poder adaptarse a las redes de centros de datos y está diseñado para proporcionar un alto rendimiento predecible, baja latencia, flexibilidad y extensibilidad.

Por la parte de su característica de ofrecer una baja latencia en redes Ethernet de alta velocidad que toleran la pérdida de paquetes, Falcon utiliza tres principios: medición detallada de los retrasos entre el envío de una solicitud y la recepción de una respuesta (RTT, tiempo de ida y vuelta), recorte de tráfico implementado por hardware en relación con individuos flujos y retransmisión de paquetes rápida y precisa. Estas propiedades se complementan con medios para el acceso simultáneo a través de varios canales (Multipath) y soporte para cifrado de conexiones.

Además de esta base, Falcon ha sido diseñado desde cero como un transporte multiprotocolo capaz de admitir ULP con requisitos de rendimiento y semántica de aplicaciones muy variables. La capa de mapeo ULP no solo proporciona compatibilidad inmediata con Infiniband Verbs RDMA y NVMe ULP, sino que también incluye innovaciones adicionales críticas para aplicaciones a escala de almacén, como semántica de pedidos flexible y manejo elegante de errores. 

Por último, pero no menos importante, el hardware y el software están diseñados conjuntamente para trabajar juntos y ayudar a lograr los atributos deseados de alta velocidad de mensajes, baja latencia y alto ancho de banda, manteniendo al mismo tiempo la flexibilidad para la programabilidad y la innovación continua.

Por la parte de la base de Falcon, se menciona que las siguientes tecnologías están involucradas:

• Carrusel: un mecanismo de limitación de tráfico (Traffic Shaping), que permite regular el rendimiento y la intensidad del flujo de paquetes en el contexto de hosts individuales.
• Snap: un subsistema de red basado en microkernel que se puede ampliar con módulos a través de los cuales se pueden agregar funciones avanzadas, como virtualización de red, limitación de tráfico y funciones de entrega de mensajes.
• Swift: un mecanismo de control de congestión para redes a nivel de centro de datos, que permite lograr una latencia de menos de 50 microsegundos para mensajes RPC cortos mientras se mantiene un rendimiento de 100 Gbps por servidor con una carga cercana al 100%.
• RACK-TLP: un algoritmo para determinar la pérdida de paquetes para TCP.
• PLB: es un mecanismo de equilibrio de carga que utiliza señales de congestión.
• CSIG: un protocolo de intercambio de telemetría que se utiliza para enviar señales de congestión y control de tráfico.
• PSP: protocolo de cifrado de tráfico.

El soporte Falcon estará disponible por primera vez en la serie Intel IPU E2000 de aceleradores de red, que combinan un adaptador Ethernet con un procesador programable que puede manejar operaciones que normalmente se realizan en la pila de red o en el lado del sistema, como la gestión del tráfico y la congestión control y análisis de protocolos de alto nivel.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

from Linux Adictos https://ift.tt/uYlTINR
via IFTTT

OpenSilver, el marco de código abierto y sin complementos que utiliza WebAssembly, C#, XAML y .NET

Hace pocos días se dio a conocer en lanzamiento de la nueva versión de OpenSilver 2.0, la cual con el soporte para VB.NET, asi como también con mejoras de integración, nuevas funciones, mejoras de rendimiento y muchas cosas más.

Para quienes desconocen de OpenSilver, deben saber que este es un proyecto que continúa con el desarrollo de la plataforma Silverlight que permite crear aplicaciones web interactivas utilizando tecnologías C#, XAML y .NET y la cual en 2021 Microsoft dejó de desarrollar y mantener.

Las aplicaciones Silverlight compiladas con OpenSilver se pueden ejecutar en cualquier navegador de escritorio y móvil que admita WebAssembly, pero actualmente la compilación solo es posible en Windows usando Visual Studio.

En su forma actual, OpenSilver ya ha ido más allá de una capa para extender la vida útil de Silverlight y puede considerarse como una plataforma independiente para crear nuevas aplicaciones.

Por primera vez, los entusiastas de VB.NET pueden unirse a la diversión y crear aplicaciones web con Visual Basic y XAML. ¡Pero espera hay mas! Aproveche la integración fluida con marcos populares como Blazor , React y Angular : ¡no es necesario iniciar su aplicación OpenSilver desde cero! Sea testigo de cómo sus creaciones cobran vida con una vista previa XAML en vivo y salude nuevamente a un clásico de los días de Silverlight.

Principales novedades de OpenSilver 2.0

En esta nueva versión que se presenta de OpenSilver 2.0, una de sus características más importantes es la compatibilidad con VB.NET, la cual fue añadida para el desarrollo de aplicaciones web utilizando el lenguaje de programación Visual Basic para definir la lógica y el lenguaje de marcado XAML para la interfaz. Se menciona que esta nueva característica ofrece un mensaje positivo a la comunidad de Visual Basic, brindándoles la seguridad de que su lenguaje preferido se mantiene firme en entornos de desarrollo de vanguardia.

Esta actualización proporciona una opción muy necesaria para aquellos apasionados por VB.NET para continuar creando aplicaciones web innovadoras o migrar aplicaciones heredadas a la web moderna.

Otra de las novedades que se destaca, es la integración con los frameworks web Blazor, React y Angular, junto con la cual se agregó el componente XAML para Blazor, el cual tiene como finalidad permitir a los desarrolladores el poder integrar OpenSilver en proyectos Blazor existentes.

Ademas de ello, también se destaca el soporte añadido para la vista previa de XAML, esto es gracias a la función Live XAML Preview, con ello se puede obtener una vista previa de la interfaz que se está desarrollando a medida que se desarrolla, sin tener que iniciar la aplicación.

RIA es otra de las novedades que acompaña a OpenSilver 2.0, ya que gracias a esta plantilla de aplicaciones empresariales se puede simplifican el desarrollo de aplicaciones web para empresas, pues RIA permite que se generen automáticamente objetos en el servidor para su ejecución en el lado del cliente, ademas de que permite manejar una variedad de tareas, que incluyen consultas, validación, almacenamiento en caché de entidades del lado del cliente, seguimiento de cambios y actualizaciones por lotes, simplificando así el proceso de desarrollo y fortaleciendo la solidez de las aplicaciones.

De los demás cambios que se destacan:

• Se agregó SampleCRM : un ejemplo de una aplicación abierta con la implementación de un sistema CRM funcional para organizar la interacción con los clientes en una empresa y garantizar el trabajo del servicio de ventas.
• Se agregó la capacidad de crear sus propios diseños de interfaz (Layout) y usar conjuntos de elementos de interfaz suministrados por separado, como Telerik UI para Silverlight.
• Se ha aumentado significativamente el rendimiento del simulador (hasta 10 veces) y se han ampliado las capacidades de depuración.

Finalmente, se menciona que se tienen planes futuros en los cuales se espera poder proporcionar un entorno de diseño visual que permita crear interfaces XAML en modo WYSIWYG, soporte para WPF y una integración mejorada con el editor de código VS Code. 

Si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

from Linux Adictos https://ift.tt/OZ3KcD2
via IFTTT

DDoS, es un ataque a un sistema de computadoras o red que causa que un servicio o recurso sea inaccesible a los usuarios legítimos

Hace pocos días se dio a conocer la noticia de que Google registró el mayor ataque DDoS a su infraestructura, cuya intensidad fue de 398 millones de RPS (solicitudes por segundo). Los ataques se llevaron a cabo utilizando una vulnerabilidad previamente desconocida (CVE-2023-44487) en el protocolo HTTP/2, que permite enviar un gran flujo de solicitudes al servidor con una carga mínima para el cliente.

Se menciona que la nueva técnica de ataque llamada «Rapid Reset» aprovecha el hecho de que los medios de multiplexación de canales de comunicación proporcionados en HTTP/2 permiten formar un flujo de solicitudes dentro de una conexión ya establecida, sin abrir nuevas conexiones de red y sin esperando confirmación de recepción de paquetes.

La vulnerabilidad se considera consecuencia de un fallo en el protocolo HTTP/2 , cuya especificación establece que si se intenta abrir demasiados flujos, sólo se deben cancelar los flujos que superen el límite, pero no toda la red.

Dado que un ataque del lado del cliente se puede llevar a cabo simplemente enviando solicitudes sin recibir respuestas, el ataque se puede llevar a cabo con una sobrecarga mínima. Por ejemplo, un ataque de 201 millones de solicitudes por segundo registrado por Cloudflare se llevó a cabo utilizando una botnet relativamente pequeña de 20 mil computadoras.

En el lado del servidor, el costo de procesar las solicitudes entrantes es significativamente mayor, a pesar de su cancelación, ya que es necesario realizar operaciones como asignar estructuras de datos para nuevos subprocesos, analizar la solicitud, descomprimir el encabezado y asignar la URL al recurso. Al atacar servidores proxy inversos, el ataque puede extenderse a los servidores, ya que el proxy puede tener tiempo para redirigir la solicitud al servidor antes de que se procese la trama RST_STREAM.

Un ataque solo se puede llevar a cabo en servidores vulnerables que admitan HTTP/2 (un script para verificar la manifestación de vulnerabilidades en los servidores, herramientas para realizar un ataque). Para HTTP/3, los ataques aún no se han detectado y la posibilidad de que ocurran no se ha analizado completamente, pero los representantes de Google recomiendan que los desarrolladores de servidores agreguen medidas de seguridad a las implementaciones de HTTP/3 similares a las implementadas para bloquear ataques en HTTP/2.

De manera similar a los métodos de ataque utilizados anteriormente en HTTP/2, el nuevo ataque también crea una gran cantidad de subprocesos dentro de una sola conexión. La diferencia clave del nuevo ataque es que en lugar de esperar una respuesta, cada solicitud enviada va seguida de un marco con el indicador RST_STREAM, que cancela inmediatamente la solicitud.

Cancelar una solicitud en una etapa temprana permite deshacerse del tráfico inverso hacia el cliente y evitar las restricciones en la cantidad máxima posible de transmisiones que se abren simultáneamente dentro de una única conexión HTTP/2 en servidores HTTP. Así, en el nuevo ataque, el volumen de solicitudes enviadas al servidor HTTP deja de depender de los retrasos entre el envío de la solicitud y la recepción de la respuesta (RTT, tiempo de ida y vuelta) y depende únicamente del ancho de banda del canal de comunicación.

Se menciona que la ola de ataques más reciente comenzó a finales de agosto y continúa en la actualidad. Se dirige a los principales proveedores de infraestructura, incluidos los servicios de Google, la infraestructura de Google Cloud y sus clientes. 

Aunque estos ataques estuvieron entre los más grandes que Google haya visto, su equilibrio de carga global y su infraestructura de mitigación de DDoS permitieron que sus servicios siguieran funcionando. 

Para proteger a Google, sus clientes y el resto de Internet, ayudaron a liderar un esfuerzo coordinado con socios de la industria para comprender la mecánica del ataque y colaborar en las medidas de mitigación que se pueden implementar en respuesta a estos ataques.

Además de Google, Amazon y Cloudflare también se enfrentaron a ataques con una intensidad de 155 y 201 millones de RPS. Los nuevos ataques superan significativamente la intensidad del anterior ataque DDoS, que batió récords, en el que los atacantes lograron generar un flujo de 47 millones de solicitudes por segundo. A modo de comparación, se estima que todo el tráfico en toda la Web es de entre 1.000 y 3.000 millones de solicitudes por segundo.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

from Linux Adictos https://ift.tt/c5G0VXI
via IFTTT