作者：Tsahi Levent-Levi（原文链接）
翻译：刘通
原标题：You Better Ignore the Default Protocol Ports You Implement
默认的协议端口是非常好，但在现实世界中运行的协议端口需要做的更好。
如果你想正确地做某件事情，你可能应该忽略你经常会使用的协议规范。当我多年前直接实现协议时，出现了这种想法—你需要以最严格的格式发送消息，但在如何接受消息的方面可以做的非常宽松。其背后的原因是，通过严格的发送端，你将获得更高的互操作性（更多的设备将能够“解译”你发送的内容），并且在接收端相对宽容，你也能达到相同的目标（能够理解来自更多设备的消息）。但是这么做在这里不值得，需要更聪明地行事。
这同样适用于默认协议端口。
假设我们有一个需要使用端口号5349的理论协议。你需要设置服务器，将其配置为在该端口上监听（毕竟我们希望符合标准），然后运行你的服务。
这会对你有好处吗？
对于大部分情况，如上图所示，是的对你有好处。
该协议可能是基于客户端—服务器的。某个位于其专用网络内部的客户端正在访问Internet，将服务器的公共IP转到该特定端口并链接。看上去生活还是很美好对吧？
只可惜有时候并不是这样。
嗯……现在发生了什么？IT部门中有人决定阻止输出到5349端口的流量。或者也可能他决定只为端口80和端口443打开输出流量。他为什么要这么做呢？因为这是HTTP和HTTPS流量的来源，也就是我们的浏览器连接到Web服务器的端口。比如说我在写这篇文章的时候就需要进行这样一个连接（我需要在文档中写完，然后将其复制到WordPress上）。
因此，我们的服务器决定使用默认端口5349，那么具有相同要求的相同使用场景将会无法正常工作。
如果我们决定将它通过443端口怎么办？
现在它正常工作的机会加大了？为什么呢？因为端口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流量并完成此操作。与使用默认端口进行部署和所有可能的优势相比，这种方法没有什么实际的缺点。
未完待续。
