理解WebSocket

WebSocket的动机是什么?

目前的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请求不断接力(long polling)
  • 单个HTTP请求不终止 (HTTP streaming)

 

但是,如果我们回过头来仔细想一下HTTP协议的细节,HTTP其实是建立在TCP之上的,所以当我们在进行HTTP通信时,client和server之间已经建立起了一个TCP连接,而任何TCP连接(从程序员角度来说,就是一个Berkeley socket)都是可以用来双向通信的,那么为什么不直接利用这个现成的TCP连接来实现client和server的双向通信呢?

 

没错!这就是WebSocket所做的事情!

WebSocket连接如何建立

我们建立WebSocket通信的过程是这样的:

  • Step 1 建立TCP连接(这一步是一切的基础,和HTTP一样)
  • Step 2 通过TCP连接,发送HTTP Get 请求,其中包含关键的Upgrade: websocket header。
  • Step 3 Server收到HTTP请求后,会把Step 1的TCP连接的用户层协议从HTTP转变为WebSocket。至此,HTTP部分就退出舞台了,WebSocket开始接管一切。

 

 

如何理解WebSocket可以和HTTP共享80端口?

准确的说,应该是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格式的WebSocket 请求
  • 协议切换
  • WebSocket的协议模块

 

 

参考

 

你可能感兴趣的:(websocket)