Content deleted Content added
Reverted 1 edit by 115.78.95.116 (talk): Why unlink application layer? |
|||
| (16 intermediate revisions by 12 users not shown) | |||
Line 6:
{{IPstack}}
The '''Internet protocol suite''', commonly known as '''TCP/IP''', is a framework for organizing the [[communication protocol]]s used in the [[Internet]] and similar [[computer network]]s according to functional criteria. The foundational protocols in the suite are the [[Transmission Control Protocol]] (TCP), the [[User Datagram Protocol]] (UDP), and the [[Internet Protocol]] (IP). Early versions of this networking model were known as the '''Department of Defense''' ('''DoD''') '''
The Internet protocol suite provides [[End-to-end principle|end-to-end data communication]] specifying how data should be packetized, addressed, transmitted, [[routed]], and received. This functionality is organized into four [[abstraction layer]]s, which classify all related protocols according to each protocol's scope of networking.{{Ref RFC|1122}}{{Ref RFC|1123}} An implementation of the layers for a particular application forms a [[protocol stack]]. From lowest to highest, the layers are the [[link layer]], containing communication methods for data that remains within a single network segment (link); the [[internet layer]], providing [[internetworking]] between independent networks; the [[transport layer]], handling host-to-host communication; and the [[application layer]], providing process-to-process data exchange for applications.
Line 23:
By the summer of 1973, Kahn and Cerf had 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. Cerf credits [[Louis Pouzin]] and [[Hubert Zimmermann]], designers of the [[CYCLADES]] network, with important influences on this design.<ref name="YSZAX">{{Cite journal|last1=Cerf|first1=V.|last2=Kahn|first2=R.|date=1974|title=A Protocol for Packet Network Intercommunication|url=https://www.cs.princeton.edu/courses/archive/fall06/cos561/papers/cerf74.pdf|journal=IEEE Transactions on Communications|volume=22|issue=5|pages=637–648|doi=10.1109/TCOM.1974.1092259|issn=1558-0857|quote=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.|access-date=October 18, 2015|archive-date=October 10, 2022|archive-url=https://ghostarchive.org/archive/20221010/https://www.cs.princeton.edu/courses/archive/fall06/cos561/papers/cerf74.pdf|url-status=live}}</ref><ref name="MevuR">{{cite news|date=13 December 2013|title=The internet's fifth man|work=Economist|url=https://www.economist.com/news/technology-quarterly/21590765-louis-pouzin-helped-create-internet-now-he-campaigning-ensure-its|access-date=11 September 2017|quote=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.|archive-date=April 19, 2020|archive-url=https://web.archive.org/web/20200419230318/https://www.economist.com/news/technology-quarterly/21590765-louis-pouzin-helped-create-internet-now-he-campaigning-ensure-its|url-status=live}}</ref> The new protocol was implemented as the [[Transmission Control Program]] in 1974 by Cerf, [[Yogen Dalal]] and Carl Sunshine.{{Ref RFC|675}}
Initially, the Transmission Control Program,
The design of the network included the recognition that it should provide only the functions of efficiently transmitting and routing traffic between end nodes and that all other intelligence should be located at the edge of the network, in the end nodes. This [[end-to-end principle]] was pioneered by Louis Pouzin in the CYCLADES network,<ref name="Bennett2009">{{cite web |last1=Bennett |first1=Richard |date=September 2009 |title=Designed for Change: End-to-End Arguments, Internet Innovation, and the Net Neutrality Debate |url=https://www.itif.org/files/2009-designed-for-change.pdf |access-date=11 September 2017 |publisher=Information Technology and Innovation Foundation |pages=7, 11}}</ref> based on the ideas of [[Donald Davies]].<ref name="Pelkey2">{{cite book |last=Pelkey |first=James |url=https://www.historyofcomputercommunications.info/section/8.3/cyclades-network-and-louis-pouzin-1971-1972/ |title=Entrepreneurial Capitalism and Innovation: A History of Computer Communications 1968-1988 |chapter=8.3 CYCLADES Network and Louis Pouzin 1971-1972 |quote=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. |access-date=2021-11-21 |archive-url=https://web.archive.org/web/20210617093154/https://www.historyofcomputercommunications.info/section/8.3/cyclades-network-and-louis-pouzin-1971-1972/ |archive-date=2021-06-17 |url-status=dead}}</ref><ref name=":5">{{cite conference |last1=Davies |first1=Donald |last2=Bartlett |first2=Keith |last3=Scantlebury |first3=Roger |last4=Wilkinson |first4=Peter |date=October 1967 |title=A Digital Communication Network for Computers Giving Rapid Response at remote Terminals |url=https://people.mpi-sws.org/~gummadi/teaching/sp07/sys_seminar/how_did_erope_blow_this_vision.pdf |conference=ACM Symposium on Operating Systems Principles |archive-url=https://ghostarchive.org/archive/20221010/https://people.mpi-sws.org/~gummadi/teaching/sp07/sys_seminar/how_did_erope_blow_this_vision.pdf |archive-date=2022-10-10 |access-date=2020-09-15 |url-status=live |quote=all users of the network will provide themselves with some kind of error control}}</ref> Using this design, it became possible to connect other networks to the ARPANET that used the same principle, irrespective of other local characteristics, thereby solving Kahn's initial internetworking problem. A popular expression is that TCP/IP, the eventual product of Cerf and Kahn's work, can run over "two tin cans and a string."<ref>{{
DARPA contracted with [[BBN Technologies]], [[Stanford University]], and the [[University College London]] to develop operational versions of the protocol on several hardware platforms.<ref name="IjTdeF">{{cite web |author1=by Vinton Cerf, as told to Bernard Aboba |date=1993 |title=How the Internet Came to Be |url=http://elk.informatik.hs-augsburg.de/tmp/cdrom-oss/CerfHowInternetCame2B.html |url-status=dead |archive-url=https://web.archive.org/web/20170926042220/http://elk.informatik.hs-augsburg.de/tmp/cdrom-oss/CerfHowInternetCame2B.html |archive-date=26 September 2017 |access-date=25 September 2017 |quote=We began doing concurrent implementations at Stanford, BBN, and University College London. So effort at developing the Internet protocols was international from the beginning.}}</ref> During development of the protocol the version number of the packet routing layer progressed from version 1 to version 4, the latter of which was installed in the ARPANET in 1983. It became known as ''[[Internet Protocol version 4]]'' (IPv4) as the protocol that is still in use in the Internet, alongside its current successor, [[Internet Protocol version 6]] (IPv6).
Line 41:
IBM, AT&T and DEC were the first major corporations to adopt TCP/IP, this despite having competing [[proprietary protocol]]s. 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 (operating system)|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]].<ref name="TtEPm">{{cite web| url = http://support.microsoft.com/kb/108007| title = Using Wollongong TCP/IP with Windows for Workgroups 3.11| website=Microsoft Support| archive-url=https://web.archive.org/web/20120112105314/http://support.microsoft.com/kb/108007| archive-date = 12 January 2012| url-status=dead}}</ref> The first [[VM/CMS]] TCP/IP stack came from the University of Wisconsin.<ref name="BZHnU">{{cite web|url=http://www.weblab.isti.cnr.it/education/ssfs/lezioni/slides/archives/cern.htm|title=A Short History of Internet Protocols at CERN|access-date=12 September 2016|archive-url=https://web.archive.org/web/20161110200124/http://www.weblab.isti.cnr.it/education/ssfs/lezioni/slides/archives/cern.htm|archive-date=10 November 2016|url-status=dead}}</ref>
Some
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 ([[Serial_Line_Internet Protocol|SLIP]] or [[Point-to-Point Protocol|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).
Line 67:
* The [[transport layer]] performs host-to-host communications on either the local network or remote networks separated by routers.<ref name="AoJD3">{{cite book |last=Hunt |first=Craig |date=2002 |title=TCP/IP Network Administration |edition=3rd |publisher=O'Reilly |pages=9–10 |isbn=9781449390785}}</ref> It provides a channel for the communication needs of applications. The [[User Datagram Protocol]] (UDP) is the most basic{{Citation needed|date=June 2025|reason=Which source states UDP is the most basic transport layer protocol ? I refer to Jim Kurose (2012), Computer Networking: A Top-Down Approach, 7th Edition, Chapter 3: Transport layer, Section 3.1 Introduction and Transport-layer services), which states that both TCP and UDP are two best known transport layer protocols, which made up many application layer protocols like HTTP, IMAP, POP3, and SMTP. So what makes UDP is the "most basic", compared to TCP ?}} transport layer protocol, providing an unreliable [[connectionless]] datagram service. The [[Transmission Control Protocol]] (TCP) provides flow-control, connection establishment, and reliable transmission of data.
* The [[internet layer]] exchanges datagrams across network boundaries. It provides a uniform networking interface that hides the actual topology (layout) of the underlying network connections. It is therefore also the layer that establishes internetworking. Indeed, it defines and establishes the Internet. This layer defines the addressing and routing structures used for the TCP/IP protocol suite. The primary protocol in this scope is the Internet Protocol, which defines [[IP address]]es.<ref>{{Cite journal |last=Guttman |first=E. |date=1999 |title=Service ___location protocol: automatic discovery of IP network services |url=http://dx.doi.org/10.1109/4236.780963 |journal=IEEE Internet Computing |volume=3 |issue=4 |pages=71–80 |doi=10.1109/4236.780963 |issn=1089-7801|url-access=subscription }}</ref>{{failed verification|date=April 2024}}<ref name=kz>{{Cite journal |last=Zheng |first=Kai |date=July 2017 |title=Enabling "Protocol Routing": Revisiting Transport Layer Protocol Design in Internet Communications |url=http://dx.doi.org/10.1109/mic.2017.4180845 |journal=IEEE Internet Computing |volume=21 |issue=6 |pages=52–57 |doi=10.1109/mic.2017.4180845 |issn=1089-7801|url-access=subscription }}</ref> Its function in routing is to transport datagrams to the next host, functioning as an IP router, that has the connectivity to a network closer to the final data destination.<ref name=kz/>{{failed verification|date=April 2024}}
* The [[link layer]] defines the networking methods within the scope of the local network link on which hosts communicate without intervening routers. This layer includes the protocols used to describe the local network topology and the interfaces needed to effect the transmission of internet layer datagrams to next-neighbor hosts.<ref>{{Cite journal |last=Huang |first=Jing-lian |date=2009-04-07 |title=Cross layer link adaptation scheme in wireless local area network |url=http://dx.doi.org/10.3724/sp.j.1087.2009.00518 |journal=Journal of Computer Applications |volume=29 |issue=2 |pages=518–520 |doi=10.3724/sp.j.1087.2009.00518 |doi-broken-date=
==Link layer==
Line 118:
At the application layer, the TCP/IP model distinguishes between ''user protocols'' and ''support protocols''.{{Ref RFC|1122|rsection=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 box]]es 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 [[network switch|switches]] do not typically examine the encapsulated traffic, rather they just provide a conduit for it. However, some [[Firewall (computing)|firewall]] and [[bandwidth throttling]] applications use [[deep packet inspection]] to interpret application data. An example is the [[Resource Reservation Protocol]] (RSVP).<ref>{{
==Layering evolution and representations in the literature==
Line 206:
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.<ref>{{
The IETF protocol development effort is not concerned with strict layering. Some of its protocols may not fit cleanly into the OSI model, although RFCs sometimes refer to it and often use the old OSI layer numbers. The IETF has repeatedly stated<ref name="introduction-to-the-ietf" />{{failed verification|date=April 2024}} that Internet Protocol and architecture development is not intended to be OSI-compliant. RFC 3439, referring to the internet architecture, contains a section entitled: "Layering Considered Harmful".{{ref RFC|3439}}
Line 218:
==Implementations==
{{unreferenced section|date=March 2014}}
==See also==
| |||