?? tyt04fi.htm
字號:
<HTML>
<HEAD>
<TITLE>tyt04fi.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="tyt05fi.htm" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/tyt05fi.htm">
<LINK REL="Previous" HREF="tyt03fi.htm" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/tyt03fi.htm"></HEAD>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#800080"><A ID="I0" NAME="I0"></A>
<P><P ALIGN=CENTER>
<A HREF="tyt03fi.htm" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/tyt03fi.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="tyt05fi.htm" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/tyt05fi.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="#E68E35" >What Is TCP?</A></LI>
<LI>
<A HREF="#E68E36" >Following a Message</A></LI>
<LI>
<A HREF="#E68E37" >Ports and Sockets</A></LI>
<LI>
<A HREF="#E68E38" >TCP Communications with the Upper Layers</A></LI>
<LI>
<A HREF="#E68E39" >Passive and Active Ports</A></LI>
<LI>
<A HREF="#E68E40" >TCP Timers</A></LI>
<UL>
<LI>
<A HREF="#E69E64" >The Retransmission Timer</A></LI>
<LI>
<A HREF="#E69E65" >The Quiet Timer</A></LI>
<LI>
<A HREF="#E69E66" >The Persistence Timer</A></LI>
<LI>
<A HREF="#E69E67" >The Keep-Alive Timer and the Idle Timer</A></LI></UL>
<LI>
<A HREF="#E68E41" >Transmission Control Blocks and Flow Control</A></LI>
<LI>
<A HREF="#E68E42" >TCP Protocol Data Units</A></LI>
<LI>
<A HREF="#E68E43" >TCP and Connections</A></LI>
<UL>
<LI>
<A HREF="#E69E68" >Establishing a Connection</A></LI>
<LI>
<A HREF="#E69E69" >Data Transfer</A></LI>
<LI>
<A HREF="#E69E70" >Closing Connections</A></LI></UL>
<LI>
<A HREF="#E68E44" >User Datagram Protocol (UDP)</A></LI>
<LI>
<A HREF="#E68E45" >Summary</A></LI>
<LI>
<A HREF="#E68E46" >Q&A</A></LI>
<LI>
<A HREF="#E68E47" >Workshop</A></LI>
<UL>
<LI>
<A HREF="#E69E71" >Quiz</A></LI></UL></UL></UL></UL>
<HR ALIGN=CENTER>
<A ID="E66E4" NAME="E66E4"></A>
<H1 ALIGN=CENTER>
<CENTER>
<FONT SIZE=6 COLOR="#FF0000"><B>— 4 —</B>
<BR><B>TCP and UDP</B></FONT></CENTER></H1>
<BR>
<P>Yesterday's text examined the Internet Protocol (IP) in considerable detail. As you might remember, the Internet Protocol handles the lower-layer functionality. Today I look at the transport layer, where the Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) come into play.
<BR>
<P>TCP is one of the most widely used transport layer protocols, expanding from its original implementation on the ARPANET to connecting commercial sites all over the world. On Day 1, "Open Systems, Standards, and Protocols," you looked at the OSI seven-layer model, which bears a striking resemblance to TCP/IP's layered model, so it is not surprising that many of the features of the OSI transport layer were based on TCP.
<BR>
<P>In theory, a transport layer protocol could be a very simple software routine, but TCP cannot be called simple. Why use a transport layer that is as complex as TCP? The most important reason depends on IP's unreliability. As you saw yesterday, IP does not guarantee delivery of a datagram; it is a connectionless system with no reliability. IP simply handles the routing of datagrams, and if problems occur, IP discards the packet without a second thought (generating an ICMP error message back to the sender in the process). The task of ascertaining the status of the datagrams sent over a network and handling the resending of information if parts have been discarded falls to TCP, which can be thought of as riding shotgun over IP.
<BR>
<P>Most users think of TCP and IP as a tightly knit pair, but TCP can be (and frequently is) used with other protocols without IP. For example, TCP or parts of it are used in the File Transfer Protocol (FTP) and the Simple Mail Transfer Protocol (SMTP), both of which do not use IP.
<BR>
<BR>
<A ID="E68E35" NAME="E68E35"></A>
<H3 ALIGN=CENTER>
<CENTER>
<FONT SIZE=5 COLOR="#FF0000"><B>What Is TCP?</B></FONT></CENTER></H3>
<BR>
<P>The Transmission Control Protocol provides a considerable number of services to the IP layer and the upper layers. Most importantly, it provides a connection-oriented protocol to the upper layers that enable an application to be sure that a datagram sent out over the network was received in its entirety. In this role, TCP acts as a message-validation protocol providing reliable communications. If a datagram is corrupted or lost, TCP usually handles the retransmission, rather than the applications in the higher layers.
<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>TCP is not a piece of software. It is a communications protocol. When you install a TCP stack on your machine, you are installing the TCP layer, and usually a lot more software to provide the rest of the TCP/IP services. TCP is used as a catch-all phrase for TCP/IP in many cases. </NOTE>
<BR>
<HR ALIGN=CENTER>
</BLOCKQUOTE></BLOCKQUOTE>
<P>TCP manages the flow of datagrams from the higher layers to the IP layer, as well as incoming datagrams from the IP layer up to the higher level protocols. TCP has to ensure that priorities and security are properly respected. TCP must be capable of handling the termination of an application above it that was expecting incoming datagrams, as well as failures in the lower layers. TCP also must maintain a state table of all data streams in and out of the TCP layer. The isolation of all these services in a separate layer enables applications to be designed without regard to flow control or message reliability. Without the TCP layer, each application would have to implement the services themselves, which is a waste of resources.
<BR>
<P>TCP resides in the transport layer, positioned above IP but below the upper layers and their applications, as shown in Figure 4.1. TCP resides only on devices that actually process datagrams, ensuring that the datagram has gone from the source to the target machine. It does not reside on a device that simply routes datagrams, so there is usually no TCP layer in a gateway. This makes sense, because on a gateway the datagram has no need to go higher in the layered model than the IP layer.
<BR>
<P><B><A HREF="04tyt01.gif" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/04tyt01.gif">Figure 4.1. TCP provides end-to-end </B><B>communications.</A></B>
<BR>
<P>Because TCP is a connection-oriented protocol responsible for ensuring the transfer of a datagram from the source to destination machine (end-to-end communications), TCP must receive communications messages from the destination machine to acknowledge receipt of the datagram. The term <I>virtual circuit</I> is usually used to refer to the communications between the two end machines, most of which are simple acknowledgment messages (either confirmation of receipt or a failure code) and datagram sequence numbers.
<BR>
<BR>
<A ID="E68E36" NAME="E68E36"></A>
<H3 ALIGN=CENTER>
<CENTER>
<FONT SIZE=5 COLOR="#FF0000"><B>Following a Message</B></FONT></CENTER></H3>
<BR>
<P>To illustrate the role of TCP, it is instructive to follow a sample message between two machines. The processes are simplified at this stage, to be expanded on later today. The message originates from an application in an upper layer and is passed to TCP from the next higher layer in the architecture through some protocol (often referred to as an upper-layer protocol, or ULP, to indicate that it resides above TCP). The message is passed as a <I>stream</I>—a sequence of individual characters sent asynchronously. This is in contrast to most protocols, which use fixed blocks of data. This can pose some conversion problems with applications that handle only formally constructed blocks of data or insist on fixed-size messages.
<BR>
<P>TCP receives the stream of bytes and assembles them into TCP <I>segments</I>, or packets. In the process of assembling the segment, header information is attached at the front of the data. Each segment has a checksum calculated and embedded within the header, as well as a sequence number if there is more than one segment in the entire message. The length of the segment is usually determined by TCP or by a system value set by the system administrator. (The length of TCP segments has nothing to do with the IP datagram length, although there is sometimes a relationship between the two.)
<BR>
<P>If two-way communications are required (such as with Telnet or FTP), a connection (virtual circuit) between the sending and receiving machines is established prior to passing the segment to IP for routing. This process starts with the sending TCP software issuing a request for a TCP connection with the receiving machine. In the message is a unique number (called a socket number) that identifies the sending machine's connection. The receiving TCP software assigns its own unique socket number and sends it back to the original machine. The two unique numbers then define the connection between the two machines until the virtual circuit is terminated. (I look at sockets in a little more detail in a moment.)
<BR>
<P>After the virtual circuit is established, TCP sends the segment to the IP software, which then issues the message over the network as a datagram. IP can perform any of the changes to the segment that you saw in yesterday's material, such as fragmenting it and reassembling it at the destination machine. These steps are completely transparent to the TCP layers, however. After winding its way over the network, the receiving machine's IP passes the received segment up to the recipient machine's TCP layer, where it is processed and passed up to the applications above it using an upper-layer protocol.
<BR>
<P>If the message was more than one TCP segment long (not IP datagrams), the receiving TCP software reassembles the message using the sequence numbers contained in each segment's header. If a segment is missing or corrupt (which can be determined from the checksum), TCP returns a message with the faulty sequence number in the body. The originating TCP software can then resend the bad segment.
<BR>
<P>If only one segment is used for the entire message, after comparing the segment's checksum with a newly calculated value, the receiving TCP software can generate either a positive acknowledgment (ACK) or a request to resend the segment and route the request back to the sending layer.
<BR>
<P>The receiving machine's TCP implementation can perform a simple flow control to prevent buffer overload. It does this by sending a buffer size called a window value to the sending machine, following which the sender can send only enough bytes to fill the window. After that, the sender must wait for another window value to be received. This provides a handshaking protocol between the two machines, although it slows down the transmission time and slightly increases network traffic.
<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>The use of a sliding window is more efficient than a single block send and acknowledgment scheme because of delays waiting for the acknowledgment. By implementing a sliding window, several blocks can be sent at once. A properly configured sliding window protocol provides a much higher throughput.</NOTE>
<BR>
<HR ALIGN=CENTER>
</BLOCKQUOTE></BLOCKQUOTE>
<P>As with most connection-based protocols, timers are an important aspect of TCP. The use of a timer ensures that an undue wait is not involved while waiting for an ACK or an error message. If the timers expire, an incomplete transmission is assumed. Usually an expiring timer before the sending of an acknowledgment message causes a retransmission of the datagram from the originating machine.
<BR>
<P>Timers can cause some problems with TCP. The specifications for TCP provide for the acknowledgment of only the highest datagram number that has been received without error, but this cannot properly handle fragmentary reception. If a message is composed of several datagrams that arrive out of order, the specification states that TCP cannot acknowledge the reception of the message until all the datagrams have been received. So even if all but one datagram in the middle of the sequence have been successfully received, a timer might expire and cause all the datagrams to be resent. With large messages, this can cause an increase in network traffic.
<BR>
<P>If the receiving TCP software receives duplicate datagrams (as can occur with a retransmission after a timeout or due to a duplicate transmission from IP), the receiving version of TCP discards any duplicate datagrams, without bothering with an error message. After all, the sending system cares only that the message was received—not how many copies were received.
<BR>
<P>TCP does not have a negative acknowledgment (NAK) function; it relies on a timer to indicate lack of acknowledgment. If the timer has expired after sending the datagram without receiving an acknowledgment of receipt, the datagram is assumed to have been lost and is retransmitted. The sending TCP software keeps copies of all unacknowledged datagrams in a buffer until they have been properly acknowledged. When this happens, the retransmission timer is stopped, and the datagram is removed from the buffer.
<BR>
<P>TCP supports a push function from the upper-layer protocols. A push is used when an application wants to send data immediately and confirm that a message passed to TCP has been successfully transmitted. To do this, a push flag is set in the ULP connection, instructing TCP to forward any buffered information from the application to the destination as soon as possible (as opposed to holding it in the buffer until it is ready to transmit it).
<BR>
<BR>
<A ID="E68E37" NAME="E68E37"></A>
<H3 ALIGN=CENTER>
<CENTER>
<FONT SIZE=5 COLOR="#FF0000"><B>Ports and Sockets</B></FONT></CENTER></H3>
<BR>
<P>All upper-layer applications that use TCP (or UDP) have a port number that identifies the application. In theory, port numbers can be assigned on individual machines, or however the administrator desires, but some conventions have been adopted to enable better communications between TCP implementations. This enables the port number to identify the type of service that one TCP system is requesting from another. Port numbers can be changed, although this can cause difficulties. Most systems maintain a file of port numbers and their corresponding service.
<BR>
<P>Typically, port numbers above 255 are reserved for private use of the local machine, but numbers below 255 are used for frequently used processes. A list of frequently used port numbers is published by the Internet Assigned Numbers Authority and is available through an RFC or from many sites that offer Internet summary files for downloading. The commonly used port numbers on this list are shown in Table 4.1. The numbers 0 and 255 are reserved.
<BR>
<BR>
<P ALIGN=CENTER>
<CENTER>
<FONT COLOR="#000080"><B>Table 4.1. Frequently used TCP port numbers.</B></FONT></CENTER>
<BR>
<CENTER><TABLE BORDERCOLOR=#000040 BORDER=1 CELLSPACING=2 CELLPADDING=3 >
<TR>
<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>
<P><B><I>Port </I></B><B><I>Number</I></B>
</FONT>
<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>
<P><B><I>Process Name</I></B>
</FONT>
<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>
<P><B><I>Description</I></B>
</FONT>
<TR>
<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>
<P>1
<BR>
</FONT>
<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>
<P>TCPMUX
<BR>
</FONT>
<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>
<P>TCP Port Service Multiplexer
<BR>
</FONT>
<TR>
<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>
<P>5
<BR>
</FONT>
<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>
<P>RJE
<BR>
</FONT>
<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>
<P>Remote Job Entry
<BR>
</FONT>
<TR>
<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>
<P>7
<BR>
</FONT>
<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>
<P>ECHO
<BR>
</FONT>
<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>
<P>Echo
<BR>
</FONT>
<TR>
<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>
<P>9
<BR>
</FONT>
<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>
<P>DISCARD
<BR>
</FONT>
<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>
<P>Discard
<BR>
</FONT>
<TR>
<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>
<P>11
<BR>
</FONT>
<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>
<P>USERS
<BR>
</FONT>
<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>
<P>Active Users
<BR>
</FONT>
<TR>
<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>
<P>13
<BR>
</FONT>
<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>
<P>DAYTIME
<BR>
</FONT>
<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>
<P>Daytime
<BR>
</FONT>
<TR>
<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>
<P>17
<BR>
</FONT>
<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>
<P>Quote
<BR>
</FONT>
<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>
<P>Quotation of the Day
<BR>
</FONT>
<TR>
<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>
<P>19
<BR>
</FONT>
<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>
<P>CHARGEN
<BR>
</FONT>
<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>
<P>Character generator
<BR>
</FONT>
<TR>
<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>
<P>20
<BR>
</FONT>
<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>
<P>FTP-DATA
<BR>
</FONT>
<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>
<P>File Transfer Protocol•Data
<BR>
</FONT>
<TR>
<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>
<P>21
<BR>
</FONT>
<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>
<P>FTP
<BR>
</FONT>
<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>
<P>File Transfer Protocol•Control
<BR>
</FONT>
<TR>
<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>
<P>23
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -