昨天收到一个高大上的礼盒，以为里面装着一件古董

打开一看，惊呆了。。。

正好美国最近大动乱，啥都不缺，就缺这件防弹背心，顺便还可以防寒保暖。

以后深夜撸代码，就可以穿着这件背心了。哇咔咔。。。谢谢融云的惊喜

WebRTC中两个或多个主机进行P2P连接是通过STUN、TURN、ICE等技术实现的。主机往往都是在NAT之后，且不同的NAT导致外部主机向内网主机发送数据的可见性不同。 内网主机通过STUN协议可以获得NAT分配的外部地址。ICE是主机之间发现P2P传输路径机制，ICE中使用了STUN协议进行连通检测、传输路径的指定和保活。 本文将对STUN和ICE协议进行分析和解读，希望能为开发者们带来一些启发和帮助。

1. NAT类型

网络地址转换， 简称NAT，节省了IPv4地址空间的使用并且隔离了内网和外网。NAT对待UDP的实现方式有4种，分别如下：

1.1完全圆锥型

一个内网地址(iAddr:iPort)被映射到一个外网地址 (eAddr:ePort)。这个内网(iAddr:iPort)地址发送的数据包都会通过这个外网地址(eAddr:ePort)。外部主机可以通过这个外网地址(eAddr:ePort)向这个内网地址(iAddr:iPort)发送数据包。

1.2地址受限锥型

一个内网地址(iAddr:iPort)被映射到一个外网地址 (eAddr:ePort)。这个内网(iAddr:iPort)地址发送的数据包都会通过这个外网地址(eAddr:ePort)。外部主机 (hAddr:any) 只有接收过从内网(iAddr:iPort)发送来的数据包后，才能通过外部地址 (eAddr:ePort)发送数据包给内网地址(iAddr:iPort)。其中外部主机的端口可以是任意的。

1.3端口受限锥型

一个内网地址(iAddr:iPort)被映射到一个外网地址 (eAddr:ePort)。这个内网(iAddr:iPort)地址发送的数据包都会通过这个外网地址(eAddr:ePort)。外部主机 (hAddr:hPort) 只有接收过从内网(iAddr:iPort)发送来的数据包后，才能通过外部地址 (eAddr:ePort)发送数据包给内网地址(iAddr:iPort)。其中外部主机的端口hPort是受限的。

1.4对称型

一个内网地址(iAddr:iPort)向外网地址 (sAddr1:sPort1)发送的多次请求时，NAT会分配同一个外网地址(eAddr1:ePort1)。若向不同的外网地址如(sAddr2:sPort2)发送数据包时，NAT分配另外一个外网地址(eAddr2:ePort2)。外网地址 (sAddr1:sPort1)只有接收过从内网(iAddr:iPort)发送来的数据后，才能通过已经在NAT上开辟的(eAddr1:ePort1)发送数据包给内网.

2. STUN简介

STUN是Session Traversal Utilities for NAT简写，RFC5389规定了具体内容。STUN协议是用来获取内网地址对应在NAT上的外网地址，NAT穿越。 STUN是C/S模式的协议，由客户端发送STUN请求；STUN服务响应，告知由NAT分配给主机的IP地址和端口号。

2.1 STUN消息结构

STUN消息头为20字节，后面紧跟0或多个属性。STUN头部包含一STUN消息类型、magic cookie、事务ID和消息长度。 

(图)STUN消息结构

每个STUN消息的最高位前2位必须为0。当多个协议复用同一个端口的时候，这个可以用于与其他协议区分STUN数据包。 消息类型确定消息的类别（如请求、成功回应、失败回应、指示indication）。虽然这里有四种消息类型，但可以分为2类事务：请求/响应事务、指示事务。

magic cookie为固定值0x2112A442。

Transaction ID标识同一个事务的请求和响应。当客户端发送多个STUN请求，通过Transaction ID识别对应的STUN响应。

2.2 STUN消息类型

(图)STUN消息类型

C0和C1位置的bit指明了消息的分类。其余的12位置标示不同的请求类型，比如绑定请求。

2.3 STUN属性

STUN头之后是0或多个属性。每个属性都采用TLV编码，type为16位的类型、lenght为16位的长度、value为属性值。每个STUN属性必须是4字节对齐。

(图)STUN属性

STUN属性格式

STUN服务器请求和响应都包含消息属性。一些属性不是强制性的，其中一些只能出现在绑定请求中，而其他一些只能出现在绑定响应中。  属性空间被划分为2个范围。强制理解属性STUN代理必须处理，否则STUN代理将无法正常处理该属性的消息；STUN代理不能理解可选理解属性的话，这些属性可以被忽略。

强制理解属性 (0x0000-0x7FFF):

 可选理解属性 (0x8000-0xFFFF)

具体说明如下： MAPPED-ADDRESS属性标识了NAT映射后的地址。

XOR-MAPPED-ADDRESS属性与MAPPED-ADDRESS属性一致，映射后的地址要做异或处理。

USERNAME属性用于消息完整性。用户名和密码包含在消息完整性中。

MESSAGE-INTEGRITY属性是STUN消息的HMAC-SHA1值，长度20字节。MESSAGE-INTEGRITY属性可以出现在任何类型的STUN消息中。用作HMAC输入的文本是STUN消息，包括头部，直到且包括MESSAGE-INTEGRITY属性前面的属性。FINGERPRINT属性出现MESSAGE-INTEGRITY后。所以FINGERPRINT属性外，STUN代理忽略其他出现在MESSAGE-INTEGRITY属性后的任何属性。

FINGERPRINT属性可以出现在所有的STUN消息中，该属性用于区分STUN数据包与其他协议的包。属性的值为采用CRC32方式计算STUN消息直到但不包括FINGERPRINT属性的的结果，并与32位的值0x5354554e异或。

ERROR-CODE属性被用于错误响应消息中。它包含一个在300至699范围内的错误响应号。

REALM属性出现在请求中，表示认证时要用长期资格。出现在响应中，表示服务器希望客户端使用长期资格进行认证。

NONCE属性是出现在请求和响应消息中的一段字符串。

UNKNOWN-ATTRIBUTES属性出现在错误代码为420的的错误响应，表示服务器端无法理解的属性。

SOFTWARE属性用于代理发送消息时所使用的软件的描述。

ALTERNATE-SERVER属性表示STUN客户可以尝试的不同的STUN服务器地址。属性格式与MAPPED-ADDRESS相同。

2.4 STUN示例

下面是Wireshark抓取的一对STUN绑定请求和响应。STUN绑定请求，源地址192.168.2.36:47798，目标地址180.76.137.157:30001。

STUN绑定响应，源地址180.76.137.157:30001，目标地址192.168.2.36:47798

其中ICE-CONTROLLING、PRIORITY属性是下面提到的ICE中扩充的属性。

3. ICE简介

ICE两端并不知道所处的网络的位置和NAT类型，通过ICE能够动态的发现最优的传输路径。如下图L和R是ICE代理，下面简称L和R。L和R有各自的传输地址，包括主机的网卡地址、NAT上的外网地址、 TURN服务地址。ICE就是要从这些地址中，找到L和R的候选地址对，实现两端高效连通。

(图)ICE部署图举例

ICE两端可以通过信令服务器交换SDP信息。ICE使用STUN，TURN等协议来建立会话。

3.1收集候选地址

ICE端收集本地地址。通过STUN服务收集NAT外网地址；通过TURN收集中继地址。

所以有四种候选地址：

如下图: 主机候选X:x 服务器反射候选X1':x1' 中继候选Y:y 这里称主机候选地址是服务器候选地址的BASE。

(图)ICE端口

3.2连通检测

L收集了所有的候选地址后，按优先级从高到低排序，通过信令服务器发送SDP offer给R。R收到offer后，收集获选地址，并将自己候选地址放入SDP answer发送给L。此时两端都有了对端的和本端的候选地址。然后配对，生成candidate pair。为了确保candidate pair的有效性，两端都要做连通检测。根据candidate pair，从本地candidate发送STUN请求到远端candidate；接收端返回STUN响应给发送端。如下图。

(图)ICE基本连通检测

两端都按照各自checklist分别进行检查。

当R收到L的检测时，R发送向L的检测被称为Triggered检测。

3.3 Candidates pair排序

将连通性检查成功的candidate pair按优先级排序加入check list。两端定期遍历这个check list， 发送STUN请求给对端称为Ordinary检测。优先级的计算根据以下原则： 每端给自己的candidate一个优先级数值。本端优先级和远端优先级结合，得到candidate pair的优先级优先级。

公式 priority = (2^24)*(type preference) + (2^8)*(local preference) + (2^0)*(256 - component ID)

再根据candidate的优先级计算candidate pair的优先级。

priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0)

G:controlling candidate 优先级 D:controlled candidate 优先级

3.4提名Candidates

ICE中有两种角色, controlling角色可以选取最终的candidate pair；controlled角色会等待controlling角色选取的candidate pair。 ICE指定一个ICE代理为controlling角色，其他ICE代理为controlled角色。ICE优先检测优先级高的candidate pair。

Controlling角色有两中提名方案：REGULAR提名：当得到至少一对有效的pair的时候，Controlling角色就会选择其中的一个pair作为候选，此次连通检测发送一个带flag的请求，告诉对端这个就是被选中的pair。

(图)REGULAR提名

AGGRESSIVE提名:Controlling角色会在每个STUN请求之中添加flag标志，最先成功的那个被选为媒体传输通道。

(图)AGGRESSIVE提名

3.5 ICE示例

下面是例子中，L和R都是full模式ICE代理，采用aggressive提名，传输媒体为RTP。full模式为双方都要进行连通性检查，都要的走一遍流程；lite模式为，full模式ICE一方进行连通性检查，lite一方只需回应response消息。

(图)ICE举例

便于理解，采用"主机类型-网络类型-序号"的格式表示传输的地址。地址有两个分量，分别是IP和PORT。L，R，STUN，NAT代表不同的主机类型；PUB代表外网，PRV代表内网； L处在内网中，内网地址是10.0.1.1，R处在外网，外网地址是192.0.2.1。L和R都配置了STUN服务，地址是192.0.2.2，端口是3478。L在NAT后面，NAT外网地址是192.0.2.3。序号表示不同的媒体类型，这里只有RTP所以序号为1。 "S="表示STUN消息的发送地址、"D=" 表示STUN消息的接收地址。 "MA=" 表示STUN绑定响应的中mapped address。"USE-CAND" 表示带有"USE-CANDIDATE" STUN消息。

L收集本地候选地址，并发起STUN绑定请求给STUN服务器，L得到 NAT-PUB-1作为服务器反射候选地址。 L计算候选的优先级，主机候选地址type preference为126；服务器反射候选地址type preference为100。local preference为65535。component ID为1 套用公式priority = (2^24)*(type preference) + (2^8)*(local preference) + (2^0)*(256 - component ID) 得主机候选地址的优先级为2130706431，服务器反射候选地址的优先级为1694498815。 L设置主机候选地址的foundation为1，服务器反射候选地址foundation为2。  L将服务器反射候选地址作为default候选地址。对应的offer sdp为

替换地址后

因为L和R都采用的是full-mode，这种情况下ICE协议规定发送offer为controlling端，L为controlling端。 L和R生成candidate pair，两端都有2个candidate pair。L会裁减掉包含服务映射候选地址，保留candidate pair为本端$L_PRIV_1、远端$R_PUB_1。

消息9表示R做连通检测，因为R是controlled角色，所以无需设置USE-CANDIDATE。L处于NAT后面，且没有向R发送过请求，所以此次连通检测会失败。

当L收到answer sdp后，开始连通检测（消息10-13）。L采用的是aggressive提名，所以每个请求都会有USE-CANDIDATE。L使用candidate pair为$L_PRIV_1/$R_PUB_1发起的连通检测成功后，L创建一个新的candidate pair，本端为NAT-PUB-1(消息13中得到) 、远端为R-PUB-1(消息10中得到)，加入valid list中。这个连通检测中设置了USE-CANDIDA属性，该candidate pair为选中的候选。L的RTP流在valid list中有选中的candidate pair，所以L进入完成状态。

R收到L的STUN绑定请求(消息11)后，R发起消息11对应的Triggered检测，其candidate pair的本端为R-PUB-1、远端为NAT-PUB-1。检测成功后，R创建本端为R-PUB-1、远端为NAT-PUB-1的candidate pair，加入valid list。因为消息11中包含了USE-CANDIDATE，所以这个candidate pair就被选中为这个RTP流的传输通道。R进入完成状态。

4. 总结

本文介绍了NAT、STUN、ICE等基本概念。STUN部分介绍了STUN的消息结构、消息类型和消息属性，ICE协议中STUN消息要遵循STUN协议。 ICE部分介绍了ICE代理之间是如何根据各自的网络地址建立连接的，步骤有收集候选地址、连通检测、Candidates pair生成与排序、提名Candidates。 详细内容还需查看ICE协议rfc5245以及webrtc的p2p部分的具体实现。

当前阶段，群聊已经成为主流IM软件的基本功能，不管是亲属群，朋友群亦或是工作群，都是非常常见的场景。随着移动互联网的发展，即时通讯服务被广泛应用到各个行业，客户业务快速发展，传统百人甚至千人上限的群聊已经无法满足很多业务发展需求，所以超大群的业务应运而生。

1超大群面临的挑战

我们以一个万人群的模型进行举例：

1、如果群中有人发了消息，那么这条消息需要按照1:9999的比例进行分发投递，如果我们按照常规消息的处理流程，那么消息处理服务压力巨大。

2、消息量大的情况下，服务端向客户端直推消息的处理速度将会成为系统瓶颈，而一旦用户的消息下发队列造成了挤压，会影响到正常的消息分发，也会导致服务缓存使用量激增。

3、在微服务架构中，服务以及存储（DB，缓存）之间的QPS和网络流量也会急剧增高。

4、以群为单位的消息缓存，内存和存储开销较大（消息体的存储被放大了万倍）。

基于这些挑战，我们的服务势必要做一定的优化来应对。

2群消息分发模型

整体的群聊服务架构如下图所示：

   用户在群里发了一条群消息后，消息先到群组服务，然后通过群组服务缓存的群关系，锁定这条消息最终需要分发的目标用户，然后根据一定的策略分发到消息服务上，消息服务再根据用户的在线状态和消息状态来判断这条消息是直推、通知拉取还是转Push，最终投递给目标用户。

3超大群消息分发解决方案

3.1分发控速：

第一，首先我们会根据服务器的核数来建立多个群消息分发队列，这些队列我们设置了不同的休眠时间以及不同的消费线程数，这里可以理解为快、中、慢等队列。如下图所示：

第二，我们根据群成员数量的大小来将所有群映射到相应的队列中，规则是小群映射到快队列中，大群映射到相应的慢队列中。

第三，小群由于人数少，对服务的影响很小，所以服务利用快队列快速的将群消息分发出去，而大群群消息则利用慢队列的相对高延时来起到控速的作用。

3.2 合并分发：

一条群消息发送到IM服务器后，需要从群组服务投递给消息服务，如果每一个群成员都投递一次，并且投递的群消息内容是一致的话，那肯定会造成相应的资源浪费和服务压力。

服务落点计算中我们使用的是一致性哈希，群成员落点相对固定，所以落点一致的群成员我们可以合并成一次请求进行投递，这样就大幅提高了投递效率同时减少了服务的压力。

3.3 超大规模群的处理方案

在实际群聊业务中，还有一种业务场景是超大规模群，这种群的群人数达到了数十万甚至上百万，这种群如果按照上述的分发方案，势必也会造成消息节点的巨大压力。比如我们有一个十万人的群，消息节点五台，消息服务处理消息的上限是一秒钟4000条，那每台消息节点大约会分到2万条群消息，这超出了消息节点的处理能力。

所以为了避免上述问题，我们的超大群（群成员上线超过3000，可以根据服务器数量和服务器配置相应做调整）会用特殊的队列来处理群消息的分发，这个特殊的队列一秒钟往后端消息服务投递的消息数是消息服务处理上限的一半（留相应的能力处理其他消息），如果单台消息服务处理的QPS上限是4000，那群组服务一秒往单台消息服务最多投递2000条。

结束语

我们后续也会针对群消息进行引用分发，对于大群里发的消息体比较大的消息，我们给群成员只分发和缓存消息的索引，比如MessageID，等群成员真正拉取群消息时再从将消息组装好给客户端分发下去。这样做会节省分发的流量以及存储的空间。

随着互联网的发展，群组业务的模型和压力也在不停地扩展，后续可能还会遇到更多的挑战，届时我们服务器也会通过更优的处理方式来应对。

感兴趣的开发者可以扫码下载融云的 IM 即时通讯 Demo 产品：SealTalk，体验融云的群聊、聊天室等通信能力。

到此，我们分析完了有关 IM 消息核心处理流程，通过层层拆解逻辑，提供可靠的消息投递机制。