HTML5的WebSocket是什么原理

Websocket是应用层第七层上的一个应用层协议，它必须依赖 HTTP 协议进行一次握手 ，握手成功后，数据就直接从 TCP 通道传输，与 HTTP 无关了。即：websocket分为握手和数据传输阶段，即进行了HTTP握手 + 双工的TCP连接。 下面我们分别来看一下这两个阶段的具体实现原理： 客户端发送消息： 服务端返回消息： 这里值得注意的是 Sec-WebSocket-Accept的计算方法 ： base64(hsa1(sec-websocket-key + 258EAFA5-E914-47DA-95CA-C5AB0DC85B11)) 如果这个Sec-WebSocket-Accept计算错误浏览器会提示：Sec-WebSocket-Accept dismatch 如果返回成功，Websocket就会回调onopen事件 Websocket的数据传输是frame形式传输的，比如会将一条消息分为几个frame，按照先后顺序传输出去。这样做会有几个好处： websocket传输使用的协议如下图： 参数说明如下： 我们了解了websocket的实现原理之后，请看以下golang的实现案例： html和js使用案例：

本篇文章主要讲述以下几点： WebSocket协议分为两部分：握手和数据传输 下面通过客户端和服务端交互的报文对比WebSocket通讯与传统HTTP的不同点，主要关注握手阶段。 根据上面的例子，运行之后，new WebSocket实例化一个新的WebSocket客户端对象，请求WebSocket URL为 ws://localhost:8000 的服务器，打开控制台的NetWork，客户端WebSocket对象会自动解析并识别为WebSocket请求，连接服务端端口，执行双方握手过程，来自客户端握手发送数据格式如下：至此，HTTP已经完成它所有工作，接下来就是完全按照Websocket协议进行了。 通过查看WebSocket的原理，与HTTP对比，得出结论： HTTP长连接中，每次数据交换除了真正的数据部分外，服务器和客户端还要大量交换HTTP header，信息交换效率很低。Websocket协议通过第一个请求建立了TCP连接之后，之后交换的数据都不需要发送 HTTP header就能交换数据，这显然和原有的HTTP协议有区别，所以它需要对服务器和客户端都进行升级才能实现（主流浏览器都已支持HTML5）。此外还有 multiplexing、不同的URL可以复用同一个WebSocket连接等功能。这些都是HTTP长连接不能做到的。 我们在使用WebSocket协议时通常不会使用它的API来实现，而是借助于Socket.io，Socket.io是一个WebSocket库，包括客户端的js和服务端的nodejs，它的目标是构建可以在不同浏览器和移动设备上使用的实时应用。它会自动根据浏览器从WebSocket、AJAX长轮询等各种方式中选择最佳的方式来实现网络实时应用，也就是说如果浏览器对WebSocket兼容性差，Socket.io会自动选择最佳方式实现实时通信，非常方便和人性化。 Socket.io 官方文档： https://socket.io/get-started/chat/ WebSocket兼容几乎所有现代浏览器，IE 10+ Edge Firefox 4+ Chrome 4+ Safari 5+ Opera 11.5+ socket.io对浏览器做了很好的兼容。 下一篇讲述Socket.io客户端API 参考文档： https://www.zhihu.com/question/20215561

WebSocket是html5新增加的一种通信协议，目前流行的浏览器都支持这个协议，例如Chrome，Safari，Firefox，Opera，IE等等，对该协议支持最早的应该是chrome，从chrome12就已经开始支持，随着协议草案的不断变化，各个浏览器对协议的实现也在不停的更新。该协议还是草案，没有成为标准，不过成为标准应该只是时间问题了，从WebSocket草案的提出到现在已经有十几个版本了，目前最新的是版本17，所对应的协议版本号为13，目前对该协议支持最完善的浏览器应该是chrome，毕竟WebSocket协议草案也是Google发布的。1. WebSocket API简介首先看一段简单的javascript代码，该代码调用了WebSockets的API。[javascript] view plaincopyvar ws = new WebSocket(“ws://echo.websocket.org”); ws.onopen = function(){ws.send(“Test!”); }; ws.onmessage = function(evt){console.log(evt.data);ws.close();}; ws.onclose = function(evt){console.log(“WebSocketClosed!”);}; ws.onerror = function(evt){console.log(“WebSocketError!”);}; 这份代码总共只有5行，现在简单概述一下这5行代码的意义。第一行代码是在申请一个WebSocket对象，参数是需要连接的服务器端的地址，同http协议使用http://开头一样，WebSocket协议的URL使用ws://开头，另外安全的WebSocket协议使用wss://开头。第二行到第五行为WebSocket对象注册消息的处理函数，WebSocket对象一共支持四个消息 onopen, onmessage, onclose和onerror，当Browser和WebSocketServer连接成功后，会触发onopen消息；如果连接失败，发送、接收数据失败或者处理数据出现错误，browser会触发onerror消息；当Browser接收到WebSocketServer发送过来的数据时，就会触发onmessage消息，参数evt中包含server传输过来的数据；当Browser接收到WebSocketServer端发送的关闭连接请求时，就会触发onclose消息。咱们可以看出所有的操作都是采用消息的方式触发的，这样就不会阻塞UI，使得UI有更快的响应时间，得到更好的用户体验。

PHP即时通讯可以通过使用Socket实现。Socket是一种在计算机之间进行网络通信的API，允许程序员编写与网络协议的交互，以实现网络应用程序。下面是基于PHP Socket实现即时通讯的大体步骤：创建一个服务器端Socket，监听指定的端口。在PHP中可以使用socket_create()、socket_bind()和socket_listen()函数来完成这个步骤。当有客户端连接时，服务器端Socket会接受客户端的连接请求。在PHP中可以使用socket_accept()函数来接受连接请求，并创建一个客户端Socket。服务器端可以使用socket_write()函数将数据发送给客户端，客户端可以使用socket_read()函数读取服务器端发送的数据。客户端也可以使用socket_write()函数将数据发送给服务器端，服务器端可以使用socket_read()函数读取客户端发送的数据。在PHP中，可以使用socket_select()函数来检测是否有可读或可写的Socket，并进行相应的处理。需要注意的是，PHP Socket实现即时通讯需要处理诸如连接管理、消息路由、消息推送、消息持久化等一系列问题，这需要更为复杂的开发和调试过程。因此，如果您不具备相关的网络编程知识和经验，建议使用已有的即时通讯解决方案，如XMPP、WebSocket等。

还得有个后端服务器（固定IP地址）做websocket消息转发，只靠vue websocket搞不了的

目前要实现消息实时推送，有两种方法，一种是ajax轮询，由客户端不停地请求服务器端，查询有没有新消息，然后再由服务器返回结果；另外一种就是long poll,通过一次请求，询问服务器有没有新消息更新，如果没有新消息时，会保持长连接，就一直不返回Response给客户端。直到有消息才返回，返回完之后，客户端再次建立连接，周而复始。这两种都是单向链接，需要被动的请求服务器，而不是由服务器自动发给客户端。从上面可以看出其实这两种方式，都是在不断地建立HTTP连接，然后等待服务端处理，可以体现HTTP协议的另外一个特点，被动性。何为被动性呢，其实就是，服务端不能主动联系客户端，只能有客户端发起。简单地说就是，服务器是一个很懒的冰箱（这是个梗）（不会、不能主动发起连接），但是上司有命令，如果有客户来，不管多么累都要好好接待。

一个小数，

踩着年末的尾巴，提前布局来年，为来年的工作做个好的铺垫，所以就开始了面试历程，因为项目中使用到了 WebSocket ，面试官在深挖项目经验的时候，也难免提到 WebSocket 相关的知识点，因为之前并没有考虑这么深，所以，回答的还是有所欠缺，因此，赶紧趁热再熟悉熟悉，也借此机会，整理出来供大家咀嚼，每个项目都有其值得挖掘的闪光点，要用有爱的眼睛去发现。 WebSocket 是一种在单个TCP连接上进行全双工通信的协议。 WebSocket 使得客户端和服务器之间的数据交换变得更加简单，允许服务端主动向客户端推送数据。 在 WebSocket API 中，浏览器和服务器只需要完成一次握手，两者之间就直接可以创建持久性的连接， 并进行双向数据传输。（维基百科） WebSocket 本质上一种计算机网络应用层的协议，用来弥补 http 协议在持久通信能力上的不足。 WebSocket 协议在2008年诞生，2011年成为国际标准。现在最新版本浏览器都已经支持了。 它的最大特点就是，服务器可以主动向客户端推送信息，客户端也可以主动向服务器发送信息，是真正的双向平等对话，属于服务器推送技术的一种。 WebSocket 的其他特点包括： 我们已经有了 HTTP 协议，为什么还需要另一个协议？它能带来什么好处？ 因为 HTTP 协议有一个缺陷：通信只能由客户端发起，不具备服务器推送能力。 举例来说，我们想了解查询今天的实时数据，只能是客户端向服务器发出请求，服务器返回查询结果。HTTP 协议做不到服务器主动向客户端推送信息。 这种单向请求的特点，注定了如果服务器有连续的状态变化，客户端要获知就非常麻烦。我们只能使用"轮询"：每隔一段时候，就发出一个询问，了解服务器有没有新的信息。最典型的场景就是聊天室。轮询的效率低，非常浪费资源（因为必须不停连接，或者 HTTP 连接始终打开）。 在 WebSocket 协议出现以前，创建一个和服务端进双通道通信的 web 应用，需要依赖HTTP协议，进行不停的轮询，这会导致一些问题： http 协议本身是没有持久通信能力的，但是我们在实际的应用中，是很需要这种能力的，所以，为了解决这些问题， WebSocket 协议由此而生，于2011年被IETF定为标准RFC6455，并被RFC7936所补充规范。并且在 HTML5 标准中增加了有关 WebSocket 协议的相关 api ，所以只要实现了 HTML5 标准的客户端，就可以与支持 WebSocket 协议的服务器进行全双工的持久通信了。 WebSocket 与 HTTP 的关系图： 下面一张图说明了 HTTP 与 WebSocket 的主要区别： 不同点： 与http协议一样， WebSocket 协议也需要通过已建立的TCP连接来传输数据。具体实现上是通过http协议建立通道，然后在此基础上用真正 WebSocket 协议进行通信，所以WebSocket协议和http协议是有一定的交叉关系的。首先， WebSocket 是一个持久化的协议，相对于 HTTP 这种非持久的协议来说。简单的举个例子吧，用目前应用比较广泛的 PHP 生命周期来解释。 HTTP 的生命周期通过 Request 来界定，也就是一个 Request 一个 Response ，那么在 HTTP1.0 中，这次 HTTP 请求就结束了。 在 HTTP1.1 中进行了改进，使得有一个 keep-alive，也就是说，在一个 HTTP 连接中，可以发送多个 Request，接收多个 Response。但是请记住 Request = Response， 在 HTTP 中永远是这样，也就是说一个 Request 只能有一个 Response。而且这个 Response 也是被动的，不能主动发起。首先 WebSocket 是基于 HTTP 协议的，或者说借用了 HTTP 协议来完成一部分握手。 首先我们来看个典型的 WebSocket 握手 熟悉 HTTP 的童鞋可能发现了，这段类似 HTTP 协议的握手请求中，多了这么几个东西。 这个就是 WebSocket 的核心了，告诉 Apache 、 Nginx 等服务器：注意啦，我发起的请求要用 WebSocket 协议，快点帮我找到对应的助理处理~而不是那个老土的 HTTP 。 这里开始就是 HTTP 最后负责的区域了，告诉客户，我已经成功切换协议啦~ 依然是固定的，告诉客户端即将升级的是 WebSocket 协议，而不是 mozillasocket ，lurnarsocket 或者 shitsocket 。 然后， Sec-WebSocket-Accept 这个则是经过服务器确认，并且加密过后的 Sec-WebSocket-Key 。服务器：好啦好啦，知道啦，给你看我的 ID CARD 来证明行了吧。后面的， Sec-WebSocket-Protocol 则是表示最终使用的协议。至此，HTTP 已经完成它所有工作了，接下来就是完全按照 WebSocket 协议进行了。总结， WebSocket 连接的过程是： 优点： 缺点： 心跳就是客户端定时的给服务端发送消息，证明客户端是在线的， 如果超过一定的时间没有发送则就是离线了。 当客户端第一次发送请求至服务端时会携带唯一标识、以及时间戳，服务端到db或者缓存去查询改请求的唯一标识，如果不存在就存入db或者缓存中， 第二次客户端定时再次发送请求依旧携带唯一标识、以及时间戳，服务端到db或者缓存去查询改请求的唯一标识，如果存在就把上次的时间戳拿取出来，使用当前时间戳减去上次的时间， 得出的毫秒秒数判断是否大于指定的时间，若小于的话就是在线，否则就是离线； 通过查阅资料了解到 nginx 代理的 websocket 转发，无消息连接会出现超时断开问题。网上资料提到解决方案两种，一种是修改nginx配置信息，第二种是 websocket 发送心跳包。下面就来总结一下本次项目实践中解决的 websocket 的断线 和 重连 这两个问题的解决方案。主动触发包括主动断开连接，客户端主动发送消息给后端 主动断开连接，根据需要使用，基本很少用到。 下面主要讲一下客户端也就是前端如何实现心跳包： 首先了解一下心跳包机制 跳包之所以叫心跳包是因为：它像心跳一样每隔固定时间发一次，以此来告诉服务器，这个客户端还活着。事实上这是为了保持长连接，至于这个包的内容，是没有什么特别规定的，不过一般都是很小的包，或者只包含包头的一个空包。 在 TCP 的机制里面，本身是存在有心跳包的机制的，也就是 TCP 的选项： SO_KEEPALIVE 。系统默认是设置的2小时的心跳频率。但是它检查不到机器断电、网线拔出、防火墙这些断线。而且逻辑层处理断线可能也不是那么好处理。一般，如果只是用于保活还是可以的。 心跳包一般来说都是在逻辑层发送空的 echo 包来实现的。下一个定时器，在一定时间间隔下发送一个空包给客户端，然后客户端反馈一个同样的空包回来，服务器如果在一定时间内收不到客户端发送过来的反馈包，那就只有认定说掉线了。 在长连接下，有可能很长一段时间都没有数据往来。理论上说，这个连接是一直保持连接的，但是实际情况中，如果中间节点出现什么故障是难以知道的。更要命的是，有的节点(防火墙)会自动把一定时间之内没有数据交互的连接给断掉。在这个时候，就需要我们的心跳包了，用于维持长连接，保活。 心跳检测步骤： 针对这种异常的中断解决方案就是处理重连，下面我们给出的重连方案是使用js库处理：引入 reconnecting-websocket.min.js ，ws建立链接方法使用js库api方法： 断网监测支持使用js库： offline.min.js 以上方案，只是抛砖引玉，如果大家有更好的解决方案欢迎评论区分享交流。 WebSocket 是为了在 web 应用上进行双通道通信而产生的协议，相比于轮询HTTP请求的方式，WebSocket 有节省服务器资源，效率高等优点。WebSocket 中的掩码是为了防止早期版本中存在中间缓存污染攻击等问题而设置的，客户端向服务端发送数据需要掩码，服务端向客户端发送数据不需要掩码。WebSocket 中 Sec-WebSocket-Key 的生成算法是拼接服务端和客户端生成的字符串，进行SHA1哈希算法，再用base64编码。WebSocket 协议握手是依靠 HTTP 协议的，依靠于 HTTP 响应101进行协议升级转换。

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是一个持久化的协议，相对于HTTP这种非持久的协议来说。简单的举个例子吧，用目前应用比较广泛的PHP生命周期来解释。 HTTP的生命周期通过 Request 来界定，也就是一个 Request 一个 Response ，那么在 HTTP1.0 中，这次HTTP请求就结束了。 在HTTP1.1中进行了改进，使得有一个keep-alive，也就是说，在一个HTTP连接中，可以发送多个Request，接收多个Response。但是请记住 Request = Response ， 在HTTP中永远是这样，也就是说一个request只能有一个response。而且这个response也是被动的，不能主动发起。 教练，你BB了这么多，跟Websocket有什么关系呢？ (:з」∠) 好吧，我正准备说Websocket呢。。 首先Websocket是基于HTTP协议的，或者说借用了HTTP的协议来完成一部分握手。 首先我们来看个典型的 Websocket 握手（借用Wikipedia的。。） 熟悉HTTP的童鞋可能发现了，这段类似HTTP协议的握手请求中，多了几个东西。我会顺便讲解下作用。 这个就是Websocket的核心了，告诉 Apache 、 Nginx 等服务器：注意啦，我发起的是Websocket协议，快点帮我找到对应的助理处理~不是那个老土的HTTP。 首先， Sec-WebSocket-Key 是一个 Base64 encode 的值，这个是浏览器随机生成的，告诉服务器：泥煤，不要忽悠窝，我要验证尼是不是真的是Websocket助理。 然后， Sec_WebSocket-Protocol 是一个用户定义的字符串，用来区分同URL下，不同的服务所需要的协议。简单理解：今晚我要服务A，别搞错啦~ 最后， Sec-WebSocket-Version 是告诉服务器所使用的 Websocket Draft（协议版本），在最初的时候，Websocket协议还在 Draft 阶段，各种奇奇怪怪的协议都有，而且还有很多期奇奇怪怪不同的东西，什么Firefox和Chrome用的不是一个版本之类的，当初Websocket协议太多可是一个大难题。。不过现在还好，已经定下来啦 大家都使用的一个东西 脱水： 服务员，我要的是13岁的噢→_→ 然后服务器会返回下列东西，表示已经接受到请求， 成功建立Websocket啦！ 这里开始就是HTTP最后负责的区域了，告诉客户，我已经成功切换协议啦~ Upgrade: websocket Connection: Upgrade 依然是固定的，告诉客户端即将升级的是 Websocket 协议，而不是mozillasocket，lurnarsocket或者shitsocket。 然后， Sec-WebSocket-Accept 这个则是经过服务器确认，并且加密过后的 Sec-WebSocket-Key 。 服务器：好啦好啦，知道啦，给你看我的ID CARD来证明行了吧。。 后面的， Sec-WebSocket-Protocol 则是表示最终使用的协议。 至此，HTTP已经完成它所有工作了，接下来就是完全按照Websocket协议进行了。具体的协议就不在这阐述了。 ——————技术解析部分完毕—————— 你TMD又BBB了这么久，那到底Websocket有什么鬼用， http long poll ，或者ajax轮询 不都可以实现实时信息传递么。 好好好，年轻人，那我们来讲一讲Websocket有什么用。来给你吃点胡（苏）萝（丹）卜（红） 在讲Websocket之前，我就顺带着讲下 long poll 和 ajax轮询 的原理。 ajax轮询 ajax轮询的原理非常简单，让浏览器隔个几秒就发送一次请求，询问服务器是否有新信息。 场景再现： long poll long poll 其实原理跟 ajax轮询 差不多，都是采用轮询的方式，不过采取的是阻塞模型（一直打电话，没收到就不挂电话），也就是说，客户端发起连接后，如果没消息，就一直不返回Response给客户端。直到有消息才返回，返回完之后，客户端再次建立连接，周而复始。 场景再现： 从上面可以看出其实这两种方式，都是在不断地建立HTTP连接，然后等待服务端处理，可以体现HTTP协议的另外一个特点，被动性。 何为被动性呢，其实就是，服务端不能主动联系客户端，只能有客户端发起。 简单地说就是，服务器是一个很懒的冰箱（这是个梗）（不会、不能主动发起连接），但是上司有命令，如果有客户来，不管多么累都要好好接待。 说完这个，我们再来说一说上面的缺陷（原谅我废话这么多吧OAQ） 从上面很容易看出来，不管怎么样，上面这两种都是非常消耗资源的。 ajax轮询 需要服务器有很快的处理速度和资源。（速度）long poll 需要有很高的并发，也就是说同时接待客户的能力。（场地大小） 所以 ajax轮询 和 long poll 都有可能发生这种情况。 言归正传，我们来说Websocket吧 通过上面这个例子，我们可以看出，这两种方式都不是最好的方式，需要很多资源。 一种需要更快的速度，一种需要更多的"电话"。这两种都会导致"电话"的需求越来越高。 哦对了，忘记说了HTTP还是一个状态协议。 通俗的说就是，服务器因为每天要接待太多客户了，是个健忘鬼，你一挂电话，他就把你的东西全忘光了，把你的东西全丢掉了。你第二次还得再告诉服务器一遍。 所以在这种情况下出现了，Websocket出现了。他解决了HTTP的这几个难题。首先，被动性，当服务器完成协议升级后（HTTP->Websocket），服务端就可以主动推送信息给客户端啦。所以上面的情景可以做如下修改。 就变成了这样，只需要经过一次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 轮询 来 模拟出类似的效果

长连接： 一个链接上可以连续发送多个数据包，在链接期间，如果没有数据包发送，需要双方发链路检查包 TCP/IP: TCP/IP 属于传输层，主要解决网络中的数据传输问题，只管传输数据。但这样对传输的数据没有一个规范的封装、解析等处理。使得传输的数据难以识别，所以才有了应用层协议对数据进行的封装、解析等，如http协议。 HTTP: HTTP协议是应用层协议，用于分装解析传输数据。 从HTTP1.1开始其实就默认开启了长链接，也就是请求头header中可以看到Connection:Keep-alive。但是长连接只是说保持了（服务器可以告诉客户端保持时间Keep-Alive:timeout=20;max=20;）这个TCP通道，并采用服务器和客户端应答模式（Request-Response）,不需要再创建一个链接通道，做到一个性能优化。 socket: 与HTTP协议不一样，socket不是协议，他是在程序层面上对传输层协议（像TCP/IP）的接口封装。我们知道传输层的协议，是解决数据在网络中传输的问题的，那么socket(套接字)就是传输通道两端的接口。 Websocket: WebSocket是包装成了一个应用层协议作为socket,从而能够让客户端和远程服务端通过web建立全双工通信。 WebSocket API 是HTML5 推出的东西。在客户端我们可以通过HTML5 所提供的API 对websocket 进行创建、发送数据、监听信息、监听报错等功能( HTML5 WebSocket ) 我们知道WebSocket 是在Socket的基础上实现的，所以我们要做的是对现有的Socket协议进行升级。 步骤： 客户端发送websocket请求-->服务端接受并识别该请求-->对该请求协议进行升级--> 返回给客户端 --> websocket 通道建立 --> 客户端/服务端发送数据 协议升级 在这里需要注意的是头部信息和头部信息中的Sec-Websocket-Accept的值。 该值需要是一个通过base64加密的哈希值（sha1）。 而该加密所用的数据是客户端传过来的sec-websocket-key的值和MAGIC_STRINC内的固定值。 对MAGIC_STRINC的说明 Webscoket 中传输的数据是 数据帧（frame） 数据帧有多种类型 主要有：文本型、二进制数据 数据帧结构 每一列代表一个字节，一个字节8位，每一位又代表一个二进制数。 创建数据帧 解数据帧 心跳检查 由于websocket 不进行交互会关闭通道所以，才有了心跳检查。 websocket与和他http的区别 基于node实现websocket协议 使用nodeJS在HTTP上实现WebSocket 如何让我的服务器返回正确的Sec-WebSocket-Accept标头值 学习WebSocket协议—从顶层到底层的实现原理 websocket 协议帧 解析 nodejs实现Websocket的数据接收发送

注释1：WebSocket是一个接口，它的实现类RealWebSocket，该类完成WebSocket的连接、数据请求与接收功能。 注释1：将RealCall实例添加至Dispatcher中(下文会介绍Dispatcher)。 注释2：通过getResponseWithInterceptorChain()获取响应。 注释3：通过封装好的拦截器集合，获取第一个拦截器的任务。 注释4：触发第一个拦截器的任务，该任务就触发一下拦截器的任务，以此类推，原理(Android事件传递机制)如下图： 注释1：把AsyncCall请求对象传递进Dispatcher线程池管理； 注释2：通过getResponseWithInterceptorChain()获取响应; 注释1：获取自定义线程池； 注释2：判断正在执行的异步请求数量与请求集合中相同host的数量是否满足，如果满足就添加到执行中的集合中，并添加至线程池中执行请求；如果不满足就添加至待执行请求的集合中，等待执行中的请求完成之后，再执行相同host数量判断满足才添加至线程池中执行请求； 注释3：将请求对象AsyncCall添加进请求执行的集合中； 注释4：将请求对象AsyncCall添加进线程池中执行； 注释5：当不满足执行条件时(注释2)，把请求对象添加至待执行的集合中； 注释6：每当一个请求执行完毕时，就会调用finished()去掉对应集合中的存储对象，并在次判断待执行的集合中是否有满足条件的请求，若满足就添加至执行的集合与线程池中执行，若不满足继续等待下一个请求完成再次判断。 注释7：判断待执行的集合中是否满足可执行的对象。 2.RealConnection与HttpCodec初始化(RealConnection在ConnectInterceptor中通过StreamAllocation的newStream()初始化，而HttpCodec在RealConnection中被初始化)

Http协议是无状态的，只能由客户端主动发起，服务端再被动响应，服务端无法向客户端主动推送内容，并且一旦服务器响应结束，链接就会断开所以无法进行实时通信。WebSocket协议正是为解决客户端与服务端实时通信而产生的技术，现在已经被主流浏览器支持。目前 Flutter也提供了专门的包来支持WebSocket协议。 web_socket_channel package 提供了我们需要连接到WebSocket服务器的工具。该package提供了一个 WebSocketChannel 允许我们既可以监听来自服务器的消息，又可以将消息发送到服务器的方法。 执行flutter pub get 命令，即可 1. 连接到WebSocket服务器 2. 监听来自服务器的消息 使用一个 StreamBuilder 来监听新消息， 并用一个Text来显示它们 工作原理 WebSocketChannel 提供了一个来自服务器的消息 Stream 。该 Stream 类是 dart:async 包中的一个基础类。它提供了一种方法来监听来自数据源的异步事件。与 Future 返回单个异步响应不同， Stream 类可以随着时间推移传递很多事件。该 StreamBuilder 组件将连接到一个 Stream ， 并在每次收到消息时通知Flutter重新构建界面 3. 将数据发送到服务器 为了将数据发送到服务器，我们会add消息给WebSocketChannel提供的sink。 WebSocketChannel 提供了一个 StreamSink ，它将消息发给服务器 StreamSink 类提供了给数据源同步或异步添加事件的一般方法 4. 关闭WebSocket连接 思考: 假如我们想通过WebSocket传输二进制数据应该怎么做（比如要从服务器接收一张图片）？我们发现StreamBuilder和Stream都没有指定接收类型的参数，并且在创建WebSocket链接时也没有相应的配置，貌似没有什么办法……其实很简单，要接收二进制数据仍然使用StreamBuilder，因为WebSocket中所有发送的数据使用帧的形式发送，而帧是有固定格式，每一个帧的数据类型都可以通过Opcode字段指定，它可以指定当前帧是文本类型还是二进制类型（还有其它类型），所以客户端在收到帧时就已经知道了其数据类型，所以flutter完全可以在收到数据后解析出正确的类型，所以就无需开发者去关心，当服务器传输的数据是指定为二进制时，StreamBuilder的snapshot.data的类型就是List<int>，是文本时，则为String。 https://book.flutterchina.club/chapter11/websocket.html

我的世界“wsserver”指“WebSocket Server”。此命令用于连接WebSocket服务器，WebSocket服务器使用命令信息与客户端交互。主要用于教育版中。亦可使用/connect实现相同功能。

在室内环境无法使用卫星定位时，使用室内定位技术作为卫星定位的辅助定位，解决卫星信号到达地面时较弱、不能穿透建筑物的问题。最终定位物体当前所处的位置。

在上一章 Asyncio 协议Protocol 与 传输Transport 中我们提到了关于Asyncio提供的网络服务器。 main.py → run() 是uvicorn的启动入口，他可以从uvicorn.run调用启动，也可以从命令行启动。 之前的一篇 Uvicorn 基本了解 介绍了关于如何启动Uvicorn。 main.py → run() 会创建若干个 class Server 的实例，通常为一个，代表Uvicorn服务器自身。 Server 会进行初始化，例如构建前半的中间件堆栈(starlette中的我们可以称之为后半)。初始化完成后，服务器会在main_loop()中不断循环来维护自身状态。 在初始化阶段，Server会构建Asyncio的网络服务器。 流程如下： 到此为止，两大部分就都构建完成了，进入运行时状态 class H11Protocol(asyncio.Protocol) 是由uvicorn提供的一个基于H11协议库实现的Protocol，它是整个uvicorn通信的核心(如果选用httptools库就是HttpToolsProtocol) 可以看到，接收到数据，首先是将数据加入到缓冲区。然后再进行处理。 我们可以看到其具有 send 和 receive 两个方法。让人感到很熟悉。 这里的app，是指uvicorn构建的中间件堆栈，我们切回 Config 类 起初这个 loaded_app 为 starlette 的实例。 最终构成了 ProxyHeadersMiddleware 为起点，endpointApp为终点的App链(中间件堆栈包含于其中) Uvicorn中间件堆栈 → Starlette实例 → Starlette中间件堆栈 → Router → endpoint/cbv 这就是整个服务器的全貌 我们来看一send和receive方法 send中，包含了大量的服务器状态切换，其逻辑极为复杂。尤其是关于服务器的状态机方面，让人头昏眼花。 在发送的时候，报文分至少三次发送： receive的使用比较少，在传统http请求中基本不需要，主要是用于websocket，在此不多做介绍。 到此为止，在starlette中看到的send，receive和scope三者的来源，我们已经搞清了。 关于Uvicorn的更深一步探索，我们将将在未来进行。目前的准备还不够充分，贸然进行容易出现错误。

没有信令服务器，各个WebRTC之间是没办法通信的。 传递媒体数据有两个信息，必须经过信令服务器进行交换 通过SDP来表示，如编解码器是什么？是否支持音频视频？编码方式是什么？等 这些信息是通过SDP协议描述出来，通过信令服务器中转的 两个WebRTC客户端会尽可能选择P2P进行连接，那么进行连接前是如何发现对方的？就是通过信令服务器。 首先将你所有网络相关信息传到信令服务器，服务器帮你交换到对端，对端拿到你的信息后， 若在同一局域网内，直接通过P2P传输；若不在，首先进行P2P穿越，看是否能打通，打通则传输，打不通则中转等。 还有一点也需要信令服务器进行传输，比如加入房间，离开房间，禁言等功能 在传输时，一般有两种协议 TCP和 UDP 底层协议使用 UDP主要用于流媒体传输（音频视频）还有文本，文字聊天等，但 UDP是不可靠传输，是可以丢包的，当然音频视频是可以丢包的，丢失一帧只会卡顿下，还可以继续工作。 但信令服务器不能丢失数据，所有的包必须保证到达，否则断开连接，所以信令服务器一般使用TCP可靠性传输。 websocket底层使用的就是 TCP协议， socket.io 使用的也是TCP 在websocket官方中，是有三个服务器的，ROOM服务器（提供用户进出房间服务）、信令服务器、流媒体（中转）服务器 选用socket.io 即不用单独写ROOM服务器，这里ROOM和信令是同一个服务器 socket.io是一个基于Nodejs的库，在现有的Node Server上增加个socket.io即可 在任何终端都可以引入socket.io客户端的库，通过客户端的库就可以连接到 Nodejs中 socket.io服务器上 这样就可以建立连接，然后就可以创建，加入房间，这样房间内的人就可以通信了 多个 socke.io可以串行通信。

一些参考内容: 用户的需求通常是: 希望web页面更具交互性. 而解决方案就是使用javascript. 而这一切的推动力又是Ajax. Ajax是异步javascript和xml的缩写(Asynchronous Javascript and XML), 利用这种技术, 可以让远程服务器和客户端保持数据同步. 但在这个机制中XML并非必须的, 它只是作为数据传递的载体, 实际很多时候是使用JSON来进行传递(很多时候又叫AJAJ). 使用Ajax的最大好处是: 客户端不必刷新整个页面就可以实现同服务器的数据交换, 而这种交换对于用户来说可以是透明的. 但这样也造成一个难题: 由于客户端是主动从服务器获取新数据, 但客户端怎么获知数据的更新呢? 过去14年间(2000年开始算起), 针对上面的问题, 出现了各种各样的解决方案. 主要有四种形式的解决办法: 1999年的时候, 在HTTP1.1规范内就提供了一种功能, 可以用在任何HTTP数据交流过程中的功能, 叫做HTTP Upgrade. 作用原理如下: HTTP Upgrade最好的地方是: 指定的协议几乎可以是任意的. 当HTTP握手结束后就会释放掉之前的HTTP连接. 理论上讲, 使用HTTP Upgrade, 可以建立起任意的两端点间的任意TCP Socket连接(甚至可以是持久的, 全双工的TCP socket连接), 并且连接上工作的协议可以是你自己设计的. 当然, 浏览器不可能将客户端程序员推入到TCP协议栈的深渊让他们自己针对HTTP Upgrade开发自己的协议. 所以由专门机构开发了一些协议出来, 而WebSockets协议正是其中之一. WebSocket连接的建立过程: 使用WebSocket协议的好处很多, 主要和它的实现有关: 虽然原理很复杂, 但是已经有现成的API了, 要做的就是在上面构建你自己的应用即可... 而WebSocket的API又分为客户端API和服务端API. 不同点只是对不同工作内容的支持不同而已. 用途基本上没有任何限制, 比如浏览器应用, 以及任何支持平台上的客户端应用.下面是一些典型用途: 和HTTP协议一样, 由于是信息交流的规范或标准. 所以使用WebSocket建立的不同应用理论上说都可以相互通信, 不管是哪个平台, 什么类型的. 正是因为如此, 所以大多数WebSocket的实现中都将自己分为客户端和服务器端工具两个部分. 比如Java或.net. 而Javascript中只是有客户端工具的部分, 因为它本身就是用作客户端脚本的. 下面先来使用JavaScript的客户端工具建立客户端, 然后再转到Java的服务端(当然Java也有客户端的API,只是使用Java实现客户端还是交给android中去吧...) W3C规定将浏览器中的WebSocket支持接口作为HTML5的扩展. 故虽然使用的是Javascript来实现WebSocket的交流, 但实际上WebSocket接口是HTML5的组成部分.任何浏览器都可以通过WebSocket接口的implementation来实现WebSocket通信.(早期的Ajax通信则是不同浏览器有不同的类和不同的方法来做Ajax请求, 比起现在可以说复杂很多) 下面就来建立客户端. WebSocket API是从Java EE7开始加入进来的, 在规范JSR 356可以查到. 它里面包含了客户端以及服务端的API. 客户端API是基础API: 包含了一个WebSocket端所必须的基本类和接口(在javax.websocket包中). 服务端API: 建立在客户端API之上并对客户端API进行了扩展(javax.websocket.server包中). 所以针对Java的WebSocket API, 有两大部分组件: 仅用于客户端的API或完整版API(服务端API). API的详细使用需要查看Java EE7的API文档. 下面分别来看看这两个部分的API. 关于Tomcat中WebSocket连接数的限制, 实际就是TCP连接的最大数目: TO reach the max alive websocket connection in Tomcat, following config changes need to be done. Change this to from 50 till 65535. The above configuration changes allows around ~50k live connections in a 2GB Intel Core i5 machine provided the server and client are running in different machines. 下面是一些连接数限制的尝试: https://blog.krecan.net/2010/05/02/cool-tomcat-is-able-to-handle-more-than-13000-concurrent-connections/ http://grokbase.com/t/tomcat/users/132d14c1q0/achieve-large-number-of-concurrent-websocket-connections-40000-50000 https://github.com/rstoyanchev/spring-websocket-portfolio/issues/52 https://support.appharbor.com/discussions/problems/26648-websockets-max-concurrent-connections-request-queue-limit https://mrotaru.wordpress.com/2013/10/10/scaling-to-12-million-concurrent-connections-how-migratorydata-did-it/ 经典做法

只要在页面上引入pace.js和相关的css，并不需要对业务逻辑做什么修改，就能拥有网页加载进度条，只要大家发挥想象力，那除了默认的进度条之外还能开发各种加载进度效果，使用起来非常方便。那问题来了：pace.js是如何做到“自动”监控加载进度的呢？pace.js监控了什么：pace.js对于加载进度监控了什么呢？通过阅读源码，我们看到整体的进度有四个部分组成：document，elements，eventLag和ajax这四种监视器（Monitor）。那接下来就来看看它们分别是什么。首先是document。document就是我们所熟悉的HTMLDocument节点。document节点有一个事件，onreadystatechange，当document的readyState状态变化时会触发。因为无法准确的知道document到底加载了多少百分比，所以就用这个状态来做一个估算。在pace.js中将document的readyState的三个状态loadong，interactive和complete分别定义为0%，50%和100%。通过监听document节点的readyState状态变更，形成了pace.js的DocumentMonitor。接下来是elements。我们可以通过配置传入一个css选择器列表，默认的选择器列表仅包含“body”。pace.js会按照设置的时间间隔搜索所有的选择器，如果能获得则认为这一项满足，所以elements这一项的加载进度就是 满足的选择器/全部的选择器。通过查询页面中制定的元素，就是pace.js的ElementMonitor。然后是eventLag。EventLagMonitor其实只是一个“假的”监视器。它就在那里安静匀速的更新进度，这一小小的措施却带来了不错的用户体验，让用户不会因为加载“卡住了”而慌张。pace.js是如何监控ajax的：最后是用来监控ajax进度的AjaxMonitor。这是最有趣的一部分。如何才能监控所有ajax请求，并且不需要开发者修改自己或第三方的业务逻辑呢？如果了解原生js的话，应该了解这几个类：XMLHttpRequest，XDomainRequest，WebSocket。这三个类分别用来发送ajax请求，跨域的ajax请求，以及websocket。如果能监控所有这些请求的时间，包括progress，load，error等等，我们就可以更新我们的加载进度了。既然我们知道了要监控的对象，那我们便可以“请君入瓮”了，而这个瓮，就是代理模式：我们可以把原生的类保存起来，再用我们自己写的埋藏了“间谍”的类覆盖原生的类，这样当其他代码建立这些类的实例的时候，我们的“间谍”便悄悄开始监听加载进度了。让我们来看一下代码：12345678910111213141516171819202122232425262728// 保存原生的XMLHttpRequest_XMLHttpRequest = window.XMLHttpRequest;// 覆盖XMLHttpRequestwindow.XMLHttpRequest = function(flags) { var req; // 调用原生的XMLHttpRequest req = new _XMLHttpRequest(flags); // 埋入我们的“间谍” monitorXHR(req); return req;};monitorXHR = function(req) { var _open; // “间谍”又对open方法埋入了间谍 _open = req.open; return req.open = function(type, url, async) { if (shouldTrack(type)) { _this.trigger("request", { type: type, url: url, request: req }); } return _open.apply(req, arguments); };};通过代理模式埋了这些“间谍”后，我们就能对发起的ajax请求等做到监控，以更新加载进度。当然pace.js也不是什么都监听了除了以上这些，当然也有pace.js并没有监听的加载事件，比如script标签的加载。如果我们使用了sea.js或者require.js等，当js代码动态加载时并不会影响进度条，因为这里我们用动态建立script标签的方式加载js代码，而pace.js并没有对这方面进行监听。我们可以同样的代理appendChild方法，如果发现script标签被加到页面上，那么就监听它的加载进度。不过实际情况当然复杂的多，还有insertBefore，甚至innerHTML等方法都可以创建script标签加入文档并开始js的加载（当然一般就是appendChild和insertBefore啦）。相似的还有css的加载，还要注意处理css的加载事件，在一些老的浏览器上，css并没有加载事件，还有加个定时不断检查css节点的cssRules和name来确定加载状况。小结：通过阅读pace.js的源码我们了解了pace.js的原理，同时学习了鸡贼的代理模式。比如在jasmine.js中也有个spy，可以监控制定函数被调用了几次，被什么参数调用了等等。灵活应用这种代理模式，可以方便我们扩展功能、进行调试等等。

java 后台做 websocket 服务端。 页面使用js的websocket客户端 连接上 服务端 就能实时通信了。

如果遇见了一个全新的协议，怎么从零开始，完成接口测试？以 WebSocket 为例。 WebSocket 协议在2008年诞生，2011年成为国际标准。现在所有浏览器都已经支持了。WebSocket 的最大特点就是，服务器可以主动向客户端推送信息，客户端也可以主动向服务器发送信息，是真正的双向平等对话。 WebSocket 的其他特点： 1. 建立在 TCP 协议之上，服务器端的实现比较容易。 2. 与 HTTP 协议有着良好的兼容性。默认端口也是80和443，并且握手阶段采用 HTTP 协议，因此握手时不容易屏蔽，能通过各种 HTTP 代理服务器。 3. 数据格式比较轻量，性能开销小，通信高效。 4. 可以发送文本，也可以发送二进制数据。 5. 没有同源限制，客户端可以与任意服务器通信。 6. 协议标识符是ws（如果加密，则为wss），服务器网址就是 URL。 · ws–>http（未加密） 无证书 · wss–>https（加密） 有证书 第一步： 很多时候第一反应向开发工程师求助，因为开发工程师基于新协议已经完成了接口开发，向开发工程师求助显然是最好的办法。找到一些学习脉络，包含了协议的说明文档、代码开发文档、实现代码等内容，了解协议的原理。向开发求助是个方法。 那么 WebSocket 用 Fiddler 怎么搞定？，其实主要就是修改了 Fiddler 中 Rules 下的 Customize Rules，如果感兴趣可以自己去搜一下。当面对陌生技术问题的时候，应该使用最熟悉的技术去尝试解决问题。虽然 Fiddler 截获 WebSocket 接口的办法，所截获的全部消息都在日志里面，根本无法操作。但是，可以借助 Fiddler 分析 WebSocket 的接口，一开始给 Fiddler 这款工具的定位一样，那就是通过它辅助分析我们的被测接口。处理HTTP、HTTPS，推荐用Fiddler。 但是在处理TCP,UDP 就用WireShark。Websocket是应用层协议，建立在 TCP 协议之上，服务器端的实现比较容易。因为应用层是在传输层的基础上包装数据，所以我们还是从底层开始了解Websocket到底是个啥?是如何工作的? 可以通过---- wireshark（网络封包分析软件）抓包工具抓到WebSocket接口 wireshark下载地址：https://www.wireshark.org/download.html 以下是python实现的websocket 接口连接。

WebSocket的出现是基于Web应用的实时性需要而产生的。这种实时的Web应用大家应该不陌生，在生活中都应该用到过，比如新浪微博的评论、私信的通知，腾讯的WebQQ等。让我们来回顾下实时 Web 应用的窘境吧。在WebSocket出现之前，一般通过两种方式来实现Web实时用：轮询机制和流技术；其中轮询有不同的轮询，还有一种叫Comet的长轮询。轮询：这是最早的一种实现实时 Web 应用的方案。客户端以一定的时间间隔向服务端发出请求，以频繁请求的方式来保持客户端和服务器端的同步。这种同步方案的缺点是，当客户端以固定频率向服务 器发起请求的时候，服务器端的数据可能并没有更新，这样会带来很多无谓的网络传输，所以这是一种非常低效的实时方案。长轮询：是对定时轮询的改进和提高，目地是为了降低无效的网络传输。当服务器端没有数据更新的时候，连接会保持一段时间周期直到数据或状态改变或者 时间过期，通过这种机制来减少无效的客户端和服务器间的交互。当然，如果服务端的数据变更非常频繁的话，这种机制和定时轮询比较起来没有本质上的性能的提 高。流：常就是在客户端的页面使用一个隐藏的窗口向服务端发出一个长连接的请求。服务器端接到这个请求后作出回应并不断更新连接状态以保证客户端和服务 器端的连接不过期。通过这种机制可以将服务器端的信息源源不断地推向客户端。这种机制在用户体验上有一点问题，需要针对不同的浏览器设计不同的方案来改进 用户体验，同时这种机制在并发比较大的情况下，对服务器端的资源是一个极大的考验。上述方式其实并不是真正的实时技术，只是使用了一种技巧来实现的模拟实时。在每次客户端和服务器端交互的时候都是一次 HTTP 的请求和应答的过程，而每一次的 HTTP 请求和应答都带有完整的 HTTP 头信息，这就增加了每次传输的数据量。但这些方式最痛苦的是开发人员，因为不论客户端还是服务器端的实现都很复杂，为了模拟比较真实的实时效果，开发人员 往往需要构造两个HTTP连接来模拟客户端和服务器之间的双向通讯，一个连接用来处理客户端到服务器端的数据传输，一个连接用来处理服务器端到客户端的数 据传输，这不可避免地增加了编程实现的复杂度，也增加了服务器端的负载，制约了应用系统的扩展性。基于上述弊端，实现Web实时应用的技术出现了，WebSocket通过浏览器提供的API真正实现了具备像C/S架构下的桌面系统的实时通讯能 力。其原理是使用JavaScript调用浏览器的API发出一个WebSocket请求至服务器，经过一次握手，和服务器建立了TCP通讯，因为它本质 上是一个TCP连接，所以数据传输的稳定性强和数据传输量比较小。WebSocket 协议WebSocket 协议本质上是一个基于 TCP 的协议。为了建立一个 WebSocket 连接，客户端浏览器首先要向服务器发起一个 HTTP 请求，这个请求和通常的 HTTP 请求不同，包含了一些附加头信息，其中附加头信息”Upgrade: WebSocket”表明这是一个申请协议升级的 HTTP 请求，服务器端解析这些附加的头信息然后产生应答信息返回给客户端，客户端和服务器端的 WebSocket 连接就建立起来了，双方就可以通过这个连接通道自由的传递信息，并且这个连接会持续存在直到客户端或者服务器端的某一方主动的关闭连接。下面我们来详细介绍一下 WebSocket 协议，由于这个协议目前还是处于草案阶段，版本的变化比较快，我们选择目前最新的 draft-ietf-hybi-thewebsocketprotocol-17 版本来描述 WebSocket 协议。因为这个版本目前在一些主流的浏览器上比如 Chrome,、FireFox、Opera 上都得到比较好的支持。通过描述可以看到握手协议客户端发到服务器的内容: 代码如下 复制代码 GET /chat HTTP/1.1 Host: server.example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Origin: http://example.com Sec-WebSocket-Protocol: chat, superchat Sec-WebSocket-Version: 13从服务器到客户端的内容: 代码如下 复制代码 HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= Sec-WebSocket-Protocol: chat这些请求和通常的 HTTP 请求很相似，但是其中有些内容是和 WebSocket 协议密切相关的。我们需要简单介绍一下这些请求和应答信息，”Upgrade:WebSocket”表示这是一个特殊的 HTTP 请求，请求的目的就是要将客户端和服务器端的通讯协议从 HTTP 协议升级到 WebSocket 协议。其中客户端的Sec-WebSocket-Key和服务器端的Sec-WebSocket-Accept就是重要的握手认证信息了，这些内容将在服 务器端实现的博文中讲解。相信通过上文的讲解你应该对WebSocket有了个初步认识了，如果有任何疑问欢迎交流。 客户端如概念篇中介绍的握手协议，客户端是由浏览器提供了API，所以只要使用JavaScript来简单调用即可，而服务器端是要自己实现的，服务器端将在下个博文来讲。 代码如下 复制代码 WebSocket JavaScript 接口定义:[Constructor(in DOMString url, optional in DOMString protocol)]interface WebSocket {readonly attribute DOMString URL;// ready stateconst unsigned short CONNECTING = 0;const unsigned short OPEN = 1;const unsigned short CLOSED = 2;readonly attribute unsigned short readyState;readonly attribute unsigned long bufferedAmount; // networkingattribute Function onopen;attribute Function onmessage;attribute Function onclose;boolean send(in DOMString data);void close();};WebSocket implements EventTarget; 简单了解下接口方法和属性：readyState表示连接有四种状态：CONNECTING (0)：表示还没建立连接；OPEN (1)： 已经建立连接，可以进行通讯；CLOSING (2)：通过关闭握手，正在关闭连接；CLOSED (3)：连接已经关闭或无法打开；url是代表 WebSocket 服务器的网络地址，协议通常是”ws”或“wss(加密通信)”,send 方法就是发送数据到服务器端；close 方法就是关闭连接；onopen连接建立，即握手成功触发的事件；onmessage收到服务器消息时触发的事件；onerror异常触发的事件；onclose关闭连接触发的事件；JavaScript调用浏览器接口实例如下： 代码如下 复制代码 var wsServer = "ws://localhost:8888/Demo"; //服务器地址var websocket = new WebSocket(wsServer); //创建WebSocket对象websocket.send("hello");//向服务器发送消息alert(websocket.readyState);//查看websocket当前状态websocket.onopen = function (evt) {//已经建立连接};websocket.onclose = function (evt) {//已经关闭连接};websocket.onmessage = function (evt) {//收到服务器消息，使用evt.data提取};websocket.onerror = function (evt) {//产生异常};

g因为http有同步和异步发送，我在刷新浏览器的时候，是可以捕获到浏览器刷新时间，向服务器发送请求，这时候是发送同步请求，如果服务端不响应，我不关闭浏览器，就是保证这个请求不中断，但是用websokcet发送不出去，因为浏览器刷新，请求中断了，

Socket，WebSocket，Http，Tcp等这些我们已经听的耳朵有茧了，但是用得时候还是复习一下吧。 大学学习网络基础的时候老师讲过，网络由下往上分为物理层、数据链路层、网络层、传输层、会话层、表示层和应用层。通过初步的了解，我知道IP协议对应于网络层，TCP协议对应于传输层，而HTTP协议对应于应用层，三者从本质上来说没有可比性，socket则是对TCP/IP协议的封装和应用（程序员层面上）。也可以说，TPC/IP协议是传输层协议，主要解决数据如何在网络中传输，而HTTP是应用层协议，主要解决如何包装数据。关于TCP/IP和HTTP协议的关系，网络有一段比较容易理解的介绍： “我们在传输数据时，可以只使用（传输层）TCP/IP协议，但是那样的话，如果没有应用层，便无法识别数据内容，如果想要使传输的数据有意义，则必须使用到应用层协议，应用层协议有很多，比如HTTP、FTP、TELNET等，也可以自己定义应用层协议。WEB使用HTTP协议作应用层协议，以封装HTTP文本信息，然后使用TCP/IP做传输层协议将它发到网络上。” 而我们平时说的最多的socket是什么呢，实际上socket是对TCP/IP协议的封装，Socket本身并不是协议，而是一个调用接口（API），通过Socket，我们才能使用TCP/IP协议。实际上，Socket跟TCP/IP协议没有必然的联系。Socket编程接口在设计的时候，就希望也能适应其他的网络协议。所以说，Socket的出现只是使得程序员更方便地使用TCP/IP协议栈而已，是对TCP/IP协议的抽象，从而形成了我们知道的一些最基本的函数接口，比如create、listen、connect、accept、send、read和write等等。网络有一段关于socket和TCP/IP协议关系的说法比较容易理解： “TCP/IP只是一个协议栈，就像操作系统的运行机制一样，必须要具体实现，同时还要提供对外的操作接口。这个就像操作系统会提供标准的编程接口，比如win32编程接口一样，TCP/IP也要提供可供程序员做网络开发所用的接口，这就是Socket编程接口。” 关于TCP/IP协议的相关只是，用博大精深来讲我想也不为过，单单查一下网上关于此类只是的资料和书籍文献的数量就知道，这个我打算会买一些经典的书籍（比如《TCP/IP详解：卷一、卷二、卷三》）进行学习，今天就先总结一些基于基于TCP/IP协议的应用和编程接口的知识，也就是刚才说了很多的HTTP和Socket。 CSDN上有个比较形象的描述： HTTP是轿车，提供了封装或者显示数据的具体形式； Socket是发动机，提供了网络通信的能力。 实际上，传输层的TCP是基于网络层的IP协议的，而应用层的HTTP协议又是基于传输层的TCP协议的，而Socket本身不算是协议，就像上面所说，它只是提供了一个针对TCP或者UDP编程的接口。 下面是一些经常在笔试或者面试中碰到的重要的概念，特在此做摘抄和总结。一什么是TCP连接的三次握手第一次握手：客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。 握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。理想状态下，TCP连接一旦建立，在通信双方中的任何一方主动关闭连接之前，TCP连接都将被一直保持下去。断开连接时服务器和客户端均可以主动发起断开TCP连接的请求，断开过程需要经过“四次握手”（过程就不细写了，就是服务器和客户端交互，最终确定断开）二利用Socket建立网络连接的步骤建立Socket连接至少需要一对套接字，其中一个运行于客户端，称为ClientSocket，另一个运行于服务器端，称为ServerSocket。套接字之间的连接过程分为三个步骤：服务器监听，客户端请求，连接确认。1、服务器监听：服务器端套接字并不定位具体的客户端套接字，而是处于等待连接的状态，实时监控网络状态，等待客户端的连接请求。2、客户端请求：指客户端的套接字提出连接请求，要连接的目标是服务器端的套接字。为此，客户端的套接字必须首先描述它要连接的服务器的套接字，指出服务器端套接字的地址和端口号，然后就向服务器端套接字提出连接请求。3、连接确认：当服务器端套接字监听到或者说接收到客户端套接字的连接请求时，就响应客户端套接字的请求，建立一个新的线程，把服务器端套接字的描述发给客户端，一旦客户端确认了此描述，双方就正式建立连接。而服务器端套接字继续处于监听状态，继续接收其他客户端套接字的连接请求。三HTTP链接的特点 HTTP协议即超文本传送协议(Hypertext Transfer Protocol )，是Web联网的基础，也是手机联网常用的协议之一，HTTP协议是建立在TCP协议之上的一种应用。 HTTP连接最显著的特点是客户端发送的每次请求都需要服务器回送响应，在请求结束后，会主动释放连接。从建立连接到关闭连接的过程称为“一次连接”。四、TCP和UDP的区别（考得最多。。快被考烂了我觉得）1、TCP是面向链接的，虽然说网络的不安全不稳定特性决定了多少次握手都不能保证连接的可靠性，但TCP的三次握手在最低限度上（实际上也很大程度上保证了）保证了连接的可靠性；而UDP不是面向连接的，UDP传送数据前并不与对方建立连接，对接收到的数据也不发送确认信号，发送端不知道数据是否会正确接收，当然也不用重发，所以说UDP是无连接的、不可靠的一种数据传输协议。2、也正由于1所说的特点，使得UDP的开销更小数据传输速率更高，因为不必进行收发数据的确认，所以UDP的实时性更好。知道了TCP和UDP的区别，就不难理解为何采用TCP传输协议的MSN比采用UDP的QQ传输文件慢了，但并不能说QQ的通信是不安全的，因为程序员可以手动对UDP的数据收发进行验证，比如发送方对每个数据包进行编号然后由接收方进行验证啊什么的，即使是这样，UDP因为在底层协议的封装上没有采用类似TCP的“三次握手”而实现了TCP所无法达到的传输效率。 简单总结：HTTP协议：简单对象访问协议，对应于应用层 ，HTTP协议是基于TCP连接的。TCP协议： 对应于传输层。IP协议： 对应于网络层。TCP/IP是传输层协议，主要解决数据如何在网络中传输；而HTTP是应用层协议，主要解决如何包装数据。Socket是对TCP/IP协议的封装，Socket本身并不是协议，而是一个调用接口（API），通过Socket，我们才能使用TCP/IP协议。HTTP连接：HTTP连接就是所谓的短连接，即客户端向服务器端发送一次请求，服务器端响应后连接即会断掉；Socket连接：Socket连接就是所谓的长连接，理论上客户端和服务器端一旦建立起连接将不会主动断掉；但是由于各种环境因素可能会是连接断开，比如说：服务器端或客户端主机down了，网络故障，或者两者之间长时间没有数据传输，网络防火墙可能会断开该连接以释放网络资源。所以当一个Socket连接中没有数据的传输，那么为了维持连接需要发送心跳消息~~具体心跳消息格式是开发者自己定义的。WebSocket WebSocket是HTML5开始提供的一种浏览器与服务器间进行全双工通讯的网络技术。 WebSocket通信协定于2011年被IETF定为标准 RFC 6455，WebSocketAPI被W3C定为标准。 在WebSocket API中，浏览器和服务器只需要要做一个握手的动作，然后，浏览器和服务器之间就形成了一条快速通道。两者之间就直接可以数据互相传送。现在，很多网站为了实现推送技术，所用的技术都是轮询。轮询是在特定的的时间间隔（如每1秒），由浏览器对服务器发出HTTP request，然后由服务器返回最新的数据给客户端的浏览器。这种传统的模式带来很明显的缺点，即浏览器需要不断的向服务器发出请求，然而HTTP request的header是非常长的，里面包含的数据可能只是一个很小的值，这样会占用很多的带宽和服务器资源。 而比较新的技术去做轮询的效果是Comet，使用了AJAX。但这种技术虽然可达到双向通信，但依然需要发出请求，而且在Comet中，普遍采用了长链接，这也会大量消耗服务器带宽和资源。 面对这种状况，HTML5定义了WebSocket协议，能更好的节省服务器资源和带宽并达到实时通讯。握手协议在实现Websocket连线过程中，需要透过浏览器发出Websocket连线请求，然后服务器发出回应，这个过程通常称为“握手” (handshaking)。PS:后期的版本大多属于功能上的扩充，例如使用第7版的握手协议同样也适用于第8版的握手协议。浏览器请求GET / HTTP/1.1Upgrade: websocketConnection: UpgradeHost: example.comOrigin: nullSec-WebSocket-Key: sN9cRrP/n9NdMgdcy2VJFQ==Sec-WebSocket-Version: 13服务器回应HTTP/1.1 101 Switching ProtocolsUpgrade: websocketConnection: UpgradeSec-WebSocket-Accept: fFBooB7FAkLlXgRSz0BT3v4hq5s=Sec-WebSocket-Origin: nullSec-WebSocket-Location: ws://example.com/原理在请求中的“Sec-WebSocket-Key”是随机的，服务器端会用这些数据来构造出一个SHA-1的信息摘要。把“Sec-WebSocket-Key”加上一个魔幻字符串“258EAFA5-E914-47DA-95CA-C5AB0DC85B11”。使用 SHA-1 加密，之后进行 BASE-64编码，将结果做为“Sec-WebSocket-Accept”头的值，返回给客户端。客户端的Websocket对象一共绑定了四个事件：1、onopen：连接建立时触发；2、onmessage：收到服务端消息时触发；3、onerror：连接出错时触发；4、onclose：连接关闭时触发；有了这4个事件，我们就可以很容易很轻松的驾驭websocket，并且需要说明的是websocket支持二进制数据的传输，因此，它远不止聊天室应用这么简单。WebSocket API是下一代客户端-服务器的异步通信方法。该通信取代了使用ws或wss协议的单个的TCP套接字，可用于任意的客户端和服务器程序WebSocket API最伟大之处在于在任意时刻服务器和客户端可以相互推送信息。WebSocket并不限于以Ajax(或XHR)方式通信，Ajax技术需要客户端发起请求，而WebSocket服务器和客户端可以彼此相互推送信息；XHR受到域的限制，而WebSocket是允许跨域通信。

双屏互动原理描述：现在多数双屏互动的实现方式主要是依靠浏览器的WebSocket即时通信技术，包括国外许多案例，在以前传统的网站为了实现这种技术基本都是轮询，在一个特定的时间内，由客户端向服务端发出请求，之后服务器返回到浏览器，这种传统的实现方法需要客户端不停的向服务端请求数据，而且其传输的数据可能是一个很小的值。在 WebSocket API中，浏览器和服务器只需要要做一个握手的动作，然后浏览器和服务器之间就形成了一条快速通道，两者之间就可以直接实时的互相传送数据。采用websocket技术的页面不同于普通页面，而是需要特殊的服务器环境支持。 服务器环境的搭建：目前支持WebSocket环境有很多方式，比如PHP、Java、.Net、Tomcat、Nodejs等，还有html5 的websocket方案，但是目前在我国浏览器使用情况上，IE用户还占有50%左右的市场份额，html5 的websocket只能支持IE10+和其他高端浏览器，在兼容性方面socket.io做的很好，所以对于前端工程师，我们优先选Nodejs和socket.io来搭建WebSocket服务器端。前期我们可以在自己电脑搭建与服务器一致的环境来测试，本地搭建的方法:1. 下载官方Node.js，安装可以一直下一步，我个人习惯都会自定义安装软件2. 安装Nodejs 的模块管理器npm（官网最新版Nodejs已集成，无需单独安装）3. 命令窗口模式安装 socket.io（npm install socket.io）（这里如果遇到安装不成功情况，注意考虑设置一下代理，设置方法：npm config set proxy=地址:端口号，运气实在不好的话从其他电脑复制同版本文件夹也一样）4. 最后查看安装的模块及版本：npm list

在网速快速提升的时代，浏览器已经成为我们访问各种服务的入口，很难想象如果离开了浏览器，我们的网络世界应该如何运作。现在恨不得把操作系统都搬上浏览器。但是并不是所有的应用都需要浏览器来执行，比如服务器和服务器之间的通信，就需要使用到自建客户端来和服务器进行交互。 本文将会介绍使用netty客户端连接websocket的原理和具体实现。 在介绍netty客户端之前，我们先看一个简单的浏览器客户端连接websocket的例子： 这里使用了浏览器最通用的语言javascript，并使用了浏览器提供的websocket API进行操作，非常的简单。 那么用netty客户端实现websocket的连接是否和javascript使用一样呢？我们一起来 探索 。 先看看netty对websocket的支持类都有哪些，接着我们看下怎么具体去使用这些工具类。 和websocket server一样，client中最核心的类也是handshaker，这里叫做WebSocketClientHandshaker。这个类有什么作用呢？一起来看看。 这个类主要实现的就是client和server端之间的握手。 我们看一下它的最长参数的构造类： 参数中有websocket连接的URI，像是：”ws://flydean.com/mypath”。 有请求子协议的类型subprotocol，有自定义的HTTP headers：customHeaders，有最大的frame payload的长度：maxFramePayloadLength，有强制timeout关闭的时间，有使用HTTP协议进行升级的URI地址。 怎么创建handshaker呢？同样的，netty提供了一个WebSocketClientHandshakerFactory方法。 WebSocketClientHandshakerFactory提供了一个newHandshaker方法，可以方便的创建各种不同版本的handshaker: 可以看到，根据传入协议版本的不同，可以分为WebSocketClientHandshaker13、WebSocketClientHandshaker08、WebSocketClientHandshaker07、WebSocketClientHandshaker00这几种。 通常来说，对于webSocket协议，为了提升传输的性能和速度，降低网络带宽占用量，在使用过程中通常会带上额外的压缩扩展。为了处理这样的压缩扩展，netty同时提供了服务器端和客户端的支持。 对于服务器端来说对应的handler叫做WebSocketServerCompressionHandler，对于客户端来说对应的handler叫做WebSocketClientCompressionHandler。 通过将这两个handler加入对应pipline中，可以实现对websocket中压缩协议扩展的支持。 对于协议的扩展有两个级别分别是permessage-deflate和perframe-deflate，分别对应PerMessageDeflateClientExtensionHandshaker和DeflateFrameClientExtensionHandshaker。 至于具体怎么压缩的，这里就不详细进行讲解了， 感兴趣的小伙伴可以自行了解。 前面讲解了netty对websocket客户端的支持之后，本节将会讲解netty到底是如何使用这些工具进行消息处理的。 首先是按照正常的逻辑创建客户端的Bootstrap，并添加handler。这里的handler就是专门为websocket定制的client端handler。 除了上面提到的WebSocketClientCompressionHandler，就是自定义的handler了。 在自定义handler中，我们需要处理两件事情，一件事情就是在channel ready的时候创建handshaker。另外一件事情就是具体websocket消息的处理了。 首先使用WebSocketClientHandshakerFactory创建handler： 然后在channel active的时候使用handshaker进行握手连接： 然后在进行消息接收处理的时候还需要判断handshaker的状态是否完成，如果未完成则调用handshaker.finishHandshake方法进行手动完成： 当handshake完成之后，就可以进行正常的websocket消息读写操作了。 websocket的消息处理比较简单，将接收到的消息转换成为WebSocketFrame进行处理即可。 本文讲解了netty提供的websocket客户端的支持和具体的对接流程，大家可以再次基础上进行扩展，以实现自己的业务逻辑。 本文的例子可以参考：learn-netty4

疯狂创客圈 Java 高并发【 亿级流量聊天室实战】实战系列 【 博客园总入口 】 架构师成长+面试必备之 高并发基础书籍 【 Netty Zookeeper Redis 高并发实战 】 很多项目，都需要基于 Websocket 协议做在线客服、在线推送、在线聊天，虽然 Tomcat 内置支持 Websocket 协议，但是由于 Tomcat 的吞吐量、连接数都很低，作为测试是可以的。 在生产环境，一定需要使用高吞吐量、高连接数的 Netty 服务器进行替代 。 之所以 Netty 性能高，因为其使用的是 Reactor 反应器模式。关于反应器模式原理，请参见 《Netty Zookeeper Redis 高并发实战》 一书。 聊天过程gif 演示： 聊天示意图： Netty搭建的服务器基本上都是差不多的写法： 绑定主线程组和工作线程组，这部分对应架构图中的事件循环组。其原理，，请参见 《Netty Zookeeper Redis 高并发实战》 一书。 重点就是ChannelInitializer的配置，以异步的方式启动，最后是结束的时候关闭线程组。 下面是用websocket做聊天室的逻辑： 源码网址： Java 高并发研习社群 【 博客园 总入口 】 疯狂创客圈 经典图书 ： 《Netty Zookeeper Redis 高并发实战》 面试必备 + 面试必备 + 面试必备

写在最前面：由于现在游戏基本上采用全球大区的模式，全球玩家在同一个大区进行游戏，传统的单服模式已经不能够满足当前的服务需求，所以现在游戏服务器都在往微服务架构发展。当前我们游戏也是利用微服务架构来实现全球玩家同服游戏。 玩家每次断线（包括切换网络/超时断线）后应该会重新连接服务器，重连成功的话可以继续当前情景继续游戏，但是之前写的底层重连机制一直不能生效，导致每次玩家断线后重连都失败，要从账号登陆开始重新登陆，该文章写在已经定位了重连问题是由SLB引起后，提出的解决方案。 每次重连后，客户端向SLB发送建立连接，SLB都会重新分配一个网关节点，导致客户端连接到其他网关，重连失败。 会话保持的作用是什么？ 开启SLB会话保持功能后，SLB会记录客户端的IP地址，在一定时间内，自动将同一个IP的连接转发到上次连接的网关。 在网络不稳定的情况下，游戏容易心跳或者发包超时，开启会话保持，能解决大部分情况下的重连问题。 但是在切换网络的时候，手机网络从Wifi切换成4G，自身IP会变，这时候连接必定和服务器断开，需要重新建立连接。由于IP已经变化，SLB不能识别到是同一个客户端发出的请求，会将连接转发到其他网关节点。所以使用TCP连接的情况下，SLB开启会话保持并不能解决所有的重连问题。 另外某些时刻，手机频繁开启和断开WI-FI，有时候可能不会断开网络，这并不是因为4G切换WI-FI时网络没断开，从4G切换到Wi-Fi网络，因为IP变了，服务器不能识别到新的IP，连接肯定是断开的。这时候网络没断开，主要是因为现在智能手机会对4G和Wi-Fi网络做个权重判断，当Wi-Fi网络频繁打开关闭时，手机会判断Wi-Fi网络不稳定，所有流量都走4G。所以网络没断开是因为一直使用4G连接，才没有断开。想要验证，只需要切换Wi-Fi时，把4G网络关闭，这样流量就必定走Wi-Fi。 上面说过，四层的TCP协议主要是基于IP来实现会话保持。但是切换网络的时候客户端的IP会变。所以要解决切换网络时的重连问题，只有两个方法：1. 当客户端成功连接网关节点后，记录下网关节点的IP，下次重连后不经过SLB，直接向网关节点发送连接请求。2.使用 SLB的七层（HTTP）转发服务。 当客户端经过SLB将连接转发到网关时，二次握手验证成功后向客户端发送自己节点的IP，这样客户端下次连接的时候就能直接连接网关节点。但是这样会暴露网关的IP地址，为安全留下隐患。 如果不希望暴露网关的IP地址，就需要增加一层代理层，SLB将客户端请求转发到代理层，代理层再根据客户端带有的key，转发到正确的网关节点上。增加一层代理层，不仅会增加请求的响应时间，还会增加整体框架的复杂度。 阿里云的七层SLB会话保持服务，主要是基于cookie的会话保持。客户端在往服务器发送HTTP请求后，服务器会返回客户端一个Response，SLB会在这时候，将经过的Response插入或者重写cookie。客户端获取到这个cookie，下次请求时会带上cookie，SLB判断Request的Headers里面有cookie，就将连接转发到之前的网关节点。 HTTP是短链接，我们游戏是长连接，所以用HTTP肯定不合适。但是可以考虑基于HTTP的WebSocket。 什么是WebSocket？ WSS（Web Socket Secure）是WebSocket的加密版本。 SLB对WebSocket的支持 查看阿里云SLB文档对WS的支持，说明SLB是支持WS协议的，并且SLB对于WS无需配置，只需要选用HTTP监听时，就能够转发WS协议。说明WS协议在SLB这边看来就是一个HTTP，这样WS走的也是七层的转发服务。只要SLB能够正常识别WS握手协议里Request的cookie和正常识别服务器返回的Response并且往里面插入cookie，就可以利用会话保持解决重连问题。 Go语言实现WS服务器有两种方法，一种是利用golang.org/x/net下的websocket包，另外一种方法就是自己解读Websocket协议来实现，由于WS协议一样是基于TCP协议之上，完全可以通过监听TCP端口来实现。 客户端发送Request消息 服务器返回Response消息 其中服务器返回的Sec-WebSocket-Accept字段，主要是用于客户端需要验证服务器是否支持WS。RFC6455文档中规定，在WebSocket通信协议中服务端为了证实已经接收了握手，它需要把两部分的数据合并成一个响应。一部分信息来自客户端握手的Sec-WebSocket-Keyt头字段：Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==。对于这个字段，服务端必须得到这个值（头字段中经过base64编码的值减去前后的空格）并与GUID"258EAFA5-E914-47DA-95CA-C5AB0DC85B11"组合成一个字符串，这个字符串对于不懂WebSocket协议的网络终端来说是不能使用的。这个组合经过SHA-1掩码，base64编码后在服务端的握手中返回。如果这个Sec-WebSocket-Accept计算错误浏览器会提示：Sec-WebSocket-Accept dismatch 如果返回成功，Websocket就会回调onopen事件 游戏服务器的使用的TCP协议，是在协议的包头使用4Byte来声明本协议长度，然后将协议一次性发送。但是在WS协议是通过Frame形式发送的，会将一条消息分为几个frame，按照先后顺序传输出去。这样做会有几个好处： websocket的协议格式： 参数说明如下： 阿里云的SLB开启HTTP监听后，会检查过往的Request和Response请求，收到服务器返回的Response后，会往Response插入一个Cookie 客户端收到服务器的Response后，可以在Header中查到有个“Set-Cookie”字段，里面是SLB插入的Cookie值 客户端断开连接后，下次发送请求需要往Headers插入Cookie字段 分别在阿里云的两台ECS实例上部署WS服务器，打开8000端口，开启一个SLB服务，SLB服务选择HTTP方式监听，并且打开会话保持功能，Cookie处理方式选择植入Cookie。Demo服务器没有做HTTP健康监听的处理，健康检查这块可以先关掉。 在两台ECS上启动WS服务器，然后本地运行客户端，分别测试两台服务器是否能正常连接，测试完毕后，测试SLB能否正常工作。服务器和SLB都正常的情况下，运行客户端，客户端会得到以下结果 收到的三次Cookie都相同，说明Cookie是有正常植入工作的，并且三次都被SLB正确抓取了。 收到的三次serverId也都是同样的值，说明三次都是同一个ECS上的服务器响应。 至此，验证成功。 Websocket+SLB会话保持能够解决超时重连和切换网络时重连的问题。 参考： 阿里云会话保持 解答Wi-Fi与4G网络切换的困惑 WebSocket的实现原理 阿里云SLB对WebSocket的支持 HTTP Headers和Cookie

一、socket协议的简介 WebSocket是什么，有什么优点 WebSocket是一个持久化的协议，这是相对于http非持久化来说的。应用层协议 举个简单的例子，http1.0的生命周期是以request作为界定的，也就是一个request，一个response，对于http来说，本次client与server的会话到此结束；而在http1.1中，稍微有所改进，即添加了keep-alive，也就是在一个http连接中可以进行多个request请求和多个response接受操作。然而在实时通信中，并没有多大的作用，http只能由client发起请求，server才能返回信息，即server不能主动向client推送信息，无法满足实时通信的要求。而WebSocket可以进行持久化连接，即client只需进行一次握手，成功后即可持续进行数据通信，值得关注的是WebSocket实现client与server之间全双工通信，即server端有数据更新时可以主动推送给client端。 二、介绍client与server之间的socket连接原理 1、下面是一个演示client和server之间建立WebSocket连接时握手部分 2、client与server建立socket时握手的会话内容，即request与response a、client建立WebSocket时向服务器端请求的信息 GET /chat HTTP/1.1 　　Host: server.example.com 　　Upgrade: websocket //告诉服务器现在发送的是WebSocket协议 　　Connection: Upgrade 　　Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw== //是一个Base64 encode的值，这个是浏览器随机生成的，用于验证服务器端返回数据是否是WebSocket助理 　　Sec-WebSocket-Protocol: chat, superchat 　　Sec-WebSocket-Version: 13 　　Origin: http://example.com b、服务器获取到client请求的信息后，根据WebSocket协议对数据进行处理并返回，其中要对Sec-WebSocket-Key进行加密等操作 HTTP/1.1 101 Switching Protocols 　　Upgrade: websocket //依然是固定的，告诉客户端即将升级的是Websocket协议，而不是mozillasocket，lurnarsocket或者shitsocket 　　Connection: Upgrade 　　Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk= //这个则是经过服务器确认，并且加密过后的 Sec-WebSocket-Key,也就是client要求建立WebSocket验证的凭证 　　Sec-WebSocket-Protocol: chat 3、socket建立连接原理图： 三、PHP中建立websocket的过程讲解 SocketService.php: web.html:

学习，找到对的方向是很重要的，一个好的开始意味着你已经成功了一半。前端学习路线主要有三点，下面我将像你详细介绍下：一、初级阶段：前端初体验，感受视觉冲击，提升学习兴趣，打消学习疑虑PS入门（前端UI协同工具蓝湖与标你妹工具使用)HTML5，cSS3(大量CSS3网页特效制作)移动端布局基础(媒体查询、页面适配)，响应式页面布局。二、中级阶段：夯实基础，打通任督二脉，杜绝做一个API的搬运工JS入门，DOM操作，BOM，H5常用新API，Jquery之DOM操作，Ajax ;JS高阶，面向对象(OOP)，原型、原型链，执行上下文栈，作用域、作用域链，This，闭包，ES6/ES7.Jquery页面特效+插件封装;服务器知识Node.js (Express4) , MongoDB(mongoose)/Mysql. Websocket.三、高级阶段：通往前端实战之路，时下最新开发框架与使用技巧，杜绝过时技术炒剩饭Vue全家桶(Vue2.x+Vue-Router3.x+Vuex3.x+ElementUl2.x+Axios0.9)React全家桶(React16.x+React-Route-Dom5.x+Redux4.x+React-Redux+Redux-Thunk)微信小程序（登录态+微信支付)Webpack4.x

它的工作原理是Pub-Sub（发布和订阅）。它适用于发送者将数据（发布者）发送给抽象数量的收件人（订阅者），而无需指定他们是谁。根据定义，WebSocket是通过单个TCP连接提供全双工（双向通信）通信信道的计算机通信协议。此WebSocket API可在用户的浏览器和服务器之间进行双向通信。用户可以向服务器发送消息并接收事件驱动的响应，而无需轮询服务器。它可以让多个用户连接到同一个实时服务器，并通过API进行通信并立即获得响应。WebSockets允许用户和服务器之间的流连接，并允许即时信息交换。在聊天应用程序的示例中，通过套接字汇集消息，可以实时与一个或多个用户交换，具体取决于谁在服务器上“监听”（连接）。WebSockets不仅限于聊天／消息传递应用程序。它们适用于需要实时更新和即时信息交换的任何应用程序。一些示例包括但不限于：现场体育更新，股票行情，多人游戏，聊天应用，社交媒体等等。WebSockets还会考虑代理和防火墙等危险，使得任何连接都可以进行流式传输。它支持单个连接的上游和下游通信。它还减轻了服务器的负担，允许现有机器支持同时连接。

你可以把 WebSocket 看成是 HTTP 协议为了支持长连接所打的一个大补丁，它和 HTTP 有一些共性，是为了解决 HTTP 本身无法解决的某些问题而做出的一个改良设计。在以前 HTTP 协议中所谓的 keep-alive connection 是指在一次 TCP 连接中完成多个 HTTP 请求，但是对每个请求仍然要单独发 header；所谓的 polling 是指从客户端（一般就是浏览器）不断主动的向服务器发 HTTP 请求查询是否有新数据。这两种模式有一个共同的缺点，就是除了真正的数据部分外，服务器和客户端还要大量交换 HTTP header，信息交换效率很低。它们建立的“长连接”都是伪.长连接，只不过好处是不需要对现有的 HTTP server 和浏览器架构做修改就能实现。WebSocket 解决的第一个问题是，通过第一个 HTTP request 建立了 TCP 连接之后，之后的交换数据都不需要再发 HTTP request了，使得这个长连接变成了一个真.长连接。但是不需要发送 HTTP header就能交换数据显然和原有的 HTTP 协议是有区别的，所以它需要对服务器和客户端都进行升级才能实现。在此基础上 WebSocket 还是一个双通道的连接，在同一个 TCP 连接上既可以发也可以收信息。此外还有 multiplexing 功能，几个不同的 URI 可以复用同一个 WebSocket 连接。这些都是原来的 HTTP 不能做到的。另外说一点技术细节，因为看到有人提问 WebSocket 可能进入某种半死不活的状态。这实际上也是原有网络世界的一些缺陷性设计。上面所说的 WebSocket 真.长连接虽然解决了服务器和客户端两边的问题，但坑爹的是网络应用除了服务器和客户端之外，另一个巨大的存在是中间的网络链路。一个 HTTP/WebSocket 连接往往要经过无数的路由，防火墙。你以为你的数据是在一个“连接”中发送的，实际上它要跨越千山万水，经过无数次转发，过滤，才能最终抵达终点。在这过程中，中间节点的处理方法很可能会让你意想不到。比如说，这些坑爹的中间节点可能会认为一份连接在一段时间内没有数据发送就等于失效，它们会自作主张的切断这些连接。在这种情况下，不论服务器还是客户端都不会收到任何提示，它们只会一厢情愿的以为彼此间的红线还在，徒劳地一边又一边地发送抵达不了彼岸的信息。而计算机网络协议栈的实现中又会有一层套一层的缓存，除非填满这些缓存，你的程序根本不会发现任何错误。这样，本来一个美好的 WebSocket 长连接，就可能在毫不知情的情况下进入了半死不活状态。而解决方案，WebSocket 的设计者们也早已想过。就是让服务器和客户端能够发送 Ping/Pong Frame（RFC 6455 - The WebSocket Protocol）。这种 Frame 是一种特殊的数据包，它只包含一些元数据而不需要真正的 Data Payload，可以在不影响 Application 的情况下维持住中间网络的连接状态。

、TCP连接手机能够使用联网功能是因为手机底层实现了TCP/IP协议，可以使手机终端通过无线网络建立TCP连接。TCP协议可以对上层网络提供接口，使上层网络数据的传输建立在逗无差别地的网络之上。建立起一个TCP连接需要经过逗三次握手地：第一次握手：客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。理想状态下，TCP连接一旦建立，在通信双方中的任何一方主动关闭连接之前，TCP 连接都将被一直保持下去。断开连接时服务器和客户端均可以主动发起断开TCP连接的请求，断开过程需要经过逗四次握手地（过程就不细写了，就是服务器和客户端交互，最终确定断开）2、HTTP连接HTTP协议即超文本传送协议(Hypertext Transfer Protocol )，是Web联网的基础，也是手机联网常用的协议之一，HTTP协议是建立在TCP协议之上的一种应用。HTTP连接最显著的特点是客户端发送的每次请求都需要服务器回送响应，在请求结束后，会主动释放连接。从建立连接到关闭连接的过程称为逗一次连接地。1）在HTTP 1.0中，客户端的每次请求都要求建立一次单独的连接，在处理完本次请求后，就自动释放连接。2）在HTTP 1.1中则可以在一次连接中处理多个请求，并且多个请求可以重叠进行，不需要等待一个请求结束后再发送下一个请求。由于HTTP在每次请求结束后都会主动释放连接，因此HTTP连接是一种逗短连接地，要保持客户端程序的在线状态，需要不断地向服务器发起连接请求。通常的做法是即时不需要获得任何数据，客户端也保持每隔一段固定的时间向服务器发送一次逗保持连接地的请求，服务器在收到该请求后对客户端进行回复，表明知道客户端逗在线地。若服务器长时间无法收到客户端的请求，则认为客户端逗下线地，若客户端长时间无法收到服务器的回复，则认为网络已经断开。3、SOCKET原理3.1套接字（socket）概念套接字（socket）是通信的基石，是支持TCP/IP协议的网络通信的基本操作单元。它是网络通信过程中端点的抽象表示，包含进行网络通信必须的五种信息：连接使用的协议，本地主机的IP地址，本地进程的协议端口，远地主机的IP地址，远地进程的协议端口。应用层通过传输层进行数据通信时，TCP会遇到同时为多个应用程序进程提供并发服务的问题。多个TCP连接或多个应用程序进程可能需要通过同一个 TCP协议端口传输数据。为了区别不同的应用程序进程和连接，许多计算机操作系统为应用程序与TCP／IP协议交互提供了套接字(Socket)接口。应用层可以和传输层通过Socket接口，区分来自不同应用程序进程或网络连接的通信，实现数据传输的并发服务

flv.js 就是由 bilibili 网站开源的 HTML5 Flash 视频（FLV）播放器，纯原生 JavaScript 开发（ECMAScript 6 编写） ，没有用到 Flash。它的工作原理是 Flv.js 在 JavaScript 中流式解析 flv 文件流，并实时转封装为 fmp4 ，通过 Media Source Extensions 喂给浏览器，实现了 FLV 格式视频的播放。 具有H.264 + AAC / MP3编解码器播放功能的FLV容器 多段分段视频播放 HTTP FLV低延迟实时流播放 通过WebSocket进行FLV实时流播放 与Chrome，FireFox，Safari 10，IE11和Edge兼容 极低的开销，浏览器可以加速硬件！ 1、准备一个flv格式的视频 我的文件，关于分片上传可参考 vue中使用Plupload分片上传

知道WebSocket的原理就好解决：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数据，就是这样=。=再简单来说，层级不一样。

启动php sever服务client新建一个websocket对象连接后端client发送数据给后端服务器接受数据后返回数据client接收到返回数据继续下一步我这边有个聊天室的demo就是这样做的，很简答

知道WebSocket的原理就好解决：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数据，就是这样=。=再简单来说，层级不一样。

workerman客户端连不上怎么办？客户端连接失败原因连接失败客户端一般会有两种报错，connection refuse 和 connection timeoutconnection refuse（连接拒绝）一般是以下原因:1、客户端连接的端口错了2、客户端连接的域名或者ip错了3、如果客户端使用了域名连接，域名可能指向了错误的服务器ip4、服务端没有启动或者端口没有被监听5、使用了网络代理软件6、服务端监听ip与访问地址不在一个地址段。例如服务端监听127.0.0.1，则客户端只能通过127.0.0.1连接，不能通过局域网ip或者外网ip连接。建议监听地址设置为0.0.0.0，这样本机、内网、外网都可以连接。connection timeout（连接超时）一般是以下原因：1、服务器防火墙阻止了连接，可以临时关闭防火墙试下2、如果是云服务器，安全组也可能会阻止连接建立，需要到管理后台开放对应端口3、服务器不存在或者没有启动4、如果客户端使用了域名连接，域名可能指向了错误的服务器ip5、客户端访问的ip是服务器内网ip，并且客户端和服务端不在一个局域网其它报错如果发生的报错不是connection refuse 和 connection timeout则一般是以下原因：1、客户端使用的通讯协议与服务端不一致。例如服务端是http通讯协议，客户端使用websocket通讯协议访问是无法连接的。如果客户端用websocket协议连接，那么服务端必须也是websocket协议。如果服务端是http协议的服务，那么客户端必须用http协议访问。这里的原理类似如果你要和英国人交流，那么要使用英语。如果要和日本人交流，那么要使用日语。这里的语言就类似通讯协议，双方(客户端和服务端)必须使用相同的语言才能交流，否则无法通讯。通讯协议不一致导致的常见的报错有：WebSocket connection to "ws://xxx.com:xx/" failed: Error during WebSocket handshake: Unexpected response code: xxxWebSocket connection to "ws://xxx.com:xx/" failed: Error during WebSocket handshake: net::ERR_INVALID_HTTP_RESPONSE解决办法：从上面两条报错看出，客户端使用的是ws连接是websocket协议。服务端也需要是websocket协议才行，服务端监听部分代码需要指定websocket协议才能通讯，例如下面这样如果是gatewayWorker，监听部分代码类似// websocket协议，这样客户端才能用ws://...来连。xxxx为端口不用改动$gateway = new Gateway("websocket://0.0.0.0:xxxx");如果是Workerman则是// websocket协议，这样客户端才能用ws://...来连。xxxx为端口不用改动$worker = new Worker("websocket://0.0.0.0:xxxx");推荐：workerman教程

知道WebSocket的原理就好解决：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协议可以为网站和应用提供真正的双向通信，具有控制开销、保持连接状态、更强实时性、更好的压缩效果等优点，是当下低延时应用最常采用的一种技术协议。 HTML5定义 的WebSocket协议是基于TCP的一种新的网络协议。它实现了浏览器与服务器全双工(full-duplex)通信，即允许服务器主动发送信息给客户端。因此，WebSocket使得客户端和服务器之间的数据交换变得更加简单，允许服务端主动向客户端推送数据。在WebSocket API中，浏览器和服务器只需要完成一次握手，两者之间就直接可以创建持久性的连接，并进行双向数据传输。 WebSocket能更好的节省服务器资源和带宽，并且能够更实时地进行通讯，它的优势： u2022 较少的控制开销。 在连接创建后，服务器和客户端之间交换数据时，用于协议控制的数据包头部相对较小。 u2022 更强的实时性。 由于协议是全双工的，所以服务器可以随时主动给客户端下发数据。相对于HTTP请求需要等待客户端发起请求服务端才能响应，延迟明显更少；即使是和Comet等类似的长轮询比较，其也能在短时间内更多次地传递数据。 u2022 保持连接状态。 与HTTP不同的是，Websocket需要先创建连接，这就使得其成为一种有状态的协议，之后通信时可以省略部分状态信息。而HTTP请求可能需要在每个请求都携带状态信息（如身份认证等）。 u2022 更好的二进制支持。 Websocket定义了二进制帧，相对HTTP，可以更轻松地处理二进制内容。 u2022 可以支持扩展。 Websocket定义了扩展，用户可以扩展协议、实现部分自定义的子协议。 u2022 更好的压缩效果。 相对于HTTP压缩，Websocket在适当的扩展支持下，可以沿用之前内容的上下文，在传递类似的数据时，可以显著地提高压缩率。 一、 在线聊天速度慢，断开连接较快，不能更好的保持业务通讯 二、 网页通讯信息更安全，连接更稳定 三、 提供更高效的网页通讯 四、 网络抖动带来的连接时断时续问题 五、 访问打不开网页，需要刷新页面 六、 同时在线人数多，如何实时推送所有用户 七、 服务端支持WebSocket协议 八、 如何降低带宽，保证成本 总之，如果你的应用需要提供多个用户相互交流，或者展示服务器端经常变动的数据，就十分需要使用WebSocket技术。 阿里云CDN服务全球30多万家客户，涵盖视频、教育、政府、游戏、金融、社交、电商等各大行业场景，其中有几个典型的业务场景，可以利用平台技术优势，更好地解决实时通讯业务需求。DCDN已经支持WebSocket协议，可以应用在以下场景之中： 弹幕的流程是终端用户A在自己的客户端广播了一条信息，这条信息需要在与其他N个用户端发送的弹幕信息一并展示在A这边。它需要马上显示到屏幕上，对实时性要求极高。在今年S8赛事总决赛中，虎牙直播就采用全站加速WebSocket协议，更从容地应对2000万在线超高并发流量下更实时、更猛烈的互动考验。 在线教育跨越了时空的限制，学生与老师进行一对多/一对一的在线授课，老师在客户端内编写的笔记、大纲、白板信息等信息，需要实时推送至多个学生的客户端，同时在课堂上，通话、文字聊天、实时解题等交互的实时性要求非常高，需要通过WebSocket协议来完成。 股票价格瞬息万变，如果显示数据不及时，很有可能会影响用户的收益。需要通过WebSocket协议流式更新数据变化，将价格实时推送至世界各地的客户端，方便交易员迅速做出交易判断。 由于全世界体育爱好者数量众多，比赛实况成为他们最为关心的热点。如果你是提供体育新闻类服务，WebSocket能够助力你的用户降低延时，获得实时的更新。 尽管视频会议并不能代替和真人相见，但是应用场景众多。而互动直播和视频会议中的连麦的服务对低延时的要求非常高。试想主播或者你的主管说了一句话后，你要10秒后才能听到，那你们是根本无法进行正常交流的 。WebSocket可以帮助两端或多端接入会议/直播的用户实时传递信息。 阿里云自主研发的全站加速产品 DCDN（Dynamic Route for Content Delivery Network），是融合了动态加速和静态加速技术的 CDN 产品。该产品旨在提升动静态资源混合站点的访问体验，支持静态资源边缘缓存，动态内容最优路由回源传输，同时满足整体站点的全网访问速度及稳定性需求。一站式解决了页面动静态资源混杂、跨运营商、网络不稳定、单线源站、突发流量、网络拥塞等诸多因素导致的响应慢、丢包、服务不稳定的问题，提升全站性能和用户体验。全站加速构建于阿里云 CDN 平台之上，适用于动静混合型、纯动态型站点或应用的内容分发加速服务。 您可以通过以下架构图，了解全站加速的工作原理。 全站加速 DCDN 特点 便捷接入： 站点无需动静态内容拆分加速，一键接入解决网络拥塞，提高访问成功率； 智能加速： 加速方案更智能，多种分发策略，边缘缓存、最优路由、压缩传输，访问效率提升 60%； 稳定极速： 1500+ 全球节点，120T 带宽能力，六大洲覆盖，国内主流运营商支持； 内容安全： 全链路加密传输，集成多种访问控制方式，增强源站防护能力，为文件，视频的传输保驾护航。

知道WebSocket的原理就好解决：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是html5出的东西（协议），也就是说http协议没有变化，或者说没关系，但http是不支持持久连接的（长连接，循环连接的不算）首先http有1.1和1.0之说，也就是所谓的keep-alive，把多个http请求合并为一个，但是websocket其实是一个新协议，跟http协议基本没有关系，只是为了兼容现有浏览器的握手规范而已，也就是说它是http协议上的一种补充另外html5是指的一系列新的api，或者说新规范，新技术。http协议本身只有1.0和1.1，而且跟html本身没有直接关系。。通俗来说，你可以用http协议传输非html数据，就是这样=。=再简单来说，层级不一样。

你先看看socket的原理

优就业软件测试课程内容刚刚迭代升级，新增移动端测试，包括App兼容性测dao试，7*24小时稳定性测试，功耗性能测试，UI测试，交互测试等，课程主要学习的内容有：1、功能测试主要包括计算机基础、软件测试核心理论、Linux、数据库，学习目标是掌握软件测试核心理论，结合Linux、数据库等可实现移动端、web端的功能测试。学完可胜任功能测试工程师的职位。2、自动化测试主要学习Python、自动化测试入门、Web自动化测试、App自动化测试，培养方向是掌握自动化测试各类元素定位和操作方法;掌握自动化测试框架unittest使用和断言方法;掌握自动生成测试报告的方法。学完可胜任自动化测试测试工程师的职位。3、接口测试主要学习接口测试核心理论、接口测试工具Jmeter、接口测试工具Postman、抓包工具Fiddler、Jenkins持续集成、Python实现接口测试。4、性能测试性能测试理论、虚拟脚本生成器操作、场景设计、报告生成和分析，学习目标是掌握性能测试理论知识，能运用性能测试工具LoadRunner和Jmeter做性能测试，测试出系统的性能情况。

通过上面的原理分析可以知道，需要发送到后台的数据很简单，就是用户信息，聊天信息，和所在的空间信息，因为是一个简单的例子，所以bean就设计的比较简单了：[java] view plain copy public class UserChatCommand {private String name;private String chatContent;private String coordinationId; public String getName() {return name;}

使用 websocket , 这是html5新特性，当然也要求后台服务器支持，现在很多服务器已经支持了。

web前端学习路线

就目前而言，html5的价值程度很高。html5的技术人员的薪资就同行业相比也是比较突出的，html5技术人员薪酬更是水涨船高，高薪一族当之无愧。html5就业前景非常乐观。对应届生而言，现在抓紧时间学习html5和相关软件无疑是明智之举。想学好html5开发技术知识，首先要了解什么是html5，零基础的同学学html5基础知识要掌握哪些内容？想要学好html5前端开发，以下这些知识必须得掌握好，分享html5学习教程给大家。第1阶段：前端页面重构：PC端网站布局、html5+CSS3基础项目、WebAPP页面布局；第2阶段：JavaScript高级程序设计：原生JavaScript交互功能开发、面向对象开发与ES5/ES6、JavaScript工具库自主研发；第3阶段：PC端全栈项目开发：jQuery经典特效交互开发、HTTP协议，Ajxa进阶与后端开发、前端工程化与模块化应用、PC端网站开发、PC端管理信息系统前端开发；第4阶段：移动端webAPP开发：Touch端项目、微信场景项目、应用Vue.js开发WebApp项目、应用Ionic开发WebApp项目、应用React.js开发WebApp；第5阶段：混合（Hybrid）开发：各类混合应用开发；第6阶段：NodeJS全栈开发：WebApp后端系统开发；第7阶段：大数据可视化：数据可视化入门、D3.jS详解及项目实战。html5前端全栈课程学习，致力于培养覆盖前端+后台+全栈开发的综合性人才，专业性强、课程创新、师资雄厚。课程涵盖JavaScript、html5、CSS3、NodeJS全栈开发等内容，让学员全方位技能，一手掌控。html5课程学习门槛低，适合零基础的小白迅速成长，学习曲线先快后慢，也适合有一定基础的学员进阶学习，巩固知识的基础上，突破职业瓶颈。html5前端开发的就业前景也十分被业界看好，一方面是企业需求量大，薪资高；另一方面，移动互联网开发是可以长远发展的行业。只要技术水平足够好，专业性足够高，开发人才将是长期被企业所追捧和青睐的对象，职业道路的发展和薪资的稳固提升自然不言而喻。

前端工程师已经成为目前互联网企业极具竞争力的人才，企业不断提升薪资水平为了招聘到优秀的Web前端开发工程师。因此，越来越多的人想要学习Web前端。那么呢？Web前端的学习路线是什么？想成为一个Web前端开发工程师，需要掌握的知识有很多，大概包括：HTML、CSS、JavaScript、XML、JSON、服务器脚本语言(PHP,ASP,.NET,JSP等等)、jquery框架、页面性能优化、SEO站内优化、开放服务API接入、浏览器兼容性调试、W3C规范等等。1、前端页面重构。主要内容为PC端网站布局、HTML5+CSS3基础、WebApp页面布局。学习目标是完成PC端网站布局，WebApp页面布局，还要可以通过HTML5+CSS3的2D、3D等属性实现一些精美的动画效果。2、JavaScript高级课程、PC端全栈项目开发。主要内容为原生JavaScript、面向对象进阶与ES5/ES6应用、JavaScript工具库自主研发、JQuery经典交互特效开发、HTTP协议、Ajax进阶与后端开发、前端工程化与模块化应用以及AngularJS等。学习目标是可以通过原生JavaScript开发交互功能，实现网站上的交互效果，以及模块化应用等，实现完整的前端工程。3、Web前端框架、混合开发(Hybrid，RN)、大数据可视化。主要内容为Node.js后端开发、Vue.js前端框架、React前端框架、混合开发(Hybrid，RN)、Angular前端框架、大数据可视化等。学习目标是可以独立完成相应的项目，如微信场景，应用Vue.js、Ionic、React.js等框架开发WebApp，微信小程序项目开发，以及各类混合应用项目开发等。以上就是为大家分享的关于杭州Web前端学习路线。不知道对于还在迷茫的你或者是正在考虑学习的你在看完上面所介绍的内容之后有没有想要赶紧去学习的想法呢？

适用于 Linux 的 Windows 子系统中的 Visual Studio Code 服务器使用本地 WebSocket WebSocket 连接与远程 WSL 扩展进行通信。网站中的 JavaScript 可以连接到该服务器并在目标系统上执行任意命令。目前该漏洞被命名为CVE-2021-43907。这些漏洞可以被用于：本地 WebSocket 服务器正在监控所有接口。如果允许通过 Windows 防火墙，外部应用程序可能会连接到此服务器。本地 WebSocket 服务器不检查 WebSocket 握手中的 Origin 标头或具有任何身份验证模式。浏览器中的 JavaScript 可以连接到该服务器。即使服务器正在监控本地主机，也是如此。我们可以在特定端口上生成一个Node Inspector示例，它还监控所有接口。外部应用程序可以连接到它。如果外部应用程序或本地网站可以连接到这些服务器中的任何一个，它们就可以在目标计算机上运行任意代码。Visual Studio Code 库是不断更新的。我将使用一个特定的提交 (b3318bc0524af3d74034b8bb8a64df0ccf35549a)。$ git clone https://github.com/microsoft/vscode $ git reset --hard b3318bc0524af3d74034b8bb8a64df0ccf35549a我们可以使用 Code (lol) 来导航源代码。事实上，我已经在 WSL 中为这个漏洞创建了具有相同扩展名的概念验证。Visual Studio Code在 WSL 内以服务器模式运行，并与 Windows 上的代码示例对话（我称之为代码客户端）。这使我们可以在 WSL 中编辑文件和运行应用程序，而不需要运行其中的所有内容。远程开发架构可以通过 SSH 和容器在远程计算机上进行远程开发。GitHub Codespaces 使用相同的技术（很可能通过容器）。在 Windows 上使用它的方法：1.打开一个WSL终端示例，在Windows上的代码中应该可以看到远程WSL扩展；2.在 WSL 中运行code /path/to/something；3.如果未安装代码服务器或已过时，则会下载它；4.VS Code 在 Windows 上运行；5.你可能会收到一个 Windows 防火墙弹出窗口，用于执行如下所示的可执行文件：服务器的防火墙对话框这个防火墙对话框是我执行失败的原因。出现该对话框是因为 VS Code 服务器想要监控所有接口。从我信任的Process Monitor开始：1.运行进程监控器；2.在WSL中运行code .；3.Tools > Process Tree；4.我运行代码（例如，Windows Terminal.exe）的终端示例中运行Add process and children to Include filte。Procmon 的进程树经过一番挖掘，我发现了 VSCODE_WSL_DEBUG_INFO 环境变量。我只是在 WSL 中将 export VSCODE_WSL_DEBUG_INFO=true 添加到 ~/.profile 。运行服务器后我们会得到额外的信息。VSCODE_WSL_DEBUG_INFO=true输出被清理。检查命令行参数。可以看到出现了WebSocket词汇。运行 Wir.shark 并捕获loopback接口上的流量。然后我再次在 WSL 中运行代码。这次可以看到两个 WebSocket 握手。在 Wireshark 中捕获的 WebSocket 连接该运行中的服务器端口是63574，我们也可以从日志中看到。在 Windows 上的代码客户端中打开命令面板 (ctrl+shift+p) 并运行 > Remote-WSL: Show Log。远程 WSL：显示日志最后一行有端口：在 http://127.0.0.1:63574/version 上打开本地浏览器。我们还可以看到从 Windows 上的 Code 客户端到服务器的两个单独的 WebSocket 连接。服务器是位于 /src/vs/server/remoteExtensionHostAgentServer.ts#L207 的 RemoteExtensionHostAgentServer 的一个示例。它被 createServer 在同一个文件中使用，我们可以使用 Code (lol) 找到它的引用并追踪到 remoteExtensionHostAgent.ts（同一目录）。可以根据注释查看 main.js 内部。打开文件，看到服务器可以从传递给main.js的参数中获得主机和端口。main.js 被 server.sh 调用：没有 IP 地址传递给脚本，我认为这就是为什么服务器监控所有有趣的事情。port=0 可能告诉服务器使用临时端口，此信息来自同一目录中的 wslServer.sh。每次看到本地 WebSocket 服务器时，都应该检查谁可以连接到它。WebSocket 连接不受同源策略约束，浏览器中的 JavaScript 可以连接到本地服务器。WebSockets 从握手开始，在跨源资源共享或 CORS 的上下文中它始终是一个“简单”的GET 请求，因此浏览器不需要预先请求就可以发送它。可以快速创建一个尝试连接到特定端口上的本地WebSocket服务器的测试页面，将它托管在某个远程位置（例如，S3 存储桶）并在计算机上打开它。如果连接成功，就可以继续操作了。我还检查了 Burp，在 Burp Repeater 中创建了 WebSocket 握手。将 Origin 标头修改为 https://example.net。如果响应具有 HTTP/1.1 101 交换协议，那么就可以继续了。在 Burp 中测试注意，这只对本地主机服务器有影响。这里的服务器也对外公开，攻击者不受浏览器约束。它们可以直接连接到服务器并提供任何 Origin 标头。接下来是查看 Wireshark 中的流量，右键点击之前的WebSocket握手GET请求，然后选择 Follow > TCP Stream。我们将看到一个带有一些可读文本的屏幕。关闭它，只会看到这个进程的数据包，这允许我们只关注这个进程。你可能会问为什么我关闭了仅包含消息内容的弹出窗口，因为没有用。根据 RFC6455，从客户端到服务器的消息必须被屏蔽。这意味着它们与一个 4 字节的密钥（也随消息一起提供）进行了异或运算。Wireshark 在选择时取消屏蔽每个数据包，但有效载荷在初始进程弹出窗口中显示为屏蔽。所以我们将看到纯文本的服务器消息，而客户端消息被屏蔽并出现乱码。如果你点击单个消息，Wireshark 就会显示有效载荷。我花了几天时间对协议进行逆向工程。后来，我意识到只能在/src/vs/base/parts/ipc/common/ipc.net.ts 中看到协议的源代码。来自服务器的第一条消息是 KeepAlive 消息。在协议定义中，我们可以看到不同的消息类型。在 /src/vs/platform/remote/common/remoteAgentConnection.ts 中，它在代码的其他部分被称为 OKMessage 和heartbeat。客户端在/src/vs/platform/remote/common/remoteAgentConnection.ts的connectToRemoteExtensionHostAgent中处理此问题。客户端(Windows上的代码)发送这个包，它是一个KeepAlive和一个单独的认证消息。最初，我认为长度字段是 12 个字节而不是 4 个字节，因为其余的字节总是空的。然后我意识到只有常规消息使用消息 ID 和 ACK 字段，而且我只看到了不规则的握手消息。在修复之前，没有勾选此选项。注意：在 2021-11-09 更新之前（commit b3318bc0524af3d74034b8bb8a64df0ccf35549a）客户端没有发送数据。但是，使用此提交，我们仍然可以在没有此密钥的情况下发送消息并且它会起作用。这是我们给服务器签名的内容，以检查连接到正确的服务器。服务器响应一个签名请求。另一个 JSON 对象：服务器已经签名了我们在前一条消息中发送的数据，并用它自己的数据请求进行了响应。客户端验证签名的数据，以检查它是否是受支持的服务器。当创建我们的客户端时，可以简单地跳过。使用options.signService.validate 方法，然后就会得到/src/vs/platform/sign/node/signService.ts。vsda 是一个用 C++ 编写的 Node 原生插件，将 Node 原生插件视为共享库或 DLL。该插件位于 https://github.com/microsoft/vsda 的私有存储库中，根据https://libraries.io/npm/vsda/的说法，直到2019年左右，它都是一个NPM包。它与 VS Code 客户端和服务器捆绑在一起：Windows系统：C:Program FilesMicrosoft VS Code esourcesapp ode_modules.asar.unpackedvsdauildReleasevsda.node服务器（WSL）：~/.vscode-server/bin/{commit}/node_modules/vsda/build/Release/vsda.node。我找到了https://github.com/kieferrm/vsda-example，并通过一些实验找到了如何使用它创建和签名消息。1.用msg1 = validator.createNewMessage("1234")创建一个新消息，输入至少4个字符。2.使用signed1 = signer.sign(msg1)进行签名。3.使用 validator.validate(signed1) 对其进行验证，响应为“ok”。需要注意的是，如果你创建了新消息，则无法再验证旧消息。在源代码中，每条消息都有自己的验证器。Linux 版本有符号，大小约为 40 KB。把它放到 IDA/Ghidra 中，应该就可以开始了。我花了一些时间，想出了这个伪代码。可能不太正确，但可以让你大致了解此签名的工作原理。1.用当前时间 + 2*(msg[0]) 初始化 srand，它只会创建 0 到 9（含）之间的随机数；2.从许可证数组中附加两个随机字符；3.从 salt 数组中附加一个随机字符；4.SHA256；5.Base64；6.???；7.Profit。仅从许可证数组中选择前 10 个位置的字符，它总是 rand() % 10 ，但salt 数组翻了一番。许可证数组的字符串如下所示：salt 数组的前 32 个字节（查找 Handshake::CHandshakeImpl::s_saltArray）是：我从来没有真正检查过我的分析是否正确，不过这无关紧要，知道如何使用插件签名消息，这就足够了。接下来，客户端需要签名来自服务器的数据并将其发送回来，以显示它是一个“合法”的代码客户端。服务器响应如下：客户端发送了如下消息：提交应该匹配服务器的提交哈希。这不是秘密。这可能是最后一个稳定版本提交（或最后几个之一）。这只是检查客户端和服务器是否在同一版本上。它也可以在 http://localhost:{port}/version 上找到，你的浏览器 JavaScript 可能无法看到它，但外部客户端没有这样的限制。signedData是对我们在前面消息中从服务器获得的数据进行签名的结果。Args是此消息中最重要的部分，它可以告诉服务器在特定端口上启动一个 Node Inspector 示例。break: 启动 Inspector 示例后中断。端口：检查器示例的端口。Env：传递给检查器示例进程的环境变量及其值的列表。Node Inspector 示例可用于调试 Node 应用程序。如果攻击者可以连接到你计算机上的此类示例，那么攻击就成功了。2019 年，Tavis 发现 VS Code 默认启用了远程调试器。整个设置旨在允许 Windows 上的代码客户端在 WSL、容器或 GitHub 代码空间中进行远程开发。这意味着它可以在远程计算机上做任何想做的事情。因此，如果网站可以连接到你本地的 WebSocket 服务器并绕过 DRM，它就可以模拟代码客户端。它可以在你的系统上远程执行代码，并且不需要 Node Inspector 示例。到目前为止，我们已经找到了两种利用该系统的方法：生成并连接到 Node Inspector 示例；模拟代码客户端并使用自定义协议与远程计算机交互；Node Inspector示例让我们看看前面消息中的参数， /src/vs/server/remoteExtensionHostAgentServer.ts 在服务器上处理它们。IRemoteExtensionHostStartParams 接口类似于我们之前看到的 JSON 对象：_updateWithFreeDebugPort检查端口是否空闲，如果没有，它将尝试接下来的10个端口。最后一个空闲端口存储在startParams.port中。选择的端口被发送回客户端，所以我们知道去哪里：最后，它在 /src/vs/server/extensionHostConnection.ts 中调用con.start(startParams);。这看起来很复杂，让我们来分析一下：1.Node Inspector 示例将监听 0.0.0.0:debugPort，这很危险，如果用户接受 Windows 防火墙对话框，它将在外部可用；2.我们也可以注入 Inspector 的环境变量；3.removeDangerousEnvVariables 方法不是安全过滤器，只是删除 DEBUG、DYLD_LIBRARY_PATH 和 LD_PRELOAD 环境变量（如果存在）以防止崩溃。什么是Node Inspector？它可以用来调试Node进程。有一些客户端和库支持这一点，但通常，我使用Chromium内置的专用节点DevTools (chrome|edge://inspect)。连接到 Inspector 示例后，我们可以打开控制台并运行 require("child_process").exec("calc.exe");。尽管我们使用的是wsdl，但它仍然有效。浏览器中的 JavaScript 无法连接到 Inspector 示例，客户端使用另一个 WebSocket 连接与示例对话。但是，我们需要知道调试器会话 ID。/json/列表浏览器中的 JavaScript 可以发送此 GET 请求，但由于 SOP（响应没有 Access-Control-Allow-Origin 标头）而无法看到响应。其他客户端则没有这个限制，因为检查器在外部可用，我们可以从外部连接到它。现在，我创建了一个简单的概念验证：1.打开一个网站并输入端口（我们可以扫描它，但手动输入它会更快）。2.网站中的 JavaScript 完成握手。3.我使用 /sign API 创建了一个 Node 应用程序，这样就可以使用 vsda 插件。4.一旦生成Node Inspector 示例，第二个 API 就会被 debugPort 调用。5.使用 chrome-remote-interface 库的 Node 应用程序连接到 Inspector 示例并运行 calc。你可以通过以下链接看到源代码：https://github.com/parsiya/code-wsl-rce https://github.com/parsiya/Parsia-Code/tree/master/code-wsl-rce模拟代码客户端创建客户端并使用协议连接到服务器的代码位于 VS Code GitHub 存储库中，这需要大量的复制/粘贴和解析，我只花了几个小时。如果要创建一个快速的概念验证，应该满足一些假设：1.找到本地的 WebSocket 端口；2.从外部连接到Node Inspector示例；查找本地 WebSocket 端口并不难，从浏览器扫描本地服务器并不是什么新鲜事。服务器也可以从外部使用，因此我们不受那里的浏览器约束。Chrome 限制不起作用，因为 WebSocket 服务器需要一个网络服务器来处理握手。我也很好奇 WebSocket 节流是 Chrome 特定的保护还是 Chromium 的一部分。有趣的是，Chrome 浏览器有一个保护机制，可以防止恶意行为者暴力破解 WebSocket 端口，它在第 10 次尝试后开始节流。不幸的是，这种保护很容易被绕过，因为扩展的 HTTP 和 WebSocket 服务器都在同一个端口上启动。这可用于通过向 img 标签添加 onload 处理程序来检查特定本地主机端口上的图片是否存在来强制所有可能的本地端口。也就是说，这是一个开发环境，用户可能整天都在 WSL 中开发并且从不关闭他们的浏览器选项卡，因此如果他们打开我们的网站，我们就有可能找到它。连接到Node Inspector示例是另一回事，我们无法从浏览器执行此操作，因此我们需要我们的服务器可以访问受害者的计算机。第二种利用方法（模拟代码客户端）没有这些限制，因为浏览器可以与本地服务器通信并执行所有操作。它只需要我们对协议进行逆向工程并找出要发送的正确消息。当你收到 WebSocket 升级请求时，请根据许可名单检查 Origin 标头。代码客户端在该标头中发送 vscode-file://vscode-app，以便我们可以使用它来操作。参考及来源：https://parsiya.net/blog/2021-12-20-rce-in-visual-studio-codes-remote-wsl-for-fun-and-negative-profit/

访问错误的地址，导致返回的是已经移走的资源————————————————————