rfc1144.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   current and previous values.  However, either positive or negative
   changes are allowed since the window is a 16 bit field.  The packet's
   urgent pointer is sent if URG is set (an uncompressed packet is sent if
   the urgent pointer changes but URG is not set).  For packet ID, the
   number sent is the difference between the current and previous values.
   However, unlike the rest of the compressed fields, the assumed change
   when I is clear is one, not zero.

   There are two important special cases:

   (1) The sequence number and ack both change by the amount of data in the
       last packet; no window change or URG.

   (2) The sequence number changes by the amount of data in the last
       packet, no ack or window change or URG.

   ----------------------------
    12. The bit `P' in the figure is different from the others:  It is a
   copy of the `PUSH' bit from the TCP header.  `PUSH' is a curious
   anachronism considered indispensable by certain members of the Internet
   community.  Since PUSH can (and does) change in any datagram, an
   information preserving compression scheme must pass it explicitly.
    13. All differences are computed using two's complement arithmetic.


   Jacobson                                                        [Page 7]

   RFC 1144               Compressing TCP/IP Headers          February 1990


   (1) is the case for echoed terminal traffic.  (2) is the sender side of
   non-echoed terminal traffic or a unidirectional data transfer.  Certain
   combinations of the S, A, W and U bits of the change mask are used to
   signal these special cases.  `U' (urgent data) is rare so two unlikely
   combinations are S W U (used for case 1) and S A W U (used for case 2).
   To avoid ambiguity, an uncompressed packet is sent if the actual changes
   in a packet are S * W U.

   Since the `active' connection changes rarely (e.g., a user will type for
   several minutes in a telnet window before changing to a different
   window), the C bit allows the connection number to be elided.  If C is
   clear, the connection is assumed to be the same as for the last
   compressed or uncompressed packet.  If C is set, the connection number
   is in the byte immediately following the change mask./14/

   From the above, it's probably obvious that compressed terminal traffic
   usually looks like (in hex):  0B c c d, where the 0B indicates case (1),
   c c is the two byte TCP checksum and d is the character typed.  Commands
   to vi or emacs, or packets in the data transfer direction of an FTP
   `put' or `get' look like 0F c c d ... , and acks for that FTP look like
   04 c c a where a is the amount of data being acked./15/


   3.2.3  Compressor processing

   The compressor is called with the IP packet to be processed and the
   compression state structure for the outgoing serial line.  It returns a
   packet ready for final framing and the link level `type' of that packet.

   As the last section noted, the compressor converts every input packet
   into either a TYPE_IP, UNCOMPRESSED_TCP or COMPRESSED_TCP packet.  A



   ----------------------------
    14. The connection number is limited to one byte, i.e., 256
   simultaneously active TCP connections.  In almost two years of
   operation, the author has never seen a case where more than sixteen
   connection states would be useful (even in one case where the SLIP link
   was used as a gateway behind a very busy, 64-port terminal multiplexor).
   Thus this does not seem to be a significant restriction and allows the
   protocol field in UNCOMPRESSED_TCP packets to be used for the connection
   number, simplifying the processing of those packets.
    15. It's also obvious that the change mask changes infrequently and
   could often be elided.  In fact, one can do slightly better by saving
   the last compressed packet (it can be at most 16 bytes so this isn't
   much additional state) and checking to see if any of it (except the TCP
   checksum) has changed.  If not, send a packet type that means
   `compressed TCP, same as last time' and a packet containing only the
   checksum and data.  But, since the improvement is at most 25%, the added
   complexity and state doesn't seem justified.  See appendix C.


   Jacobson                                                        [Page 8]

   RFC 1144               Compressing TCP/IP Headers          February 1990


   TYPE_IP packet is an unmodified copy/16/ of the input packet and
   processing it doesn't change the compressor's state in any way.

   An UNCOMPRESSED_TCP packet is identical to the input packet except the
   IP protocol field (byte 9) is changed from `6' (protocol TCP) to a
   connection number.  In addition, the state slot associated with the
   connection number is updated with a copy of the input packet's IP and
   TCP headers and the connection number is recorded as the last connection
   sent on this serial line (for the C compression described below).

   A COMPRESSED_TCP packet contains the data, if any, from the original
   packet but the IP and TCP headers are completely replaced with a new,
   compressed header.  The connection state slot and last connection sent
   are updated by the input packet exactly as for an UNCOMPRESSED_TCP
   packet.

   The compressor's decision procedure is:

     - If the packet is not protocol TCP, send it as TYPE_IP.

     - If the packet is an IP fragment (i.e., either the fragment offset
       field is non-zero or the more fragments bit is set), send it as
       TYPE_IP./17/

     - If any of the TCP control bits SYN, FIN or RST are set or if the ACK
       bit is clear, consider the packet uncompressible and send it as
       TYPE_IP./18/

   ----------------------------
    16. It is not necessary (or desirable) to actually duplicate the input
   packet for any of the three output types.  Note that the compressor
   cannot increase the size of a datagram.  As the code in appendix A
   shows, the protocol can be implemented so all header modifications are
   made `in place'.
    17. Only the first fragment contains the TCP header so the fragment
   offset check is necessary.  The first fragment might contain a complete
   TCP header and, thus, could be compressed.  However the check for a
   complete TCP header adds quite a lot of code and, given the arguments in
   [6], it seems reasonable to send all IP fragments uncompressed.
    18. The ACK test is redundant since a standard conforming
   implementation must set ACK in all packets except for the initial SYN
   packet.  However, the test costs nothing and avoids turning a bogus
   packet into a valid one.
   SYN packets are not compressed because only half of them contain a valid
   ACK field and they usually contain a TCP option (the max. segment size)
   which the following packets don't.  Thus the next packet would be sent
   uncompressed because the TCP header length changed and sending the SYN
   as UNCOMPRESSED_TCP instead of TYPE_IP would buy nothing.
   The decision to not compress FIN packets is questionable.  Discounting
   the trick in appendix B.1, there is a free bit in the header that could
   be used to communicate the FIN flag.  However, since connections tend to


   Jacobson                                                        [Page 9]

   RFC 1144               Compressing TCP/IP Headers          February 1990


   If a packet makes it through the above checks, it will be sent as either
   UNCOMPRESSED_TCP or COMPRESSED_TCP:

     - If no connection state can be found that matches the packet's source
       and destination IP addresses and TCP ports, some state is reclaimed
       (which should probably be the least recently used) and an
       UNCOMPRESSED_TCP packet is sent.

     - If a connection state is found, the packet header it contains is
       checked against the current packet to make sure there were no
       unexpected changes.  (E.g., that all the shaded fields in fig. 3 are
       the same).  The IP protocol, fragment offset, more fragments, SYN,
       FIN and RST fields were checked above and the source and destination
       address and ports were checked as part of locating the state.  So
       the remaining fields to check are protocol version, header length,
       type of service, don't fragment, time-to-live, data offset, IP
       options (if any) and TCP options (if any).  If any of these fields
       differ between the two headers, an UNCOMPRESSED_TCP packet is sent.

   If all the `unchanging' fields match, an attempt is made to compress the
   current packet:

     - If the URG flag is set, the urgent data field is encoded (note that
       it may be zero) and the U bit is set in the change mask.
       Unfortunately, if URG is clear, the urgent data field must be
       checked against the previous packet and, if it changes, an
       UNCOMPRESSED_TCP packet is sent.  (`Urgent data' shouldn't change
       when URG is clear but [11] doesn't require this.)

     - The difference between the current and previous packet's window
       field is computed and, if non-zero, is encoded and the W bit is set
       in the change mask.

     - The difference between ack fields is computed.  If the result is
       less than zero or greater than 2^16 - 1, an UNCOMPRESSED_TCP packet
       is sent./19/  Otherwise, if the result is non-zero, it is encoded
       and the A bit is set in the change mask.

     - The difference between sequence number fields is computed.  If the
       result is less than zero or greater than 2^16 - 1, an






   ----------------------------
   last for many packets, it seemed unreasonable to dedicate an entire bit
   to a flag that would only appear once in the lifetime of the connection.
    19. The two tests can be combined into a single test of the most
   significant 16 bits of the difference being non-zero.


   Jacobson                                                       [Page 10]

   RFC 1144               Compressing TCP/IP Headers          February 1990


       UNCOMPRESSED_TCP packet is sent./20/  Otherwise, if the result is
       non-zero, it is encoded and the S bit is set in the change mask.

   Once the U, W, A and S changes have been determined, the special-case
   encodings can be checked:

     - If U, S and W are set, the changes match one of the special-case
       encodings.  Send an UNCOMPRESSED_TCP packet.

     - If only S is set, check if the change equals the amount of user data
       in the last packet.  I.e., subtract the TCP and IP header lengths
       from the last packet's total length field and compare the result to
       the S change.  If they're the same, set the change mask to SAWU (the
       special case for `unidirectional data transfer') and discard the
       encoded sequence number change (the decompressor can reconstruct it
       since it knows the last packet's total length and header length).

     - If only S and A are set, check if they both changed by the same
       amount and that amount is the amount of user data in the last
       packet.  If so, set the change mask to SWU (the special case for
       `echoed interactive' traffic) and discard the encoded changes.

     - If nothing changed, check if this packet has no user data (in which
       case it is probably a duplicate ack or window probe) or if the
       previous packet contained user data (which means this packet is a
       retransmission on a connection with no pipelining).  In either of
       these cases, send an UNCOMPRESSED_TCP packet.

   Finally, the TCP/IP header on the outgoing packet is replaced with a
   compressed header:

     - The change in the packet ID is computed and, if not one,/21/ the
       difference is encoded (note that it may be zero or negative) and the
       I bit is set in the change mask.

     - If the PUSH bit is set in the original datagram, the P bit is set in
       the change mask.

     - The TCP and IP headers of the packet are copied to the connection
       state slot.


   ----------------------------
    20. A negative sequence number change probably indicates a
   retransmission.  Since this may be due to the decompressor having
   dropped a packet, an uncompressed packet is sent to re-sync the
   decompressor (see sec. 4).
    21. Note that the test here is against one, not zero.  The packet ID is
   typically incremented by one for each packet sent so a change of zero is
   very unlikely.  A change of one is likely:  It occurs during any period
   when the originating system has activity on only one connection.


   Jacobson                                                       [Page 11]

   RFC 1144               Compressing TCP/IP Headers          February 1990


     - The TCP and IP headers of the packet are discarded and a new header
       is prepended consisting of (in reverse order):

         - the accumulated, encoded changes.

         - the TCP checksum (if the new header is being constructed `in
           place', the checksum may have been overwritten and will have to
           be taken from the header copy in the connection state or saved
           in a temporary before the original header is discarded).

         - the connection number (if different than the last one sent on
           this serial line).  This also means that the the line's last
           connection sent must be set to the connection number and the C
           bit set in the change mask.