关于web实时通信，通常使用长轮询或这长连接方式进行实现。
为了能够实际体会长轮询，通过Ajax长轮询实现了一个简单的聊天程序，在此作为笔记。
长轮询
传统的轮询方式是，客户端定时（一般使用setInterval）向服务器发送Ajax请求，服务器接到请求后马上返回响应信息。使用这种方式，无论客户端还是服务端都比较好实现，但是会有很多无用的请求（服务器没有有效数据的时候，也需要返回通知客户端）。
而长轮询是，客户端向服务器发送Ajax请求，服务器接到请求后保持住连接，直到有新消息才返回响应信息，客户端处理完响应信息后再向服务器发送新的请求。这样的好处就是，在没有数据的时候，客户端和服务器之间不会有无用的请求。
对于使用长轮询的实现，客户端和服务器都有一定的要求：
- 客户端发起请求，当接收到服务器响应（正常或异常的响应）后，需要向服务求发送新的请求，从而达到轮询的效果
- 服务器端要能够一直保持住客户端的请求，直到有响应消息；同时服务器对请求的处理要支持非阻塞模式
实现
例子很简单，客户端使用Ajax进行轮询请求，服务器端使用Python的gevent库来实现了非阻塞式的响应。
客户端
客户端实现了一个longPolling的函数，当文档加载完成后，就会调用这个longPolling函数。
注意Ajax请求的complete属性设置，每次当longPolling函数中的Ajax请求结束后，又会重新通过longPolling函数向服务器发出轮询请求。
function longPolling() {
$.ajax({
url: "update",
data: {"cursor": cursor},
type: "POST",
error: function (XMLHttpRequest, textStatus, errorThrown) {
$("#state").append("[state: " + textStatus + ", error: " + errorThrown + " ]<br/>");
},
success: function (result, textStatus) {
msg_data = eval("(" + result + ")");
$("#inbox").append(msg_data.html);
cursor = msg_data.latest_cursor;
console.log(msg_data)
$("#message").val("");
$("#state").append("[state: " + textStatus + " ]<br/>");
},
complete: longPolling
});
}
服务端
服务器端通过MessageBuffer类来维护了一个cache（用list实现），用来存放所有来自客户端的消息。当消息的数量超过cache_size的时候，服务器会清理掉早期的消息。
class MessageBuffer(object):
def __init__(self, cache_size = 200):
self.cache = []
self.cache_size = cache_size
self.message_event = Event()
由于Python自带的WSGI服务器是阻塞模式的，所以这里使用了gevent库中提供的非阻塞模式的WSGI服务器。
服务器的工作流程可以简单描述如下：
- 当服务器接收到客户端的数据请求时（/update）
- 如果存放消息cache为空，或者客户端已经得到了最新的消息（根据cursor这个GUID来判断），服务器阻塞（保持）该请求
- 服务器将所有有效的消息返回给客户端
- 当服务器接收到新的消息时（/new请求），服务器将新消息添加到cache中，并通过message_event事件来唤醒被阻塞的update请求
def application(env, start_response):
# visit the main page
if env[‘PATH_INFO‘] == ‘/‘:
return generate_response_data(‘200 OK‘, chat_html, start_response)
# client to send a new message
elif env[‘PATH_INFO‘] == ‘/new‘:
msg = escape(get_request_data("msg", env))
msg_item = {}
msg_item["id"] = str(uuid.uuid4())
msg_item["msg"] = msg
print "Got new message from client %s" %str(msg_item)
messageBuffer.cache.append(msg_item)
if len(messageBuffer.cache) > messageBuffer.cache_size:
messageBuffer.cache = messageBuffer.cache[-messageBuffer.cache_size:]
messageBuffer.message_event.set()
messageBuffer.message_event.clear()
return generate_response_data(‘200 OK‘, "", start_response)
# serve to send available messages
elif env[‘PATH_INFO‘] == ‘/update‘:
cursor = escape(get_request_data("cursor", env))
print "cursor: %s" %cursor
# if message buffer is empty or no new messages, just wait
if len(messageBuffer.cache) == 0 or messageBuffer.cache[-1]["id"] == cursor:
messageBuffer.message_event.wait()
for index, m in enumerate(messageBuffer.cache):
if m[‘id‘] == cursor:
return generate_response_data(‘200 OK‘, generate_json_data(messageBuffer.cache[index + 1:]), start_response)
return generate_response_data(‘200 OK‘, generate_json_data(messageBuffer.cache), start_response)
else:
return generate_response_data(‘404 Not Found‘, b‘<h1>Not Found</h1>‘, start_response)
运行效果
通过下面两个图片可以看到运行效果。
长轮询也是长连接?
为了进一步看看长轮询的工作方式，基于上面的例子，通过wireshark抓取了一些数据包。
在服务器启动后，客户端发送了三条消息，并通过三次"/update"请求分别得到了这三条消息。
从截图中可以看到，三次请求并没有创建新的连接，而是重用了TCP连接；这是因为HTTP 1.1中会有一个"keep-alive"模式，服务器响应后并不会直接关闭TCP连接，而是看看客户端会不会有新的请求，从而重用已有的TCP连接。
对于客户端，由于每次收到消息后都会重新发送新的"/update"请求，所以可以一直重用TCP连接。
当客户端发出"/update"请求后，如果没有新的消息可以返回，服务器会一直保持这个请求。
为了保持住这条TCP连接，可以看到客户端会定期的发送"TCP Keep-Alive"包来维持TCP连接。
我的理解是，在使用HTTP的"keep-alive"模式中，长轮询中始终使用的是相同的TCP连接，其实这也是一种长连接方式。
总结
本文中，通过简单的例子试用了长轮询的方式来实现web实时通信。
长轮询的方式，使用起来相对容易，同时用能减少客户端和服务器之间的无用请求。
Ps:
通过此处可以下载例子的源码，需要安装Python和gevent才能正常运行。