作者：Tsahi Levent-Levi（原文链接）
翻译：刘通
原标题：You Better Ignore the Default Protocol Ports You Implement
前文链接：你最好在你的实现中忽略默认协议端口（一）
以下是我查到的几个知名服务是如何正确执行操作的：
Hangouts Meet
或者叫做Google Hangouts。或者Google Meet。
点击图片以跳转链接
Google Meet使用STUN:19302，其中包含5个不同的服务器子域名。这里没有TURN，因为该服务直接从媒体服务器使用ICE-TCP。
使用19302这个选择很奇怪。我不知道为什么选用这个数字，也不知道为什么它很有趣。
Google AppRTC
你可能会认为Google展示WebRTC将是一个坚实的STUN / TURN配置的模范公民。但是它是这么做的：
点击图片以跳转链接
它将TURN / UDP配置在端口19305上，TURN / TCP在端口443上，以及STUN在端口19302上。与其他的应用不同，它有明确的IPv6地址。它没有TURN / TLS。
Jitsi Meet
点击图片以跳转链接
Jitsi展示了STUN和TURN的多个地点—中欧，西欧使用STUN:443，TURN / UDP:443和TURN / TCP:443。没有TURN/TLS。
appear.in
点击图片以跳转链接
appear.in使用了TURN/UDP:443，TURN/TCP:443以及TURN/TLS:443。STUN在这里通过使用TURN而隐秘的实现。
Facebook Messenger
点击图片以跳转链接
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：
他们解释了如何将MQTT用作WebRTC信令的Messenger后端的一部分（并且我猜测他们通过Messenger发送的所有其他消息）。
MQTT可以运行在监听端口1883的TCP上以及端口8883上的TLS上运行。但是当你查看AWS IOT的AWS文档时，你会发现：
完全没有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上了。这可能是互联网上最重要的端口。
