浅谈人人网以及淘宝网的IM即时通信以及point-to-point通信

简介:
+关注继续查看

我想,淘宝网或者是人人网,应该是大家较为熟知的网站了。就算你不是它们的使用者,我想你也应该早有耳闻。人人网和淘宝网的右下角,都提供了"在线"通信功能:


这次,我就和大家来谈谈我认为的这些网站实现这种在线聊天的“通信机制”。

实现Web版的IM(即时消息),是一种很实用的需求。比如:监控系统:后台硬件热插拔、LED、温度、电压发生变化;即时通信系统:其它用户登录、发送信息;即时报价系统:后台数据库内容发生变化;等等。但受限于http协议(基于请求/应答模式)。很难实现“即时”响应功能,来满足这些需求。

通常的解决方案有:基于基本的AJAX技术(不断请求服务端,以交互信息)、Flash Socket(需要有插件)、Java Applet等等。这些方案,可以实现“效果”,但是都有或多或少的缺点。【在之后的资料中,会提供它们分析它们利弊的链接】。

还有一种是基于Server Push技术——Comet。而人人网、淘宝这些大型网站正是采用了这种技术。

首先,登录人人网,然后我们使用Http Watch(用于查看和分析网页请求等信息的工具),可以看到如下的两个连接:


第一个连接的type是“text/html”,当我们在连接的右击,选择打开的时候,看到如下的画面:

这其实是一个初始化ajax“轮询”用的“页面”!

然后截图中的第二个连接,是一个“持续连接”。它保持着打开状态,一直在“侦听”服务端的响应,直到超时:


超时后返回的应该是“超时信息”,原来的“持续”连接有可能被废弃(aborted),然后继续发起“持续”连接。

---------------------------------------------------------------------------淘 宝 Comet 分 析----------------------------------------------------------------------------------------------

同上,我们查看请求:


上图中第一个请求,用于建立连接(bulidconnection)。并携带了两个参数(nkh/t)。截图中第二个也同样是一个Get请求,但是追加携带了两个参数:user/message,同时参数t的值也有所改变。

第三个连接就是用来进行“轮询”的(polling)。见第三个参数:cmd。

这在实现技术上有一些差别,人人网上的“长连接”确实如其名:超时时间设得很“长”。而你会看到淘宝的“长连接”一点也不长,非常短(见下图),取而代之的是采用非常平凡的请求来弥补连接不长的问题。


我想:

人人网采用的是:基于 Iframe 及 htmlfile 的流(streaming)方式

iframe· 是很早就存在的一种 HTML 标记, 通过在 HTML 页面里嵌入一个隐蔵帧,然后将这个隐蔵帧的 SRC 属性设为对一个长连接的请求,服务器端就能源源不断地往客户端输入数据。

淘宝网采用的是:基于 AJAX 的长轮询(long-polling)方式

虽然有些许不同,他们几乎都采用了同样的技术:Server Push技术(也就是Comet技术)

资料 :

http://www.fengfly.com/plus/view-171609-1.html

http://www.ibm.com/developerworks/cn/web/wa-lo-comet/

http://www.ibm.com/developerworks/cn/web/wa-cometjava/index.html

http://www.codeproject.com/KB/aspnet/CometAsync.aspx

http://www.codeproject.com/KB/aspnet/AspNetComet.aspx

http://topic.csdn.net/u/20120813/10/5C468BD3-5DB7-4387-A408-CADDF19CD20E.html

http://blog.csdn.net/ibm_hoojo/article/details/7850540

本人之前写过的几篇文章:

http://blog.csdn.net/yanghua_kobe/article/details/6737224

http://blog.csdn.net/yanghua_kobe/article/details/6744518

http://blog.csdn.net/yanghua_kobe/article/details/5451910




原文发布时间为:2011-09-04


本文作者:vinoYang


本文来自云栖社区合作伙伴CSDN博客,了解相关信息可以关注CSDN博客。

目录
相关文章
|
2月前
|
运维 关系型数据库 MySQL
使用docker快速部署ferry开源工单系统
简单好用的工单系统,你不来看看吗?
|
3月前
基于低代码平台搭建工单系统
基于低代码平台搭建工单系统
|
4月前
|
Cloud Native 关系型数据库 数据库
云原生之使用Docker部署PESMCS Ticket工单系统
云原生之使用Docker部署PESMCS Ticket工单系统
65 2
|
4月前
|
机器学习/深度学习 人工智能 自然语言处理
LLM系列 | 11: 基于ChatGPT构建智能客服系统(query分类&安全检查&防注入)
本文主要介绍如何使用ChatGPT对智能客服领域中的客户咨询进行分类。此外还补充构建真实应用中如何对用户咨询内容和模型生成内容进行安全检查及其如何预防用户注入。
|
5月前
|
网络协议 开发工具
IM即时通信系统数据多端同步解决方案
每个客户端定时轮询服务端,请求好友列表。
309 0
|
6月前
|
消息中间件 前端开发 JavaScript
太顶了,使用 Netty 实现了一个 IM 即时通讯系统
太顶了,使用 Netty 实现了一个 IM 即时通讯系统
|
7月前
|
存储 自然语言处理 网络协议
得物从0到1自研客服IM系统的技术实践之路
本篇文章将基于工程实践,分享我们从0到1自研一套客服IM系统时在各种关键技术点上的设计思路和实践方法。
314 1
得物从0到1自研客服IM系统的技术实践之路
|
自然语言处理 前端开发 中间件
手淘千牛IM即时通信 - 星巴克消息开放实践
> 对垂直业务领域进行了解,抽象成领域模型,沉淀出通用能力和标准化体系,为后续业务赋能。 这是笔者理解的技术驱动业务。生于业务,又高于业务 笔者很荣幸可以参与到淘宝小程序的开放体系中,消息能力的开放也是里面很重要的一环,在双十一前可以借助星巴克小程序把消息方案落地,这次做个总结。 这次星巴克消息开放融合带来的挑战是:底层需要对接不同的服务体系,他们之间的协议不一致,上层业务业务又需要统
2251 0
|
分布式计算 Java 数据安全/隐私保护
热门文章
最新文章
相关产品
云迁移中心
推荐文章
更多