rfc1644.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,520 行 · 第 1/5 页
TXT
1,520 行
Figure 1. TAO: Three-Way Handshake is Bypassed
The CC value x is echoed in a CC.ECHO option in the <SYN,ACK>
segment (#2); the client side uses this option to validate the
segment. Since segment #2 is valid, its data2 is delivered to the
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
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?