Hispanopedia Wiki
Articulo de referencia

Protocolo de comunicación

Un protocolo de comunicación es un sistema de reglas que permite a dos o más entidades de un sistema de comunicaciones transmitir información . El protocolo define las reglas, l...

Hispanopedia WikiContenido en espanolLectura gratuita

Un protocolo de comunicación es un sistema de reglas que permite a dos o más entidades de un sistema de comunicaciones transmitir información . El protocolo define las reglas, la sintaxis , la semántica y la sincronización de la comunicación , así como los posibles métodos de recuperación de errores . Los protocolos pueden implementarse mediante hardware , software o una combinación de ambos. [ 1 ]

Los sistemas de comunicación utilizan formatos bien definidos para intercambiar diversos mensajes. Cada mensaje tiene un significado exacto destinado a obtener una respuesta de entre un rango de posibles respuestas predeterminadas para esa situación particular. El comportamiento especificado suele ser independiente de cómo se implemente . Los protocolos de comunicación deben ser acordados por las partes involucradas. [ 2 ] Para llegar a un acuerdo, un protocolo puede convertirse en un estándar técnico . Un lenguaje de programación describe lo mismo para los cálculos, por lo que existe una estrecha analogía entre protocolos y lenguajes de programación: los protocolos son a la comunicación lo que los lenguajes de programación son a los cálculos . [ 3 ] Una formulación alternativa afirma que los protocolos son a la comunicación lo que los algoritmos son a los cálculos . [ 4 ]

Varios protocolos suelen describir diferentes aspectos de una misma comunicación. Un conjunto de protocolos diseñados para funcionar conjuntamente se conoce como conjunto de protocolos; cuando se implementan en software, se denominan pila de protocolos .

Algunos de los protocolos de comunicación más conocidos son los relacionados con Internet , la web y el correo electrónico, desarrollados y publicados por el Grupo de Trabajo de Ingeniería de Internet (IETF) y el Consorcio World Wide Web . Muchos protocolos cableados e inalámbricos también son bien conocidos, como Ethernet, Bluetooth y, por supuesto, los estándares de telefonía móvil . Estos son gestionados principalmente por el IEEE (Instituto de Ingenieros Eléctricos y Electrónicos, por ejemplo, Ethernet). También existe la UIT-T , que gestiona los protocolos y formatos de telecomunicaciones para la red telefónica pública conmutada (PSTN). A medida que la PSTN e Internet convergen , muchos protocolos tienden a converger. La Organización Internacional de Normalización (ISO) gestiona muchos otros tipos.

Sistemas de comunicación

Historia

El primer uso del término protocolo en un contexto moderno de comunicación de datos se produce en abril de 1967 en un memorándum titulado « Un protocolo para su uso en la red de comunicaciones de datos del NPL». Bajo la dirección de Donald Davies , pionero de la conmutación de paquetes en el Laboratorio Nacional de Física del Reino Unido, fue escrito por Roger Scantlebury y Keith Bartlett para la red del NPL . Publicaron su trabajo al año siguiente. [ 5 ] [ 6 ] [ 7 ] [ 8 ]

En ARPANET , el punto de partida para la comunicación entre hosts en 1969 fue el protocolo 1822 , escrito por Bob Kahn , que definía la transmisión de mensajes a un IMP. [ 9 ] El Programa de Control de Red (NCP) para ARPANET, desarrollado por Steve Crocker y otros estudiantes de posgrado, incluido Jon Postel , se implementó por primera vez en 1970. [ 10 ] La interfaz NCP permitía que el software de aplicación se conectara a través de ARPANET mediante la implementación de protocolos de comunicación de nivel superior, un ejemplo temprano del concepto de capas de protocolo . [ 11 ]

La red CYCLADES , diseñada por Louis Pouzin a principios de la década de 1970, fue la primera en implementar el principio de extremo a extremo y hacer que los hosts fueran responsables de la entrega confiable de datos en una red de conmutación de paquetes, en lugar de que este fuera un servicio de la propia red. [ 12 ] Su equipo fue el primero en abordar el problema altamente complejo de proporcionar a las aplicaciones de usuario un servicio de circuito virtual confiable mientras se utilizaba un servicio de mejor esfuerzo , una contribución temprana a lo que sería el Protocolo de Control de Transmisión (TCP). [ 13 ] [ 14 ] [ 15 ]

Bob Metcalfe y otros en Xerox PARC esbozaron la idea de Ethernet y el PARC Universal Packet (PUP) para la interconexión de redes. [ 16 ]

Las investigaciones realizadas a principios de la década de 1970 por Bob Kahn y Vint Cerf llevaron a la formulación del Programa de Control de Transmisión (TCP). [ 17 ] Su especificación RFC 675 fue escrita por Cerf junto con Yogen Dalal y Carl Sunshine en diciembre de 1974, siendo aún un diseño monolítico en ese momento. 

El Grupo de Trabajo de Redes Internacionales acordó un estándar de datagramas sin conexión , que se presentó al CCITT en 1975 pero no fue adoptado ni por el CCITT ni por la ARPANET. [ 18 ] Investigaciones internacionales separadas, en particular el trabajo de Rémi Després , contribuyeron al desarrollo del estándar X.25 , basado en circuitos virtuales , que fue adoptado por el CCITT en 1976. [ 19 ] [ 20 ] Los fabricantes de computadoras desarrollaron protocolos propietarios como Systems Network Architecture (SNA) de IBM, DECnet de Digital Equipment Corporation y Xerox Network Systems . [ 21 ]

El software TCP se rediseñó como una pila de protocolos modular, denominada TCP/IP. Esta se instaló en SATNET en 1982 y en ARPANET en enero de 1983. El desarrollo de un conjunto completo de protocolos de Internet para 1989, tal como se describe en los RFC 1122 y 1123 , sentó las bases para el crecimiento de TCP/IP como un conjunto integral de protocolos y componente central de la incipiente Internet . [ 22 ]  

El trabajo internacional sobre un modelo de referencia para estándares de comunicación dio lugar al modelo OSI , publicado en 1984. Durante un período a finales de la década de 1980 y principios de la de 1990, ingenieros, organizaciones y naciones se polarizaron en torno a la cuestión de qué estándar , el modelo OSI o el conjunto de protocolos de Internet, daría como resultado las mejores y más robustas redes informáticas. [ 23 ] [ 24 ] [ 25 ]

Concepto

La información que se intercambia entre dispositivos a través de una red u otro medio se rige por reglas y convenciones que se pueden establecer en las especificaciones de los protocolos de comunicación. La naturaleza de la comunicación, los datos que se intercambian y cualquier comportamiento dependiente del estado , se definen mediante estas especificaciones. En los sistemas informáticos digitales, las reglas se pueden expresar mediante algoritmos y estructuras de datos . Los protocolos son a la comunicación lo que los algoritmos o los lenguajes de programación son a los cálculos. [ 3 ] [ 4 ]

Los sistemas operativos suelen contener un conjunto de procesos cooperativos que manipulan datos compartidos para comunicarse entre sí. Esta comunicación se rige por protocolos bien definidos, que pueden estar integrados en el propio código del proceso. [ 26 ] [ 27 ] En cambio, al no existir memoria compartida , los sistemas que se comunican deben hacerlo mediante un medio de transmisión compartido . La transmisión no es necesariamente fiable, y los sistemas individuales pueden utilizar hardware o sistemas operativos diferentes.

Para implementar un protocolo de red, los módulos de software del protocolo se conectan a un marco de trabajo implementado en el sistema operativo de la máquina. Este marco de trabajo implementa la funcionalidad de red del sistema operativo. [ 28 ] Cuando los algoritmos del protocolo se expresan en un lenguaje de programación portable, el software del protocolo puede hacerse independiente del sistema operativo . Los marcos de trabajo más conocidos son el modelo TCP/IP y el modelo OSI .

En el momento del desarrollo de Internet, la estratificación de abstracción había demostrado ser un enfoque de diseño exitoso tanto para compiladores como para sistemas operativos y, dadas las similitudes entre los lenguajes de programación y los protocolos de comunicación, los programas de red originalmente monolíticos se descompusieron en protocolos cooperativos. [ 29 ] Esto dio origen al concepto de protocolos en capas, que hoy en día constituye la base del diseño de protocolos. [ 30 ]

Los sistemas normalmente no utilizan un único protocolo para gestionar una transmisión. En su lugar, utilizan un conjunto de protocolos que cooperan entre sí, a veces denominado conjunto de protocolos . [ 31 ] Algunos de los conjuntos de protocolos más conocidos son TCP/IP , IPX/SPX , X.25 , AX.25 y AppleTalk .

Los protocolos se pueden organizar en grupos según su funcionalidad; por ejemplo, existe un grupo de protocolos de transporte . Las funcionalidades se asignan a las capas, y cada capa resuelve una clase distinta de problemas relacionados con, por ejemplo: funciones de interfaz de aplicación, transporte, internet y red. [ 32 ] Para transmitir un mensaje, se debe seleccionar un protocolo de cada capa. La selección del siguiente protocolo se realiza extendiendo el mensaje con un selector de protocolo para cada capa. [ 33 ]

Codificación de mensajes

Los protocolos de comunicación definen la representación de los mensajes intercambiados entre sistemas que se comunican. Los enfoques comunes para la codificación de mensajes utilizan representaciones de texto o binarias.

Basado en texto

Un protocolo basado en texto o protocolo de texto plano representa sus mensajes en un formato legible para humanos , a menudo en texto plano codificado en una codificación legible por máquina como ASCII o UTF-8 , o en formatos estructurados basados ​​en texto como el formato hexadecimal Intel , XML o JSON .

La legibilidad inmediata para el ser humano contrasta con las representaciones de mensajes binarios, que tienen ventajas inherentes para su uso en un entorno informático (como la facilidad de análisis mecánico y una mejor utilización del ancho de banda ).

Las aplicaciones de red emplean diversos métodos para encapsular datos. Un método muy común en los protocolos de Internet es la representación de mensajes basada en texto, que transmite solicitudes y respuestas como líneas de texto ASCII , terminadas por un salto de línea (y generalmente un retorno de carro). Ejemplos de protocolos que utilizan texto plano legible para sus comandos son FTP ( Protocolo de Transferencia de Archivos ), SMTP ( Protocolo Simple de Transferencia de Correo ), las primeras versiones de HTTP ( Protocolo de Transferencia de Hipertexto ) y el protocolo finger . [ 34 ]

Las representaciones de mensajes basadas en texto suelen ser más fáciles de inspeccionar e interpretar para los humanos y, por lo tanto, son adecuadas siempre que se requiera la inspección humana del contenido del protocolo, como durante la depuración y durante las primeras fases de diseño del desarrollo del protocolo.

Binario

Un protocolo binario utiliza una representación de mensaje que puede emplear todos los valores de un byte , a diferencia de una representación basada en texto, que se limita a los valores correspondientes a los caracteres de una codificación de caracteres como ASCII o UTF-8 . Las representaciones de mensajes binarios están diseñadas para ser procesadas por máquinas en lugar de ser leídas directamente por humanos. Los protocolos binarios tienen la ventaja de la concisión, lo que se traduce en una mayor velocidad de transmisión e interpretación. [ 35 ]

Las representaciones de mensajes binarios se han utilizado en estándares modernos como EbXML , HTTP/2 , HTTP/3 y EDOC . [ 36 ] Una interfaz en UML [ 37 ] también puede considerarse un protocolo binario.

Requisitos básicos

Para un protocolo, transmitir datos a través de una red es solo una parte del problema. Los datos recibidos deben evaluarse en el contexto del desarrollo de la conversación, por lo que el protocolo debe incluir reglas que describan dicho contexto. Se dice que estas reglas expresan la sintaxis de la comunicación. Otras reglas determinan si los datos son relevantes para el contexto en el que se produce el intercambio. Se dice que estas reglas expresan la semántica de la comunicación.

Los mensajes se envían y reciben en sistemas de comunicación para establecer la comunicación. Por lo tanto, los protocolos deben especificar las reglas que rigen la transmisión. En general, se debe abordar gran parte de lo siguiente: [ 38 ]

Formatos de datos para el intercambio de datos
Se intercambian cadenas de bits de mensajes digitales. Estas cadenas se dividen en campos, y cada campo contiene información relevante para el protocolo. Conceptualmente, la cadena de bits se divide en dos partes: la cabecera y la carga útil . El mensaje propiamente dicho se transporta en la carga útil. La cabecera contiene los campos relevantes para el funcionamiento del protocolo. Las cadenas de bits que superan la unidad de transmisión máxima (MTU) se dividen en fragmentos del tamaño adecuado. [ 39 ]
Formatos de direcciones para el intercambio de datos
Las direcciones se utilizan para identificar tanto al remitente como al receptor o receptores previstos. Las direcciones se incluyen en la cabecera de las cadenas de bits, lo que permite a los receptores determinar si las cadenas de bits son relevantes y deben procesarse o ignorarse. Una conexión entre un remitente y un receptor se puede identificar mediante un par de direcciones (dirección del remitente, dirección del receptor) . Generalmente, algunos valores de dirección tienen significados especiales. Una dirección compuesta únicamente por unos podría interpretarse como una dirección a todas las estaciones de la red, por lo que enviar a esta dirección resultaría en una difusión en la red local. Las reglas que describen el significado del valor de la dirección se denominan colectivamente esquema de direccionamiento . [ 40 ]
Mapeo de direcciones
En ocasiones, los protocolos necesitan asignar direcciones de un esquema a direcciones de otro esquema. Por ejemplo, para traducir una dirección IP lógica especificada por la aplicación a una dirección MAC Ethernet. Esto se conoce como asignación de direcciones . [ 41 ]
Enrutamiento
Cuando los sistemas no están conectados directamente, los sistemas intermediarios a lo largo de la ruta hacia el o los receptores previstos deben reenviar los mensajes en nombre del remitente. En Internet, las redes se conectan mediante enrutadores. La interconexión de redes a través de enrutadores se denomina interconexión de redes .
Detección de errores de transmisión
La detección de errores es necesaria en redes donde es posible la corrupción de datos. En un enfoque común, se agrega un CRC del área de datos al final de los paquetes, lo que permite al receptor detectar diferencias causadas por la corrupción. El receptor rechaza los paquetes que presentan diferencias en el CRC y gestiona su retransmisión. [ 42 ]
Expresiones de gratitud
La confirmación de la correcta recepción de los paquetes es necesaria para la comunicación orientada a la conexión . Los receptores envían confirmaciones a sus respectivos remitentes. [ 43 ]
Pérdida de información: tiempos de espera y reintentos.
Los paquetes pueden perderse en la red o retrasarse durante el tránsito. Para solucionar esto, según algunos protocolos, el emisor puede esperar una confirmación de recepción correcta por parte del receptor dentro de un cierto tiempo. Por lo tanto, en caso de que se agote el tiempo de espera , el emisor puede necesitar retransmitir la información. [ a ] En caso de una interrupción permanente del enlace, la retransmisión no tiene efecto, por lo que el número de retransmisiones es limitado. Superar el límite de reintentos se considera un error. [ 44 ]
Dirección del flujo de información
Es necesario abordar la direccionalidad si las transmisiones solo pueden ocurrir en una dirección a la vez, como en enlaces semidúplex , o desde un solo remitente a la vez, como en un medio compartido . Esto se conoce como control de acceso al medio . Deben establecerse medidas para gestionar el caso de colisión o contención, donde dos partes transmiten o desean transmitir simultáneamente. [ 45 ]
Control de secuencia
Si las cadenas de bits largas se dividen en fragmentos y luego se envían individualmente por la red, estos fragmentos pueden perderse o retrasarse o, en algunos tipos de redes, tomar rutas diferentes hacia su destino. Como resultado, los fragmentos pueden llegar fuera de secuencia. Las retransmisiones pueden generar fragmentos duplicados. Al marcar los fragmentos con información de secuencia en el remitente, el receptor puede determinar qué se perdió o duplicó, solicitar las retransmisiones necesarias y reconstruir el mensaje original. [ 46 ]
Control de flujo
El control de flujo es necesario cuando el emisor transmite más rápido de lo que el receptor o el equipo de red intermedio pueden procesar las transmisiones. El control de flujo se puede implementar mediante el envío de mensajes del receptor al emisor. [ 47 ]
Hacer cola
Los procesos comunicantes o las máquinas de estado emplean colas (o "búferes"), generalmente colas FIFO, para gestionar los mensajes en el orden en que se envían, y a veces pueden tener varias colas con diferente priorización.

Diseño de protocolo

Se han aplicado principios de ingeniería de sistemas para crear un conjunto de principios comunes de diseño de protocolos de red. El diseño de protocolos complejos suele implicar su descomposición en protocolos más simples que cooperan entre sí. Este conjunto de protocolos cooperativos se denomina a veces familia de protocolos o conjunto de protocolos [ 31 ] dentro de un marco conceptual.

Los sistemas de comunicación operan de forma concurrente. Un aspecto importante de la programación concurrente es la sincronización del software para recibir y transmitir mensajes de comunicación en la secuencia adecuada. La programación concurrente ha sido tradicionalmente un tema en los textos de teoría de sistemas operativos. [ 48 ] La verificación formal parece indispensable porque los programas concurrentes son conocidos por los errores ocultos y sofisticados que contienen. [ 49 ] Un enfoque matemático para el estudio de la concurrencia y la comunicación se denomina procesos secuenciales comunicantes (CSP). [ 50 ] La concurrencia también se puede modelar utilizando máquinas de estados finitos , como las máquinas de Mealy y Moore . Las máquinas de Mealy y Moore se utilizan como herramientas de diseño en sistemas electrónicos digitales que se encuentran en forma de hardware utilizado en telecomunicaciones o dispositivos electrónicos en general. [ 51 ]

La literatura presenta numerosas analogías entre la comunicación informática y la programación. Por analogía, un mecanismo de transferencia de un protocolo es comparable a una unidad central de procesamiento (CPU). El marco de trabajo introduce reglas que permiten al programador diseñar protocolos que cooperan entre sí de forma independiente.

Capas

Figura 2. Protocolos en relación con el esquema de capas de Internet.
El modelo TCP/IP o esquema de capas de Internet y su relación con algunos protocolos comunes.

En el diseño de protocolos modernos, estos se estructuran en capas para formar una pila de protocolos. La estratificación es un principio de diseño que divide la tarea de diseño del protocolo en pasos más pequeños, cada uno de los cuales cumple una función específica e interactúa con las demás partes del protocolo solo de maneras limitadas y bien definidas. La estratificación permite diseñar y probar las partes de un protocolo sin una explosión combinatoria de casos, manteniendo así cada diseño relativamente simple.

Los protocolos de comunicación utilizados en Internet están diseñados para funcionar en entornos diversos y complejos. Los protocolos de Internet están diseñados para ser simples y modulares, y se ajustan a una jerarquía general de capas funcionales definidas en el conjunto de protocolos de Internet . [ 52 ] Los dos primeros protocolos cooperativos, el Protocolo de Control de Transmisión (TCP) y el Protocolo de Internet (IP), surgieron de la descomposición del Programa de Control de Transmisión original, un protocolo de comunicación monolítico, en este conjunto de comunicación por capas.

El modelo OSI se desarrolló internacionalmente basándose en la experiencia con redes anteriores a Internet, como modelo de referencia para la comunicación general, con reglas mucho más estrictas de interacción de protocolos y una estratificación rigurosa.

Por lo general, el software de aplicación se basa en una sólida capa de transporte de datos. Esta capa se sustenta en un mecanismo de entrega y enrutamiento de datagramas que, en Internet, suele ser sin conexión . El reenvío de paquetes a través de redes se produce sobre otra capa que solo involucra tecnologías de enlace de red, a menudo específicas de ciertas tecnologías de capa física, como Ethernet . La arquitectura por capas permite intercambiar tecnologías cuando sea necesario; por ejemplo, los protocolos suelen apilarse en una configuración de túnel para conectar redes diferentes. Por ejemplo, IP puede tunelizarse a través de una red de Modo de Transferencia Asíncrona (ATM).

Capas de protocolo

Figura 3. Flujos de mensajes mediante un conjunto de protocolos.
Figura 3. Flujos de mensajes mediante un conjunto de protocolos. Los bucles negros muestran los bucles de mensajería reales, mientras que los bucles rojos representan la comunicación efectiva entre capas habilitada por las capas inferiores.

La estratificación de protocolos constituye la base del diseño de protocolos. [ 30 ] Permite la descomposición de protocolos complejos e individuales en protocolos cooperativos más simples. [ 52 ] Cada capa de protocolo resuelve una clase distinta de problemas de comunicación. En conjunto, las capas conforman un esquema o modelo de estratificación.

Los cálculos se ocupan de algoritmos y datos; la comunicación implica protocolos y mensajes; por lo tanto, el análogo de un diagrama de flujo de datos es algún tipo de diagrama de flujo de mensajes. [ 4 ] Para visualizar la estratificación de protocolos y los conjuntos de protocolos, en la figura 3 se muestra un diagrama de los flujos de mensajes dentro y entre dos sistemas, A y B. Ambos sistemas, A y B, utilizan el mismo conjunto de protocolos. Los flujos verticales (y protocolos) son dentro del sistema y los flujos horizontales de mensajes (y protocolos) son entre sistemas. Los flujos de mensajes se rigen por reglas y los formatos de datos están especificados por protocolos. Las líneas azules marcan los límites de las capas de protocolo (horizontales).

Capas de software

Figura 5: Estructura de protocolos y software. Los módulos de software que implementan los protocolos están representados por cubos. El flujo de información entre los módulos está representado por flechas. Las dos flechas rojas horizontales superiores son virtuales. Las líneas azules marcan los límites de las capas.

El software que da soporte a los protocolos tiene una organización por capas, y su relación con la organización de los protocolos por capas se muestra en la figura 5.

Para enviar un mensaje en el sistema A, el módulo de software de la capa superior interactúa con el módulo inmediatamente inferior y le entrega el mensaje para su encapsulación. El módulo inferior completa los datos de la cabecera de acuerdo con el protocolo que implementa e interactúa con el módulo inferior, que envía el mensaje a través del canal de comunicación al módulo inferior del sistema B. En el sistema receptor B ocurre lo contrario, por lo que finalmente el mensaje se entrega en su formato original al módulo superior del sistema B. [ 53 ]

La traducción de programas se divide en subproblemas. Como resultado, el software de traducción también está estructurado en capas, lo que permite diseñar las capas de software de forma independiente. El mismo enfoque se observa en la estructura de capas TCP/IP. [ 54 ]

Los módulos situados por debajo de la capa de aplicación se consideran generalmente parte del sistema operativo. El intercambio de datos entre estos módulos es mucho menos costoso que el intercambio de datos entre un programa de aplicación y la capa de transporte. El límite entre la capa de aplicación y la capa de transporte se denomina límite del sistema operativo. [ 55 ]

Capas estrictas

Adherirse estrictamente a un modelo de capas, una práctica conocida como estratificación estricta, no siempre es el mejor enfoque para las redes. [ 56 ] La estratificación estricta puede tener un impacto negativo en el rendimiento de una implementación. [ 57 ]

Aunque el uso de la estratificación de protocolos es hoy omnipresente en el campo de las redes informáticas, históricamente ha sido criticado por muchos investigadores [ 58 ] ya que abstraer la pila de protocolos de esta manera puede hacer que una capa superior duplique la funcionalidad de una capa inferior, un ejemplo claro es la recuperación de errores tanto a nivel de enlace como de extremo a extremo. [ 59 ]

Patrones de diseño

Los problemas recurrentes en el diseño e implementación de protocolos de comunicación pueden abordarse mediante patrones de diseño de software . [ 60 ] [ 61 ] [ 62 ] [ 63 ] [ 64 ]

Especificación formal

Los métodos formales más populares para describir la sintaxis de la comunicación son la Notación de Sintaxis Abstracta Uno (un estándar ISO ) y la forma Backus-Naur aumentada (un estándar IETF ).

Los modelos de máquinas de estados finitos se utilizan para describir formalmente las posibles interacciones del protocolo. [ 65 ] [ 66 ] y máquinas de estados finitos comunicantes [ 67 ]

Desarrollo de protocolos

Para que se produzca la comunicación, es necesario seleccionar protocolos. Las reglas pueden expresarse mediante algoritmos y estructuras de datos. La independencia del hardware y del sistema operativo se ve reforzada al expresar los algoritmos en un lenguaje de programación portable. La independencia del código fuente de la especificación proporciona una mayor interoperabilidad.

Los estándares de protocolo suelen crearse obteniendo la aprobación o el respaldo de una organización de normalización, que inicia el proceso. Los miembros de la organización se comprometen voluntariamente a cumplir con el resultado del trabajo. A menudo, estos miembros controlan una gran cuota de mercado relevante para el protocolo y, en muchos casos, los estándares son obligatorios por ley o por el gobierno, ya que se consideran de interés público importante; por lo tanto, obtener la aprobación puede ser crucial para el protocolo.

La necesidad de estándares de protocolo

La necesidad de estándares de protocolo se evidencia al observar lo sucedido con el protocolo de Comunicaciones Binarias Síncronas (BSC), inventado por IBM . BSC es un protocolo de nivel de enlace primitivo utilizado para conectar dos nodos separados. Originalmente no estaba diseñado para usarse en una red multinodo, pero su uso reveló varias deficiencias. Ante la falta de estandarización, fabricantes y organizaciones se sintieron libres de modificar el protocolo, creando versiones incompatibles en sus redes. En algunos casos, esto se hizo deliberadamente para disuadir a los usuarios de utilizar equipos de otros fabricantes. Existen más de 50 variantes del protocolo bi-sync original. Cabe suponer que un estándar habría evitado al menos parte de esta situación. [ 28 ]

En algunos casos, los protocolos logran dominar el mercado sin pasar por un proceso de estandarización. Estos protocolos se denominan estándares de facto . Los estándares de facto son comunes en mercados emergentes, nichos de mercado o mercados monopolizados ( u oligopolizados ). Pueden ejercer un control muy negativo sobre un mercado, especialmente cuando se utilizan para ahuyentar a la competencia. Desde una perspectiva histórica, la estandarización debería considerarse una medida para contrarrestar los efectos negativos de los estándares de facto. Existen excepciones positivas; un sistema operativo estándar de facto como Linux no ejerce este control negativo sobre su mercado porque su código fuente se publica y mantiene de forma abierta, lo que fomenta la competencia.

Organizaciones de normalización

Algunas de las organizaciones de normalización relevantes para los protocolos de comunicación son la Organización Internacional de Normalización (ISO), la Unión Internacional de Telecomunicaciones (UIT), el Instituto de Ingenieros Eléctricos y Electrónicos (IEEE) y el Grupo de Trabajo de Ingeniería de Internet (IETF). El IETF mantiene los protocolos utilizados en Internet. El IEEE controla muchos protocolos de software y hardware en la industria electrónica para dispositivos comerciales y de consumo. La UIT es una organización coordinadora de ingenieros de telecomunicaciones que diseña la red telefónica pública conmutada (PSTN), así como muchos sistemas de radiocomunicación . Para la electrónica marina , se utilizan los estándares NMEA . El Consorcio World Wide Web (W3C) produce protocolos y estándares para tecnologías web.

Se supone que las organizaciones internacionales de normalización son más imparciales que las organizaciones locales, que suelen tener en cuenta sus propios intereses nacionales o comerciales. Además, realizan investigación y desarrollo para las normas del futuro. En la práctica, las organizaciones de normalización mencionadas cooperan estrechamente entre sí. [ 68 ]

En el desarrollo de un protocolo pueden participar varios organismos de normalización. Si no están coordinados, el resultado pueden ser múltiples definiciones incompatibles del protocolo o múltiples interpretaciones incompatibles de los mensajes; es posible que no se respeten invariantes importantes en una definición (por ejemplo, que los valores de tiempo de vida disminuyan monótonamente para evitar bucles de enrutamiento estables ). [ 69 ]

El proceso de estandarización

En la ISO, el proceso de normalización comienza con la creación de un subcomité. Este subcomité publica borradores y documentos de debate para las partes interesadas (incluidos otros organismos de normalización) con el fin de generar debate y comentarios. Esto suscita numerosas preguntas, debates y, por lo general, desacuerdos. Estos comentarios se tienen en cuenta y el subcomité elabora una propuesta preliminar . Tras recibir comentarios, realizar modificaciones y llegar a acuerdos, la propuesta se convierte en un borrador de norma internacional y, finalmente, en una norma internacional . Las normas internacionales se reeditan periódicamente para corregir deficiencias y reflejar la evolución de las opiniones sobre el tema. [ 70 ]

Estandarización OSI

Una lección aprendida de ARPANET , el predecesor de Internet, fue que los protocolos necesitan un marco para funcionar. Por lo tanto, es importante desarrollar un marco de propósito general y a prueba de futuro, adecuado para protocolos estructurados (como los protocolos en capas) y su estandarización. Esto evitaría estándares de protocolo con funcionalidades superpuestas y permitiría una definición clara de las responsabilidades de un protocolo en los diferentes niveles (capas). [ 72 ] Esto dio origen al modelo de interconexión de sistemas abiertos (modelo OSI), que se utiliza como marco para el diseño de protocolos y servicios estándar que se ajustan a las distintas especificaciones de las capas. [ 73 ]

En el modelo OSI, se supone que los sistemas que se comunican están conectados por un medio físico subyacente que proporciona un mecanismo de transmisión básico. Las capas superiores están numeradas. Cada capa proporciona servicios a la capa superior utilizando los servicios de la capa inmediatamente inferior. La capa superior proporciona servicios al proceso de la aplicación. Las capas se comunican entre sí mediante una interfaz, denominada punto de acceso de servicio . Las capas correspondientes en cada sistema se denominan entidades pares . Para comunicarse, dos entidades pares en una capa determinada utilizan un protocolo específico de esa capa, que se implementa utilizando los servicios de la capa inferior. [ 74 ] Para cada capa, existen dos tipos de estándares: estándares de protocolo que definen cómo se comunican las entidades pares en una capa determinada, y estándares de servicio que definen cómo una capa determinada se comunica con la capa superior.

En el modelo OSI, las capas y su funcionalidad son (de la capa más alta a la más baja):

  • La capa de aplicación puede proporcionar los siguientes servicios a los procesos de la aplicación: identificación de los interlocutores previstos, establecimiento de la autorización necesaria para comunicarse, determinación de la disponibilidad y autenticación de los interlocutores, acuerdo sobre los mecanismos de privacidad para la comunicación, acuerdo sobre la responsabilidad de la recuperación de errores y los procedimientos para garantizar la integridad de los datos , sincronización entre los procesos de aplicación que cooperan, identificación de cualquier restricción de sintaxis (por ejemplo, conjuntos de caracteres y estructuras de datos), determinación del coste y la calidad aceptable del servicio, selección de la disciplina de diálogo, incluidos los procedimientos de inicio y cierre de sesión requeridos. [ 75 ]
  • La capa de presentación puede proporcionar los siguientes servicios a la capa de aplicación: una solicitud para el establecimiento de una sesión, transferencia de datos, negociación de la sintaxis que se utilizará entre las capas de aplicación, cualquier transformación de sintaxis necesaria, formato y transformaciones de propósito especial (por ejemplo, compresión y cifrado de datos). [ 76 ]
  • La capa de sesión puede proporcionar los siguientes servicios a la capa de presentación: establecimiento y liberación de conexiones de sesión, intercambio de datos normal y acelerado, un servicio de cuarentena que permite a la entidad de presentación emisora ​​instruir a la entidad de sesión receptora para que no le envíe datos sin permiso, gestión de interacciones para que las entidades de presentación puedan controlar a quién le corresponde realizar ciertas funciones de control, resincronización de una conexión de sesión, notificación de excepciones irrecuperables a la entidad de presentación. [ 77 ]
  • La capa de transporte proporciona una transferencia de datos fiable y transparente de forma rentable, según lo requiera la calidad de servicio seleccionada. Puede admitir la multiplexación de varias conexiones de transporte en una única conexión de red o dividir una conexión de transporte en varias conexiones de red. [ 78 ]
  • La capa de red se encarga de la configuración, el mantenimiento y la liberación de las rutas de red entre las entidades de transporte. Cuando se requieren repetidores, esta capa proporciona las funciones de enrutamiento y retransmisión. La calidad del servicio se negocia entre las entidades de red y de transporte en el momento en que se establece la conexión. Esta capa también es responsable del control de la congestión de la red . [ 79 ]
  • La capa de enlace de datos se encarga de la configuración, el mantenimiento y la liberación de las conexiones de enlace de datos. Los errores que se producen en la capa física se detectan y pueden corregirse. Los errores se notifican a la capa de red. El intercambio de unidades de enlace de datos (incluido el control de flujo) se define en esta capa. [ 80 ]
  • La capa física describe detalles como las características eléctricas de la conexión física, las técnicas de transmisión utilizadas y la configuración, el mantenimiento y la limpieza de las conexiones físicas. [ 81 ]

A diferencia del esquema de capas TCP/IP , que asume una red sin conexión, RM/OSI asumió una red orientada a la conexión. [ 82 ] Las redes orientadas a la conexión son más adecuadas para redes de área amplia y las redes sin conexión son más adecuadas para redes de área local. La comunicación orientada a la conexión requiere algún tipo de sesión y circuitos (virtuales), de ahí la capa de sesión (que falta en el modelo TCP/IP). Los miembros constituyentes de ISO se preocupaban principalmente por las redes de área amplia, por lo que el desarrollo de RM/OSI se centró en las redes orientadas a la conexión y las redes sin conexión se mencionaron por primera vez en un apéndice de RM/OSI [ 83 ] [ 84 ] y posteriormente se incorporaron en una actualización de RM/OSI. [ 85 ]

En aquel momento, la IETF tuvo que lidiar con esto y con el hecho de que Internet necesitaba protocolos que simplemente no existían. Como resultado, la IETF desarrolló su propio proceso de estandarización basado en "consenso aproximado y código ejecutable". [ 86 ] El proceso de estandarización se describe en la RFC 2026 . 

Actualmente, la IETF se ha convertido en una organización de estandarización para los protocolos utilizados en Internet. El modelo RM/OSI ha ampliado su aplicación para incluir servicios sin conexión, lo que ha permitido que tanto TCP como IP se conviertan en estándares internacionales.

Imagen de cable

La imagen de la red de un protocolo es la información que un observador no participante puede extraer al observar los mensajes del protocolo, incluyendo tanto la información explícitamente definida por el protocolo como las inferencias realizadas por el observador. [ 87 ] Los metadatos del protocolo sin cifrar son una fuente que conforma la imagen de la red, y los canales laterales, incluyendo la sincronización de paquetes, también contribuyen. [ 88 ] Diferentes observadores con diferentes perspectivas pueden ver diferentes imágenes de la red. [ 89 ] La imagen de la red es relevante para la privacidad del usuario final y la extensibilidad del protocolo. [ 90 ]

Si alguna parte de la imagen de la red no está autenticada criptográficamente , está sujeta a modificación por parte de intermediarios (es decir, dispositivos intermedios ), lo que puede influir en el funcionamiento del protocolo. [ 88 ] Incluso si está autenticada, si una parte no está cifrada, formará parte de la imagen de la red, y los intermediarios pueden intervenir dependiendo de su contenido (por ejemplo, descartando paquetes con indicadores específicos). Las señales destinadas deliberadamente al consumo de intermediarios pueden dejarse autenticadas pero sin cifrar. [ 91 ]

La imagen del cable puede diseñarse deliberadamente, cifrando partes que los intermediarios no deberían poder observar y proporcionando señales para lo que sí deberían poder. [ 92 ] Si las señales proporcionadas se desacoplan de la operación del protocolo, pueden volverse poco confiables. [ 93 ] La administración de redes benignas y la investigación se ven afectadas por el cifrado de metadatos; los diseñadores de protocolos deben equilibrar la observabilidad para la operatividad y la investigación con la resistencia a la osificación y la privacidad del usuario final. [ 90 ] El IETF anunció en 2014 que había determinado que la vigilancia a gran escala de las operaciones del protocolo es un ataque debido a la capacidad de inferir información de la imagen del cable sobre los usuarios y su comportamiento, [ 94 ] y que el IETF "trabajaría para mitigar la vigilancia generalizada" en sus diseños de protocolos; [ 95 ] esto no se había hecho sistemáticamente con anterioridad. [ 95 ] El Consejo de Arquitectura de Internet recomendó en 2023 que la divulgación de información por parte de un protocolo a la red debería ser intencional, [ 96 ] realizada con el acuerdo tanto del receptor como del remitente, [ 97 ] autenticada en la medida posible y necesaria, [ 98 ] actuada solo en la medida de su confiabilidad, [ 99 ] y minimizada y proporcionada a un número mínimo de entidades. [ 100 ] [ 101 ] La ingeniería de la imagen de la red y el control de las señales que se proporcionan a los elementos de la red era un "campo en desarrollo" en 2023, según el IAB. [ 102 ]

Osificación

La osificación de protocolos es la pérdida de flexibilidad, extensibilidad y capacidad de evolución de los protocolos de red . Esto se debe principalmente a los dispositivos intermedios que son sensibles a la representación del protocolo en la red y que pueden interrumpir o interferir con mensajes válidos que el dispositivo intermedio no reconoce correctamente. [ 103 ] Esto constituye una violación del principio de extremo a extremo . [ 104 ] Entre las causas secundarias se incluye la inflexibilidad en las implementaciones de protocolos en los puntos finales. [ 105 ]

La osificación es un problema importante en el diseño y despliegue de protocolos de Internet , ya que puede impedir el despliegue de nuevos protocolos o extensiones en Internet, o imponer restricciones al diseño de nuevos protocolos; estos pueden tener que encapsularse en un protocolo ya desplegado o imitar la estructura de otro protocolo. [ 106 ] Debido a la osificación, el Protocolo de Control de Transmisión (TCP) y el Protocolo de Datagramas de Usuario (UDP) son las únicas opciones prácticas para protocolos de transporte en Internet, [ 107 ] y el propio TCP se ha osificado significativamente, lo que dificulta la extensión o modificación del protocolo. [ 108 ]

Los métodos recomendados para prevenir la osificación incluyen el cifrado de los metadatos del protocolo, [ 109 ] y asegurar que se ejerciten los puntos de extensión y se muestre la variabilidad de la imagen del cable en la medida de lo posible; [ 110 ] remediar la osificación existente requiere coordinación entre los participantes del protocolo. [ 111 ] QUIC es el primer protocolo de transporte de la IETF que se ha diseñado con propiedades antiosificación deliberadas. [ 87 ]

Taxonomías

Los esquemas de clasificación de protocolos suelen centrarse en el dominio de uso y la función. Como ejemplo de dominio de uso, los protocolos orientados a la conexión y los protocolos sin conexión se utilizan en redes orientadas a la conexión y redes sin conexión, respectivamente. Un ejemplo de función es un protocolo de tunelización , que se utiliza para encapsular paquetes en un protocolo de alto nivel para que puedan transmitirse a través de un sistema de transporte utilizando dicho protocolo.

Un esquema de capas combina tanto la función como el dominio de uso. Los esquemas de capas dominantes son los desarrollados por la IETF y la ISO. A pesar de que los supuestos subyacentes de los esquemas de capas son lo suficientemente diferentes como para justificar su distinción, es una práctica común compararlos relacionando protocolos comunes con las capas de ambos esquemas. [ 112 ] El esquema de capas de la IETF se denomina estratificación de Internet o estratificación TCP/IP . El esquema de capas de la ISO se denomina modelo OSI o estratificación ISO .

En la configuración de equipos de red, se suele establecer una distinción terminológica: el término «protocolo» se refiere estrictamente a la capa de transporte, mientras que el término «servicio» se refiere a los protocolos que utilizan un protocolo para el transporte. En el caso común de TCP y UDP, los servicios se distinguen por números de puerto. El cumplimiento de estos números de puerto es voluntario, por lo que en los sistemas de inspección de contenido, el término « servicio» se refiere estrictamente a los números de puerto, y el término « aplicación» se utiliza a menudo para referirse a los protocolos identificados mediante firmas de inspección.

Véase también

Notas

  1. ↑ La falta de recepción de una confirmación indica que se perdió la transmisión original o la confirmación. El remitente no tiene forma de distinguir entre estos casos y, por lo tanto, para garantizar la recepción de todos los datos, debe asumir, por precaución, que se perdió la transmisión original.

Referencias

  1. ↑ US 7529565 , Hilpisch, Robert E.; Duchscher, Rob y Seel, Mark et al., "Protocolo de comunicación inalámbrica", publicado el 5 de mayo de 2009, asignado a Starkey Laboratories Inc. y Oticon AS. 
  2. ↑ Protocolo , Encyclopædia Britannica , archivado del original el 12 de septiembre de 2012 , consultado el 24 de septiembre de 2012.
  3. 1 2 Comer 2000, Sec. 11.2 - La necesidad de múltiples protocolos, pág. 177, "Ellos (los protocolos) son a la comunicación lo que los lenguajes de programación son a la computación"
  4. 1 2 3 Comer 2000, Sec. 1.3 - Servicios de Internet, pág. 3, "Los protocolos son a la comunicación lo que los algoritmos son a la computación"
  5. ↑ Naughton, John (24 de septiembre de 2015). Breve historia del futuro . Orion. ISBN 978-1-4746-0277-8.
  6. ↑ Campbell-Kelly, Martin (julio de 1987). "Comunicaciones de datos en el Laboratorio Nacional de Física (1965-1975)" . IEEE Annals of the History of Computing . 9 (3): 221– 247. Bibcode : 1987IAHC....9c.221C . doi : 10.1109/MAHC.1987.10023 .
  7. ↑ Pelkey, James L. "6.1 La subred de comunicaciones: BBN 1969" . Capitalismo empresarial e innovación: una historia de las comunicaciones informáticas 1968-1988 . Como recuerda Kahn: ... las contribuciones de Paul Baran... También creo que Paul estaba motivado casi enteramente por consideraciones de voz. Si miras lo que escribió, hablaba de conmutadores que eran electrónica de bajo costo. La idea de colocar computadoras potentes en esos lugares no se le había ocurrido como algo rentable. Así que la idea de conmutadores informáticos estaba ausente. La noción de protocolos no existía en ese momento. Y la idea de las comunicaciones de computadora a computadora era realmente una preocupación secundaria.
  8. ↑ Kleinrock, L. (1978). "Principios y lecciones en comunicaciones de paquetes". Actas del IEEE . 66 (11): 1320– 1329. Bibcode : 1978IEEEP..66.1320K . doi : 10.1109/PROC.1978.11143 . ISSN 0018-9219 . Paul Baran... se centró en los procedimientos de enrutamiento y en la supervivencia de los sistemas de comunicación distribuidos en un entorno hostil, pero no se concentró en la necesidad de compartir recursos en su forma actual; de hecho, el concepto de conmutador de software no estaba presente en su trabajo. 
  9. ↑ Procesador de mensajes de interfaz: Especificaciones para la interconexión de un host y un IMP (PDF) (Informe). Bolt Beranek and Newman (BBN). Informe n.° 1822.
  10. ↑ LIBROS, ALTA DEFINICIÓN. UGC -NET/JRF/SET PTP y Guía de Aptitud para la Enseñanza y la Investigación: UGC -NET Por HD . Libros de Alta Definición.
  11. ↑ "NCP – Programa de Control de Red" . Internet en Vivo . Archivado del original el 7 de agosto de 2022. Consultado el 8 de octubre de 2022 .
  12. ↑ Bennett, Richard (septiembre de 2009). "Diseñado para el cambio: argumentos de extremo a extremo, innovación en Internet y el debate sobre la neutralidad de la red" (PDF) . Fundación de Tecnologías de la Información e Innovación. págs. 7, 11. Recuperado el 11 de septiembre de 2017 . 
  13. ↑ Abbate, Janet (2000). Inventando Internet . MIT Press. págs. 124–127 . ISBN  978-0-262-51115-5De hecho , CYCLADES, a diferencia de ARPANET, había sido diseñado explícitamente para facilitar la interconexión de redes; podía, por ejemplo, manejar diferentes formatos y diferentes niveles de servicio.
  14. ↑ Kim, Byung-Keun (2005). La internacionalización de Internet: la coevolución de la influencia y la tecnología . Edward Elgar. pp. 51–55 . ISBN  1845426754Además de la red NPL y ARPANET, CYCLADES, una red experimental académica y de investigación, también desempeñó un papel importante en el desarrollo de las tecnologías de redes informáticas .
  15. ↑ «El quinto hombre de internet» . The Economist . 30 de noviembre de 2013. ISSN 0013-0613 . Consultado el 22 de abril de 2020. A principios de la década de 1970 , el Sr. Pouzin creó una innovadora red de datos que conectaba ubicaciones en Francia, Italia y Gran Bretaña. Su simplicidad y eficiencia allanaron el camino para una red que podría conectar no solo docenas de máquinas, sino millones de ellas. Captó la imaginación del Dr. Cerf y el Dr. Kahn, quienes incluyeron aspectos de su diseño en los protocolos que ahora impulsan internet. 
  16. ↑ Moschovitis 1999 , pág. 78-9 
  17. ↑ Cerf, V.; Kahn, R. (mayo de 1974). "Un protocolo para la intercomunicación de redes de paquetes" (PDF) . IEEE Transactions on Communications . 22 (5): 637– 648. Bibcode : 1974ITCom..22..637C . doi : 10.1109/TCOM.1974.1092259 . ISSN 1558-0857 . Archivado (PDF) del original el 6 de enero de 2017. Recuperado el 23 de febrero de 2020. Los autores desean agradecer a varios colegas por sus útiles comentarios durante las primeras discusiones sobre protocolos de redes internacionales, especialmente a R. Metcalfe, R. Scantlebury, D. Walden y H. Zimmerman; D. Davies y L. Pouzin, quienes comentaron de manera constructiva sobre los problemas de fragmentación y contabilidad; y S. Crocker, quien comentó sobre la creación y destrucción de asociaciones. 
  18. ↑ McKenzie, Alexander (enero de 2011). "INWG y la concepción de Internet: un relato de primera mano". IEEE Annals of the History of Computing . 33 (1): 66– 71. Bibcode : 2011IAHC...33a..66M . doi : 10.1109/MAHC.2011.9 . ISSN 1934-1547 . 
  19. ↑ Schwartz, Mischa (noviembre de 2010). "Circuitos virtuales X.25 - TRANSPAC en Francia - Redes de datos pre-Internet [Historia de las comunicaciones]". IEEE Communications Magazine . 48 (11): 40– 46. doi : 10.1109/MCOM.2010.5621965 . ISSN 1558-1896 . 
  20. ↑ Rybczynski, Tony (diciembre de 2009). "Comercialización de la conmutación de paquetes (1975-1985): una perspectiva canadiense [Historia de las comunicaciones]". IEEE Communications Magazine . 47 (12): 26–31 . doi : 10.1109/MCOM.2009.5350364 . ISSN 1558-1896 . 
  21. ↑ La prehistoria "oculta" de las redes de investigación europeas . Trafford Publishing. pág. 354. ISBN  978-1-4669-3935-6.
  22. ↑ "Protocolo de Internet TCP/IP" . Internet en constante evolución . Archivado del original el 1 de septiembre de 2022. Consultado el 8 de octubre de 2022 .
  23. ↑ Andrew L. Russell (30 de julio de 2013). "OSI: Internet que no fue" . IEEE Spectrum . Vol. 50, n.º 8.  
  24. ↑ Russell, Andrew L. «Consenso aproximado y código en ejecución: la guerra de estándares entre Internet y OSI» (PDF) . Anales de la historia de la computación del IEEE. Archivado (PDF) del original el 17 de noviembre de 2019. Consultado el 23 de febrero de 2020 .
  25. ↑ "Guerras de estándares" (PDF) . 2006. Archivado (PDF) del original el 24 de febrero de 2021. Recuperado el 23 de febrero de 2020 .
  26. ↑ Ben-Ari 1982, capítulo 2 - La abstracción de la programación concurrente, págs. 18-19, afirma lo mismo.
  27. ↑ Ben-Ari 1982, Sección 2.7 - Resumen, pág. 27, resume la abstracción de programación concurrente.
  28. 1 2 Marsden 1986, Sección 6.1 - ¿Por qué son necesarios los estándares?, págs. 64-65, utiliza BSC como ejemplo para mostrar la necesidad tanto de protocolos estándar como de un marco estándar.
  29. ↑ Comer 2000, Sec. 11.2 - La necesidad de múltiples protocolos, pág. 177, explica esto estableciendo analogías entre la comunicación informática y los lenguajes de programación.
  30. 1 2 Sec. 11.10 - La desventaja de la estratificación, pág. 192, afirma: la estratificación constituye la base del diseño de protocolos.
  31. 1 2 Comer 2000, Sect. 11.2 - La necesidad de múltiples protocolos, pág. 177, afirma lo mismo.
  32. ↑ Comer 2000, Sec. 11.3 - Las capas conceptuales del software de protocolo, pág. 178, "Cada capa se responsabiliza de manejar una parte del problema".
  33. ↑ Comer 2000, Sect. 11.11 - La idea básica detrás de la multiplexación y la demultiplexación, pág. 192, afirma lo mismo.
  34. ↑ Kirch, Olaf (16 de enero de 2002). "Protocolos basados ​​en texto" . Archivado del original el 30 de mayo de 2010. Recuperado el 21 de octubre de 2014 .
  35. ↑ Kirch, Olaf (16 de enero de 2002). "Protocolos de representación binaria" . Archivado del original el 30 de mayo de 2010. Recuperado el 4 de mayo de 2006 .
  36. ↑ Kirch, Olaf (16 de enero de 2002). "Protocolos de representación binaria" . Archivado del original el 5 de marzo de 2006. Recuperado el 4 de mayo de 2006 .
  37. ↑ "¡Bienvenido al sitio web de UML!" . Uml.org . Archivado del original el 30 de septiembre de 2019 . Consultado el 15 de enero de 2017 .
  38. ↑ Marsden 1986, Capítulo 3 - Conceptos fundamentales de protocolo y áreas problemáticas, págs. 26-42, explica gran parte de lo siguiente.
  39. ↑ Comer 2000, Sec. 7.7.4 - Tamaño del datagrama, MTU de red y fragmentación, pág. 104, Explica la fragmentación y el efecto en el encabezado de los fragmentos.
  40. ↑ Comer 2000, Capítulo 4 - Direcciones de Internet con clase, págs. 64-67;71.
  41. ↑ Marsden 1986, Sección 14.3 - Conceptos de capas y definiciones generales, pág. 187, explica el mapeo de direcciones.
  42. ↑ Marsden 1986, Sección 3.2 - Errores de detección y transmisión, pág. 27, explica las ventajas de la corrección de errores hacia atrás.
  43. ↑ Marsden 1986, Sección 3.3 - Reconocimiento, págs. 28-33, explica las ventajas del reconocimiento solo positivo y menciona los protocolos de datagramas como excepciones.
  44. ↑ Marsden 1986, Sección 3.4 - Pérdida de información - tiempos de espera y reintentos, págs. 33-34.
  45. ↑ Marsden 1986, Sección 3.5 - Dirección del flujo de información, págs. 34-35, explica la relación amo/esclavo y las negociaciones para obtener el control.
  46. ↑ Marsden 1986, Sección 3.6 - Control de secuencia, págs. 35-36, explica cómo se pierden los paquetes y cómo la secuenciación resuelve este problema.
  47. ↑ Marsden 1986, Sección 3.7 - Control de flujo, págs. 36–38.
  48. ↑ Ben-Ari 1982, en su prefacio, pág. xiii.
  49. ↑ Ben-Ari 1982, en su prefacio, pág. xiv.
  50. ↑ Hoare 1985, Capítulo 4 - Comunicación, pág. 133, trata sobre la comunicación.
  51. ↑ S. Srinivasan, Circuitos y sistemas digitales , cursos de NPTEL, archivado del original el 27 de diciembre de 2009.
  52. 1 2 Comer 2000, Sect. 11.2 - La necesidad de múltiples protocolos, pág. 177, introduce la descomposición en capas.
  53. ↑ Comer 2000, Sec. 11.3 - Las capas conceptuales del software de protocolo, pág. 179, los dos primeros párrafos describen el envío de un mensaje a través de capas sucesivas.
  54. ↑ Comer 2000, Sect. 11.2 - La necesidad de múltiples protocolos, pág. 178, explica las similitudes entre el software de protocolo y el compilador, ensamblador, enlazador y cargador.
  55. ↑ Comer 2000, Sect. 11.9.1 - Límite del sistema operativo, pág. 192, describe el límite del sistema operativo.
  56. ↑ IETF 1989, Sec 1.3.1 - Organización, pág. 15, segundo párrafo: muchas decisiones de diseño implican una "ruptura" creativa de la estratificación estricta.
  57. ↑ Comer 2000, Sect. 11.10 - La desventaja de la estratificación, pág. 192, explica por qué "la estratificación estricta puede ser extremadamente ineficiente" dando ejemplos de optimizaciones.
  58. ↑ Wakeman, I (enero de 1992). "La superposición de capas se considera perjudicial". IEEE Network : 20–24 .
  59. ↑ Kurose, James; Ross, Keith (2005). Redes informáticas: un enfoque descendente . Pearson.
  60. ↑ Lascano, Jorge Edison; Clyde, Stephen; Raza, Ali. "Patrones de diseño de protocolos de comunicación (CommDP) - COMMDP" . Archivado del original el 18 de marzo de 2017. Recuperado el 17 de marzo de 2017 .
  61. ↑ Lascano, JE; Clyde, S. (2016). Un lenguaje de patrones para protocolos de comunicación a nivel de aplicación . ICSEA 2016, Undécima Conferencia Internacional sobre Avances en Ingeniería de Software. pp. 22–30 . 
  62. ↑ Daigneau, R. (2011). Patrones de diseño de servicios: Soluciones de diseño fundamentales para servicios web SOAP/WSDL y RESTful (1.ª ed.). Upper Saddle River, NJ: Addison-Wesley Professional. 
  63. ↑ Fowler, M. (2002). Patrones de arquitectura de aplicaciones empresariales (1.ª ed.). Boston: Addison-Wesley Professional. ISBN  0-321-12742-0.
  64. ↑ [1]F. Buschmann, K. Henney y DC Schmidt, Pattern-Oriented Software Architecture Volumen 4: Un lenguaje de patrones para la computación distribuida, edición del volumen 4. Chichester, Inglaterra; Nueva York: Wiley, 2007.
  65. ↑ Bochmann, G. (1978). "Descripción de estados finitos de protocolos de comunicación". Computer Networks . 2 ( 4– 5): 361– 372. doi : 10.1016/0376-5075(78)90015-6 .
  66. ↑ Comer 2000, Glosario de términos y abreviaturas de interconexión de redes, pág. 704, término protocolo.
  67. ↑ Brand, Daniel; Zafiropulo, Pitro (abril de 1983). "Sobre máquinas de estados finitos comunicantes" . Journal of the ACM . 30 (2): 323– 342. doi : 10.1145/322374.322380 .
  68. ↑ Marsden 1986, Sección 6.3 - Ventajas de la estandarización, págs. 66-67, afirma lo mismo.
  69. ↑ Bryant & Morrow 2009 , pág. 4.
  70. ↑ Marsden 1986, Sección 6.4 - Algunos problemas con la estandarización, pág. 67, sigue a HDLC para ilustrar el proceso.
  71. ↑ "X.225 : Tecnología de la información – Interconexión de sistemas abiertos – Protocolo de sesión orientado a la conexión: Especificación del protocolo" . Archivado del original el 1 de febrero de 2021. Recuperado el 10 de marzo de 2023 . 
  72. ↑ Marsden 1986, Sección 6.1 - ¿Por qué son necesarios los estándares?, pág. 65, explica las lecciones aprendidas de ARPANET.
  73. ↑ Marsden 1986, Sección 14.1 - Introducción, pág. 181, presenta OSI.
  74. ↑ Marsden 1986, Sección 14.3 - Conceptos de capas y definiciones generales, págs. 183-185, explica la terminología.
  75. ↑ Marsden 1986, Sección 14.4 - La capa de aplicación, pág. 188, explica esto.
  76. ↑ Marsden 1986, Sección 14.5 - La capa de presentación, pág. 189, explica esto.
  77. ↑ Marsden 1986, Sección 14.6 - La capa de sesión, pág. 190, explica esto.
  78. ↑ Marsden 1986, Sección 14.7 - La capa de transporte, pág. 191, explica esto.
  79. ↑ Marsden 1986, Sección 14.8 - La capa de red, pág. 192, explica esto.
  80. ↑ Marsden 1986, Sección 14.9 - La capa de enlace de datos, pág. 194, explica esto.
  81. ↑ Marsden 1986, Sección 14.10 - La capa física, pág. 195, explica esto.
  82. ↑ ISO 7498:1984 – Sistemas de procesamiento de información - Interconexión de sistemas abiertos - Modelo de referencia básico . pág. 5. Este modelo de referencia básico de interconexión de sistemas abiertos se basa en el supuesto de que se requiere una conexión para la transferencia de datos. 
  83. ↑ ISO 7498:1984/ADD 1:1987 – Sistemas de procesamiento de información — Interconexión de sistemas abiertos — Modelo de referencia básico — Anexo 1 .
  84. ↑ Marsden 1986, Sección 14.11 - Modo sin conexión y RM/OSI, pág. 195, menciona esto.
  85. ↑ ISO 7498:1994 – Sistemas de procesamiento de información - Interconexión de sistemas abiertos - Modelo de referencia básico .
  86. ↑ Comer 2000, Sección 1.9 - Protocolos de Internet y estandarización, pág. 12, explica por qué el IETF no utilizó protocolos existentes.
  87. 1 2 Trammell y Kuehlewind 2019 , pág. 2.
  88. 1 2 Trammell y Kuehlewind 2019 , pág. 3.
  89. ↑ Trammell y Kuehlewind 2019 , pág. 4.
  90. 1 2 Fairhurst y Perkins 2021 , 7. Conclusiones.
  91. ↑ Trammell y Kuehlewind 2019 , pág. 5.
  92. ↑ Trammell y Kuehlewind 2019 , pág. 6.
  93. ↑ Trammell y Kuehlewind 2019 , págs. 7-8.
  94. ↑ Farrell y Tschofenig 2014 , pág. 2.
  95. 1 2 Farrell y Tschofenig 2014 , pág. 3.
  96. ↑ Arkko et al. 2023 , 2.1. Distribución intencional.
  97. ↑ Arkko et al. 2023 , 2.2. Control de la distribución de la información.
  98. ↑ Arkko et al. 2023 , 2.3. Protección de la información y autenticación.
  99. ↑ Arkko et al. 2023 , 2.5. Limitación del impacto de la información.
  100. ↑ Arkko et al. 2023 , 2.4. Minimizar la información.
  101. ↑ Arkko et al. 2023 , 2.6. Conjunto mínimo de entidades.
  102. ↑ Arkko et al. 2023 , 3. Trabajos adicionales.
  103. ^ Papastergiou y col. 2017 , pág. 619.
  104. ^ Papastergiou y col. 2017 , pág. 620.
  105. ^ Papastergiou y col. 2017 , pág. 620-621.
  106. ^ Papastergiou y col. 2017 , pág. 623-4.
  107. ↑ McQuistin, Perkins y Fayed 2016 , pág. 1.
  108. ↑ Thomson y Pauly 2021 , A.5. TCP.
  109. ↑ Hardie 2019 , págs. 7-8.
  110. ↑ Thomson y Pauly 2021 , 3. Uso activo.
  111. ↑ Thomson y Pauly 2021 , 3.5. Restablecimiento del uso activo.
  112. ↑ Comer 2000, Sect. 11.5.1 - El modelo de referencia de 5 capas TCP/IP, pág. 183, afirma lo mismo.

Bibliografía

  • Radia Perlman (1999). Interconexiones: puentes, enrutadores, conmutadores y protocolos de interconexión de redes (2.ª  ed.). Addison-Wesley. ISBN 0-201-63448-1.En particular, el capítulo 18 sobre "folclore del diseño de redes", que también está disponible en línea.
  • Gerard J. Holzmann (1991). Diseño y validación de protocolos informáticos . Prentice Hall. ISBN 0-13-539925-4.
  • Douglas E. Comer (2000). Interconexión de redes con TCP/IP: Principios, protocolos y arquitectura (4.ª  ed.). Prentice Hall. ISBN 0-13-018380-6.En particular, el capítulo 11 trata sobre la estratificación de protocolos. También incluye una guía RFC y un glosario de términos y abreviaturas de interconexión de redes.
  • R. Braden , ed. (1989). Requisitos para hosts de Internet: capas de comunicación . Grupo de trabajo de ingeniería de Internet abreviado IETF. doi : 10.17487/RFC1122 . RFC 1122 .Describe TCP/IP a los desarrolladores de software de protocolo. En particular, la introducción ofrece una visión general de los objetivos de diseño del conjunto de herramientas.
  • M. Ben-ari (1982). Principios de programación concurrente (10.ª  ed. impresa). Prentice Hall International. ISBN 0-13-701078-8.
  • CAR Hoare (1985). Comunicación de procesos secuenciales (10.ª  ed. impresa). Prentice Hall International. ISBN 0-13-153271-5.
  • RD Tennent (1981). Principios de los lenguajes de programación (10.ª  ed. impresa). Prentice Hall International. ISBN 0-13-709873-1.
  • Brian W. Marsden (1986). Protocolos de redes de comunicación (2.ª  ed.). Chartwell Bratt. ISBN 0-86238-106-1.
  • Andrew S. Tanenbaum (1984). Organización estructurada de computadoras (10.ª  edición impresa). Prentice Hall International. ISBN 0-13-854605-3.
  • Bryant, Stewart; Morrow, Monique, eds. (noviembre de 2009). El desarrollo de protocolos no coordinado se considera perjudicial . IETF . doi : 10.17487/RFC5704 . RFC 5704 .
  • Farrell, Stephen; Tschofenig, Hannes (mayo de 2014). El monitoreo generalizado es un ataque . IETF . doi : 10.17487/RFC7258 . RFC 7258 .
  • Trammell, Brian; Kuehlewind, Mirja (abril de 2019). La imagen de cable de un protocolo de red . IETF . doi : 10.17487/RFC8546 . RFC 8546 .
  • Hardie, Ted, ed. (abril de 2019). Señales de ruta de protocolo de transporte . IETF . doi : 10.17487/RFC8558 . RFC 8558 .
  • Fairhurst, Gorry; Perkins, Colin (julio de 2021). Consideraciones sobre la confidencialidad de las cabeceras de transporte, las operaciones de red y la evolución de los protocolos de transporte de Internet . IETF . doi : 10.17487/RFC9065 . RFC 9065 .
  • Thomson, Martin; Pauly, Tommy (diciembre de 2021). Viabilidad a largo plazo de los mecanismos de extensión de protocolo . IETF . doi : 10.17487/RFC9170 . RFC 9170 .
  • Arkko, Jari; Hardie, Ted; Pauly, Tommy; Kühlewind, Mirja (julio de 2023). Consideraciones sobre la aplicación: colaboración en red mediante señales de ruta . IETF . doi : 10.17487/RFC9419 . RFC 9419 .
  • McQuistin, Stephen; Perkins, Colin; Fayed, Marwan (julio de 2016). Implementación de servicios de transporte en tiempo real sobre una red osificada . Taller de investigación de redes aplicadas de 2016. doi : 10.1145/2959424.2959443 . hdl : 1893/26111 .
  • Papastergiou, Giorgos; Fairhurst, Gorry; Ros, David; Brunstrom, Anna; Grinnemo, Karl-Johan; Hurtig, Per; Khademi, Naeem; Tüxen, Michael; Welzl, Michael; Damjanovic, Dragana; Mangiante, Simone (2017). "Desosilización de la capa de transporte de Internet: una revisión y perspectivas futuras". IEEE Communications Surveys & Tutorials . 19 : 619–639 . doi : 10.1109/COMST.2016.2626780 . hdl : 2164/8317 .
  • Moschovitis, Christos JP (1999). Historia de Internet: Cronología, 1843 hasta la actualidad . ABC-CLIO. ISBN 978-1-57607-118-2.
  • Diccionario de protocolos de Javvin en la Wayback Machine (archivado el 10 de junio de 2004)
  • Descripción general de los protocolos en el campo del telecontrol con el modelo de referencia OSI.
Lecturas relacionadas
6 articulos
Sistema de comunicacionesSistema de comunicacionesUn sistema de comunicaciones o sistema de comunicación es un conjunto de sistemas de redes de telecomunicaciones individuales, estaciones repetidor...Mapa parcial de Internet, con nodos que representan direcciones IPInformaciónLa información es un concepto abstracto que se refiere a algo que tiene el poder de informar . En el nivel más fundamental, se refiere a la interpr...SintaxisEn lingüística , la sintaxis ( / ˈsɪntæks / SIN - taks ) [ 1] [2] es el estudio de cómo las palabras y los morfemas se combinan para formar unidade...Semántica (informática)Semántica (informática)En la teoría de los lenguajes de programación , la semántica es el estudio matemático riguroso del significado de los lenguajes de programación . [...SincronizaciónSincronizaciónLa sincronización es la coordinación de eventos para que un sistema funcione al unísono. Por ejemplo, el director de una orquesta mantiene a la orq...Foto de un apretón de manosComunicaciónExisten muchas formas de comunicación, incluida la comunicación lingüística humana mediante sonidos, lenguaje de señas y escritura, así como el int...