我的世界ICE服务器？

【ICE服务器事件辟谣】最近闹的沸沸扬扬的《我的世界》ICE服务器被炸的事情，想必大家也都听说了。网上纷纷乱乱各种谣言不断，如今这件事ICE官方已经辟谣了，希望大家可以理性看待此事！

① ICE服务器只开了不到两个月，造成的财产损失有限；

② 传闻服务器亏损18W并不存在；

③ 某音个别人恶意炒作、恶意引战，其目的大家都明白；

④ 没有人被起诉，这是谣言；

⑤ 服务器被炸是事实，目前管理员尽力在重建服务器；

最后，ICE官方已经表示，事已至此追究谁炸的毫无意义，也希望大家理性看待，不要盲目跟风。

——百度创作者 我叫Minecraft

端点的格式如下所

示： protocol option。所支持的协议有tcp、udp、ssl，以及

default。如果使用了default，它会被Ice.Default.Protocol 属性的值替

代。如果端点的格式有问题，或者指定了未知的协议，应用会收到

Ice::EndpointParseException。

只有安装了IceSSL 插件，才能使用ssl 协议。

各个协议及其所支持的选项将在下面描述。

TCP 端点纲要tcp -h host -p port -t timeout -z描述tcp 端点支持以下选项：

选项描述客户语义服务器语义

-h host 指定端点的主机名

或IP 地址。如果

没有指定，将使用

Ice.Default.Host 的值。

确定要连接到的主

机名或IP 地址。

确定对象适配器用

于侦听连接的网络

接口，以及在适配

器所创建的代理中

向外公布的主机名。

-p port 指定端点的端口号。

确定要连接到的端

口( 必须指定)。

如果没有指定这个

选项，或是port 为

零，端口将由操作系统选择。

932 代理与端点

课程地址：零声学院 WebRTC入门与提高 https://ke.qq.com/course/435382?tuin=137bb271

技术支持QQ群：782508536

更多音视频知识请点击： 专注音视频开发

交互式连接建立是一种标准穿透协议，利用Stun和Turn服务器来帮助端点建立连接。市面上已有不少介绍ICE的资料，像《WebRTC权威指南(第三版)》中的“9.2 交互式连接建立”。但看了那些后，有人还是不能理解，这里试着用一个实例来描述整个过程。ICE协议只是制定规范，没规定怎么实现细节，在细节实现上这里参考Google的WebRTC。

上图就是《WebRTC权威指南(第三版)》中的图9.1。呼叫要交换两种信息，一是候选地址，二是媒体信息。候选地址用于建立网络连接，它存储着和网络连接相关的参数。媒体信息（SDP）用于描述要在对等连接上传输的数据，包括音频、视频和数据。用路和车来比喻的话，候选地址用于造路，媒体信息于用指定要跑什么车。

在图中，双方是串行处理媒体、候选地址，但实际中是并发的。举个例子，主叫收到Answer后，它仍可能在收集候选地址，然后通过信令服务器发向被叫。

除了主叫必须创建Offer才开始收集候选地址、被叫必须创建Answer才开始收集候选地址外，ICE代理是相互独立地处理媒体和候选地址。 （这结论细节参考底下的“四：选定候选地址，并启动媒体”）。

和“9.2 交互式连接建立”一样， 这里也把ICE分为六个步骤。下图是例子使用的网络拓扑结构。

<ignore_js_op style="word-wrap: break-wordcolor: rgb(68, 68, 68)font-family: Tahoma, Helvetica, SimSun, sans-seriffont-size: 14pxfont-style: normalfont-variant-ligatures: normalfont-variant-caps: normalfont-weight: normalletter-spacing: normalorphans: 2text-align: starttext-indent: 0pxtext-transform: nonewhite-space: normalwidows: 2word-spacing: 0px-webkit-text-stroke-width: 0pxbackground-color: rgb(255, 255, 255)text-decoration-style: initialtext-decoration-color: initial">

</ignore_js_op>

一：收集候选地址

候选地址是或许可用于接收媒体以建立对等连接的<IP地址, 端口>对，它分四种类型。

| 类型 | 别名 | 如何传给对端 | 用法 |

| 主机候选项 | host | 信令服务器 | 从网卡中获取的本地传输地址，如果此地址位于NAT之后，则为内网地址 |

| 服务器反射候选项 | srflx | 信令服务器 | 从发送给Stun服务器的Binding检查中获取的传输地址。如果此地址位于NAT之后，则为最外层NAT的公网地址 |

| 对端反射候选项 | prflx | Stun Binding请求 | 从对端发送的Stun Binding请求获取的传输地址。这是一种在连接检查期间新发生的候选项 |

| 中继候选项 | relay | 信令服务器 | 媒体中继服务器的传输地址。通过使用TURN Allocate请求获取 |

具体到例子，以下是此阶段将至少能收集到的候选地址。为简单，不再写A的IP2、B的IP2的服务器反射地址。

| 别名 | 类型 | 值 |

| A Cand2 | srflx | 211.161.240.181(raddr: 192.168.1.105) |

| A Cand1 | host | 192.168.0.204 |

| B Cand3 | host | 192.168.0.181 |

二：交换候选地址

A通过信令服务器把A Cand2、A Cand1、B Cand3发向A。对端收到一个候选地址后会做什么？深入它之前让引入两种对象：P2PTransportChannel、Connection。

ICE代理用P2PTransportChannel管理通道（Component）上的网络传输。什么是通道？Webrtc有个概念叫轨道（Track），常见有视频轨、音频轨，而要发送一条轨道中数据，最多可能使用两个通道，分别是Rtp、Rtcp。肯定会有Rtp，Rtcp则可选。一个P2PTransportChannel对应一条通道，如果当前会话要同时处理音频、视频，每条轨道又都包括Rtp、Rtcp，那会话中就存在四个P2PTransportChannel对象。P2PTransportChannel用维护一张连接状态表来管理网络传输，表中一条记录对应一个Connection对象。这里让具体到A的视频Rtp对应的P2PTransportChannel，看它在收到B Cand1后，P2PTransportChannel会向连接状态表新增两条记录，即两个Connection。这时已到通道，地址须是ip:port对。

| 本地网卡地址(Port) | 对端地址 | 状态 |

| 192.168.1.105:60001 | 192.168.0.204:40001 | 未进行过Stun检查 |

| 172.16.40.6:60003 | 192.168.0.204:40001 | 未进行过Stun检查 |

此时A不知道该用哪个网卡IP才能把数据成功发向192.168.0.204，于是它只要在有可能的地址对就创建Connection。注意Connection只会基于网卡IP，即host，因为对发送源来说，host才可能是源，其它的只是中间转换出的地址，像srflx。当然，创建时会放弃明显不可能的<网卡地址, 对端地址>对，举个例子，网卡地址是ipv4，而对端地址是ipv6。

当收全B Cand2、B$Cand3，状态表中就有6条记录。

| 本地网卡地址 | 对端地址 | 状态 |

| 192.168.1.105:60001 | 192.168.0.204:40001 | 未进行过Stun检查 |

| 172.16.40.6:60003 | 192.168.0.204:40001 | 未进行过Stun检查 |

| 192.168.1.105:60001 | 11.92.14.8:50002 | 未进行过Stun检查 |

| 172.16.40.6:60003 | 11.92.14.8:50002 | 未进行过Stun检查 |

| 192.168.1.105:60001 | 192.168.0.181:40003 | 未进行过Stun检查 |

| 172.16.40.6:60003 | 192.168.0.181:40003 | 未进行过Stun检查 |

表中有一条、或多条、或没有，能够把A的视频Rtp数据发向B的视频Rtp通道，到底怎么个可能性就要执行接下的Stun检查。

三：STUN检查

在状态表新建一条记录，即一个Connection，很快就会在此Connection上进行Stun检查。Stun检查具体操作是在此Connection上发Stun Binding请求。 由于要能支持Stun应答，每个ICE代理必须内置Stun服务器功能。 Stun检查具体步骤见下图。

<ignore_js_op style="word-wrap: break-wordcolor: rgb(68, 68, 68)font-family: Tahoma, Helvetica, SimSun, sans-seriffont-size: 14pxfont-style: normalfont-variant-ligatures: normalfont-variant-caps: normalfont-weight: normalletter-spacing: normalorphans: 2text-align: starttext-indent: 0pxtext-transform: nonewhite-space: normalwidows: 2word-spacing: 0px-webkit-text-stroke-width: 0pxbackground-color: rgb(255, 255, 255)text-decoration-style: initialtext-decoration-color: initial">

</ignore_js_op>

为什么说Stun检查会发现prflx候选项？假如A和Stun服务器之间连接状态不好，在它收到B发来的srflx（11.92.14.8）之后还没得出自个的srflx（211.161.240.181）。虽然A没得到自个的srflx，但这不妨碍对B的srflx这个候选地址进行Stun检查，于是会向11.92.14.8发Stun请求。B收到这个请求，从请求解析出211.161.240.181。虽然这个地址在值上等于A的srflx，但不是从信令服务器得到，而是来自对端的Stun请求。此时B就会以这个prflx向状态表新建Connection。

A在之后终于向Stun服务器拿到了自个的srflx，并通过信令服务器发向B。B发现这个srflx值对应的Connection已存在，就不会再创建了。

到此可得出个结论：两种原因会导致新建Connection，一是从信令服务器收到候选地址，二是Stun检查发现prflx。不同于从信令服务器得到地址而创建的Connection，Stun检查时创建的Connection一开始就基本能确定连接是畅通的。

四：选定候选地址，并启动媒体

P2PTransportChannel会维护连接状态表，并排序表中记录（SortConnectionsAndUpdateState）。排序指的是计算每条记录的连接“成本”，把成本最低的排在第一条。如何计算成本？这涉及到很多因素，比如发出Stun请求到收到应答经过了的时间，用时越少的“成本”自然会低些。

当A有视频Rtp数据要发送时，它检查状态表的第一条记录，如果判断出它的状态是发送就绪，就会用此Connection进行发送。否则直接放弃这个发送任务。 媒体模块在处理数据的采集、编码任务时，不用考虑候选地址方面进展怎样了，只是要到发送时才关注下，而即使不能发送也不会影响自个进度；同样，候选地址处理模块也不会关注媒体处理模块的进度。这正是之前写的一个结论：“除了主叫必须创建Offer才开始收集候选地址、被叫必须创建Answer才开始收集候选地址外，ICE代理是相互独立地处理媒体和候选地址”。

维护表任务包括新建、删除记录，以及修改记录中的状态字段。删除记录、修改状态都涉及到“长连接”。

五：长连接

为确保NAT映射和过滤规则不在媒体会话期间超时，ICE会不断通过使用中的候选项对发送Stun连接检查。具体到P2PTransportChannel，表现出来的是对状态表中所有记录隔段时间就要发送个Stun Binding请求。如果检测到本来是畅通的Connection上Stun应答超时了，那它就会更改该Connection状态，执行表排序时就有可能会向下掉，严重时会从状态表删除该记录。

一记录被删除后，如果之后那候选地址的连接又恢复了，则会基于该候选地址重新创建Connection。

六：ICE重新启动

分析长连接时，我们已能得出个结论，如果是网络拥堵或通断导致的状态表变化，P2PTransportChannel内部就能处理。但是，如果基地址发生改变，像一网卡被禁用，这就超出P2PTransportChannel可处理范围了，需重启ICE。

---