0

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

翻译:刘通

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

前文链接:你最好在你的实现中忽略默认协议端口(一)

 

以下是我查到的几个知名服务是如何正确执行操作的:

Hangouts Meet

或者叫做Google Hangouts。或者Google Meet。

code1

点击图片以跳转链接

Google Meet使用STUN:19302,其中包含5个不同的服务器子域名。这里没有TURN,因为该服务直接从媒体服务器使用ICE-TCP。

使用19302这个选择很奇怪。我不知道为什么选用这个数字,也不知道为什么它很有趣。

Google AppRTC

你可能会认为Google展示WebRTC将是一个坚实的STUN / TURN配置的模范公民。但是它是这么做的:

code2

点击图片以跳转链接

它将TURN / UDP配置在端口19305上,TURN / TCP在端口443上,以及STUN在端口19302上。与其他的应用不同,它有明确的IPv6地址。它没有TURN / TLS。

Jitsi Meet

code3

点击图片以跳转链接

Jitsi展示了STUN和TURN的多个地点—中欧,西欧使用STUN:443,TURN / UDP:443和TURN / TCP:443。没有TURN/TLS。

appear.in

code4

点击图片以跳转链接

appear.in使用了TURN/UDP:443,TURN/TCP:443以及TURN/TLS:443。STUN在这里通过使用TURN而隐秘的实现。

Facebook Messenger

code5

点击图片以跳转链接

Messenger使用端口3478用于STUN,UDP上的TURN在端口40002上,TCP上的TURN在端口3478上。它也在端口443上使用TCP上的TURN。Messenger没有使用TURN/TLS。

下面是我所学到的:

         # 人们在其部署中不使用默认的STUN/TURN端口

         # 即使他们没有使用有意义的端口(443),他们也可能不会使用默认端口(参考Google Meet)

         # 虽然是STUN/TURN看似简单的事情,但是最后每个人都会以不同的方式实现它

MQTT

我们已经探讨了NAT穿透以及STUN和TURN服务器。但是一些信令协议呢?当我想到其他示例时,首先想到的就是MQTT

MQTT是一种用于IOT和M2M空间的消息传递协议。其他人也会使用它—比如Facebook:

ports21

他们解释了如何将MQTT用作WebRTC信令的Messenger后端的一部分(并且我猜测他们通过Messenger发送的所有其他消息)。

MQTT可以运行在监听端口1883的TCP上以及端口8883上的TLS上运行。但是当你查看AWS IOT的AWS文档时,你会发现:

ports22

完全没有1883端口,而且现在如果需要的话可以直接使用端口443.

知道他们的移动应用Facebook Messenger是否在端口443或8883上使用MQTT会很有趣—如果它使用端口443,是通过TLS的MQTT还是通过WebSocket的MQTT。

SIP

SIP是最常见的VoIP信令协议。我记不太清关于SIP的细节了,所以我查了维基百科上的解释:

SIP客户端通常在端口号5060或5061上使用TCP或UDP传输到服务器和其他端点的SIP流量。端口5060通常用于未加密的信令流量,而端口5061通常用于通过传输层安全性(TLS)加密的流量。

端口5060用于UDP和TCP通信。端口5061用于TLS流量。

然后我问了一位知道SIP的朋友。他直接回答:443。

他记得5060是UDP,5061是TCP,443是TLS。

当你要部署一个产品SIP网络时,可以将服务器配置为通过端口443在TLS上执行SIP。

下一步

如果你正在查看协议实现,并且碰巧看到一些需要的默认端口,请问问自己是否使用他们以符合你的最佳利益。要通过沿途的防火墙和其他恶意设备,你可能需要考虑使用其他端口。

当你处于这种状态时,如果可能的话,我会尽量避免发送明确的内容,并在连接上选择TLS,这样我们就可以回到端口443上了。这可能是互联网上最重要的端口。





加入WebRTC技术交流群,免费获得学习资料,交流经验
群号:659922087
q群
期待你一针见血的评论,Come on!

不用想啦,马上 "登录"  发表自已的想法.