En redes informáticas , un protocolo confiable es un protocolo de comunicación que notifica al remitente si la entrega de datos a los destinatarios previstos se realizó correctamente o no. Confiabilidad es sinónimo de garantía , que es el término utilizado por la UIT y el Foro ATM .
Los protocolos confiables suelen generar más sobrecarga que los protocolos no confiables y, como resultado, funcionan más lentamente y con menos escalabilidad. Esto no suele ser un problema para los protocolos de unidifusión , pero puede convertirse en un problema para los protocolos de multidifusión confiables .
El Protocolo de Control de Transmisión (TCP), el principal protocolo utilizado en Internet , es un protocolo de unidifusión confiable; proporciona la abstracción de un flujo de bytes confiable para las aplicaciones. UDP es un protocolo poco confiable y se utiliza a menudo en juegos de computadora , transmisión de medios o en otras situaciones donde la velocidad es un problema y se puede tolerar cierta pérdida de datos debido a la naturaleza transitoria de los datos.
A menudo, un protocolo de unidifusión confiable también está orientado a la conexión . Por ejemplo, TCP está orientado a la conexión, y el identificador de circuito virtual consta de direcciones IP de origen y destino y números de puerto. Sin embargo, algunos protocolos no confiables están orientados a la conexión, como el modo de transferencia asíncrono y Frame Relay . Además, algunos protocolos sin conexión, como IEEE 802.11 , son confiables.
Basándose en los conceptos de conmutación de paquetes propuestos por Donald Davies , el primer protocolo de comunicación en ARPANET fue un procedimiento de entrega de paquetes confiable para conectar sus hosts a través de la interfaz 1822. [1] [2] Un ordenador host simplemente organizaba los datos en el formato de paquete correcto, insertaba la dirección del ordenador host de destino y enviaba el mensaje a través de la interfaz a su Procesador de mensajes de interfaz (IMP) conectado. Una vez que el mensaje se entregaba al host de destino, se enviaba un acuse de recibo al host emisor. Si la red no podía entregar el mensaje, el IMP enviaba un mensaje de error de vuelta al host emisor.
Mientras tanto, los desarrolladores de CYCLADES y de ALOHAnet demostraron que era posible construir una red informática eficaz sin proporcionar una transmisión fiable de paquetes. Esta lección fue adoptada posteriormente por los diseñadores de Ethernet .
Si una red no garantiza la entrega de paquetes, entonces es responsabilidad del host proporcionar confiabilidad detectando y retransmitiendo los paquetes perdidos. La experiencia posterior en ARPANET indicó que la red por sí misma no podía detectar de manera confiable todos los fallos en la entrega de paquetes, y esto hizo que la responsabilidad de la detección de errores recayera en el host emisor en cualquier caso. Esto condujo al desarrollo del principio de extremo a extremo , que es uno de los principios de diseño fundamentales de Internet .
Un servicio confiable es aquel que notifica al usuario si falla la entrega, mientras que uno no confiable no notifica al usuario si falla la entrega. [ cita requerida ] Por ejemplo, el Protocolo de Internet (IP) proporciona un servicio no confiable. Juntos, el Protocolo de Control de Transmisión (TCP) e IP proporcionan un servicio confiable, mientras que el Protocolo de Datagramas de Usuario (UDP) e IP proporcionan uno no confiable.
En el contexto de los protocolos distribuidos, las propiedades de confiabilidad especifican las garantías que proporciona el protocolo con respecto a la entrega de mensajes a los destinatarios previstos.
Un ejemplo de una propiedad de confiabilidad para un protocolo de unidifusión es "al menos una vez", es decir, se garantiza que al menos una copia del mensaje se entregará al destinatario.
Las propiedades de confiabilidad de los protocolos multicast pueden expresarse por destinatario (propiedades de confiabilidad simples) o pueden relacionar el hecho de la entrega o el orden de entrega entre los diferentes destinatarios (propiedades de confiabilidad fuerte). En el contexto de los protocolos multicast, las propiedades de confiabilidad fuerte expresan las garantías que proporciona el protocolo con respecto a la entrega de mensajes a diferentes destinatarios.
Un ejemplo de una propiedad de confiabilidad fuerte es la recuperación de la última copia , lo que significa que mientras al menos una copia de un mensaje permanezca disponible en cualquiera de los destinatarios, todos los demás destinatarios que no fallen también recibirán una copia. Las propiedades de confiabilidad fuerte como esta generalmente requieren que los mensajes se retransmitan o reenvíen entre los destinatarios.
Un ejemplo de una propiedad de confiabilidad más fuerte que la recuperación de la última copia es la atomicidad . La propiedad establece que si se ha entregado al menos una copia de un mensaje a un destinatario, todos los demás destinatarios recibirán una copia del mensaje. En otras palabras, cada mensaje siempre se entrega a todos los destinatarios o a ninguno.
Una de las propiedades de confiabilidad fuerte más complejas es la sincronía virtual .
La mensajería confiable es el concepto de transmisión de mensajes a través de una infraestructura no confiable y al mismo tiempo poder ofrecer ciertas garantías sobre la transmisión exitosa de los mensajes. [3] Por ejemplo, que si se entrega el mensaje, se entregue como máximo una vez, o que todos los mensajes entregados exitosamente lleguen en un orden particular.
La entrega confiable se puede contrastar con la entrega de máximo esfuerzo , donde no hay garantía de que los mensajes se entreguen rápidamente, en orden o en absoluto.
Se puede crear un protocolo de entrega confiable sobre un protocolo no confiable. Un ejemplo muy común es la superposición del Protocolo de Control de Transmisión sobre el Protocolo de Internet , una combinación conocida como TCP/IP .
Los sistemas de comunicación grupal (GCS) como IS-IS , Appia framework , JGroups o QuickSilver Scalable Multicast ofrecen propiedades de confiabilidad sólidas . QuickSilver Properties Framework es una plataforma flexible que permite expresar propiedades de confiabilidad sólidas de manera puramente declarativa, utilizando un lenguaje simple basado en reglas, y traducirlas automáticamente a un protocolo jerárquico.
Un protocolo que implementa mensajería confiable es WS-ReliableMessaging , que maneja la entrega confiable de mensajes SOAP . [4]
La función de coordinación específica del servicio ATM permite una entrega transparente y segura con AAL5 . [5] [6] [7]
IEEE 802.11 intenta proporcionar un servicio confiable para todo el tráfico. La estación emisora reenviará una trama si no recibe una trama ACK dentro de un período de tiempo predeterminado.
Sin embargo, existe un problema con la definición de confiabilidad como "entrega o notificación de falla" en computación en tiempo real . En tales sistemas, la falla en la entrega de datos en tiempo real afectará negativamente el rendimiento de los sistemas, y algunos sistemas, por ejemplo, los críticos para la seguridad , los que involucran seguridad y algunos sistemas críticos para la misión segura , deben demostrar que funcionan a un nivel mínimo especificado. Esto, a su vez, requiere que se cumpla una confiabilidad mínima especificada para la entrega de los datos críticos. Por lo tanto, en estos casos, es solo la entrega lo que importa; la notificación de la falla en la entrega mejora la falla. En sistemas de tiempo real estrictos , todos los datos deben entregarse antes de la fecha límite o se considera una falla del sistema. En sistemas de tiempo real firmes , los datos tardíos aún no tienen valor, pero el sistema puede tolerar cierta cantidad de datos tardíos o faltantes. [8] [9]
Hay una serie de protocolos que pueden abordar los requisitos en tiempo real para una entrega confiable y puntual:
MIL-STD-1553B y STANAG 3910 son ejemplos bien conocidos de tales protocolos oportunos y confiables para buses de datos de aviónica . MIL-1553 utiliza un medio compartido de 1 Mbit/s para la transmisión de datos y el control de estas transmisiones, y se usa ampliamente en sistemas de aviónica militar federados. [10] Utiliza un controlador de bus (BC) para ordenar a los terminales remotos (RT) conectados que reciban o transmitan estos datos. El BC puede, por lo tanto, garantizar que no habrá congestión y que las transferencias siempre sean oportunas. El protocolo MIL-1553 también permite reintentos automáticos que aún pueden garantizar la entrega oportuna y aumentar la confiabilidad por encima de la de la capa física. STANAG 3910, también conocido como EFABus en su uso en el Eurofighter Typhoon , es, en efecto, una versión del MIL-1553 aumentada con un bus de medios compartido de 20 Mbit/s para transferencias de datos, conservando el bus de medios compartido de 1 Mbit/s para fines de control.
El modo de transferencia asíncrono (ATM), el Ethernet conmutado dúplex completo de Avionics (AFDX) y el Ethernet activado por tiempo (TTEthernet) son ejemplos de protocolos de redes conmutadas por paquetes en los que la puntualidad y la fiabilidad de las transferencias de datos pueden garantizarse mediante la red. AFDX y TTEthernet también se basan en el estándar IEEE 802.3 Ethernet, aunque no son totalmente compatibles con él.
ATM utiliza canales virtuales orientados a conexión (VC) que tienen rutas totalmente deterministas a través de la red, y control de uso y parámetros de red (UPC/NPC), que se implementan dentro de la red, para limitar el tráfico en cada VC por separado. Esto permite que el uso de los recursos compartidos (buffers de conmutación) en la red se calcule a partir de los parámetros del tráfico que se va a transportar con antelación, es decir, en el momento del diseño del sistema. El hecho de que sean implementados por la red significa que estos cálculos siguen siendo válidos incluso cuando otros usuarios de la red se comportan de manera inesperada, es decir, transmiten más datos de los esperados. Los usos calculados se pueden comparar entonces con las capacidades de estos recursos para mostrar que, dadas las restricciones en las rutas y los anchos de banda de estas conexiones, el recurso utilizado para estas transferencias nunca se verá sobresuscrito. Por lo tanto, estas transferencias nunca se verán afectadas por la congestión y no habrá pérdidas debido a este efecto. Luego, a partir de los usos máximos previstos de los buffers de conmutación, también se puede predecir el retraso máximo a través de la red. Sin embargo, para que se demuestre la confiabilidad y puntualidad, y para que las pruebas sean tolerantes a fallas y acciones maliciosas por parte de los equipos conectados a la red, los cálculos de estos usos de recursos no pueden basarse en ningún parámetro que no sea aplicado activamente por la red, es decir, no pueden basarse en lo que se espera que hagan las fuentes de tráfico o en análisis estadísticos de las características del tráfico (ver cálculo de red ). [11]
AFDX utiliza la asignación de ancho de banda del dominio de frecuencia y el control del tráfico , lo que permite limitar el tráfico en cada enlace virtual para que se puedan predecir los requisitos de recursos compartidos y evitar la congestión de modo que se pueda demostrar que no afecta a los datos críticos. [12] Sin embargo, las técnicas para predecir los requisitos de recursos y demostrar que se evita la congestión no forman parte del estándar AFDX.
TTEthernet proporciona la latencia más baja posible en la transferencia de datos a través de la red mediante el uso de métodos de control de dominio temporal: cada transferencia activada por tiempo se programa en un momento específico para controlar la contención de los recursos compartidos y, por lo tanto, eliminar la posibilidad de congestión. Los conmutadores de la red aplican este tiempo para proporcionar tolerancia a fallas y acciones maliciosas por parte de los demás equipos conectados. Sin embargo, "los relojes locales sincronizados son el prerrequisito fundamental para la comunicación activada por tiempo". [13] Esto se debe a que las fuentes de datos críticos tendrán que tener la misma visión del tiempo que el conmutador, para poder transmitir en el momento correcto y el conmutador lo verá como correcto. Esto también requiere que la secuencia con la que se programa una transferencia crítica tenga que ser predecible tanto para la fuente como para el conmutador. Esto, a su vez, limitará el programa de transmisión a uno altamente determinista, por ejemplo, el ejecutivo cíclico .
Sin embargo, la baja latencia en la transferencia de datos a través del bus o la red no se traduce necesariamente en demoras de transporte bajas entre los procesos de aplicación que obtienen y reciben estos datos. Esto es especialmente cierto cuando las transferencias a través del bus o la red están programadas cíclicamente (como es el caso común con MIL-STD-1553B y STANAG 3910, y necesariamente con AFDX y TTEthernet) pero los procesos de aplicación no están sincronizados con este cronograma.
Tanto con AFDX como con TTEthernet, se requieren funciones adicionales de las interfaces, por ejemplo, el control de la brecha de asignación de ancho de banda de AFDX y el requisito de TTEthernet de una sincronización muy estrecha de las fuentes de datos activados por tiempo, que dificultan el uso de interfaces Ethernet estándar. Otros métodos para controlar el tráfico en la red que permitirían el uso de dichas interfaces de red estándar IEEE 802.3 son un tema de investigación actual. [14]
En casi todos los aspectos, la propuesta original de Davies, desarrollada a fines de 1965, era similar a las redes reales que se construyen hoy.
Cada sistema tiene sus propias computadoras que realizan sus propias funciones.
{{cite web}}: CS1 maint: copia archivada como título ( enlace )