[转载]TCP/IP参考模型

The Internet Protocol Suite is the set of 网络传输协议 that implement the protocol stack on which the Internet and most commercial networks run. It is sometimes called the TCP/IP protocol suite, after the two most important protocols in it: the Transmission Control Protocol (TCP) and the Internet Protocol (IP), which were also the first two defined.

The 网络传输协议 like many can be viewed as a set of layers, each layer solves a set of problems involving the transmission of data, and provides a well-defined service to the higher layers based on using services from some lower layers. Higher layers are logically closer to the user and deal with more abstract data, relying on lower layers to translate data into forms that can eventually be physically manipulated.

The 网络传输协议 can be roughly fitted to the OSI模型 which describes a fixed set of 7 layers and some vendors like to use this model. However not all of these layers fit well with ip based networking (which really involves a varying number of layers depending on the design of the applications and the underlying network) and some believe that trying to fit the internet protocol suite to the OSI模型 does more to confuse than to help.

分层

TCP/IP参考模型分为四层。应用层(Application Layer)，传输层(Transport Layer)，网络层(Internet Layer)，链路层(Link Layer)。

应用层

该层包括所有和应用程序协同工作，利用基础网络交换应用程序专用的数据的协议。如,

• HTTPS(Hypertext Transfer Protocol over Secure Socket Layer, or HTTP over SSL),安全超文本传输协议。
• HTTP(Hypertext Transfer Protocol),超文本传输协议。
• TELNET (Teletype over the Network, 网络电传) ，通过一个终端(terminal)登陆到网络(运行在TCP协议上)。
• FTP (File Transfer Protocol, 文件传输协议) ，由名知义(运行在TCP协议上) 。
• SMTP (Simple Mail Transfer Protocol，简单邮件传输协议) ，用来发送电子邮件(运行在TCP协议上) 。
• DNS (Domain Name Service，域名服务) ，用于完成地址查找，邮件转发等工作(运行在TCP和UDP协议上) 。
• NTP (Network Time Protocol，网络时间协议) ，用于网络同步(运行在UDP协议上) 。
• SNMP (Simple Network Management Protocol, 简单网络管理协议) ，用于网络信息的收集和网络管理。

传输层

该层提供端对端的通信。最重要的传输层协议是传输控制协议TCP。

• 传输控制协议TCP (Transport Control Protocol) - 数据流传输（面向连接，可靠）
• 用户数据报文协议UDP (User Datagram Protocol) - 数据报文传输(无连接不可靠)

网络层

该层负责数据转发和路由。从该层上面往下看，可以认为底下存在的是一个不可靠无连接的端对端的数据通路。最核心的协议当然是IP协议。此外还有ICMP，RIP,OSPF,IS-IS,BGP,ARP,RARP等。

Layers in the Internet Protocol stack

There is some discussion about how to map the TCP/IP参考模型 onto the OSI模型. Since the TCP/IP and OSI protocol suites do not match precisely, there is no one correct answer.

In addition, the OSI模型 is not really rich enough at the lower layers to capture the true layering; there needs to be an extra layer (the Internetworking layer) between the Transport and Network layers. Protocols specific to a particular network type, but which are run on top of the basic hardware framing, ought to be at the Network layer. Examples of such protocols are ARP and the Spanning Tree Protocol (used to keep redundant bridges idle until they are needed). However, they are local protocols and operate beneath the internetwork functionality. Admittedly, placing both groups (not to mention protocols which are logically part of the internetwork layer, but run on top of the internetwork protocol, such as ICMP) all at the same layer can be confusing, but the OSI model is not complex enough to do a better job.

The following diagram attempts to show where various TCP/IP and other protocols would reside in the original OSI模型l:

Commonly, the top three layers of the OSI model (Application, Presentation and Session) are considered as a single Application Layer in the TCP/IP suite. Because the TCP/IP suite has a comparatively lightweight session layer, consisting of opening and closing connections under TCP and RTP and providing different port numbers for different applications under TCP and UDP, these functions may be augmented by individual applications (or libraries used by those applications). Similarly, IP is designed around the idea of treating the network below it as a black box so it can be considered as a single layer for the purposes of discussing TCP/IP.

The link layer

The Link layer is not really part of the Internet protocol suite, but is the method used to pass packets from the Internet layer of one device to the Internet layer of another. This process can be controlled both in the software device driver for the network card, as well as on firmware or specialist chipsets. These will perform data link functions such as adding a packet header to prepare it for transmission, then actually transmit the frame over a physical medium. On the other end, the link layer will receive data frames, strip off the packet headers, and hand the received packets to the Internet layer.

However, the link layer is not always so simple. It may also be a Virtual private network (VPN) or tunnel, where packets from the Internet layer, instead of being sent over a physical interface, are sent using a tunneling protocol and another (or the same) protocol suite. The VPN or tunnel is usually established ahead of time, and has special characteristics that direct transmission out a physical interface does not (for example, it may encrypt the data going over it). This recursive use of the protocol suite can be confusing since the link "layer" is now an entire network. But it is an elegant method for implementing often complex functions. (though care is needed to prevent a packet that is wrapped and sent through a tunnel being repeatedly re-wrapped and sent down the tunnel again).

The Internetwork layer

As originally defined, the Network layer solves the problem of getting packets across a single network. Examples of such protocols are X.25, and the ARPANET's Host/IMP Protocol.

With the advent of the concept of internetworking, additional functionality was added to this layer, namely getting data from the source network to the destination network. This generally involves routing the packet across a network of networks, known as an internet.

In the internet protocol suite, IP performs the basic task of getting packets of data from source to destination. IP can carry data for a number of different higher level protocols; these protocols are each identified by a unique IP Protocol Number. ICMP and IGMP are protocols 1 and 2, respectively.

Some of the protocols carried by IP, such as ICMP (used to transmit diagnostic information about IP transmission) and IGMP (used to manage multicast data) are layered on top of IP but perform internetwork layer functions, illustrating an incompatibility between the internet and OSI models. All routing protocols, such as BGP, OSPF, and RIP are also really part of the internetwork layer, although they might seem to belong higher in the stack.

The transport layer

The protocols at the Transport layer can solve problems like reliability ("did the data reach the destination?") and ensure that data arrives in the correct order. In the TCP/IP protocol suite, transport protocols also determine which application any given data is intended for.

The dynamic routing protocols which technically fit at this layer in the TCP/IP Protocol Suite (since they run over IP) are generally considered to be part of the Network layer; an example is OSPF (IP protocol number 89).

TCP (IP protocol number 6) is a "reliable", connection-oriented, transport mechanism providing a reliable byte stream, which makes sure data arrives complete, undamaged, and in order. TCP tries to continuously measure how loaded the network is and throttles its sending rate in order to avoid overloading the network. Furthermore, TCP will attempt to deliver all data correctly in the specified sequence. These are its main differences from UDP, and can become disadvantageous in real-time streaming or routing applications with high internetwork layer loss rates.

The newer SCTP is also a "reliable", connection-oriented, transport mechanism. It is record rather than byte oriented, and provides multiple sub-streams multiplexed over a single connection. It also provides multi-homing support, in which a connection end can be represented by multiple IP addresses (representing multiple physical interfaces), such that if one fails the connection is not interrupted. It was developed initially for telephony applications (to transport SS7 over IP), but can also be used for other applications.

UDP (IP protocol number 17) is a connectionless datagram protocol. It is a "best effort" or "unreliable" protocol - not because it is particularly unreliable, but because it does not verify that packets have reached their destination, and gives no guarantee that they will arrive in order. If an Application requires these characteristics, it must provide them itself, or use TCP.

UDP is typically used for applications such as streaming media (audio and video, etc) where on-time arrival is more important than reliability, or for simple query/response applications like DNS lookups, where the overhead of setting up a reliable connection is disproportionately large.

DCCP is currently under development by IETF. It provides TCP's flow control semantics, while keeping UDP's datagram service model visible to the user.

Both TCP and UDP are used to carry a number of higher-level applications. The applications at any given network address are distinguished by their TCP or UDP port number. By convention certain well known ports are associated with specific applications.

RTP is a datagram protocol that is designed for real-time data such as streaming audio and video. RTP is a session layer that uses the UDP packet format as a basis yet is said to sit within the transport layer of the Internet protocol stack.

The application layer

The Application layer is the layer that most common network-aware programs use in order to communicate across a network with other programs. Processes that occur in this layer are application specific; data is passed from the network-aware program, in the format used internally by this application, and is encoded into a standard protocol.

Some specific programs are considered to run in this layer. They provide services that directly support user applications. These programs and their corresponding protocols include HTTP (The World Wide Web), FTP (File transport), SMTP (Email), SSH (Secure remote login), DNS (Name <-> IP Address lookups) and many others.

Once the data from an application has been encoded into a standard application layer protocol it will be passed down to the next layer of the IP stack.

At the Transport Layer, applications will most commonly make use of TCP or UDP, and server applications are often associated with a well-known port number. Ports for server applications are officially allocated by the Internet Assigned Numbers Authority (IANA) but developers of new protocols today often choose the port numbers themselves. As it is rare to have more than a few server applications on the same system, problems with port conflicts are rare. Application software also generally allows users to specify arbitrary port numbers as runtime parameters.

Client applications connecting out generally use a random port number assigned by the operating system. Applications that listen on a port and then send that port to another copy of the application via a server to set up a peer-peer link (e.g. dcc file transfers on IRC). may also use a random port but the applications usually allow specification of a specific port range to allow the ports to be mapped inwards through a router that implements network address translation.

Development

The Internet protocol suite came from work done by DARPA in the early 1970s. After building the pioneering ARPANET, DARPA started work on a number of other data transmission technologies. In 1972, Robert E. Kahn was hired at 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 them. In the spring of 1973, Vinton Cerf, the developer of the existing ARPANET Network Control Program (NCP) protocol, joined Kahn to work on open-architecture interconnection models with the goal of designing the next protocol for the ARPANET.

By the summer of 1973, Kahn and Cerf had soon worked out a fundamental reformulation, where the differences between network protocols were hidden by using a common internetwork protocol, and instead of the network being responsible for reliability, as in the ARPANET, the hosts became responsible. (Cerf credits Hubert Zimmerman and Louis Pouzin (designer of the CYCLADES network) with important influences on this design.)

With the role of the network reduced to the bare minimum, it became possible to join almost any networks together, no matter what their characteristics were, thereby solving Kahn's initial problem. (One popular saying has it that TCP/IP, the eventual product of Cerf and Kahn's work, will run over "two tin cans and a string", and it has in fact been implemented using homing pigeons.) A computer called a gateway (later changed to router to avoid confusion with other types of gateway) is provided with an interface to each network, and forwards packets back and forth between them.

The idea was worked out in more detailed form by Cerf's networking research group at Stanford in the 1973–74 period. (The early networking work at Xerox PARC, which produced the PARC Universal Packet protocol suite, much of which was contemporaneous, was also a significant technical influence; people moved between the two.)

DARPA then contracted with BBN, Stanford, and The University College London to develop operational versions of the protocol on different hardware platforms. Four versions were developed -- TCP v1, TCP v2, a split into TCP v3 and IP v3 in the spring of 1978, and then stability with TCP/IP v4 -- the standard protocol still in use on the Internet today.

In 1975, a two-network TCP/IP communications test was performed between Stanford and University College London (UCL). In November, 1977, a three-network TCP/IP test was conducted between the U.S., U.K., and Norway. Between 1978 and 1983, several other TCP/IP prototypes were developed at multiple research centres. A full switchover to TCP/IP on the ARPANET took place January 1, 1983. [1]

In 1984, the US Department of Defense made TCP/IP the standard for all military computer networking. In 1985, the Internet Architecture Board held a three day workshop on TCP/IP for the computer industry, attended by 250 vendor representatives, helping popularize the protocol and leading to its increasing commercial use.

On 9 November 2005 Kahn and Cerf were presented with the Presidential Medal of Freedom for their contribution to American culture. [2]

How IP Kills and Eats Competitive Networks

In the long term, IP appears to replace other networks. Here's a brief explanation. IP transmits generic data. The data can serve any purpose, and can easily replace data previously provided by proprietary data networks. Here's the usual sequence:

1. A proprietary data network is developed for a specialized purpose. If it works well, users will adopt it.
2. IP service is provided as a convenience, often to get e-mail or chat, usually tunneling through the proprietary data service in some fashion. The tunneling method may be quite inefficient at first, because e-mail and chat require only low bandwidth.
3. IP infrastructure is emplaced by gradual investment at the edges of the proprietary data network.
4. A substitute for the proprietary service is developed using IP, often by a user.
5. The IP substitute spreads over the entire internet, making the IP substitute more valuable (because of network effects) than the original proprietary network.
6. The proprietary network is deprecated. Most users begin maintaining a duplicate facility that uses the IP substitute.
7. IP packets have very low overheads, less than 1%, and therefore compete very effectively on cost. An inexpensive transmission medium is developed that can carry IP to most of the users of the proprietary network.
8. The proprietary network is removed by most users to cut costs.
9. Die-hard users of the proprietary network are therefore forced to adopt.

Implementations

• KA9Q PPJ
• lwIP

Today, most commercial operating systems include and install the TCP/IP stack by default, For most users, there is no need to look for implementations. TCP/IP is included in all commercial Unix and Linux distributions as well as with Mac OS X and Microsoft Windows and Windows Server.

See also

• OSI Model
• DoD Model
• TCP and UDP port numbers

References

• Internet History -- Pages on Robert Kahn, Vinton Cerf, and TCP/IP (reviewed by Cerf and Kahn).

External links

• RFC 1180 A TCP/IP Tutorial - from the Internet Engineering Task Force (January 1991)
• TCP/IP FAQ
• A Study of the ARPANET TCP/IP Digest
• TCP/IP Sequence Diagrams
• The Internet in Practice
• Ateneo Network Research Group TCP/IP research at the Ateneo de Manila University
• TCP/IP Directory & Informational Resource.

TCP/IP 参考文献

• RFC 1122 - Requirements for Internet Hosts -- Communication Layers
• Joseph G. Davies and Thomas F. Lee. Microsoft Windows Server 2003 TCP/IP Protocols and Services. ISBN 0735612919
• Craig Hunt TCP/IP Network Administration. O'Reilly (1998) ISBN 1565923227
• W. Richard Stevens. The Protocols (TCP/IP Illustrated, Volume 1). Addison-Wesley Professional; 1st edition (December 31, 1993). ISBN 0201633469