CN102255972B

CN102255972B - 6LoWPAN网络中面向HTTP协议的TCP首部压缩方法

Info

Publication number: CN102255972B
Application number: CN201110228460.6A
Authority: CN
Inventors: 黄小红; 马严; 王振华; 马哲
Original assignee: Beijing University of Posts and Telecommunications
Current assignee: Beijing University of Posts and Telecommunications
Priority date: 2011-08-10
Filing date: 2011-08-10
Publication date: 2014-06-25
Anticipated expiration: 2031-08-10
Also published as: CN102255972A

Abstract

一种用于6LoWPAN网络中面向HTTP的TCP首部压缩方法，是该网络中所有基于HTTP的通信过程都要执行TCP首部的压缩和解压操作，以节省负载空间，用于传输应用层数据，减少数据链路层分片并提高通信效率。操作步骤是：发送端的应用层、传输层和网络层各自完成相应操作，将形成的IP数据报交给适配层；适配层先完成IP首部与IP扩展首部的压缩，然后按照报头压缩结构：Encoding(编码)和In-Line(队列)的方式对TCP首部进行压缩操作，以保证该压缩方法的兼容性和操作实现的简便性；再将形成的6LoWPAN数据报交给数据链路层，经由数据链路层和物理层将数据链路帧通过网络发送给接收端。接收端按照上述过程的逆处理对接收的数据报进行解压后，其应用层接收到发送端传送的HTTP协议的数据。

Description

6LoWPAN网络中面向HTTP协议的TCP首部压缩方法

技术领域

本发明涉及一种用于6LoWPAN网络中面向超文本传输协议HTTP（HyperText Transport Protocol）的传输控制协议TCP（Transmission Control Protocol）首部压缩方法，属于物联网技术，特别是无线传感器网络的技术领域。

背景技术

作为信息技术产业的一个新的发展方向，无线传感器网络WSN（Wirelesssensor network）在军事和民用领域都有着广泛的应用前景。近些年，WSN的一个分支，即无线个人低功耗局域网LoWAPN（low-power wireless personal areanetwork）更是受到了广泛关注，逐渐成为行业内的热点。

2004年11月，因特网工程任务组IETF成立了基于IPv6的无线个人低功耗局域网6LoWAPN（IPv6over low-power wireless personal area network）工作组，旨在将网际通信协议第6版IPv6（IP Version6）引入到LoWAPN中，使得无线局域网中的每个节点都具有一个全球的IPv6地址，以便能与互联网中的每个IPv6节点进行通信。

6LoWAPN遵循IEEE802.15.4的行业标准，具有能耗低、带宽窄、传输单元小等特点，其最主要的改进是在传统TCP/IP协议栈中的网络层和链路层之间增设一个适配层，用来完成数据包的压缩、解压、路由等功能。因为IPv6的网络层中最大传输单元MTU（Maximum Transmission Unit）是1280字节，而IEEE802.15.4标准规定的链路层上最大帧负载是102字节，如果再减去安全机制所消耗的21个字节，就只剩下81个字节用于链路层以上的负载（IPv6首部是40字节，TCP/UDP首部是20/8字节），这样，就会在传输过程中不可避免地产生大量的数据包分片，因此，必须在适配层上对网络层和传输层的首部进行压缩，以节省负载空间，用于传输应用层的数据，进而减少数据包分片。

目前，6LoWPAN工作组已经提出了两种报头压缩方法，并分别命名为LoWPAN_IPHC编码和LoWPAN_NHC编码，前者用于IPv6首部的压缩，后者用于IPv6扩展首部和UDP首部的压缩。其主要思想是：首先对IPv6首部进行逐个字段的编码，并直接省略一些众所周知的字段，如版本号等；然后再将每个字段中不能压缩的部分紧跟着置于压缩编码的后面，命名为In-Line（队列）。故整个6LoWPAN压缩结构如图1所示。

参见图2，介绍LoWPAN_IPHC编码的结构：前3位是设定数值011，后面依次表示为：IPv6首部中的流量级别和流标签TF（Traffic Class and Flow Label），下一个首部NH（Next Header），跳数限制HLIM（Hop Limits），以及源地址和目的地址的相关字段。举个例子，如果由IPv6首部中的流量级别是非0值，流标签是0值，则先对这两个字段进行编码，即TF=10，此后将不能压缩的部分（流量级别）保留在In-Line中，具体的压缩规则在draft-ietf-6lowpan-hc-15中有详细介绍，这里就不再赘述。

在进行地址压缩时，又分为有状态压缩和无状态压缩。二者区别是前者使用了一种名为Context（关联）表的数据结构，该表用于存储一段时间内网络中所使用过的IPv6地址前缀，其存储于网络中的每个节点，并通过相应的数据包交互进行更新。这样在进行地址压缩时，IPv6的地址前缀（通常为64字节）就可以只用几个比特来表示，从而大大提高了压缩效率。当然，这种压缩方式也会带来额外一个字节的开销。

参见图3和图4，分别介绍LoWPAN_NHC编码用于IPv6扩展首部和用户数据报协议UDP（User Datagram Protocol）首部压缩时的编码结构：它是通过一个变长的值域（这里命名为NHC ID）来区分这两种不同编码。在IPv6扩展首部编码中，位于NHC ID（1110）后面的是扩展首部标识EID（Extension HeaderID），表示被压缩的IPv6扩展首部的类型，其后的NH字段则表示下一个首部。在UDP首部编码中，位于NHC ID（11110）后面的分别是单个比特的校验和C（Checksum）和两个比特的端口号P（Ports），如果上层应用对数据包已进行过验证，则可以省略其中的校验和字段。

对于6LoWPAN上层应用来说，很多应用层协议是基于TCP的（比如HTTP，Telnet等）。考虑到TCP首部有20个字节，对于只有102个字节的链路层MTU来讲，仍然十分庞大。所以有必要对TCP首部进行压缩来进一步减少数据包分片。

然而，直至今天，6LoWPAN工作组还没有提出关于TCP首部压缩的方法（只有一份个人提出的通用的TCP首部压缩草案）。由于TCP之上的应用层协议的多样性，设计通用的TCP首部压缩方法或结构都是相当复杂的工作，而且很难获得较高的压缩效率；此外，当前越来越多的上层应用倾向于网页的方式，所以，如何设计一种基于HTTP的TCP首部压缩方法就成为业内科技人员关注的一个焦点任务。

发明内容

有鉴于此，本发明的目的是提供一种用于6LoWPAN网络中面向HTTP协议的TCP首部压缩方法，以便能够节省负载空间而用于传输应用层的数据，进而减少数据分片，显著提高通信效率。

为了达到上述目的，本发明提供了一种用于6LoWPAN网络中面向超文本传输协议HTTP（Hyper Text Transport Protocol）的传输控制协议TCP（Transmission Control Protocol）首部压缩方法，其特征在于：6LoWPAN网络中的所有基于HTTP的通信过程都要执行TCP首部的压缩和解压操作，以减少数据链路层的数据分片和提高通信效率；所述方法包括下列操作步骤：

（1）发送端的应用层将需要传送的HTTP协议的数据交给传输层；

（2）传输层对应用层数据封装TCP首部后，形成TCP报文交给网络层；

（3）网络层对TCP报文封装IP首部后，形成IP数据报交给6LoWPAN适配层；

（4）6LoWPAN适配层先完成IP数据报中的IP首部与其扩展首部的压缩，然后按照6LoWPAN工作组提出的报头压缩结构：Encoding（编码）和In-Line（队列）两个字段结构对TCP首部进行压缩操作，以保证该压缩方法的兼容性和操作实现的简便性；再将形成的6LoWPAN数据报交给数据链路层；其中，TCP首部的压缩操作包括两部分：基本首部的7个字段压缩操作和扩展选项的3个字段压缩操作；且所涉及的基本首部和扩展选项的两种字段压缩操作都是根据网络层传送来的不同类型的IP数据报而分别选择执行其中的若干项字段或全部字段执行压缩操作，并对每个字段的压缩顺序没有特殊要求；

所述TCP中基本首部是顺序包括端口号（Ports）、序列号和确认号（Sequenceand Acknowledgment Number）、首部长度（Header Length）、标志位（Flags）、窗口值（Window）、紧急指针（Urgent Pointer）和校验和（Checksum）共7个字段的TCP报文前20个字节，TCP基本首部的压缩操作是对LoWPAN_NHC编码方法的扩展，即将该20个字节压缩为前3个比特为标志位F、接着2个比特为端口号P，最后3个比特为首部长度HL的单字节TCP基本首部的压缩编码；包括下列操作内容：

（41）对标志位F（Flags）进行压缩：因在HTTP中不会用到紧急指针位（URG），且在TCP传输过程中有些情况不会出现，故只对包括应答位（ACK）、推送位（PSH）、重置位（RST）、同步位（SYN）和结束位（FIN）共5个标志位可能出现的各种不同情况进行下述编码:

000:表示ACK=0,PSH=0,RST=0,SYN=1,FIN=0;

001:表示ACK=1,PSH=0,RST=0,SYN=1,FIN=0;

010:表示ACK=1,PSH=0,RST=0,SYN=0,FIN=1;

011:表示ACK=1,PSH=0,RST=0,SYN=0,FIN=0;

100:表示ACK=1,PSH=1,RST=0,SYN=0,FIN=0;

101:表示ACK=0,PSH=0,RST=1,SYN=0,FIN=0；

110和111:均为保留标志位；

（42）对端口号P（Ports）进行压缩：因每一次完整的TCP传输过程中，源端口号和目的端口号都不会改变，故在TCP首次握手时，就将源端口号分别储存于HTTP客户端和服务器，但当服务器端口不是80时，则还要存储目的端口；并在后续的传输过程中，采用下述三种状态：01、10和11分别表示端口号，直到本次TCP连接断开；其中，

00：表示TCP连接的第一次握手，如果目的端口号是服务器端口80，则只存储源端口号于In-Line部分；否则，将源端口和目的端口都存储于In-Line部分；

01：源端口号是表示HTTP服务器的80，目的端口号是HTTP客户端；

10：目的端口号是表示HTTP服务器的80，源端口号是HTTP客户端；

11：HTTP服务器端口号不是80的情况；

（43）对首部长度HL（Header Length）进行压缩：因不含选项字段的TCP首部长度是20字节，意味着首部长度值不会出现在0000到0100之间；含有一个或多个选项字段的TCP首部在HTTP协议通信中最长为40字节，即不会使用1011到1111；故对下述可能出现的首部长度值进行编码如下：

000：首部长度为5，表示不含选项字段的TCP首部长度是20字节；

001：首部长度为6，表示包含选项字段的TCP首部长度是24字节；

010：首部长度为7，表示包含选项字段的TCP首部长度是28字节；

011：首部长度为8，表示包含选项字段的TCP首部长度是32字节；

100：首部长度为9，表示包含选项字段的TCP首部长度是36字节；

101：首部长度为10，表示包含选项字段的TCP首部长度是HTTP中最长的40字节；

110和111：均为保留用途；

（44）对序列号和确认号（Sequence and Acknowledgment Number）进行压缩：因TCP连接第一次握手时，数据包不会携带确认号，故直接省略该字段；若不是第一次握手时，则将序列号和确认号均保留于In-Line部分；

（45）对窗口值（Window）进行压缩：将其保留于In-Line部分；

（46）对紧急指针（Urgent Pointer）进行压缩：因其与紧急指针位（URG）一起使用，而HTTP不会使用该字段，故直接省略；

（47）对校验和（Checksum）进行压缩：因HTTP不进行校验，故将其保留于In-Line部分；

（5）数据链路层对6LoWPAN数据报封装帧头和帧尾后，形成数据链路帧交给物理层；

（6）物理层将数据链路帧通过网络发送给接收端；

（7）接收端按照上述过程的逆处理对接收的数据报进行解压，接收端的应用层接收到发送端传送的HTTP协议的数据。

下面介绍本发明方法的优点和效果：

（1）TCP基本首部的压缩分析：因TCP基本首部的压缩操作是将原来的20个字节压缩为1字节的压缩编码，若是TCP连接的第一次握手时，In-Line部分依次为2字节的源端口、4字节的序列号、2字节的窗口值和2字节的校验和，故TCP基本首部的压缩率为：

若不是TCP连接第一次握手时，In-Line部分依次为4字节的序列号、4字节的确认号、2字节的窗口值和2字节的校验和，此时TCP基本首部的压缩率为：

（2）TCP扩展选项的压缩分析：使用一个字节的扩展选项压缩编码（LoWPAN_TCP_OP）对TCP扩展选项中的选项类型（Kind）、选项长度（Length）和选项内容（Value）3个字段进行压缩编码，然而，TCP报文中的选项类型与数量等字段的长度是不确定的，因此在计算压缩率时需要满足以下两个假设：

①在所有TCP报文中，携带扩展选项数量的概率m是相同的；

②每个扩展选项类型出现的概率n也是相同的，故TCP扩展选项的压缩率计算公式为：

式中，CE⁰(X)表示单个字段的压缩率。

总之，本发明方法能够节省TCP报文的首部负载空间，用于传输应用层的数据，进而减少数据分片，显著提高通信效率。

附图说明

图1是6LoWPAN报头压缩整体结构组成示意图。

图2是LoWPAN_IPHC编码组成示意图。

图3是IPv6扩展首部压缩编码组成示意图。

图4是UDP首部压缩编码组成示意图。

图5是本发明TCP首部压缩方法中的数据包压缩与解压过程流程图。

图6是TCP协议规定的首部结构组成示意图。

图7是采用本发明压缩方法的TCP基本首部的1字节压缩编码结构示意图。

图8是采用本发明压缩方法的TCP扩展选项的1字节压缩编码LoWPAN_TCP_OP结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面结合附图对本发明作进一步的详细描述。

参见图4，介绍本发明用于6LoWPAN网络中面向HTTP的TCP首部压缩方法，该方法规定6LoWPAN网络中的所有基于HTTP的通信过程都要执行TCP首部的压缩和解压操作，以减少数据链路层的数据分片和提高通信效率；该方法包括下列操作步骤：

步骤1，发送端的应用层将需要传送的HTTP协议的数据交给传输层。

步骤2，传输层对应用层数据封装TCP首部后，形成TCP报文交给网络层。

步骤3，网络层对TCP报文封装IP首部后，形成IP数据报交给6LoWPAN适配层。

步骤4，6LoWPAN适配层先完成IP数据报中的IP首部与其扩展首部的压缩，然后按照6LoWPAN工作组提出的报头压缩结构：Encoding（编码）和In-Line（队列）两个字段结构对TCP首部进行压缩操作，以保证该压缩方法的兼容性和操作实现的简便性；再将形成的6LoWPAN数据报交给数据链路层。

步骤5，数据链路层对6LoWPAN数据报封装帧头和帧尾后，形成数据链路帧交给物理层。

步骤6，物理层将数据链路帧通过网络发送给接收端。

步骤7，接收端按照上述过程的逆处理对接收的数据报进行解压，接收端的应用层接收到发送端传送的HTTP协议的数据。

因此，TCP首部压缩是上述过程的第4步骤中，在IP首部与IP扩展首部（如果存在）压缩后进行的。为了压缩方法的兼容性和操作的简易性，本发明沿用了6LoWPAN工作组提出的压缩编码结构（参见图1），即Encoding（编码）字段+In-Line（队列）字段的结构。由于现在的整个TCP首部结构如图6所示，分为基本首部和扩展选项两部分，因此，步骤4中的TCP首部的压缩操作也包括两部分：基本首部的7个字段压缩操作和扩展选项的3个字段压缩操作。而且，所涉及的基本首部和扩展选项的两种字段压缩操作都是根据网络层传送来的不同类型的IP数据报而分别选择执行其中的若干项字段或全部字段执行压缩操作，并对每个字段的压缩顺序没有特殊要求。下面分别介绍这两部分的压缩操作内容：

A、TCP基本首部压缩方法：TCP基本首部是TCP报文的前20个字节，顺序包括端口号（Ports）、序列号和确认号（Sequence and Acknowledgment Number）、首部长度（Header Length）、标志位（Flags），窗口值（Window），紧急指针（UrgentPointer）和校验和（Checksum）共7个字段。TCP基本首部的压缩操作可以看作是对LoWPAN_NHC编码方法的扩展，即将该20个字节压缩为前3个比特为标志位F、接着2个比特为端口号P，最后3个比特为首部长度HL的单字节TCP基本首部的压缩编码（参见图7所示）。包括下列具体操作内容：

（A1）对标志位F（Flags）进行压缩：因在HTTP中不会用到紧急指针位（URG），且在TCP传输过程中有些情况不会出现，比如ACK=1,PSH=1,RET=1,SYN=1,FIN=1等。所以只对包括应答位（ACK）、推送位（PSH）、重置位（RST）、同步位（SYN）和结束位（FIN）共5个标志位可能出现的各种不同情况进行下述编码:

000:表示ACK=0,PSH=0,RST=0,SYN=1,FIN=0。

001:表示ACK=1,PSH=0,RST=0,SYN=1,FIN=0。

010:表示ACK=1,PSH=0,RST=0,SYN=0,FIN=1。

011:表示ACK=1,PSH=0,RST=0,SYN=0,FIN=0。

100:表示ACK=1,PSH=1,RST=0,SYN=0,FIN=0。

101:表示ACK=0,PSH=0,RST=1,SYN=0,FIN=0。

110和111:均为保留标志位。

（A2）对端口号P（Ports）进行压缩：因每一次完整的TCP传输过程中，源端口号和目的端口号都不会改变，故在TCP第一次握手时，就将源端口号分别储存于HTTP客户端和服务器两端（HTTP的端口号是80，且不会改变）。但当服务器端口不是80时，则还要存储目的端口；并在后续的传输过程中，采用下述三种状态：01、10和11分别表示端口号，直到本次TCP连接断开。其中，

00：表示TCP连接的第一次握手，如果目的端口号是服务器端口80，则只存储源端口号于In-Line部分；否则，将源端口和目的端口都存储于In-Line部分。

01：源端口号是表示HTTP服务器的80，目的端口号是HTTP客户端。

10：目的端口号是表示HTTP服务器的80，源端口号是HTTP客户端。

11：HTTP服务器端口号不是80的情况。

（A3）对首部长度HL（Header Length）进行压缩：因不含选项字段的TCP首部长度是20字节，意味着首部长度值不会出现在0000到0100之间；含有一个或多个选项字段的TCP首部在HTTP协议通信中最长为40字节，即不会使用1011到1111。故对下述可能出现的首部长度值进行编码如下：

000：首部长度为5，表示不含选项字段的TCP首部长度是20字节。

001：首部长度为6。

010：首部长度为7。

011：首部长度为8。

100：首部长度为9。

101：首部长度为10，表示包含选项字段的TCP首部长度是HTTP中最长的40字节。

110和111：均为保留用途。

（A4）对序列号和确认号（Sequence and Acknowledgment Number）进行压缩：因TCP连接第一次握手时，数据包不会携带确认号，故直接省略该字段；若不是第一次握手时，则将序列号和确认号均保留于In-Line部分。

（A5）对窗口值（Window）进行压缩：将其保留于In-Line部分。

（A6）对紧急指针（Urgent Pointer）进行压缩：因其与URG位一起使用，而HTTP不会使用该字段，故直接省略该字段.。

（A7）对校验和（Checksum）进行压缩：因HTTP不进行校验，故将其保留于In-Line部分。

本发明的单字节TCP基本首部的压缩编码与前述介绍的LoWPAN_NHC编码的不同之处是没有设置NHC ID字段，原因是本发明的该压缩编码恰好为一个字节长度，如果要设置NHC ID字段，就要额外再增加一个字节；再者，数据包不会同时包含TCP和UDP首部，故压缩时通过IPv6首部的Next Header字段就能区分之。

B、TCP扩展选项压缩方法：TCP扩展选项包括：选项类型（Kind），选项总长度（Length）和选项内容（Value）共3个字段，它的压缩操作是将其压缩为前3个比特设置为固定值000，接着2个比特分别为下一个选项NO和压缩标志位C，最后3个比特为TCP选项类型标识OID的单字节TCP扩展选项压缩编码，即本发明提出的一种全新的用于TCP扩展选项的压缩编码（LoWPAN_TCP_OP），其编码格式如图8所示。包括下列操作内容：

（B1）下一个选项NO（Next Option）：

0：表示该选项是整个首部中最后一个选项字段；

1：表示该选项后面还有其他选项字段。

（B2）压缩标志C（Compressed）：

0：该选项不能被压缩，直接放入In-Line部分；

1：该选项能够被压缩，并使用LoWPAN_TCP_OP压缩编码格式。

（B3）TCP选项类型标识OID（TCP Option Identifier）：因为TCP选项的类型和长度值都是固定不变的，故用3个比特表示之，并将选项内容保留于In-Line部分；HTTP常用的选项类型如下所述：

000：类型为0，表示选项列表的结尾（End option List）。

001：类型为1，表示无操作选项（No-Operation）。

010：类型为2，长度为4，表示最大字段值选项（Maximum Segment Size）；且最大选项长度值（Max Seg Size）保留于In-Line部分。

011：类型为3，长度为3，表示TCP窗口范围选项WSopt（TCP Window ScaleOption）；且移位值（Shift）保留于In-Line部分。

100：类型为4，长度为2，表示TCP选择确认允许选项（TCP SACK PermittedOption）。

101：类型为5，长度为10，表示TCP选择确认选项（TCP SACK Option），且将SACK块左边界值（Left Edge of Block）和SACK块右边界值（Right Edgeof Block）都保留于In-Line部分。

110：类型为8，长度为10，表示TCP时间戳选项TSopt（TCP TimestampsOption），且将时间戳值（TS Value）和时间戳返回值（TS Echo Reply）都保留于In-Line部分；

111：保留。

本发明已经进行了多次实施试验，下面简要介绍实施例中的仿真情况：通过浏览器访问6LoWPAN主机中的Web服务器，并通过工具获取相应数据包。

为了能更清楚地演示压缩效果，这里只截取TCP三次握手的过程，并只保留TCP首部的部分，并分别进行下述分析：

第一个数据包（第一次握手）：

压缩之前的TCP首部：a4a900503d8d c3f000000000a002135857e00000020404d60402080a00207c01030305，

压缩之后的TCP首部：05a4a93d8d c3f0135857e01a04d61c1e00207c3f00000000190b05。

表1第一次握手的压缩结果分析

第二个数据包（第二次握手）：

压缩之前的TCP首部：0050a4a9000001943d8d c3f1601204c431470000020404c4，

压缩之后的TCP首部：31000001943d8d c3f104c431470a04c4。

表2第二次握手的压缩结果分析

第三个数据包（第三次握手）：

压缩之前的TCP首部：a4a900503d8d c3f1000001955010135839800000，

压缩之后的TCP首部：683d8d c3f100000195501013583980。

表3第三次握手的压缩结果分析

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明保护的范围之内。

Claims

1.一种用于6LoWPAN网络中面向超文本传输协议HTTP的传输控制协议TCP首部压缩方法，其特征在于：6LoWPAN网络中的所有基于HTTP的通信过程都要执行TCP首部的压缩和解压操作，以减少数据链路层的数据分片和提高通信效率；所述方法包括下列操作步骤：

所述TCP中基本首部是顺序包括端口号（Ports）、序列号和确认号（Sequence and Acknowledgment Number）、首部长度（Header Length）、标志位（Flags）、窗口值（Window）、紧急指针（Urgent Pointer）和校验和（Checksum）共7个字段的TCP报文前20个字节，TCP基本首部的压缩操作是对LoWPAN_NHC编码方法的扩展，即将该20个字节压缩为前3个比特为标志位F、接着2个比特为端口号P，最后3个比特为首部长度HL的单字节TCP基本首部的压缩编码；包括下列操作内容：

（41）对标志位F（Flags）进行压缩：因在HTTP中不会用到紧急指针位（URG），且在TCP传输过程中有些情况不会出现，故只对包括应答位ACK、推送位PSH、重置位RST、同步位SYN和结束位FIN共5个标志位可能出现的各种不同情况进行下述编码:

000:表示ACK=0,PSH=0,RST=0,SYN=1,FIN=0;

001:表示ACK=1,PSH=0,RST=0,SYN=1,FIN=0;

010:表示ACK=1,PSH=0,RST=0,SYN=0,FIN=1;

011:表示ACK=1,PSH=0,RST=0,SYN=0,FIN=0;

100:表示ACK=1,PSH=1,RST=0,SYN=0,FIN=0;

101:表示ACK=0,PSH=0,RST=1,SYN=0,FIN=0；

110和111:均为保留标志位；

11：HTTP服务器端口号不是80的情况；

110和111：均为保留用途；

（45）对窗口值（Window）进行压缩：将其保留于In-Line部分；

（6）物理层将数据链路帧通过网络发送给接收端；

2.根据权利要求1所述的方法，其特征在于：所述单字节TCP基本首部的压缩编码里没有设置NHC ID字段，原因是该压缩编码恰好为一个字节长度，如果要设置LoWPAN_NHC编码的NHC ID字段，就要额外再增加一个字节；再者，数据包不会同时包含TCP和UDP首部，故压缩时通过IPv6首部的Next Header字段就能区分之。

3.根据权利要求1所述的方法，其特征在于：所述TCP中扩展选项的选项类型（Kind），选项总长度（Length）和选项内容（Value）共3个字段的压缩操作是将其压缩为前3个比特设置为固定值000，接着2个比特分别为下一个选项NO和压缩标志位C，最后3个比特为TCP选项类型标识OID的单字节TCP扩展选项压缩编码（LoWPAN_TCP_OP）；包括下列操作内容：

（4A）下一个选项NO（Next Option）：

0：表示该选项是整个首部中最后一个选项字段；

1：表示该选项后面还有其他选项字段；

（4B）压缩标志C（Compressed）：

0：该选项不能被压缩，直接放入In-Line部分；

1：该选项能够被压缩，并使用TCP选项类型标识OID的单字节TCP扩展选项压缩编码（LoWPAN_TCP_OP）格式；

（4C）TCP选项类型标识OID（TCP Option Identifier）：因TCP选项的类型和长度值都是固定不变的，故用3个比特表示之，并将选项内容保留于In-Line部分；HTTP常用的选项类型如下所述：

000：类型为0，表示选项列表的结尾（End of Option List）；

001：类型为1，表示无操作选项（No-Operation）；

010：类型为2，长度为4，表示最大字段值选项（Maximum Segment Size）；且最大选项长度值（Max Seg Size）保留于In-Line部分；

011：类型为3，长度为3，表示TCP窗口范围选项WSopt（TCP Window Scale Option）；且移位值（Shift）保留于In-Line部分；

100：类型为4，长度为2，表示TCP选择确认允许选项（TCP SACK Permitted Option）；

101：类型为5，长度为10，表示TCP选择确认选项TCP SACK Option，且将SACK块左边界值（Left Edge of Block）和SACK块右边界值（Right Edge of Block）都保留于In-Line部分；

110：类型为8，长度为10，表示TCP时间戳选项TSopt（TCP Timestamps Option），且将时间戳值（TS Value）和时间戳返回值（TS Echo Reply）都保留于In-Line部分；

111：保留。