即时通信软件实现原理

现在即时通讯软件非常的常用，像QQ、微信等等通讯工具基本上是人人必备，但是即时通讯软件的原理是什么呢？我在这里就简单的谈一谈即时通讯软件的原理。

1. 乌托邦式的即时通讯方法

乌托邦的意思就是在绝对的理想条件下，服务器与所有的客户端都建立一个连接，它需要满足3个条件：

• 服务器资源无限，网络带宽无限。
• 网络链路稳定，路由不会宕机，客户端不具有移动性。
• 协调通信。
  每当客户端使用Socket连接上服务器，就不关闭连接，通过这个Socket与服务器交换数据。每当client要发送消息的时侯，它把消息发送给服务器，服务器找到目标client对应的Socket连接，将消息发送给目标用户。它的缺点显而易见，第一点，当client数很多时，服务器需要维护一个极大Socket List，事实上，一个Socket大概需要消耗1M左右的内存资源，且不说Socket与用户之间的映射表占用的空间，还有查找目标用户对应的Socket需要用大量时间。NAT服务器的端口数也是有数量限制的，众所周知，我们的机器一般使用的都是内网IP，当我们要建立一个连接到公网上的服务器时，NAT服务器该连接绑定在该机器的一个端口上，这叫做NAT地址转换，我们可以构造一个极端的例子，假如内网有50万台机器要登陆了，要建立50万个连接，也就是说NAT服务器要使用50万个PORT绑定那些内网用户，而一般的NAT服务器只有几万个PORT，这显然是不行的。第二点，网络链路是不稳定的，从我们的手机到QQ服务器会经过很多跳，中间一旦一个路由器突然宕机，Socket就可能会发生错误。而且我们的手机是会不断的移动的，从一个教室移动到另一个教室，连接的路由器就可能会发生变化。就算我们待在一个地方不动，由于DHCP协议自动配置IP地址，路由也会有可能发生变化，因此，在一个不稳定的网络上作出假设它是稳定的这种行为本身就是错误的。第三点，建立了一个Socket就相当于建立了一条管道，对于客户端与服务器来说，必须开一个线程来循环监听每个管道内是否有新的内容，效率很低。
  
  还有些人会提出一个这样的想法：
  服务器就不维护Socket连接了，只维护一个IP地址表，每当Client连接时，服务器将Client的IP地址记下来，每当有消息时再根据Client对应的IP地址，这个想法看上去确实比上面那个靠谱点，但是它也是建立用户无移动性的基础上的。我们也假设一个情况，B在3点登陆了，IP地址为198.168.0.1，他于4点突然断线(手机没电了)。C在5点连接上网络，DHCP自动给他分配了198.168.0.1的地址，他也连上了服务器。6点的时侯，A给B发一条消息，却发送到了C的电脑上。这就是一个潜在的隐患。再者就是NAT穿透问题。也就是说和上面那种方法一样，因为公网是无法主动访问到内网IP的，它们通过NAT服务器桥接，然而NAT分配端口是动态分配的，一旦连接断开，端口映射便回收了，就算你记录了IP地址也毫无意义。

2. 轮询式的即时通讯方法

轮询式即时通讯方法原理很简单，即每n毫秒连接一次服务器，在得到回复之后断开连接。这种方法，当有消息时存入数据库，直到目标用户询问时将消息发送给他。服务器有一个连接池，有一个Socket连接的上限。我曾经的Java课程设计做了一个即时通讯软件，使用的就是这种方法(当时年少无知)。这种方法的缺点也很明显，当用户不活跃时，周期性轮询会浪费大量的网络带宽，而且需要在即时性与性能之间做一个权衡。当用户很多时，也会造成服务器的沉重负担。但是这种方式实现起来十分的简单，单纯的使用http协议 (http的特点就是回复之后立刻断开) 便可以完成所有功能。

3. 广播式的即时通讯方法

前面两种方法都只用到了TCP，而接下来的两种方法就使用了UDP。如图所示，假如A有消息要发送给C，A首先与服务器建立一个TCP连接，服务器收到消息后回复，然后立即断开与A之间的连接。同时服务器会在全网段广播：“C，有你的消息！”，然后等待C的回复。这个时候ABCD都收到了广播消息，ABD发现这不是找自己的，然后丢弃掉消息，只有C发起一个TCP连接到服务器，然后服务器就将消息发给C；如果超时无回复，则存入数据库。这个方法其实是非常优秀的。首先它对服务器，对客户端的要求是很低的，有消息才发，没有消息的时侯只需要监听端口(没什么资源消耗)，不会造成它们的沉重负担。它也有一个瑕疵，广播使用的是范洪算法，因此每广播一次都会对网络造成沉重的负担，因此广播被限制只能在局域网中使用，因此，如果你的服务器是公网的IP地址，那么对不起，无法使用该方法，就只能使用最后一种方法了。广播的方法适用于局域网，如果你要在公司里或家里搭一个即时通讯系统的话，可以使用这种方法。如果每一个用户都是一个服务器的话，那就成了一个P2P的即时通讯网络。它很像ARP地址解析协议，A有消息要发给C，A就大喊一声：“C！我叫你一声你敢答应吗？”，BD听到表示吃瓜，C听到后回答：“爷爷在此！”。然后它们两个就开始深入交流。苹果产品的 “隔空投送” 也是基于这个原理。我曾经小学期的一个局域网即时通讯软件就使用的是这个方法。

4. 组播式的即时通讯方法

上面说了广播不使用于公网，因为大量范洪会导致网络负担，但是组播是可以使用在公网的。组播结构如下图：

对于每个节点，负责接收来自上层的消息，转发给所有登记了该服务的下层，这样其实就相当于递归，对于每一个节点，每一条边，它产生的资源消耗都很小，图中相当于形成了一棵生成树，它的优点是显而易见的。

于是，即时通讯服务便可以使用组播实现。每当用户登陆的时侯，或者当网络状态、环境改变的时侯，都会递归向上注册QQ的即时通讯服务。这时，如果A要向E发送一个消息，首先会把消息发给服务器，然后服务器进行组播，E收到组播之后自发向服务器发起一个连接，然后服务器就通过该连接将消息发给E。这也是目前大多数的即时通讯系统的实现原理。

现在对需求做一下变化，现在A想不通过服务器与E进行通讯，而它们又不在同一个局域网，这种P2P的即时通讯需求虽然没什么前景，但是的确可以通过代理实现NAT穿透。

即时通讯的原理就讲完了。而实现的方式各个软件都有所不同，就比如《计算机网络第五版》所说，为了节约成本，某些即时通讯软件使用UDP单播的方式发送消息，虽然它消息不可靠，看各自的需求。