La suite de protocolos de Internet , comúnmente conocida como TCP/IP , es un marco para organizar el conjunto de protocolos de comunicación utilizados en Internet y redes informáticas similares según criterios funcionales. Los protocolos fundamentales del conjunto son el Protocolo de control de transmisión (TCP), el Protocolo de datagramas de usuario (UDP) y el Protocolo de Internet (IP). Las primeras versiones de este modelo de red se conocían como modelo del Departamento de Defensa ( DoD ) porque la investigación y el desarrollo fueron financiados por el Departamento de Defensa de los Estados Unidos a través de DARPA .
El conjunto de protocolos de Internet proporciona comunicación de datos de extremo a extremo y especifica cómo se deben empaquetar, direccionar, transmitir, enrutar y recibir los datos. Esta funcionalidad está organizada en cuatro capas de abstracción , que clasifican todos los protocolos relacionados según el alcance de la red de cada protocolo. [1] [2] Una implementación de las capas para una aplicación particular forma una pila de protocolos . De menor a mayor, las capas son la capa de enlace , que contiene métodos de comunicación para los datos que permanecen dentro de un único segmento de red (enlace); la capa de Internet , que proporciona interconexión entre redes independientes; la capa de transporte , que maneja la comunicación de host a host; y la capa de aplicación , que proporciona intercambio de datos de proceso a proceso para las aplicaciones.
Los estándares técnicos subyacentes al conjunto de protocolos de Internet y sus protocolos constituyentes son mantenidos por el Grupo de Trabajo de Ingeniería de Internet (IETF). El conjunto de protocolos de Internet es anterior al modelo OSI , un marco de referencia más completo para sistemas de redes generales.
Inicialmente denominado Modelo de Arquitectura de Internet del DOD , el conjunto de protocolos de Internet tiene sus raíces en la investigación y el desarrollo patrocinados por la Agencia de Proyectos de Investigación Avanzada de Defensa ( DARPA ) a finales de los años 1960. [3] Después de que DARPA iniciara la ARPANET pionera en 1969, Steve Crocker estableció un "Grupo de Trabajo de Redes" que desarrolló un protocolo host-host, el Programa de Control de Red (NCP). [4] A principios de la década de 1970, DARPA comenzó a trabajar en varias otras tecnologías de transmisión de datos, incluida la radio móvil por paquetes, el servicio de paquetes por satélite, las redes de área local y otras redes de datos en los dominios público y privado. En 1972, Bob Kahn se unió a la Oficina de Tecnología de Procesamiento de Información de DARPA , donde trabajó tanto en redes de paquetes satelitales como en redes terrestres de paquetes de radio, y reconoció el valor de poder comunicarse a través de ambas. En la primavera de 1973, Vinton Cerf se unió a Kahn con el objetivo de diseñar la próxima generación de protocolos para ARPANET para permitir la interconexión . [5] [6] Se basaron en la experiencia de la comunidad de investigación ARPANET, el Grupo de Trabajo de Red Internacional , que presidió Cerf, y los investigadores de Xerox PARC . [7] [8] [9]
En el verano de 1973, Kahn y Cerf habían elaborado una reformulación fundamental, en la que las diferencias entre los protocolos de red local se ocultaban mediante el uso de un protocolo de red común y, en lugar de que la red fuera responsable de la confiabilidad, como en los protocolos ARPANET existentes. , esta función fue delegada a los anfitriones. Cerf atribuye importantes influencias a este diseño a Louis Pouzin y Hubert Zimmermann , diseñadores de la red CYCLADES . [10] [11] El nuevo protocolo fue implementado como Programa de Control de Transmisión en 1974 por Cerf, Yogen Dalal y Carl Sunshine. [12]
Inicialmente, el Programa de Control de Transmisión (el Protocolo de Internet no existía entonces como un protocolo separado) solo proporcionaba a sus usuarios un servicio confiable de flujo de bytes , no datagramas . [13] A medida que crecía la experiencia con el protocolo, los colaboradores recomendaron dividir la funcionalidad en capas de protocolos distintos, permitiendo a los usuarios acceso directo al servicio de datagramas. Entre sus defensores se encontraban Danny Cohen , que lo necesitaba para su trabajo de voz en paquetes ; Jonathan Postel del Instituto de Ciencias de la Información de la Universidad del Sur de California , quien editó la Solicitud de Comentarios (RFC), la serie de documentos técnicos y estratégicos que ha documentado y catalizado el desarrollo de Internet; [14] y Bob Metcalfe y Yogen Dalal en Xerox PARC. [15] [16] Postel declaró: "Estamos cometiendo un error en nuestro diseño de protocolos de Internet al violar el principio de capas". [17] La encapsulación de diferentes mecanismos tenía como objetivo crear un entorno donde las capas superiores pudieran acceder solo a lo que se necesitaba desde las capas inferiores. Un diseño monolítico sería inflexible y generaría problemas de escalabilidad. En la versión 3 de TCP, escrita en 1978, Cerf, Cohen y Postel dividieron el Programa de Control de Transmisión en dos protocolos distintos, el Protocolo de Internet como capa sin conexión y el Protocolo de Control de Transmisión como un servicio confiable orientado a la conexión . [nota 1] [18]
El diseño de la red incluyó el reconocimiento de que debería proporcionar sólo las funciones de transmitir y enrutar eficientemente el tráfico entre los nodos finales y que toda la demás inteligencia debería ubicarse en el borde de la red, en los nodos finales. Este diseño se conoce como principio de extremo a extremo . Usando este diseño, fue posible conectar otras redes a ARPANET que usaban el mismo principio, independientemente de otras características locales, resolviendo así el problema inicial de interconexión de Kahn. Una expresión popular es que TCP/IP, el producto final del trabajo de Cerf y Kahn, puede pasar por "dos latas y una cuerda". [ cita necesaria ] Años más tarde, como broma, se creó y probó con éxito la especificación del protocolo formal IP sobre Avian Carriers .
DARPA contrató a BBN Technologies , la Universidad de Stanford y el University College London para desarrollar versiones operativas del protocolo en varias plataformas de hardware. [19] Durante el desarrollo del protocolo, el número de versión de la capa de enrutamiento de paquetes avanzó de la versión 1 a la versión 4, la última de las cuales se instaló en ARPANET en 1983. Se conoció como Protocolo de Internet versión 4 (IPv4) como el protocolo que todavía se utiliza en Internet, junto con su actual sucesor, el Protocolo de Internet versión 6 (IPv6).
En 1975, se realizó una prueba de comunicaciones IP de dos redes entre Stanford y el University College de Londres. En noviembre de 1977, se llevó a cabo una prueba de IP de tres redes entre sitios de EE. UU., Reino Unido y Noruega . Se desarrollaron varios otros prototipos de propiedad intelectual en múltiples centros de investigación entre 1978 y 1983.
Una computadora llamada enrutador cuenta con una interfaz para cada red. Reenvía paquetes de red de un lado a otro entre ellos. [20] Originalmente un router se llamaba gateway , pero el término se cambió para evitar confusiones con otros tipos de gateways . [21]
En marzo de 1982, el Departamento de Defensa de Estados Unidos declaró TCP/IP como estándar para todas las redes informáticas militares. [22] [23] En el mismo año, NORSAR / NDRE y el grupo de investigación de Peter Kirstein en el University College de Londres adoptaron el protocolo. [24] La migración de ARPANET de NCP a TCP/IP se completó oficialmente el día de la bandera , el 1 de enero de 1983, cuando los nuevos protocolos se activaron permanentemente. [22] [25]
En 1985, el Consejo Asesor de Internet (más tarde Consejo de Arquitectura de Internet ) celebró un taller de tres días sobre TCP/IP para la industria informática, al que asistieron 250 representantes de proveedores, promoviendo el protocolo y conduciendo a su creciente uso comercial. En 1985, la primera conferencia Interop se centró en la interoperabilidad de redes mediante una adopción más amplia de TCP/IP. La conferencia fue fundada por Dan Lynch, uno de los primeros activistas de Internet. Desde el principio asistieron a la reunión grandes corporaciones, como IBM y DEC. [26]
IBM, AT&T y DEC fueron las primeras corporaciones importantes en adoptar TCP/IP, a pesar de tener protocolos propietarios competidores . En IBM, desde 1984, el grupo de Barry Appelman se dedicó al desarrollo de TCP/IP. Navegaron por la política corporativa para obtener un flujo de productos TCP/IP para varios sistemas IBM, incluidos MVS , VM y OS/2 . Al mismo tiempo, varias empresas más pequeñas, como FTP Software y Wollongong Group , comenzaron a ofrecer pilas TCP/IP para DOS y Microsoft Windows . [27] La primera pila TCP/IP de VM/CMS provino de la Universidad de Wisconsin. [28]
Algunas de las primeras pilas TCP/IP fueron escritas por unos pocos programadores. Jay Elinsky y Oleg Vishnepolsky de IBM Research escribieron pilas TCP/IP para VM/CMS y OS/2, respectivamente. [ cita necesaria ] En 1984, Donald Gillies en el MIT escribió un TCP de conexión múltiple ntcp que se ejecuta sobre la capa IP/PacketDriver mantenida por John Romkey en el MIT en 1983–84. Romkey aprovechó este TCP en 1986 cuando se fundó FTP Software. [29] [30] A partir de 1985, Phil Karn creó una aplicación TCP de conexión múltiple para sistemas de radioaficionados (KA9Q TCP). [31]
La difusión de TCP/IP se vio impulsada aún más en junio de 1989, cuando la Universidad de California, Berkeley, acordó colocar el código TCP/IP desarrollado para BSD UNIX en el dominio público. Varios proveedores corporativos, incluido IBM, incluyeron este código en versiones comerciales de software TCP/IP. Microsoft lanzó una pila TCP/IP nativa en Windows 95. Este evento ayudó a consolidar el dominio de TCP/IP sobre otros protocolos en redes basadas en Microsoft, que incluían Systems Network Architecture (SNA) de IBM, y en otras plataformas como Digital Equipment Corporation . DECnet , Interconexión de sistemas abiertos (OSI) y Sistemas de red Xerox (XNS).
Sin embargo, durante un período a finales de los años 1980 y principios de los años 1990, los ingenieros, las organizaciones y las naciones estuvieron polarizados 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 informáticas. [32] [33] [34]
Los estándares técnicos subyacentes al conjunto de protocolos de Internet y sus protocolos constituyentes se han delegado al Grupo de Trabajo de Ingeniería de Internet (IETF). [35]
La arquitectura característica del conjunto de protocolos de Internet es su amplia división en ámbitos operativos para los protocolos que constituyen su funcionalidad principal. La especificación que define la suite es RFC 1122, que describe en términos generales cuatro capas de abstracción . [1] Estos han resistido la prueba del tiempo, ya que el IETF nunca ha modificado esta estructura. Como modelo de red, el conjunto de protocolos de Internet es anterior al modelo OSI, un marco de referencia más completo para sistemas de red generales. [34]
El principio de extremo a extremo ha evolucionado con el tiempo. Su expresión original situaba el mantenimiento del estado y la inteligencia general en los bordes, y suponía que Internet que conectaba los bordes no conservaba ningún estado y se concentraba en la velocidad y la simplicidad. Las necesidades del mundo real de cortafuegos, traductores de direcciones de red, cachés de contenido web y similares han obligado a cambiar este principio. [36]
El principio de robustez establece: "En general, una implementación debe ser conservadora en su comportamiento de envío y liberal en su comportamiento de recepción. Es decir, debe tener cuidado de enviar datagramas bien formados, pero debe aceptar cualquier datagrama que pueda interpretar ( por ejemplo, no objetar errores técnicos cuyo significado aún esté claro)." [37] "La segunda parte del principio es casi igual de importante: el software de otros hosts puede contener deficiencias que hagan imprudente explotar características legales pero oscuras del protocolo". [38]
La encapsulación se utiliza para proporcionar abstracción de protocolos y servicios. La encapsulación suele estar alineada con la división del conjunto de protocolos en capas de funcionalidad general. En general, una aplicación (el nivel más alto del modelo) utiliza un conjunto de protocolos para enviar sus datos a través de las capas. Los datos se encapsulan aún más en cada nivel.
Uno de los primeros documentos arquitectónicos, RFC 1122, titulado Requisitos del host , enfatiza los principios arquitectónicos sobre las capas. [39] RFC 1122 está estructurado en secciones que se refieren a capas, pero el documento se refiere a muchos otros principios arquitectónicos y no enfatiza las capas. Define vagamente un modelo de cuatro capas, donde las capas tienen nombres, no números, de la siguiente manera:
Los protocolos de la capa de enlace operan dentro del alcance de la conexión de red local a la que está conectado un host. Este régimen se denomina enlace en el lenguaje TCP/IP y es la capa componente más baja de la suite. El enlace incluye todos los hosts accesibles sin atravesar un enrutador. Por tanto, el tamaño del enlace está determinado por el diseño del hardware de red. En principio, TCP/IP está diseñado para ser independiente del hardware y puede implementarse prácticamente sobre cualquier tecnología de capa de enlace. Esto incluye no sólo implementaciones de hardware sino también capas de enlace virtual, como redes privadas virtuales y túneles de red .
La capa de enlace se utiliza para mover paquetes entre las interfaces de la capa de Internet de dos hosts diferentes en el mismo enlace. Los procesos de transmisión y recepción de paquetes en el enlace se pueden controlar en el controlador del dispositivo para la tarjeta de red , así como en firmware o mediante conjuntos de chips especializados . Estos realizan funciones, como el entramado, para preparar los paquetes de la capa de Internet para la transmisión y, finalmente, transmitir las tramas a la capa física y a través de un medio de transmisión . El modelo TCP/IP incluye especificaciones para traducir los métodos de direccionamiento de red utilizados en el Protocolo de Internet a direcciones de capa de enlace, como direcciones de control de acceso a medios (MAC). Sin embargo, se supone implícitamente que todos los demás aspectos por debajo de ese nivel existen y no están definidos explícitamente en el modelo TCP/IP.
La capa de enlace en el modelo TCP/IP tiene funciones correspondientes en la Capa 2 del modelo OSI.
La conexión a Internet requiere enviar datos desde la red de origen a la red de destino. Este proceso se denomina enrutamiento y está respaldado por el direccionamiento y la identificación del host mediante el sistema de direccionamiento IP jerárquico . La capa de Internet proporciona una instalación de transmisión de datagramas poco confiable entre hosts ubicados en redes IP potencialmente diferentes al reenviar datagramas a un enrutador de siguiente salto apropiado para su posterior retransmisión a su destino. La capa de Internet tiene la responsabilidad de enviar paquetes a través de redes potencialmente múltiples. Con esta funcionalidad, la capa de Internet hace posible la interconexión de diferentes redes IP y, esencialmente, establece Internet.
La capa de Internet no distingue entre los distintos protocolos de la capa de transporte. IP transporta datos para una variedad de protocolos de capa superior diferentes . Cada uno de estos protocolos se identifica mediante un número de protocolo único : por ejemplo, el Protocolo de mensajes de control de Internet (ICMP) y el Protocolo de administración de grupos de Internet (IGMP) son los protocolos 1 y 2, respectivamente.
El Protocolo de Internet es el componente principal de la capa de Internet y define dos sistemas de direccionamiento para identificar los hosts de la red y ubicarlos en la red. El sistema de direcciones original de ARPANET y su sucesor, Internet, es el Protocolo de Internet versión 4 (IPv4). Utiliza una dirección IP de 32 bits y, por tanto, es capaz de identificar aproximadamente cuatro mil millones de hosts. Esta limitación fue eliminada en 1998 mediante la estandarización del Protocolo de Internet versión 6 (IPv6), que utiliza direcciones de 128 bits. Las implementaciones de producción de IPv6 surgieron aproximadamente en 2006.
La capa de transporte establece canales de datos básicos que las aplicaciones utilizan para el intercambio de datos de tareas específicas. La capa establece conectividad de host a host en forma de servicios de transferencia de mensajes de extremo a extremo que son independientes de la red subyacente y de la estructura de los datos del usuario y de la logística del intercambio de información. La conectividad en la capa de transporte se puede clasificar como orientada a conexión , implementada en TCP, o sin conexión , implementada en UDP. Los protocolos en esta capa pueden proporcionar control de errores , segmentación , control de flujo , control de congestión y direccionamiento de aplicaciones ( números de puerto ).
Con el fin de proporcionar canales de transmisión específicos de procesos para aplicaciones, la capa establece el concepto de puerto de red . Se trata de una construcción lógica numerada asignada específicamente para cada uno de los canales de comunicación que necesita una aplicación. Para muchos tipos de servicios, estos números de puerto se han estandarizado para que las computadoras cliente puedan abordar servicios específicos de una computadora servidor sin la participación de descubrimiento de servicios o servicios de directorio .
Debido a que IP proporciona sólo una entrega con el mejor esfuerzo , algunos protocolos de capa de transporte ofrecen confiabilidad.
TCP es un protocolo orientado a la conexión que aborda numerosos problemas de confiabilidad al proporcionar un flujo de bytes confiable :
El nuevo protocolo de transmisión de control de flujo (SCTP) también es un mecanismo de transporte confiable y orientado a la conexión. Está orientado al flujo de mensajes, no al flujo de bytes como TCP, y proporciona múltiples flujos multiplexados a través de una única conexión. También proporciona soporte multihoming , en el que el extremo de una conexión puede representarse mediante múltiples direcciones IP (que representan múltiples interfaces físicas), de modo que si una falla, la conexión no se interrumpe. Fue desarrollado inicialmente para aplicaciones de telefonía (para transportar SS7 sobre IP).
La confiabilidad también se puede lograr ejecutando IP a través de un protocolo de enlace de datos confiable, como el Control de enlace de datos de alto nivel (HDLC).
El Protocolo de datagramas de usuario (UDP) es un protocolo de datagramas sin conexión . Al igual que IP, es un protocolo poco fiable y de mejor esfuerzo. La confiabilidad se aborda mediante la detección de errores mediante un algoritmo de suma de verificación. UDP se utiliza normalmente para aplicaciones como transmisión de medios (audio, vídeo, voz sobre IP , etc.) donde la llegada a tiempo es más importante que la confiabilidad, o para aplicaciones simples de consulta/respuesta como búsquedas de DNS , donde la sobrecarga de configuración una conexión confiable es desproporcionadamente grande. El protocolo de transporte en tiempo real (RTP) es un protocolo de datagramas que se utiliza sobre UDP y está diseñado para datos en tiempo real, como la transmisión de medios .
Las aplicaciones en cualquier dirección de red determinada se distinguen por su puerto TCP o UDP. Por convención, ciertos puertos conocidos están asociados con aplicaciones específicas.
La capa de transporte o de host a host del modelo TCP/IP corresponde aproximadamente a la cuarta capa del modelo OSI, también llamada capa de transporte.
QUIC está emergiendo rápidamente como un protocolo de transporte alternativo. Aunque técnicamente se transporta a través de paquetes UDP, busca ofrecer una conectividad de transporte mejorada en relación con TCP. HTTP/3 funciona exclusivamente a través de QUIC.
La capa de aplicación incluye los protocolos utilizados por la mayoría de las aplicaciones para proporcionar servicios de usuario o intercambiar datos de aplicaciones a través de las conexiones de red establecidas por los protocolos de nivel inferior. Esto puede incluir algunos servicios básicos de soporte de red, como protocolos de enrutamiento y configuración de host. Ejemplos de protocolos de capa de aplicación incluyen el Protocolo de transferencia de hipertexto (HTTP), el Protocolo de transferencia de archivos (FTP), el Protocolo simple de transferencia de correo (SMTP) y el Protocolo de configuración dinámica de host (DHCP). [44] Los datos codificados según los protocolos de la capa de aplicación se encapsulan en unidades de protocolo de la capa de transporte (como flujos TCP o datagramas UDP), que a su vez utilizan protocolos de capa inferior para efectuar la transferencia de datos real.
El modelo TCP/IP no considera los detalles de formateo y presentación de datos y no define capas adicionales entre las capas de aplicación y transporte como en el modelo OSI (capas de presentación y sesión). Según el modelo TCP/IP, dichas funciones pertenecen al ámbito de las bibliotecas y las interfaces de programación de aplicaciones . La capa de aplicación en el modelo TCP/IP a menudo se compara con una combinación de las capas quinta (sesión), sexta (presentación) y séptima (aplicación) del modelo OSI.
Los protocolos de capa de aplicación a menudo están asociados con aplicaciones cliente-servidor particulares , y los servicios comunes tienen números de puerto bien conocidos reservados por la Autoridad de Números Asignados de Internet (IANA). Por ejemplo, el Protocolo de transferencia de hipertexto utiliza el puerto de servidor 80 y Telnet utiliza el puerto de servidor 23. Los clientes que se conectan a un servicio suelen utilizar puertos efímeros , es decir, números de puerto asignados sólo durante la duración de la transacción de forma aleatoria o de un rango específico configurado en el solicitud.
En la capa de aplicación, el modelo TCP/IP distingue entre protocolos de usuario y protocolos de soporte . [45] Los protocolos de soporte proporcionan servicios a un sistema de infraestructura de red. Los protocolos de usuario se utilizan para aplicaciones de usuario reales. Por ejemplo, FTP es un protocolo de usuario y DNS es un protocolo de soporte.
Aunque las aplicaciones suelen conocer las cualidades clave de la conexión de la capa de transporte, como las direcciones IP de los terminales y los números de puerto, los protocolos de la capa de aplicación generalmente tratan los protocolos de la capa de transporte (y los inferiores) como cajas negras que proporcionan una conexión de red estable a través de la cual comunicarse. . La capa de transporte y las capas de nivel inferior no se preocupan por los detalles de los protocolos de la capa de aplicación. Los enrutadores y conmutadores no suelen examinar el tráfico encapsulado, sino que simplemente proporcionan un conducto para él. Sin embargo, algunas aplicaciones de firewall y limitación de ancho de banda utilizan una inspección profunda de paquetes para interpretar los datos de la aplicación. Un ejemplo es el Protocolo de reserva de recursos (RSVP). [ cita necesaria ] A veces también es necesario que las aplicaciones afectadas por NAT consideren la carga útil de la aplicación.
El conjunto de protocolos de Internet evolucionó gracias a la investigación y el desarrollo financiados durante un período de tiempo. En este proceso, las características específicas de los componentes del protocolo y sus capas cambiaron. Además, la investigación paralela y los intereses comerciales de las asociaciones industriales competían con las características del diseño. En particular, los esfuerzos de la Organización Internacional de Normalización condujeron a un objetivo similar, pero con un alcance más amplio de creación de redes en general. Los esfuerzos por consolidar las dos escuelas principales de estratificación, que eran superficialmente similares, pero divergían marcadamente en los detalles, llevaron a autores de libros de texto independientes a formular herramientas de enseñanza abreviadas.
La siguiente tabla muestra varios modelos de redes de este tipo. El número de capas varía entre tres y siete.
Algunos de los modelos de redes provienen de libros de texto, que son fuentes secundarias que pueden entrar en conflicto con la intención del RFC 1122 y otras fuentes primarias del IETF . [54]
Las tres capas superiores del modelo OSI, es decir, la capa de aplicación, la capa de presentación y la capa de sesión, no se distinguen por separado en el modelo TCP/IP, que sólo tiene una capa de aplicación por encima de la capa de transporte. Si bien algunas aplicaciones de protocolo OSI puro, como X.400 , también los combinan, no existe ningún requisito de que una pila de protocolo TCP/IP deba imponer una arquitectura monolítica por encima de la capa de transporte. Por ejemplo, el protocolo de aplicación NFS se ejecuta sobre el protocolo de presentación de representación de datos externos (XDR), que, a su vez, se ejecuta sobre un protocolo llamado llamada a procedimiento remoto (RPC). RPC proporciona una transmisión de registros confiable, por lo que puede utilizar de manera segura el transporte UDP de mejor esfuerzo.
Diferentes autores han interpretado el modelo TCP/IP de manera diferente y no están de acuerdo sobre si la capa de enlace, o cualquier aspecto del modelo TCP/IP, cubre cuestiones de la capa 1 ( capa física ) OSI, o si TCP/IP supone que existe una capa de hardware debajo de la capa física. capa de enlace.
Varios autores han intentado incorporar las capas 1 y 2 del modelo OSI en el modelo TCP/IP, ya que se hace referencia a ellas comúnmente en los estándares modernos (por ejemplo, por IEEE e ITU ). Esto a menudo da como resultado un modelo con cinco capas, donde la capa de enlace o la capa de acceso a la red se divide en las capas 1 y 2 del modelo OSI.
El esfuerzo de desarrollo del protocolo IETF no se ocupa de la estratificación estricta. Es posible que algunos de sus protocolos no encajen claramente en el modelo OSI, aunque los RFC a veces hacen referencia a él y suelen utilizar los números de capa OSI antiguos. El IETF ha declarado repetidamente [55] que el desarrollo de arquitectura y protocolo de Internet no pretende ser compatible con OSI. RFC 3439, que se refiere a la arquitectura de Internet, contiene una sección titulada: "Capas consideradas dañinas".
Por ejemplo, las capas de sesión y presentación de la suite OSI se consideran incluidas en la capa de aplicación de la suite TCP/IP. La funcionalidad de la capa de sesión se puede encontrar en protocolos como HTTP y SMTP y es más evidente en protocolos como Telnet y el Protocolo de inicio de sesión (SIP). La funcionalidad de la capa de sesión también se logra con la numeración de puertos de los protocolos TCP y UDP, que se incluyen en la capa de transporte de la suite TCP/IP. Las funciones de la capa de presentación se realizan en las aplicaciones TCP/IP con el estándar MIME en el intercambio de datos.
Otra diferencia está en el tratamiento de los protocolos de enrutamiento . El protocolo de enrutamiento OSI IS-IS pertenece a la capa de red y no depende de CLNS para entregar paquetes de un enrutador a otro, pero define su propia encapsulación de capa 3. Por el contrario, OSPF , RIP , BGP y otros protocolos de enrutamiento definidos por el IETF se transportan a través de IP y, para enviar y recibir paquetes de protocolos de enrutamiento, los enrutadores actúan como hosts. Como consecuencia, RFC 1812 incluye protocolos de enrutamiento en la capa de aplicación. Algunos autores, como Tanenbaum en Computer Networks , describen protocolos de enrutamiento en la misma capa que IP, razonando que los protocolos de enrutamiento informan las decisiones tomadas por el proceso de reenvío de los enrutadores.
Los protocolos IETF se pueden encapsular de forma recursiva, como lo demuestran los protocolos de túnel como Generic Routing Encapsulation (GRE). GRE utiliza el mismo mecanismo que utiliza OSI para crear túneles en la capa de red.
El conjunto de protocolos de Internet no presupone ningún entorno de hardware o software específico. Solo requiere que exista una capa de hardware y software que sea capaz de enviar y recibir paquetes en una red informática. Como resultado, la suite se ha implementado prácticamente en todas las plataformas informáticas. Una implementación mínima de TCP/IP incluye lo siguiente: Protocolo de Internet (IP), Protocolo de resolución de direcciones (ARP), Protocolo de mensajes de control de Internet (ICMP), Protocolo de control de transmisión (TCP), Protocolo de datagramas de usuario (UDP) y Gestión de grupos de Internet. Protocolo (IGMP). Además de IP, ICMP, TCP, UDP, el protocolo de Internet versión 6 requiere el protocolo de descubrimiento de vecinos (NDP), ICMPv6 y el descubrimiento de escuchas de multidifusión (MLD) y suele ir acompañado de una capa de seguridad IPSec integrada.
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.
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.
Comenzamos a realizar implementaciones simultáneas en Stanford, BBN y University College London.
Por eso, el esfuerzo por desarrollar los protocolos de Internet fue internacional desde el principio.
Marzo de 1982: Noruega abandona ARPANET y se convierte en una conexión a Internet mediante TCP/IP sobre SATNET.
Noviembre de 1982: UCL abandona ARPANET y se convierte en una conexión a Internet.
redes.
