⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 rfc1185.txt

📁 著名的RFC文档,其中有一些文档是已经翻译成中文的的.
💻 TXT
📖 第 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 theyJacobson, 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 bytesJacobson, 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 theJacobson, 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 anJacobson, 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: (415) 486-6411   EMail: van@CSAM.LBL.GOV   Bob Braden   University of Southern California   Information Sciences Institute   4676 Admiralty Way   Marina del Rey, CA 90292   Phone: (213) 822-1511   EMail: Braden@ISI.EDUJacobson, 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: (415) 494-4415   EMail: lixia@PARC.XEROX.COMJacobson, Braden & Zhang                                       [Page 21]

⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -