0

我发誓我用谷歌搜索了这个。我想知道是否有任何方法可以通过解析SRVDNS 查询来连接到 WebSocket 服务。原则上，这对我来说听起来很合理，例如，在服务将要监听的端口取决于主机并且没有固定端口的情况下。

例如：服务器 A 使用端口 1234 上的 WebSocket 进行侦听。服务器 B 使用端口 1235 上的 WebSocket 进行侦听。

服务器 NS 将 a 分配CNAME给 A，将 a 分配CNAME给 B。它还添加了一个SRV指向 A 和 B 的条目CNAME，并且还指向每个端口。

连接时，用户应该连接到类似srvws://websockethost而不是ws://aorbcname:aorbport.

甚至有可能做这样的事情吗？是否有任何计划？有没有其他方法可以解决这种问题，我需要与 DNS 查询一起通信端口？

更新：环顾四周，我发现了这个草稿：https ://datatracker.ietf.org/doc/html/draft-ibc-websocket-dns-srv-02

但我不确定如何解释这一点。这是一个标准吗？这甚至被批准了吗？这只是一个提议吗？

4

1 回答 1

1

在 RFC 2782中，用于指定服务位置 (DNS SRV) 的 DNS RR声明

目前，要么必须知道服务器的确切地址才能联系它，要么广播问题。

SRV RR 允许管理员为单个域使用多个服务器，轻松地将服务从一个主机移动到另一个主机，并指定一些主机作为服务的主服务器，而将其他主机指定为备份。

SRV RR 的格式是

_Service._Proto.Name TTL Class SRV Priority Weight Port Target

没有技术原因不能使用 SRV 记录指向 WS。正如您所指出的，它一直是 IETF 草案的主题。这似乎没有更进一步，尽管其历史原因尚不清楚，但它似乎已与RFC 6455 WebSocket协议合并具有以下内容的WebSocket 协议

SRV 将是许多人的完美选择 [...] 从管理员和用户的角度来看，它是完全可选的。网站所有者可以决定是否使用 SRV。当然，唯一的要求是 WS 客户端支持它的操作系统

因此，虽然没有技术规范，但肯定没有理由不能/不应该。这个想法已经被提出并被允许消亡，因为最终取决于您是否要使用 SRV 记录来查找完全符合协议的 WS 服务。

在我看来，它将解决许多问题。

编辑添加

在 IETF 留言板上进行了更多挖掘之后。（对为什么它没有实施的好奇心让我变得更好）我从提出它的人那里找到了这条消息

我提出了它，但是在邮件列表中经过长时间的讨论后，我了解到在 WS 客户端中强制使用 DNS SRV 会破坏 HTTP 世界中的太多假设（通常只看到 HTTP 层之上而不是之下）。

HTTP 代理的存在也是一个很大的障碍，因为应该升级/修改这些代理以执行 DNS SRV 解析，以防万一 HTTP 请求是 WebSocket 握手。最后一个论点足以不强制要求解决 SRV。

因此，虽然这听起来是个好主意，但真正了解这些东西（并为其编写标准）的人发现了一些建议仅使用标准 HTTP / A 记录查找的问题。

于 2016-02-03T08:14:52.457 回答