为何重要：不符合安全规范，无法通过安全审核。多端口更容易被攻击，如果出现安全事故，比一台服务不可用还要严重，这也是为何 WebRTC 正在做 E2E（端到端）加密的原因。
有些用户在企业防火墙后面，访问公网时不能访问任意端口，必须收敛到某些 IP 和端口。如果不支持端口复用，就无法在这些企业场景下使用。
端口本质上是一种状态，它是一种对用户的标示，比如 IP+ 端口就可以认为是某个客户端。这也给服务迁移带来问题，需要迁移更多的状态。
现状和未来：云原生的标准做法，是通过 SLB/Service 隐藏服务，流量通过 SLB 转发到真实的 Pod 服务器。SRS 已经支持了这种方式。
线上还有移动端切网问题，会影响 SLB 定位客户端。SRS 目前使用 ICE 的 PingPong 标示客户端，未来和更好的做法是用 QUIC，QUIC 协议本身考虑了会话的标示，在 SLB 层就可以解决问题。
GRTN (Tenfold) 还支持了 TURN 协议的 SLB 转发。未来还需要解决在边缘云中的端口复用问题，和中心云不同，边缘云可能是分运营商的，客户端切网后需要更换 IP 入口。
流多且关联，负载均衡难流多且有关联，还有切网问题：直播的流之间没有关联性，可以在服务器负载高时调度新的会话到其他服务器，而 RTC 流之间有关联性，有时候不能随意调度，导致负载均衡很难做。
问题：流有关联性，服务的会话数不变，负载可能会突增。流的关联性，码率的波动，以及 QoS 算法的动态变化，导致水位评估不准，会话数目不增加时，消耗的 CPU 和带宽都不同。
为何重要：水位如果无法精确评估，就只能预留较多资源，保持较低的水位运行，避免水位突增，服务器被打爆。保持较低水位导致整体成本高。
现状和未来：SRS 还没有解决这个问题，正在做 QUIC 级联，未来会考虑给出服务器的水位，但不会做流量调度和负载均衡，这个是系统要做的。
GRTN (Tenfold) 已经支持多级级联，跨区域级联，有粗略的水位评估。正在做精确的水位评估，未来会考虑做流量均衡。
SRS 云原生总结来说，云原生解决的都是脏活累活，而且还是干不完的脏活累活。云原生往前走了一大步，让基础设施可以不断的标准化发展，应用只要遵守云原生的规范，就可以在多个云上悠然自得。
视频的门槛真的非常非常非常的高，还记得十一年前刚开始接触 Flash 和 FFmpeg，仅仅各种概念和协议，就让人一头雾水。SRS 希望能让视频的门槛不断降低，保持易用性让开发者少一些焦虑和压力，保持浓密的头发。
但，这不是 RTC 服务的全部挑战。生生不息，填坑不止，后端服务就没有做完的那一天。
「视频云技术」你最值得关注的音视频技术公众号，每周推送来自阿里云一线的实践技术文章，在这里与音视频领域一流工程师交流切磋。