📄 rfc1185.txt
字号:
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 + -