在本文中，我们将讨论 SIDN Labs 提出的向可扩展配置协议 (EPP)添加基于REST的API的提议。除了让注册商更轻松地使用 EPP 之外，此类 API 还可以通过提高可扩展性以及提高性能和安全性来帮助域名注册机构。
由于 RESTful EPP 是无状态的，因此也更适合现代软件工程技术，例如容器化和 Kubernetes。我们正在与其他欧洲注册机构合作，在互联网工程任务组 (IETF) 上对 RESTful EPP 进行标准化——这是我们在 2012 年就尝试过的事情（不是笔误
）。
什么是 EPP？
EPP 是一种基于 XML 的协议，用于在创建和更新域名等流程的背景下管理注册中心内的域名对象。它是一种 IETF 标准化协议，已经存在了大约 15 年。EPP 的推出是为了让注册中心拥有一个标准化、统一的注册中心访问界面。这对于许多向客户提供不同顶级域名 (TLD) 下的域名的注册中心来说非常重要，因为他们不必为每个注册中心单独设置一个客户，从而避免复杂性和成本。
作为 .nl 域名的注册机构，SIDN 自 2010 年起支持 EPP。EPP 协议的核心定义在RFC 5730中。此外，还有针对域名对象、主机对象和联系对象的附加规范。
EPP存在哪些问题？
越来越多的注册中心正在采用 Kubernetes 等新的软件工程技术，这些技术在自己的场所或私有云或公共云环境中运行。在这样的环境中，基于 REST 的无状态服务很常见。然而，EPP 被认为是一种有状态 协议，因为它早于新软件技术和基于 REST 的服务的兴起。作为有状态协议，EPP 使用“会话”概念，EPP 服务器记录有关客户端的信息，例如执行的命令和连接状态。
状态协议的缺点是，它使开发能够快速处理大量 EPP 消息的可扩展系统变得复杂。原因是注册中心的 EPP 系统必须确保每个 EPP 连接都由一个特定服务器专门管理，以便可以监控连接的状态。
这反过来又影响了 EPP 请求在可用服务器容量中的有效分配。因此，一台服务器有时必须在给定连接上每分钟接收和处理数千个 EPP 请求。然后服务器面临超载的危险，对注册商和注册人产生不利影响，例如请求执行延迟、请求超时和服务器不稳定，从而降低整个 EPP 服务的可用性。
对于注册中心来说，决定将哪些服务器资源分配给哪些 EPP 请求类型也变得更加困难，例如，如何确保最重要的请求类型能够得到最快速的处理。
RESTful EPP 有哪些优势？
我们认为RESTful EPP (REPP)是解决上述问题的一种可能方法，也是实现用户友好、可扩展的 EPP 服务的一种手段。我们建议尽可能重复使用现有的 EPP 标准，并结合RESTful 架构风格。因此，REPP 应被视为 EPP 和 REST 功能的混合体，而不仅仅是透明地中继 EPP 消息的 EPP 传输层。
与 EPP 不同，REPP 是一种无状态协议。服务器上不保存有关客户端或连接的任何信息。每个 REPP 请求都是独立的，独立于任何先前的请求，这意味着它必须包含服务器成功执行所需的所有信息，例如客户端身份验证信息。
借助 REPP，注册中心拥有更大的负载平衡范围。请求可以有效地分布在可用的服务器容量中，因为 REPP 的无状态设计意味着任何服务器都可以处理给定的请求（与 EPP 的情况相反）。
REPP 还可以区分不同类型的交易。例如，“检查”和“信息”请求可以与其他流量（例如“创建”和“更新”交易）分开处理（见图 1）。
注册机构通常会收到比新域名“创建”请求等更多的信息请求（“检查”和“信息”请求）。在单独的基础设施上处理信息请求将使注册机构能够做更多的事情，以确保处理其他事务的服务器的可用性和性能。
REPP 也会使注册商受益。由于 REPP 提供无状态、基于 HTTP 的接口，因此与 REST API 的集成更容易且更便宜。相比之下，像 EPP 这样的有状态 TCP 套接字协议要求程序员使用低级套接字 API。我们还在努力支持其他数据格式，例如JSON，以方便在现代 Web API 中使用。
本站全部资讯来源于实验室原创、合作机构投稿及网友汇集投稿，仅代表个人观点，不作为任何依据，转载联系作者并注明出处：https://www.lvsky.net/145.html
评论