头压缩协议(rfc4996)中文翻译.docx
《头压缩协议(rfc4996)中文翻译.docx》由会员分享,可在线阅读,更多相关《头压缩协议(rfc4996)中文翻译.docx(74页珍藏版)》请在咨信网上搜索。
1、RFC4996中文版RObust Header Compression (ROHC): A Profile for TCP/IP (ROHC-TCP)摘要本文档为TCP/IP报头指定了一个健壮的头压缩机制。该机制被称为ROHC-TCP,提供了有效且健壮的TCP头压缩,包括频繁使用的TCP选项,如SACK(选择性确认)和时戳。ROHC-TCP在错误率高和RTT长的链路上表现良好,常有许多这样的链路带宽有限,必需要头压缩。目录1. 介绍2. 术语基础上下文基础上下文是压缩器和解压器都已经证实的上下文。一个基础上下文可以被用来作为使用复制建立新上下文的参考基础上下文标识符(基础CID)基础CID是标
2、识基础上下文的CID,从基础上下文中可以提取到上下文复制时需要的信息基础报头未压缩报文的最里层的IP和TCP报头的压缩形式链接条目一条链基于相似的特性组合条目。ROHC-TCP为静态、动态、可复制或不规则的条目定义条目链。链接是通过为每个报头添加条目来完成的,例如以条目在未压缩报文中出现顺序来添加给链。上下文复制(CR)上下文复制是一种基于另外一个存在的有效上下文(一个基础上下文)来建立和初始化一个新上下文的机制。引入这个机制是为了减少上下文建立流程的负载,特别适用于压缩多个短暂TCP连接,这些连接可能同时或近乎同时发生ROHC-TCP报文类型ROHC-TCP使用3种报文类型:初始和刷新(IR
3、)报文类型,上下文修复(IR-CR)报文类型和压缩(CO)报文类型短暂(Short-lived) TCP传输是指用每个单个连接只传输少量报文的TCP连接2.1缩写2.2翻译术语Profile 机制Packet 报文Header 报头、头Fields 字段、域formal notation 标注格式3. 背景3.1 现存TCP/IP头压缩机制3.2 TCP/IP头字段分类报文有可能压缩正是由于报文(尤其是连续的报文)的头字段之间有很大的冗余。 对于TCP/IP头压缩要利用这些特性,了解各种头部字段的变化模式就很重要。所有TCP/IP报文的头字段都已在RFC4413中详细分类。主要结论是大多数头字
4、段很容易被压缩,因为它们从不改变或很少改变。然而以下字段确实需要更复杂的机制:- IPv4 Identification (16 bits) - IP-ID- TCP Sequence Number (32 bits) - SN- TCP Acknowledgment Number (32 bits)- TCP Reserved ( 4 bits)- TCP ECN flags ( 2 bits) - ECN- TCP Window (16 bits)- TCP Optionso Maximum Segment Size (32 bits) - MSSo Window Scale (24 bi
5、ts) - WSCALEo SACK Permitted (16 bits)o TCP SACK (80, 144, 208, or 272 bits) - SACKo TCP Timestamp (80 bits) - TSIP-ID值能有多种方式分配,通常是有序的、按序跳变或随机的其中之一,如4.1.3 RFC4413节所述。一些IPV4栈使用有序分配产生IP-ID值,但是不按照该值的网络字节序发送,而是将2个字节颠倒后发送。在这种情况下压缩器能在交换子节后压缩IP-ID字段。因此,解压器也在解压后交换IP-ID字节以再生出原始IP-ID。关于TCP压缩,RFC4413中分析显示在TCP字
6、段中没有明显的备选来推导出IP-ID。几个TCP字段(Sequence Number,Acknowledgment Number, Window等)的变化很难预测。理解序列号和确认号RFC4413对于TCP/IP头压缩机制特别重要。特别地,TCP序列号能是TCP窗口范围内的任意值(即,可能在任何地方进行压缩)。丢包或重传能引起TCP序列号在窗口限制内波动。TCP窗口也限制了确认号跳变。TCP/IP头的另外一个重要行为是序列号和确认号之间的依赖。关于数据业务TCP连接能要么是近乎对称,要么显示出强烈的不对称偏好。这意味着在转发路径(从服务器到客户端)上,对于大部分报文,只有确认号在变化,而序列号
7、保持不变。TCP压缩机制应该有适用于两者情况的报文格式,即,报文格式要么能够携带单序列号比特、单确认号比特,要么两者皆可。另外,TCP流能是短时传输。TCP短时传输会降低通过初始发送全头来建立上下文的头压缩机制的性能。多个同时或近乎同时的TCP连接可能在头子段值和上下文值之间显示出许多相似性,这个使得在初始化新的上下文时复用流之间的信息成为可能。为此,一种上下文复用机制,通过复用一个存在的上下文的一部分给一个新流,使得上下文建立更快更高效。RFC4413的总结是部分IP子上下文、一些TCP字段和一些上下文值能被复制,因为它们很少变化或者仅仅一个小的跳变。ROHC-TCP也压缩如下报头:IPV6
8、目的选项报头RFC2460、IPV6路由报头、IPV6逐跳选项报头RFC2460、鉴权报头(AH)RFC4302、空加密封装安全负载(ESP)报头RFC4303、通用路由封装(GRE)RFC2784RFC2890和最小封装头(MINE)RFC2004。本文档没有针对移动IP(IPV4或IPV6)的特殊处理,原因和RFC3095中的描述类似。4. TCP/IP机制概述(信息的)4.1 通用概念ROHC-TCP使用RFC4995描述的头压缩协议。支持RFC4164种定义的上下文复制。上下文复制对短时TCP流RFC4413特别有用。4.2 压缩器和解压器交互4.2.1 压缩器操作采用ROHC的头压缩
9、在概念上可以表现为一个压缩器和解压器交互的状态机。压缩机的任务是,基于对有关解压器上下文状态的一定信心,发送需要成功解压报文的最少信息。对于ROHC-TCP压缩,压缩器通常开始工作时初始假设解压器没有有用信息来处理新流,于是发送初始化和刷新(IR)报文。可选地,压缩器也可以支持上下文复制(CR),使用IR-CR报文RFC4164,来尝试复用和另外一个流相关的上下文信息。之后,基于对解压器已经有必要信息来成功处理自己选择的压缩(CO)报文的信心,压缩器能调整压缩级别。换言之,压缩器的任务就是确保解压器工作在允许解压最有效的CO报文的状态,否则确保允许解压器尽可能转移到这样的状态。4.3.2 解压
10、器反馈ROHC-TCP机制能在带或者不带从解压器到压缩器的反馈能力的环境中使用。但是,ROHC-TCP假设:如果一个ROHC反馈信道可用,并且如果对于一个指定的ROHC-TCP上下文这个信道至少一次被解压强使用,那么对于该上下文该信道将要在整个压缩操作被使用。如果反馈信道消失了,压缩必须要重启。接收到确认(ACKs)或否定应答(NACKs),就为收到反馈的上下文建立来自解压器的反馈信道。一旦为指定上下文建立了反馈信道,压缩器应该使用该反馈来估计解压器当前的状态。这个通过提供压缩器达到必要的信心级别所需的信息,有助于增加压缩效率。ROHC-TCP反馈机制的能力是被FEEDBACK-2格式(见8.
11、3节)中使用的主序列号(MSN)(见6.1.1节)的位数(最低有效位(LSB)编码)限制的。4.3 报文格式和编码方法使用RFC4997标注形式定义ROHC-TCP使用的报文格式和编码方法。这个标注格式被用来提供报文格式的清晰表示以及编码方式的清楚定义。4.3.1 压缩TCP选项ROHC-TCP使用允许建立选项内容的列表压缩编码来压缩TCP选项,这样TCP选项能被加入到上下文,而不用必须发送所有未压缩的TCP选项。4.3.2 压缩扩展头ROHC-TCP压缩3.2节中列出的扩展头。这些扩展头和其他其它报头同样对待,因此具有静态链,动态链,不规则链和上下文复制链(见6.2)。这意味着报头从正在压缩
12、的流中出现或消失将会导致静态链变化。但是,使用这个设计策略,扩展头的变化模式注定不会影响压缩效率。4.4ROHC-TCP期望的压缩率下述表格描述了使用ROHC-TCP和IPHCRFC2507预期的典型压缩效率。表格中的数字假设压缩上下文已经被很好地初始化。对于TS选项,时戳以小值变化。所有的TCP选项包含一个合适个无操作(NOP)选项RFC0793来填充和或对齐。最后,以IPV4为例,具有有序的IP-ID行为。Fig. typical compression ratios of ROHC-TCP and IPHC1) 数据流的负载大小是常量2) 报头中出现SACK选项,但是不在前面的报文中。假
13、设有2个SACK块。3) 报头中出现SACK选项,同时也在前面的报文中(具有不同的SACK块)。假设有2个SACK块。下表描述了ROHC-TCP和IPHC的典型初始压缩率。例子中的数据流假设是IPV4+TCP,IP-ID具有有序行为。如下选项出现在SYN报文中:TS、MSS、WSCALE,以及一些合适个NOP选项。Fig. typical initial compression ratios of ROHC-TCP and IPHC表中的数字假设压缩器在压缩第二个报文前已经收到一个来自解压器的确认,当ROHC-TCP中使用反馈时能够期望收到确认。这是因为在大部分情况下,TCP ACKs期望使用
14、相同的返回路径,并且因为TCP不能发送更多的报文直到TCP SYN报文被确认。5. 压缩器和解压器逻辑(规范的)5.1 上下文初始化ROHC-TCP流的静态上下文能用以下两种方式之一进行初始化 通过使用7.1节的IR报文,profile是0x06,并且静态链以TCP头的静态部分结束 通过使用RFC4164定义的机制复制一个存在的上下文。这是用7.2节定义的IR-CR报文,profile是0x06。5.2 压缩器操作5.2.1 压缩逻辑压缩器的任务是决定在压缩TCP/IP报文时发送什么数据,使得解压器基于当前状态能成功重构初始报文。选择压缩头类型来发依赖于需要因素,包括: 报文流中的头子段变化行
15、为,例如,在可用报文格式的限制范围内传送必要的信息 压缩器对解压器状态的信心级别,例如,为多个连续的数据包或来从接收解压器反馈(ACK和或NACKs)中,选择报头格式来更新同类型信息翻译地有点奇怪 报文流需要的额外的健壮性,例如,当不期待解压器的反馈时,周期地使用IR和IR-DYN报文刷新静态和动态信息这些因素对压缩器报文类型选择的影响在后面子章节中进行更为详细的描述。在本节中,“更高压缩状态”意味着将在压缩报文中发送更少数据,即,使用更小的压缩头。同时更低压缩状态意味着更多数据将使用更大的压缩报文发送。5.2.1.1 优化方法优化方法是一种准则,据此准则压缩器为一些报文(连续或不连续)发送相
16、同类型的信息,直到压缩器相当自信于解压器以及收到了这个信息。当ROHC-TCP用来在丢包链路中压缩报文时,优化方法对保证健壮性很有用。因此,如果未压缩报文的字段X值发生了变化,压缩器必须使用一种报文类型,该类型包含字段X的编码直到压缩器有足够信心于解压器已经至少收到了包含X新值的一个报文。压缩器应该选择一个具有最小报头的能携带变化的压缩格式来满足使用的优化方法条件。5.2.1.2 周期上下文刷新当使用优化方法时,由于解压器没有收到正确解压的足够信息总有可能解压失败。因此,压缩器应该周期移到更低的压缩状态并且发送IR或IR-DYN报文,直到解压器建立一个反馈信道。这些刷新能基于超时,基于流中发送
17、的压缩报文个数,或者任何其他特定于实现的策略。一旦建立了反馈信道,解压器可以停止周期刷新。5.2.2 反馈逻辑反馈消息、应答(ACKs)、否定应答(NACKs或STATIC-NACKs)的语义在5.2.4.1 RFC4995节定义。5.2.2.1 可选的应答(ACKs)压缩器可以使用应答反馈(ACKs)来移到更高的压缩状态。接收到一个更新上下文的报文的ACK,压缩器获取足够的信心于解压器已经受到了被确认的报文并且解压器已经获得了报文流中被确认报文前的变化。这个功能是可选的,因此压缩器不必期待得到这样的ACKs,即便有反馈信道可用并且已经为该报文流建立了反馈信道。5.2.2.2否定应答(NACK
18、s)压缩器使用来自于解压器的反馈来移到更低的压缩状态(NACKs)。接收到NACK反馈,压缩器应该 假设解压器仅仅静态部分是有效的,并且 下一次在压缩指示流的报文时,重发所有的动态信息(通过IR或IR-DYN报文)除非猜测对应的场景是:在NACK报文之后,压缩器已经发送过包含所有动态信息的IR或IR-DYN报文压缩器有信心于在正被确认的报文之后发送的信息已经为NACK反馈提供了合适的响应。另外, 压缩器可以使用携带7比特循环冗余检查(CRC)的CO报文,如果压缩器能有足够信息决策出什么信息会为NACK反馈提供合适的响应。接收到STATIC-NACK反馈,压缩器应该 假设解压器没有有效上下文,并
19、且 下一次在压缩指示流的报文时,重发所有的静态和动态信息(通过IR报文)除非压缩器有信心于在正被确认的报文之后发送的信息已经为STATIC-NACK反馈提供了合适的响应。5.2.3 上下文复制压缩器可以通过实现RFC416中定义的额外压缩和反馈逻辑来支持上下文复制。5.3 解压器操作5.3.1解压器状态和逻辑解压器的3个状态时无上下文(NC)、静态上下文(SC)和全上下文(FC)。解压器开始于最低压缩状态,NC状态。成功解压总会将解压器移到FC状态。解压器一旦进入该状态正常不会离开;只有重复解压失败会强制解压器向下转移到更低的状态。下面是解压器的状态机。状态之间转移的细节和压缩器逻辑在图后面的
20、子节给出。解压器的状态机5.3.1.1 重构和验证当解压IR或IR-DYN报文,解压器必须验证接收到的使用CRC-8校验RFC4995的报文头的完整性。如果验证失败,报文不允许递给上层。当收到一个IR-CR报文,解压器必须执行RFC4164中指定的行为。当解压其它报文类型(例如,CO报文),解压器必须验证使用CRC校验RFC4995的解压缩尝试的结果。如果验证失败,解压器实现可以尝试矫正或修复报文的方法,并且任何尝试结果必须使用CRC校验验证;反之,报文不允许递给上层。当收到报文的CRC-8校验或CRC校验成功,解压器应该用当前报头中收到的信息更新上下文;然后解压器将重构的报文传给系统的网络层
21、。反之,解压器的上下文不允许被更新。如果接收到的报文比当前参考报文更旧,例如,基于压缩报文中的主序列号(MSN),解压器可以避免使用当前报文信息更新上下文,即便报文的正确性已经被成功验证。5.3.1.2 检测上下文损坏所有报头格式携带CRC并且是上下文更新。一个CRC成功的报文或者显示地(从压缩报头携带的字段的信息中)或者隐式地(从其它字段中推到出来的字段)更新所有头字段的参考值。解压器可以假设一些或整个上下文是无效的,在一个或多个故障之后使用CRC验证或验证报头。因为解压器不能知道CRC失败的准确原因或者什么字段引起的,因此上下文的有效性并不是指确切的上下文条目被认为是有效与否。上下文的有效
22、性相当于检测上下文中的问题。解压器首先假设最有可能引起失败的信息类型是每个报文正常变化的状态,即,上下文动态部分的上下文损坏。由于重复的失败和不成功的修复,解压器假设整个上下文,包括静态部分,需要被修复,即,静态上下文损坏。上下文损坏检测上下文损坏的假设意味着解压器将不会尝试解压一个携带3-bit CRC的CO报头,并且仅仅尝试解压IR、IR-DYN、IR-CR报头或被CRC-7保护的CO报头。静态上下文损坏检测静态上下文损坏的假设意味着解压器避免尝试解压除IR报头外的任何类型的报头。怎么做出这些假设,即,上下文损坏如何被检测,对实现是开放的。It can be based on the re
23、sidual error rate, where a low error rate makes the decompressor assume damage more often than on a high-rate link。解压器通过选择其尝试解压的压缩报头类型来实现假设。换言之,上下文的有效性涉及到解压器尝试或者不尝试解压特定的报文类型。5.3.1.3 无上下文(NC)状态起初,工作在NC状态,解压器还没有成功解压一个报文。允许的解压:在NC状态,只有携带在静态字段的足够信息的报文(IR和IR-CR报文)能被解压缩;否则,报文不允许解压缩并且不允许提交给上层。反馈逻辑:在NC状态,如果
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 压缩 协议 rfc4996 中文翻译
1、咨信平台为文档C2C交易模式,即用户上传的文档直接被用户下载,收益归上传人(含作者)所有;本站仅是提供信息存储空间和展示预览,仅对用户上传内容的表现方式做保护处理,对上载内容不做任何修改或编辑。所展示的作品文档包括内容和图片全部来源于网络用户和作者上传投稿,我们不确定上传用户享有完全著作权,根据《信息网络传播权保护条例》,如果侵犯了您的版权、权益或隐私,请联系我们,核实后会尽快下架及时删除,并可随时和客服了解处理情况,尊重保护知识产权我们共同努力。
2、文档的总页数、文档格式和文档大小以系统显示为准(内容中显示的页数不一定正确),网站客服只以系统显示的页数、文件格式、文档大小作为仲裁依据,平台无法对文档的真实性、完整性、权威性、准确性、专业性及其观点立场做任何保证或承诺,下载前须认真查看,确认无误后再购买,务必慎重购买;若有违法违纪将进行移交司法处理,若涉侵权平台将进行基本处罚并下架。
3、本站所有内容均由用户上传,付费前请自行鉴别,如您付费,意味着您已接受本站规则且自行承担风险,本站不进行额外附加服务,虚拟产品一经售出概不退款(未进行购买下载可退充值款),文档一经付费(服务费)、不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
4、如你看到网页展示的文档有www.zixin.com.cn水印,是因预览和防盗链等技术需要对页面进行转换压缩成图而已,我们并不对上传的文档进行任何编辑或修改,文档下载后都不会有水印标识(原文档上传前个别存留的除外),下载后原文更清晰;试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓;PPT和DOC文档可被视为“模板”,允许上传人保留章节、目录结构的情况下删减部份的内容;PDF文档不管是原文档转换或图片扫描而得,本站不作要求视为允许,下载前自行私信或留言给上传者【精****】。
5、本文档所展示的图片、画像、字体、音乐的版权可能需版权方额外授权,请谨慎使用;网站提供的党政主题相关内容(国旗、国徽、党徽--等)目的在于配合国家政策宣传,仅限个人学习分享使用,禁止用于任何广告和商用目的。
6、文档遇到问题,请及时私信或留言给本站上传会员【精****】,需本站解决可联系【 微信客服】、【 QQ客服】,若有其他问题请点击或扫码反馈【 服务填表】;文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“【 版权申诉】”(推荐),意见反馈和侵权处理邮箱:1219186828@qq.com;也可以拔打客服电话:4008-655-100;投诉/维权电话:4009-655-100。