设计选择 这些实现最初是由加密货币服务器应用（例如 [rippled](https://github.com/ripple/rippled)）的业务需求驱动的，使用 C++ 编写。由于现有方案无法满足这些需求，因此从零开始编写了 Beast 作为解决方案。Beast 的设计哲学避免了其他库所表现出的缺陷： * 不要试图包揽过多功能。 * 绝不牺牲性能。 * 模仿 Asio；熟悉感带来信心。 * 角色对称的接口；客户端与服务端一致（或高度相似）。 * 将重要决策权（如内存分配或 Beast 采用了 NetTS 中提出的 DynamicBuffer 概念，并高度依赖 ConstBufferSequence 和 MutableBufferSequence 概念来向函数传递缓冲区。作者发现，动态缓冲区和缓冲区序列接口不仅非常适合与 Asio 交互，也非常适合其他任务，例如对缓冲区中的数据进行增量解析（比如解析存储在 [link beast.ref.boost__beast__static_buffer `static_buffer`] 中的 WebSocket 帧）。 在开发 Beast 的过程中，作者研究了其他软件包，特别是针对其他提供类似功能的软件包在 Boost 审查过程中留下的评论。在本节以及随后的常见问题解答（FAQs）中，我们将尝试回答那些同样适用于 Beast 的问题。 对于 HTTP，我们对消息进行建模，以最大限度地提高实现策略的灵活性，同时允许使用诸如 [*`read`] 和 [*`write`] 等熟悉的动词。HTTP 接口的设计还进一步受 WebSocket 模块需求的驱动，因为 WebSocket 会话在开始时需要一次 HTTP 升级握手交换。其他设计目标： * 保持简单。 * 保持底层；不要重新发明一整套 Web 服务器或客户端。 * 允许用户根据需要进行自定义。 以下视频演示是在 2016 年的 [@https://cppcon.org/ CppCon] 上发表的。它简要介绍了 Beast 的一些早期接口（这些接口此后已发生变化）。