rfc1379.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                          R. Braden
Request for Comments: 1379                                           ISI
                                                           November 1992


               Extending TCP for Transactions -- Concepts

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard.  Distribution of this memo is
   unlimited.

Abstract

   This memo discusses extension of TCP to provide transaction-oriented
   service, without altering its virtual-circuit operation.  This
   extension would fill the large gap between connection-oriented TCP
   and datagram-based UDP, allowing TCP to efficiently perform many
   applications for which UDP is currently used.  A separate memo
   contains a detailed functional specification for this proposed
   extension.

   This work was supported in part by the National Science Foundation
   under Grant Number NCR-8922231.

TABLE OF CONTENTS

   1. INTRODUCTION ..................................................  2
   2. TRANSACTIONS USING STANDARD TCP ...............................  3
   3. BYPASSING THE 3-WAY HANDSHAKE .................................  6
      3.1  Concept of TAO ...........................................  6
      3.2  Cache Initialization ..................................... 10
      3.3  Accepting <SYN,ACK> Segments ............................. 11
   4. SHORTENING TIME-WAIT STATE .................................... 13
   5. CHOOSING A MONOTONIC SEQUENCE ................................. 15
      5.1  Cached Timestamps ........................................ 16
      5.2  Current TCP Sequence Numbers ............................. 18
      5.3  64-bit Sequence Numbers .................................. 20
      5.4  Connection Counts ........................................ 20
      5.5  Conclusions .............................................. 21
   6. CONNECTION STATES ............................................. 24
   7. CONCLUSIONS AND ACKNOWLEDGMENTS ............................... 32
   APPENDIX A: TIME-WAIT STATE AND THE 2-PACKET EXCHANGE ............ 34
   REFERENCES ....................................................... 37
   Security Considerations .......................................... 38
   Author's Address ................................................. 38




Braden                                                          [Page 1]

RFC 1379              Transaction TCP -- Concepts          November 1992


1. INTRODUCTION

   The TCP protocol [STD-007] implements a virtual-circuit transport
   service that provides reliable and ordered data delivery over a
   full-duplex connection.  Under the virtual circuit model, the life of
   a connection is divided into three distinct phases: (1) opening the
   connection to create a full-duplex byte stream; (2) transferring data
   in one or both directions over this stream; and (3) closing the
   connection.  Remote login and file transfer are examples of
   applications that are well suited to virtual-circuit service.

   Distributed applications, which are becoming increasingly numerous
   and sophisticated in the Internet, tend to use a transaction-oriented
   rather than a virtual circuit style of communication.  Currently, a
   transaction-oriented Internet application must choose to suffer the
   overhead of opening and closing TCP connections or else build an
   application-specific transport mechanism on top of the connectionless
   transport protocol UDP.  Greater convenience, uniformity, and
   efficiency would result from widely-available kernel implementations
   of a transport protocol supporting a transaction service model [RFC-
   955].

   The transaction service model has the following features:

   *    The fundamental interaction is a request followed by a response.

   *    An explicit open or close phase would impose excessive overhead.

   *    At-most-once semantics is required; that is, a transaction must
        not be "replayed" by a duplicate request packet.

   *    In favorable circumstances, a reliable request/response
        handshake can be performed with exactly one packet in each
        direction.

   *    The minimum transaction latency for a client is RTT + SPT, where
        RTT is the round-trip time and SPT is the server processing
        time.

   We use the term "transaction transport protocol" for a transport-
   layer protocol that follows this model [RFC-955].

   The Internet architecture allows an arbitrary collection of transport
   protocols to be defined on top of the minimal end-to-end datagram
   service provided by IP [Clark88].  In practice, however, production
   systems implement only TCP and UDP at the transport layer.  It has
   proven difficult to leverage a new transport protocol into place, to
   be widely enough available to be useful for application builders.



Braden                                                          [Page 2]

RFC 1379              Transaction TCP -- Concepts          November 1992


   This memo explores an alternative approach to providing a transaction
   transport protocol: extending TCP to implement the transaction
   service model, while continuing to support the virtual circuit model.
   Each transaction will then be a single instance of a TCP connection.
   The proposed transaction extension is effectively implementable
   within current TCPs and operating systems, and it should also scale
   to the much faster networks, interfaces, and CPUs of the future.

   The present memo explains the theory behind the extension, in
   somewhat exquisite detail.  Despite the length and complexity of this
   memo, the TCP extensions required for transactions are in fact quite
   limited and simple.  Another memo [TTCP-FS] provides a self-contained
   functional specification of the extensions.

   Section 2 of this memo describes the limitations of standard TCP for
   transaction processing, to motivate the extensions.  Sections 3, 4,
   and 5 explore the fundamental extensions that are required for
   transactions.  Section 6 discusses the changes required in the TCP
   connection state diagram.  Finally, Section 7 presents conclusions
   and acknowledgments.  Familiarity with the standard TCP protocol
   [STD-007] is assumed.

2.  TRANSACTIONS USING STANDARD TCP

   Reliable transfer of data depends upon sequence numbers.  Before data
   transfer can begin, both parties must "synchronize" the connection,
   i.e, agree on common sequence numbers.  The synchronization procedure
   must preserve at-most-once semantics, i.e., be free from replay
   hazards due to duplicate packets.  The TCP developers adopted a
   synchronization mechanism known as the 3-way handshake.

   Consider a simple transaction in which client host A sends a single-
   segment request to server host B, and B returns a single-segment
   response.  Many current TCP implementations use at least ten segments
   (i.e., packets) for this sequence: three for the 3-way handshake
   opening the connection, four to send and acknowledge the request and
   response data, and three for TCP's full-duplex data-conserving close
   sequence.  These ten segments represent a high relative overhead for
   two data-bearing segments.  However, a more important consideration
   is the transaction latency seen by the client:  2*RTT + SPT, larger
   than the minimum by one RTT.  As CPU and network speeds increase, the
   relative significance of this extra transaction latency also
   increases.

   Proposed transaction transport protocols have typically used a
   "timer-based" approach to connection synchronization [Birrell84].  In
   this approach, once end-to-end connection state is established in the
   client and server hosts, a subset of this state is maintained for



Braden                                                          [Page 3]

RFC 1379              Transaction TCP -- Concepts          November 1992


   some period of time.  A new request before the expiration of this
   timeout period can then reestablish the full state without an
   explicit handshake.  Watson pointed out that the timer-based approach
   of his Delta-T protocol [Watson81] would encompass both virtual
   circuits and transactions.  However, the TCP group adopted the 3-way
   handshake (because of uncertainty about the robustness of enforcing
   the packet lifetime bounds required by Delta-T, within a general
   Internet environment).  More recently, Liskov, Shrira, and Wroclawski
   [Liskov90] have proposed a different timer-based approach to
   connection synchronization, requiring loosely-synchronized clocks in
   the hosts.

   The technique proposed in this memo, suggested by Clark [Clark89],
   depends upon cacheing of connection state but not upon clocks or
   timers; it is described in Section 3 below.  Garlick, Rom, and Postel
   also proposed a connection synchronization mechanism using cached
   state [Garlick77].  Their scheme required each host to maintain
   connection records containing the highest sequence number on each
   connection.  The technique suggested here retains only per-host
   state, not per-connection state.

   During TCP development, it was suggested that TCP could support
   transactions with data segments containing both SYN and FIN bits.
   (These "Kamikaze" segments were not supported as a service; they were
   used mainly to crash other experimental TCPs!)  To illustrate this
   idea, Figure 1 shows a plausible application of the current TCP rules
   to create a minimal transaction.  (In fact, some minor adjustments in
   the standard TCP spec would be required to make Figure 1 fully legal
   [STD-007]).

   Figure 1, like many of the examples shown in this memo, uses an
   abbreviated form to illustrate segment sequences.  For clarity and
   brevity, it omits explicit sequence and acknowledgment numbers,
   assuming that these will follow the well-known TCP rules.  The
   notation "ACK(x)" implies a cumulative acknowledgment for the control
   bit or data "x" and everything preceding "x" in the sequence space.
   The referent of "x" should be clear from the context.  Also, host A
   will always be the client and host B will be the server in these
   diagrams.

   The first three segments in Figure 1 implement the standard TCP
   three-way handshake.  If segment #1 had been an old duplicate, the
   client side would have sent an RST (Reset) bit in segment #3,
   terminating the sequence.  The request data included on the initial
   SYN segment cannot be delivered to user B until segment #3 completes
   the 3-way handshake.  Loading control bits onto the segments has
   reduced the total number of segments to 5, but the client still
   observes a transaction latency of 2*RTT + SPT.  The 3-way handshake



Braden                                                          [Page 4]

RFC 1379              Transaction TCP -- Concepts          November 1992


   thus precludes high-performance transaction processing.


       TCP A  (Client)                                 TCP B (Server)
       _______________                                 ______________

       CLOSED                                               LISTEN

   (Client sends request)
    1. SYN-SENT             --> <SYN,data1,FIN> -->       SYN-RCVD
                                                       (data1 queued)

    2. ESTABLISHED  <-- <SYN,ACK(SYN)> <--                SYN-RCVD


    3. FIN-WAIT-1            --> <ACK(SYN),FIN> -->     CLOSE-WAIT
                                                    (data1 to server)

                                                 (Server sends reply)
    4. TIME-WAIT    <-- <ACK(FIN),data2,FIN> <--          LAST-ACK
    (data2 to client)

    5. TIME-WAIT                 --> <ACK(FIN)> -->         CLOSED

       (timeout)
       CLOSED

               Figure 1: Transaction Sequence: RFC-793 TCP


   The TCP close sequence also poses a performance problem for
   transactions: one or both end(s) of a closed connection must remain
   in "TIME-WAIT" state until a 4 minute timeout has expired [STD-007].
   The same connection (defined by the host and port numbers at both
   ends) cannot be reopened until this delay has expired.  Because of
   TIME-WAIT state, a client program should choose a new local port
   number (i.e., a different connection) for each successive
   transaction.  However, the TCP port field of 16 bits (less the
   "well-known" port space) provides only 64512 available user ports.
   This limits the total rate of transactions between any pair of hosts
   to a maximum of 64512/240 = 268 per second.  This is much too low a
   rate for low-delay paths, e.g., high-speed LANs.  A high rate of
   short connections (i.e., transactions) could also lead to excessive
   consumption of kernel memory by connection control blocks in TIME-
   WAIT state.

   In summary, to perform efficient transaction processing in TCP, we
   need to suppress the 3-way handshake and to shorten TIME-WAIT state.



Braden                                                          [Page 5]

RFC 1379              Transaction TCP -- Concepts          November 1992


   Protocol mechanisms to accomplish these two goals are discussed in
   Sections 3 and 4, respectively.  Both require the choice of a
   monotonic sequence-like space; Section 5 analyzes the choices and
   makes a selection for this space.  Finally, the TCP connection state
   machine must be extended as described in Section 6.

   Transaction processing in TCP raises some other protocol issues,
   which are discussed in the functional specification memo [TTCP-FS].
   These include:

   (1)  augmenting the user interface for transactions,

   (2)  delaying acknowledgment segments to allow maximum piggy-backing
        of control bits with data,

   (3)  measuring the retransmission timeout time (RTO) on very short
        connections, and