📄 rfc761.txt
字号:
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 1980Transmission Control ProtocolFunctional Specification3.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 1980Transmission Control ProtocolFunctional 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 over again. A connection is defined by a pair of sockets. New instances of a connection will be referred to as incarnations of the connection. The problem that arises owing to this [Page 27] January 1980Transmission Control ProtocolFunctional Specification is -- "how does the TCP identify duplicate segments from previous incarnations of the connection?" This problem becomes apparent if the connection is being opened and closed in quick succession, or if the connection breaks with loss of memory and is then reestablished. To avoid confusion we must prevent segments from one incarnation of a connection from being used while the same sequence numbers may still be present in the network from an earlier incarnation. We want to assure this, even if a TCP crashes and loses all knowledge of the sequence numbers it has been using. When new connections are created, an initial sequence number (ISN) generator is employed which selects a new 32 bit ISN. The generator is bound to a (possibly fictitious) 32 bit clock whose low order bit is incremented roughly every 4 microseconds. Thus, the ISN cycles approximately every 4.55 hours. Since we assume that segments will stay in the network no more than tens of seconds or minutes, at worst, we can reasonably assume that ISN's will be unique. For each connection there is a send sequence number and a receive sequence number. The initial send sequence number (ISS) is chosen by the data sending TCP, and the initial receive sequence number (IRS) is learned during the connection establishing procedure. For a connection to be established or initialized, the two TCPs must ⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -