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

The first use of the term protocol in a modern data communication context occurs in April 1967 in a memorandum entitled A Protocol for Use in the NPL Data Communications Network. Under the direction of Donald Davies, who pioneered packet switching at the National Physical Laboratory in the United Kingdom, it was written by Roger Scantlebury and Keith Bartlett for the NPL network. They published their work the following year.[5][6][7][8]

On the ARPANET, the starting point for host-to-host communication in 1969 was the 1822 protocol, written by Bob Kahn, which defined the transmission of messages to an IMP.[9] The Network Control Program (NCP) for the ARPANET, developed by Steve Crocker and other graduate students including Jon Postel, was first implemented in 1970.[10] The NCP interface allowed application software to connect across the ARPANET by implementing higher-level communication protocols, an early example of the protocol layering concept.[11]

The CYCLADES network, designed by Louis Pouzin in the early 1970s, was the first to implement the end-to-end principle, and make the hosts responsible for the reliable delivery of data on a packet-switched network, rather than this being a service of the network itself.[12] His team was the first to tackle the highly complex problem of providing user applications with a reliable virtual circuit service while using a best-effort service, an early contribution to what will be the Transmission Control Protocol (TCP).[13][14][15]

Bob Metcalfe and others at Xerox PARC outlined the idea of Ethernet and the PARC Universal Packet (PUP) for internetworking.[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 (July 1987). "Data Communications at the National Physical Laboratory (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 The Communications Subnet: BBN 1969". Entrepreneurial Capitalism and Innovation: A History of Computer Communications 1968–1988. As Kahn recalls: ... Paul Baran's contributions ... I also think Paul was motivated almost entirely by voice considerations. If you look at what he wrote, he was talking about switches that were low-cost electronics. The idea of putting powerful computers in these locations hadn't quite occurred to him as being cost effective. So the idea of computer switches was missing. The whole notion of protocols didn't exist at that time. And the idea of computer-to-computer communications was really a secondary concern.
  8. ↑Kleinrock, L. (1978). "Principles and lessons in packet communications". Proceedings of the IEEE. 66 (11): 1320–1329. Bibcode:1978IEEEP..66.1320K. doi:10.1109/PROC.1978.11143. ISSN 0018-9219. Paul Baran ... focused on the routing procedures and on the survivability of distributed communication systems in a hostile environment, but did not concentrate on the need for resource sharing in its form as we now understand it; indeed, the concept of a software switch was not present in his work.
  9. ↑Interface Message Processor: Specifications for the Interconnection of a Host and an IMP(PDF) (Report). Bolt Beranek and Newman (BBN). Report No. 1822.
  10. ↑BOOKS, HIGH DEFINITION. UGC -NET/JRF/SET PTP & Guide Teaching and Research Aptitude: UGC -NET By HD. High Definition Books.
  11. ↑"NCP – Network Control Program". Living Internet. Archived from the original on 7 August 2022. Retrieved 8 October 2022.
  12. ↑Bennett, Richard (September 2009). "Designed for Change: End-to-End Arguments, Internet Innovation, and the Net Neutrality Debate"(PDF). Information Technology and Innovation Foundation. pp. 7, 11. Retrieved 11 September 2017.
  13. ↑Abbate, Janet (2000). Inventing the Internet. MIT Press. pp. 124–127. ISBN 978-0-262-51115-5. In fact, CYCLADES, unlike ARPANET, had been explicitly designed to facilitate internetworking; it could, for instance, handle varying formats and varying levels of service
  14. ↑Kim, Byung-Keun (2005). Internationalising the Internet the Co-evolution of Influence and Technology. Edward Elgar. pp. 51–55. ISBN 1845426754. In addition to the NPL Network and the ARPANET, CYCLADES, an academic and research experimental network, also played an important role in the development of computer networking technologies
  15. ↑"The internet's fifth man". The Economist. 30 November 2013. ISSN 0013-0613. Retrieved 22 April 2020. In the early 1970s Mr Pouzin created an innovative data network that linked locations in France, Italy and Britain. Its simplicity and efficiency pointed the way to a network that could connect not just dozens of machines, but millions of them. It captured the imagination of Dr Cerf and Dr Kahn, who included aspects of its design in the protocols that now power the internet.
  16. ↑Moschovitis 1999, p. 78-9
  17. ↑Cerf, V.; Kahn, R. (May 1974). "A Protocol for Packet Network Intercommunication"(PDF). IEEE Transactions on Communications. 22 (5): 637–648. Bibcode:1974ITCom..22..637C. doi:10.1109/TCOM.1974.1092259. ISSN 1558-0857. Archived(PDF) from the original on 6 January 2017. Retrieved 23 February 2020. The authors wish to thank a number of colleagues for helpful comments during early discussions of international network protocols, especially R. Metcalfe, R. Scantlebury, D. Walden, and H. Zimmerman; D. Davies and L. Pouzin who constructively commented on the fragmentation and accounting issues; and S. Crocker who commented on the creation and destruction of associations.
  18. ↑McKenzie, Alexander (January 2011). "INWG and the Conception of the Internet: An Eyewitness Account". 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 (November 2010). "X.25 Virtual Circuits - TRANSPAC IN France - Pre-Internet Data Networking [History of communications]". IEEE Communications Magazine. 48 (11): 40–46. doi:10.1109/MCOM.2010.5621965. ISSN 1558-1896.
  20. ↑Rybczynski, Tony (December 2009). "Commercialization of packet switching (1975-1985): A Canadian perspective [History of Communications]". IEEE Communications Magazine. 47 (12): 26–31. doi:10.1109/MCOM.2009.5350364. ISSN 1558-1896.
  21. ↑The "Hidden" Prehistory of European Research Networking. Trafford Publishing. p. 354. ISBN 978-1-4669-3935-6.
  22. ↑"TCP/IP Internet Protocol". Living Internet. Archived from the original on 1 September 2022. Retrieved 8 October 2022.
  23. ↑Andrew L. Russell (30 July 2013). "OSI: The Internet That Wasn't". IEEE Spectrum. Vol. 50, no. 8.
  24. ↑Russell, Andrew L. "Rough Consensus and Running Code' and the Internet-OSI Standards War"(PDF). IEEE Annals of the History of Computing. Archived(PDF) from the original on 17 November 2019. Retrieved 23 February 2020.
  25. ↑"Standards Wars"(PDF). 2006. Archived(PDF) from the original on 24 February 2021. Retrieved 23 February 2020.
  26. ↑Ben-Ari 1982, chapter 2 - The concurrent programming abstraction, p. 18-19, states the same.
  27. ↑Ben-Ari 1982, Section 2.7 - Summary, p. 27, summarizes the concurrent programming abstraction.
  28. 12Marsden 1986, Section 6.1 - Why are standards necessary?, p. 64-65, uses BSC as an example to show the need for both standard protocols and a standard framework.
  29. ↑Comer 2000, Sect. 11.2 - The Need For Multiple Protocols, p. 177, explains this by drawing analogies between computer communication and programming languages.
  30. 12Sect. 11.10 - The Disadvantage Of Layering, p. 192, states: layering forms the basis for protocol design.
  31. 12Comer 2000, Sect. 11.2 - The Need For Multiple Protocols, p. 177, states the same.
  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, Digital Circuits and Systems, NPTEL courses, archived from the original on 27 December 2009
  52. 12Comer 2000, Sect. 11.2 - The Need For Multiple Protocols, p. 177, introduces the decomposition in layers.
  53. ↑Comer 2000, Sect. 11.3 - The Conceptual Layers Of Protocol Software, p. 179, the first two paragraphs describe the sending of a message through successive layers.
  54. ↑Comer 2000, Sect. 11.2 - The need for multiple protocols, p. 178, explains similarities protocol software and compiler, assembler, linker, loader.
  55. ↑Comer 2000, Sect. 11.9.1 - Operating System Boundary, p. 192, describes the operating system boundary.
  56. ↑IETF 1989, Sect 1.3.1 - Organization, p. 15, 2nd paragraph: many design choices involve creative "breaking" of strict layering.
  57. ↑Comer 2000, Sect. 11.10 - The Disadvantage Of Layering, p. 192, explains why "strict layering can be extremely inefficient" giving examples of optimizations.
  58. ↑Wakeman, I (January 1992). "Layering considered harmful". IEEE Network: 20–24.
  59. ↑Kurose, James; Ross, Keith (2005). Computer Networking: A Top-Down Approach. Pearson.
  60. ↑Lascano, Jorge Edison; Clyde, Stephen; Raza, Ali. "Communication-protocol Design Patterns (CommDP) - COMMDP". Archived from the original on 18 March 2017. Retrieved 17 March 2017.
  61. ↑Lascano, J. E.; Clyde, S. (2016). A Pattern Language for Application-level Communication Protocols. ICSEA 2016, The Eleventh International Conference on Software Engineering Advances. pp. 22–30.
  62. ↑Daigneau, R. (2011). Service Design Patterns: Fundamental Design Solutions for SOAP/WSDL and RESTful Web Services (1 ed.). Upper Saddle River, NJ: Addison-Wesley Professional.
  63. ↑Fowler, M. (2002). Patterns of Enterprise Application Architecture (1 ed.). Boston: Addison-Wesley Professional. ISBN 0-321-12742-0.
  64. ↑[1]F. Buschmann, K. Henney, and D. C. Schmidt, Pattern-Oriented Software Architecture Volume 4: A Pattern Language for Distributed Computing, Volume 4 edition. Chichester England; New York: Wiley, 2007.
  65. ↑Bochmann, G. (1978). "Finite state description of communication protocols". 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.