tyt04fi.htm

快速学习TCP/IP协议

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>SND.WND

<BR>

</FONT>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>Send Window

<BR>

</FONT>

<TR>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>SND.UP

<BR>

</FONT>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>Sequence number of last urgent set

<BR>

</FONT>

<TR>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>SND.WL1

<BR>

</FONT>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>Sequence number for last window update

<BR>

</FONT>

<TR>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>SND.WL2

<BR>

</FONT>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>Acknowledgment number for last window update

<BR>

</FONT>

<TR>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>SND.PUSH

<BR>

</FONT>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>Sequence number of last pushed set

<BR>

</FONT>

<TR>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>ISS

<BR>

</FONT>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>Initial send sequence number

<BR>

</FONT>

<TR>

<TD COLSPAN=2 ALIGN=center  BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P ALIGN=CENTER>

<CENTER><B><I>Receive Variables</I></B></CENTER>

</FONT>

<TR>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>RCV.NXT

<BR>

</FONT>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>Sequence number of next received set

<BR>

</FONT>

<TR>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>RCV.WND

<BR>

</FONT>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>Number of sets that can be received

<BR>

</FONT>

<TR>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>RCV.UP

<BR>

</FONT>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>Sequence number of last urgent data

<BR>

</FONT>

<TR>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>RCV.IRS

<BR>

</FONT>

<TD BGCOLOR=#80FFFF ><FONT COLOR=#000080>

<P>Initial receive sequence number</FONT>

</TABLE></CENTER><BR>

<P>Using these variables, TCP controls the flow of information between two sockets. A sample connection session helps illustrate the use of the variables. It begins with Machine A wanting to send five blocks of data to Machine B. If the window limit is seven blocks, a maximum of seven blocks can be sent without acknowledgment. The SND.UNA variable on Machine A indicates how many blocks have been sent but are unacknowledged (5), and the SND.NXT variable has the value of the next block in the sequence (6). The value of the SND.WND variable is 2 (seven blocks possible, minus five sent), so only two more blocks could be sent without overloading the window. Machine B returns a message with the number of blocks received, and the window limit is adjusted accordingly.

<BR>

<P>The passage of messages back and forth can become quite complex as the sending machine forwards blocks unacknowledged up to the window limit, waiting for acknowledgment of earlier blocks that have been removed from the incoming cue, and then sending more blocks to fill the window again. The tracking of the blocks becomes a matter of bookkeeping, but with large window limits and traffic across internetworks that sometimes cause blocks to go astray, the process is, in many ways, remarkable.

<BR>

<BR>

<A ID="E68E42" NAME="E68E42"></A>

<H3 ALIGN=CENTER>

<CENTER>

<FONT SIZE=5 COLOR="#FF0000"><B>TCP Protocol Data Units</B></FONT></CENTER></H3>

<BR>

<P>As mentioned earlier, TCP must communicate with IP in the layer below (using an IP-defined method) and applications in the upper layer (using the TCP-ULP primitives). TCP also must communicate with other TCP implementations across networks. To do this, it uses Protocol Data Units (PDUs), which are called segments in TCP parlance.

<BR>

<P>The layout of the TCP PDU (commonly called the header) is shown in Figure 4.5.

<BR>

<P><B><A HREF="04tyt05.gif" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/04tyt05.gif">Figure 4.5. The TCP Protocol Data Unit.</A></B>

<BR>

<P>The different fields are as follows:

<BR>

<UL>

<LI><B>Source port:</B> A 16-bit field that identifies the local TCP user (usually an upper-layer application program).

<BR></LI>

<BR>

<LI><B>Destination port:</B> A 16-bit field that identifies the remote machine's TCP user.

<BR></LI>

<BR>

<LI><B>Sequence number:</B> A number indicating the current block's position in the overall message. This number is also used between two TCP implementations to provide the initial send sequence (ISS) number.

<BR></LI>

<BR>

<LI><B>Acknowledgment number:</B> A number that indicates the next sequence number expected. In a backhanded manner, this also shows the sequence number of the last data received; it shows the last sequence number received plus 1.

<BR></LI>

<BR>

<LI><B>Data offset:</B> The number of 32-bit words that are in the TCP header. This field is used to identify the start of the data field.

<BR></LI>

<BR>

<LI><B>Reserved:</B> A 6-bit field reserved for future use. The six bits must be set to 0.

<BR></LI>

<BR>

<LI><B>Urg flag:</B> If on (a value of 1), indicates that the urgent pointer field is significant.

<BR></LI>

<BR>

<LI><B>Ack flag:</B> If on, indicates that the Acknowledgment field is significant.

<BR></LI>

<BR>

<LI><B>Psh flag:</B> If on, indicates that the push function is to be performed.

<BR></LI>

<BR>

<LI><B>Rst flag:</B> If on, indicates that the connection is to be reset.

<BR></LI>

<BR>

<LI><B>Syn flag:</B> If on, indicates that the sequence numbers are to be synchronized. This flag is used when a connection is being established.

<BR></LI>

<BR>

<LI><B>Fin flag:</B> If on, indicates that the sender has no more data to send. This is the equivalent of an end-of-transmission marker.

<BR></LI>

<BR>

<LI><B>Window:</B> A number indicating how many blocks of data the receiving machine can accept.

<BR></LI>

<BR>

<LI><B>Checksum:</B> Calculated by taking the 16-bit one's complement of the one's complement sum of the 16-bit words in the header (including pseudo-header) and text together. (A rather lengthy process required to fit the checksum properly into the header.)

<BR></LI>

<BR>

<LI><B>Urgent pointer:</B> Used if the urg flag was set; it indicates the portion of the data message that is urgent by specifying the offset from the sequence number in the header. No specific action is taken by TCP with respect to urgent data; the action is determined by the application.

<BR></LI>

<BR>

<LI><B>Options:</B> Similar to the IP header option field, this is used for specifying TCP options. Each option consists of an option number (one byte), the number of bytes in the option, and the option values. Only three options are currently defined for TCP:

<BR>

<BR>0     End of option list

<BR>

<BR>1     No operation

<BR>

<BR>2     Maximum segment size

<BR></LI>

<BR>

<LI><B>Padding:</B> Filled to ensure that the header is a 32-bit multiple.

<BR></LI>

<BR>

</UL>

<P>Following the PDU or header is the data. The Options field has one useful function: to specify the maximum buffer size a receiving TCP implementation can accommodate. Because TCP uses variable-length data areas, it is possible for a sending machine to create a segment that is longer than the receiving software can handle.

<BR>

<P>The Checksum field calculates the checksum based on the entire segment size, including a 96-bit pseudoheader that is prefixed to the TCP header during the calculation. The pseudoheader contains the source address, destination address, protocol identifier, and segment length. These are the parameters that are passed to IP when a send instruction is passed, and also the ones read by IP when delivery is attempted.

<BR>

<BR>

<A ID="E68E43" NAME="E68E43"></A>

<H3 ALIGN=CENTER>

<CENTER>

<FONT SIZE=5 COLOR="#FF0000"><B>TCP and Connections</B></FONT></CENTER></H3>

<BR>

<P>TCP has many rules imposed on how it communicates. These rules and the processes that TCP follows to establish a connection, transfer data, and terminate a connection are usually presented in state diagrams. (Because TCP is a state-driven protocol, its actions depend on the state of a flag or similar construct.) Avoiding overly complex state diagrams is difficult, so flow diagrams can be used as a useful method for understanding TCP.

<BR>

<BR>

<A ID="E69E68" NAME="E69E68"></A>

<H4 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>Establishing a Connection</B></FONT></CENTER></H4>

<BR>

<P>A connection can be established between two machines only if a connection between the two sockets does not exist, both machines agree to the connection, and both machines have adequate TCP resources to service the connection. If any of these conditions are not met, the connection cannot be made. The acceptance of connections can be triggered by an application or a system administration routine.

<BR>

<P>When a connection is established, it is given certain properties that are valid until the connection is closed. Typically, these are a precedence value and a security value. These settings are agreed upon by the two applications when the connection is in the process of being established.

<BR>

<P>In most cases, a connection is expected by two applications, so they issue either active or passive open requests. Figure 4.6 shows a flow diagram for a TCP open. The process begins with Machine A's TCP receiving a request for a connection from its ULP, to which it sends an active open primitive to Machine B. (Refer back to Table 4.2 for the TCP primitives.) The segment that is constructed has the SYN flag set on (set to 1) and has a sequence number assigned. The diagram shows this with the notation &quot;SYN SEQ 50,&quot; indicating that the SYN flag is on and the sequence number (Initial Send Sequence number or ISS) is 50. (Any number could have been chosen.)

<BR>

<P><B><A HREF="04tyt06.gif" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/04tyt06.gif">Figure 4.6. Establishing a connection.</A></B>

<BR>

<P>The application on Machine B has issued a passive open instruction to its TCP. When the SYN SEQ 50 segment is received, Machine B's TCP sends an acknowledgment back to Machine A with the sequence number of 51. Machine B also sets an ISS number of its own. The diagram shows this message as &quot;ACK 51; SYN 200,&quot; indicating that the message is an acknowledgment with sequence number 51, it has the SYN flag set, and it has an ISS of 200.

<BR>

<P>Upon receipt, Machine A sends back its own acknowledgment message with the sequence number set to 201. This is &quot;ACK 201&quot; in the diagram. Then, having opened and acknowledged the connection, Machine A and Machine B both send connection open messages through the ULP to the requesting applications.

<BR>

<P>It is not necessary for the remote machine to have a passive open instruction, as mentioned earlier. In this case, the sending machine provides both the sending and receiving socket numbers, as well as precedence, security, and timeout values. It is common for two applications to request an active open at the same time. This is resolved quite easily, although it does involve a little more network traffic.

<BR>

<BR>

<A ID="E69E69" NAME="E69E69"></A>

<H4 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>Data Transfer</B></FONT></CENTER></H4>

<BR>

<P>Transferring information is straightforward, as shown in Figure 4.7. For each block of data received by Machine A's TCP from the ULP, TCP encapsulates it and sends it to Machine B with an increasing sequence number. After Machine B receives the message, it acknowledges it with a segment acknowledgment that increments the next sequence number (and hence indicates that it has received everything up to that sequence number). Figure 4.7 shows the transfer of two segments of information&#151;one each way.

<BR>

<P><B><A HREF="04tyt07.gif" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/04tyt07.gif">Figure 4.7. Data transfers.</A></B>

<BR>

<P>The TCP data transport service actually embodies six subservices:

<BR>

<UL>

<LI><B>Full duplex:</B> Enables both ends of a connection to transmit at any time, even simultaneously.

<BR></LI>

<BR>

<LI><B>Timeliness:</B> The use of timers ensures that data is transmitted within a reasonable amount of time.

<BR></LI>

<BR>

<LI><B>Ordered:</B> Data sent from one application is received in the same order at the other end. This occurs despite the fact that the datagrams might be received out of order through IP, because TCP reassembles the message in the correct order before passing it up to the higher layers.

<BR></LI>

<BR>

<LI><B>Labeled:</B> All connections have an agreed-upon precedence and security value.

<BR></LI>

<BR>

<LI><B>Controlled flow:</B> TCP can regulate the flow of information through the use of buffers and window limits.

<BR></LI>

<BR>

<LI><B>Error correction:</B> Checksums ensure that data is free of errors (within the checksum algorithm's limits).

<BR></LI>

<BR>

</UL>

<BR>

<A ID="E69E70" NAME="E69E70"></A>

<H4 ALIGN=CENTER>

<CENTER>

<FONT SIZE=4 COLOR="#FF0000"><B>Closing Connections</B></FONT></CENTER></H4>

<BR>

<P>To close a connection, one of the TCPs receives a close primitive from the ULP and issues a message with the FIN flag set on. This is shown in Figure 4.8. In the figure, Machine A's TCP sends the request to close the connection to Machine B with the next sequence number. Machine B then sends back an acknowledgment of the request and its next sequence number. Following this, Machine B sends the close message through its ULP to the application and waits for the application to acknowledge the closure. This step is not strictly necessary; TCP can close the connection without the application's approval, but a well-behaved system would inform the application of the change in state.

<BR>

<P><B><A HREF="04tyt08.gif" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/04tyt08.gif">Figure 4.8. Closing a connection.</A></B>

<BR>

<P>After receiving approval to close the connection from the application (or after the request has timed out), Machine B's TCP sends a segment back to Machine A with the FIN flag set. Finally, Machine A acknowledges the closure, and the connection is terminated.

<BR>

<P>An abrupt termination of a connection can occur when one side shuts down the socket. This can be done without any notice to the other machine and without regard to any information in transit between the two. Aside from sudden shutdowns caused by malfunctions or power outages, abrupt termination can be initiated by a user, an application, or a system monitoring routine that judges the connection worthy of termination. The other end of the connection might not realize that an abrupt termination has occurred until it attempts to send a message and the timer expires.

<BR>

<P>To keep track of all the connections, TCP uses a connection table. Each existing connection has an entry in the table that shows information about the end-to-end connection. The layout of the TCP connection table is shown in Figure 4.9.

<BR>

<P><B><A HREF="04tyt09.gif" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/04tyt09.gif">Figure 4.9. The TCP connection table.</A></B>

<BR>

<P>The meaning of each column is as follows:

<BR>

<UL>

<LI><B>State:</B> The state of the connection (closed, closing, listening, waiting, and so on).

<BR></LI>

<BR>

<LI><B>Local address:</B> The IP address for the connection. When in a listening state, this is set to 0.0.0.0.

<BR></LI>

<BR>

<LI><B>Local port:</B> The local port number.

<BR></LI>

<BR>

<LI><B>Remote address:</B> The remote machine's IP address.

<BR></LI>

<BR>

<LI><B>Remote port:</B> The port number of the remote connection.

<BR></LI>

<BR>

</UL>

<BR>

<A ID="E68E44" NAME="E68E44"></A>

<H3 ALIGN=CENTER>

<CENTER>

<FONT SIZE=5 COLOR="#FF0000"><B>User Datagram Protocol (UDP)</B></FONT></CENTER></H3>

<BR>

<P>TCP is a connection-based protocol. There are times when a connectionless protocol is required, so UDP is used. UDP is used with both the Trivial File Transfer Protocol (TFTP) and the Remote Call Procedure (RCP). Connectionless communications don't provide reliability, meaning there is no indication to the sending device that a message has been received correctly. Connectionless protocols also do not offer error-recovery capabilities&#151;which must be either ignored or provided in the higher or lower layers. UDP is much simpler than TCP. It interfaces with IP (or other protocols) without the bother of flow control or error-recovery mechanisms, acting simply as a sender and receiver of datagrams.

<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>UDP is connectionless; TCP is based on connections. </NOTE>

<BR>

<HR ALIGN=CENTER>

</BLOCKQUOTE></BLOCKQUOTE>

<P>The UDP message header is much simpler than TCP's. It is shown in Figure 4.10. Padding can be added to the datagram to ensure that the message is a multiple of 16 bits.

<BR>

<P><B><A HREF="04tyt10.gif" tppabs="http://www.mcp.com/817948800/0-672/0-672-30885-1/04tyt10.gif">Figure 4.10. The UDP header.</A></B>

<BR>

<P>The fields are as follows:

<BR>

<UL>

<LI><B>Source port:</B> An optional field with the port number. If a port number is not specified, the field is set to 0.

<BR></LI>

<BR>

<LI><B>Destination port:</B> The port on the destination machin