使用AI写WebSocket知识是一种怎么样的体验?
一、WebSocket基础知识
1. WebSocket概念
1.1 为什么会出现WebSocket
一般的Http请求我们只有主动去请求接口,才能获取到服务器的数据。例如前后端分离的开发场景,自嘲为切图仔的前端大佬找你要一个配置信息
的接口,我们后端开发三下两下开发出一个RESTful
架构风格的API接口,只有当前端主动请求,后端接口才会响应。
但上文这种基于HTTP的请求-响应模式并不能满足实时数据通信的场景,例如游戏、聊天室等实时业务场景。现在救世主来了,WebSocket作为一款主动推送技术,可以实现服务端主动推送数据给客户端。大家有没听说过全双工、半双工的概念。
全双工通信允许数据同时双向流动,而半双工通信则是数据交替在两个方向上传输,但在任一时刻只能一个方向上有数据流动
HTTP通信协议就是半双工,而数据实时传输需要的是全双工通信机制,WebSocket采用的便是全双工通信。举个微信聊天的例子,企业微信炸锅了,有成百条消息轰炸你手机,要实现这个场景,大家要怎么设计?用iframe、Ajax异步交互技术配合以客户端长轮询不断请求服务器数据也可以实现,但造成的问题是服务器资源的无端消耗,运维大佬直接找到你工位来。显然服务端主动推送数据的WebSocket技术更适合聊天业务场景。
1.2 WebSocket优点
大家先看看传统的Ajax长轮询和WebSocket性能上掰手腕谁厉害。在websocket.org网站提供的Use Case C
的测试里,客户端轮询频率为10w/s,使用Poling长轮询每秒需要消耗高达665Mbps,而我们的新宠儿WebSocet仅仅只需要花费1.526Mbps,435倍的差距!!
为什么差距会这么大?胡广告诉你,WebSocket技术设计的目的就是要取代轮询技术和Comet技术。Http消息十分冗长和繁琐,一个Http消息就要包含了起始行、消息头、消息体、空行、换行符,其中请求头Header非常冗长,在大量Http请求的场景会占用过多的带宽和服务器资源。
大家看下百度翻译接口的Http请求,拷贝成curl命令是非常冗长的,可用的消息肉眼看过去没多少。
curl ^"https://fanyi.baidu.com/mtpe-individual/multimodal?query=^%^E6^%^B5^%^8B^%^E8^%^AF^%^95&lang=zh2en^" ^
-H "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7" ^
-H "Accept-Language: zh-CN,zh;q=0.9" ^
-H "Cache-Control: max-age=0" ^
-H "Connection: keep-alive" ^
-H ^"Cookie: BAIDUID=C8FA8569F446CB3F684CCD2C2B32721E:FG=1; BAIDUID_BFESS=C8FA8569F446CB3F684CCD2C2B32721E:FG=1; ab_sr=1.0.1_NDhjYWQyZmRjOWIwYjI3NTNjMGFiODExZWFiMWU4NTY4MjA2Y2UzNGQwZjJjZjI1OTdlY2JmOThlNzk1ZDAxMDljMTA2NTMxYmNlM1OTQ1MTE0ZTI3Y2M0NTIzMzdkMmU2MGMzMjc1OTRiM2EwNTJQ==; RT=^\^"z=1&dm=baidu.com&si=b9941642-0feb-4402-ac2b-a913a3eef1&ss=ly866fx&sl=4&tt=38d&bcn=https^%^3A^%^2F^%^2Ffclog.baidu.com^%^2Flog^%^2Fweirwood^%^3Ftype^%^3Dp&ld=ccy&ul=jes^\^"^" ^
-H "Sec-Fetch-Dest: document" ^
-H "Sec-Fetch-Mode: navigate" ^
-H "Sec-Fetch-Site: same-origin" ^
-H "Sec-Fetch-User: ?1" ^
-H "Upgrade-Insecure-Requests: 1" ^
-H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36" ^
-H ^"sec-ch-ua: ^\^"Not/A)Brand^\^";v=^\^"8^\^", ^\^"Chromium^\^";v=^\^"126^\^", ^\^"Google Chrome^\^";v=^\^"126^\^"^" ^
-H "sec-ch-ua-mobile: ?0" ^
-H ^"sec-ch-ua-platform: ^\^"Windows^\^"^" &
而WebSocket是基于帧传输的,只需要做一次握手动作就可以让客户端和服务端形成一条通信通道,这仅仅只需要2个字节。我搭建了一个SpringBoot集成的WebSocket项目,浏览器拷贝WebSocket的Curl命令十分简洁明了,大家对比下。
curl "ws://localhost:8080/channel/echo" ^
-H "Pragma: no-cache" ^
-H "Origin: http://localhost:8080" ^
-H "Accept-Language: zh-CN,zh;q=0.9" ^
-H "Sec-WebSocket-Key: VoUk/1sA1lGGgMElV/5RPQ==" ^
-H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36" ^
-H "Upgrade: websocket" ^
-H "Cache-Control: no-cache" ^
-H "Connection: Upgrade" ^
-H "Sec-WebSocket-Version: 13" ^
-H "Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits"
如果你要区分Http请求或是WebSocket请求很简单,WebSocket请求的请求行前缀都是固定是ws://
。
2. WebSocket实践
2.1 集成WebSocket服务器
大家要在SpringBoot使用WebSocket的话,可以集成spring-boot-starter-websocket
,引入胡广下面给的pom依赖。
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-websocket</artifactId>
</dependency>
</dependencies>
感兴趣点开spring-boot-starter-websocket
依赖的话,你会发现依赖所引用包名为package jakarta.websocket
。这代表SpringBoot其实是集成了Java EE开源的websocket项目。这里有个小故事,Oracle当年决定将Java EE移交给Eclipse基金会后,Java EE就进行了改名,现在Java EE更名为Jakarta EE。Jakarta是雅加达的意思,有谁知道有什么寓意吗,评论区告诉我下?
我们的程序导入websocket依赖后,应用程序就可以看成是一台小型的WebSocket服务器。我们通过@ServerEndpoint可以定义WebSocket服务器对客户端暴露的接口。
@ServerEndpoint(value = "/channel/echo")
而WebSocket服务器要推送消息给到客户端,则使用package jakarta.websocket
下的Session对象,调用sendText
发送服务端消息。
private Session session;
@OnMessage
public void onMessage(String message) throws IOException{
LOGGER.info("[websocket] 服务端收到客户端{}消息:message={}", this.session.getId(), message);
this.session.getAsyncRemote().sendText("halo, 客户端" + this.session.getId());
}
看下getAsyncRemote
方法返回的对象,里面是一个远程端点实例。
RemoteEndpoint.Async getAsyncRemote();
2.2 客户端发送消息
客户端发送消息要怎么操作?这点还和Http请求很不一样。后端开发出接口后,我们在Swagger填充参数,点击Try it out
,Http请求就发过去了。
但WebSocket需要我们在浏览器的控制台上操作,例如现在胡广要给我们的WebSocket服务器发送Halo,JavaGetOffer
,可以在浏览器的控制台手动执行以下命令。
websocket.send("Halo,JavaGetOffer");
实践的操作界面如下。
二、感受下chatGPT4生成的文章(我感觉一般)
1. WebSocket概念
- 什么是WebSocket: WebSocket是一种通信协议,专为在客户端和服务器之间实现实时双向通信而设计。不同于HTTP协议的“请求-响应”模式,WebSocket允许在单个TCP连接上进行全双工通信。
- 工作原理: WebSocket连接通过一个初始的HTTP请求来建立,称为“WebSocket握手”。一旦握手成功,连接就切换为WebSocket协议,允许数据在客户端和服务器之间低延迟地传输。连接保持打开状态,直到明确关闭。
- 适用场景: 主要用于需要实时更新的应用场景,如在线聊天、实时数据推送、在线游戏、股票交易系统等。WebSocket的低延迟特性使其成为这些场景的理想选择。
2. WebSocket实践举例
- 在线聊天应用: 描述如何使用WebSocket实现一个简单的在线聊天应用。客户端通过WebSocket连接到服务器,服务器将消息广播给所有连接的客户端,实现实时的消息传递。
- 股票实时更新系统: 通过WebSocket向客户端推送股票价格的实时更新,使用户能够在浏览器中看到最新的市场动向,保持交易的即时性和准确性。
- 多人在线游戏: 讨论如何利用WebSocket实现游戏中的玩家位置、动作等信息的实时同步,以确保玩家在同一个虚拟世界中的一致体验。
3. 相较于其它的有哪些优势和劣势
- 优势:
- 低延迟: WebSocket的设计使得它在保持连接的同时能够以极低的延迟进行数据传输,这对实时应用非常关键。
- 全双工通信: 允许服务器和客户端之间同时发送和接收数据,而不需要像HTTP那样的轮询或长连接,降低了服务器的负担。
- 节省带宽: WebSocket连接在初始化后,不再需要额外的HTTP头部信息,从而减少了数据开销,节省了带宽。
- 劣势:
- 复杂性: WebSocket的实现和调试相对复杂,尤其是在处理连接管理、错误处理和安全方面。
- 不适合所有场景: 对于不需要实时双向通信的应用,使用WebSocket可能会造成不必要的复杂性和资源消耗。
- 服务器资源消耗: 持久连接需要服务器维持大量的活动连接,在高并发场景下可能导致资源消耗过高。
4. 感叹一下现在的AI环境
- AI与开发的关系: 讨论当前AI技术如何帮助开发者更高效地进行代码编写、调试和优化,减少重复性劳动。例如,AI驱动的代码生成工具能够根据自然语言描述自动生成WebSocket实现代码,降低了入门门槛。
- AI是否真的是大趋势: 从AI在各个行业的快速渗透和广泛应用的角度讨论,AI的确已经成为一种大趋势。分析AI对编程语言、开发流程的影响,以及如何加速软件开发的自动化和智能化。
- Python的崛起: Python作为AI和数据科学领域的主要编程语言,其市场份额的持续增长表明了AI和数据驱动开发的快速发展。解释Python的优势,例如其简洁的语法和强大的生态系统,如何帮助开发者在AI领域快速实现创新.
感觉其实也没那么牛叉,只是一般般而已,写的都是些套话,没有一点主见思维。不知道付费的gpt5咋样。看起来也就是:
1、回复的数据量更加的大
2、文件能上传
3、网页能访问
4、图片生成的多一些
一个月20刀,啧啧啧心疼的嘞。不过对于高度使用的用户来看,收益远远大于投入
三、 最后整点面试题干货(你们看到这题目会不会懵逼呢?)
包懵逼的,这些对于没学过的人毫无意义,不用记啦,当做笑话随便看看,老老实实去学websocket基础知识吧,学完再去动手做比啥都强
1. 什么是WebSocket?它与HTTP有什么区别?
答案: WebSocket是一种在单个TCP连接上提供全双工通信的协议。与HTTP不同,WebSocket允许服务器主动向客户端发送数据,而不需要客户端轮询。这使得WebSocket非常适合于实时应用。
2. WebSocket如何建立连接?
答案: WebSocket连接通过HTTP协议的Upgrade请求从普通的HTTP连接升级而来。客户端发送一个带有Upgrade: websocket
的HTTP请求,服务器响应并确认升级,从而建立WebSocket连接。
3. WebSocket在什么时候适用?
答案: WebSocket适用于需要实时数据交换的应用场景,如即时聊天、在线游戏、股票行情更新、在线协作工具等。
4. WebSocket的握手过程是如何进行的?
答案: WebSocket握手过程开始于客户端发送一个带有Upgrade: websocket
头的HTTP请求。服务器如果支持WebSocket协议,会返回一个带有101 Switching Protocols
状态码的响应,从而升级连接为WebSocket。
5. 如何在WebSocket中实现安全通信?
答案: WebSocket可以通过使用wss://协议(WebSocket Secure)实现加密通信,类似于HTTPS。这依赖于底层的SSL/TLS加密。
6. WebSocket如何处理数据帧?
答案: WebSocket通信中的数据被分割为帧传输。每个数据帧包含了帧的类型、长度、以及实际数据内容。WebSocket支持文本帧和二进制帧,服务器和客户端通过这些帧交换信息。
7. WebSocket是否支持跨域?
答案: WebSocket默认支持跨域连接,但浏览器会进行Origin检查以防止CSRF攻击。服务器需要检查并决定是否允许来自特定Origin的连接。
8. WebSocket连接中断后,如何重连?
答案: 当WebSocket连接中断时,客户端可以使用JavaScript代码检测连接状态,并在断开时通过设定重连机制(如指数退避算法)重新发起连接。
9. WebSocket的ping/pong机制是什么?
答案: WebSocket协议提供了ping/pong帧来检测连接的状态。客户端或服务器可以发送ping帧,另一端应回复pong帧。这有助于确保连接保持活跃,检测连接是否仍然有效。
10. WebSocket如何与传统HTTP服务器共存?
答案: WebSocket可以与传统HTTP服务器共存,通常通过同一个服务器端口。通过HTTP的Upgrade头,WebSocket连接可以在同一服务器上与HTTP请求并行处理。
11. WebSocket的负载均衡如何实现?
答案: WebSocket连接是持久的,因此负载均衡通常在连接初期由负载均衡器决定。如果使用了多台服务器,可以通过Sticky Sessions(会话保持)或WebSocket代理来确保后续通信由同一服务器处理。
12. 如何处理WebSocket中的大数据量传输?
答案: 对于大数据量的传输,WebSocket可以将数据分割为多个帧(fragmentation),每个帧依次发送,直到所有数据传输完成。这样可以避免单个大数据帧占用过多内存或网络带宽。
13. WebSocket在高并发场景下的表现如何?
答案: WebSocket在高并发场景中表现良好,因为它基于事件驱动模型,适合处理大量并发连接。然而,服务器端需要有效管理资源(如线程、内存),以避免瓶颈和性能下降。
14. 如何在WebSocket中进行身份验证和授权?
答案: WebSocket本身不包含身份验证机制,通常是在连接建立前通过HTTP请求进行身份验证。在连接建立后,可以通过自定义协议或使用JSON Web Tokens (JWT)在WebSocket通信中实现授权。
15. WebSocket有哪些替代方案?
答案: WebSocket的替代方案包括Server-Sent Events (SSE)和HTTP长轮询。SSE适用于单向服务器推送场景,而HTTP长轮询通过定期重新建立HTTP连接来模拟实时通信,但效率不如WebSocket高