http与webSocket区别
我们平时打开网页,比如淘宝当我们点击下商品信息就会跳转到商品详情。从HTTP协议的角度来看就是点击一下网页的某个按钮,前端发送一次HTTP请求。网站返回一次HTTP响应,这种由客户端主动请求服务器响应的方式也满足大部分网页的功能场景。这种情况下服务器从来不会主动给客户端发送一次消息。但是像这种服务器主动发数据给客户端的场景又该如何做到呢？其实关键痛点是怎样才能在用户不做任何操作的情况下网页能收到消息并发生变更,最常见的解决方案是网页的前端代码里边不断定时发HTTP请求到服务器。服务器收到请求后响应消息。这是一种伪服务器推的形式,它其实并不是服务器主动发送消息到客户端而是客户端不断请求服务器。只是用户无感知而已。用到这种方式的场景很多最常见的是扫码登录(登录页面二维码出现后前端网页不知道用户扫没扫于是不断向后端服务器询问看有没有人扫过这个码而且都是1~2秒不至于等太久)这就是HTTP定时轮询。问题在于这种操作会偷偷的请求数据(短轮询)虽然数据很小但是也会消耗带宽,会增加下游服务器的负担。用户在扫码后需要等个一到两秒才正好触发下一次的HTTP请求。然后才会跳转页面,用户会感到明显的卡顿。那么问题来了有没有更好的解决方案？我们可以用长轮询来实现HTTP请求发出后会给服务器留下一定的时间做响应。比如3秒如果在规定时间内没返回那么就是超时,如果我们的http请求将超时设置的很大。比如三十秒,在这三十秒内只要服务器收到了扫码请求就立马返回给客户端网页,如果超时,那么就立马发起下一次请求。这样就减少了HTTP请求的个数。并且由于大多数情况下用户都会在某个30秒的区间内做扫码操作所以响应也是及时的。
WobSocket
我们知道TCP链接的两端同一时间里双方都会主动的向对方发送数据。这就是所谓的全双工,而现在使用最广泛的HTTP1.1也是基于TCP协议的同一时间里客户端和服务器只能有一方发送数据,这就是所谓的半双工也就是说,好好的全双工TCP被HTTP用成了半双工。这是为什么？这是由于HTTP协议设计之初。考虑的是看看网页文本的场景能做到客户端发送请求。再由服务器响应就够了根本就没考虑网页游戏这种(服务端需要主动推送数据给客户端)客户端和服务器之间都要互相主动发大量数据的场景为了更好的支持这种场景我们需要一个基于TCP的新协议。于是新的应用层协议websocket就被设计出来了。
websocket连接的建立
我们平时刷网页,一般都是在浏览器上面刷的,一会儿刷刷图文,这时候就是用的HTTP协议。一会儿打开网页游戏这时候就得切换回来我们新介绍的websocket协议。或者后边还得看看视频,又要切换为了兼容这些使用场景,浏览器在TCP三次握手建立连接之后都会使用HTTP先进行一次通信如果此时是普通的HTTP请求那后续双方就还是老样子。继续用普通的HTTP协议进行交互。如果这时候想建立webSocket连接就会在HTTP请求里边带上一些特殊的HTTP Header 其中Connection:Upgrade Upgrade:websocket。从upgrade:websocket看出客户端想要升级成websocket协议。同时带上一段Sec-WebSocket_Key:T2a6wZIAwhgQNqruZ2YUyg 发给服务器如果服务器正好支持升级成websocket协议。就会走websocket握手流程。根据客户端生成的BASE64码用公开的算法变成另外的一段字符串放在相应的sec-ws-accept里同时带上101状态码发送回给浏览器。101指的就是协议切换之后浏览器也用同样的公开算法将BASE64转变成另外一段字符串。如果这段字符串跟服务器传回来的字符串是一致的那验证通过ws和HTTP都是基于TCP协议的经历了三次TCP握手之后利用HTTP协议升级成ws协议。后续双方就使用ws的数据格式进行通信数据包在ws中被称为帧。
