Protocolo de comunicación

Un protocolo de comunicación es un sistema de reglas que permite que dos o más entidades de un sistema de comunicaciones transmitan información a través de cualquier variación de una cantidad física . El protocolo define las reglas, la sintaxis , la semántica y la sincronización de la comunicación y 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 un rango de posibles respuestas predeterminadas para esa situación particular. El comportamiento especificado es típicamente independiente de cómo se va a implementar . Los protocolos de comunicación tienen que 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 establece que los protocolos son a la comunicación lo que los algoritmos son a los cálculos . ^[4]

Los protocolos múltiples suelen describir diferentes aspectos de una única comunicación. Un grupo de protocolos diseñados para funcionar juntos se conoce como conjunto de protocolos; cuando se implementan en software, forman una pila de protocolos .

Los protocolos de comunicación de Internet son publicados por el Grupo de Trabajo de Ingeniería de Internet (IETF). El IEEE (Instituto de Ingenieros Eléctricos y Electrónicos) se ocupa de las redes cableadas e inalámbricas y la Organización Internacional de Normalización (ISO) se ocupa de otros tipos. La UIT-T se ocupa de los protocolos y formatos de telecomunicaciones para la red telefónica pública conmutada (PSTN). A medida que la PSTN e Internet convergen , los estándares también se están orientando hacia la convergencia.

El primer uso del término protocolo en un contexto moderno de conmutación de datos se produjo en abril de 1967 en un memorando titulado A Protocol for Use in the NPL Data Communications Network. Bajo la dirección de Donald Davies , pionero en 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 NPL . ^{[5] [6] [7] [8] [9]}

En ARPANET , el punto de partida para la comunicación de host a host en 1969 fue el protocolo 1822 , escrito por Bob Kahn , que definió la transmisión de mensajes a un IMP. ^[10] El Programa de Control de Red (NCP) para ARPANET, desarrollado por Steve Crocker y otros estudiantes de posgrado, incluidos Jon Postel y Vint Cerf , se implementó por primera vez en 1970. ^[11] La interfaz NCP permitió que el software de aplicación se conectara a través de ARPANET implementando protocolos de comunicación de nivel superior, un ejemplo temprano del concepto de capas de protocolo . ^[12]

La red CYCLADES , diseñada por Louis Pouzin a principios de los años 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 esto sea un servicio de la red en sí. ^[13] 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 utiliza un servicio de mejor esfuerzo , una contribución temprana a lo que será el Protocolo de Control de Transmisión (TCP). ^{[14] [15] [16]}

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

Las investigaciones realizadas a principios de los años 1970 por Bob Kahn y Vint Cerf condujeron a la formulación del Programa de Control de Transmisión (TCP). ^[18] Su especificación RFC  675 fue escrita por Cerf con Yogen Dalal y Carl Sunshine en diciembre de 1974, todavía 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 ARPANET. ^[19] Investigaciones internacionales independientes, 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. ^{[20] [21]} Los fabricantes de computadoras desarrollaron protocolos propietarios como Systems Network Architecture (SNA) de IBM, DECnet de Digital Equipment Corporation y Xerox Network Systems . ^[22]

El software TCP fue rediseñado como una pila de protocolos modular, conocida como 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 en 1989, como se describe en RFC  1122 y RFC  1123, sentó las bases para el crecimiento de TCP/IP como un conjunto de protocolos integral como el componente central de la Internet emergente . ^[23]

El trabajo internacional sobre un modelo de referencia para los estándares de comunicación condujo al modelo OSI , publicado en 1984. Durante un período a fines de la década de 1980 y principios de la de 1990, los ingenieros, las organizaciones y las naciones se polarizaron sobre 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 de computadoras. ^{[24] [25] [26]}

La información que se intercambia entre dispositivos a través de una red u otros medios se rige por reglas y convenciones que pueden establecerse en especificaciones de protocolos de comunicación. La naturaleza de la comunicación, los datos reales intercambiados 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 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 entendidos, que pueden estar integrados en el propio código del proceso. ^{[27] [28]} Por el contrario, debido a que no hay memoria compartida , los sistemas que se comunican tienen que comunicarse entre sí utilizando un medio de transmisión compartido . La transmisión no es necesariamente fiable y los sistemas individuales pueden utilizar diferentes hardware o sistemas operativos.

Para implementar un protocolo de red, los módulos de software de protocolo se interconectan con un marco implementado en el sistema operativo de la máquina. Este marco implementa la funcionalidad de red del sistema operativo. ^[29] Cuando los algoritmos de protocolo se expresan en un lenguaje de programación portátil, el software de protocolo puede volverse independiente del sistema operativo . Los marcos más conocidos son el modelo TCP/IP y el modelo OSI .

En el momento en que se desarrolló Internet, la superposición de abstracciones había demostrado ser un enfoque de diseño exitoso tanto para el diseño de compiladores como de 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. ^[30] Esto dio lugar al concepto de protocolos en capas que hoy en día forman la base del diseño de protocolos. ^[31]

Los sistemas normalmente no utilizan un único protocolo para gestionar una transmisión, sino que utilizan un conjunto de protocolos cooperativos, a veces denominados suite de protocolos . ^[32] Algunas de las suites de protocolos más conocidas son TCP/IP , IPX/SPX , X.25 , AX.25 y AppleTalk .

Los protocolos se pueden organizar en función de su funcionalidad en grupos; 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, las funciones de interfaz de aplicación, transporte, Internet y red. ^[33] Para transmitir un mensaje, se debe seleccionar un protocolo de cada capa. La selección del siguiente protocolo se logra ampliando el mensaje con un selector de protocolo para cada capa. ^[34]

Existen dos tipos de protocolos de comunicación, en función de su representación del contenido transportado: basados ​​en texto y binarios. ^[35]

Un protocolo basado en texto o protocolo de texto simple representa su contenido en formato legible para humanos , a menudo en texto simple codificado en una codificación legible por máquinas como ASCII o UTF-8 , o en formatos basados ​​en texto estructurado como el formato hexadecimal Intel , XML o JSON .

La legibilidad humana inmediata contrasta con los protocolos binarios nativos que tienen beneficios inherentes para su uso en un entorno informático (como facilidad de análisis mecánico y mejor utilización del ancho de banda ).

Las aplicaciones de red tienen varios métodos para encapsular datos. Un método muy común con los protocolos de Internet es una representación orientada a texto que transmite solicitudes y respuestas como líneas de texto ASCII , terminadas por un carácter de nueva línea (y generalmente un carácter de retorno de carro). Ejemplos de protocolos que utilizan texto simple y legible para sus comandos son FTP ( Protocolo de transferencia de archivos ), SMTP ( Protocolo simple de transferencia de correo ), versiones anteriores de HTTP ( Protocolo de transferencia de hipertexto ) y el protocolo finger . ^[36]

Los protocolos basados ​​en texto generalmente están optimizados para el análisis y la interpretación humanos y, por lo tanto, son adecuados 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.

Un protocolo binario utiliza todos los valores de un byte , a diferencia de un protocolo basado en texto que solo utiliza valores correspondientes a caracteres legibles por humanos en codificación ASCII . Los protocolos binarios están pensados ​​para ser leídos por una máquina, no por un ser humano. Los protocolos binarios tienen la ventaja de ser breves, lo que se traduce en velocidad de transmisión e interpretación. ^[37]

El binario se ha utilizado en los documentos normativos que describen estándares modernos como EbXML , HTTP/2 , HTTP/3 y EDOC . ^[38] Una interfaz en UML ^[39] también puede considerarse un protocolo binario.

La transmisión de datos a través de una red es solo una parte del problema de un protocolo. Los datos recibidos deben evaluarse en el contexto del progreso de la conversación, por lo que un protocolo debe incluir reglas que describan el contexto. Se dice que este tipo de reglas expresan la sintaxis de la comunicación. Otras reglas determinan si los datos son significativos para el contexto en el que se produce el intercambio. Se dice que este tipo de 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 reglas que rijan la transmisión. En general, se deben abordar muchos de los siguientes aspectos: ^[40]

Formatos de datos para el intercambio de datos

Se intercambian cadenas de bits de mensajes digitales. Las cadenas de bits se dividen en campos y cada campo lleva información relevante para el protocolo. Conceptualmente, la cadena de bits se divide en dos partes llamadas encabezado y carga útil . El mensaje real se transporta en la carga útil. El área del encabezado contiene los campos relevantes para el funcionamiento del protocolo. Las cadenas de bits más largas que la unidad máxima de transmisión (MTU) se dividen en partes del tamaño apropiado. ^[41]

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 el área de encabezado de las cadenas de bits, lo que permite a los receptores determinar si las cadenas de bits son de interés y deben procesarse o ignorarse. Una conexión entre un remitente y un receptor se puede identificar utilizando un par de direcciones (dirección del remitente, dirección del receptor) . Por lo general, algunos valores de dirección tienen significados especiales. Una dirección de todos 1 podría interpretarse como un direccionamiento de todas las estaciones de la red, por lo que el envío a esta dirección daría como resultado una difusión en la red local. Las reglas que describen los significados del valor de la dirección se denominan colectivamente esquema de direccionamiento . ^[42]

Mapeo de direcciones

A veces, los protocolos necesitan mapear direcciones de un esquema con direcciones de otro esquema. Por ejemplo, para traducir una dirección IP lógica especificada por la aplicación a una dirección MAC de Ethernet. Esto se conoce como mapeo de direcciones . ^[43]

Enrutamiento

Cuando los sistemas no están conectados directamente, los sistemas intermediarios a lo largo de la ruta hacia los receptores previstos deben reenviar mensajes en nombre del remitente. En Internet, las redes están conectadas 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 que el receptor detecte diferencias causadas por la corrupción. El receptor rechaza los paquetes con diferencias de CRC y organiza de alguna manera la retransmisión. ^[44]

Expresiones de gratitud

Para la comunicación orientada a la conexión es necesario confirmar la recepción correcta de los paquetes . Los receptores envían confirmaciones a sus respectivos remitentes. ^[45]

Pérdida de información: tiempos de espera y reintentos

Los paquetes pueden perderse en la red o demorarse en el tránsito. Para hacer frente a esto, bajo algunos protocolos, un remitente puede esperar un acuse de recibo de la recepción correcta del receptor dentro de un cierto período de tiempo. Por lo tanto, en los tiempos de espera , el remitente puede necesitar retransmitir la información. ^[a] En caso de un enlace roto permanentemente, la retransmisión no tiene efecto, por lo que el número de retransmisiones es limitado. Exceder el límite de reintentos se considera un error. ^[46]

Dirección del flujo de información

Es necesario abordar la dirección si las transmisiones solo pueden ocurrir en una dirección a la vez, como en enlaces semidúplex , o desde un remitente a la vez, como en un medio compartido . Esto se conoce como control de acceso al medio . Se deben tomar medidas para dar cabida al caso de colisión o contención en el que dos partes transmiten o desean transmitir simultáneamente. ^[47]

Control de secuencia

Si se dividen en fragmentos largos y luego se envían a la red individualmente, los fragmentos pueden perderse o demorarse o, en algunos tipos de redes, tomar rutas diferentes a su destino. Como resultado, los fragmentos pueden llegar fuera de secuencia. Las retransmisiones pueden dar como resultado 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 volver a ensamblar el mensaje original. ^[48]

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 puede procesar las transmisiones. El control de flujo se puede implementar mediante el envío de mensajes del receptor al emisor. ^[49]

Haciendo cola

Los procesos de comunicación o máquinas de estados emplean colas (o "buffers"), normalmente colas FIFO, para procesar los mensajes en el orden en que se envían y, a veces, pueden tener varias colas con diferentes priorizaciones.

Los principios de ingeniería de sistemas se han aplicado para crear un conjunto de principios de diseño de protocolos de red comunes. El diseño de protocolos complejos a menudo implica la descomposición en protocolos cooperativos más simples. Este conjunto de protocolos cooperativos a veces se denomina familia de protocolos o suite de protocolos ^[32] dentro de un marco conceptual.

Los sistemas de comunicación funcionan 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. ^[50] La verificación formal parece indispensable porque los programas concurrentes son conocidos por los errores ocultos y sofisticados que contienen. ^[51] Un enfoque matemático para el estudio de la concurrencia y la comunicación se conoce como procesos secuenciales de comunicación (CSP). ^[52] 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 de electrónica digital que se encuentran en forma de hardware utilizado en telecomunicaciones o dispositivos electrónicos en general. ^{[53] [ se necesita una mejor fuente ]}

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

En el diseño de protocolos modernos, los protocolos se organizan en capas para formar una pila de protocolos. La organización en capas es un principio de diseño que divide la tarea de diseño de protocolos en pasos más pequeños, cada uno de los cuales realiza una parte específica e interactúa con las otras partes del protocolo solo en un pequeño número de formas bien definidas. La organización en capas permite diseñar y probar las partes de un protocolo sin una explosión combinatoria de casos, lo que mantiene cada diseño relativamente simple.

Los protocolos de comunicación que se utilizan 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 encajan en una jerarquía básica de capas funcionales definidas en el conjunto de protocolos de Internet . ^[54] Los dos primeros protocolos cooperantes, el Protocolo de Control de Transmisión (TCP) y el Protocolo de Internet (IP), resultaron de la descomposición del Programa de Control de Transmisión original, un protocolo de comunicación monolítico, en este conjunto de comunicaciones en capas.

El modelo OSI fue desarrollado internacionalmente con base en la experiencia con redes anteriores a Internet como modelo de referencia para la comunicación general, con reglas de interacción de protocolos mucho más estrictas y capas rigurosas.

Por lo general, el software de aplicación se basa en una capa de transporte de datos robusta. Detrás de esta capa de transporte hay un mecanismo de entrega y enrutamiento de datagramas que, por lo general, no tiene conexión en Internet. La retransmisión de paquetes a través de redes se realiza a través de otra capa que involucra solo tecnologías de enlace de red, que a menudo son específicas de ciertas tecnologías de capa física, como Ethernet . La superposición de capas brinda oportunidades para intercambiar tecnologías cuando es necesario; por ejemplo, los protocolos a menudo se apilan en una disposición de tunelización para dar cabida a la conexión de redes diferentes. Por ejemplo, IP puede tunelizarse a través de una red de modo de transferencia asíncrono (ATM).

La superposición de protocolos constituye la base del diseño de protocolos. ^[31] Permite la descomposición de protocolos únicos y complejos en protocolos más simples y cooperativos. ^[54] Cada capa de protocolo resuelve una clase distinta de problemas de comunicación. Juntas, las capas conforman un esquema o modelo de superposició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 las capas de protocolos y los conjuntos de protocolos, en la figura 3 se muestra un diagrama de los flujos de mensajes en y entre dos sistemas, A y B. Los sistemas, A y B, ambos hacen uso del mismo conjunto de protocolos. Los flujos verticales (y protocolos) son dentro del sistema y los flujos de mensajes horizontales (y protocolos) son entre sistemas. Los flujos de mensajes están regidos por reglas y los formatos de datos especificados por protocolos. Las líneas azules marcan los límites de las capas de protocolo (horizontales).

El software que soporta los protocolos tiene una organización en capas y su relación con las capas de protocolos 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 que se encuentra directamente debajo de él y le entrega el mensaje para que sea encapsulado. El módulo inferior completa los datos del encabezado 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 comunicaciones al módulo inferior del sistema B. En el sistema receptor B sucede lo contrario, por lo que finalmente el mensaje se entrega en su forma original al módulo superior del sistema B. ^[55]

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 que las capas de software se diseñen de forma independiente. El mismo enfoque se puede observar en la estructura en capas de TCP/IP. ^[56]

Los módulos que se encuentran por debajo de la capa de aplicación generalmente se consideran parte del sistema operativo. Pasar datos entre estos módulos es mucho menos costoso que pasar 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. ^[57]

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

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

Los problemas que se repiten con frecuencia en el diseño e implementación de protocolos de comunicación se pueden abordar mediante patrones de diseño de software . ^{[62] [63] [64] [65] [66]}

Los métodos formales 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. ^{[67] [68]} y máquinas de estados finitos comunicantes ^[69]

Para que se produzca la comunicación, es necesario seleccionar protocolos. Las reglas se pueden expresar mediante algoritmos y estructuras de datos. La independencia del hardware y del sistema operativo se mejora al expresar los algoritmos en un lenguaje de programación portátil. La independencia de la fuente de la especificación proporciona una interoperabilidad más amplia.

Los estándares de protocolo se crean habitualmente obteniendo la aprobación o el apoyo de una organización de normalización , que inicia el proceso de normalización. Los miembros de la organización de normalización aceptan adherirse al resultado del trabajo de forma voluntaria. A menudo, los miembros controlan grandes cuotas de mercado relevantes para el protocolo y, en muchos casos, los estándares se aplican por ley o por el gobierno porque se cree que sirven a un interés público importante, por lo que obtener la aprobación puede ser muy importante para el protocolo.

La necesidad de estándares de protocolo se puede demostrar observando lo que sucedió con el protocolo de Comunicaciones Sincrónicas Binarias (BSC) inventado por IBM . BSC es un protocolo de nivel de enlace temprano utilizado para conectar dos nodos separados. Originalmente no estaba destinado a ser utilizado en una red multinodo, pero al hacerlo reveló varias deficiencias del protocolo. En ausencia de estandarización, los fabricantes y las organizaciones se sintieron libres de mejorar el protocolo, creando versiones incompatibles en sus redes. En algunos casos, esto se hizo deliberadamente para disuadir a los usuarios de usar equipos de otros fabricantes. Hay más de 50 variantes del protocolo bi-sync original. Se puede suponer que un estándar habría evitado al menos algo de esto. ^[29]

En algunos casos, los protocolos ganan dominio del mercado sin pasar por un proceso de estandarización. Estos protocolos se conocen como estándares de facto . Los estándares de facto son comunes en mercados emergentes, mercados de nicho o mercados que están monopolizados (u oligopolizados ). Pueden tener un control muy negativo sobre un mercado, especialmente cuando se utilizan para ahuyentar a la competencia. Desde una perspectiva histórica, la estandarización debe verse como una medida para contrarrestar los efectos nocivos de los estándares de facto. Existen excepciones positivas; un sistema operativo estándar de facto como Linux no tiene este control negativo sobre su mercado, porque las fuentes se publican y mantienen de manera abierta, lo que invita a la competencia.

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 que se utilizan 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 paraguas de ingenieros de telecomunicaciones que diseñan la red telefónica pública conmutada (PSTN), así como muchos sistemas de comunicación por radio . 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 tienen intereses comerciales o nacionales que considerar. Las organizaciones de normalización también realizan investigación y desarrollo para las normas del futuro. En la práctica, las organizaciones de normalización mencionadas cooperan estrechamente entre sí. ^[70]

En el desarrollo de un protocolo pueden participar varios organismos de normalización. Si no están coordinados, el resultado puede ser múltiples definiciones incompatibles de un protocolo, o múltiples interpretaciones incompatibles de mensajes; invariantes importantes de una definición (por ejemplo, que los valores de tiempo de vida sean monótonos y decrecientes para evitar bucles de enrutamiento estables ) pueden no ser respetadas en otra. ^[71]

En la ISO, el proceso de normalización comienza con la designación de un subcomité de trabajo. El grupo de trabajo emite borradores de trabajo y documentos de discusión para las partes interesadas (incluidos otros organismos de normalización) con el fin de provocar debates y comentarios. Esto generará muchas preguntas, mucha discusión y, por lo general, algún desacuerdo. Estos comentarios se tienen en cuenta y el grupo de trabajo elabora una propuesta preliminar . Después de la retroalimentación, la modificación y el compromiso, la propuesta alcanza el estado de borrador de norma internacional y, en última instancia, de norma internacional . Las normas internacionales se vuelven a emitir periódicamente para abordar las deficiencias y reflejar los puntos de vista cambiantes sobre el tema. ^[72]

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 uso general y a prueba de futuro adecuado para protocolos estructurados (como protocolos en capas) y su estandarización. Esto evitaría estándares de protocolo con funcionalidad superpuesta y permitiría una definición clara de las responsabilidades de un protocolo en los diferentes niveles (capas). ^[74] Esto dio lugar 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 ajusten a las diversas especificaciones de capa. ^[75]

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 servicio a la capa superior utilizando los servicios de la capa inmediatamente inferior. La capa superior proporciona servicios al proceso de aplicación. Las capas se comunican entre sí por medio de una interfaz, denominada punto de acceso al servicio . Las capas correspondientes en cada sistema se denominan entidades pares . Para comunicarse, dos entidades pares en una capa dada utilizan un protocolo específico para esa capa que se implementa utilizando los servicios de la capa inferior. ^[76] Para cada capa, hay dos tipos de estándares: estándares de protocolo que definen cómo se comunican las entidades pares en una capa dada, y estándares de servicio que definen cómo se comunica una capa dada 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 aplicación: identificación de los socios de comunicación previstos, establecimiento de la autoridad necesaria para comunicarse, determinación de la disponibilidad y autenticación de los socios, acuerdo sobre mecanismos de privacidad para la comunicación, acuerdo sobre la responsabilidad de la recuperación de errores y procedimientos para asegurar la integridad de los datos , sincronización entre procesos de aplicación que cooperan, identificación de cualquier restricción en la sintaxis (por ejemplo, conjuntos de caracteres y estructuras de datos), determinación del costo 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. ^[77]
• 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, formateo y transformaciones de propósito especial (por ejemplo, compresión de datos y cifrado de datos). ^[78]
• 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 que no libere datos a su entidad de presentación sin permiso, gestión de interacción para que las entidades de presentación puedan controlar a quién le toca realizar ciertas funciones de control, resincronización de una conexión de sesión, informe de excepciones irrecuperables a la entidad de presentación. ^[79]
• La capa de transporte proporciona una transferencia de datos fiable y transparente de una manera rentable, tal como lo requiere la calidad de servicio seleccionada. Puede admitir la multiplexación de varias conexiones de transporte en una conexión de red o dividir una conexión de transporte en varias conexiones de red. ^[80]
• La capa de red se encarga de la configuración, el mantenimiento y la liberación de rutas de red entre entidades de transporte pares. Cuando se necesitan repetidores, esta capa proporciona funciones de enrutamiento y repetidores. 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 . ^[81]
• 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 informan a la capa de red. El intercambio de unidades de enlace de datos (incluido el control de flujo) está definido por esta capa. ^[82]
• 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. ^[83]

A diferencia del esquema de capas TCP/IP, que supone una red sin conexión, RM/OSI supuso una red orientada a la conexión. ^[84] 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 la ISO se ocupaban principalmente de las redes de área amplia, por lo que el desarrollo de RM/OSI se concentró en las redes orientadas a la conexión y las redes sin conexión se mencionaron por primera vez en un apéndice a RM/OSI ^{[85] [86]} y luego se incorporaron en una actualización de RM/OSI. ^[87]

En ese momento, ^{[ ¿ cuándo? ]} el IETF tuvo que lidiar con esto y con el hecho de que Internet necesitaba protocolos que simplemente no existían. ^{[ cita requerida ]} Como resultado, el IETF desarrolló su propio proceso de estandarización basado en "consenso aproximado y código ejecutable". ^[88] El proceso de estandarización se describe en RFC  2026.

En la actualidad, la IETF se ha convertido en una organización de normalización para los protocolos que se utilizan en Internet. RM/OSI ha ampliado su modelo para incluir servicios sin conexión y, gracias a ello, tanto TCP como IP han podido convertirse en estándares internacionales. ^{[ cita requerida ]}

La imagen de un protocolo es la información que un observador no participante puede obtener al observar los mensajes del protocolo, incluyendo tanto la información explícitamente asignada por el protocolo como las inferencias hechas por el observador. ^[89] Los metadatos de protocolo no cifrados son una fuente que compone la imagen de un protocolo, y los canales secundarios, incluida la sincronización de paquetes, también contribuyen. ^[90] Diferentes observadores con diferentes puntos de vista pueden ver diferentes imágenes de un protocolo. ^{[91] La imagen de un protocolo es relevante para} la privacidad del usuario final y la extensibilidad del protocolo. ^[92]

Si alguna parte de la imagen de la red no está autenticada criptográficamente , está sujeta a modificaciones por parte de los intermediarios (es decir, los middleboxes ), lo que puede influir en el funcionamiento del protocolo. ^[90] 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 particulares). Las señales destinadas deliberadamente al consumo de intermediarios pueden dejarse autenticadas pero sin cifrar. ^[93]

La imagen del cable puede ser diseñada deliberadamente, cifrando partes que los intermediarios no deberían poder observar y proporcionando señales para lo que deberían poder. ^[94] Si las señales proporcionadas se desacoplan del funcionamiento del protocolo, pueden volverse poco fiables. ^[95] La gestión y la investigación benignas de la red se ven afectadas por el cifrado de metadatos; los diseñadores de protocolos deben equilibrar la observabilidad para la operatividad y la investigación frente a la resistencia a la osificación y la privacidad del usuario final. ^[92] 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, ^[96] y que el IETF "trabajaría para mitigar el monitoreo generalizado" en sus diseños de protocolos; ^[97] esto no se había hecho sistemáticamente anteriormente. ^[97] 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, ^[98] realizada con el acuerdo tanto del destinatario como del remitente, ^[99] autenticada en la medida de lo posible y necesario, ^[100] utilizada únicamente en la medida de su fiabilidad, ^[101] y minimizada y proporcionada a un número mínimo de entidades. ^{[102] [103]} La ingeniería de la imagen del cable 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. ^[104]

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 en gran medida a los middleboxes que son sensibles a la imagen de cable del protocolo y que pueden interrumpir o interferir con los mensajes que son válidos pero que el middlebox no reconoce correctamente. ^[105] Esto es una violación del principio de extremo a extremo . ^[106] Las causas secundarias incluyen la inflexibilidad en las implementaciones de protocolos en los puntos finales. ^[107]

La osificación es un problema importante en el diseño y la implementación de protocolos de Internet , ya que puede impedir que se implementen nuevos protocolos o extensiones en Internet, o imponer restricciones al diseño de nuevos protocolos; es posible que los nuevos protocolos deban encapsularse en un protocolo ya implementado o imitar la imagen de otro protocolo. ^[108] 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 los protocolos de transporte en Internet, ^[109] y el propio TCP se ha osificado significativamente, lo que dificulta la extensión o modificación del protocolo. ^[110]

Los métodos recomendados para prevenir la osificación incluyen el cifrado de metadatos del protocolo, ^[111] y garantizar que se ejerzan los puntos de extensión y que la variabilidad de la imagen del cable se exhiba lo más completamente posible; ^[112] remediar la osificación existente requiere coordinación entre los participantes del protocolo. ^[113] QUIC es el primer protocolo de transporte IETF que ha sido diseñado con propiedades antiosificación deliberadas. ^[89]

Los esquemas de clasificación de los protocolos suelen centrarse en el dominio de uso y la función. Como ejemplo de dominio de uso, se utilizan protocolos orientados a conexión y protocolos sin conexión en redes orientadas a 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 de modo que los paquetes puedan pasar a través de un sistema de transporte utilizando el protocolo de alto nivel.

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

En la configuración de equipos de red, a menudo se hace una distinción técnica: el término protocolo se refiere estrictamente a la capa de transporte, y 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. La conformidad con estos números de puerto es voluntaria, 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 a través de firmas de inspección.

• Listas de protocolos de red
• Protocol Builder  : herramienta de programación para crear componentes de conectividad de red

• 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 el "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 sobre la superposició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 los hosts de Internet: capas de comunicación. Internet Engineering Task Force, abreviatura de IETF. doi : 10.17487/RFC1122 . RFC 1122.Describe TCP/IP a los implementadores de software de protocolo. En particular, la introducción ofrece una descripción general de los objetivos de diseño de la suite.
• M. Ben-ari (1982). Principios de programación concurrente (10.ª edición impresa). Prentice Hall International. ISBN 0-13-701078-8.
• CAR Hoare (1985). Comunicación de procesos secuenciales (10.ª edición impresa). Prentice Hall International. ISBN 0-13-153271-5.
• RD Tennent (1981). Principios de lenguajes de programación (10.ª edición 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 de computadoras estructuradas (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 coordinados se considera perjudicial. doi : 10.17487/RFC5704 . RFC 5704.
• Farrell, Stephen; Tschofenig, Hannes (mayo de 2014). La monitorización generalizada es un ataque. doi : 10.17487/RFC7258 . RFC 7258.
• Trammell, Brian; Kuehlewind, Mirja (abril de 2019). La imagen de un protocolo de red. doi : 10.17487/RFC8546 . RFC 8546.
• Hardie, Ted, ed. (abril de 2019). Transport Protocol Path Signals (Señales de ruta del protocolo de transporte). doi : 10.17487/RFC8558 . RFC 8558.
• Fairhurst, Gorry; Perkins, Colin (julio de 2021). Consideraciones sobre la confidencialidad de los encabezados de transporte, las operaciones de red y la evolución de los protocolos de transporte de Internet. doi : 10.17487/RFC9065 . RFC 9065.
• Thomson, Martin; Pauly, Tommy (diciembre de 2021). Viabilidad a largo plazo de los mecanismos de extensión de protocolos. doi : 10.17487/RFC9170 . RFC 9170.
• Arkko, Jari; Hardie, Ted; Pauly, Tommy; Kühlewind, Mirja (julio de 2023). Consideraciones sobre la colaboración entre aplicaciones y redes mediante señales de ruta. 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 en 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). "Desosificación de la capa de transporte de Internet: un estudio y perspectivas futuras". IEEE Communications Surveys & Tutorials . 19 : 619–639. doi :10.1109/COMST.2016.2626780. hdl : 2164/8317 . S2CID  1846371.
• Moschovitis, Christos JP (1999). Historia de Internet: una cronología, desde 1843 hasta la actualidad. ABC-CLIO. ISBN 978-1-57607-118-2.

• Diccionario de protocolo de Javvin
• Descripción general de los protocolos en el campo del telecontrol con el modelo de referencia OSI