组织：中国互动出版网（http://www.china-pub.com）<br />
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）<br />
E-mail：ouyang@china-pub.com<br />
译者：wind_like（wind_like&nbsp;&nbsp;wind_feng2000@163.com&nbsp;）<br />
译文发布时间：2001-5-8<br />
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必<br />
须保留本文档的翻译及版权信息。<br />
<br />
<br />
<br />
Network&nbsp;Working&nbsp;Group&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;M.&nbsp;Rose<br />
Request&nbsp;for&nbsp;Comments:&nbsp;3081&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Invisible&nbsp;Worlds,&nbsp;Inc.<br />
Category:&nbsp;Standards&nbsp;Track&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;March&nbsp;2001<br />
<br />
<br />
将区块扩展交换协议（BEEP）核心映射到传输控制协议（TCP）<br />
(RFC&nbsp;3081&nbsp;Mapping&nbsp;the&nbsp;BEEP&nbsp;Core&nbsp;onto&nbsp;TCP)<br />
<br />
本备忘录的状态<br />
本文档讲述了一种Internet社区的Internet标准跟踪协议，它需要进一步进行讨论和<br />
建议以得到改进。请参考最新版的“Internet正式协议标准”&nbsp;(STD1)来获得本协议的标准<br />
化程度和状态。本备忘录的发布不受任何限制。<br />
版权声明<br />
Copyright&nbsp;(C)&nbsp;The&nbsp;Internet&nbsp;Society&nbsp;(2001)。保留所有权利。<br />
摘要<br />
本备忘录讲述了如何将一个BEEP（区块扩展交换协议）会话映射到单个TCP（传输控制<br />
协议）连接上。<br />
<br />
<br />
目录<br />
1.&nbsp;&nbsp;&nbsp;&nbsp;引言&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;1<br />
&nbsp;&nbsp;&nbsp;&nbsp;2.&nbsp;&nbsp;&nbsp;&nbsp;会话管理&nbsp;&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;2<br />
&nbsp;&nbsp;&nbsp;&nbsp;3.&nbsp;&nbsp;&nbsp;&nbsp;报文交换&nbsp;&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;2<br />
&nbsp;&nbsp;&nbsp;&nbsp;3.1&nbsp;&nbsp;&nbsp;流量控制&nbsp;&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;3<br />
&nbsp;&nbsp;&nbsp;&nbsp;3.1.1&nbsp;信道建立&nbsp;&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;3<br />
&nbsp;&nbsp;&nbsp;&nbsp;3.1.2&nbsp;发送报文&nbsp;&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;3<br />
&nbsp;&nbsp;&nbsp;&nbsp;3.1.3&nbsp;处理SEQ帧&nbsp;&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;4<br />
&nbsp;&nbsp;&nbsp;&nbsp;3.1.4&nbsp;使用流量控制&nbsp;&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;4<br />
&nbsp;&nbsp;&nbsp;&nbsp;4.&nbsp;&nbsp;&nbsp;&nbsp;安全性考虑&nbsp;&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;6<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;参考文献&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;6<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;作者地址&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;6<br />
&nbsp;&nbsp;&nbsp;&nbsp;A.&nbsp;&nbsp;&nbsp;&nbsp;致谢&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;7<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;完整版权声明&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.&nbsp;.8<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
1.	引言<br />
本备忘录讲述了如何将一个BEEP[1]会话映射到单个TCP[2]连接上。关于映射要求的解<br />
释见参考文献[1]的2.5节。<br />
2.	会话管理<br />
&nbsp;&nbsp;&nbsp;&nbsp;BEEP会话管理到TCP业务的映射是直接进行的。<br />
当建立起一个TCP连接时就在两个BEEP对等体之间建立一个BEEP会话。<br />
O&nbsp;&nbsp;发起一个被动TCP&nbsp;OPEN呼叫道BEEP对等体称为接收者。<br />
O&nbsp;&nbsp;发起一个主动TCP&nbsp;OPEN呼叫道BEEP对等体称为发起者。<br />
同时发起的TCP&nbsp;OPEN会导致两个BEEP对等体都认为它们是发起者，而使得两者都不能<br />
建立起通道。因此，基于BEEP的业务应该不允许两个TCP&nbsp;OPENs同时出现。<br />
如果两个对等体都同意释放一个BEEP会话（c.f.，参考文献[1]2.4节），发送“ok”<br />
回答的对等体立即发起TCP&nbsp;CLOSE呼叫。另一个对等体收到回答后也立即发起TCP&nbsp;CLOSE<br />
呼叫。<br />
任意一个对等体发起TCP&nbsp;ABORT呼叫时BEEP会话就被终止，TCP连接随后也终止。<br />
3.&nbsp;报文交换<br />
BEEP报文交换到TCP业务上的映射不像这样直接。<br />
报文使用TCP的SEND和RECEIVE呼叫进行可靠发送和接收。（这也提供了在同一信道上<br />
报文的顺序传送。）<br />
尽管TCP对每个连接进行流量控制，但是如果在一个BEEP会话中同时使用多个信道，<br />
BEEP应该提供一种避免资源匮乏和死锁的机制。为此，BEEP重新引入了一种TCP使用的机<br />
制：基于窗口的流量控制——每个信道有一个滑动窗口，指明对等体在收到进一步的发送许<br />
可之前可以发送的有效载荷八位组数。<br />
3.	1流量控制<br />
参考文献[1]第2.2.1.2节讲过，在一个信道的两个方向上传输的每个负载八位组都有<br />
一个相关联的顺序号。数据帧中的负载八位组是这样编号的：第一个八位组编最小号，后面<br />
的八位组依次连续编号。尽管顺序号空间很大，从0到4294967295&nbsp;(2**32&nbsp;-&nbsp;1)，但还是<br />
有限的。因此，所有对顺序号的算术运算是按模2**32进行的。这种无符号算法保持了顺序<br />
号之间的关联，因为它们从2**32&nbsp;-&nbsp;1到0循环。有关顺序号算法属性的讨论可参见参考文<br />
献[3]的第2节到第5节。<br />
3.1.1&nbsp;信道建立<br />
信道建立时，与第一个数据帧的第一个八位组相关联的顺序号是0，并且这个信道最初<br />
的窗口大小是4096个八位组。信道建立后，BEEP对等体可以发送一个SEQ帧来改变窗口大<br />
小（3.1.3节）。<br />
如果BEEP对等体被要求建立一个信道而又不能分配最少4096个八位组的话，那么它应<br />
该如参考文献[1]第2.3.1.2节所指出的，拒绝建立信道。类似地，在BEEP会话建立过程中，<br />
如果处在监听状态的BEEP对等体不能为0信道分配至少4096个八位组，那么它应该如参考<br />
文献[1]第2.4节所指出的，返回一个拒绝回答，而不是同意。<br />
3.1.2&nbsp;发送报文<br />
发送报文之前，发送端BEEP对等体应该保证待发送的负载大小在接收端BEEP对等体通<br />
告的窗口大小之内。如果不是，那么有三种选择：<br />
?	如果窗口允许发送至少一个八位组，BEEP对等体可以分割报文并发送一个较小<br />
的数据帧（大小可为窗口剩余的八位组数）；<br />
?	BEEP对等体延迟发送报文，直到窗口变大；或者，<br />
?	BEEP对等体给其应用程序发信号说明其不能发送报文，并允许应用程序过一段<br />
时间重试（或者在窗口变大时给应用程序发信号）。<br />
这种选择与实现方式有关，尽管人们推荐给使用BEEP的应用程序增加一个机制来影响<br />
其选择。<br />
3.1.3&nbsp;处理SEQ帧<br />
应用程序决定接收数据帧时，其对等体应该发送SEQ帧来通告一个新窗口。<br />
SEQ帧的ABNF[4]是：<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;seq&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=&nbsp;"SEQ"&nbsp;SP&nbsp;信道&nbsp;SP&nbsp;确认序号&nbsp;SP&nbsp;窗口&nbsp;CR&nbsp;LF<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ackno&nbsp;&nbsp;&nbsp;=&nbsp;顺序号<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;window&nbsp;&nbsp;=&nbsp;窗口大小<br />
；信道，顺序号和窗口大小在参考文献[1]第2.2.1节中定义。<br />
SEQ帧有三个参数：<br />
?	信道号<br />
?	确认序号，指明发送者在这个信道上准备接收的下一个顺序号。<br />
?	窗口大小，指明以确认序号开始的负载八位组数，这个确认序号是发送者在这<br />
个信道上准备接收的下一个顺序号。<br />
&nbsp;&nbsp;&nbsp;&nbsp;每个分量之间用一个空格字符（十进制码32,“&nbsp;”）隔开。SEQ帧以一个CRPF对结束。<br />
收到一个SEQ帧时，如果信道号、确认序号或窗口大小中的任何一个参数无法确定和不<br />
合法，则终止BEEP会话而并不产生响应,因此建议加入一个诊断入口。<br />
3.1.4&nbsp;流量控制的使用<br />
在BEEP中成功使用流量控制的关键是在性能和公平性之间平衡：<br />
?	大报文应分割为不大于TCP规定的最大分段的三分之二的帧；<br />
?	等待发送数据的各不同信道中的帧应以循环方式发送；<br />
?	每次收到一个帧时，只要待发送到窗口至少有对这个信道可用的缓存空间的一<br />
半就必须发送一个SEQ帧。<br />
?	如果传输业务同时给BEEP对等体发送多个帧，则可以发送单个合并对SEQ帧。<br />
为了避免与传输业务产生病态的交互，很重要的一点是，BEEP对等体应根据可用的缓<br />
存空间来通告窗口大小，只要一有可用空间就允许从传输业务中读取数据。并且，信道的<br />
SEQ帧应该有比报文更高的优先级。<br />
实现可能希望为使用BEEP的应用程序提供队列管理工具，例如：信道优先级，（相关的）<br />
缓存分配，等等。特别地，实现应不允许一个给定的信道独占传输窗口。<br />
另外，可能的话，实现应支持传输层传送拥塞信息的应用程序接口（APIs）。这些APIs<br />
允许实现决定其可用带宽的共享，同时将估测通道带宽的变化通知给实现。注意，BEEP会<br />
话有多个信道同时交换大报文时，如果实现不能获得这些信息，则在网络拥塞时可能会产生<br />
不确定的公平性和影响其继续进行的问题。<br />
最后，实现应依循RFC1122[5]中相关章节给出的规定，该文档讨论了流量控制（记住，<br />
一些问题如重传在本备忘录中不能使用，而在TCP中它们是和流量控制相互作用的）。例如，<br />
RFC1122[5]第4.2.2.16节指出，接收者不应当缩小窗口，如将窗口的右边界向左移，并讨<br />
论了这条规则对未确认数据的影响。在与映射BEEP到单个TCP连接相关的内容中，只有关<br />
于流量控制的部分应予实现。<br />
4.安全考虑<br />
安全问题的讨论参考文献[1]的第九节。<br />
参考文献<br />
[1]&nbsp;&nbsp;Rose,&nbsp;M.,&nbsp;"The&nbsp;Blocks&nbsp;Extensible&nbsp;Exchange&nbsp;Protocol&nbsp;Core",&nbsp;RFC&nbsp;3080,&nbsp;March&nbsp;<br />
2001.<br />
&nbsp;&nbsp;&nbsp;&nbsp;[2]&nbsp;&nbsp;Postel,&nbsp;J.,&nbsp;"Transmission&nbsp;Control&nbsp;Protocol",&nbsp;STD&nbsp;7,&nbsp;RFC&nbsp;793,&nbsp;September&nbsp;<br />
1981.<br />
&nbsp;&nbsp;&nbsp;&nbsp;[3]&nbsp;&nbsp;Elz,&nbsp;R.&nbsp;and&nbsp;R.&nbsp;Bush,&nbsp;"Serial&nbsp;Number&nbsp;Arithmetic",&nbsp;RFC&nbsp;1982,&nbsp;August&nbsp;1996.<br />
&nbsp;&nbsp;&nbsp;&nbsp;[4]&nbsp;&nbsp;Crocker,&nbsp;D.&nbsp;and&nbsp;P.&nbsp;Overell,&nbsp;"Augmented&nbsp;BNF&nbsp;for&nbsp;Syntax&nbsp;Specifications:&nbsp;ABNF",&nbsp;<br />
RFC&nbsp;2234,&nbsp;November&nbsp;1997.<br />
&nbsp;&nbsp;&nbsp;&nbsp;[5]&nbsp;&nbsp;Braden,&nbsp;R.,&nbsp;"Requirements&nbsp;for&nbsp;Internet&nbsp;Hosts&nbsp;--&nbsp;Communication&nbsp;Layers",&nbsp;STD&nbsp;<br />
3,&nbsp;RFC&nbsp;1122,&nbsp;October&nbsp;1989.<br />
作者地址<br />
Marshall&nbsp;T.&nbsp;Rose<br />
&nbsp;&nbsp;&nbsp;&nbsp;Invisible&nbsp;Worlds,&nbsp;Inc.<br />
&nbsp;&nbsp;&nbsp;&nbsp;1179&nbsp;North&nbsp;McDowell&nbsp;Boulevard<br />
&nbsp;&nbsp;&nbsp;&nbsp;Petaluma,&nbsp;CA&nbsp;&nbsp;94954-6559<br />
&nbsp;&nbsp;&nbsp;&nbsp;US<br />
<br />
&nbsp;&nbsp;&nbsp;&nbsp;Phone:&nbsp;+1&nbsp;707&nbsp;789&nbsp;3700<br />
&nbsp;&nbsp;&nbsp;&nbsp;EMail:&nbsp;mrose@invisible.net<br />
&nbsp;&nbsp;&nbsp;&nbsp;URI:&nbsp;&nbsp;&nbsp;http://invisible.net/<br />
附录A&nbsp;&nbsp;致谢<br />
作者非常感谢以下人的帮助：Dave&nbsp;Crocker，Steve&nbsp;Harris，Eliot&nbsp;Lear，Keith&nbsp;<br />
McCloghrie，Craig&nbsp;Partridge，Vernon&nbsp;Schryver和Joe&nbsp;Touch.。特别地，Dave&nbsp;Crocker<br />
对映射中的流量控制的特性提出了有意的建议。<br />
完整版权声明<br />
Copyright&nbsp;(C)&nbsp;The&nbsp;Internet&nbsp;Society&nbsp;(2001)。所有权利保留。&nbsp;<br />
本文档及其译文可以复制并对外提供。可以部分或全部编著、复制、出版、分发与其有<br />
关的评议、解释和有助于实施的派生著作，没有任何限制，但要求在复制文件和派生著作中<br />
包括上述版权警告及本节版权声明内容。但是，本文档的内容不允许做任何形式的修改，诸<br />
如删除版权警告或者关于因特网协会或者其他因特网组织的介绍，除非为了开发Internet<br />
标准或翻译成英语以外的其他语言的需要，即使在这种情况下，也仍然必须遵循Internet<br />
标准过程中确定的版权程序。<br />
上述许可是永久性的，不会由因特网协会或者它的继承者或转让者予以废除。<br />
本文档及其提供的信息以“现状”为基础，因特网协会与IETF(因特网工程任务小组)<br />
否认所有的保证明示或暗示，包含但并不限于任何保证。所含信息的使用将不会侵犯具有特<br />
殊目的的商用性或者适用性的任何权利或隐含的保证。<br />
致谢<br />
RFC编辑基金由因特网协会提供。<br />
RFC&nbsp;3081&nbsp;Mapping&nbsp;the&nbsp;BEEP&nbsp;Core&nbsp;onto&nbsp;TCP将区块扩展交换协议（BEEP）核心映射到传输控制协议（TCP）<br />
<br />
<br />
1<br />
RFC文档中文翻译计划<br />