你最好在你的实现中忽略默认协议端口(一)

作者:Tsahi Levent-Levi(原文链接

翻译:刘通

原标题:You Better Ignore the Default Protocol Ports You Implement

 

默认的协议端口是非常好,但在现实世界中运行的协议端口需要做的更好。

ports1

如果你想正确地做某件事情,你可能应该忽略你经常会使用的协议规范。当我多年前直接实现协议时,出现了这种想法—你需要以最严格的格式发送消息,但在如何接受消息的方面可以做的非常宽松。其背后的原因是,通过严格的发送端,你将获得更高的互操作性(更多的设备将能够“解译”你发送的内容),并且在接收端相对宽容,你也能达到相同的目标(能够理解来自更多设备的消息)。但是这么做在这里不值得,需要更聪明地行事。

这同样适用于默认协议端口。

假设我们有一个需要使用端口号5349的理论协议。你需要设置服务器,将其配置为在该端口上监听(毕竟我们希望符合标准),然后运行你的服务。

这会对你有好处吗?

ports2

对于大部分情况,如上图所示,是的对你有好处。

该协议可能是基于客户端—服务器的。某个位于其专用网络内部的客户端正在访问Internet,将服务器的公共IP转到该特定端口并链接。看上去生活还是很美好对吧?

只可惜有时候并不是这样。

ports3

嗯……现在发生了什么?IT部门中有人决定阻止输出到5349端口的流量。或者也可能他决定只为端口80和端口443打开输出流量。他为什么要这么做呢?因为这是HTTP和HTTPS流量的来源,也就是我们的浏览器连接到Web服务器的端口。比如说我在写这篇文章的时候就需要进行这样一个连接(我需要在文档中写完,然后将其复制到WordPress上)。

因此,我们的服务器决定使用默认端口5349,那么具有相同要求的相同使用场景将会无法正常工作。

如果我们决定将它通过443端口怎么办?

ports4

现在它正常工作的机会加大了?为什么呢?因为端口443是为加密的TLS流量保留的。这意味着除了数据的目的地之外,我们正在处理的防火墙无法知道发送的内容或地点,所以他通常会将其视为“HTTPS”类型的流量,并且只会传递给它。

这里有警告。如果企业正在执行一个本地可信的Web代理,它实际上是一个中间人,并打开所有的数据包,这意味着他现在看到了数据,并可能决定不继续传递它,因为它并不能理解这些数据。

我们的目标是最好的覆盖面。而且端口443将让我们实现这个目标。它可能会被屏蔽,但是发生的几率很小。

这里有几个例子,来建议你忽略协议默认端口:

TURN

WebRTC(和其他协议)使用TURN来让你的媒体会话能够连接,以防你无法端到端的进行直接发送。它充当的是媒体的中继,位于公共互联网中,唯一目的是在NAT中打孔穿透,并且穿越防火墙

TURN通过UDP,TCP和TLS运行。而且是的,你需要在UDP,TCP和TLS上配置和运行它(不要懒,要把它们全部都配置好,不会花费你很多精力)。

你的STUN和TURN服务器的默认端口是(你很可能会在同一个进程中部署它们):

         # 用于STUN的3478(通过UDP)

         # 用于TURN的3478(通过UDP)—与STUN一样

         # 用于TURN的3478(通过TCP)—与通过UDP的STUN和TURN一样

         # 用于TURN的5349(通过TLS)

看到上面列出的这些会想到一些事情:

         1. 我们针对UDP和TCP监听同一个端口,以及针对STUN和TURN—这样很好

         2. 还记得我在上文中提到的故事里的端口5349吗?

是这样的。如果你只部署STUN,那么许多WebRTC会话都无法建立起连接。如果你也同时使用TURN / UDP进行部署,则某些会话仍然无法建立连接(主要是因为IT管理员完全阻止了UDP)。TURN / TCP也有可能无法连接。而且,5349上的TURN / TLS仍然可以被阻止。

那在这些情况下开发人员需要做些什么呢?

只需要让你WebRTC设备指向端口443,即可完成所有STUN / TURN流量并完成此操作。与使用默认端口进行部署和所有可能的优势相比,这种方法没有什么实际的缺点。

 

未完待续。

填写常用邮箱,接收社区更新

WebRTC 中文社区由

运营