我发誓我用Google搜索了这个。我想知道是否有任何方法可以通过解析SRV DNS查询来连接到WebSocket服务。原则上，这对我来说听起来很合理，例如，在服务将要监听的端口取决于主机并且没有固定端口的情况下。
例如： 服务器A在端口1234上侦听WebSocket。 服务器B在端口1235上侦听WebSocket。
服务器NS为A分配CNAME，向{B}分配CNAME。它还会添加一个SRV条目，指向A和B＆＃39; { {1}} s，并指向每个端口。
连接时，用户应该连接到CNAME而不是srvws://websockethost。
甚至可以做这样的事吗？这有什么计划吗？有没有其他方法可以解决这类问题，我需要将端口与DNS查询进行通信？
更新：环顾四周我找到了这个草稿：https://tools.ietf.org/html/draft-ibc-websocket-dns-srv-02
但我不确定如何解释这一点。这是标准吗？这甚至被批准了吗？这只是一个提案吗？
答案 0 :(得分：1)
在RFC 2782 A DNS RR for specifying the location of services (DNS SRV)中声明
目前，必须要知道服务器的确切地址 联系它，或者播出一个问题。
SRV RR允许管理员为一个服务器使用多个服务器 域，将服务从主机移动到主机，并没有那么大惊小怪 将某些主机指定为服务的主服务器，将其他主机指定为 备份
SRV RR的格式是
_Service._Proto.Name TTL类SRV优先权重端口目标
没有技术原因您无法使用SRV记录指向WS。正如你所指出的那样，它一直是IETF草案的主题。这似乎没有进一步发展，虽然原因并不清楚history它似乎已经与RFC 6455合并The WebSocket Protocol有一个{{3}关于包含具有以下
的IETF草案discussion对于很多人来说，SRV将是一个完美的选择 [...]管理员和用户完全可选 透视。网站所有者可以决定是否使用SRV。该 当然，只有requeriment，WS客户支持它
因此，虽然没有技术规范，但肯定没有理由不能做到/不应该做。这个想法已被提出并被允许死亡，因为如果您想使用SRV记录来查找完全在协议内的WS服务，最终由您决定。
在我看来，它可以解决许多问题。
已编辑添加
在IETF留言板上进行了一些挖掘。 （好奇心为什么它没有被实施得更好我）我发现DNS SRV Resource Records for the WebSocket Protocol来自提出它的人
我提出了这个建议，但是经过长期讨论后，我才进行了讨论 明白在WS客户端强制DNS SRV会破坏太多 HTTP世界中的假设（通常只能在HTTP层之上看到） 而不是在下面）。
HTTP代理的存在也是一个很大的障碍 应升级/修改代理以执行DNS SRV 如果HTTP请求是WebSocket握手，则解析只是。 最后一个论点足以不强制要求SRV解决。
因此，虽然这听起来不错，但真正了解这些内容（并为其编写标准）的人发现了一些问题，这些问题建议只使用标准的HTTP / A记录查找。