?? tyt03fi.htm
字號:
<HTML>
<HEAD>
<TITLE>tyt03fi.htm</TITLE>
<LINK REL="ToC" HREF="index.htm" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/index.htm">
<LINK REL="Index" HREF="tppmsgs/msgs0.htm#3" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/htindex.htm">
<LINK REL="Next" HREF="tyt04fi.htm" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/tyt04fi.htm">
<LINK REL="Previous" HREF="tyt02fi.htm" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/tyt02fi.htm"></HEAD>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#800080"><A ID="I0" NAME="I0"></A>
<P><P ALIGN=CENTER>
<A HREF="tyt02fi.htm" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/tyt02fi.htm" TARGET="_self"><IMG SRC="blanprev.gif" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/blanprev.gif" WIDTH = 37 HEIGHT = 37 BORDER = 0 ALT="Previous Page"></A>
<A HREF="index.htm" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/index.htm" TARGET="_self"><IMG SRC="blantoc.gif" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/blantoc.gif" WIDTH = 37 HEIGHT = 37 BORDER = 0 ALT="TOC"></A>
<A HREF="tyt04fi.htm" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/tyt04fi.htm" TARGET="_self"><IMG SRC="blannext.gif" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/blannext.gif" WIDTH = 37 HEIGHT = 37 BORDER = 0 ALT="Next Page"></A>
<HR ALIGN=CENTER>
<P>
<UL>
<UL>
<UL>
<LI>
<A HREF="#E68E28" >Internet Protocol</A></LI>
<UL>
<LI>
<A HREF="#E69E51" >The Internet Protocol Datagram Header</A></LI>
<UL>
<LI>
<A HREF="#E70E7" >Version Number</A></LI>
<LI>
<A HREF="#E70E8" >Header Length</A></LI>
<LI>
<A HREF="#E70E9" >Type of Service</A></LI>
<LI>
<A HREF="#E70E10" >Datagram Length (or Packet Length) </A></LI>
<LI>
<A HREF="#E70E11" >Identification</A></LI>
<LI>
<A HREF="#E70E12" >Flags</A></LI>
<LI>
<A HREF="#E70E13" >Fragment Offset</A></LI>
<LI>
<A HREF="#E70E14" >Time to Live (TTL)</A></LI>
<LI>
<A HREF="#E70E15" >Transport Protocol</A></LI>
<LI>
<A HREF="#E70E16" >Header Checksum</A></LI>
<LI>
<A HREF="#E70E17" >Sending Address and Destination Address</A></LI>
<LI>
<A HREF="#E70E18" >Options</A></LI>
<LI>
<A HREF="#E70E19" >Padding</A></LI></UL>
<LI>
<A HREF="#E69E52" >A Datagram's Life</A></LI></UL>
<LI>
<A HREF="#E68E29" >Internet Control Message Protocol (ICMP)</A></LI>
<LI>
<A HREF="#E68E30" >IPng: IP Version 6</A></LI>
<UL>
<LI>
<A HREF="#E69E53" >IPng Datagram</A></LI>
<UL>
<LI>
<A HREF="#E70E20" >Priority Classification</A></LI>
<LI>
<A HREF="#E70E21" >Flow Labels</A></LI></UL>
<LI>
<A HREF="#E69E54" >128-Bit IP Addresses</A></LI>
<LI>
<A HREF="#E69E55" >IP Extension Headers</A></LI>
<UL>
<LI>
<A HREF="#E70E22" >Hop-by-Hop Headers</A></LI>
<LI>
<A HREF="#E70E23" >Routing Headers</A></LI>
<LI>
<A HREF="#E70E24" >Fragment Headers</A></LI>
<LI>
<A HREF="#E70E25" >Authentication Headers</A></LI></UL></UL>
<LI>
<A HREF="#E68E31" >Internet Protocol Support in Different Environments</A></LI>
<UL>
<LI>
<A HREF="#E69E56" >MS-DOS</A></LI>
<LI>
<A HREF="#E69E57" >Microsoft Windows</A></LI>
<LI>
<A HREF="#E69E58" >Windows NT</A></LI>
<LI>
<A HREF="#E69E59" >OS/2</A></LI>
<LI>
<A HREF="#E69E60" >Macintosh</A></LI>
<LI>
<A HREF="#E69E61" >DEC</A></LI>
<LI>
<A HREF="#E69E62" >IBM's SNA</A></LI>
<LI>
<A HREF="#E69E63" >Local Area Networks</A></LI></UL>
<LI>
<A HREF="#E68E32" >Summary</A></LI>
<LI>
<A HREF="#E68E33" >Q&A</A></LI>
<LI>
<A HREF="#E68E34" >Quiz</A></LI></UL></UL></UL>
<HR ALIGN=CENTER>
<A ID="E66E3" NAME="E66E3"></A>
<H1 ALIGN=CENTER>
<CENTER>
<FONT SIZE=6 COLOR="#FF0000"><B>— 3 —</B>
<BR><B>The Internet Protocol (IP)</B></FONT></CENTER></H1>
<BR>
<P>Yesterday I looked at the history of TCP/IP and the Internet in some detail. Today I move on to the first of the two important protocol elements of TCP/IP: the Internet Protocol, the "IP" part of TCP/IP. A good understanding of IP is necessary to continue on to TCP and UDP, because the IP is the component that handles the movement of datagrams across a network. Knowing how a datagram must be assembled and how it is moved through the networks helps you understand how the higher-level layers work with IP. For almost all protocols in the TCP/IP family, IP is the essential element that packages data and ensures that it is sent to its destination.
<BR>
<P>This chapter contains, unfortunately, even more detail on headers, protocols, and messaging than you saw in the last couple of days. This level of information is necessary in order for you to deal with understanding the applications and their interaction with IP, as well as troubleshooting the system. Although I don't go into exhaustive detail, there is enough here that you can refer back to this chapter whenever needed.
<BR>
<P>As with many of the subjects I look at in this book, don't assume that this chapter covers everything there is to know about IP. There are many books written on IP alone, going into each facet of the protocol and its functionality. Luckily, most of the details are transparent to you, and there is little advantage gained in knowing it. For that reason, I simplify the subject a little, still providing enough detail for you to see how IP works and what it does.
<BR>
<BR>
<A ID="E68E28" NAME="E68E28"></A>
<H3 ALIGN=CENTER>
<CENTER>
<FONT SIZE=5 COLOR="#FF0000"><B>Internet Protocol</B></FONT></CENTER></H3>
<BR>
<P>The Internet Protocol (IP) is a primary protocol of the OSI model, as well as an integral part of TCP/IP (as the name suggests). Although the word "Internet" appears in the protocol's name, it is not restricted to use with the Internet. It is true that all machines on the Internet can use or understand IP, but IP can also be used on dedicated networks that have no relation to the Internet at all. IP defines a protocol, not a connection. Indeed, IP is a very good choice for any network that needs an efficient protocol for machine-to-machine communications, although it faces some competition from protocols like Novell NetWare's IPX on small to medium local area networks that use NetWare as a PC server operating system.
<BR>
<P>What does IP do? Its main tasks are addressing of datagrams of information between computers and managing the fragmentation process of these datagrams. The protocol has a formal definition of the layout of a datagram of information and the formation of a header composed of information about the datagram. IP is responsible for the routing of a datagram, determining where it will be sent, and devising alternate routes in case of problems.
<BR>
<P>Another important aspect of IP's purpose has to do with unreliable delivery of a datagram. Unreliable in the IP sense means that the delivery of the datagram is not guaranteed, because it can get delayed, misrouted, or mangled in the breakdown and reassembly of message fragments. IP has nothing to do with flow control or reliability: there is no inherent capability to verify that a sent message is correctly received. IP does not have a checksum for the data contents of a datagram, only for the header information. The verification and flow control tasks are left to other components in the layer model. (For that matter, IP doesn't even properly handle the forwarding of datagrams. IP can make a guess as to the best routing to move a datagram to the next node along a path, but it does not inherently verify that the chosen path is the fastest or most efficient route.) Part of the IP system defines how gateways manage datagrams, how and when they should produce error messages, and how to recover from problems that might arise.
<BR>
<P>In the first chapter, you saw how data can be broken into smaller sections for transmission and then reassembled at another location, a process called fragmentation and reassembly. IP provides for a maximum packet size of 65,535 bytes, which is much larger than most networks can handle, hence the need for fragmentation. IP has the capability to automatically divide a datagram of information into smaller datagrams if necessary, using the principles you saw in Day 1.
<BR>
<P>When the first datagram of a larger message that has been divided into fragments arrives at the destination, a <I>reassembly timer</I> is started by the receiving machine's IP layer. If all the pieces of the entire datagram are not received when the timer reaches a predetermined value, all the datagrams that have been received are discarded. The receiving machine knows the order in which the pieces are to be reassembled because of a field in the IP header. One consequence of this process is that a fragmented message has a lower chance of arrival than an unfragmented message, which is why most applications try to avoid fragmentation whenever possible.
<BR>
<P>IP is connectionless, meaning that it doesn't worry about which nodes a datagram passes through along the path, or even at which machines the datagram starts and ends. This information is in the header, but the process of analyzing and passing on a datagram has nothing to do with IP analyzing the sending and receiving IP addresses. IP handles the addressing of a datagram with the full 32-bit Internet address, even though the transport protocol addresses use 8 bits. A new version of IP, called version 6 or IPng (IP Next Generation) can handle much larger headers, as you will see toward the end of today's material in the section titled "IPng: IP Version 6."
<BR>
<BR>
<A ID="E69E51" NAME="E69E51"></A>
<H4 ALIGN=CENTER>
<CENTER>
<FONT SIZE=4 COLOR="#FF0000"><B>The Internet Protocol Datagram Header</B></FONT></CENTER></H4>
<BR>
<P>It is tempting to compare IP to a hardware network such as Ethernet because of the basic similarities in packaging information. Yesterday you saw how Ethernet assembles a frame by combining the application data with a header block containing address information. IP does the same, except the contents of the header are specific to IP. When Ethernet receives an IP-assembled datagram (which includes the IP header), it adds its header to the front to create a frame—a process called <I>encapsulation.</I> One of the primary differences between the IP and Ethernet headers is that Ethernet's header contains the physical address of the destination machine, whereas the IP header contains the IP address. You might recall from yesterday's discussion that the translation between the two addresses is performed by the Address Resolution Protocol.
<BR>
<BLOCKQUOTE>
<BLOCKQUOTE>
<HR ALIGN=CENTER>
<BR>
<NOTE>
<IMG SRC="note.gif" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/note.gif" WIDTH = 75 HEIGHT = 46>Encapsulation is the process of adding something to the start (and sometimes the end) of data, just as a pill capsule holds the medicinal contents. The added header and tail give details about the enclosed data.</NOTE>
<BR>
<HR ALIGN=CENTER>
</BLOCKQUOTE></BLOCKQUOTE>
<P>The datagram is the transfer unit used by IP, sometimes more specifically called an Internet datagram, or IP datagram. The specifications that define IP (as well as most of the other protocols and services in the TCP/IP family of protocols) define headers and tails in terms of words, where a word is 32 bits. Some operating systems use a different word length, although 32 bits per word is the more-often encountered value (some minicomputers and larger systems use 64 bits per word, for example). There are eight bits to a byte, so a 32-bit word is the same as four bytes on most systems.
<BR>
<P>The IP header is six 32-bit words in length (24 bytes total) when all the optional fields are included in the header. The shortest header allowed by IP uses five words (20 bytes total). To understand all the fields in the header, it is useful to remember that IP has no hardware dependence but must account for all versions of IP software it can encounter (providing full backward-compatibility with previous versions of IP). The IP header layout is shown schematically in Figure 3.1. The different fields in the IP header are examined in more detail in the following subsections.
<BR>
<P><B><A HREF="03tyt01.gif" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/03tyt01.gif">Figure 3.1. The IP header layout.</A></B>
<BR>
<BR>
<A ID="E70E7" NAME="E70E7"></A>
<H5 ALIGN=CENTER>
<CENTER>
<FONT SIZE=4 COLOR="#FF0000"><B>Version Number</B></FONT></CENTER></H5>
<BR>
<P>This is a 4-bit field that contains the IP version number the protocol software is using. The version number is required so that receiving IP software knows how to decode the rest of the header, which changes with each new release of the IP standards. The most widely used version is 4, although several systems are now testing version 6 (called IPng). The Internet and most LANs do not support IP version 6 at present.
<BR>
<P>Part of the protocol definition stipulates that the receiving software must first check the version number of incoming datagrams before proceeding to analyze the rest of the header and encapsulated data. If the software cannot handle the version used to build the datagram, the receiving machine's IP layer rejects the datagram and ignores the contents completely.
<BR>
<BR>
<A ID="E70E8" NAME="E70E8"></A>
<H5 ALIGN=CENTER>
<CENTER>
<FONT SIZE=4 COLOR="#FF0000"><B>Header Length</B></FONT></CENTER></H5>
<BR>
<P>This 4-bit field reflects the total length of the IP header built by the sending machine; it is specified in 32-bit words. The shortest header is five words (20 bytes), but the use of optional fields can increase the header size to its maximum of six words (24 bytes). To properly decode the header, IP must know when the header ends and the data begins, which is why this field is included. (There is no start-of-data marker to show where the data in the datagram begins. Instead, the header length is used to compute an offset from the start of the IP header to give the start of the data block.)
<BR>
<BR>
<A ID="E70E9" NAME="E70E9"></A>
<H5 ALIGN=CENTER>
<CENTER>
<FONT SIZE=4 COLOR="#FF0000"><B>Type of Service</B></FONT></CENTER></H5>
<BR>
<P>The 8-bit (1 byte) Service Type field instructs IP how to process the datagram properly. The field's 8 bits are read and assigned as shown in Figure 3.2, which shows the layout of the Service Type field inside the larger IP header shown in Figure 3.1. The first 3 bits indicate the datagram's precedence, with a value from 0 (normal) through 7 (network control). The higher the number, the more important the datagram and, in theory at least, the faster the datagram should be routed to its destination. In practice, though, most implementations of TCP/IP and practically all hardware that uses TCP/IP ignores this field, treating all datagrams with the same priority.
<BR>
<P><B><A HREF="03tyt02.gif" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/03tyt02.gif">Figure 3.2. The 8-bit Service Type field </B><B>layout.</A></B>
<BR>
<P>The next three bits are 1-bit flags that control the delay, throughput, and reliability of the datagram. If the bit is set to 0, the setting is normal. A bit set to 1 implies low delay, high throughput, and high reliability for the respective flags. The last two bits of the field are not used. Most of these bits are ignored by current IP implementations, and all datagrams are treated with the same delay, throughput, and reliability settings.
<BR>
<P>For most purposes, the values of all the bits in the Service Type field are set to 0 because differences in precedence, delay, throughput, and reliability between machines are virtually nonexistent unless a special network has been established. Although these flags would be useful in establishing the best routing method for a datagram, no currently available UNIX-based IP system bothers to evaluate the bits in these fields. (Although it is conceivable that the code could be modified for high security or high reliability networks.)
<BR>
<BR>
<A ID="E70E10" NAME="E70E10"></A>
<H5 ALIGN=CENTER>
<CENTER>
<FONT SIZE=4 COLOR="#FF0000"><B>Datagram Length (or Packet Length) </B></FONT></CENTER></H5>
<BR>
<P>This field gives the total length of the datagram, including the header, in bytes. The length of the data area itself can be computed by subtracting the header length from this value. The size of the total datagram length field is 16 bits, hence the 65,535 bytes maximum length of a datagram (including the header). This field is used to determine the length value to be passed to the transport protocol to set the total frame length.
<BR>
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -