rfc761.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,816 行 · 第 1/5 页
TXT
1,816 行
CLOSE-WAIT - represents waiting for a connection termination request
from the local user.
CLOSING - represents waiting for a connection termination request
acknowledgment from the remote TCP.
CLOSED - represents no connection state at all.
[Page 21]
January 1980
Transmission Control Protocol
Functional Specification
A TCP connection progresses from one state to another in response to
events. The events are the user calls, OPEN, SEND, RECEIVE, CLOSE,
ABORT, and STATUS; the incoming segments, particularly those
containing the SYN and FIN flags; and timeouts.
The Glossary contains a more complete list of terms and their
definitions.
The state diagram in figure 6 only illustrates state changes, together
with the causing events and resulting actions, but addresses neither
error conditions nor actions which are not connected with state
changes. In a later section, more detail is offered with respect to
the reaction of the TCP to events.
[Page 22]
January 1980
Transmission Control Protocol
Functional Specification
+---------+ ---------\ active OPEN
| CLOSED | \ -----------
+---------+<---------\ \ create TCB
| ^ \ \ snd SYN
passive OPEN | | CLOSE \ \
------------ | | ---------- \ \
create TCB | | delete TCB \ \
V | \ \
+---------+ CLOSE | \
| LISTEN | ---------- | |
+---------+ delete TCB | |
rcv SYN | | SEND | |
----------- | | ------- | V
+---------+ snd SYN,ACK / \ snd SYN +---------+
| |<----------------- ------------------>| |
| SYN | rcv SYN | SYN |
| RCVD |<-----------------------------------------------| SENT |
| | snd ACK | |
| |------------------ -------------------| |
+---------+ rcv ACK of SYN \ / rcv SYN,ACK +---------+
| -------------- | | -----------
| x | | snd ACK
| V V
| CLOSE +---------+
| ------- | ESTAB |
| snd FIN +---------+
| CLOSE | | rcv FIN
V ------- | | -------
+---------+ snd FIN / \ snd ACK +---------+
| FIN |<----------------- ------------------>| CLOSE |
| WAIT-1 |------------------ -------------------| WAIT |
+---------+ rcv FIN \ / CLOSE +---------+
| rcv ACK of FIN ------- | | -------
| -------------- snd ACK | | snd FIN
V x V V
+---------+ +---------+
|FINWAIT-2| | CLOSING |
+---------+ +---------+
| rcv FIN | rcv ACK of FIN
| ------- Timeout=2MSL | --------------
V snd ACK ------------ V delete TCB
+---------+ delete TCB +---------+
|TIME WAIT|----------------->| CLOSED |
+---------+ +---------+
TCP Connection State Diagram
Figure 6.
[Page 23]
January 1980
Transmission Control Protocol
Functional Specification
3.3. Sequence Numbers
A fundamental notion in the design is that every octet of data sent
over a TCP connection has a sequence number. Since every octet is
sequenced, each of them can be acknowledged. The acknowledgment
mechanism employed is cumulative so that an acknowledgment of sequence
number X indicates that all octets up to but not including X have been
received. This mechanism allows for straight-forward duplicate
detection in the presence of retransmission. Numbering of octets
within a segment is that the first data octet immediately following
the header is the lowest numbered, and the following octets are
numbered consecutively.
It is essential to remember that the actual sequence number space is
finite, though very large. This space ranges from 0 to 2**32 - 1.
Since the space is finite, all arithmetic dealing with sequence
numbers must be performed modulo 2**32. This unsigned arithmetic
preserves the relationship of sequence numbers as they cycle from
2**32 - 1 to 0 again. There are some subtleties to computer modulo
arithmetic, so great care should be taken in programming the
comparison of such values. The typical kinds of sequence number
comparisons which the TCP must perform include:
(a) Determining that an acknowledgment refers to some sequence
number sent but not yet acknowledged.
(b) Determining that all sequence numbers occupied by a segment
have been acknowledged (e.g., to remove the segment from a
retransmission queue).
(c) Determining that an incoming segment contains sequence numbers
which are expected (i.e., that the segment "overlaps" the
receive window).
[Page 24]
January 1980
Transmission Control Protocol
Functional Specification
On send connections the following comparisons are needed:
older sequence numbers newer sequence numbers
SND.UNA SEG.ACK SND.NXT
| | |
----|----XXXXXXX------XXXXXXXXXX---------XXXXXX----|----
| | | | | |
| | |
Segment 1 Segment 2 Segment 3
<----- sequence space ----->
Sending Sequence Space Information
Figure 7.
SND.UNA = oldest unacknowledged sequence number
SND.NXT = next sequence number to be sent
SEG.ACK = acknowledgment (next sequence number expected by the
acknowledging TCP)
SEG.SEQ = first sequence number of a segment
SEG.SEQ+SEG.LEN-1 = last sequence number of a segment
A new acknowledgment (called an "acceptable ack"), is one for which
the inequality below holds:
SND.UNA < SEG.ACK =< SND.NXT
All arithmetic is modulo 2**32 and that comparisons are unsigned.
"=<" means "less than or equal".
A segment on the retransmission queue is fully acknowledged if the sum
of its sequence number and length is less than the acknowledgment
value in the incoming segment.
SEG.LEN is the number of octets occupied by the data in the segment.
It is important to note that SEG.LEN must be non-zero; segments which
do not occupy any sequence space (e.g., empty acknowledgment segments)
are never placed on the retransmission queue, so would not go through
this particular test.
[Page 25]
January 1980
Transmission Control Protocol
Functional Specification
On receive connections the following comparisons are needed:
older sequence numbers newer sequence numbers
RCV.NXT RCV.NXT+RCV.WND
| |
---------XXX|XXX------XXXXXXXXXX---------XXX|XX---------
| | | | |
| | |
Segment 1 Segment 2 Segment 3
<----- sequence space ----->
Receiving Sequence Space Information
Figure 8.
RCV.NXT = next sequence number expected on incoming segments
RCV.NXT+RCV.WND = last sequence number expected on incoming
segments, plus one
SEG.SEQ = first sequence number occupied by the incoming segment
SEG.SEQ+SEG.LEN-1 = last sequence number occupied by the incoming
segment
A segment is judged to occupy a portion of valid receive sequence
space if
0 =< (SEG.SEQ+SEG.LEN-1 - RCV.NXT) < (RCV.NXT+RCV.WND - RCV.NXT)
SEG.SEQ+SEG.LEN-1 is the last sequence number occupied by the segment;
RCV.NXT is the next sequence number expected on an incoming segment;
and RCV.NXT+RCV.WND is the right edge of the receive window.
Actually, it is a little more complicated than this. Due to zero
windows and zero length segments, we have four cases for the
acceptability of an incoming segment:
[Page 26]
January 1980
Transmission Control Protocol
Functional Specification
Segment Receive Test
Length Window
------- ------- -------------------------------------------
0 0 SEG.SEQ = RCV.NXT
0 >0 RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND
>0 0 not acceptable
>0 >0 RCV.NXT < SEG.SEQ+SEG.LEN =< RCV.NXT+RCV.WND
Note that the acceptance test for a segment, since it requires the end
of a segment to lie in the window, is somewhat more restrictive than
is absolutely necessary. If at least the first sequence number of the
segment lies in the receive window, or if some part of the segment
lies in the receive window, then the segment might be judged
acceptable. Thus, in figure 8, at least segments 1 and 2 are
acceptable by the strict rule, and segment 3 may or may not be,
depending on the strictness of interpretation of the rule.
Note that when the receive window is zero no segments should be
acceptable except ACK segments. Thus, it should be possible for a TCP
to maintain a zero receive window while transmitting data and
receiving ACKs.
We have taken advantage of the numbering scheme to protect certain
control information as well. This is achieved by implicitly including
some control flags in the sequence space so they can be retransmitted
and acknowledged without confusion (i.e., one and only one copy of the
control will be acted upon). Control information is not physically
carried in the segment data space. Consequently, we must adopt rules
for implicitly assigning sequence numbers to control. The SYN and FIN
are the only controls requiring this protection, and these controls
are used only at connection opening and closing. For sequence number
purposes, the SYN is considered to occur before the first actual data
octet of the segment in which it occurs, while the FIN is considered
to occur after the last actual data octet in a segment in which it
occurs. The segment length includes both data and sequence space
occupying controls. When a SYN is present then SEG.SEQ is the
sequence number of the SYN.
Initial Sequence Number Selection
The protocol places no restriction on a particular connection being
used over and o⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?