rfc675.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,653 行 · 第 1/5 页

         defined in section 2.4.3.

         010: Special Functions

         011: Reject (codes as yet undefined)

         1XX: Unused

   8 bits: Control Data Octet

      If CD is 000 then this octet is to be ignored.





Cerf, Dalal & Sunshine                                         [Page 18]

RFC 675              Specification of Internet TCP         December 1974


      If CD is 001, this octet contains event codes defined in section
      2.4.3

      If CD is 010, this octet contains a special function code as
      defined below:

         0: RESET all connections between Source and Destination TCPs

         l: RESET the specific connection referenced in this packet

         2: ECHO return packet to sender with the special function code
         ECHOR (Echo Reply).

         3: QUERY Query status of connection referenced in this packet

         4: STATUS Reply to QUERY with requested status.

         5: ECHOR Echo Reply

         6: TRASH Discard packet without acknowledgment

         >6: Unused

         Note: Special function packets not pertaining to a particular
         connection [RESET all, ECHO, ECHOR, and TRASH] are normally
         sent using socket zero as described in section 3.2.

      If CD is 01l, this octet contains an as yet undefined REJECT code.

      If CD is 1XX, this octet is undefined.

   4 bits: Length of destination network address in 4 bit units (current
   value is 1)

   4 bits: Destination network address

      1010-1111 are addresses of ARPANET, UCL, CYCLADES, NPL, CADC, and
      EPSS respectively.

   16 bits: Destination TCP address

   8 bits: Padding

   4 bits: length of source network address in 4 bit units (current
   value is 1)

   4 bits: source network address (as for destination address)




Cerf, Dalal & Sunshine                                         [Page 19]

RFC 675              Specification of Internet TCP         December 1974


   16 bits: Source TCP address

   24 bits: Destination port address

   24 bits: Source port address

   16 bits: Checksum (if EOS bit is set)

4.2.2  TRANSMISSION CONTROL BLOCK

   It is highly likely that any implementation will include shared data
   structures among parts of the TCP and some asynchronous means of
   signaling users when letters have been delivered.

   One typical data structure is the Transmission Control Block (TCB)
   which is created and maintained during the lifetime of a given
   connection. The TCB contains the following information (field sizes
   are notional only and may vary from one implementation to another):

      16 bits: Local connection name

      48 bits: Local socket

      48 bits: Foreign socket

      16 bits: Receive window size in octets

      32 bits: Receive left window edge (next sequence number expected)

      16 bits: Receive packet buffer size of TCB (may be less than
      window)

      16 bits: Send window size in octets

      32 bits: Send left window edge (earliest unacknowledged octet)

      32 bits: Next packet sequence number

      16 bits: Send packet buffer size of TCB (may be less than window)

      8 bits: Connection state

         E/C - 1 if TCP has been synchronized at least once (i.e. has
         been established, else O, meaning it is closed; this bit is
         reset after FINS are exchanged and the user has done a CLOSE).
         The bit is not reset if the connection is only desynchronized
         on send or receive or both directions.




Cerf, Dalal & Sunshine                                         [Page 20]

RFC 675              Specification of Internet TCP         December 1974


         SS - SYNCed on send side (if set) else desynchronized

         SR - SYNCed on receive side (if set, else desynchronized)

   16 bits: Special flags

      S1 - SYN sent if set

      S2 - SYN verified if set

      R - SYN received if set

      Y - FIN sent if set

      C - CLOSE from local user received if set

      U - Foreign socket unspecified if set

      SDS - Send side DSN sent if set

      SDV - Send side DSN verified if set

      RDR - Receive side DSN received if set

   Initially, all bits are off [no pun intended] (i.e. SS, SR, E/C, S1,
   S2, R, F, C, SDS, SDV, RDR =0). When R is set, so is SR. When S1 and
   S2 are both set, so is SS. SR is reset when RDR is set. SS is reset
   when both SDS and SDV are set. These bits are used to keep track of
   connection state and to aid in arriving packet processing (e.g. Can
   sequence number be validated? Only if SR is set.).

   16 bits: Retransmission timeout (in eighths of a second#]

   16 bits: Head of Send buffer queue [buffers SENT from user to TCP,
   but not packetized]

   16 bits: Tail of Send buffer queue

   16 bits: Pointer to last octet packetized in partially packetized
   buffer (refers to the buffer at the head of the queue)

   16 bits: Head of Send packet queue

   16 bits: Tail of Send packet queue

   16 bits: Head of Packetized buffer Queue

   16 bits: Tail of Packetized buffer queue



Cerf, Dalal & Sunshine                                         [Page 21]

RFC 675              Specification of Internet TCP         December 1974


   16 bits: Head of Retransmit packet queue

   16 bits: Tail of Retransmit packet queue

   16 bits: Head of Receive buffer queue [queue of buffers given by user
   to RECEIVE letters, but unfilled]

   16 bits: Tail of Receive buffer queue

   16 bits: Head of Receive packet queue

   16 bits: Tail of receive packet queue

   16 bits: Pointer to last contiguous receive packet

   16 bits: Pointer to last octet filled in partly filled buffer

   16 bits: Pointer to next octet to read from partly emptied packet

      [Note: The above two pointers refer to the head of the receive
      buffer and receive packet queues respectively]

   16 bits: Forward TCB pointer

   16 bits: Backward TCB pointer

4.3  CONNECTION MANAGEMENT

4.3.1  INITIAL SEQUENCE NUMBER SELECTION

   The protocol places no restriction on a particular connection being
   used over and over again. New instances of a connection will be
   referred to as incarnations of the connection. The problem that
   arises owing to this is, "how does the TCP identify duplicate packets
   from previous incarnations of the connection?". This problem becomes
   harmfully 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.

   The essence of the solution [TOML74] is that the initial sequence
   number [ISN] must be chosen so that a particular sequence number can
   never refer to an "o1d" octet, Once the connection is established the
   sequencing mechanism provided by the TCP filters out duplicates.

   For an association to be established or initialized, the two TCP's
   must synchronize on each other's initial sequence numbers. Hence the
   solution requires a suitable mechanism for picking an initial
   sequence number [ISN], and a slightly involved handshake to exchange



Cerf, Dalal & Sunshine                                         [Page 22]

RFC 675              Specification of Internet TCP         December 1974


   the ISN's. A "three way handshake" is necessary because sequence
   numbers are not tied to a global clock in the network, and TCP's may
   have different mechanisms for picking the ISN's. The receiver of the
   first SYN has no way of knowing whether the packet was an old delayed
   one or not, unless it remembers the last sequence number used on the
   connection which is not always possible, and so it must ask the
   sender to verify this SYN.

   The "three way handshake" and the advantages of a "clock-driven"
   scheme are discussed in [TOML74]. More on the subject, and algorithms
   for implementing the clock-driven scheme can be found in [DALA74].

4.3.2 ESTABLISHING A CONNECTION

   The "three way handshake" is essentially a unidirectional attempt to
   establish the connection, i.e. there is an initiator and a responder.
   The TCP's should however be able to establish the connection even if
   a simultaneous attempt is made by both TCP's to establish the
   connection. Simultaneous attempts are treated like "collisions" in
   "Aloha" systems and these conflicts are resolved into unidirectional
   attempts to establish the connection. This scheme was adopted because

      (i) Connections will normally have a passive and an active end,
      and so the mechanism should in most cases be as simple as
      possible.

      (ii) It is easy to implement as special cases do not have to be
      accounted for.

   The example below indicates what a three way handshake between TCP's
   A and B looks like

         A                                                 B

         --> <SEQ x><SYN>                                  -->

         <-- <SEQ y><SYN, ACK x+l>                         <--

         --> <SEQ x+1><ACK y+l><DATA BYTES>                -->

   The receiver of a "SYN" is able to determine whether the "SYN" was
   real (and not an old duplicate) when a positive "ACK" is returned for
   the receiver's "SYN,ACK" in response to the "SYN". The sender of a
   "SYN" gets verification on receipt of a "SYN,ACK" whose "ACK" part
   references the sequence number proposed in the original "SYN" [pun
   intended]. If the TCP is in the state where it is waiting for a
   response to its SYN, but gets a SYN instead, then it always thinks
   this is a collision and goes into the state prior to having sent the



Cerf, Dalal & Sunshine                                         [Page 23]

RFC 675              Specification of Internet TCP         December 1974


   SYN, i.e. it forgets that it had sent a SYN. The TCP will try to
   establish the connection again after some time, unless it has to
   respond to an arriving SYN. Even if the wait times in the two TCPs
   are the same, the varying delays in network transmission will usually
   be adequate to avoid a collision on the next cycle of attempts to
   send SYN.

   When establishing a connection, the state of the TCP is represented
   by 3 bits --

      S1 S2 R

      S1 = 1 -- SYN sent

      S2 = 1 -- My SYN verified

      R = 1 -- SYN received

   Some examples of attempts to establish the connection are now shown.
   The state of the connection is indicated when a change occurs. We
   specifically do not show the cases in which connection
   synchronization is carried out with packets containing both SYN and
   data. We do this to simplify the explanation, but we do not rule out
   an implementation which is capable of dealing with data arriving in
   the first packet (it has to be stored temporarily without
   acknowledgment or delivery to the user until the arriving SYN has
   been verified).

   The "three way handshake" now looks like --