外文翻译--以太网和IEEE802

TCP/IP Illustrated Volume 1 The Protocols Chapter 1 .Introduction 1.3 TCP/IP Layering There are more protocols in the TCP/IP protcol suite. Figure 1.4 shows some of additional protocols that we talk about in this text. TCP and UDP are the two precominant transport ；ayer protocols. Both use OP the network layer. TCP provides areliable transport ；ayer,even though the service it uese(IP) is unrelitable. Chapters 17 througe 22 provike a detailed look at the operation of TCP. We then look at some TCP applications. Telnet and Tlogin in Chapter 26,FTP in Chapter 27,and SMTP in Chapter 28. The applications user processes. UDP sends and recieves datagrams for applications. A datagram is a unit of information(i.e., a ceertain number of bytes of information that is specified by the sender) that travels from the sender to the recerver. Unlike TCP, however,UDP is unreliable. There is no guarantee that the datafram ever gets to its final destination. Chapter 11 looks at UDP,and then Chapter 14(the Domain Name System),Chapter 15(the Trivial File Transfer Protocol),and Chapter 16(the Bootstrap Protocol)look at some applications that use UDP. SMNP(the Simp；e Nerwork Managemennt Protocol) also uses UDP, but since it deals with many of the other protocols,we save a discussion if it until Chapter 25. IP is the main protocol at the network layer. It is used by both TCP and UDP.Every piece of TCP and UDP data that gers transferred around an internert goes through the IP layer at both end systems and at every intermediate router.OnFigure 1.4 we also show an application accessing OP directly. This is rare,but possible.(Some older routing protocols were implementde thes way.Also, it is possible to wxperiment with new transport layer protocols using this feature.)Chapter 3 look at IP,but we save some of the details for later chapters where their discussion makes more sense.Chapters 9 and 10 look at how IP performw routing. ICMP is an adjunct to IP. It is used by the IP layer to cxchange error messages and other vital information with the IP layer in another host ir router.Chapter 6 looks at ICMP in mire detail.Although ICMP is used primarily by IP,it is possible for an application to also access it.Indeed well see that two popular diagnostic tools,ping and traceroute(Chapters 7 and 8),both use ICMP. IGMP is the Internet Group management Protocol.It is used with multicasting:sending aUDP datagram to multiple hosts. We describe the general propertise of broadcasting(sendihng aUDP datagramto every host on aspecified nerwork) and multicasting in Chapter 12,and then descrebe IGMP itself in Chapter 13. ARP(Address Resolution Protocol) and RARP (Reverse Address Resolution Protocol )are specialized protocols used only with certain types of nerwerk interfaces(such as Ethernet and token ring )to convert between the addresses used by the IP layer and the addresses used by the network interface.We examine these protocols in Chapters 45 and 5,respectively. 1.8 Client-Server Model Most netwirking applications are written assuming are side is the dirent and the client and the other the server. The purpose of the application is for the server to provide some defined service for clients. We can categorize servers into two classes:iterative or concurrent. An iterative server itsrates through the following steps. 1. Wait for a client requset to arrive 2. Process the client request. 3. Send the response back to the client that sent the request. 4. Go back to step. The problem with an iterative server is when step 2 takes a while.During this time no other clients are serviced. A concurrent server, on the other hand,performs the following steps. 1. Waet for a client request to arrive. 2. Start a new server to handle this clients rquest. This may involve creating new process,task,or thread,depending on what the underlying operating systim. This new server handles thiis clients entire requist.When complete,this new server timinates. 3. Go back to step C1. The advantage of aconcurrent server is that the server just spawns other servers to handle the client reqsets. Each client has,inessence, its own server.Assuming the operating systim allows multiprogramming,multiple clients are serviced concurrintly. The reason we categorize servers ,and not clients ,is because a client nomally cant tell whether its talking to an iterative server or a concurrent server. As a general rule,TCP servers are concurrent, and UDP servers are iterative,but there are a few wxceptions.Will look in detail at the impact of UDP in its servers Section 11.12, and the impact of TCP on its servers in Section 18.11. Chapter 2. Link Layer 2.1 Introduction From Figure 1.4 we see that the purpose of the link layer in the TCP/IP protocol suite is to send and receive IP datagrams for the IP module ARP requests and replies for the ARP module and RARP requests and replies for the RARP module TCP/IP supports many different link layers depending o the type of networking hardware being used: Ethernet token ring ,FDDI(Fiber Distributed Data Interface),RS-232 serial lines,and the like. In this chapter well lool at some of the details involved in the Ethernet link layer two specialized link layers for serial interfaces(SLIP and PPP),and the loopback driver thats part of most implementations Ethernet and SLIP are the link layers used for most of the examples in the book.Wi aloe talk about the MTU(Macimim Transmission Unit ),a characteristic of the link layer that wi encounter numerous times in the remaining chapters We also show some calculations lof how to choose the MTU for a serial line. 2.2 Ethernet and IEEE 802 Encapsulation The term Ethernet generally refers to a standard published in 1982 by Digital Equipment Corp., Intel Corp., and Xerox Corp. It is the predominant form of local area network techonology used with TCP/IP today. It uses an access method called CSMA/CD, which stands for Carrier Sense Multiple Access with Collision Detection. It operates at 10 Mbits/sed and uses 48-bit addresses. A few years later the IEEE 802 Committee published a sightly differebt set of standards.802.3 covers an entire set of CSMA/CD networks,802.4 covers token bus networks, and 802.5 covers token ring networks. Common to all three of these is the 802.2 standard that defines the logical link control common to many of the 802 networks ,Unfortunately the combination covers all the details of these IEEE802 standards. In the TCP/IP world ,the encapsulation of IP datagrams is defined in RFC 894 for Ethernets and in RFC requires that every Internet host connected to a 10Mbits/sec Ethernet cable: 1. Must be able to send and receive packets using RFC 8j94(Ethernet) encapsulation. 2. Should be able to receive RFC 1042 packets intermixed with RFC 894 packets. 3. May be able to send packets using RFC 1042 encapsulation. If the host can send both types of packets the packet sent must be configurable and the configuration option must default to RFC 894 packets. RFC 894 encapsulation is most commonly used. Figure 2.1 shows the two different forms of encapsulation. The number below each box in the figure is the size of that box in bytes. Both frame formats use 48-bit destination and source address .(802.3 allows 16-bit addresses to be used ,bit 48-bit addresses are nirmal.) These are what we call hardware addresses throughout the text. The ARP and RARP protocols(Chapters and 5)map between the 32-bit IP addresses and the 48-bit hardware addresses. The next 2 bytes are different in the two frame formats. The 802 length field says how many bytes follow,up to but not includeing the CRC at the end. The Ethernet type later in the SNAP haeder. Fortunately none of the nalid 802 length values is the same as the Tthenet type values ,making the two frame formats distinguishable. In the Ethernet frame the data immediately follows the type field while in the frame format 3 bytes of 802.2 LL Cand 5 bytes of 802.2 SNAP follow. The DSAP and SSAP are both set to the same 2-byte type field that we had with the Ethernet frame format. The CRC field is a cyclic redundancy check that detects errors in rest of the frame. There is a minimum size for 802.3 and Ethernet frames. Thos minimum requires that the data portion be at least 38 bytes for 802.3 or 46 bytes for Ethernet. To handle this ,pad bytes are inserted to assure that the frame is long enough. Well encounter this minimum when we start watching packets on the wire. In this text well display the Ethernet encapsulation when we need to ,because this is the most commonly used form of encapsulation. Chapter 3 IP: Internet Protocol 3.1 Inttoduction IP is the workhorse protocol of the TCP/IP protocol suite. All TCP, UDP, ICMP, and IGMP data gets transmitted as IP datagrams. Afact tht amazes many newcomers to TCP/IP, especially those from an X.25 or SNA background, is that IP provides an unreliable, connectionless datagram delivery service. By unreliable we mean there re no guarantees that an IP datagram successfully gets to its destination. IP provides a best effort service. When something goes wrong, such as a router temporarily running ort of buffers , IP has a simple error handling algorithm:throw away the datagram and try to send an ICMP message back to the source. Any required reliability must be provided by the upper layers. The term connectionless means that IP does net maintain any state information about successive datagrams. Each datagram is handled independently from all other datagrams. Those also means that IP datagrams can get delivered out of order. If a sou sends two consecutive datagrams to the same destination,each is routed independly and can take different routes ,with B arriving before A. In this chapter we take a brief look at the fields in the IP header,describe IP routing, and cover subnetting . we also liik at two useful commands: ifconfig and netstat. We leave adetailed discussion of some of the fields in the IP header for later when wi can see exactly how the fields are used. Chapter 18 . TCP Connection Establishment and Termination 18.3 Timeout of Connectio Establishment There are several instances when the connection cannot be established. In one example the server host is down To simulate this scenario we issue our telnet command after disconnecting the Ethernet cable from the servers host. Figure 18.6 shows the tcpdump output. The interesting point on this output os how frequently the clients TCP sends a SYN to try to establish the connection. The second segment is sent 5.8 seconds after the first, and the third is sent 24 seconds after the second. The time difference is 76 seconds.Most Berkeley-derived systems set a time limit of 75 seconds on the establishment of a new connection. Well see in Section 21.4 that the third packet sent by the client would have timed out around 16:25:29,48 seconds after it wes sent ,had the client not fiven up after 75 seconds. First Timeout Period One puzzling itwm in Figure 18.6 is that the first timeout period,5.8 seconds ,is close to 6 seconds,but not exact,while the second period is almost exactly 24 seconds. Ten more of these tests were run and the first timeout period took on various values between 5.59 seconds and 5.93 seconds. The second timeout period,however,was always 24.00. Whats happening here is that BSD implementations of TCP run a timer that goes off every 500 ms. This 500-ms timer is used for various TCP timeouts, all of which we cover in later chapters. When we type in the telnet command, an initial 6-second timer is established ,but it may expire any where betwiin 5.5 and 6 seconds in the future. Figure 18.7 shows whats happening. Although the timer is initialized to 12 ticks ,the first decrement of the timer can occur between 0 and 500 ms after it is set. From that point on the timer is decremented about every 500 ms, but the first period can e variable. When that 6-second timer expires at the tick labeled 0 in Figure 18.7, the timer is reset for 24 seconds in the future. This next timer will be close to 24 seconds, since it was set at a time when the TCPs 500-ms timer handler was called by the kernel. Type-of-Service Field In Figure 18.6, the notation appears. This is the type0of-service field in the IP datagram. The BSD/386 Telnet client sets the field for minimum delay. 18.4 Maximum Segment Size The macimum segment size is the largest “chunk” of data that TCP will send to the other end.When a connection is established ,each end can announce its MSS. The values weve seen have all been 1024. The resulting IP datagram is normally 40 bytes large:20 bytes for the TCP header and 20 bytes for the IP header. Some texts refer to this as a “negotiated” option. It is not negotiated in any way. When a connection is established,each end has the option of announcing the MSS it expects to receive. If one end does not receive an MSS option from the other end, adefault of 536 bytes is assumed. In general, the larger the MSS the better, until fragmentation occurs. A large segment size allows more data to be sent in each segment, amortizing the cost of the IP and TCP headers. When TCP sends a SYN segment, either because a local application wants to send an MSS value up to the outgoing interfaces MTU, minus the size of the fixed TCP and IP headers. For an Ethernet thos implies an MSS of up to 1460 bytes. Using IEEE802.3 encapsulation, the MSS could go up to 1452 bytes. The values of 1024 that weve seen in this chapter, for connections involving BSD/386 and SVR4, are because many BSD implementations require the MSS to be a announce an MSS of 1460 when both ends are on a local Ethernet. Measurements in show how an MSS of 1460 provides better performance on an Ethernet than an MSS of 1024. If the destination IP address is “nonlocal,” the MSS normally defaults to 536. Ehile its easy to say that a destination whose IP address has the same network ID and the ent network ID from ours is nonlocal, a destination with the same network ID but a different subnet ID could be erther local or nonlocal. Most implementations provide a configuration iption that lets the system adminestrator mines whether the announced MSS is as large as possible or the default of 536. The MSS lets a host limet the size of datagrams that the other end sends it . When combined with the fact that a host can also limet the size of the datagrams that or sends, this lets a host avoid ftagmentation whaen the host os connected to a network with a small MTU. Consider our host slip ,which has a SLIP link with an MTU of 296 to the router bsdi. Figure 18.8 shows these systems and the host sun. The important fact here is that sun cannot send a segment with more than 256 bytes of data, since it received an MSS option of 256. Furthermore ,since slip knows that the outgoing interfaces MTU os 296 bytes of data, to avoid fragmentation. Its OK for a system to send less than the MSS announced by the other end. This avoidance of fragmentation works only if either host is directly connected to a network with an MTU of less than 5756. If both hosts are connected to Ethernets, and both announce an MSS of 536, but an intermediate network has an MTU of 296, fragmentation will occur. The only way around this is to use the path MTU discovery mechanism. 18.11 TCP Server Design We said in Section 1.8 that most TCP servers are concurrent. When a new connection request arrives at a server, the server accepts the connection and invokes a new process to handle the new client. Depending on the iperating system, various techniques are used to in voke the new server. Under Unixx the connom technique is to create a new process using the fork function. Lightweight processes can also be used ,if supported. What were interested in is the interaction of TCP with concurrent server. We need to answer the following questions:how are the port numbers handled when aserver accits anew connection request from a client ,and what happens if multiple connection requests arrive at about the same time? 18.11.1 TCP Server Port Numbers We can see how TCP handles the port numbers by watching any TCP server. Well watch the Telnet server using the netstat command. The following output is on a system with no active Telnet xonnections. The a flag reports on all network end points, not just those that are ESTABLISHED. The n flag prints IP addresses as dotted-decimal numbers,instead of trying to use the instead of service names. The f inet option reports only TCP and UDP end points. The local address is output as*.23. where the asterisk is normally called the wildcard character. This means that an incoming connection request will be accepted on any local intercface4. If the host were multihomed, we could specify asingle IP address for the local IP address ,and only connections received on that interface would be accepted. The local port is 23, the well-kown port number for Telnet. The foreign address is outputs as *.*, which means the foreign IP address and forrign port number are not known yet ,because the end point I in the LISTEN state ,waeting for aconnection toarrive. We now start a Telnet client on the host slip that connects to this server. Here are the relevant lines from the netstat output: The first line for port 23 is the ESTABLISHED connection. All four elements of the local and foreign address are filled in for this connection: the local IP address and port number,and the foreign IP address and port number. The local IP address corresponds to the interface on which the connection request arrived. The end point in the LISTEN state is left alone. This is the end point that the concurrent server uses to accept future connection requests. It is the TCP module in the kernel that creates the new end point in the ESTABLISHED state, when the incoming connection requewt arrines and is accepted. Also notice that the port number for the ESTABLISHED connection doesnt change: its 23, the same as the LISTEN end point. We now initiate another Telnet client from the same client to this server. Here is the relevant netstat output: We now have two ESTABLISHED connections from the same host to the same serer. Both have a local port number of 23. This is not a problem for TCP sincethe foreign port numbers are different. They must be different beacarse each of the Telnet clients rses an wpheneral port, and the definition of an ephemeral port os ene that os net currently in use on that host. This example reiterates that RCP demultiplexs incoming segments using all four values that comprise the local and foreign addresses:destination IP address, destination port number, source IP address, and source portnumber. TCP cannot detemine which the only one of the three end points at port 23 that will receive incoming connection requests is the one in the LISTEN state. The end points in the ESTABLISHED state can not receive SYN segments ,and the end point in the LISTEN state cannot receive datasegments. Next we initate a third Telnet client, from the host solaris that is across the SLIP link from sun, and not on its Ethernet. The local IP address of the first ESTABLISHED connedtion now corresponds to the interface address of SLIP link on the multihomed host sun. Chapter 21 . TCP Timeout and Retransmission 21.1 Introduction TCP provides a reliable transport layer. one of the ways it provides reliability is for each end to acknowledgments can get lost. TCP handles these by setting a timeout when to sends data, and of the data isnt acknowledge when the timeout expires, to retransmits the data. A critical element of any complementation is the timeout and retransmission strategy. How is the timeout interval determined, and how frequently does a retransmission occur? Weve already seen two examples of timeout and retransmission(1)In the ICMP port unreachable example in Section 6.5 we saw the TFTP client using UDP employing a simple timeout and retransmission strategy: it assumed 5 seconds was an adequate timeout period and retransmitted every 5 seconds.(2) In the ARP example to anonexistent host , wi saw that when TCP tried to establish the connection it retransmitted its SYN using a longer delay between each retransmisson. TCP manages four different timers for each connection. 1. A retransmisson timer is used when expectiong an acknowledgment from the other end. Thos chapter looks at this timer in detail, along with related issues such as congestion avoedance. 2. A persist timer keeps window size information flowing even if the other end closes its receive window. Chapter 22 describes this timer. 3. A keepalive timer detects when the other end on an otherwise idle connection crashes or reboots. Chapter 23 describes this timer. 4. A 2MSL timer measures the time a connection has been in the TOME_WAIT state. We described these state in Section 18.6. In this chapter wi start with a simple example of TCPs tomeout and retransmission and then move to a larger example that lets us liik at all the details involved in TCPs timer management. We liik at how typical implementations measure the round-trip time of TCP segments and how TCP uses these measurements to estimate the retransmission timeout of the next segment it transmits. We then look at TCPs congestion avoidance-what TCP does when packets are lost-and follow through an actual example where packets are lost. We also look at the newer fast retransmit and fast recovery algorithms, and see how they let TCP detect lost packets faster than waiting for a timer to expire. 21.2 Simple Timeout and Retransmission Example Lets first look at the retransmission strategy used by TCP. Well establish a connection, send some data to verify that everything is OK, disconnect the cable, send some more data, and watch what TCP does: Figure 21.1 shows the tcpdump output. Lines 1, 2, and 3 correspond to the normal TCP connection establishment. Line 4 is the transmission of “hello, world” and line 5 is its acknowledgment. We then disconnect the Ethernet cable from svr4. Line 6 shows “and hi” being sent .Lines 7-18 are 12 retransmissions of that segment, and line 19 is when the sending TCP finally gives up and sends a reset. Ecamine the time difference betwiin successive retransmissions: with rounding thru occur 1,3,6,12,24,48, and the 64 wsconds apart. Well see later in this chapter that the first timeout is actually set for 1.5 seconds after the first transmission After this the timeout value is doubled for each retransmission, with an upper limit of 64 seconds. This doubling is called an exponetial backoff. Compare thos to the TFTP example in Section 6.5,where every retransmission occurred 5 seconds after the previous. The time difference betwoon the first ransmission of the packet is about 9 minutes. Modern TCPs are persistent when trying to send data! 21.3 Round-Trip Time Measurement Fundamental to TCPs timeout and retransmission is the measurement of the round-trip time experienced on a given connection. We expect this can change over time, as routes might change and as network traffic changes, and TCP should track these changes and modify its timeout accordingly.； First TCP must measure the RTT between sendong abute with aparticular sequence number and receiving an acknowledgment that covers that sequence number. Recall from the prevous chapter that normally there is not a one-to-one correspondence between data segments and ACKs. In Figure 20.1 this means that one RTT that can be meacured by the sender is the time betwiin the transmission of segment 4 and the reception of segment 7, even though this ACK is for an additional 1024 bytes. Well use M to denote the measured RTT. The original TCP specification had TCP update a smoothed RTT estimator using the low-pass filter R R+(1- )M Where is a smoothing factor with a recommended value of 0.9. Thos smoothed RTT os updated every time a new measurement is made. Ninety percint of each new estimate is from the previous estimate and 10% is from the new measurement. Given this smoothed estimater, which changes as the RTT changes, RFC 793 recommended the retransmission timeout value (RTO) be set to RTO=R Where is a delay variance factor with a recommended value of 2. Jacobson 1988 details the problems with this approach, basically that it cant keep up with wide fluctuations in the RTT, causing unnecessary retransmissions. As Jacobson notes, unnecessary retransmissions add to the network load, when the network is already liaded. It is the network equivalent of pouring gasoline on a fire. What.s needed is to keep rack of the variance in the RTT meacurements, in addition to the smoothed RTT estimator. Calculating the RTO based on both the ean and variance provides much better response to wide fluctuations in the round-trip times, than just calculating the RTO as a calculations we show below, which take into account the variance of the round-trip times. As described by Jacobsonm, the mean deviation is a good approximation to the standard deviation, but easier to compute. This leads to the following equations that are applied to each RTT measurement M. Err = M A A A + gErr D D + d(|Err|-D) RTO = A + 4D Where A is the smoothed RTT and D is the smoothed mean deviation. Rtt is the difference betwiin the measured value just obtained and the current RTT estimator. Both A and D are used o calculate the next retransmission timeout. The gain g is for the average and os set to 1/8. The gain for the deviation is and is set to 0.25. The larger gain for the deviation makes the RTO go up faster when the RTT changes. TCP/IP Illustrated Volume 3 TCP for Transaction, HTTP, NNTP, and the UNIX Domain Protocols Chapter 1. T/TCP Introduction 1.2 UDP Client-Server We begin with asimple UDP client=-server example, shoeing the client source code in Figure 1.1. The client sends a request to the server,the server processes the reques and sends back a reply. Create a UDP socket The socket function creates a UDP socket, returning a ninnegative descriptor to the process. The error-handling function err-sys kiss shown in Appendix B.2of Steven 1992.It accepts any number of arguments,formats them using vsprintf,prints the Unix error message corresponding to the errno value from the system call, and then terminates the process. Fill in servers address An Internet socket address structrure is first zeroed out using memset and then filled with the IP address and port number of the server. For simplicity we require the user to enter the IP address as a dotted-decimal number on the command line when the program is rn (argv1).We #define the servers port number(UDP_SERV_PORT)in the cliserv.h header, which is included at the beginning of all the programs in this chapter. This is done for simplicity and to avoid complicating the code with calls to gethostbyname and gerservbyname. Form request and send it to server The client forms arequest (which we show only as a comment)and sends it to the server using sendto. This causes asingle UDP datagram to e sent to the server.Once again, or simplicity, we assume afixed-sized request(REQUEST)and a fixed-sized reply(REPLAY).A real application would allocate room for its maximum-sized request and rely, but the actual request and reply would vary and would normally be smaller. Read and process reply from server The call to recvfrom blicks the process(i.e., puts it to sleep) until a datagram arrives for the client. The client then processes the reply(which we show as acomment)and terminates. Create UDP socket and bind local address The call to socket creates a UDP socket, and an Internet socket address structure is filled in with the servers local address . The local IP address is set to the wildcard interface(in case the servers host is multihomed,that is, has mire than one network interface). The pert number is set to the servers well-known port(UDP_SERV_PORT)which we said earlier is defined in the cliserv. header. This local IP address and well-known port are bound to the socket by bind. Process client requests The server then enters an infinite loop, waiting for aclient request to arrive(recvfrom),processing that request(which we show only as acomment),and sending back a reply(sendto). 1.3 TCP Client-Server Our next example of aclient-erver transaction appkication uses TCP. Figure 1.5 shows the client program. Create TCP socket and connect to server A TCP socket is created but socket and then an Internet socket address structure is filled in with the IP address and port number of the server. The call to connect causes TCPs tree-way handshake to occur, establishing a connection between the client and werver. Chapter 18 of Volume 1 provides additional details in the packet exchanges when TCP connections are established and terminated. Send request and half-close the connection The clients request is sent to the server by write. The client then clises one-half of the connection, the direction of data flow from the client to the server, by calling shutdown with a second argument of 1. This tells the server that the client is done sending data: it passes an end-of=file notification from the client to the server .A TCP segment containing the FIN flag is sent to the server . The client can still read from the connectiong-only one direction of data flow is closed. This is called TCPs half-close. Section 18.5 of Volume 1 provides additional details. Read reply The reply is read by our function read_ stream,shown in Figure 1.6.Since TCP is a byte-stream protocol, without any from of record markers, the reply from the servers TCP can be returned in one or mire TCP segments, This can be returned to the client process in one or mire reads. Furthermire we know that when the server has sent the complete reply, the server process clises the connection, causing its TCP to send a FIN segment to the client, which is retruned to the client process by read returning an dedn-of-file (areturn value of 0).To handle these detail, the function read_ stream calls read as many times as necessary, until either the input buffer is full, or an end-of-file is returned by read. The return value of the function is the number of bytes read. Create listening TCP socket A TCP socket is created and the servers ell-known port is bouned to the socket. As with the UDP server, the TCP server binds the wildcard as its local IP address. The call to listen makes the socket a listening socket on which incoming connections will be accepted ,and the second argument of SOMAXCONN sepcifies the maximum number if pending connections the kernel will queue for the socket. Accept a connection and process request The server blocks in the call to accept until aconnes action is established by the clients connect. The new socket descriptor returned by accept ,sockfd, refers to the connection to the client. The clients request is read by read_ stream and the reply is returned by write. TCPs TIME_WAIT State TCP requires that the endpoint that sends the first FIN, which in our example is the client, must remain in the TIME_WAIT state for twice the maximun segmeng lifetine onece he connection is completely closed by both ends. The recommended value for the MSL is 120 seconds ,implying a TIME_ WAIT delay if 4 minutes. While the connection is in the TIME_WAIT state ,that same connection cannot be opened again. Reducing the Number if Segments with TCP TCP can reduce the number of segments in the transaction shown in Figure 1.8 by combining data with the control segments ,as we shoe in Figure1.9. Notice that the fist segment now contains the SYN, data, and FIN, not just the SYN as we saw in Figure 1.8.Similarly the servers reply is combined with the servers FIN. Although this sequence of packets is legal under the rules of TCP, the author is not aware of a method for an application to cause TCP to generate these sequende of segments using the sockets API(hence the question mark that generates the first segment from the clien, and the question mark that generates the final segment from the serner)and knows of no implenmentations that actually generate this sequence of segments. 卷一：协议 第 1 章 概述 1.3 TCP/IP 的分层 在 T C P / I P协议族中，有很多种协议。图 1 - 4给出了本书将要讨论的其他协议。 T C P和 U D P是两种最为著名的运输层协议，二者都使用 I P作为网络层协议。 虽然 T C P使用不可靠的 I P服务，但它却提供一种可靠的运输层服务。本书第 1 7 2 2章将详细讨论 T C P的内部操作细节。然后，我们将介绍一些 T C P的应用，如第 2 6章中的 Te l n e t和 R l o g i n、第 2 7章中的 F T P以 及第 2 8章中的 S M T P等。这些应用通常都是用户进程。 U D P为应用程序发送和接收数据报。一个数据报是指从发送方传输到接收方的一个信息单元（例如，发送方指定的一定字节数的信息）。但是与 T C P不同的是， U D P是不可靠的，它不能保证数据报能安全无误地到达最终目的。本书第 11章将讨论 U D P，然后在第 1 4章（ D N S :域名系统），第 1 5章（ T F T P：简单文件传送协议），以及第 1 6章（ BO OT P：引导程序协议）介绍使用 U D P的应用程序。 S N M P也使用了 U D P协 议，但是由于它还要处理许多其他的协议，因此本书把它留到第 2 5章再进行讨论。 I P是网络层上的主要协议，同时被 T C P和 U D P使用。 T C P和 U D P的每组数据都通过端系统和每个中间路由器中的 I P层在互联网中进行传输。在图 1 - 4中，我们给出了一个直接访问 I P的应用程序。这是很少见的，但也是可能的（一些较老的选路协议就是以这种方式来实现的。当然新的运输层协议也有可能使用这种方式）。第 3章主要讨论 I P协议，但是为了使内容更加有针对 性，一些细节将留在后面的章节中进行讨论。第 9章和第 1 0章 讨论 I P如何进行选路。 I C M P是 I P协议的附属协议。 I P层用它来与其他主机或路由器交换错误报文和其他重要信息。第 6章对 I C M P的有关细节进行讨论。尽管 I C M P主要被 I P使用，但应用程序也有可能访问它。我们将分析两个流行的诊断工具， P i n g和 Tr a c e r o u t e（第 7章和第 8章），它们都使用了 I C M P。 I G M P是 I n t e r n e t组管理协议。它用来把一个 U D P数据报多播到多个主机。我们在第 1 2章中描述广播（把一个 U D P数据报发 送到某个指定网络上的所有主机）和多播的一般特性，然后在第 1 3章中对 I G M P协议本身进行描述。 A R P（地址解析协议）和 R A R P（逆地址解析协议）是某些网络接口（如以太网和令牌环网）使用的特殊协议，用来转换 I P层和网络接口层使用的地址。我们分别在第 4章和第 5章对这两种协议进行分析和介绍。 1.8 客户 -服务器模型 大部分网络应用程序在编写时都假设一端是客户，另一端是服务器，其目的是为了让服务器为客户提供一些特定的服务。 可以将这种服务分为两种类型：重复型或并发型。重复型服务器通过以下步骤 进行交互： I1. 等待一个客户请求的到来。 I2. 处理客户请求。 I3. 发送响应给发送请求的客户。 I4. 返回 I 1步。 重复型服务器主要的问题发生在 I 2状态。在这个时候，它不能为其他客户机提供服务。 相应地，并发型服务器采用以下步骤： C1. 等待一个客户请求的到来。 C2. 启动一个新的服务器来处理这个客户的请求。在这期间可能生成一个新的进程、任务或线程，并依赖底层操作系统的支持。这个步骤如何进行取决于操作系统。生成的新服务器对客户的全部请求进行处理。处理结束后，终止这个新服务器。 C3. 返回 C 1步。 并发服务器的优点在于它是利用生成其他服务器的方法来处理客户的请求。也就是说，每个客户都有它自己对应的服务器。如果操作系统允许多任务，那么就可以同时为多个客户服务。 对服务器，而不是对客户进行分类的原因是因为对于一个客户来说，它通常并不能够辨别自己是与一个重复型服务器或并发型服务器进行对话。 一般来说， T C P服务器是并发的，而 U D P服务器是重复的，但也存在一些例外。我们将在 11 . 1 2节对 U D P对其服务器产生的影响进行详细讨论，并在 1 8 . 11节对 T C P对其服务器的影 响进行讨论。 第 2 章 链路层 2.1 引言 从图 1 - 4中可以看出，在 T C P / I P协议族中，链路层主要有三个目的：（ 1）为 I P模块发送和接收 I P数据报；（ 2）为 A R P模块发送 A R P请求和接收 A R P应答；（ 3）为 R A R P发送 R A R P请求和接收 R A R P应答。 T C P / I P支持多种不同的链路层协议，这取决于网络所使用的硬件，如以太网、令牌环网、 F D D I（光纤分布式数据接口）及 R S-2 3 2串行线路等。在本章中，我们将详细讨论以太网链路层协议，两个串 行接口链路层协议（ S L I P和 P P P），以及大多数实现都包含的环回（ l o o p b a c k）驱动程序。以太网和 S L I P是本书中大多数例子使用的链路层。对 M T U（最大传输单元）进行了介绍，这个概念在本书的后面章节中将多次遇到。我们还讨论了如何为串行线路选择 M T U。 2.2 以太网和 IEEE 802 封装 以太网这个术语一般是指数字设备公司（ Digital Equipment Corp.）、英特尔公司（ I n t e lC o r p .）和 X e r o x公司在 1 9 8 2年联合公布的一个标准。它是当今 T C P / I P采用的主要的局域网技术。它采用一种称作 C S M A / C D的媒体接入方法，其意思是带冲突检测的载波侦听多路接入（ Carrier Sense, Multiple Access with Collision Detection）。它的速率为 10 Mb/s，地址为 48 bit。 几年后， I E E E（电子电气工程师协会） 8 0 2委员会公布了一个稍有不同的标准集，其中 8 0 2 . 3针对整个 C S M A / C D网络， 8 0 2 . 4针对 令牌总线网络， 8 0 2 . 5针对令牌环网络。这三者的共同特性由 8 0 2 . 2标准来定义，那就是 8 0 2网络共有的逻辑链路控制（ L L C）。不幸的是， 8 0 2 . 2和 8 0 2 . 3定义了一个与以太网不同的帧格式。文献 Stallings 1987对所有的 IEEE 802标准进行了详细的介绍。 在 T C P / I P世界中，以太网 I P数据报的封装是在 RFC 894Hornig 1984中定义的， IEEE 802网络的 I P数据报封装是在 RFC 1042Postel and Reynolds 1988中定义的。主机需求 R F C要求每台 I n t e r n e t主机都与一个 10 Mb/s的以太网电缆相连接： 1) 必须能发送和接收采用 RFC 894（以太网）封装格式的分组。 2) 应该能接收与 RFC 894混合的 RFC 1042（ IEEE 802）封装格式的分组。 3) 也许能够发送采用 RFC 1042格式封装的分组。 如果主机能同时发送两种类型的分组数据，那么发送的分组必须是可以设置的，而且默认条件下必须是 RFC 894分组。最常使用的封装格式是 RFC 894定义的格式。 图 2 - 1显示了两种不同形式的封装格式。图中每个方框下面的数字是它们的字节长度。两种帧格式都采用 48 bit（ 6字节）的目的地址和源地址（ 8 0 2 . 3允许使用 16 bit的地址，但一般是 48 bit地址）。这就是我们在本书中所称的硬件地址。 A R P和 R A R P协议（第 4章和第 5章）对 32 bit的 I P地址和 48 bit的硬件地址进行映射。接下来的 2个字节在两种帧格式中互不相同。在 8 0 2标准定义的帧格式中，长度字段是指它后续数据的字节长度，但不包括 C R C检验码。以太网的类型字段定义了 后续数据的类型。在 8 0 2标准定义的帧格式中，类型字段则由后续的子网接入协议（ Sub-network AccessP r o t o c o l， S N A P）的首部给出。幸运的是， 8 0 2定义的有效长度值与以太网的有效类型值无一相同，这样，就可以对两种帧格式进行区分。 在以太网帧格式中，类型字段之后就是数据；而在 8 0 2帧格式中，跟随在后面的是 3字节的 802.2 LLC和 5字节的 802.2 SNAP。目的服务访问点（ Destination Service Access Point,D S A P）和源服务访问点（ Source Service Access Point, SSAP）的值都设为 0 x a a。 Ct r l字段的值设为 3。随后的 3个字节 o rg code都置为 0。再接下来的 2个字节类型字段和以太网帧格式一样（其他类型字段值可以参见 RFC 1340 Reynolds and Postel 1992）。 C R C字段用于帧内后续字节差错的循环冗余码检验（检验和）（它也被称为 F C S或帧检验序列）。 8 0 2 . 3标准定义的帧和以太网的帧都有最小长度要求。 8 0 2 . 3规定数 据部分必须至少为 3 8字节，而对于以太网，则要求最少要有 4 6字节。为了保证这一点，必须在不足的空间插入填充（ p a d）字节。在开始观察线路上的分组时将遇到这种最小长度的情况。在本书中，我们在需要的时候将给出以太网的封装格式，因为这是最为常见的封装格式。 第 3 章 IP：网际协议 3.1 引言 I P是 T C P / I P协议族中最为核心的协议。所有的 T C P、 U D P、 I C M P及 I G M P数据都以 I P数据报格式传输（见图 1 - 4）。许多刚开始接触 T C P / I P的人对 I P提供不可靠、无连接的数据报传送服务感到很奇怪，特别是那些具有 X . 2 5或 S N A背景知识的人。 不可靠（ u n r e l i a b l e）的意思是它不能保证 I P数据报能成功地到达目的地。 I P仅提供最好的传输服务。如果发生某种错误时，如某个路由器暂时用完了缓冲区， I P有一个简单的错误处理算法：丢弃该数据报，然后发送I C M P消息报给信源端。任何要求的可靠性必须由上层来提供（如 T C P）。 无连接（ c o n n e c t i o n l e s s）这个术语的意思是 I P并不维护任何关于后续数据报的状态信息。每个数据报的处理是相互独立的。这也说明， I P数据报可以不按发送顺序接收。如果一信源向相同的信宿发送两个连续的数据报（先是 A，然后是 B），每个数据报都是独立地进行路由选择，可能选择不同的路线，因此 B可能在 A到达之前先到达。 在本章，我们将简要介绍 I P首部中的各个字段，讨论 I P路由选择和子网的有关内容。还要介绍两个有用的命令： i f c o n f i g和 n e t s t a t。关于 I P首部中一些字段的细节，将留在以后使用这些字段的时候再进行讨论。 RFC 791Postel 1981a是 I P的正式规范文件。 第 18章 TCP 的连接和终止 18.3 连接建立的超时 有很多情况导致无法建立连接。一种情况是服务器主机没有处于正常状态。为了模拟这种情况，我们断开服务器主机的电缆线，然后向它发出 telnet命令。图 18-6显示了 tcpdump的输出。 在这个输出中有趣的一点是客户间隔多长时间发送一个 SYN，试图建立连接。第2个 SYN与第 1个的间隔是 5.8秒，而第 3个与第 2个的间隔是 24秒。作为一个附注，这个例子运行 38分钟后客户重新启动。这对应初始序号为 291 008 001 （约为 38 60 64000 2）。我们曾经介绍过使用典型的伯克利实现版的系统将初始序号初始化为 1，然后每隔 0.5秒就增加 64000。另外，因为这是系统启动后的第一个 TCP连接，因此客户的端口号是 1024。 图 18-6中没有显示客户端在放弃建立连接尝试前进行 SYN重传的时间。为了了解它我们必须对 telnet命令进行计时： 时间差值是 76秒。大多数伯克利系统将建立一个新连接的最长时间限制为 75秒。我们将在 21.4节看到由客户发出的第 3个分组大约在 16:25:29超时， 客户在它第 3个分组发出后 48秒而不是 75秒后放弃连接。 18.3.1 第一次超时时间在图 18-6中一个令人困惑的问题是第一次超时时间为 5.8秒，接近 6秒，但不准确，相比之下第二个超时时间几乎准确地为 24秒。运行十多次测试，发现第一次超时时间在 5.59秒 5.93秒之间变化。然而，第二次超时时间则总是 24.00秒（精确到小数点后面两位）。 这是因为 BSD版的 TCP软件采用一种 500 ms的定时器。这种 500 ms的定时器用于确定本章中所有的各种各样的 TCP超时。当我们键入 telnet命令，将建立一个 6秒的定时器（ 12个时钟滴答（ tick），但它可能在之后的 5.5秒 6秒内的任意时刻超时。图 18-7显示了这一发生过程。 尽管定时器初始化为 12个时钟滴答，但定时计数器会在设置后的第一个 0500 ms中的任意时秒刻减 1。从那以后，定时计数器大约每隔 500 ms减 1，但在第 1个 500 ms内是可变的（我们使用限定词“大约”是因为在 TCP每隔 500 ms获得系统控制的瞬间，系统内核可能会优先处理其他中断）。 当滴答计数器为 0时， 6秒的定时器便会超时（见图 18-7），这个定时器会在以后的 24秒（ 48个滴答）重新复位。之后的下一个定时器将更接近 24秒，因为当TCP的 500 ms定时器被内核调用时，它就会被修改一次。 在图 18-6中，出现了符号 tos 0x10 。这是 IP数据报内的服务类型（ TOS）字段（参见图 3-2）。 BSD/386中的 Telnet客户进程将这个字段设置为最小时延。 18.4 最大报文段长度最大报文段长度（ MSS）表示 TCP传往另一端的最大块数据的长度。当一个连接建立时，连接的双方都要通告各自的 MSS。我们已经见过 MSS都是 1024。这导致 IP数据报通常是 40字节 长： 20字节的 TCP首部和 20字节的 IP首部。在有些书中，将它看作可“协商”选项。它并不是任何条件下都可协商。当建立一个连 接时，每一方都有用于通告它期望接收的 MSS选项（ MSS选项只能出现在 SYN报文段中）。如果一方不接收来自另一方的 MSS值，则 MSS就定为默认值 536字节（这个默认值允许 20字节的 IP首部和 20字节的 TCP首部以适合 576字节 IP数据报 ） 。 一般说来，如果没有分段发生， MSS还是越大越好（这也并不总是正确，参见图 24-3和图 24-4中的例子）。报文段越大允许每个报文段传送的数据就 越多，相对 IP和 TCP首部有更高的网络利用率。当 TCP发送一个 SYN时，或者是因为一个本地应用进程想发起一个连接，或者是因为另一端的主机收到了一个连接请求，它能将 MSS值设置为外出接口上的 MTU长度减去固定的 IP首部和 TCP首部长度。对于一个以太网， MSS值可达 1460字节。使用 IEEE 802.3的封装（参见 2.2节），它的 MSS可达 1452字节。 在本章见到的涉及 BSD/386和 SVR4的 MSS为 1024，这是因为许多 BSD的实现版本需要 MSS为 512的倍数。其他的系统，如 SunOS 4.1.3、 Solaris 2.2 和 AIX 3.2.2，当双方都在一个本地以太网上时都规定 MSS为 1460。 Mogul 1993 的比较显示了在以太网上 1460的 MSS在性能上比 1024的 MSS更好。如果目的 IP地址为“非本地的 (nonlocal)”， MSS通常的默认值为 536。而区分地址是本地还是非本地是简单的，如果目的 IP地址的网络号与子网号都和我们的相同，则是本地的；如果目的 IP地址的网络号与我们的完全不同，则是非本地的；如果目的 IP地址的网络号与我们的相同而子网号与我们的不同，则可能是本地的 ，也可能是非本地的。大多数 TCP实现版都提供了一个配置选项（附录 E和图 E-1），让系统管理员说明不同的子网是属于本地还是非本地。这个选项的设置将确定 MSS可以选择尽可能的大（达到外出接口的 MTU长度）或是默认值 536。 MSS让主机限制另一端发送数据报的长度。加上主机也能控制它发送数据报的长度，这将使以较小 MTU连接到一个网络上的主机避免分段。考虑我们的主机slip，通过 MTU为 296的 SLIP链路连接到路由器 bsdi上。图 18-8显示这些系统和主机 sun。 从 sun向 slip发起一个 TCP连接， 并使用 tcpdump来观察报文段。图 18-9显示这个连接 的建立（省略了通告窗口大小）。 在这个例子中， sun发送的报文段不能超过 256字节的数据，因为它收到的 MSS选项值为 256（第 2行）。此外，由于 slip知道它外出接口的 MTU长度为 296，即使 sun已经通告它的 MSS为 1460，但为避免将数据分段，它不会发送超过 256字节数据的报文段。系统允许发送的数据长度小于另一端的 MSS值。 只有当一端的主机以小于 576字节的 MTU直接连接到一个网络中，避免这种分段才会有效。如果两端的主机都连接到以 太网上，都采用 536的 MSS，但中间网络采用 296的 MTU，也将会出现分段。使用路径上的 MTU发现机制（参见 24.2节）是关于这个问题的唯一方法。 18.11 TCP 服务器的设计 我们在 1 . 8节说过大多数的 T C P服务器进程是并发的。当一个新的连接请求到达服务器时，服务器接受这个请求，并调用一个新进程来处理这个新的客户请求。不同的操作系统使用不同的技术来调用新的服务器进程。在 U n i x系统下，常用的技术是使用 f o r k函数来创建新的进程。如果系统支持，也可使用轻型进程，即线程（ t h r e a d）。 我们感兴趣的是 T C P与若干并发服务器的交互作用。需要回答下面的问题：当一个服务器进程接受一来自客户进程的服务请求时是如何处理端口的？如果多个连接请求几乎同时到 达会发生什么情况？ 18.11.1 TCP 服务器端口号 通过观察任何一个 T C P服务器，我们能了解 T C P如何处理端口号。我们使用 n e t s t a t命令来观察 Te l n e t服务器。下面是在没有 Te l n e t连接时的显示（只留下显示 Te l n e t服务器的行） sun % netstat -a -n -f inet Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp 0 0 *.23 *.* LISTEN a标志将显示网络中的所有主机端，而不仅仅是处于 E S TA B L I S H E D的主机端。 - n标志将以点分十进制的 形式显示 I P地址，而不是通过 D N S将地址转化为主机名，同时还要求显示端口号（例如为 2 3）而不是服务名称（如 Te l n e t）。 -f inet选项则仅要求显示使用 T C P或 U D P的主机。显示的本地地址为 * . 2 3，星号通常又称为通配符。这表示传入的连接请求（即 S Y N）将被任何一个本地接口所接收。如果该主机是多接口主机，我们将制定其中的一个 I P地址为本地 I P地址，并且只接收来自这个接口的连接（在本节后面我们将看到这样的例子）。本地端口为 2 3，这是 Te l n e t的熟知端口号。 远端地址显示为 * . *，表示还不知道远端 I P地址和端口号，因为该端还处于 L I S T E N状态，正等待连接请求的到达。现在我们在主机 s l i p（ 1 4 0 . 2 5 2 . 1 3 . 6 5）启动一个 Te l n e t客户程序来连接这个 Te l n e t服务器。以下是 n e t s t a t程序的输出行： Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp 0 0 3.23 5.1029 ESTABLISHED tcp 0 0 *.23 *.* LISTEN 端口号为 23的第 1行表示处于 E S TABLISHED 状态的连接。另外还显示了这个连接的本地 I P地址、本地端口号、远端 I P地址和远端端口号。本地 I P地址为该连接请求到达的接口（以太网接口， 1 4 0 . 2 5 2 . 1 3 . 3 3）。处于 L I S T E N状态的服务器进程仍然存在。这个服务器进程是当前 Te l n e t服务器用于接收其他的连接请求。当传入的连接请求到达并被接收时，系统内核中的T C P模块就创建一个处于 E S TA B L I S H E D状态的进程。另外，注意处于 E S TA B L I S H E D状态的连接的端口不会变化：也是 2 3，与处于 L I S T E N状态的进程相同。现在我们在主机 s l i p上启动另一个 Te l n e t客户进程，并仍与这个 Te l n e t服务器进行连接。以下是 n e t s t a t程序 的输出行： Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp 0 0 3.23 5.1030 ESTABLISHED tcp 0 0 3.23 5.1029 ESTABLISHED tcp 0 0 *.23 *.* LISTEN 现在我们有两条从相同主机到相同服务器的处于 E S TA B L I S H E D 的连接。它们的本地端口号均为 2 3。由于它们的远端端口号不同，这不会造成冲突。因为每个 Te l n e t 客户进程要使用一个外设端口，并且这个外设端口会选择为主机（ s l i p）当前未曾使用的端口，因此它们的端口号肯定不同。这个例子再次重申 T C P使用由本地地址和远端地址组成的 4元组：目的 I P 地址、目的端口号、源 I P地址和源端口号来处理传入的多个连接 请求。 T C P 仅通过目的端口号无法确定那个进程接收了一个连接请求。另外，在三个使用端口 2 3的进程中，只有处于 L I S T E N 的进程能够接收新的连接请求。处于 E S TA B L I S H E D的进程将不能接收 S Y N报文段，而处于 L I S T E N的进程将不能接收数据报文段。下面我们从主机 s o l a r i s 上启动第 3 个 Te l n e t 客户进程，这个主机通过 S L I P链路与主机 s u n 相连，而不是以太网接口。 第 21 章 TCP 的超时与重传 21.1 引言 TCP提供可靠的运输层。它使用的方法之一就是确认从另一端收到的数据。但数据和确认都有可能会丢失。 TCP通过在发送时设置一个定时器来解决这种问题。如果当定时器溢出时还没有收到确认，它就重传该数据。对任何实现而言，关键之处就在于超时和重传的策略，即怎样决定超时间隔和如何确定重传的频率。 我们已经看到过两个超时和重传的例子：（ 1）在 6.5节的 ICMP端口不能到达的例子中，看到 TFTP客户使用 UDP实现了一个简单的超时和重传机制：假定 5秒是一个适当的时间间隔，并每隔 5秒进行重传；（ 2）在向一个不存在的主机发 送 ARP的例子中（第 4.5节），我们看到当 TCP试图建立连接的时候，在每个重传之间使用一个较长的时延来重传 SYN。 对每个连接， TCP管理 4个不同的定时器。 1) 重传定时器使用于当希望收到另一端的确认。在本章我们将详细讨论这个定时器以及一些相关的问题，如拥塞避免。 2) 坚持 (persist)定时器使窗口大小信息保持不断流动，即使另一端关闭了其接收窗口。第 22章将讨论这个问题。 3) 保活 (keepalive)定时器可检测到一个空闲连接的另一端何时崩溃或重启。第 23章将描述这个定时器。 4) 2MSL定时器测量一个连接处于 TIME_WAIT状态的时间。我们在 18.6节对该状态进行了介绍。 本章以一个简单的 TCP超时和重传的例子开始，然后转向一个更复杂的例子。该例子可以使我们观察到 TCP时钟管理的所有细节。可以看到 TCP的典型实现是怎样测量 TCP报文段的往返时间以及 TCP如何使用这些测量结果来为下一个将要传输的报文段建立重传超时时间。接着我们将研究 TCP的拥塞避免 当分组丢失时 TCP所采取的动作 并提供一个分组丢失的实际例子，我们还将介绍较新的快速重传和快速恢复算法，并介绍该算法如何使 TCP检测分组丢失比等待时钟超时更快 21.2 超时与重传的简单例子 首先观察 TCP所使用的重传机制，我们将建立一个连接，发送一些分组来证明一切正常，然后拔掉电缆，发送更多的数据，再观察 TCP的行为。 图 21-1表示的是 tcpdump的输出结果（已经去掉了 bsdi设置的服务类型信息）。 图 21-1 TCP超时和重传的简单例子 第 1、 2和 3行表示正常的 TCP连接建立的过程，第 4行是“ hello, world”（ 12个字符加上回车和换行）的传输过程，第 5行是其确认。接着我们从 svr4拔掉了以太网电缆， 第 6行表示 and hi”将被发送。第 718行是这个报文段的 12次重传过程，而第 19行则是发送方的 TCP最终放弃并发送一个复位信号的过程。 现在检查连续重传之间不同的时间差，它们取整后分别为 1、 3、 6、 12、 24、48和多个 64秒。在本章的后面，我们将看到当第一次发送后所设置的超时时间实际上为 1.5秒（它在首次发送后的 1.0136秒而不是精确的 1.5秒后，发生的原因我们已在图 18-7中进行了解释），此后该时间在每次重传时增加 1倍并直至 64秒。 这个倍乘关系被称为“指数退避 (exponential backoff)”。可以将该例子与 6.5节中的 TFTP例子比较，在那里每次重传总是在前一次的 5秒后发生。 首次分组传输（第 6行， 24.480秒）与复位信号传输（第 19行， 566.488秒）之间的时间差约为 9分钟，该时间在目前的 TCP实现中是不可变的。 对于大多数实现而言，这个总时间是不可调整的。 Solaris 2.2允许管理者改变这个时间（ E.4节中的 tcp_ip_abort_interval变量），且其默认值为 2分钟，而不是最常用的 9分钟。 21.3 往返时间测量 TCP超时与重传中最重要的部分就是 对一个给定连接的往返时间（ RTT）的测量。由于路由器和网络流量均会变化，因此我们认为这个时间可能经常会发生变化， TCP应该跟踪这些变化并相应地改变其超时时间。 首先 TCP必须测量在发送一个带有特别序号的字节和接收到包含该字节的确认之间的 RTT。在上一章中，我们曾提到在数据报文段和 ACK之间通常并没有一一对应的关系。在图 20.1中，这意味着发送方可以测量到的一个 RTT，是在发送报文段 4（第 11024字节）和接收报文段 7（对 11024字节的 ACK）之间的时间，用 M表示所测量到的 RTT。 最初的 TCP规范使 TCP使用低通过滤器来更新一个被平滑的 RTT估计器（记为O）。 R R+(1- )M 这里的 是一个推荐值为 0.9的平滑因子。每次进行新测量的时候，这个被平滑的 RTT将得到更新。每个新估计的 90来自