使用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刀，啧啧啧心疼的嘞。不过对于高度使用的用户来看，收益远远大于投入