📄 rfc1379.txt
字号:
Implementation of 64-bit sequence numbers would require
negotiation of a new header format and expansion of all variables
and calculations on the sequence space. CC can be carried in an
option and need be examined only once per packet.
We propose to use a simple 32-bit connection count CC, without
augmentation with timestamps, for the transaction extension. This
choice has the advantages of simplicity and directness. Its
drawback is that it adds a third sequence-like space (in addition
to the TCP sequence number and the TCP timestamp) to each TCP
header and to the main line of packet processing. However, the
additional code is in fact very modest.
We now have a general outline of the proposed TCP extensions for
transactions.
o A host maintains a 32-bit global connection counter variable CC.
o The sender's current CC value is carried in an option in every
TCP segment.
o CC values are cached per host, and the TAO mechanism is used to
bypass the 3-way handshake when possible.
o In non-SYN segments, the CC value is used to reject duplicates
from earlier incarnations. This allows TIME-WAIT state delay to
be reduced to K*RTO (i.e., U=0 in Eq. [2]).
Braden [Page 22]
RFC 1379 Transaction TCP -- Concepts November 1992
TABLE I: Summary of Monotonic Sequences
APPROACH TRmax (Tps) Required MSL COMMENTS
__________________________________________________________________
1. Timestamp & PAWS 1 24 days TRmax is
too small
__________________________________________________________________
2. Current TCP Sequence Numbers
(a) clock-driven
ISN: eq. [3] 268 240 secs TRmax & MSL
too small
(b) Timestamps& clock-
driven ISN [3] & 10**9 24 days Hard to
R=10**9 implement
(c) Timestamps & c-dr
ISN: eq. [4] 2**30/(R*Ts) 24 days TRmax too
small.
__________________________________________________________________
3. 64-bit TCP Sequence Numbers
2**63/(MSL*R*Ts) MSL Significant
TCP change
e.g., R=10**9 Bps,
MSL = 4.4 hrs,
Ts = 0.5 sec=>
TRmax = 10**6
__________________________________________________________________
4. Connection Counts
(a) no timestamps 2**31/MSL MSL 3rd sequence
e.g., MSL=2000 sec space
TRmax = 10**6
(b) with timestamps 2**30 24 days (ditto)
and PAWS
__________________________________________________________________
Braden [Page 23]
RFC 1379 Transaction TCP -- Concepts November 1992
6. CONNECTION STATES
TCP has always allowed a connection to be half-closed. TAO makes a
significant addition to TCP semantics by allowing a connection to be
half-synchronized, i.e., to be open for data transfer in one
direction before the other direction has been opened. Thus, the
passive end of a connection (which receives an initial SYN) can
accept data and even a FIN bit before its own SYN has been
acknowledged. This SYN, data, and FIN may arrive on a single segment
(as in Figure 4), or on multiple segments; packetization makes no
difference to the logic of the finite-state machine (FSM) defining
transitions among connection states.
Half-synchronized connections have several consequences.
(a) The passive end must provide an implied initial data window in
order to accept data. The minimum size of this implied window
is a parameter in the specification; we suggest 4K bytes.
(b) New connection states and transitions are introduced into the
TCP FSM at both ends of the connection. At the active end, new
states are required to piggy-back the FIN on the initial SYN
segment. At the passive end, new states are required for a
half-synchronized connection.
This section develops the resulting FSM description of a TCP
connection as a conventional state/transition diagram. To develop a
complete FSM, we take a constructive approach, as follows: (1) write
down all possible events; (2) write down the precedence rules that
govern the order in which events may occur; (3) construct the
resulting FSM; and (4) augment it to support TAO. In principle, we
do this separately for the active and passive ends; however, the
symmetry of TCP results in the two FSMs being almost entirely
coincident.
Figure 8 lists all possible state transitions for a TCP connection in
the absence of TAO, as elementary events and corresponding actions.
Each transition is labeled with a letter. Transitions a-g are used
by the active side, and c-i are used by the passive side. Without
TAO, transition "c" (event "rcv ACK(SYN)") synchronizes the
connection, allowing data to be accepted for the user.
By definition, the first transition for an active (or passive) side
must be "a" (or "i", respectively). During a single instance of a
connection, the active side will progress through some permutation of
the complete sequence of transitions {a b c d e f } or the sequence
{a b c d e f g}. The set of possible permutations is determined by
precedence rules governing the order in which transitions can occur.
Braden [Page 24]
RFC 1379 Transaction TCP -- Concepts November 1992
Label Event / Action
_____ ________________________
a OPEN / snd SYN
b rcv SYN [No TAO]/ snd ACK(SYN)
c rcv ACK(SYN) /
d CLOSE / snd FIN
e rcv FIN / snd ACK(FIN)
f rcv ACK(FIN) /
g timeout=2MSL / delete TCB
___________________________________________________
h passive OPEN / create TCB
i rcv SYN [No TAO]/ snd SYN, ACK(SYN)
___________________________________________________
Figure 8. Basic TCP Connection Transitions
Using the notation "<." to mean "must precede", the precedence rules
are:
(1) Logical ordering: must open connection before closing it:
b <. e
(2) Causality -- cannot receive ACK(x) before x has been sent:
a <. c and i <. c and d <. f
(3) Acknowledgments are cumulative
c <. f
(4) First packet in each direction must contain a SYN.
b <. c and b <. f
(5) TIME-WAIT state
Whenever d precedes e in the sequence, g must be the last
transition.
Braden [Page 25]
RFC 1379 Transaction TCP -- Concepts November 1992
Applying these rules, we can enumerate all possible permutations of
the events and summarize them in a state transition diagram. Figure
9 shows the result, with boxes representing the states and directed
arcs representing the transitions.
________ ________
| | h | |
| CLOSED |--------->| LISTEN |
|________| |________|
| |
| a | i
____V____ ____V___ ________
| | b | | e | |
| |--------->| |-------------->| |
|________| |________| |________|
/ / | / |
/ / | c d / | c
/ / __V_____ | ____V___
/ / | | e | | |
d | d / | |------------>| |
| | |________| | |________|
| | | | |
| | | ___V____ |
| | | | | |
| | | | | |
| | | |________| |
| | | | |
____V___ ______V_ | ________ | |
| | b | | e | | | | |
| |------->| |--------->| | | |
|________| |________| | |________| | |
| / | | |
c | / d c | c | d |
| / | | |
_V___V__ ____V___ V_____V_
| | e | | | |
| |---->| | | |
|________| |________| |________|
| | |
| f | f | f
____V___ ____V___ ___V____
| | e | TIME- | g | |
| |---->| WAIT |-->| CLOSED |
|________| |________| |________|
Figure 9: Basic State Diagram
Braden [Page 26]
RFC 1379 Transaction TCP -- Concepts November 1992
Although Figure 9 gives a correct representation of the possible
event sequences, it is not quite correct for the actions, which do
not compose as shown. In particular, once a control bit X has been
sent, it must continue to be sent until ACK(X) is received. This
requires new transitions with modified actions, shown in the
following list. We use the labeling convention that transitions with
the same event part all have the same letter, with different numbers
of primes to indicate different actions.
Label Event / Action
_____ _______________________________________
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -