TCP粘包处理

                                                                    [Docs] [txt|pdf] [Tracker] [Email] [Nits]                               

Versions: 00

INTERNET-DRAFT C. Sapuntzakis
Cisco Systems
<draft-csapuntz-tcpmsgbnd-00.txt> August 2000
Expires February 2001

                  TCP Message Boundary Option

Status of this Memo

 This document is an Internet-Draft and is in full conformance with
 all provisions of Section 10 of RFC2026.

 Internet-Drafts are working documents of the Internet Engineering
 Task Force (IETF), its areas, and its working groups.  Note that
 other groups may also distribute working documents as Internet-
 Drafts.

 Internet-Drafts are draft documents valid for a maximum of six
 months and may be updated, replaced, or obsoleted by other docu¡
 ments at any time.  It is inappropriate to use Internet-Drafts as
 reference material or to cite them other than as "work in
 progress."

 The list of current Internet-Drafts can be accessed at
 http://www.ietf.org/ietf/1id-abstracts.txt

 The list of Internet-Draft Shadow Directories can be accessed at
 http://www.ietf.org/shadow.html.

Copyright Notice

 Copyright (C) Cisco Systems (2000). All Rights Reserved.

Abstract

 TCP does not have a mechanism for specifying message boundaries in
 a stream. This I-D describes a new TCP option and a new way of
 using the TCP urgent field to specify message boundaries in the
 stream.

Sapuntzakis [Page 1]

Internet-Draft TCP Message Boundary option 29 August 2000

Introduction

 TCP does not have a built-in mechanism for signalling message
 boundaries at the TCP layer.

 Most current TCP message encapsulations place the message length at
 the beginning of each message. The message length serves to delin¡
 eate the end of the current message as well as the beginning of the
 next message.

 Unfortunately, when relying solely on this scheme, missing a seg¡
 ment with a message length makes it impossible to find message
 boundaries in subsequent segments. The missing segment must be
 received before later segments can be parsed and processed.

 There are several ways to get around this.


 * Make each message fixed size
 * Put synchronization information in the stream at fixed intervals
 * Use a marker byte to mark message boundaries


 However, none of these techniques seems particularly appetizing.
 Marker bytes work well for hardware but the escape sequences they
 assume make it difficult for software. Putting information at fixed
 intervals in the stream does not prevent the information from being
 split across segments.

 Instead, this document proposes a combination of a TCP option and
 an overloaded usage of the urgent field in the TCP header.

 This option brings TCP more in-line with the principles of applica¡
 tion-layer framing outlined in [ALF].
  1. Message boundary option

1.1. Usage

 This TCP option appears only during negotiation. It is a two byte
 option, with kind <fill in here> and length 2. If both sides indi¡
 cate support for the TCP message boundary option, then the URG bit
 is interpreted as below.

Sapuntzakis [Page 2]

Internet-Draft TCP Message Boundary option 29 August 2000

  1. Redefinition of the URG bit and

    The URG bit and urgent pointer are redefined from RFC 793. An URG
    bit set to one in a segment indicates that the urgent pointer is
    valid.

    The sum of the urgent pointer and sequence number of the TCP seg¡
    ment yields the sequence number of the first byte of an applica¡
    tion-layer message.

  2. Security considerations

    A malicious interceptor could modify the message boundary informa¡
    tion, falsely indicating message boundaries and corrupting the
    stream. However, such an interceptor could probably manipulate the
    stream to corrupt it in other ways.

Sapuntzakis [Page 3]

Internet-Draft TCP Message Boundary option 29 August 2000

  1. Authors’ Addresses

    Constantine Sapuntzakis
    Cisco Systems, Inc.
    170 W. Tasman Drive
    San Jose, CA 95134
    USA

    Phone: +1 408 525 5497
    Email: csapuntz@cisco.com

  2. References

    [ALF] D. D. Clark and D. L. Tennenhouse, “Architectural considera¡
    tions for a new generation of protocols,” in SIGCOMM Symposium on
    Communications Architectures and Protocols , (Philadelphia, Penn¡
    sylvania), pp. 200–208, IEEE, Sept. 1990. Computer Communications
    Review, Vol. 20(4), Sept. 1990.

    [TCP] Postel, J., “Transmission Control Protocol – DARPA Internet
    Program Protocol Specification”, RFC 793, September 1981

    Expires February 2001

Sapuntzakis [Page 4]

Html markup produced by rfcmarkup 1.115, available from https://tools.ietf.org/tools/rfcmarkup/

发表评论

电子邮件地址不会被公开。 必填项已用*标注