IM专题：模型分析（1）—IM运行模型

今天开始，基于前面内容的介绍，对 IM 进行抽象并分析几类常见模型： 运行模型、开发模型和读写扩散模型；今天对 IM 的运行模型进行分析。

IM 作为互联网一种简便的通讯工具，从产生到现在，在几十年的发展过程中，共有两类运行模型：一种是介绍人模型，一种是代理人模型。

一、介绍人模型

早期的 IM 系统以介绍人模型为主，见下图。

介绍人模型，也叫直连模型；IM 的主要业务逻辑全部在 “客户端” 进行实现，而 “服务端” 充当介绍人的角色，在服务端的帮助（介绍）下，客户端之间直接建立连接进行通信。

IM 介绍人模型在早期或在局域网环境中应用较多，目前在互联网系统中几乎不再应用，为什么呢？主要原因有三个：

1. 网络安全问题客户端之间建立连接后直接进行通信，消息收发完全 “私下” 进行，服务端无法进行有效的管控。比如在电商场景下，不法分子很容易钻空子，引导用户线下交易，让用户遭受损失。在互联网发达的今天，为营造安全的网络环境，网管也不允许未经过滤的消息任意横行！
2. 用户体验问题介绍人模型的 IM 系统，消息一般存储在客户端本地，当用户更换终端设备时，因为消息漫游问题，导致用户很难查询到之前的历史消息，从而影响用户体验。当然，可以通过客户端离线上传消息到服务端的方式解决这个问题，不过这样做反而有些本末倒置。
3. 技术问题最关键的还是技术实现问题，介绍人模型的 IM 系统需要解决 P2P 打洞技术问题。要通信的两个客户端，如果是在同一个局域网环境中，哪怕没有服务端，客户端之间也可以非常容易的建立连接（在大学寝室的局域网环境中，我们经常通过这种方式开发各类网络小程序）。如果要通信的两个客户端，是在两个不同的局域网中，比如：张三在贵阳的大学寝室，李四在北京的大学寝室，这两个客户端怎么建立连接呢？这就需要 P2P打洞技术。要理解 P2P打洞，先要了解一下 NAT，即 Network Address Translation，网络地址转换； NAT 技术几乎无处不在，大家思考一个问题：我们平时在家，在公司，在商场是如何上网的呢？要知道，我们的终端设备是没有独立的公网 IP 的，一个没有公网 IP 的设备是如何与 Internet 进行通信的呢？见下图。
   

局域网中的终端设备，通常没有独立的公网 IP，这些设备在访问 Internet 时，一般需要通过 NAT 网关，而 NAT 网关是有公网 IP 的；也就是说，NAT 网关是局域网中所有终端设备访问 Internet 的代理，这些终端设备通过同一个独立 IP（也叫做出口 IP）发送数据包到 Internet。当 Internet 返回的数据包到达 NAT 网关时，NAT 网关如何判断该将数据包转发到哪一个终端设备呢？这就是 NAT 技术的关键，通过 端口号进行区分，不同的终端设备占用 NAT 网关不同的端口号。NAT 技术同时也解决了独立 IP 资源非常紧俏的问题。NAT 网关通常由路由器来担任，也可以由一台具有独立 IP 的计算机来担任。

再来看，两个局域网中的终端设备，怎么通过 NAT 网关建立连接呢？见下图。

贵阳一局域网中的 NAT 网关其独立 IP 是 11.0.1.1，其内网中张三的终端设备 IP  是 192.168.1.1；北京一局域网中的 NAT 网关其独立 IP 是 11.0.2.2，其内网中李四的终端设备 IP 是 192.168.2.2；服务端（介绍人）独立 IP 是 11.9.9.9；以此为例，张三的终端设备如何与李四的终端设备建立连接，如下：

1. 李四终端设备通过 NAT 网关访问服务端，NAT 网关为其分配端口号 8888；服务端会记录映射关系：<李四， 11.0.2.2:8888>；
2. 张三终端设备通过 NAT 网关访问服务端，NAT 网关为其分配端口号 9999； 服务端会记录映射关系：<张三， 11.0.1.1:9999>；
3. 张三通过访问服务端，获知 李四的出口地址，即： 11.0.2.2:8888；
4. 张三终端设备通过 NAT 网关（11.0.1.1:9999）向 11.0.2.2:8888 发送连接请求，即： 11.0.1.1:9999—>11.0.2.2:8888；
5. 北京局域网 NAT 网关接收请求后，根据端口映射，将请求转发到李四的终端设备，即 192.168.2.2；
6. 李四的终端设备通过 NAT 网关（11.0.2.2:8888）向 11.0.1.1:9999 回复数据包，即：11.0.2.2:8888—>11.0.1.1:9999；
7. 贵阳局域网 NAT 网关接收请求后，根据端口映射，将数据包转发到张三的终端设备，即 192.168.1.1；
8. 至此，张三的局域网终端设备 与 李四的局域网终端设备之间的链路在 “服务端” 这个介绍人角色的支持下完成打通，这就是 P2P 打洞技术的基本流程。

       大家需要注意，掌握了 P2P 打洞技术的原理，介绍人模型下的 IM 客户端，是不一定会成功建立连接的，这是为何呢？仔细分析上述流程： 李四访问服务端，李四的出口地址 11.0.2.2:8888 被服务端获取，此时 “服务端” 对李四来说是信任的；那么任何一个知道 李四出口地址的客户端都能与之通信的话，安全性就大大降低了；所以在互联网发达的今天，NAT 网关为了增强安全性，一般会限制只有 “服务端” 发送的数据包才能转发到李四的终端设备，而只有 Full cone NAT 类型的网关才不做类似限制。总结一句就是：只有 Full cone NAT 类型的 NAT 网关可以支持 P2P 打洞。

二、代理人模型

鉴于介绍人模型的 IM 系统的上述问题，当前互联网模式下的 IM 系统以代理人模型为主，见下图。

代理人模型，也叫推拉模型；IM 的主要业务逻辑在 “服务端” 进行实现，而 “客户端” 主要完成与用户的交互行为。

代理人模型中，客户端之间的通信全部由服务端进行代理；通过服务端可以很好的对聊天消息进行管控；因为消息存储在服务端，可以很方便地实现消息漫游；同时因为 服务端 具有独立 IP，所以不存在 P2P 打洞技术问题。

如果说介绍人模型是一个去中心化的系统，则代理人模型就是一个中心化的系统，而服务端扮演一个非常关键的角色，需要解决可用性和高负载等一系列的问题。目前绝大多数的 IM 系统都采用代理人模型，本 IM 专题所有的文章和实践也全部是基于代理人模型进行讲解的。

对代理人模型抽象之后，需要解决什么的关键问题，我们在下一篇 “开发模型” 中进行分析。

最后，总结文中关键：

1. IM 共有两类运行模型：一是介绍人模型，一是代理人模型；
2. 介绍人模型目前应用不多，主要原因有三个：网络安全问题、用户体验问题和技术问题；
3. 介绍人模型的实现需要解决 P2P 打洞问题，P2P 打洞以 NAT 技术为基础，只有 Full cone NAT 类型的 NAT 网关才能支持 P2P打洞。

作者：棕生 | 来源：公众号——架构之魂