RSocket FAQ精选

1Why a new protocol?

• 支持超出请求/响应的交互模型，例如流响应和推送
• 跨网络边界的应用程序级流控制语义（异步批处理大小的拉/推）
• 单个连接的二进制复用使用
• 支持通过传输连接恢复长期订阅
• 为了使用传输协议（例如WebSockets和Aeron），需要应用程序协议

2 Why not make do with XYZ?

最终，只要有足够的努力，以上所有动机就可以在大多数事情上实现。 那些参与启动该项目的人需要更清洁，更正规的东西。 换句话说，希望有一个不是黑客的解决方案。

3 Why not HTTP/2?-为什么不是http2

对于浏览器和请求/响应文档传输，HTTP / 2比HTTP / 1更好，但是不幸的是，它没有公开请求/响应之外的交互模型，也不支持应用程序级流控制。

以下是HTTP / 2规范和常见问题解答中的一些引用，可用于提供有关HTTP / 2定位目标的上下文：

• HTTP的现有语义保持不变;
• 从应用角度来看，协议的功能基本上没有变化;
• 这项工作被特许用于修订有线协议”，即如何将HTTP标头，方法等“置于网络上”，而不改变HTTP的语义。;

此外，“承诺”重点在于为标准的Web浏览行为填充浏览器缓存： “推送的响应始终与客户端的明确请求相关联。”

这意味着我们仍然需要SSE或者Websockets来支持推送。

HTTP / 2是比HTTP / 1.1更好用于网站浏览器中的文档检索的方式，对于应用程序，我们可以做得比HTTP / 2更好。

4 What about QUIC?

此时，QUIC尚未公开或可用，不足以发挥作用。 如果/何时改变，我们希望将其用作RSocket的传输层。 RSocket专门用于在QUIC之类的图层上分层。 QUIC提供可靠的传输，拥塞控制，字节级流控制和多路复用字节流。 RSocket在这些事物的基础上分层构建了消息流（单向和双向）的二进制框架和行为语义，消息级别的流控制，恢复等。 RSocket规范是在考虑分层的基础上创建的，因此在TCP之类的协议上，RSocket包括帧长和流ID。 但是在类似HTTP / 2或QUIC的东西上，RSocket会跳过这些内容，而使用HTTP / 2或QUIC提供的内容。

当使用不提供兼容帧的传输协议时，必须在RSocket帧之前添加帧长度。

如果各方都同意，包括多路分解的传输协议（例如HTTP / 2）可以忽略流ID字段。 协商和协议的方式留给传输协议。

5 Why “Reactive Streams” request(n) Flow Control?

如果没有完成工作单元（不是字节）方面的应用程序反馈，则很容易造成“行头阻塞”，使网络和应用程序缓冲区不堪重负，并且在服务器上产生的数据量将超过客户端所能处理的。当在单个连接上多路复用多个流时，其中一个流可能会耗尽所有其他流，这一点尤其糟糕。应用程序层request（n）语义使使用者可以发信号通知它在每个流上可以接收多少，并允许生产者将多个流交织在一起。 以下是使用TCP并仅依靠其流控制时可能出现的一些问题的更多详细信息： 数据在发送方和接收方通过TCP进行缓冲，这意味着无法了解订户级别的操作。 需要发送较大工作单元（大于TCP发送方或接收方缓冲的发送方）的发送方陷入行为不佳的情况，其中TCP连接将在完整和空循环之间循环，并且极大地未充分利用缓冲（以及吞吐量）。 TCP处理单个发送者/接收者对，而响应流允许多个发送者和/或多个接收者（某种程度上），并且（最重要的是）在传输层将数据接收与应用程序消耗控制分离。应用程序可能希望与从传输中提取数据分开人为地减慢速度或限制处理。 一切都取决于TCP的设计目的（不会超出接收器OS缓冲区空间或网络队列），以及反应式流控制的目的（允许推/拉应用程序工作单元的语义，附加的传播模型和应用程序）控制何时准备更多或不准备）。对于任何实际系统而言，这种明确的关注点分离都是必不可少的。 这说明了为什么每个没有在应用程序级别具有内置流控制的解决方案（除了MQTT，AMQP和STOMP之外几乎都提到了每个解决方案），以及为什么RSocket包含了应用程序级别流量控制是一流的要求。

6 Connection Setup Requirement

This is effectively the same as the HTTP/2 requirement to exchange SETTINGS frames—see: HTTP/2 Spec: HTTP/2 Connection Preface

HTTP/2 Spec: Starting HTTP/2 for “http” URIs

HTTP/2 and RSocket both require a stateful connection with an initial exchange.

7 Transport Layer- 传输层

HTTP/2 requires TCP. RSocket requires TCP, WebSockets or Aeron. We have no intention of this running over HTTP/1.1. We also do not intend on running over HTTP/2 when fronted only by HTTP/1.1 APIs (as browsers expose), though that could be explored and conceptually is possible (with the use of SSE or chunked encoding). If using an HTTP/2 implementation that exposes the underlying byte streams, then HTTP/2 can be used as a transport (and this is in fact done in at least one production use of RSocket).

8 代理

对于HTTP / 2正确运行的代理对于RSocket正确运行。

9 Frame Length

It is optional depending on the transport. On TCP, it will be included. On Aeron or WebSockets it is not needed.

10 State Spanning Connections - 跨状态连接

我们认为这在此协议层是不必要的优化，因为必须使应用程序参与才能使其正常工作。 应用程序维护连接之间的状态。 实现微不足道的收益也非常复杂。 许多分布式系统实现无法正确处理这些类型的问题。 但是，RSocket协议确实为客户端和服务器提供了必要的通信机制，以维护状态并在新的传输连接上重新建立会话。

11 Future-Proofing - 面向未来

无法完全对未来进行验证，但我们已尝试通过以下方式对RSocket进行验证：

• 帧类型具有扩展保留值
• 错误代码具有扩展保留值
• 安装程序具有版本字段
• 所有字段的大小均已根据当前已知的给定要求进行了调整（例如支持4b请求的streamId）
• 有足够的空间放置其他标志
• 数据和元数据分离
• 在安装程序中使用MimeType消除与编码的耦合

此外，我们还停留在HTTP / 2和TCP的面向连接的语义内，因此连接行为不会异常或特殊。 除了这些因素，TCP自1977年以来就已经存在。我们不希望在不久的将来将其淘汰。 QUIC在未来几年内有望成为TCP的合法替代方案。 由于HTTP / 2已经可以在QUIC上运行，因此我们看不出RSocket也不能在QUIC上运行的原因。

12 Prioritization, QoS, OOB - 优先级，QoS，OOB

优先级，QoS，OOB允许使用元数据，应用程序级逻辑和应用程序控制发射。 RSocket不执行排队模型，也不执行发射模型，也不执行处理模型。 为了有效地利用QoS，将需要控制所有方面。 没有应用程序逻辑以及底层网络层的配合，这实际上是不可能的。 这也是为什么HTTP / 2也不进入该区域，而只是提供一种表达意图的原因。 使用元数据，RSocket甚至不需要这样做。

13 Why is cancellation required? - 为什么需要取消？

现代的分布式系统拓扑往往具有多个级别的请求扇出。 这意味着一个请求在一个级别上可能导致数十个请求到达多个后端。 能够取消请求可以节省大量的工作。

14 What are example use cases of cancellation?

假设有一个服务器负责计算Pi的第n位数字。 客户端向该服务器发送了一个请求，但后来又意识到它不再需要/不需要响应（出于任意原因）。 可以让它取消（而不是让服务器徒劳地进行计算）（服务器甚至可能还没有开始工作）。

15 What are example use cases of request-stream? - 请求流的示例用例是什么？

假设有一个聊天服务器； 您想接收聊天服务器中所说的所有消息，但又不想轮询或连续轮询（长轮询技术）。 另一个示例可能是您想收听特定的聊天室而忽略所有其他消息。

16 What are example use cases of fire-and-forget versus request-response?

某些请求不需要响应，只要可以简单地忽略发送响应的任何失败，即发即弃是正确的解决方案。 一个示例可能是在UDP不适当的环境中进行的非关键指标跟踪。

17 为什么是二进制 ？

See HTTP/2 FAQ: Why is HTTP/2 binary?

18 Doesn’t binary encoding make debugging harder? - 二进制编码不会增加调试难度吗？

是的，但是权衡是值得的。

二进制编码使人更难以阅读消息，但对机器而言也更容易阅读。 通过不解码内容，还可以显着提高性能。 因为我们估计机器将读取99.9999999％+的消息，所以我们决定使机器的读取更加容易。 存在用于分析二进制协议交换的现成工具，并且可以容易地编写新工具和扩展来解码二进制RSocket格式并呈现人类可读的文本。

19 What tooling exists for debugging the protocol?

Wireshark is the recommended tool.

The plugin is at https://github.com/rsocket/rsocket-wireshark.

20 Why are these different flow control approaches needed beyond what the transport layer offers?

为什么除了传输层提供的功能以外，还需要这些不同的流控制方法？

TCP流控制旨在根据远程端的使用率来控制来自发送器/读取器的字节率。 使用RSocket，可以在同一传输连接上多路复用流，因此实际上必须在RSocket级别进行流控制。

21 What are example use cases where RSocket flow control helps? - RSocket流控制有哪些示例用例？

流控制可帮助应用程序发信号通知其使用响应的能力。 这确保了我们永远不会在应用程序层上溢出任何队列。 依靠TCP流控制不起作用，因为我们在同一连接上多路复用流。

22 How does RSocket flow control behave?

流量控制有两种类型：

• 一种是由Reactive Streams中定义的request-n语义提供的（请阅读规范以获取详尽的详细信息）。
• 第二个是通过协议文档中定义的租约语义提供的。

23 How does RSocket benefit a client-side load balancer in a data center?

RSocket如何使数据中心的客户端负载均衡器受益？

每个RSocket提供一个可用性编号，抽象地表示其发送流量的能力。 例如，当客户没有有效的租约时，它会显示“ 0.0”的可用性，表明它无法发送任何流量。 这些额外的信息与已经使用的任何负载平衡策略结合在一起，可以为客户端提供更多信息，从而可以做出更明智的决策。

24 Why is multiplexing more efficient? - 为什么多路复用效率更高？

See: HTTP/2 FAQ: Why is HTTP/2 multiplexed?

HTTP/2 FAQ: Why just one TCP connection?

25 Is multiplexing equivalent to pipelining?复用等于流水线吗?

否。流水线化要求按照请求的顺序读取响应。 例如，使用流水线：客户端发送reqA，reqB，reqC。 它必须按以下顺序接收响应：respA，respB，respC。

通过多路复用，同一客户端可以按任何顺序接收响应，例如 respB，respA，respC。 流水线会引入行头阻塞，并降低系统性能。

26 Why is the “TLS False start” strategy useful for establishing a connection?

为什么“ TLS错误启动”策略对建立连接有用？

在遵守租约语义时，在客户端和服务器之间建立RSocket需要一个往返（⇒SETUP，⇐LEASE，⇒REQUEST）。 在网络速度较慢或连接延迟很重要的情况下，这种往返是有害的。 这就是为什么您有可能不遵守租约，然后可以立即发送您的请求（⇒SETUP，⇒REQUEST）。

27 What are example use cases for payload data on the Setup frame? - 设置帧上有效负载数据的示例用例有哪些？

您可能希望在RSocket建立时将数据传递给您的应用程序，而不是在RSocket之上重新实现连接协议。 RSocket允许您在SETUP框架旁边发送信息。 例如，客户端可以使用它来发送其凭据。

28 Why multiple interaction models? - 为什么要使用多种交互模型？

交互模型可以简化为一种：“请求通道”。 每个其他交互模型都是请求通道的子类型，但是由于两个原因，它们被专门化了：

• 从客户端的角度来看，易于使用。
• 性能。

29 So why the “RSocket” name? - 为什么命名为“RSocket”

它以ReactiveSocket开头，但缩短为RSocket：

• 因为写作和说话都比较短
• 停止过度使用“Reactive”一词

也就是说，“ R”仍然是指“ ReactiveSocket”中的“ reactive”，这使我们想到了后续问题：“ Reactive”不是一个完全被炒作的流行词吗？ 不幸的是，这个词已经成为一个流行词，并且被过度使用。 但是，该库与几个项目直接相关，其中“响应式”是其名称和架构模式的重要组成部分。 具体而言，RSocket在这些项目和库中实现，使用或遵循这些原理，因此命名为：

• Reactive Streams

• Reactive Extensions

• RxJava RxJS

• Reactive Manifesto