Hispanopedia Wiki
Articulo de referencia

conjunto de protocolos de Internet

El conjunto de protocolos de Internet , comúnmente conocido como TCP/IP , es un marco para organizar los protocolos de comunicación utilizados en Internet y redes informáticas s...

Hispanopedia WikiContenido en espanolLectura gratuita

El conjunto de protocolos de Internet , comúnmente conocido como TCP/IP , es un marco para organizar los protocolos de comunicación utilizados en Internet y redes informáticas similares según criterios funcionales. Los protocolos fundamentales de este 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 el Modelo de Arquitectura de Internet del Departamento de Defensa ( DoD ) porque la investigación y el desarrollo fueron financiados por la Agencia de Proyectos de Investigación Avanzada de Defensa (DARPA) del Departamento de Defensa de los Estados Unidos .

El conjunto de protocolos de Internet proporciona comunicación de datos de extremo a extremo especificando 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 red de cada protocolo. [ 1 ] [ 2 ] Una implementación de las capas para una aplicación particular forma una pila de protocolos . De más bajo a más alto, las capas son la capa de enlace , que contiene métodos de comunicación para 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.

El Grupo de Trabajo de Ingeniería de Internet (IETF) mantiene los estándares técnicos que sustentan el conjunto de protocolos de Internet y sus protocolos constituyentes . El conjunto de protocolos de Internet es anterior al modelo OSI , un marco de referencia más completo para sistemas de redes generales.

Historia

Investigación temprana

Una furgoneta de radio por paquetes de SRI International , utilizada para la primera transmisión interconectada de tres vías.

El conjunto de protocolos de Internet tiene sus raíces en la investigación y el desarrollo de redes informáticas patrocinados por la Agencia de Proyectos de Investigación Avanzada de Defensa ( DARPA ) a finales de la década de 1960. En agosto de 1968, ARPA seleccionó a BBN para construir los Procesadores de Mensajes de Interfaz (IMP) para ARPANET , el precursor de la Internet moderna. [ 3 ] [ nb 1 ] Los IMP fueron la primera generación de pasarelas , conocidas hoy como enrutadores . Bajo el liderazgo de Frank Heart y Bob Kahn , se produjeron cuatro IMP por casi 1 millón de dólares estadounidenses entre septiembre y diciembre de 1969. [ 5 ] [ 6 ] El primer IMP se envió a la Universidad de California, Los Ángeles en septiembre de 1969 y el segundo al Instituto de Investigación de Stanford un mes después. [ 7 ] El primer mensaje entre los dos IMP fue "LO" — fonéticamente, "Hola" — pero el host del SRI falló antes de que el investigador de la UCLA pudiera terminar de escribir el comando "LOGIN". [ 8 ] [ 9 ]

After DARPA initiated the pioneering ARPANET in 1969, Steve Crocker established a "Network Working Group" which developed a host-host protocol, the Network Control Program (NCP).[10] In the early 1970s, DARPA started work on several other data transmission technologies, including mobile packet radio, packet satellite service, local area networks, and other data networks in the public and private domains. In 1972, Bob Kahn joined the DARPA Information Processing Technology Office, where he worked on both satellite packet networks and ground-based radio packet networks, and recognized the value of being able to communicate across both. In the spring of 1973, Vinton Cerf, at Stanford University, began collaborating with Kahn on the goal of designing the next protocol generation for the ARPANET to enable internetworking.[11][12] They drew on the experience the international research community, through the International Network Working Group (INWG), chaired by Cerf, which included researchers from the ARPANET community, Xerox PARC, the United Kingdom and France.[13][14][15]

During the summer of 1973, Kahn and Cerf worked out a fundamental reformulation, in which the differences between local network protocols were hidden by using a common internetwork protocol, and, instead of the network being responsible for reliability, as in the existing ARPANET protocols, this function was delegated to the hosts.[15] Cerf and Kahn credit several members of INWG with important influences on this design, which was published in May 1974.[16] The first specification of this Transmission Control Program was written in December 1974 by Cerf, Yogen Dalal and Carl Sunshine at Stanford University.[17]

DARPA contrató a BBN Technologies , la Universidad de Stanford y el University College London para comenzar a desarrollar versiones operativas del protocolo en varias plataformas de hardware en 1975. [ 18 ] Varias versiones se desarrollaron a través de discusiones a través de la serie de Notas de Experimentos de Internet (IEN). [ 19 ] Inicialmente, el Programa de Control de Transmisión, el precursor del conjunto de protocolos posterior, proporcionaba solo un servicio confiable de flujo de bytes , no datagramas . [ 20 ] A medida que crecía la experiencia con el protocolo, los colaboradores recomendaron dividir la funcionalidad en capas de protocolos distintos, proporcionando acceso directo al servicio de datagramas. Entre los defensores se encontraban Bob Metcalfe , Yogen Dalal y John Shoch en Xerox PARC; [ 21 ] [ 22 ] [ 23 ] Danny Cohen , quien lo necesitaba para su trabajo de voz por paquetes ; y Jonathan Postel del Instituto de Ciencias de la Información de la Universidad del Sur de California , quien editó las Solicitudes de Comentarios (RFC), la serie de documentos técnicos y estratégicos que ha documentado y catalizado el desarrollo de Internet. [ 24 ] Postel afirmó: «Estamos cometiendo errores en el diseño de los protocolos de Internet al violar el principio de capas». [ 25 ] La encapsulación de diferentes mecanismos tenía como objetivo crear un entorno donde las capas superiores pudieran acceder solo a lo necesario de las capas inferiores. Un diseño monolítico sería inflexible y generaría problemas de escalabilidad. En la versión 4 , escrita en 1978, Postel dividió el Programa de Control de Transmisión en dos protocolos distintos: el Protocolo de Internet (IP) como una capa sin conexión y el Protocolo de Control de Transmisión (TCP) como un servicio confiable orientado a la conexión . [ 26 ] [ 27 ] [ 28 ] [ nb 2 ]

Diagrama de la primera conexión interconectada. Un martes lluvioso, 22 de noviembre de 1977, los datos fluyeron desde la furgoneta hasta SRI en Menlo Park y la Universidad del Sur de California a través de Inglaterra, Boston y Suecia mediante tres tipos de redes: radio por paquetes, red satelital y ARPANET. [ 29 ]

El diseño de la red incluía el reconocimiento de que debía proporcionar únicamente las funciones de transmisión y enrutamiento eficiente del tráfico entre nodos finales, y que toda la demás inteligencia debía ubicarse en el borde de la red, en los nodos finales. Este principio de extremo a extremo fue impulsado por Louis Pouzin y Hubert Zimmermann en la red CYCLADES , [ 30 ] [ 31 ] basado en las ideas de Donald Davies . [ 32 ] [ 33 ] Mediante este diseño, fue posible conectar otras redes a ARPANET que utilizaban el mismo principio, independientemente de otras características locales, resolviendo así el problema inicial de interconexión de Kahn. Virginia Travers , quien había escrito el primer software de puerta de enlace para TCP, pasó meses viajando a sitios de EE. UU. y Europa para instalar el software en los puntos necesarios para la gran prueba, como el University College London y el Norwegian Defense Research Establishment en Oslo para la conexión de la Atlantic Satellite Network. [ 34 ]

El Protocolo de Internet versión 4 (IPv4) se instaló en ARPANET en 1983, formando los protocolos de capa de red utilizados en Internet. Inicialmente conocido como el Modelo de Arquitectura de Internet del DOD , [ 35 ] junto con el Protocolo de Control de Transmisión, se hizo comúnmente conocido como TCP/IP .

Implementación temprana

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 IP de tres redes entre sedes en Estados Unidos, Reino Unido y Noruega. Entre 1978 y 1983, se desarrollaron varios otros prototipos IP en diversos centros de investigación. [ 19 ]

Un ordenador llamado enrutador dispone de una interfaz para cada red. Reenvía paquetes de red entre ellas. [ 36 ] Originalmente, un enrutador se denominaba puerta de enlace , pero el término se cambió para evitar confusiones con otros tipos de puertas de enlace . [ 37 ]

Adopción

In March 1982, the US Department of Defense declared TCP/IP as the standard for all military computer networking.[38][39][40] In the same year, Norway (NORSAR and NDRE) and Peter Kirstein's research group at University College London adopted the protocol.[41] The migration of the ARPANET from NCP to TCP/IP was officially completed on flag day January 1, 1983, when the new protocols were permanently activated.[38][42]

In 1985, the Internet Advisory Board (later Internet Architecture Board) held a three-day TCP/IP workshop for the computer industry, attended by 250 vendor representatives, promoting the protocol and leading to its increasing commercial use. In 1985, the first Interop conference focused on network interoperability by broader adoption of TCP/IP. The conference was founded by Dan Lynch, an early Internet activist. From the beginning, large corporations, such as IBM and DEC, attended the meeting.[43][44]

IBM, AT&T and DEC were the first major corporations to adopt TCP/IP, this despite having competing proprietary protocols. In IBM, from 1984, Barry Appelman's group did TCP/IP development. They navigated the corporate politics to get a stream of TCP/IP products for various IBM systems, including MVS, VM, and OS/2. At the same time, several smaller companies, such as FTP Software and the Wollongong Group, began offering TCP/IP stacks for DOS and Microsoft Windows.[45] The first VM/CMS TCP/IP stack came from the University of Wisconsin.[46]

Some programmers are notable for early TCP/IP stack implementations. Jay Elinsky and Oleg Vishnepolsky of IBM Research wrote software for VM/CMS and OS/2, respectively.[47] In 1984, Donald Gillies at MIT wrote a ntcp multi-connection TCP which runs atop the IP/PacketDriver layer maintained by John Romkey at MIT in 1983–84. Romkey leveraged this TCP in 1986 when FTP Software was founded.[48][49] Starting in 1985, Phil Karn created a multi-connection TCP application for ham radio systems (KA9Q TCP).[50]

The spread of TCP/IP was fueled further in June 1989, when the University of California, Berkeley agreed to place the TCP/IP code developed for BSD UNIX into the public domain. Various corporate vendors, including IBM, included this code in commercial TCP/IP software releases. For Windows 3.1, the dominant PC operating system among consumers in the first half of the 1990s, Peter Tattam's release of the Trumpet Winsock TCP/IP stack was key to bringing the Internet to home users. Trumpet Winsock allowed TCP/IP operations over a serial connection (SLIP or PPP). The typical home PC of the time had an external Hayes-compatible modem connected via an RS-232 port with an 8250 or 16550 UART which required this type of stack. Later, Microsoft would release their own TCP/IP add-on stack for Windows for Workgroups 3.11 and a native stack in Windows 95. These events helped cement TCP/IP's dominance over other protocols on Microsoft-based networks, which included IBM's Systems Network Architecture (SNA), and on other platforms such as Digital Equipment Corporation's DECnet, Open Systems Interconnection (OSI), and Xerox Network Systems (XNS).

Nonetheless, for a period in the late 1980s and early 1990s, engineers, organizations and nations were polarized over the issue of which standard, the OSI model or the Internet protocol suite, would result in the best and most robust computer networks.[51][52][53]

Formal specification and standards

The technical standards underlying the Internet protocol suite and its constituent protocols have been delegated to the Internet Engineering Task Force (IETF).[54][55]

The characteristic architecture of the Internet protocol suite is its broad division into operating scopes for the protocols that constitute its core functionality. The defining specifications of the suite are RFC 1122 and 1123, which broadly outlines four abstraction layers (as well as related protocols); the link layer, IP layer, transport layer, and application layer, along with support protocols.[1][2] These have stood the test of time, as the IETF has never modified this structure. As such a model of networking, the Internet protocol suite predates the OSI model, a more comprehensive reference framework for general networking systems.[53]

A successor Internet Protocol version 6 (IPv6) was developed to address issues such as IPv4 address exhaustion.[56]

Key architectural principles

Conceptual data flow in a simple network topology of two hosts (A and B) connected by a link between their respective routers. The application on each host executes read and write operations as if the processes were directly connected to each other by some kind of data pipe. After establishment of this pipe, most details of the communication are hidden from each process, as the underlying principles of communication are implemented in the lower protocol layers. In analogy, at the transport layer the communication appears as host-to-host, without knowledge of the application data structures and the connecting routers, while at the internetworking layer, individual network boundaries are traversed at each router.
Encapsulation of application data descending through the layers described in RFC 1122

The end-to-end principle has evolved over time. Its original expression put the maintenance of state and overall intelligence at the edges, and assumed the Internet that connected the edges retained no state and concentrated on speed and simplicity. Real-world needs for firewalls, network address translators, web content caches and the like have forced changes in this principle.[57]

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 sea claro)». [ 58 ] : 23 «La segunda parte del principio es casi igual de importante: el software en otros hosts puede contener deficiencias que hacen que no sea prudente explotar características de protocolo legales pero oscuras». [ 1 ] : 13

La encapsulación se utiliza para abstraer protocolos y servicios. Generalmente, la encapsulación se alinea 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.

Un par de documentos arquitectónicos tempranos, RFC 1122 y 1123 , titulados Requisitos para hosts de Internet , enfatizan los principios arquitectónicos sobre la estratificación. [ 59 ] Los RFC 1122/23 están estructurados en secciones que hacen referencia a capas, pero los documentos hacen referencia a muchos otros principios arquitectónicos y no enfatizan la estratificación. Definen vagamente un modelo de cuatro capas, con capas que tienen nombres, no números, como sigue: [ 1 ] [ 2 ] 

  • La capa de aplicación es el ámbito dentro del cual las aplicaciones, o procesos , crean datos de usuario y comunican estos datos a otras aplicaciones en otro host o en el mismo. Las aplicaciones utilizan los servicios proporcionados por las capas inferiores subyacentes, especialmente la capa de transporte, que proporciona canales fiables o no fiables a otros procesos. Los socios de comunicación se caracterizan por la arquitectura de la aplicación, como el modelo cliente-servidor y las redes peer-to-peer . Esta es la capa en la que operan todos los protocolos de aplicación, como SMTP, FTP, SSH y HTTP. Los procesos se direccionan a través de puertos que representan esencialmente servicios .
  • La capa de transporte realiza comunicaciones entre hosts en la red local o en redes remotas separadas por enrutadores. [ 60 ] Proporciona un canal para las necesidades de comunicación de las aplicaciones. El Protocolo de Datagramas de Usuario (UDP) es el protocolo más básico de la capa de transporte, que proporciona un servicio de datagramas sin conexión y no confiable . El Protocolo de Control de Transmisión (TCP) proporciona control de flujo, establecimiento de conexión y transmisión confiable de datos.
  • La capa de Internet intercambia datagramas a través de los límites de la red. Proporciona una interfaz de red uniforme que oculta la topología (diseño) real de las conexiones de red subyacentes. Por lo tanto, también es la capa que establece la interconexión de redes. De hecho, define y establece Internet. Esta capa define las estructuras de direccionamiento y enrutamiento utilizadas para el conjunto de protocolos TCP/IP. El protocolo principal en este ámbito es el Protocolo de Internet, que define las direcciones IP . [ 61 ] [ 62 ] Su función en el enrutamiento es transportar datagramas al siguiente host, que funciona como un enrutador IP, que tiene conectividad con una red más cercana al destino final de los datos. [ 62 ]
  • La capa de enlace define los métodos de red dentro del ámbito del enlace de red local en el que los hosts se comunican sin enrutadores intermedios. Esta capa incluye los protocolos utilizados para describir la topología de la red local y las interfaces necesarias para efectuar la transmisión de datagramas de la capa de Internet a los hosts vecinos. [ 63 ]

Los protocolos de la capa de enlace operan dentro del ámbito de la conexión de red local a la que está conectado un host. Este régimen se denomina enlace en la terminología TCP/IP y es la capa de componentes más baja del conjunto. El enlace incluye todos los hosts accesibles sin pasar por un enrutador. Por lo tanto, el tamaño del enlace viene determinado por el diseño del hardware de red. En principio, TCP/IP está diseñado para ser independiente del hardware y puede implementarse sobre prácticamente cualquier tecnología de capa de enlace. Esto incluye no solo implementaciones de hardware, sino también capas de enlace virtuales, como redes privadas virtuales y túneles de red .

La capa de enlace se utiliza para transferir 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 mediante el controlador del dispositivo para la tarjeta de red , así como mediante el firmware o chipsets especializados . Estos realizan funciones, como el encuadre, para preparar los paquetes de la capa de Internet para su transmisión y, finalmente, transmiten las tramas a la capa física 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 la capa de enlace, como las direcciones MAC ( control de acceso al medio ). Sin embargo, todos los demás aspectos por debajo de ese nivel se asumen implícitamente y no se definen 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.

capa de Internet

La interconexión de redes requiere el envío de datos desde la red de origen a la red de destino. Este proceso se denomina enrutamiento y se basa en el direccionamiento e identificación de hosts mediante el sistema de direccionamiento IP jerárquico . La capa de internet proporciona un mecanismo de transmisión de datagramas, aunque no fiable, entre hosts ubicados en redes IP potencialmente diferentes, reenviando los datagramas a un enrutador de siguiente salto adecuado para su posterior retransmisión a su destino. La capa de internet se encarga de enviar paquetes a través de múltiples redes. Gracias a esta funcionalidad, la capa de internet posibilita la interconexión de diferentes redes IP y, en esencia, constituye la base de internet.

La capa de Internet no distingue entre los distintos protocolos de la capa de transporte. IP transporta datos para diversos protocolos de capas superiores . 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 (IP) 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 ella. El sistema de direccionamiento original de ARPANET y su sucesor, Internet, es el Protocolo de Internet versión 4 (IPv4). Este utiliza una dirección IP de 32 bits y, por lo tanto, es capaz de identificar aproximadamente cuatro mil millones de hosts. Esta limitación se eliminó en 1998 con la estandarización del Protocolo de Internet versión 6 (IPv6), que utiliza direcciones de 128 bits. Las implementaciones de IPv6 en producción surgieron alrededor de 2006.

capa de transporte

La capa de transporte establece canales de datos que las aplicaciones utilizan para el intercambio de datos específicos de cada tarea. Esta capa establece conectividad entre hosts mediante servicios de transferencia de mensajes de extremo a extremo, independientes de la red subyacente, 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 la conexión (implementada en TCP) o sin conexión (implementada en UDP). Los protocolos de 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 para cada proceso de las aplicaciones, la capa establece el concepto de puerto de red . Se trata de una estructura lógica numerada asignada específicamente a 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 los equipos cliente puedan acceder a servicios específicos de un servidor sin necesidad de descubrimiento de servicios ni servicios de directorio .

Dado que el protocolo IP solo ofrece una entrega de mejor esfuerzo , algunos protocolos de la 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 :

  • Los datos llegan en orden.
  • Los datos tienen un error mínimo (es decir, son correctos).
  • Los datos duplicados se descartan.
  • Los paquetes perdidos o descartados se reenvían.
  • incluye el control de la congestión del tráfico

El protocolo SCTP (Stream Control Transmission Protocol ) es un mecanismo de transporte fiable y orientado a la conexión. Se basa en flujos de mensajes, a diferencia de TCP, que se basa en flujos de bytes, y permite la multiplexación de múltiples flujos a través de una única conexión. Además, ofrece soporte para multiconexión , donde un extremo de la conexión puede representarse mediante varias direcciones IP (que representan múltiples interfaces físicas), de modo que si una falla, la conexión no se interrumpe. Inicialmente, se desarrolló para aplicaciones de telefonía (para transportar SS7 sobre IP).

La fiabilidad también se puede lograr ejecutando IP sobre un protocolo de enlace de datos fiable, 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 de mejor esfuerzo y no confiable. La confiabilidad se aborda mediante la detección de errores utilizando un algoritmo de suma de verificación. UDP se usa típicamente para aplicaciones como transmisión de medios (audio, video, 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 DNS , donde la sobrecarga de establecer una conexión confiable es desproporcionadamente grande. El Protocolo de Transporte en Tiempo Real (RTP) es un protocolo de datagramas que se usa sobre UDP y está diseñado para datos en tiempo real como transmisión de medios .

Las aplicaciones en una dirección de red determinada se distinguen por su puerto TCP o UDP. Por convención, ciertos puertos conocidos se asocian con aplicaciones específicas.

La capa de transporte o de host a host del modelo TCP/IP se corresponde aproximadamente con la cuarta capa del modelo OSI, también llamada capa de transporte.

QUIC se está consolidando rápidamente como un protocolo de transporte alternativo. Si bien técnicamente se transmite mediante paquetes UDP, busca ofrecer una conectividad de transporte mejorada en comparación con TCP. HTTP/3 funciona exclusivamente a través de QUIC.

Capa de aplicación

La capa de aplicación incluye los protocolos que la mayoría de las aplicaciones utilizan para proporcionar servicios al usuario o intercambiar datos de la aplicación 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 la 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). [ 64 ] 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.

El modelo TCP/IP no considera los detalles del formato y la presentación de datos, ni 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, estas funciones corresponden a las bibliotecas y las interfaces de programación de aplicaciones (API ). La capa de aplicación en el modelo TCP/IP se suele comparar con una combinación de las capas quinta (sesión), sexta (presentación) y séptima (aplicación) del modelo OSI.

Application layer protocols are often associated with particular client–server applications, and common services have well-known port numbers reserved by the Internet Assigned Numbers Authority (IANA). For example, the HyperText Transfer Protocol uses server port 80 and Telnet uses server port 23. Clients connecting to a service usually use ephemeral ports, i.e., port numbers assigned only for the duration of the transaction at random or from a specific range configured in the application.

At the application layer, the TCP/IP model distinguishes between user protocols and support protocols.[1]:§1.1.3 Support protocols provide services to a system of network infrastructure. User protocols are used for actual user applications. For example, FTP is a user protocol and DNS is a support protocol.

Although the applications are usually aware of key qualities of the transport layer connection such as the endpoint IP addresses and port numbers, application layer protocols generally treat the transport layer (and lower) protocols as black boxes which provide a stable network connection across which to communicate. The transport layer and lower-level layers are unconcerned with the specifics of application layer protocols. Routers and switches do not typically examine the encapsulated traffic, rather they just provide a conduit for it. However, some firewall and bandwidth throttling applications use deep packet inspection to interpret application data. An example is the Resource Reservation Protocol (RSVP).[65] It is also sometimes necessary for Applications affected by NAT to consider the application payload.

Layering evolution and representations in the literature

The Internet protocol suite evolved through research and development funded over a period of time. In this process, the specifics of protocol components and their layering changed. In addition, parallel research and commercial interests from industry associations competed with design features. In particular, efforts in the International Organization for Standardization led to a similar goal, but with a wider scope of networking in general. Efforts to consolidate the two principal schools of layering, which were superficially similar, but diverged sharply in detail, led independent textbook authors to formulate abridging teaching tools.

The following table shows various such networking models. The number of layers varies between three and seven.

Some of the networking models are from textbooks, which are secondary sources that may conflict with the intent of RFC 1122 and other IETF primary sources.[74]

Comparison of TCP/IP and OSI layering

The three top layers in the OSI model, i.e. the application layer, the presentation layer and the session layer, are not distinguished separately in the TCP/IP model which only has an application layer above the transport layer. While some pure OSI protocol applications, such as X.400, also combined them, there is no requirement that a TCP/IP protocol stack must impose monolithic architecture above the transport layer. For example, the NFS application protocol runs over the External Data Representation (XDR) presentation protocol, which, in turn, runs over a protocol called Remote Procedure Call (RPC). RPC provides reliable record transmission, so it can safely use the best-effort UDP transport.

Different authors have interpreted the TCP/IP model differently, and disagree whether the link layer, or any aspect of the TCP/IP model, covers OSI layer 1 (physical layer) issues, or whether TCP/IP assumes a hardware layer exists below the link layer. Several authors have attempted to incorporate the OSI model's layers 1 and 2 into the TCP/IP model since these are commonly referred to in modern standards (for example, by IEEE and ITU). This often results in a model with five layers, where the link layer or network access layer is split into the OSI model's layers 1 and 2.[75]

El esfuerzo de desarrollo de protocolos del IETF no se centra en la estratificación estricta. Algunos de sus protocolos pueden no ajustarse perfectamente al modelo OSI, aunque los RFC a veces hacen referencia a él y suelen utilizar la numeración de capas OSI antigua. El IETF ha declarado repetidamente [ 54 ] que el desarrollo de protocolos y arquitecturas de Internet no pretende cumplir con el modelo OSI. El RFC 3439, que se refiere a la arquitectura de Internet, contiene una sección titulada: «La estratificación se considera perjudicial». [ 74 ]

Por ejemplo, las capas de sesión y presentación del modelo OSI se consideran incluidas en la capa de aplicación del modelo TCP/IP. La funcionalidad de la capa de sesión se encuentra en protocolos como HTTP y SMTP , y es más evidente en protocolos como Telnet y el Protocolo de Inicio de Sesión (SIP). Esta funcionalidad también se implementa mediante la numeración de puertos de los protocolos TCP y UDP, que se incluyen en la capa de transporte del modelo TCP/IP. Las funciones de la capa de presentación se implementan en las aplicaciones TCP/IP mediante el estándar MIME para el intercambio de datos.

Otra diferencia radica 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 la entrega de paquetes de un enrutador a otro, sino que define su propia encapsulación de capa 3. En contraste, OSPF , RIP , BGP y otros protocolos de enrutamiento definidos por la IETF se transportan sobre IP y, para el envío y la recepción de paquetes de protocolo de enrutamiento, los enrutadores actúan como hosts. En consecuencia, los protocolos de enrutamiento se incluyen en la capa de aplicación. [ 36 ] Algunos autores, como Tanenbaum en Computer Networks , describen los protocolos de enrutamiento en la misma capa que IP, argumentando que los protocolos de enrutamiento informan las decisiones tomadas por el proceso de reenvío de los enrutadores.

Los protocolos IETF pueden encapsularse de forma recursiva, como demuestran los protocolos de tunelización como Generic Routing Encapsulation (GRE). GRE utiliza el mismo mecanismo que OSI emplea para la tunelización en la capa de red.

Implementaciones

The Internet protocol suite is generally independent of a specific hardware or software environment. It only requires the hardware and a software layer to exist, capable of sending and receiving packets on a computer network. As a result, the suite has been implemented on essentially every computing platform. A minimal implementation of TCP/IP includes the following: Internet Protocol (IP), Address Resolution Protocol (ARP), Internet Control Message Protocol (ICMP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Internet Group Management Protocol (IGMP).[76] In addition to IP, ICMP, TCP, UDP, Internet Protocol version 6 requires Neighbor Discovery Protocol (NDP), ICMPv6, and Multicast Listener Discovery (MLD) and is often accompanied by an integrated IPSec security layer.

See also

Notes

  1. ↑The same idea had earlier been independently developed by Donald Davies who was the first to implement packet switching in the local area NPL network.[4]
  2. ↑For records of discussions leading up to the TCP/IP split, see the series of Internet Experiment Notes at the Internet Experiment Notes Index.

References

  1. 12345R. Braden, ed. (October 1989). Requirements for Internet Hosts -- Communication Layers. Network Working Group. doi:10.17487/RFC1122. STD 3.RFC1122.Internet Standard 3. Updated by RFC 1349, 4379, 5884, 6093, 6298, 6633, 6864, 8029 and 9293.
  2. 123R. Braden, ed. (October 1989). Requirements for Internet Hosts -- Application and Support. Network Working Group. doi:10.17487/RFC1123. STD 3.RFC1123.Internet Standard 3. Updated by RFC 1349, 2181, 5321, 5966 and 7766.
  3. ↑Hafner & Lyon 1998, p. 91 harvnb error: no target: CITEREFHafnerLyon1998 (help)
  4. ↑Roberts, Dr. Lawrence G. (May 1995). "The ARPANET & Computer Networks". Archived from the original on March 24, 2016. Retrieved April 13, 2016. Then in June 1966, Davies wrote a second internal paper, "Proposal for a Digital Communication Network" In which he coined the word packet,- a small sub part of the message the user wants to send, and also introduced the concept of an "Interface computer" to sit between the user equipment and the packet network.
  5. ↑"Dave Walden, Looking back at the ARPANET effort, 34 years later - Internet History". livinginternet.com. Retrieved December 22, 2018.
  6. ↑Hafner & Lyon 1998, p. 103 harvnb error: no target: CITEREFHafnerLyon1998 (help)
  7. ↑Hafner & Lyon 1998, pp. 103, 151 harvnb error: no target: CITEREFHafnerLyon1998 (help)
  8. ↑Beranek, Leo (2005). "BBN's earliest days: founding a culture of engineering creativity". IEEE Annals of the History of Computing. 27 (2): 6–14. doi:10.1109/MAHC.2005.20. S2CID 12645672.
  9. ↑Hafner & Lyon 1998, p. 153 harvnb error: no target: CITEREFHafnerLyon1998 (help)
  10. ↑J. Reynolds; J. Postel (November 1987). THE REQUEST FOR COMMENTS REFERENCE GUIDE. Network Working Group. doi:10.17487/RFC1000. RFC1000.Status Unknown. Obsoletes RFC 84, 100, 160, 170, 200, 598, 699, 800, 899 and 999.
  11. ↑Hafner, Katie; Lyon, Matthew (1996). Where wizards stay up late : the origins of the Internet. Internet Archive. New York : Simon & Schuster. p. 263. ISBN 978-0-684-81201-4.
  12. ↑Russell, Andrew L. (2014). Open standards and the digital age: history, ideology, and networks. New York: Cambridge Univ Press. p. 196. ISBN 978-1107039193. Archived from the original on December 28, 2022. Retrieved December 20, 2022.
  13. ↑Abbate 1999, p. 3 "The manager of the ARPANET project, Lawrence Roberts, assembled a large team of computer scientists ... and he drew on the ideas of network experimenters in the United States and the United Kingdom. Cerf and Kahn also enlisted the help of computer scientists from England, France and the United States"
  14. ↑Taylor, Bob (October 11, 2008), "Oral History of Robert (Bob) W. Taylor"(PDF), Computer History Museum Archive, CHM Reference number: X5059.2009: 28
  15. 12Isaacson, Walter (2014). The innovators: how a group of hackers, geniuses, and geeks created the digital revolution. Internet Archive. New York: Simon & Schuster. ISBN 978-1-4767-0869-0.
  16. ↑Cerf, V.; Kahn, R. (1974). "A Protocol for Packet Network Intercommunication"(PDF). IEEE Transactions on Communications. 22 (5): 637–648. Bibcode:1974ITCom..22..637C. doi:10.1109/TCOM.1974.1092259. ISSN 1558-0857. Archived(PDF) from the original on October 10, 2022. Retrieved October 18, 2015. The authors wish to thank a number of colleagues for helpful comments during early discussions of international network protocols, especially R. Metcalfe, R. Scantlebury, D. Walden, and H. Zimmerman; D. Davies and L. Pouzin who constructively commented on the fragmentation and accounting issues; and S. Crocker who commented on the creation and destruction of associations.
  17. ↑V. Cerf; Y. Dalal; C. Sunshine (December 1974). SPECIFICATION OF INTERNET TRANSMISSION CONTROL PROGRAM. Network Working Group. doi:10.17487/RFC0675. RFC675.Obsolete. Obsoleted by RFC 7805. NIC 2. INWG 72.
  18. ↑ por Vinton Cerf, según lo contado a Bernard Aboba (1993). "Cómo surgió Internet" . Archivado del original el 26 de septiembre de 2017. Recuperado el 25 de septiembre de 2017. Comenzamos a realizar implementaciones concurrentes en Stanford, BBN y University College London . Por lo tanto, el esfuerzo por desarrollar los protocolos de Internet fue internacional desde el principio.
  19. 1 2 Cerf, Vinton G. (1 de abril de 1980). "Informe final del proyecto TCP de la Universidad de Stanford" .
  20. ↑ Cerf, Vinton (marzo de 1977). "Especificación del protocolo de control de transmisión de Internet TCP (versión 2)" (PDF) . Archivado (PDF) del original el 25 de mayo de 2022. Recuperado el 4 de agosto de 2022 .
  21. ↑ Panzaris, Georgios (2008). Máquinas y romances: la construcción técnica y narrativa de la computación en red como plataforma de propósito general, 1960–1995 . Universidad de Stanford . pág. 128. Archivado del original el 17 de enero de 2023. Recuperado el 5 de septiembre de 2019 . 
  22. ↑ Pelkey, James L. (2007). "Yogen Dalal" . Capitalismo empresarial e innovación: una historia de las comunicaciones informáticas, 1968-1988 . Archivado del original el 8 de octubre de 2022. Recuperado el 8 de octubre de 2020 .
  23. ↑ "Sobre el diseño de TCP/IP" . www.nethistory.info . Consultado el 5 de diciembre de 2025 .
  24. ↑ Salón de la Fama de Internet
  25. ↑ Postel, Jon (15 de agosto de 1977), 2.3.3.2 Comentarios sobre el protocolo de Internet y TCP , IEN 2, archivado del original el 16 de mayo de 2019 , recuperado el 11 de junio de 2016
  26. ↑ Abbate, Inventando Internet , 129–30.
  27. ↑ Vinton G. Cerf (octubre de 1980). "Protocolos para redes de paquetes interconectadas". ACM SIGCOMM Computer Communication Review . 10 (4): 10– 11.
  28. ↑ Russell, Andrew L. (2007). "Legislaturas industriales": Estandarización por consenso en la segunda y tercera revolución industrial (PDF) (tesis doctoral). Universidad Johns Hopkins. Archivado (PDF) del original el 28 de diciembre de 2022. Recuperado el 28 de diciembre de 2022 .
  29. ↑"Born in a Van: Happy 40th Birthday to the Internet!". computerhistory.org/. Retrieved May 27, 2026.
  30. ↑"The internet's fifth man". Economist. December 13, 2013. Archived from the original on April 19, 2020. Retrieved September 11, 2017. In the early 1970s Mr Pouzin created an innovative data network that linked locations in France, Italy and Britain. Its simplicity and efficiency pointed the way to a network that could connect not just dozens of machines, but millions of them. It captured the imagination of Dr Cerf and Dr Kahn, who included aspects of its design in the protocols that now power the internet.
  31. ↑Bennett, Richard (September 2009). "Designed for Change: End-to-End Arguments, Internet Innovation, and the Net Neutrality Debate"(PDF). Information Technology and Innovation Foundation. pp. 7, 11. Retrieved September 11, 2017.
  32. ↑Pelkey, James. "8.3 CYCLADES Network and Louis Pouzin 1971-1972". Entrepreneurial Capitalism and Innovation: A History of Computer Communications 1968-1988. Archived from the original on June 17, 2021. Retrieved November 21, 2021. The inspiration for datagrams had two sources. One was Donald Davies' studies. He had done some simulation of datagram networks, although he had not built any, and it looked technically viable. The second inspiration was I like things simple. I didn't see any real technical motivation to overlay two levels of end-to-end protocols. I thought one was enough.
  33. ↑Davies, Donald; Bartlett, Keith; Scantlebury, Roger; Wilkinson, Peter (October 1967). A Digital Communication Network for Computers Giving Rapid Response at remote Terminals(PDF). ACM Symposium on Operating Systems Principles. Archived(PDF) from the original on October 10, 2022. Retrieved September 15, 2020. all users of the network will provide themselves with some kind of error control
  34. ↑"Virginia Travers: Technology Does Not Develop Along a Linear Path". www.internethalloffame.org/. Retrieved May 27, 2026.
  35. ↑ Cerf, Vinton G. y Cain, Edward (octubre de 1983). "El modelo de arquitectura de Internet del Departamento de Defensa". Computer Networks . 7 (5). North-Holland: 307–318 . doi : 10.1016/0376-5075(83)90042-9 .
  36. 1 2 F. Baker , ed. (junio de 1995). Requisitos para enrutadores IP versión 4. Grupo de trabajo de redes. doi : 10.17487/RFC1812 . RFC 1812 .Norma propuesta. Sustituye a las RFC 1716 y 1009. Actualizada por las RFC 2644 y 6633 .  
  37. ↑ Crowell, William; Contos, Brian; DeRodeff, Colby (2011). Convergencia de seguridad física y lógica: impulsada por la gestión de seguridad empresarial . Syngress. pág. 99. ISBN  9780080558783.
  38. 1 2 Ronda Hauben. "De ARPANET a Internet" . TCP Digest (UUCP). Archivado del original el 21 de julio de 2009. Recuperado el 5 de julio de 2007 .
  39. ↑ IEN 207 . IETF .
  40. ↑ IEN 152 . IETF .
  41. ↑ Hauben, Ronda (2004). "Internet: Sobre sus orígenes internacionales y su visión colaborativa" . Amateur Computerist . 12 (2) . Recuperado el 29 de mayo de 2009. Marzo de 1982 : Noruega abandona la ARPANET y se convierte en una conexión a Internet vía TCP/IP sobre SATNET. Noviembre de 1982: UCL abandona la ARPANET y se convierte en una conexión a Internet.
  42. ↑ "Protocolo de Internet TCP/IP" . Archivado del original el 1 de enero de 2018. Consultado el 31 de diciembre de 2017 .
  43. ↑ Leiner, Barry M.; et al. (1997), Breve historia de Internet (PDF) , Internet Society , pág. 15, archivado (PDF) del original el 18 de enero de 2018 , recuperado el 17 de enero de 2018.  
  44. ↑ "Vinton G. Cerf : Una historia oral" . Colecciones de historia oral de Stanford - Spotlight at Stanford . 2020. págs. 113, 129, 145. Recuperado el 29 de junio de 2024 .  
  45. ↑ "Uso de Wollongong TCP/IP con Windows para grupos de trabajo 3.11" . Soporte técnico de Microsoft . Archivado del original el 12 de enero de 2012.
  46. ↑ "Una breve historia de los protocolos de Internet en el CERN" . Archivado del original el 10 de noviembre de 2016. Consultado el 12 de septiembre de 2016 .
  47. ↑ "Introducción a las redes informáticas, Stanford Univ CS144 Otoño 2012" (PDF) . págs. 21–22 . 
  48. ↑ Baker, Steven; Gillies, Donald W. "TCP/IP de escritorio en la mediana edad" . Archivado del original el 21 de agosto de 2015. Recuperado el 9 de septiembre de 2016 .
  49. ↑ Romkey, John (17 de febrero de 2011). "Acerca de" . Archivado del original el 5 de noviembre de 2011. Recuperado el 12 de septiembre de 2016 .
  50. ↑ Phil Karn, KA9Q TCP Sitio web de descarga
  51. ↑ Andrew L. Russell (30 de julio de 2013). "OSI: Internet que no existió" . IEEE Spectrum . Vol. 50, n.º 8. Archivado del original el 1 de agosto de 2017. Consultado el 6 de febrero de 2020 .  
  52. ↑ Russell, Andrew L. «Consenso aproximado y código en ejecución: la guerra de estándares entre Internet y OSI» (PDF) . Anales de la historia de la computación del IEEE. Archivado del original (PDF) el 17 de noviembre de 2019.
  53. 1 2 Davies, Howard; Bressan, Beatrice (26 de abril de 2010). Una historia de las redes internacionales de investigación: las personas que lo hicieron posible . John Wiley & Sons. ISBN 978-3-527-32710-2Archivado del original el 17 de enero de 2023. Consultado el 7 de noviembre de 2020 .
  54. 1 2 "Introducción al IETF" . IETF . Consultado el 27 de febrero de 2024 .
  55. ↑ Morabito, Roberto; Jiménez, Jaime (junio de 2020). "Conjunto de protocolos IETF para el Internet de las cosas: descripción general y avances recientes" . IEEE Communications Standards Magazine . 4 (2): 41– 49. arXiv : 2003.10279 . Bibcode : 2020ICStM...4b..41M . doi : 10.1109/mcomstd.001.1900014 . ISSN 2471-2825 . 
  56. ↑B. Carpenter; R. Hinden (April 1, 2011). Adaptation of RFC 1149 for IPv6. Internet Engineering Task Force. doi:10.17487/RFC6214. ISSN 2070-1721. RFC6214.Informational. This is an April Fools' Day Request for Comments.
  57. ↑Blumenthal, Marjory S.; Clark, David D. (August 2001). "Rethinking the design of the Internet: The end-to-end arguments vs. the brave new world"(PDF). Archived(PDF) from the original on October 8, 2022. Retrieved October 8, 2022.
  58. ↑J. Postel, ed. (September 1981). INTERNET PROTOCOL - DARPA INTERNET PROGRAM PROTOCOL SPECIFICATION. IETF. doi:10.17487/RFC0791. STD 5.RFC791.IEN 128, 123, 111, 80, 54, 44, 41, 28, 26.Internet Standard 5. Obsoletes RFC 760. Updated by RFC 1349, 2474 and 6864.
  59. ↑B. Carpenter, ed. (June 1996). Architectural Principles of the Internet. Network Working Group. doi:10.17487/RFC1958. RFC1958.Informational. Updated by RFC 3439.
  60. ↑Hunt, Craig (2002). TCP/IP Network Administration (3rd ed.). O'Reilly. pp. 9–10. ISBN 9781449390785.
  61. ↑Guttman, E. (1999). "Service location protocol: automatic discovery of IP network services". IEEE Internet Computing. 3 (4): 71–80. Bibcode:1999IIC.....3d..71G. doi:10.1109/4236.780963. ISSN 1089-7801.
  62. 12Zheng, Kai (July 2017). "Enabling "Protocol Routing": Revisiting Transport Layer Protocol Design in Internet Communications". IEEE Internet Computing. 21 (6): 52–57. Bibcode:2017IIC....21f..52Z. doi:10.1109/mic.2017.4180845. ISSN 1089-7801.
  63. ↑ Huang, Jing-lian (7 de abril de 2009). "Esquema de adaptación de enlace de capa cruzada en red de área local inalámbrica" . Journal of Computer Applications . 29 (2): 518– 520. doi : 10.3724/sp.j.1087.2009.00518 (inactivo el 1 de julio de 2025). ISSN 1001-9081 . {{cite journal}}: CS1 maint: DOI inactivo desde julio de 2025 ( enlace )
  64. ↑ Stevens, W. Richard (febrero de 1994). TCP/IP Ilustrado: los protocolos . Addison-Wesley. ISBN 0-201-63346-9Archivado del original el 22 de abril de 2012. Consultado el 25 de abril de 2012 .
  65. ↑ Equipo, IR "Una explicación detallada de la inspección profunda de paquetes y cómo funciona | IR" . www.ir.com . Consultado el 13 de julio de 2025 .
  66. ↑ Dye, Mark; McDonald, Rick; Rufi, Antoon (29 de octubre de 2007). Fundamentos de redes, Guía complementaria de exploración CCNA . Cisco Press. ISBN 9780132877435Recuperado el 12 de septiembre de 2016 – a través de Google Libros.
  67. ↑ Kozierok, Charles M. (1 de enero de 2005). The TCP/IP Guide: A Comprehensive, Illustrated Internet Protocols Reference . No Starch Press. ISBN 9781593270476Recuperado el 12 de septiembre de 2016 – a través de Google Libros.
  68. ↑ Comer, Douglas (1 de enero de 2006). Interconexión de redes con TCP/IP: Principios, protocolos y arquitectura . Prentice Hall. ISBN 0-13-187671-6Recuperado el 12 de septiembre de 2016 – a través de Google Libros.
  69. ↑ Tanenbaum, Andrew S. (1 de enero de 2003). Redes informáticas . Prentice Hall PTR. pág . 42. ISBN  0-13-066102-3. Recuperado el 12 de septiembre de 2016 – a través de Internet Archive. redes.
  70. ↑ Forouzan, Behrouz A.; Fegan, Sophia Chung (1 de agosto de 2003). Comunicaciones de datos y redes . McGraw-Hill Higher Education. ISBN 9780072923544Recuperado el 12 de septiembre de 2016 – a través de Google Libros.
  71. ↑ Kurose, James F.; Ross, Keith W. (2008). Redes informáticas: Un enfoque descendente . Pearson/Addison Wesley. ISBN 978-0-321-49770-3Archivado del original el 23 de enero de 2016. Consultado el 16 de julio de 2008 .
  72. ↑ Stallings, William (1 de enero de 2007). Comunicaciones de datos e informáticas . Prentice Hall. ISBN 978-0-13-243310-5Recuperado el 12 de septiembre de 2016 – a través de Google Libros.
  73. ↑ ISO/IEC 7498-1:1994 Tecnología de la información — Interconexión de sistemas abiertos — Modelo de referencia básico: El modelo básico .
  74. 12R. Bush; D. Meyer (December 2002). Some Internet Architectural Guidelines and Philosophy. Network Working Group. doi:10.17487/RFC3439. RFC3439.Informational. Updates RFC 1958.
  75. ↑Murray, Nick (November 28, 2018). "Network Layers Explained: OSI & TCP/IP Models [with examples]". Plixer. Retrieved July 13, 2025.
  76. ↑Braden, Robert T. (1989). Requirements for internet hosts - communication layers. IETF. doi:10.17487/RFC1122. RFC1122.

Bibliography

  • Abbate, Janet (1999). Inventing the Internet. Cambridge, Massachusetts: MIT Press. ISBN 978-0-262-01172-3.
  • Douglas E. Comer (2001). Internetworking with TCP/IP – Principles, Protocols and Architecture. CET [i. e.] Computer Equipment and Trade. ISBN 86-7991-142-9.
  • Joseph G. Davies; Thomas F. Lee (2003). Microsoft Windows Server 2003 TCP/IP Protocols and Services. Microsoft Press. ISBN 0-7356-1291-9.
  • Forouzan, Behrouz A. (2003). TCP/IP Protocol Suite (2nd ed.). McGraw-Hill. ISBN 978-0-07-246060-5.
  • Craig Hunt (1998). TCP/IP Network Administration. O'Reilly. ISBN 1-56592-322-7.
  • Maufer, Thomas A. (1999). IP Fundamentals. Prentice Hall. ISBN 978-0-13-975483-8.
  • Ian McLean (2000). Windows 2000 TCP/IP Black Book. Coriolis Group Books. ISBN 1-57610-687-X.
  • Ajit Mungale (September 29, 2004). Pro .NET 1.1 Network Programming. Apress. ISBN 1-59059-345-6.
  • W. Richard Stevens (April 24, 1994). TCP/IP Illustrated, Volume 1: The Protocols. Addison-Wesley. ISBN 0-201-63346-9.
  • W. Richard Stevens; Gary R. Wright (1994). TCP/IP Illustrated, Volume 2: The Implementation. Addison-Wesley. ISBN 0-201-63354-X.
  • W. Richard Stevens (1996). TCP/IP Illustrated, Volume 3: TCP for Transactions, HTTP, NNTP, and the UNIX Domain Protocols. Addison-Wesley. ISBN 0-201-63495-3.
  • Andrew S. Tanenbaum (2003). Computer Networks. Prentice Hall PTR. ISBN 0-13-066102-3.
  • Clark, D. (1988). «La filosofía de diseño de los protocolos de Internet de DARPA» (PDF) . Actas del Simposio Sigcomm '88 sobre Arquitecturas y Protocolos de Comunicaciones . ACM . págs. 106–114 . doi : 10.1145/52324.52336 . ISBN  978-0897912792. S2CID 6156615 . Consultado el 16 de octubre de 2011 . 
  • Cerf, Vinton G .; Kahn, Robert E. (mayo de 1974). "Un protocolo para la intercomunicación de redes de paquetes" (PDF) . IEEE Transactions on Communications . 22 (5): 637– 648. Bibcode : 1974ITCom..22..637C . doi : 10.1109/TCOM.1974.1092259 .
  • Historia de Internet : páginas sobre Robert Kahn, Vinton Cerf y TCP/IP (revisadas por Cerf y Kahn).
  • T. Socolofsky; C. Kale (enero de 1991). Un tutorial de TCP/IP . Grupo de trabajo de redes. doi : 10.17487/RFC1180 . RFC 1180 .Informativo.
  • La guía definitiva de TCP/IP
  • La guía TCP/IP : una visión completa de los protocolos, el procedimiento y los procesos involucrados.
  • Un estudio del resumen TCP/IP de ARPANET , archivado del original el 4 de diciembre de 2021.