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