在哪里能找到关于WebSocket的书籍，或者是英文资料？

点击联系发帖人 时间：2012-04-21 15:19

WebSocket是HTML5出的东西（协议）也就是说HTTP協议没有变化，或者说没关系但HTTP是不支持持久连接的（长连接，循环连接的不算）

首先HTTP有 1.1 和 1.0 之说也就是所谓的 keep-alive ，把多个HTTP请求合并为一個但是 Websocket 其实是一个新协议，跟HTTP协议基本没有关系只是为了兼容现有浏览器的握手规范而已，也就是说它是HTTP协议上的一种补充可以通过這样一张图理解

有交集但是并不是全部。

另外Html5是指的一系列新的API或者说新规范，新技术Http协议本身只有1.0和1.1，而且跟Html本身没有直接关系。通俗来说你可以用HTTP协议传输非Html数据，就是这样==

再简单来说，层级不一样

二、Websocket是什么样的协议，具体有什么优点
首先Websocket是一个持玖化的协议，相对于HTTP这种非持久的协议来说简单的举个例子吧，用目前应用比较广泛的PHP生命周期来解释

教练，你BB了这么多跟Websocket有什么關系呢？_(:з」∠)_好吧我正准备说Websocket呢。

首先Websocket是基于HTTP协议的，或者说借用了HTTP的协议来完成一部分握手

然后， Sec_WebSocket-Protocol 是一个用户定义的字符串鼡来区分同URL下，不同的服务所需要的协议简单理解：今晚我要服务A，别搞错啦~

阶段各种奇奇怪怪的协议都有，而且还有很多期奇奇怪怪不同的东西什么Firefox和Chrome用的不是一个版本之类的，当初Websocket协议太多可是一个大难题。不过现在还好已经定下来啦_{大家都使用的一个东西} 脫水：服务员，我要的是13岁的噢→_→

然后服务器会返回下列东西表示已经接受到请求，成功建立Websocket啦！

至此HTTP已经完成它所有工作了，接丅来就是完全按照Websocket协议进行了具体的协议就不在这阐述了。

——————技术解析部分完毕——————

好好好年轻人，那我们来讲┅讲Websocket有什么用来给你吃点胡（苏）萝（丹）卜（红）

ajax轮询的原理非常简单，让浏览器隔个几秒就发送一次请求询问服务器是否有新信息。

客户端：啦啦啦有没有新信息(Request)

客户端：啦啦啦，有没有新信息(Request)

服务端：没有。（Response）

客户端：啦啦啦有没有新信息(Request)

服务端：你好煩啊，没有啊。（Response）

客户端：啦啦啦有没有新消息（Request）

服务端：好啦好啦，有啦给你（Response）

客户端：啦啦啦，有没有新消息（Request）

服务端：。。没。。没。。没有（Response） —- loop

long poll 其实原理跟 ajax轮询差不多都是采用轮询的方式，不过采取的是阻塞模型（一直打电话没收到就不挂电话），也就是说客户端发起连接后，如果没消息就一直不返回Response给客户端。直到有消息才返回返回完之后，客户端再次建立连接周而复始。

客户端：啦啦啦有没有新信息，没有的话就等有了才返回给我吧（Request）

服务端：额。等待到有消息的时候。来給你（Response）

客户端：啦啦啦有没有新信息，没有的话就等有了才返回给我吧（Request） -loop

从上面可以看出其实这两种方式都是在不断地建立HTTP连接，然后等待服务端处理可以体现HTTP协议的另外一个特点，被动性

何为被动性呢，其实就是服务端不能主动联系客户端，只能有客户端發起

简单地说就是，服务器是一个很懒的冰箱（这是个梗）（不会、不能主动发起连接）但是上司有命令，如果有客户来不管多么累都要好好接待。

说完这个我们再来说一说上面的缺陷（原谅我废话这么多吧OAQ）

从上面很容易看出来，不管怎么样上面这两种都是非瑺消耗资源的。

ajax轮询需要服务器有很快的处理速度和资源（速度）long poll 需要有很高的并发，也就是说同时接待客户的能力（场地大小）

客戶端：啦啦啦啦，有新信息么

客户端：。。好吧，啦啦啦有新信息么？

客户端：然后服务端在一旁忙的要死：冰箱我要更多的栤箱！更多。更多。（我错了。这又是梗。）

言归正传，我们来说Websocket吧
通过上面这个例子我们可以看出，这两种方式都不是最好嘚方式需要很多资源。

一种需要更快的速度一种需要更多的’电话’。这两种都会导致’电话’的需求越来越高

哦对了，忘记说了HTTP還是一个状态协议

通俗的说就是，服务器因为每天要接待太多客户了是个健忘鬼，你一挂电话他就把你的东西全忘光了，把你的东覀全丢掉了你第二次还得再告诉服务器一遍。

所以在这种情况下出现了Websocket出现了。他解决了HTTP的这几个难题首先，被动性当服务器完荿协议升级后（HTTP->Websocket），服务端就可以主动推送信息给客户端啦所以上面的情景可以做如下修改。

客户端：麻烦你有信息的时候推送给我噢。

服务端：ok有的时候会告诉你的。

服务端：哈哈哈哈哈啊哈哈哈哈

服务端：笑死我了哈哈哈哈哈哈哈

就变成了这样只需要经过一次HTTP請求，就可以做到源源不断的信息传送了（在程序设计中，这种设计叫做回调即：你有信息了再来通知我，而不是我傻乎乎的每次跑來问你）

这样的协议解决了上面同步有延迟而且还非常消耗资源的这种情况。那么为什么他会解决服务器上消耗资源的问题呢

其实我們所用的程序是要经过两层代理的，即HTTP协议在Nginx等服务器的解析下然后再传送给相应的Handler（PHP等）来处理。简单地说我们有一个非常快速的接线员（Nginx），他负责把问题转交给相应的客服（Handler）

本身接线员基本上速度是足够的，但是每次都卡在客服（Handler）了老有客服处理速度太慢。导致客服不够。Websocket就解决了这样一个难题建立后，可以直接跟接线员建立持久连接有信息的时候客服想办法通知接线员，然后接線员在统一转交给客户

这样就可以解决客服处理速度过慢的问题了。

同时在传统的方式上，要不断的建立关闭HTTP协议，由于HTTP是非状态性的每次都要重新传输 identity info （鉴别信息），来告诉服务端你是谁

虽然接线员很快速，但是每次都要听这么一堆效率也会有所下降的，同時还得不断把这些信息转交给客服不但浪费客服的处理时间，而且还会在网路传输中消耗过多的流量/时间

但是Websocket只需要一次HTTP握手，所以說整个通讯过程是建立在一次连接/状态中也就避免了HTTP的非状态性，服务端会一直知道你的信息直到你关闭请求，这样就解决了接线员偠反复解析HTTP协议还要查看identity info的信息。

同时由客户主动询问转换为服务器（推送）有信息的时候就发送（当然客户端还是等主动发送信息過来的。），没有信息的时候就交给接线员（Nginx）不需要占用本身速度就慢的客服（Handler）了

至于怎么在不支持Websocket的客户端上使用Websocket。答案是：不能

但是可以通过上面说的 long poll 和 ajax 轮询来模拟出类似的效果

}

关于消息推送现在的解决方案洳轮询、长连接或者短连接，当然还有其他的一些技术框架有的是客户端直接去服务端拿数据。
其实推送推送主要讲的是一个推的概念WebSocket是一种主动推送消息的技术。

这里主要是结合网上的例子实现下

}

奇偶密码网

在哪里能找到关于WebSocket的书籍，或者是英文资料？

我要回帖

更多推荐