有没有办法让 websocket 可以通过 SRV DNS 记录访问？
Is there a way to make a websocket reachable through a SRV DNS record?
我发誓我用谷歌搜索了这个。我想知道是否有任何方法可以通过解析 SRV DNS 查询来连接到 WebSocket 服务。原则上，这对我来说听起来很合理，例如，在服务将要监听的端口取决于主机并且没有固定端口的情况下。
例如：
服务器 A 在端口 1234 上使用 WebSocket 进行侦听。
服务器 B 在端口 1235 上使用 WebSocket 进行侦听。
服务器 NS 分配一个 CNAME 给 A，一个 CNAME 给 B。它还添加一个 SRV 条目指向 A 和 B 的 CNAMEs，并且还指向每个端口。
连接时，用户应该连接到 srvws://websockethost 而不是 ws://aorbcname:aorbport。
有可能做这样的事吗？有没有这方面的计划？有没有其他方法可以解决这类问题，我需要在 DNS 查询的同时通信端口？
更新：环顾四周，我发现了这个草稿：https://datatracker.ietf.org/doc/html/draft-ibc-websocket-dns-srv-02
但我不太确定如何解释这一点。这是一个标准吗？这甚至被批准了吗？这只是一个提议吗？
在 RFC 2782 A DNS RR for specifying the location of services (DNS SRV) 中指出
Currently, one must either know the exact address of a server to
contact it, or broadcast a question.
The SRV RR allows administrators to use several servers for a single
domain, to move services from host to host with little fuss, and to
designate some hosts as primary servers for a service and others as
backups.
SRV RR 的格式是
_Service._Proto.Name TTL Class SRV Priority Weight Port Target
没有技术原因不能使用 SRV 记录指向 WS。正如您指出的那样，它已成为 IETF 草案的主题。这似乎没有进一步发展，尽管其 history it does appear to have been merged with RFC 6455 The WebSocket Protocol There is a discussion concerning the inclusion of IETF draft DNS SRV Resource Records for the WebSocket Protocol 的原因尚不清楚
SRV would be a perfect choice for many people
[...] It would be fully optional from the admin and user
perspective. The website owner could decide to use SRV or not. The
only requeriment, of course, os that WS clients support it
因此，虽然没有技术规范，但您肯定没有理由不能/不应该这样做。这个想法已被提出并被允许死亡，因为最终取决于您是否要使用 SRV 记录来查找完全符合协议的 WS 服务。
而且在我看来，它会解决很多问题。
编辑添加
在 IETF 留言板上进一步挖掘之后。 （对为什么它没有实现的好奇战胜了我）我从提出它的人那里找到了 this message
I was proposing it, but after long discussions in the maillist I've
understood that mandating DNS SRV in WS clients would break too much
assumptions in HTTP world (which commonly just sees above HTTP layer
and not below).
The existence of HTTP proxies is also a big handicap since those
proxies should be upgraded/modified in order to perform DNS SRV
resolution just in case the HTTP request is a WebSocket handshake.
This last argument is enough to not mandate SRV resolution.
所以虽然这听起来是个好主意，但真正理解这些东西（并为它编写标准）的人发现了一些建议简单地使用标准 HTTP/A 记录查找的问题。
我发誓我用谷歌搜索了这个。我想知道是否有任何方法可以通过解析 SRV DNS 查询来连接到 WebSocket 服务。原则上，这对我来说听起来很合理，例如，在服务将要监听的端口取决于主机并且没有固定端口的情况下。
例如： 服务器 A 在端口 1234 上使用 WebSocket 进行侦听。 服务器 B 在端口 1235 上使用 WebSocket 进行侦听。
服务器 NS 分配一个 CNAME 给 A，一个 CNAME 给 B。它还添加一个 SRV 条目指向 A 和 B 的 CNAMEs，并且还指向每个端口。
连接时，用户应该连接到 srvws://websockethost 而不是 ws://aorbcname:aorbport。
有可能做这样的事吗？有没有这方面的计划？有没有其他方法可以解决这类问题，我需要在 DNS 查询的同时通信端口？
更新：环顾四周，我发现了这个草稿：https://datatracker.ietf.org/doc/html/draft-ibc-websocket-dns-srv-02
但我不太确定如何解释这一点。这是一个标准吗？这甚至被批准了吗？这只是一个提议吗？
在 RFC 2782 A DNS RR for specifying the location of services (DNS SRV) 中指出
Currently, one must either know the exact address of a server to contact it, or broadcast a question.
The SRV RR allows administrators to use several servers for a single domain, to move services from host to host with little fuss, and to designate some hosts as primary servers for a service and others as backups.
SRV RR 的格式是
_Service._Proto.Name TTL Class SRV Priority Weight Port Target
没有技术原因不能使用 SRV 记录指向 WS。正如您指出的那样，它已成为 IETF 草案的主题。这似乎没有进一步发展，尽管其 history it does appear to have been merged with RFC 6455 The WebSocket Protocol There is a discussion concerning the inclusion of IETF draft DNS SRV Resource Records for the WebSocket Protocol 的原因尚不清楚
SRV would be a perfect choice for many people [...] It would be fully optional from the admin and user perspective. The website owner could decide to use SRV or not. The only requeriment, of course, os that WS clients support it
因此，虽然没有技术规范，但您肯定没有理由不能/不应该这样做。这个想法已被提出并被允许死亡，因为最终取决于您是否要使用 SRV 记录来查找完全符合协议的 WS 服务。
而且在我看来，它会解决很多问题。
编辑添加
在 IETF 留言板上进一步挖掘之后。 （对为什么它没有实现的好奇战胜了我）我从提出它的人那里找到了 this message
I was proposing it, but after long discussions in the maillist I've understood that mandating DNS SRV in WS clients would break too much assumptions in HTTP world (which commonly just sees above HTTP layer and not below).
The existence of HTTP proxies is also a big handicap since those proxies should be upgraded/modified in order to perform DNS SRV resolution just in case the HTTP request is a WebSocket handshake. This last argument is enough to not mandate SRV resolution.
所以虽然这听起来是个好主意，但真正理解这些东西（并为它编写标准）的人发现了一些建议简单地使用标准 HTTP/A 记录查找的问题。