标签:
目前的Web通信使用的是HTTP协议,HTTP协议是基于TCP协议的应用层协议,HTTP协议的工作模式是request/response模式。在一次通信中,必须首先由client向server发起TCP连接,然后server接受该TCP连接请求,在TCP连接建立之后,首先由client发起HTTP request,然后server再发出HTTP response。
?
因此,在这种标准HTTP工作模式的约定下,server是不被允许发起一个TCP请求的,因此也就不被允许在未收到HTTP request的情况下,发送一个HTTP response给client。在这种约束下,为了能够不断的随时从server发送内容到client端,就必须保证server端随时都有一个待响应的request(注意这与persistent connection不是同一个概念,persistent connection是用来复用HTTP之下的TCP连接)。
?
如何在现有的HTTP框架内,来获得这么一个时刻存在于server端的待响应请求呢?这就是COMET技术,具体说有2种方式:
?
但是,如果我们回过头来仔细想一下HTTP协议的细节,HTTP其实是建立在TCP之上的,所以当我们在进行HTTP通信时,client和server之间已经建立起了一个TCP连接,而任何TCP连接(从程序员角度来说,就是一个Berkeley socket)都是可以用来双向通信的,那么为什么不直接利用这个现成的TCP连接来实现client和server的双向通信呢?
?
没错!这就是WebSocket所做的事情!
我们建立WebSocket通信的过程是这样的:
?
?
准确的说,应该是WebSocket可以分享HTTP正在使用的端口,不一定是80。原因是WebSocket的initial handshake是一个valid HTTP request,所以除非我们自己重写一套解析HTTP handshake的逻辑,否则必须发送到现有的HTTP端口来解析。而仅仅发送到HTTP端口还是不够的,我们还需要在server实现中添加关于WebSocket的逻辑。然后,server根据HTTP协议解析了initial handshake request之后,由server来进行协议切换,把HTTP换成WebSocket。
?
所以,这里可以看出,HTTP协议自己并不需要了解WebSocket什么,也不需要知道它何时应该让位于WebSocket协议,HTTP协议只是规定了HTTP的通信格式(比如WebSocket所使用的custom header),是server根据HTTP协议规定的格式,发觉了WebSocket的连接请求,然后再进行协议切换,server是协议切换逻辑的载体和执行者,当我们要实现一个WebSocket server,就必须在server代码中加入以下逻辑:
?
?
?
标签:
原文地址:http://www.cnblogs.com/smwikipedia/p/4321062.html