配置含TURNS的ICE服务器列表后，为何严格防火墙用户仍无法使用WebRTC？

• ICE候选优先级的默认逻辑阻碍了TURNS的尝试
  ICE协议会按预设优先级依次尝试候选地址，默认情况下UDP类型的候选（STUN、UDP-TURN）优先级远高于TCP/TLS类型的候选。严格防火墙环境下，UDP和普通TCP连接都被阻断，但ICE在轮到TURNS候选之前，可能已经因为前面的候选多次连接失败而直接判定连接终止，根本没机会尝试TURNS地址。

• 未手动调整TURNS候选的优先级
  ICE对RELAY类型候选的默认排序是：UDP传输 > TCP传输 > TLS加密的TCP传输（TURNS）。如果没有手动将TURNS候选的优先级设为最高，严格防火墙用户的设备会先反复尝试那些无法成功的低优先级候选，耗尽重试次数后就放弃了，不会再尝试有效的TURNS选项。

• 浏览器/设备的ICE实现存在差异
  不同浏览器、设备对ICE候选列表的处理逻辑有区别，部分浏览器在遇到多个RELAY候选时，不会逐一尝试所有选项，而是在前面几个候选失败后就停止连接流程，导致TURNS候选根本没被触发尝试。

• 多候选场景下TURNS服务器的性能问题
  当ICE列表包含多种候选时，大量用户同时发起不同类型的连接请求，可能导致TURNS服务器的TLS握手队列拥堵，响应延迟增加。严格防火墙用户的设备本身网络限制多，超时阈值更短，等不到TURNS服务器的响应就判定连接失败，而单独使用TURNS时服务器负载低，握手速度快就能成功。

内容的提问来源于stack exchange，提问作者Saul Good