rfc1185.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,179 行 · 第 1/4 页

   current window.  This is illustrated by Figure 2 for a slow, long-
   lived connection, and by Figures 3 and 4 for fast connections.  In
   each case, the point "x" marks the place at which the original
   connection closes or crashes.  The arrow in Figure 2 illustrates an
   old duplicate segment.  Figure 3 shows a connection whose total byte
   count Nc < 2**32, while Figure 4 concerns Nc >= 2**32.

   To prevent the duplication illustrated in Figure 2, Tomlinson
   proposed to "resynchronize" the connection sequence numbers if they



Jacobson, Braden & Zhang                                       [Page 16]

RFC 1185               TCP over High-Speed Paths            October 1990


   came within an MSL of the ISN.  Resynchronization might take the form
   of a delay (point "y") or the choice of a new sequence number (point
   "z").

        |- 2**32       ISN               ISN
        |              *                 *
        |             *                 *
        |            *                 *
        |           *                 *
        |          *                 *
    ^   |         *                 *
    |   |        *                 *
        |       *                 *
    S   |      *                 *
    e   |     *                x* y
    q   |    *           o     *
        |   *      o          *z
    #   |  *o                *
        | *                 *
        |*_________________*____________
                           ^         Time -->
                          4.55hrs

        Figure 2.  Resynchronization to Avoid Duplication
                   on Slow, Long-Lived Connection



        |- 2**32       ISN               ISN
        |              *                 *
        |       x   o *                 *
        |            *                 *
        |      o-->o*                 *
        |          *                 *
    ^   |     o   o                 *
    |   |        *                 *
        |    o  *                 *
    S   |      *                 *
    e   |   o *                 *
    q   |    *                 *
        |  o*                 *
    #   |  *                 *
        | o                 *
        |*_________________*____________
                           ^         Time -->
                          4.55hrs

     Figure 3.  Duplication on Fast Connection: Nc < 2**32 bytes



Jacobson, Braden & Zhang                                       [Page 17]

RFC 1185               TCP over High-Speed Paths            October 1990


        |- 2**32       ISN               ISN
        |      o       *                 *
        |           x *                 *
        |            *                 *
        |     o     *                 *
        |          o                 *
    ^   |         *                 *
    |   |    o   *                 *
        |       * o               *
    S   |      *                *
    e   |   o *                 *
    q   |    *   o             *
        |   *                 *
    #   |  o                 *
        | *     o           *
        |*_________________*____________
                           ^         Time -->
                          4.55hrs

     Figure 4.  Duplication on Fast Connection: Nc > 2**32 bytes

   In summary, Figures 1-4 illustrated four possible failure modes for
   old duplicate packets from an earlier incarnation.  We will call
   these four modes F1 , F2, F3, and F4:


   F1:  B < R, Tc < 4.55 hrs. (Figure 1)

   F2:  B < R, Tc >= 4.55 hrs. (Figure 2)

   F3:  B >= R, Nc < 2**32 (Figure 3)

   F4:  B >= R, Nc >= 2**32 (Figure 4)


   Another limitation of clock-driven ISN selection should be mentioned.
   Tomlinson assumed that the current time t in formula [2] is obtained
   from a clock that is persistent over a system crash.  For his scheme
   to work correctly, the clock must be restarted with an accuracy of
   1/R seconds (e.g, 4 microseconds in the case of TCP).  While this may
   be possible for some hosts and some crashes, in most cases there will
   be an uncertainty in the clock after a crash that ranges from a
   second to several minutes.

   As a result of this random clock offset after system
   reinitialization, there is a possibility that old segments sent
   before the crash may fall into the window of a new connection
   incarnation.  The solution to this problem that was adopted in the



Jacobson, Braden & Zhang                                       [Page 18]

RFC 1185               TCP over High-Speed Paths            October 1990


   final TCP spec is a "quiet time" of MSL seconds when the system is
   initialized [Postel81, p. 28].  No TCP connection can be opened until
   the expiration of this quiet time.

   A different approach was suggested by Garlick, Rom, and Postel
   [Garlick77].  Rather than using clock-driven ISN selection, they
   proposed to maintain connection records containing the last ISN used
   on every connection.  To immediately open a new incarnation of a
   connection, the ISN is taken to be greater than the last sequence
   number of the previous incarnation, so that the new incarnation will
   have unique sequence numbers.  To handle a system crash, they
   proposed a quiet time, i.e., a delay at system startup time to allow
   old duplicates to expire.  Note that the connection records need be
   kept only for MSL seconds; after that, no collision is possible, and
   a new connection can start with sequence number zero.

   The scheme finally adopted for TCP combines features of both these
   proposals.  TCP uses three mechanisms:

   (A)  ISN selection is clock-driven to handle short-lived connections.
        The parameter R =  250KBps, so that the ISN value cycles in
        2**32/R = 4.55 hours.

   (B)  (One end of) a closed connection is left in a "busy" state,
        known as "TIME-WAIT" state, for a time of 2*MSL.  TIME-WAIT
        state handles the proper close of a long-lived connection
        without resynchronization.  It also allows reliable completion
        of the full-duplex close handshake.

   (C)  There is a quiet time of one MSL at system startup.  This
        handles a crash of a long-lived connection and avoids time
        resynchronization problems in (A).

   Notice that (B) and (C) together are logically sufficient to prevent
   accidental reuse of sequence numbers from a different incarnation,
   for any of the failure modes F1-F4.  (A) is not logically necessary
   since the close delay (B) makes it impossible to reopen the same TCP
   connection immediately.  However, the use of (A) does give additional
   assurance in a common case, perhaps compensating for a host that has
   set its TIME-WAIT state delay too short.

   Some TCP implementations have permitted a connection in the TIME-WAIT
   state to be reopened immediately by the other side, thus short-
   circuiting mechanism (B).  Specifically, a new SYN for the same
   socket pair is accepted when the earlier incarnation is still in
   TIME-WAIT state.  Old duplicates in one direction can be avoided by
   choosing the ISN to be the next unused sequence number from the
   preceding connection (i.e., FIN+1); this is essentially an



Jacobson, Braden & Zhang                                       [Page 19]

RFC 1185               TCP over High-Speed Paths            October 1990


   application of the scheme of Garlick, Rom, and Postel, using the
   connection block in TIME-WAIT state as the connection record.

   However, the connection is still vulnerable to old duplicates in the
   other direction.  Mechanism (A) prevents trouble in mode F1, but
   failures can arise in F2, F3, or F4; of these, F2, on short, fast
   connections, is the most dangerous.

   Finally, we note TCP will operate reliably without any MSL-based
   mechanisms in the following restricted domain:

   *    Total data sent is less then 2**32 octets, and

   *    Effective sustained rate less than 250KBps, and

   *    Connection duration less than 4.55 hours.

   At the present time, the great majority of current TCP usage falls
   into this restricted domain.  The third component, connection
   duration, is the most commonly violated.

Security Considerations

   Security issues are not discussed in this memo.

Authors' Addresses

   Van Jacobson
   University of California
   Lawrence Berkeley Laboratory
   Mail Stop 46A
   Berkeley, CA 94720

   Phone: [phone]
   EMail: [e-mail]


   Bob Braden
   University of Southern California
   Information Sciences Institute
   4676 Admiralty Way
   Marina del Rey, CA 90292

   Phone: [phone]
   EMail: [e-mail]






Jacobson, Braden & Zhang                                       [Page 20]

RFC 1185               TCP over High-Speed Paths            October 1990


   Lixia Zhang
   XEROX Palo Alto Research Center
   3333 Coyote Hill Road
   Palo Alto, CA 94304

   Phone: [phone]
   EMail: [e-mail]












































Jacobson, Braden & Zhang                                       [Page 21]