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 varios mensajes. Cada mensaje tiene un significado exacto destinado a provocar una respuesta entre una gama de posibles respuestas predeterminadas para esa situación particular. El comportamiento especificado suele ser independiente de cómo se implementará . Los protocolos de comunicación deben ser acordados por las partes involucradas. [2] Para llegar a un acuerdo, se podrá desarrollar un protocolo hasta convertirlo en una norma técnica . Un lenguaje de programación describe lo mismo para los cálculos, por lo que existe una estrecha analogía entre los protocolos y los lenguajes de programación: los protocolos son para la comunicación lo que los lenguajes de programación son para los cálculos . [3] Una formulación alternativa establece que los protocolos son para comunicar lo que los algoritmos son para la computación . [4]
A menudo, varios protocolos describen 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, son 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. El UIT-T maneja protocolos y formatos de telecomunicaciones para la red telefónica pública conmutada (PSTN). A medida que la RTPC e Internet convergen , los estándares también avanzan hacia la convergencia.
El primer uso del término protocolo en un contexto moderno de conmutación de datos se produce en abril de 1967 en un memorando titulado Un protocolo para su uso en la red de comunicaciones de datos NPL . 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. [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 definía 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 graduados, 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 mediante implementar protocolos de comunicación de nivel superior, un ejemplo temprano del concepto de capas de protocolos . [12]
La red CYCLADES , diseñada por Louis Pouzin a principios de la década de 1970, fue la primera en implementar el principio de extremo a extremo y responsabilizar a los hosts de la entrega confiable de datos en una red de conmutación de paquetes, en lugar de ser un servicio de la propia red. [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 PARC Universal Packet (PUP) para la interconexión de redes. [17]
La investigación realizada a principios de la década de 1970 por Bob Kahn y Vint Cerf condujo 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 este momento.
El Grupo de Trabajo sobre Redes Internacionales acordó un estándar de datagramas sin conexión que se presentó al CCITT en 1975 pero no fue adoptado por el CCITT ni por ARPANET. [19] La investigación internacional, en particular el trabajo de Rémi Després , contribuyó al desarrollo del estándar X.25 , basado en circuitos virtuales , por parte del CCITT en 1976. [20] [21] Los fabricantes de computadoras desarrollaron protocolos propietarios como el Systems Network de IBM. Arquitectura (SNA), DECnet y Xerox Network Systems de Digital Equipment Corporation . [22]
El software TCP fue rediseñado como una pila de protocolos modular. Originalmente denominado IP/TCP , se instaló en SATNET en 1982 y en ARPANET en enero de 1983. El desarrollo de un conjunto completo de protocolos en 1989, como se describe en RFC 1122 y RFC 1123, sentó las bases para el crecimiento de TCP. /IP como conjunto integral de protocolos como componente central de la Internet emergente . [23]
El trabajo internacional sobre un modelo de referencia para estándares de comunicación condujo al modelo OSI , publicado en 1984. Durante un período entre finales de los 80 y principios de los 90, los ingenieros, las organizaciones y las naciones se polarizaron sobre la cuestión de qué estándar , el modelo OSI o Internet. conjunto de protocolos, daría como resultado las mejores y más robustas redes informáticas. [24] [25] [26]
La información intercambiada entre dispositivos a través de una red u otros medios se rige por reglas y convenciones que pueden establecerse en las especificaciones del protocolo de comunicación. Estas especificaciones definen la naturaleza de la comunicación, los datos reales intercambiados y cualquier comportamiento dependiente del estado . En los sistemas informáticos digitales, las reglas pueden expresarse mediante algoritmos y estructuras de datos . Los protocolos sirven para comunicar lo que los algoritmos o lenguajes de programación son para 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 integrarse en el propio código del proceso. [27] [28] Por el contrario, debido a que no hay memoria compartida , los sistemas de comunicación tienen que comunicarse entre sí utilizando un medio de transmisión compartido . La transmisión no es necesariamente confiable y los sistemas individuales pueden utilizar hardware o sistemas operativos diferentes.
Para implementar un protocolo de red, los módulos de software del protocolo están interconectados 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 del protocolo puede hacerse independiente del sistema operativo . Los frameworks más conocidos son el modelo TCP/IP y el modelo OSI .
En el momento en que se desarrolló Internet, las capas de abstracción habían demostrado ser un enfoque de diseño exitoso tanto para el diseño de 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. [30] Esto dio lugar al concepto de protocolos en capas que hoy en día forma la base del diseño de protocolos. [31]
Los sistemas normalmente no utilizan un único protocolo para manejar una transmisión. En su lugar, utilizan un conjunto de protocolos cooperativos, a veces denominado conjunto 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 según la funcionalidad en grupos; por ejemplo, hay un grupo de protocolos de transporte . Las funcionalidades se asignan a las capas, y cada capa resuelve una clase distinta de problemas relacionados, por ejemplo, con funciones de aplicación, transporte, Internet y interfaz de 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 que se transmite: basados en texto y binarios. [35]
Un protocolo basado en texto o protocolo de texto sin formato representa su contenido en formato legible por humanos , a menudo en texto sin formato codificado en una codificación legible por máquina como ASCII o UTF-8 , o en formatos estructurados basados en texto como 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 la facilidad de análisis mecánico y la utilización mejorada 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 con un carácter de nueva línea (y normalmente un carácter de retorno de carro). Ejemplos de protocolos que utilizan texto plano y legible por humanos 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 requiere una 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 sólo utiliza valores correspondientes a caracteres legibles por humanos en codificación ASCII . Los protocolos binarios están destinados a ser leídos por una máquina y no por un ser humano. Los protocolos binarios tienen la ventaja de ser concisos, lo que se traduce en velocidad de transmisión e interpretación. [37]
Los binarios se han 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.
Obtener los datos a través de una red es sólo 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 tiene lugar 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 comunicación. Por tanto, los protocolos deberían especificar las normas que rigen la transmisión. En general, se debe abordar gran parte de lo siguiente: [40]
Se han aplicado principios de ingeniería de sistemas 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 conjunto de protocolos [32] dentro de un marco conceptual.
Los sistemas de comunicación funcionan simultáneamente. 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 denomina 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 electrónicos digitales 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. Por analogía, el 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 independientemente unos de otros.
En el diseño de protocolos moderno, los protocolos se superponen 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 parte específica, interactuando con las otras partes del protocolo sólo en una pequeña cantidad de formas bien definidas. La estratificación permite diseñar y probar las partes de un protocolo sin una explosión combinatoria de casos, manteniendo 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 ofrecer simplicidad y modularidad y encajan en una jerarquía burda de capas funcionales definidas en Internet Protocol Suite . [54] Los dos primeros protocolos de cooperación, 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 se desarrolló internacionalmente basándose 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.
Normalmente, el software de aplicación se basa en una sólida capa de transporte de datos. Detrás de esta capa de transporte hay un mecanismo de enrutamiento y entrega de datagramas que normalmente no tiene conexión en Internet. La retransmisión de paquetes a través de redes se produce a través de otra capa que involucra únicamente tecnologías de enlace de red, que a menudo son específicas de ciertas tecnologías de capa física, como Ethernet . La estratificación brinda oportunidades para intercambiar tecnologías cuando sea necesario; por ejemplo, los protocolos a menudo se apilan en una disposición de túnel para acomodar la conexión de redes diferentes. Por ejemplo, se puede hacer un túnel IP a través de una red de modo de transferencia asincrónica (ATM).
La estratificación de protocolos forma la base del diseño de protocolos. [31] Permite la descomposición de protocolos únicos y complejos en protocolos cooperativos más simples. [54] Cada una de las capas de protocolo resuelve una clase distinta de problemas de comunicación. Juntas, las capas forman un esquema o modelo de capas.
Los cálculos se ocupan de algoritmos y datos; La comunicación implica protocolos y mensajes; Entonces, 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 dentro y entre dos sistemas, A y B. Ambos sistemas, A y B, utilizan el mismo conjunto de protocolos. Los flujos (y protocolos) verticales están dentro del sistema y los flujos (y protocolos) de mensajes horizontales están entre sistemas. Los flujos de mensajes se rigen 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 protocolos tiene una organización en capas y su relación con la estratificación de protocolos se muestra en la figura 5.
Para enviar un mensaje en el sistema A, el módulo de software de capa superior interactúa con el módulo directamente debajo de él y entrega el mensaje que se va a encapsular. 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 del programa se divide en subproblemas. Como resultado, el software de traducción también tiene capas, lo que permite que las capas del software se diseñen de forma independiente. El mismo enfoque se puede ver en las capas TCP/IP. [56]
Los módulos 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, históricamente ha sido criticado por muchos investigadores [60] ya que abstraer la pila de protocolos de esta manera puede causar que una capa superior duplique la funcionalidad de una capa inferior, Un buen ejemplo es la recuperación de errores tanto por enlace como de extremo a extremo. [61]
Los problemas comúnmente recurrentes en el diseño e implementación de protocolos de comunicación pueden abordarse 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 comunicantes de estados finitos [69]
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 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 comúnmente se crean obteniendo la aprobación o el apoyo de una organización de estándares , que inicia el proceso de estandarización. Los miembros de la organización de normalización se comprometen a adherirse voluntariamente al resultado del trabajo. A menudo, los miembros controlan grandes cuotas de mercado relevantes para el protocolo y, en muchos casos, las normas son impuestas por la ley o 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 Síncronas Binarias (BSC) inventado por IBM . BSC es uno de los primeros protocolos a nivel de enlace que se utiliza para conectar dos nodos separados. Originalmente no estaba destinado a ser utilizado en una red multinodo, pero al hacerlo se revelaron varias deficiencias del protocolo. A falta de estandarización, los fabricantes y 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 utilizar equipos de otros fabricantes. Existen más de 50 variantes del protocolo bi-sync original. Se puede suponer que una norma habría evitado que al menos parte de esto sucediera. [29]
En algunos casos, los protocolos ganan dominio en el mercado sin pasar por un proceso de estandarización. Estos protocolos se denominan normas de facto . Los estándares de facto son comunes en los mercados emergentes, nichos de mercado o mercados monopolizados ( u oligopolizados ). Pueden mantener un mercado en una situación muy negativa, especialmente cuando se utilizan para ahuyentar a la competencia. Desde una perspectiva histórica, la normalización debería verse como una medida para contrarrestar los efectos nocivos de las normas de facto. Existen excepciones positivas; Un sistema operativo estándar de facto como Linux no tiene esta influencia negativa en su mercado, porque las fuentes se publican y mantienen de forma 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 en uso 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 que agrupa a 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 World Wide Web Consortium (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 que considerar intereses nacionales o comerciales. Las organizaciones de normalización también realizan investigación y desarrollo de 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 múltiples organismos de normalización. Si no están coordinados, el resultado puede ser definiciones múltiples e incompatibles de un protocolo, o interpretaciones múltiples e incompatibles de mensajes; invariantes importantes en una definición (por ejemplo, que los valores de tiempo de vida son monótonos decrecientes para evitar bucles de enrutamiento estables ) pueden no respetarse en otra. [71]
En ISO, el proceso de estandarización comienza con la puesta en servicio de un subcomité de trabajo. El grupo de trabajo emite borradores de trabajo y documentos de discusión a las partes interesadas (incluidos otros organismos de normalización) para provocar debates y comentarios. Esto generará muchas preguntas, mucha discusión y generalmente algún desacuerdo. Estos comentarios se tienen en cuenta y el grupo de trabajo elabora un borrador de propuesta . Después de comentarios, modificaciones y compromisos, la propuesta alcanza el estatus de borrador de norma internacional y, en última instancia, de norma internacional . Las normas internacionales se vuelven a publicar periódicamente para abordar las deficiencias y reflejar los cambios de opinión 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 propósito general y preparado para el futuro, adecuado para protocolos estructurados (como 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). [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 ajustan a las distintas especificaciones de capa. [75]
En el modelo OSI, se supone que los sistemas en comunicación 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 solicitud. Las capas se comunican entre sí mediante 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 determinada utilizan un protocolo específico de esa capa que se implementa mediante el uso de servicios de la capa inferior. [76] 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 mayor a menor capa):
A diferencia del esquema de capas TCP/IP, que supone una red sin conexión, RM/OSI asumió una red orientada a la conexión. [84] Las redes orientadas a 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 estaban principalmente preocupados por las redes de área amplia, por lo que el desarrollo de RM/OSI se concentró en redes orientadas a conexión y redes sin conexión y se mencionó por primera vez en un addendum a RM/OSI [85 ] [86] y luego se incorporó a un actualizar a 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 necesaria ] Como resultado, el IETF desarrolló su propio proceso de estandarización basado en "consenso aproximado y código en ejecución". [88] El proceso de estandarización se describe en RFC 2026.
Hoy en día, el IETF se ha convertido en una organización de estándares para los protocolos utilizados en Internet. RM/OSI ha ampliado su modelo para incluir servicios sin conexión y debido a esto, tanto TCP como IP podrían convertirse en estándares internacionales. [ cita necesaria ]
La imagen alámbrica de un protocolo es la información que un observador no participante puede obtener al observar los mensajes del protocolo, incluida tanto la información a la que el protocolo da significado explícitamente como las inferencias realizadas por el observador. [89] Los metadatos del protocolo no cifrados son una de las fuentes que componen la imagen del cable, y los canales laterales, incluida la sincronización de paquetes, también contribuyen. [90] Diferentes observadores con diferentes puntos de vista pueden ver diferentes imágenes de cables. [91] La imagen del cable es relevante para la privacidad del usuario final y la extensibilidad del protocolo. [92]
Si alguna parte de la imagen del cable no está autenticada criptográficamente , está sujeta a modificaciones por parte de partes intermedias (es decir, middleboxes ), lo que puede influir en el funcionamiento del protocolo. [90] Incluso si se autentica, si una parte no está cifrada, formará parte de la imagen del cable, y partes intermediarias pueden intervenir dependiendo de su contenido (por ejemplo, descartando paquetes con banderas particulares). Las señales destinadas deliberadamente al consumo intermediario pueden dejarse autenticadas pero sin cifrar. [93]
La imagen del cable se puede diseñar deliberadamente, cifrando partes que los intermediarios no deberían poder observar y proporcionando señales de lo que deberían poder observar. [94] Si las señales proporcionadas se desacoplan de la operación del protocolo, pueden volverse no confiables. [95] La gestión y la investigación de redes benignas 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. [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 mitigar el monitoreo generalizado" en sus diseños de protocolos; [97] esto no se había hecho sistemáticamente anteriormente. [97] La Junta de Arquitectura de Internet recomendó en 2023 que la divulgación de información mediante un protocolo a la red debe ser intencional, [98] realizada con el acuerdo tanto del destinatario como del remitente, [99] autenticada en la medida posible y necesaria, [100 ] sólo actuó en función de su confiabilidad, [101] y se minimizó y proporcionó a un número mínimo de entidades. [102] [103] Diseñar la imagen del cable y controlar qué señales se proporcionan a los elementos de la red fue un "campo en desarrollo" en 2023, según la 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 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 terminales. [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 cable 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 hace que la extensión o modificación del protocolo difícil. [110]
Los métodos recomendados para prevenir la osificación incluyen cifrar los metadatos del protocolo [111] y garantizar que se ejerciten los puntos de extensión y que la variabilidad de la imagen del cable se muestre de la manera más completa posible; [112] remediar la osificación existente requiere coordinación entre los participantes del protocolo. [113] QUIC es el primer protocolo de transporte del IETF que ha sido diseñado con propiedades antiosificación deliberadas. [89]
Los esquemas de clasificación de protocolos normalmente se centran en el dominio de uso y 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 túnel , que se utiliza para encapsular paquetes en un protocolo de alto nivel para que los paquetes puedan pasar a través de un sistema de transporte utilizando el protocolo de alto nivel.
Un esquema de capas combina función y dominio de uso. Los esquemas de estratificación dominantes son los desarrollados por el IETF y la ISO. A pesar de que los supuestos subyacentes de los esquemas de estratificación son lo suficientemente diferentes como para justificar la distinción entre los dos, es una práctica común compararlos relacionando protocolos comunes con las capas de los dos esquemas. [114] El esquema de capas del IETF se llama capas de Internet o capas TCP/IP . El esquema de capas de ISO se llama 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 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 protocolos identificados mediante firmas de inspección.
Como recuerda Kahn: ... Las contribuciones de Paul Baran ... También creo que Paul estaba motivado casi exclusivamente por consideraciones de voz.
Si nos fijamos en lo que escribió, estaba hablando de interruptores que eran productos electrónicos de bajo coste.
La idea de colocar ordenadores potentes en esos lugares no se le había ocurrido del todo como rentable.
Entonces faltaba la idea de los interruptores de computadora.
Toda la noción de protocolos no existía en ese momento.
Y la idea de las comunicaciones de computadora a computadora era en realidad una preocupación secundaria.
Había un artículo escrito por [Paul Baran] de Rand Corporation que, en cierto sentido, presagiaba la conmutación de paquetes para redes de voz y redes de voz.
[Scantlebury dijo] Claramente, Donald y Paul Baran habían llegado independientemente a una idea similar, aunque con propósitos diferentes.
Paul por una red de voz/télex que pueda sobrevivir, la nuestra por una red informática de alta velocidad.
De hecho, CYCLADES, a diferencia de ARPANET, había sido diseñado explícitamente para facilitar la interconexión de redes; podría, por ejemplo, manejar distintos formatos y distintos niveles de servicio.
Además de la red NPL y ARPANET, CYCLADES, una red académica y de investigación experimental, también desempeñó un papel importante en el desarrollo de tecnologías de redes informáticas.
A principios de la década de 1970, Pouzin creó una red de datos innovadora que conectaba ubicaciones en Francia, Italia y Gran Bretaña.
Su simplicidad y eficiencia señalaron el camino hacia una red que podría conectar no sólo docenas de máquinas, sino millones de ellas.
Capturó la imaginación del Dr. Cerf y el Dr. Kahn, quienes incluyeron aspectos de su diseño en los protocolos que ahora alimentan Internet.
Los autores desean agradecer a varios colegas por sus útiles comentarios durante las primeras discusiones sobre protocolos de redes internacionales, especialmente a R. Metcalfe, R. Scantlebury, D. Walden y H. Zimmerman;
D. Davies y L. Pouzin, quienes comentaron constructivamente las cuestiones de fragmentación y contabilidad;
y S. Crocker quien comentó sobre la creación y destrucción de asociaciones.
Este Modelo Básico de Referencia de Interconexión de Sistemas Abiertos se basa en el supuesto de que se requiere una conexión para la transferencia de datos.