webim如何使用http长轮询保证消息的绝对实时性


一、webim如何实现消息推送
webim通常有三种方式实现推送通道：
1）WebSocket
2）FlashSocket
3）http轮询
其中1）和2）是用Tcp长连接实现的，其消息的实时性很好理解，但这两种方案都存在一些局限性，不通用。
方案3）才算是webim实现消息推送的“正统”方案，用http短连接轮询的方式实现“伪长连接”，既然是轮询，有朋友就对消息的实时性产生了质疑。本文要解答，webim使用http长轮询如何保证消息的绝对实时性。


二、人们为什么会误解http长轮询不实时
什么是轮询？我擦，这个该怎么解释咧。
举个栗子，在火车上想上洗手间，挤到洗手间旁，却发现洗手间有人，于是你只能回座位继续等。过了N分钟，又朝洗手间的方向挤过去，却发现洗手间还是有人，又只能回坐等。这么一而再，再而三的每隔N分钟去洗手间查看洗手间是否有蹲位，这就是轮询。


webim用轮询的方式拉取消息会存在什么问题？
webim每隔N分钟，轮询调用 “获取消息”接口，有可能出现消息的延时，某一时刻刚拉取完消息，突然又产生了一条新消息，这条消息就必须等到N分钟之后，再次发起“获取消息”轮询时，才有机会获取到。


减小轮询时间间隔是否能解决消息延时的问题？
减小轮询时间间隔的确可以缩短延时时间，但也不能保证消息绝对的实时，同时又会产生新的问题，绝大部分的轮询调用，都没有消息返回，造成服务端极大的资源浪费。


很多人基于上述直觉，认为webim使用http长轮询的方式拉取消息，会导致消息有延时，其实，webim的http长轮询根本不是这么玩的。


三、长轮询实际怎么玩
消息连接
webim和webserver之间建立一条http连接，专门用作消息通道，这条连接叫http消息连接【见下图】



消息连接的4大特性
1）没有消息到达的时候，这个http消息连接将被夯住，不返回，由于http是短连接，这个http消息连接最多被夯住90秒，就会被断开（这是浏览器或者webserver的行为）


2）在1）的情况下，如果http消息连接被断开，立马再发起一个http消息连接【见下图中的步骤1、2】



3）在1）和2）的配合下，浏览器与webserver之间将永远有一条消息连接在（极限情况下会出现4）），每次收到消息时，这个消息连接就能及时将消息带回浏览器页面，并且在返回后，会立马再发起一个http消息连接【见下图中的步骤1、2、3】



4）如果消息到达时，上一个http消息连接正在返回，没有http消息连接可用（理论上http消息连接的返回是瞬时的，没有连接可用出现的概率极小），则将消息暂存入消息池中，下一个消息连接到达后（上一个消息连接返回后，根据2）和3）会立马返回新的消息连接，无等待时间），将消息带回，并又立刻返回生成新的消息连接【见下图中的步骤1、2、3、4、5、6、7】

上述1-4就能够保证一直有一条http消息连接在，以保证webim消息推送的绝对实时性。


四、结论
webim通过http长轮询可以保证消息的绝对实时性。这种实时性的保证不是通过增加轮询频率来保证的，而是通过夯住http消息连接来保证的，在大部分时间没有实时消息的情况下，这个http消息连接对于webserver的请求压力是90秒1次，能够大大节省了web服务器资源。


下一章，笔者将讨论webim消息的可靠性（如何做到webim消息不丢失、不重复）。
【完】
回复【架构】，阅读《58同城推荐系统架构设计与实现》
回复【twitter】，阅读《twitter系统架构分析》
回复【youtube】，阅读《YouTube系统架构》
回复【赶集】，阅读《赶集mysql军规》
回复【同城】，阅读《58同城mysql实战（上）》
回复【数据库】，阅读《58同城数据库架构设计思路（下）》
回复【秒杀】，阅读《秒杀系统架构优化思路》（火）


若有收获，感谢随手转发。
                    

                                                webim如何使用http长轮询保证消息的绝对实时性


一、webim如何实现消息推送
webim通常有三种方式实现推送通道：
1）WebSocket
2）FlashSocket
3）http轮询
其中1）和2）是用Tcp长连接实现的，其消息的实时性很好理解，但这两种方案都存在一些局限性，不通用。
方案3）才算是webim实现消息推送的“正统”方案，用http短连接轮询的方式实现“伪长连接”，既然是轮询，有朋友就对消息的实时性产生了质疑。本文要解答，webim使用http长轮询如何保证消息的绝对实时性。


二、人们为什么会误解http长轮询不实时
什么是轮询？我擦，这个该怎么解释咧。
举个栗子，在火车上想上洗手间，挤到洗手间旁，却发现洗手间有人，于是你只能回座位继续等。过了N分钟，又朝洗手间的方向挤过去，却发现洗手间还是有人，又只能回坐等。这么一而再，再而三的每隔N分钟去洗手间查看洗手间是否有蹲位，这就是轮询。


webim用轮询的方式拉取消息会存在什么问题？
webim每隔N分钟，轮询调用 “获取消息”接口，有可能出现消息的延时，某一时刻刚拉取完消息，突然又产生了一条新消息，这条消息就必须等到N分钟之后，再次发起“获取消息”轮询时，才有机会获取到。


减小轮询时间间隔是否能解决消息延时的问题？
减小轮询时间间隔的确可以缩短延时时间，但也不能保证消息绝对的实时，同时又会产生新的问题，绝大部分的轮询调用，都没有消息返回，造成服务端极大的资源浪费。


很多人基于上述直觉，认为webim使用http长轮询的方式拉取消息，会导致消息有延时，其实，webim的http长轮询根本不是这么玩的。


三、长轮询实际怎么玩
消息连接
webim和webserver之间建立一条http连接，专门用作消息通道，这条连接叫http消息连接【见下图】



消息连接的4大特性
1）没有消息到达的时候，这个http消息连接将被夯住，不返回，由于http是短连接，这个http消息连接最多被夯住90秒，就会被断开（这是浏览器或者webserver的行为）


2）在1）的情况下，如果http消息连接被断开，立马再发起一个http消息连接【见下图中的步骤1、2】



3）在1）和2）的配合下，浏览器与webserver之间将永远有一条消息连接在（极限情况下会出现4）），每次收到消息时，这个消息连接就能及时将消息带回浏览器页面，并且在返回后，会立马再发起一个http消息连接【见下图中的步骤1、2、3】



4）如果消息到达时，上一个http消息连接正在返回，没有http消息连接可用（理论上http消息连接的返回是瞬时的，没有连接可用出现的概率极小），则将消息暂存入消息池中，下一个消息连接到达后（上一个消息连接返回后，根据2）和3）会立马返回新的消息连接，无等待时间），将消息带回，并又立刻返回生成新的消息连接【见下图中的步骤1、2、3、4、5、6、7】

上述1-4就能够保证一直有一条http消息连接在，以保证webim消息推送的绝对实时性。


四、结论
webim通过http长轮询可以保证消息的绝对实时性。这种实时性的保证不是通过增加轮询频率来保证的，而是通过夯住http消息连接来保证的，在大部分时间没有实时消息的情况下，这个http消息连接对于webserver的请求压力是90秒1次，能够大大节省了web服务器资源。


下一章，笔者将讨论webim消息的可靠性（如何做到webim消息不丢失、不重复）。
【完】
回复【架构】，阅读《58同城推荐系统架构设计与实现》
回复【twitter】，阅读《twitter系统架构分析》
回复【youtube】，阅读《YouTube系统架构》
回复【赶集】，阅读《赶集mysql军规》
回复【同城】，阅读《58同城mysql实战（上）》
回复【数据库】，阅读《58同城数据库架构设计思路（下）》
回复【秒杀】，阅读《秒杀系统架构优化思路》（火）


若有收获，感谢随手转发。