很多朋友对于websocket推送消息给前端和websocket服务端主动推送不太懂，今天就由小编来为大家分享，希望可以帮助到大家，下面一起来看看吧！
websocket优缺点
优点：
1、传统的http请求，其并发能力都是依赖同时发起多个TCP连接访问服务器实现的(因此并发数受限于浏览器允许的并发连接数)，而websocket则允许我们在一条ws连接上同时并发多个请求，即在A请求发出后A响应还未到达，就可以继续发出B请求。由于TCP的慢启动特性（新连接速度上来是需要时间的），以及连接本身的握手损耗，都使得websocket协议的这一特性有很大的效率提升。
2、http协议的头部太大，且每个请求携带的几百上千字节的头部大部分是重复的，很多时候可能响应都远没有请求中的header空间大。如此多无效的内容传递是因为无法利用上一条请求内容，websocket则因为复用长连接而没有这一问题。
3、当需要实现客户端刷新消息时，传统方案往往通过定时ajax请求实现，实际上对多数用户多数时间下这些请求都是无意义了，除了浪费资源。
其次则是websocket支持服务器推送消息，这带来了及时消息通知的更好体验，也是ajax请求无法达到的。
缺点：
它对开发者要求高了许多。对前端开发者，往往要具备数据驱动使用javascript的能力，且需要维持住ws连接（否则消息无法推送）；对后端开发者而言，难度增大了很多，一是长连接需要后端处理业务的代码更稳定（不要随便把进程和框架都crash掉），二是推送消息相对复杂一些，三是成熟的http生态下有大量的组件可以复用，websocket则太新了一点。
web前端培训课程都学习什么内容
随着移动互联网的发展，近几年web前端技术越来越受大家的喜欢，那对于小白童鞋而言，学习web前端到底要学习些哪些内容呢？
其实优就业web前端的学习主要包括以下几个阶段：
第一阶段Html5+CSS3：主要学习HTML5基础、CSS基础、HTML5进阶、CSS3进阶、Less
第二阶段JS交互设计：主要学习JavaScript核心语法、DOM和BOM、JavaScript高级进阶、面向对象编程、Touch、jQuery、Zepto
第三阶段Node开发：主要学习JavaScriptES6、Node、Express、MySQL、Webpack+Gulp+模块化、WebSocket+Koa2
第四阶段前端框架：主要学习Vue基础、Vue进阶、TypeScript、React
第五阶段小程序+数据可视化：主要学习小程序基础、云开发、uni-app基础、数据可视化
第六阶段就业指导+项目提升：就业指导、企业面试复盘
学习完这几个阶段，html5开发中的一些理论知识基本上就掌握得差不多了，接下来就是找一些小项目练手。在找项目的时候最好找有商业价值或有实际意义的，由深入浅。最后还可以做一两个小项目，传到开源网站上，方便面试的时候展示。
接口异步结果如何返回前端
在异步接口中，当后端处理完请求后，需要将结果返回给前端。一般来说，有以下几种方式：
1.回调函数：在异步请求中，可以通过回调函数的方式将结果返回给前端。前端在发起请求时，传入一个回调函数，后端在处理完请求后，调用该回调函数并将结果作为参数传入。这样，前端就可以在回调函数中处理返回的结果。
2.WebSocket：WebSocket是一种双向通信协议，可以在客户端和服务器之间建立持久连接。在异步请求中，可以使用WebSocket将结果实时推送给前端。后端在处理完请求后，将结果通过WebSocket推送给前端，前端接收到推送后，即可处理返回的结果。
3.轮询：在异步请求中，可以使用轮询的方式获取结果。前端在发起请求后，每隔一段时间向后端发送一次请求，后端在处理完请求后，将结果返回给前端。前端接收到返回的结果后，即可处理返回的结果。
需要注意的是，以上三种方式都需要后端支持。在选择使用哪种方式时，需要根据具体的业务场景和技术栈进行选择。
前端后端怎么连接
答:前端和后端可以通过以下几种方式进行连接：
1.RESTfulAPI：前端通过HTTP请求向后端发送请求，后端将数据以JSON或XML格式返回，前端再通过JavaScript解析和显示数据。这种方式比较简单，适用于数据量不太大的应用，如单页面应用。
2.WebSocket：前端和后端建立双向通信的长连接，可以实时传递数据。这种方式适用于实时性强的应用，如即时聊天或实时游戏。
3.GraphQL：前端通过GraphQL查询语言向后端发送请求，后端返回前端所需的数据，避免了不必要的数据传输，提高了性能。这种方式适用于数据量较大的应用，如社交网络或电商网站。
4.RPC（RemoteProcedureCall）：前端通过调用后端提供的API方法，实现远程过程调用，后端返回前端所需的数据。这种方式适用于需要频繁调用API的应用，如微服务架构的应用。
需要注意的是，前端和后端连接时需要遵守以下原则：数据传输应该安全可靠，数据格式应该统一规范，前后端应该协同开发，避免出现接口不一致或数据格式不匹配的问题。同时，前后端的技术选型和架构设计应该考虑到应用的规模和性能需求。
后端可以直接从cookie里取到token，为什么前端还要token设置到Authorization
两种方案：
将token放在cookie里；将token放在请求头里，用Authorization字段。无论对于前端还是后端而言，这两种方案都是各有利弊的，下面稍微讲几点，实际开发中根据需求来选用即可。
将token放在cookie里：
前端可以完全不写代码，设置cookie可以依赖后端的Set-Cookie响应头，同域名的情况下发送所有请求的时候cookie也是自动带上的（也有坏处，这样经常会造成网络流量和带宽的浪费，所以CDN的域名都是和主站不同的，避免请求带上cookie浪费流量）；
在安全性方面，cookie可以设置HttpOnly来保护cookie无法被JS代码捕获，避免XSS等攻击，还可以设置Secure来确保只在https环境下传输token；这些能力由浏览器提供，Authorization无法实现；
但是，cookie会存在CSRF攻击的问题，虽然浏览器厂商在逐步禁止第三方cookie（似乎推迟到2024年了），但是这个问题还是不得不防（如果想使用第三方cookie，可以在后端响应中设置cookie的SameSite属性）；
在一级域名相同的情况下，cookie可以实现跨子域名互通，比如a.example.com和b.example.com之间可以实现cookie互通（设置cookie时提供Domain=example.com属性），这个能力也是Authorization不具备的；
网页中的图片<img/>请求时也会自动带上cookie，好处是便于控制网络图片的访问权限，例如网络相册的权限控制可以精确到用户级，这个是Authorization做不到的，它必须把token放在url查询里面才行；缺点：如果网页中的背景图、icon等资源图片放在相同的域名下，每次请求这些资源图片都会带上cookie，很浪费带宽和服务器的流量，所以CDN的域名一定要和主域名区分开。
如果你还想了解更多这方面的信息，记得收藏关注本站。
