一站式营销平台,做视频网站如何利用用户的弱点,网站 分辨率,wordpress多张页面左右滑动目录1. 为什么会有websocket2. websocket协议格式3. 协议具体实现一、为什么需要 WebSocket#xff1f;初次接触 WebSocket 的人#xff0c;都会问同样的问题#xff1a;我们已经有了 HTTP 协议#xff0c;为什么还需要另一个协议#xff1f;它能带来什么好处#xff1f;…目录1. 为什么会有websocket2. websocket协议格式3. 协议具体实现一、为什么需要 WebSocket初次接触 WebSocket 的人都会问同样的问题我们已经有了 HTTP 协议为什么还需要另一个协议它能带来什么好处答案很简单因为 HTTP 协议有一个缺陷通信只能由客户端发起举例来说我们想了解今天的天气只能是客户端向服务器发出请求服务器返回查询结果。HTTP协议做不到服务器主动向客户端推送信息。这种单向请求的特点注定了如果服务器有连续的状态变化客户端要获知就非常麻烦。我们只能使用轮询每隔一段时候就发出一个询问了解服务器有没有新的信息。最典型的场景就是聊天室。轮询的效率低非常浪费资源(因为必须不停连接或者HTTP连接始终打开)。因此工程师们一直在思考有没有更好的方法。WebSocket就是这样发明的WebSocket协议在2008年诞生2011年成为国际标准。所有浏览器都已经支持了。它的最大特点就是服务器可以主动向客户端推送信息客户端也可以主动向服务器发送信息是真正的双向平等对话属于服务器推送技术的一种。其他特点包括1)建立在 TCP 协议之上服务器端的实现比较容易。(2)与 HTTP 协议有着良好的兼容性。默认端口也是80和443并且握手阶段采用 HTTP 协议因此握手时不容易屏蔽能通过各种 HTTP 代理服务器。(3)数据格式比较轻量性能开销小通信高效。(4)可以发送文本也可以发送二进制数据。(5)没有同源限制客户端可以与任意服务器通信。(6)协议标识符是ws(如果加密则为wss)服务器网址就是 URL。websocket协议格式Browser已经支持http协议为什么还要开发一种新的WebSocket协议呢我们知道http协议是一种单向的网络协议在建立连接后它只允许Browser/UA(UserAgent)向WebServer发出请求资源后WebServer才能返回相应的数据。而WebServer不能主动的推送数据给Browser/UA当初这么设计http协议也是有原因的假设WebServer能主动的推送数据给Browser/UA那Browser/UA就太容易受到攻击一些广告商也会主动的把一些广告信息在不经意间强行的传输给客户端这不能不说是一个灾难。那么单向的http协议给现在的网站或Web应用程序开发带来了哪些问题呢一条连接上只可以发送一个请求请求只能从客户端开始。客户端不可以接收除了响应以外的指令。请求 / 响应首部未经过压缩就直接进行传输。首部的信息越多那么延迟就越大。发送冗长的首部。每次互相发送相同的首部造成的浪费越多可以任意选择数据压缩格式。非强制压缩发送ajax轮询ajax(异步的javascript与xml技术)是一种有效利用javascript和dom的操作以达到局部web页面的提花和加载的异步通信手段。和以前的同步通信相比他只更新一部分页面相应中传输饿数据量会因此的减少。ajax轮询的原理是让浏览器每隔一段时间就发送一次请求询问服务器是否有新消息。而利用ajax实时的从服务器获取内容有可能导致大量的请求产生。长轮询原理和ajax轮询差不多都是采用轮询的方式不过采用的是阻塞模型。也就是说当客户端发起连接后如果服务器端内容没有更新将响应至于挂起状态一直不回复response给客户端知道有内容更新再返回响应。虽然可以做到实时更新但是为了保留响应一次连接饿持续时间也变长了。期间为了维持连接会消费更多的资源。从上面两种方式中其实可以看出是再不断的建立http连接然后等待服务器处理可以体现出了http的特点被动性即请求只能由客户端发起。服务器端不能主动联系客户端。不管怎么样上面这两种都是非常消耗资源的。ajax轮询 需要服务器有很快的处理速度和资源。(速度)长轮询 需要有很高的并发也就是说同时接待客户的能力。(场地大小)除了以上这些HTTP还是一个无状态协议。通俗的说就是服务器因为每天要接待太多浏览器了是个健忘鬼你一断连接他就把你的东西全忘光了把你的东西全丢掉了。你第二次还得再告诉服务器一遍。WebSocketWebSocket其实是HTTP协议上的一种补充他们有交集但并不是全部。一旦web服务器和客户端建立起websocket协议的通信连接之后所有的通信都依靠这个专用连接进行。只需要经过一次HTTP请求就可以做到源源不断的信息传送了。websocket是基于HTTP协议的或者说借用了http的协议来完成一部分握手。为了实现websocket通信在http建立连接后还需要进行一次“握手”的步骤。握手 · 请求GET /chat HTTP/1.1 Host: server.example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw Sec-WebSocket-Protocol: chat, superchat Sec-WebSocket-Version: 13 Origin: http://example.com为了实现websocket通信需要用到http的Upgrade首部字段告知服务器通信协议已发生改变我要发起的是websocket协议。以达到握手的目的。Sec-WebSocket-Key字段记录着握手必不可少的键值用于验证服务器是否支持websocket通信。Sec-WebSocket-Protocol字段记录的是所需要使用的协议。握手 · 响应HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: HsMrc0sMlYUkAGmm5OPpG2HaGWk Sec-WebSocket-Protocol: chat对于客户端的请求服务器返回状态码 101 Switching Protocols的响应。返回Upgrate告诉客户端即将升级的协议是Websocket协议。Sec-WebSocket-Accept字段值是由握手请求中的Sec-WebSocket-Key字段值加密过后生成的。Sec-WebSocket-Protocol 则是表明最总使用的协议。到这里http已经完成所有他的工作了接下来通信时不再使用HTTP的数据帧而是使用websocket独立的数据帧。因此websocket协议具有以下的特点推送功能支持服务器端向客户端推送功能。服务器可以直接发送数据而不用等待客户端的请求。减少通信量只要建立起websocket连接就一直保持连接在此期间可以源源不断的传送消息直到关闭请求。也就避免了HTTP的非状态性。减少资源消耗那么为什么他会解决服务器上消耗资源的问题呢其实我们所用的程序是要经过两层代理的即HTTP协议在Nginx等服务器的解析下然后再传送给相应的Handler(PHP等)来处理。简单地说我们有一个非常快速的接线员(Nginx)他负责把问题转交给相应的客服(Handler)。本身接线员基本上速度是足够的但是每次都卡在客服(Handler)了老有客服处理速度太慢。导致客服不够。Websocket就解决了这样一个难题建立后可以直接跟接线员建立持久连接有信息的时候客服想办法通知接线员然后接线员在统一转交给客户。这样就可以解决客服处理速度过慢的问题了。协议具体实现前提本人最近做的项目服务器端用的是C写的而与客户端交互用的是websocket服务器端要想正常的使用数据必须要对websocket协议进行解析。WebSocket数据格式FIN表示这个数据是不是接收完毕为1表示收到的数据是完整的占1bitRSV13用于扩展通常都为0各占1bitOPCODE表示报文的类型占4bit 0x00标识一个中间数据包0x01标识一个text数据包0x02标识一个二进制数据包0x0307保留0x08标识一个断开连接数据包0x09标识一个ping数据包0x0A标识一个pong数据包0x0BF保留MASK用于表示数据是否经常掩码处理为1时Masking-key即存在占1bitPayload len表示数据长度即Payload Data的长度当Payload len为0125时表示的值就是Payload Data的真实长度当Payload len为126时报文其后的2个字节形成的16bits无符号整型数的值是Payload Data的真实长度(网络字节序需转换)当Payload len为127时报文其后的8个字节形成的64bits无符号整型数的值是Payload Data的真实长度(网络字节序需转换)Masking-key掩码当Mask为1时存在占4字节32bitPayload Data表示数据C对websocket协议处理/*** brief getWSFrameData 解析websocket的协议包不能解决粘包半包问题* param msg 待解析的数据* param msgLen 待解析的数据长度* param outBuf 解析完成数据* return*/int unPackingWSFrameData(char *msg,int msgLen,std::vector outBuf){//报文长度一定大于2字节对于小于的做返回处理if(msgLen 2){return -3;}uint8_t opcode_ 0;uint8_t mask_ 0;uint8_t masking_key_[4] {0,0,0,0};uint64_t payload_length_ 0;int pos 0;//Opcodeopcode_ msg[pos] 0x0f;pos;//MASKmask_ (unsigned char)msg[pos] 7;//Payload lengthpayload_length_ msg[pos] 0x7f;pos;if(payload_length_ 126){uint16_t length 0;memcpy(length, msg pos, 2);pos 2;payload_length_ ntohs(length);}else if(payload_length_ 127){uint32_t length 0;memcpy(length, msg pos, 8);pos 8;payload_length_ ntohl(length);}//Masking-keyif(mask_ 1){for(int i 0; i 4; i){masking_key_[i] msg[pos i];}pos 4;}//取出消息数据if (msgLen pos payload_length_ ){outBuf.clear();if(mask_ ! 1){char* dataBegin msg pos;outBuf.insert(outBuf.begin(), dataBegin, dataBeginpayload_length_);}else{for(uint i 0; i payload_length_; i){int j i % 4;outBuf.push_back(msg[pos i] ^ masking_key_[j]);}}}else{//此时包长小于报文中记录的包长return -2;}//断开连接类型数据包if ((int)opcode_ 0x8)return -1;return 0;}以上函数即实现了对收到websocket数据的解析返回结果为vectoroutput;通常会在函数外面对此进行转换为char*方便我们使用见下vectoroutput;char* out output[0];当然现在的解析还不是完美的解决方法因为在实际的使用当中会存在接收的包粘包半包等等问题而以上函数只能解决收到包正好是一个完整的包的情况具体解决粘包半包问题留待下次博客吧参考资料后台私信“资料”送结尾只为记录只为分享! 愿所写能对你有所帮助。不忘记点个赞谢谢~后台私信可以领取 内容包括C/CLinuxNginxZeroMQMySQLRedisfastdfsMongoDBZK流媒体 WebRTC CDNP2PK8SDockerGolang, TCP/IPMTK , 嵌入式 协程DPDK等等 。
