rfc761.txt
来自「RFC 的详细文档!」· 文本 代码 · 共 1,816 行 · 第 1/5 页
TXT
1,816 行
2.5. Relation to Other Protocols
The following diagram illustrates the place of the TCP in the protocol
hierarchy:
+------+ +-----+ +-----+ +-----+
|Telnet| | FTP | |Voice| ... | | Application Level
+------+ +-----+ +-----+ +-----+
| | | |
+-----+ +-----+ +-----+
| TCP | | RTP | ... | | Host Level
+-----+ +-----+ +-----+
| | |
+-------------------------------+
| Internet Protocol | Gateway Level
+-------------------------------+
|
+---------------------------+
| Local Network Protocol | Network Level
+---------------------------+
|
Protocol Relationships
Figure 2.
[Page 9]
January 1980
Transmission Control Protocol
Philosophy
It is expected that the TCP will be able to support higher level
protocols efficiently. It should be easy to interface higher level
protocols like the ARPANET Telnet [3] or AUTODIN II THP to the TCP.
2.6. Reliable Communication
A stream of data sent on a TCP connection is delivered reliably and in
order at the destination.
Transmission is made reliable via the use of sequence numbers and
acknowledgments. Conceptually, each octet of data is assigned a
sequence number. The sequence number of the first octet of data in a
segment is the sequence number transmitted with that segment and is
called the segment sequence number. Segments also carry an
acknowledgment number which is the sequence number of the next
expected data octet of transmissions in the reverse direction. When
the TCP transmits a segment, it puts a copy on a retransmission queue
and starts a timer; when the acknowledgment for that data is received,
the segment is deleted from the queue. If the acknowledgment is not
received before the timer runs out, the segment is retransmitted.
An acknowledgment by TCP does not guarantee that the data has been
delivered to the end user, but only that the receiving TCP has taken
the responsibility to do so.
To govern the flow of data into a TCP, a flow control mechanism is
employed. The the data receiving TCP reports a window to the sending
TCP. This window specifies the number of octets, starting with the
acknowledgment number that the data receiving TCP is currently
prepared to receive.
2.7. Connection Establishment and Clearing
To identify the separate data streams that a TCP may handle, the TCP
provides a port identifier. Since port identifiers are selected
independently by each operating system, TCP, or user, they might not
be unique. To provide for unique addresses at each TCP, we
concatenate an internet address identifying the TCP with a port
identifier to create a socket which will be unique throughout all
networks connected together.
A connection is fully specified by the pair of sockets at the ends. A
local socket may participate in many connections to different foreign
sockets. A connection can be used to carry data in both directions,
that is, it is "full duplex".
TCPs are free to associate ports with processes however they choose.
However, several basic concepts seem necessary in any implementation.
[Page 10]
January 1980
Transmission Control Protocol
Philosophy
There must be well-known sockets which the TCP associates only with
the "appropriate" processes by some means. We envision that processes
may "own" ports, and that processes can only initiate connections on
the ports they own. (Means for implementing ownership is a local
issue, but we envision a Request Port user command, or a method of
uniquely allocating a group of ports to a given process, e.g., by
associating the high order bits of a port name with a given process.)
A connection is specified in the OPEN call by the local port and
foreign socket arguments. In return, the TCP supplies a (short) local
connection name by which the user refers to the connection in
subsequent calls. There are several things that must be remembered
about a connection. To store this information we imagine that there
is a data structure called a Transmission Control Block (TCB). One
implementation strategy would have the local connection name be a
pointer to the TCB for this connection. The OPEN call also specifies
whether the connection establishment is to be actively pursued, or to
be passively waited for.
A passive OPEN request means that the process wants to accept incoming
connection requests rather than attempting to initiate a connection.
Often the process requesting a passive OPEN will accept a connection
request from any caller. In this case a foreign socket of all zeros
is used to denote an unspecified socket. Unspecified foreign sockets
are allowed only on passive OPENs.
A service process that wished to provide services for unknown other
processes could issue a passive OPEN request with an unspecified
foreign socket. Then a connection could be made with any process that
requested a connection to this local socket. It would help if this
local socket were known to be associated with this service.
Well-known sockets are a convenient mechanism for a priori associating
a socket address with a standard service. For instance, the
"Telnet-Server" process might be permanently assigned to a particular
socket, and other sockets might be reserved for File Transfer, Remote
Job Entry, Text Generator, Echoer, and Sink processes (the last three
being for test purposes). A socket address might be reserved for
access to a "Look-Up" service which would return the specific socket
at which a newly created service would be provided. The concept of a
well-known socket is part of the TCP specification, but the assignment
of sockets to services is outside this specification.
Processes can issue passive OPENs and wait for matching calls from
other processes and be informed by the TCP when connections have been
established. Two processes which issue calls to each other at the
same time are correctly connected. This flexibility is critical for
[Page 11]
January 1980
Transmission Control Protocol
Philosophy
the support of distributed computing in which components act
asynchronously with respect to each other.
There are two cases for matching the sockets in the local request and
an incoming segment. In the first case, the local request has fully
specified the foreign socket. In this case, the match must be exact.
In the second case, the local request has left the foreign socket
unspecified. In this case, any foreign socket is acceptable as long
as the local sockets match.
If there are several pending passive OPENs (recorded in TCBs) with the
same local socket, an incoming segment should be matched to a request
with the specific foreign socket in the segment, if such a request
exists, before selecting a request with an unspecified foreign socket.
The procedures to establish and clear connections utilize synchronize
(SYN) and finis (FIN) control flags and involve an exchange of three
messages. This exchange has been termed a three-way hand shake [4].
A connection is initiated by the rendezvous of an arriving segment
containing a SYN and a waiting TCB entry created by a user OPEN
command. The matching of local and foreign sockets determines when a
connection has been initiated. The connection becomes "established"
when sequence numbers have been synchronized in both directions.
The clearing of a connection also involves the exchange of segments,
in this case carrying the FIN control flag.
2.8. Data Communication
The data that flows on a connection may be thought of as a stream of
octets, or as a sequence of records. In TCP the records are called
letters and are of variable length. The sending user indicates in
each SEND call whether the data in that call completes a letter by the
setting of the end-of-letter parameter.
The length of a letter may be such that it must be broken into
segments before it can be transmitted to its destination. We assume
that the segments will normally be reassembled into a letter before
being passed to the receiving process. A segment may contain all or a
part of a letter, but a segment never contains parts of more than one
letter. The end of a letter is marked by the appearance of an EOL
control flag in a segment. A sending TCP is allowed to collect data
from the sending user and to send that data in segments at its own
convenience, until the end of letter is signaled then it must send all
unsent data. When a receiving TCP has a complete letter, it must not
wait for more data from the sending TCP before passing the letter to
the receiving process.
[Page 12]
January 1980
Transmission Control Protocol
Philosophy
There is a coupling between letters as sent and the use of buffers of
data that cross the TCP/user interface. Each time an end-of-letter
(EOL) flag is associated with data placed into the receiving user's
buffer, the buffer is returned to the user for processing even if the
buffer is not filled. If a letter is longer than the user's buffer,
the letter is passed to the user in buffer size units, the last of
which may be only partly full. The receiving TCP's buffer size may be
communicated to the sending TCP when the connection is being
established.
The TCP is responsible for regulating the flow of segments on the
connections, as a way of preventing itself from becoming saturated or
overloaded with traffic. This is done using a window flow control
mechanism. The data receiving TCP reports to the data sending TCP a
window which is the range of sequence numbers of data octets that data
receiving TCP is currently prepared to accept.
TCP also provides a means to communicate to the receiver of data that
at some point further along in the data stream than the receiver is
currently reading there is urgent data. TCP does not attempt to
define what the user specifically does upon being notified of pending
urgent data, but the general notion is that the receiving process
should take action to read through the end urgent data quickly.
2.9. Precedence and Security
The TCP makes use of the internet protocol type of service field and
security option to provide precedence and security on a per connection
basis to TCP users. Not all TCP modules will necessarily function in
a multilevel secure environment, some may be limited to unclassified
use only, and others may operate at only one security level and
compartment. Consequently, some TCP implementations and services to
users may be limited to a subset of the multilevel secure case.
TCP modules which operate in a multilevel secure environment should
properly mark outgoing segments with the security, compartment, and
precedence. Such TCP modules should also provide to their users or
higher level protocols such as Telnet or THP an interface to allow
them to specify the desired security level, compartment, and
precedence of connections.
2.10. Robustness Principle
TCP implementations should follow a general principle of robustness:
be conservative in what you do, be liberal in what you accept from
others.
[Page 13]
January 1980
Transmission Control Protocol
[Page 14]
January 1980
Transmission Control Protocol
3. FUNCTIONAL SPECIFICATION
3.1. Header Format
TCP segments are sent as internet datagrams. The Internet Protocol
header carries several information fields, including the source and
destination host addresses [2]. A TCP header follows the internet
header, supplying information specific to the TCP protocol. This
division allows for the existence of host level protocols other than
TCP.
TCP Header Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|E|R|S|F| |
| Offset| Reserved |R|C|O|S|Y|I| Window |
| | |G|K|L|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Urgent Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?