rfc1644.txt

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

      client user process.  Segment #2 also carries B's CC value; this
      is used by A to validate non-SYN segments from B, as explained in
      Section 2.4.

      Implementing the T/TCP extensions expands the connection control
      block (TCB) to include the two CC values for the connection; call
      these variables TCB.CCsend and TCB.CCrecv (or CCsend, CCrecv for
      short).  For example, the sequence shown in Figure 1 sets
      TCB.CCsend = x and TCB.CCrecv = y at host A, and vice versa at
      host B.  Any segment that is received with a CC option containing
      a value SEG.CC different from TCB.CCsend will be rejected as an
      antique duplicate.

   2.2  Transaction Sequences

      T/TCP applies the TAO mechanism described in the previous section
      to perform a transaction sequence.  Figure 2 shows a minimal
      transaction, when the request and response data can each fit into
      a single segment.  This requires three segments and completes in
      one round-trip time (RTT).  If the TAO test had failed on segment
      #1, B would have queued data1 and the FIN for later processing,
      and then it would have returned a <SYN,ACK> segment to A, to
      perform a normal 3WHS.




Braden                                                          [Page 6]

RFC 1644                    Transaction/TCP                    July 1994



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

       CLOSED                                                     LISTEN

   #1  SYN-SENT*        --> <SYN,data1,FIN,CC=x> -->         CLOSE-WAIT*
                                                           (TAO test OK)
                                                         (data1->user_B)

                                                           <-- LAST-ACK*
   #2  TIME-WAIT   <-- <SYN,ACK(FIN),data2,FIN,CC=y,CC.ECHO=x>
     (data2->user_A)


   #3  TIME-WAIT          --> <ACK(FIN),CC=x> -->                 CLOSED

       (timeout)
         CLOSED

             Figure 2: Minimal T/TCP Transaction Sequence


      T/TCP extensions require additional connection states, e.g., the
      SYN-SENT*, CLOSE-WAIT*, and LAST-ACK* states shown in Figure 2.
      Section 3.3 describes these new connection states.

      To obtain the minimal 3-segment sequence shown in Figure 2, the
      server host must delay acknowledging segment #1 so the response
      may be piggy-backed on segment #2.  If the application takes
      longer than this delay to compute the response, the normal TCP
      retransmission mechanism in TCP B will send an acknowledgment to
      forestall a retransmission from TCP A.  Figure 3 shows an example
      of a slow server application.  Although the sequence in Figure 3
      does contain a 3-way handshake, the TAO mechanism has allowed the
      request data to be accepted immediately, so that the client still
      sees the minimum latency.














Braden                                                          [Page 7]

RFC 1644                    Transaction/TCP                    July 1994



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

       CLOSED                                                     LISTEN

   #1  SYN-SENT*       --> <SYN,data1,FIN,CC=x> -->          CLOSE-WAIT*
                                                        (TAO test OK =>
                                                          data1->user_B)

                                                               (timeout)
   #2  FIN-WAIT-1  <-- <SYN,ACK(FIN),CC=y,CC.ECHO=x> <--     CLOSE-WAIT*


   #3  FIN-WAIT-1      --> <ACK(SYN),FIN,CC=x> -->            CLOSE-WAIT


   #4  TIME-WAIT   <-- <ACK(FIN),data2,FIN,CC=y> <--            LAST-ACK
       (data2->user_A)

   #5  TIME_WAIT       --> <ACK(FIN),CC=x> -->                    CLOSED

         (timeout)
        CLOSED

                  Figure 3: Acknowledgment Timeout in Server


   2.3  Protocol Correctness

      This section fills in more details of the TAO mechanism and
      provides an informal sketch of why the T/TCP protocol works.

      CC values are 32-bit integers.  The TAO test requires the same
      kind of modular arithmetic that is used to compare two TCP
      sequence numbers.  We assume that the boundary between y < z and z
      < y for two CC values y and z occurs when they differ by 2**31,
      i.e., by half the total CC space.

      The essential requirement for correctness of T/TCP is this:

           CC values must advance at a rate slower than 2**31      [R1]
           counts per 2*MSL

      where MSL denotes the maximum segment lifetime in the Internet.
      The requirement [R1] is easily met with a 32-bit CC.  For example,
      it will allow 10**6 transactions per second with the very liberal
      MSL of 1000 seconds [RFC-1379].  This is well in excess of the



Braden                                                          [Page 8]

RFC 1644                    Transaction/TCP                    July 1994


      transaction rates achievable with current operating systems and
      network latency.

      Assume for the present that successive connections from client A
      to server B contain only monotonically increasing CC values.  That
      is, if x(i) and x(i+1) are CC values carried in two successive
      initial <SYN> segments from the same host, then x(i+1) > x(i).
      Assuming the requirement [R1], the CC space cannot wrap within the
      range of segments that can be outstanding at one time.  Therefore,
      those successive <SYN> segments from a given host that have not
      exceeded their MSL must contain an ordered set of CC values:

             x(1) < x(2) < x(3) ... < x(n),

      where the modular comparisons have been replaced by simple
      arithmetic comparisons. Here x(n) is the most recent acceptable
      <SYN>, which is cached by the server.  If the server host receives
      a <SYN> segment containing a CC option with value y where y >
      x(n), that <SYN> must be newer; an antique duplicate SYN with CC
      value greater than x(n) must have exceeded its MSL and vanished.
      Hence, monotonic CC values and the TAO test prevent erroneous
      replay of antique <SYN>s.

      There are two possible reasons for a client to generate non-
      monotonic CC values: (a) the client may have crashed and
      restarted, causing the generated CC values to jump backwards; or
      (b) the generated CC values may have wrapped around the finite
      space.  Wraparound may occur because CC generation is global to
      all connections.  Suppose that host A sends a transaction to B,
      then sends more than 2**31 transactions to other hosts, and
      finally sends another transaction to B.  From B's viewpoint, CC
      will have jumped backward relative to its cached value.

      In either of these two cases, the server may see the CC value jump
      backwards only after an interval of at least MSL since the last
      <SYN> segment from the same client host.  In case (a), client host
      restart, this is because T/TCP retains TCP's explicit "Quiet Time"
      of an MSL interval [STD-007].  In case (b). wrap around, [R1]
      ensures that a time of at least MSL must have passed before the CC
      space wraps around.  Hence, there is no possibility that a TAO
      test will succeed erroneously due to either cause of non-
      monotonicity; i.e., there is no chance of replays due to TAO.

      However, although CC values jumping backwards will not cause an
      error, it may cause a performance degradation due to unnecessary
      3WHS's.  This results from the generated CC values jumping
      backwards through approximately half their range, so that all
      succeeding TAO tests fail until the generated CC values catch up



Braden                                                          [Page 9]

RFC 1644                    Transaction/TCP                    July 1994


      to the cached value.  To avoid this degradation, a client host
      sends a CC.NEW option instead of a CC option in the case of either
      system restart or CC wraparound.  Receiving CC.NEW forces a 3WHS,
      but when this 3WHS completes successfully the server cache is
      updated to the new CC value.  To detect CC wraparound, the client
      must cache the last CC value it sent to each server.  It therefore
      maintains cache.CCsent[B] for each server B.  If this cached value
      is undefined or if it is larger than the next CC value generated
      at the client, then the client sends a CC.NEW instead of a CC
      option in the next SYN segment.

      This is illustrated in Figure 4, which shows the scenario for the
      first transaction from A to B after the client host A has crashed
      and recovered.  A similar sequence occurs if x is not greater than
      cache.CCsent[B], i.e., if there is a wraparound of the generated
      CC values.  Because segment #1 contains a CC.NEW option, the
      server host invalidates the cache entry and does a 3WHS; however,
      it still sets B's TCB.CCrecv for this connection to x.  TCP B uses
      this CCrecv value to validate the <ACK> segment (#3) that
      completes the 3WHS.  Receipt of this segment updates cache.CC[A],
      since the cache entry was previously undefined.  (If a 3WHS always
      updated the cache, then out-of-order SYN segments could cause the
      cached value to jump backwards, possibly allowing replays).
      Finally, the CC.ECHO option in the <SYN,ACK> segment #2 defines
      A's cache.CCsent entry.

      This algorithm delays updating cache.CCsent[] until the <SYN> has
      been ACK'd.  This allows the undefined cache.CCsent value to used
      as a a "first-time switch" to reliable resynchronization of the
      cached value at the server after a crash or wraparound.

      When we use the term "cache", we imply that the value can be
      discarded at any time without introducing erroneous behavior
      although it may degrade performance.

      (a)  If a server host receives an initial <SYN> from client A but
           has no cached value cache.CC[A], the server simply forces a
           3WHS to validate the <SYN> segment.

      (b)  If a client host has no cached value cache.CCsent[B] when it
           needs to send an initial <SYN> segment, the client simply
           sends a CC.NEW option in the segment.  This forces a 3WHS at
           the server.








Braden                                                         [Page 10]

RFC 1644                    Transaction/TCP                    July 1994


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

          cache.CCsent[B]                                   cache.CC[A]
              V                                                  V

        (Crash and restart)
            [ ?? ]                                            [ x0 ]

        #1         --> <SYN, data1,CC.NEW=x> -->      (invalidate cache;
                                                            queue data1;
                                                        3-way handshake)

            [ ?? ]                                            [ ?? ]
        #2          <-- <SYN, ACK(data1),CC=y,CC.ECHO=x> <--
          (cache.CCsent[B]= x;)

            [ x ]                                             [ ?? ]

        #3                  --> <ACK(SYN),CC=x> -->       data1->user_B;
                                                         cache.CC[A]= x;

            [ x ]                                              [ x ]

                      Figure 4.  Client Host Restarting


      So far, we have considered only correctness of the TAO mechanism
      for bypassing the 3WHS.  We must also protect a connection against
      antique duplicate non-SYN segments.  In standard TCP, such
      protection is one of the functions of the TIME-WAIT state delay.
      (The other function is the TCP full-duplex close semantics, which
      we need to preserve; that is discussed below in Section 2.5).  In
      order to achieve a high rate of transaction processing, it must be
      possible to truncate this TIME-WAIT state delay without exposure
      to antique duplicate segments [RFC-1379].

      For short connections (e.g., transactions), the CC values assigned
      to each direction of the connection can be used to protect against
      antique duplicate non-SYN segments.  Here we define "short" as a
      duration less than MSL.  Suppose that there is a connection that
      uses the CC values TCB.CCsend = x and TCB.CCrecv = y.  By the
      requirement [R1], neither x nor y can be reused for a new
      connection from the same remote host for a time at least 2*MSL.
      If the connection has been in existence for a time less than MSL,
      then its CC values will not be reused for a period that exceeds
      MSL, and therefore all antique duplicates with that CC value must
      vanish before it is reused.  Thus, for "short" connections we can



Braden                                                         [Page 11]

RFC 1644                    Transaction/TCP                    July 1994