websocket 怎么同步调用

第一步，先创建 http 服务，这个呢，其实我们前面就已经有了，来，我们把前面的这个内容呢导进来，然后呢包括这个 cache server， 好， 我们写一遍吧， import http from http 就 导进来了， 导进来之后来去使用它 const server 等于 cache server 好， 这个里面呢，我们什么都可以不用做 在这个地方。但是一般情况下，我们如果你前端是用 http， 因为我这说了啊，它应该是一个 web socket 的 服务，那如果你这个时候前端在尝试着用 http 来请求的话，我要给你报个错 啊。所以一般情况下呢，我们都会在这儿放一个，比如说什么 error code 等于四百等于四百，好，然后呢，给前端返回一个数据，就 r s 点 right hit， 把这个状态码给它返回回去啊， error code 就 告诉他，你不能够用 i g d p 来请求，你应该用 w s 来请求啊，用 web socket， 你 这个有点货不对版，对吧？然后那我们 r s 点 end， 把内容呢给它放进去，比如说你这是一个 bad request 好，其他东西呢，我们全部都不管，现在我们直接 server 点 listen 刚才的啊， server 点 listen 三千端口，然后呢说我已经监听了，好，我们来同样的 pmpv 回车跑起来啊，那同样道理，这个地方呢，我们要把 type 给它指定一下， 指定之后再来跑起来，是不是跑起来了？跑起来之后我们来到这边啊，不管你是在浏览器的这个里面输入三千也好，是不是告诉你这是四百 bit request， 看到同学在评论区来扣个一啊，四百 by request， 好， 那不管是你在这里呢还是在这里，你在这里也是一样的发送那四百 by request 不 让你请求了，对吧？我，我不让你，我不给你，你要我不给你，那接下来怎么办呢？ 既然你这个不给他，那接下来呢，你要想办法，他如果是 ws 过来的话，升级协议里面你要给他。 好，那接下来这里就升级协议，怎么升级呢？我们来看一下它的这个请求的具体细节啊，我来给大家看一下，因为之前很多同学用 ws 都没有怎么去深入的去了解过它的原理，我们就直接在这来看。 constws 等于 new 一个 web socket 啊， web socket 好， 把它触手挖一下，那东西呢？给它放进去，这里你肯定不能用 h p 了，对吧？这里要用 w s 冒号 local host 三千吧，是不是这样没问题吧？好，回车， 回车的时候呢？我待会啊，我待会回车完了之后，同学们要关注这个 w s 这个这个地方啊，当然你自己下去之后也是这样来看。回车，回车之后来看一下这边的 w s， 它是不是没有发出去任何的内容啊， 对吧？这个地方没有发出去任何内容，但是其实呢，你这个地方应该是能够看到的，我们再重新刷新一下之后，把这个 w s 清除一下， 回车扭一下。好，他这里说了啊，就是你这个呢，其实是看不到内容的，你包括发出去这个 connect s c 是 直接拒绝的，对吧？你在这边呢也看不到对应的具体内容的处理，这个没关系，我们呢把它复制一下，把这个 ws 复制一下，复制一下之后呢，我们到这里来看，它可以创建一个快捷请求啊，这个快捷请求呢，你可以去建一个 w 这个 web socket 接口，大家可以看到这里吧？好，把它拿过来，然后呢？ ws 放进去，点一下连接，然后它就会告诉你无法连接到这个里面去。好，无法连接，但是没关系，我们重点去看它的请求头，朋友们注意来看啊， header 它有哪些呢？ 你看这个就叫协商升级，就说，哎，我们俩关系好，我可不可以升级一下，走个后门？没问题啊，那接下来我就给你去升级嘛。怎么升级？当你的请求头中间有这个 update great web socket 的 时候，这个时候其实这个请求他不会立马的去对你进行处理，而是做升级的处理。

ok， 我 们来看到第二个问题，是 web socket， web socket server， web socket 是 所有的同学在面试的时候非常容易问到的一个问题，比如说什么场景呢？同学们有没有做过大屏开发？有做过大屏开发的同学在评论区来扣个一。 有做过大屏或者格式化啊，图标相关开发的同学在评论区来扣个一。应该有很多吧。 那你如果说在做这部分开发的时候呢？经常会被问到一个点，叫数据实时同步啊，这个就是很多同学之前有被问到过的，面试的时候有被问到过数据实时同步，怎么来做呢？ 想到一个最土的办法，所有这个方案呢？同学们再去面试的时候，一定要有主次之分，有浅入深，有表及理的去表述，比如说用户九五二七同学，这位同学说的就是非常非常有道理啊，这个叫暴力解法， 什么叫暴力写法呢？你让我实时同步对不对？那我就轮询啊。渔夫同学也说对了，一秒一刷新，当然你也可以两秒一刷新或者三秒一刷新，这个叫 ajax， 或者是叫 fetch， 轮询 叫 request， request， 呃， interval 啊， request interval 就是 轮询，一个一个问，一个一个问，就相当于很多同学，比如说你喜欢一个女生，你要去追求她，怎么办呢？你要想办法，每天都要见到她，并跟她说我爱你，为什么呢？因为 这个有时候人呐，它包括这个呃，人的一些行为是很奇妙的，就是如果说你每天都在去重复一件事， 然后呢？你让对方重复的每天去接受一件事，但是突然你没有这个信号了，哎，奇迹就会发生啊，单身的同学把这一招学一学，这个叫死缠烂打，叫去磨他啊，磨人 好，这个是暴力解法，暴力解法呢，我们之前给大家讲算法开发，讲那个呃设计模式这些内容的时候呢，其实都有介绍过啊，暴力解法，比如说排序，你用一个这个呃冒泡排序没有问题啊，冒泡排序也能排出来，对吧？这个程序也能跑，最后功能也能实现， 但是如果说你作为要想进阶的话啊，不想躺平的话呢，你一定要想这个暴力解法还有没有什么更好的方案，这就是同学们在面试的时候觉得始终没什么可说的原因，因为你很多事情，你很多的方案，很多的技术点， 你都只做了一件事，叫将就啊，将就工作生活，反正可以就行了，对吧？将就就可以了，这样的生活态度不好啊，一定要去追求一些这个让自己意想不到的，去追求一些更完美的东西，我认为的啊， 好。所以呢，暴力解法完了之后，接下来就是同学们说的这个 ws 还有呢？ s s 一 啊， s s 一 呢？最近我看到同学们其实，呃确实还是 说的比较多啊，就关于 s s 一 的这个点， s s 一 这个呢，其实是这个切的 gpt 啊，切的 gpt 炒起来的，因为很多同学之前没有听说过这个 sse， 对 吧？很多很多同学之前没有听说过 sse 是 切了 gpt 出来之后， sse 的 这个概念呢，让更多的同学 所听说所接受。 s s 一 呢，这个我就这里不讲了，我们今天的这个核心重点是带大家 web socket 去做一个打通啊。渔夫同学， web socket 没打通， 是哪里没打通？是我们现在没打通，还是你的任督二脉没打通？是你的任督二脉没打通，对吧？那好，我现在来帮你打通啊。同学们，来看我们现在怎么样从底层去理解 ws 这个概念，我们怎么来理解啊？同学们来想一下， ws web socket 这个呢？它是属于哪一层？ web socket， 大家告诉我。你可以用 tcp ip 模型。 tcp ip 模型啊，你还可以用这个，呃，常规的，常规的网络模型，你来 iso 网络模型啊。 osl， osl 说错了，这个网络模型里面它属于哪一层？ web socket？ web socket 属于哪一层？ 那 web socket 你 怎么样去实力化出来它呢？因为你去翻遍 node js 的 关那个 node js， 你 去翻遍 node js 的 文档，你都发现不了关于 web socket 的 这么个模块。 虽然同学们都在用 ws 模块，对吧？ ws 这个 web socket library 这个库呢，确实很受欢迎这个库，但是我觉得如果说你只是会用的话， 那个不叫技术能力啊，那个不叫技术能力，那个叫搬运，那个叫搬砖，对吧？搬砖你，你有一个 web socket， 然后就开始用了，那多简单呢，是吧？所以我们今天来给大家看一看，如果你不用这些库，怎么来做到？好，我们一步一步来分析啊。我先在这里呢，建一个 ws 杠 server 点，呃， gs 啊，同样，我这个包忘记触化了， c d 点点出来之后，我们再来到这个项目， p m m y 呃， n p m zeros 杠 y 触化一下，触化好之后，我们所有的模块都不需要，只需要在这补一行命令， dv 冒号 note， ws server 点击 s 就 ok 了啊，我们不用，不需要用任何的第三方模块我们来实现，怎么实现呢？大家记住啊，这个 web socket 呢？ ws 层呢？它其实有一个概念，叫什么呢？叫打怪升级，我把它这样， 我把它这样理解哈，什么叫打怪升级呢？就是连接啊，连接的时候是用什么连接呢？是用 http 协议连接，对吧？ http 连接，然后呢？ 连接完之后干嘛呢？协商，你看协商他协商什么呢？协商说，哎，我要升级协议，这个协议怎么升级呢？就是我给你一些这个请求头，请求头里面的信息， 请求头信息拿到之后啊，给你交换密钥，交换这些东西。然后呢？我来知道啊，就是你想要升级这个协议， 这是它完整过程，完整过程。当然对于这一系列这一串的所有的操作呢，其实 web socket 都有专门的协议来去给大家说明。这个 web socket api 里面有一个详细的介绍啊，就是在这一层呢，在这个 技术里面编写 web socket 的 客户端应用的时候，呃，服务端吧，编写 web socket 的 服务端看这个啊，它是一个 tcp 应用程序，然后呢 需要去做握手的处理，他具体怎么握手呢？这个看着太晦涩难懂了，我相信很多同学去看这个就蒙了啊，又是什么握手？又是挥手的，又是什么？服务端响应这些内容的，什么什么，对吧？ 好，太复杂了，包括还有这个交换数据帧，数据帧，哎呀，我这些东西我之前从来都没写过，这东西看的太复杂了，这怎么办呢？我来告诉大家，非常简单，就几步。

在 m c p 模型上下文协议日渐普及的今天，前端如何优雅地处理与模型的交互？特别是当这种交互不再是简单的 rest 请求，而是演变成绘画化、流逝化的复杂场景时，我们该如何应对？ 传统的 exos 方式往往显得捉襟见肘，大家有没有遇到过这种情况？项目里散落着各种各样的 exos 调用，每个组建都自己写一套健全逻辑、错误处理逻辑，甚至重试逻辑。 这就像一个团队里，每个人都有自己的工具箱，虽然也能干活，但效率低下，维护起来更是噩梦。更别提现在 m c p 场景下，我们需要处理流势响应、精细化的绘画管理、严格的审计要求。这些传统 exos 很 难搞定。 长期凭证放在前端，那简直是把金库钥匙直接挂门口，这种零散低效、难维护的状态必须改变。 所以我们的目标很明确，打造一个统一的 m c p 客户端。首先要有一个统一的接口，让所有组建通过同一个 hook 来调用 m c p 工具，不管底层是 s s e 还是 web socket， 对 上层都透明。 其次，必须支持流式响应，这是 m c p 的 核心特性之一。安全方面坚决不用长期密要，要么用短期凭证，要么走后端代理。 同时，每一次调用都要有迹可循，产生审计日制，方便后续追踪和治理。最后还得考虑用户体验，提供请求、取消和必要的回滚机制。 当然，理想很丰满，现实很骨感，我们在设计时也必须考虑工程约束。兼容性是基础，不能因为用了新东西就牺牲了浏览器或 s s 二环境的支持 改造要低侵入，不能动不动就推倒重来，得让团队能平滑迁移。可测试性非常重要，网络请求这块布马克柱怎么测？ 性能也不能忽视，特别是流逝场景，如果解析和渲染堵塞了主线程，那用户体验可就差远了。这些都是实实在在的挑战。这个眼镜不是一蹴而就的，我们可以分阶段推进。 最开始就是我们熟悉的现状，到处都是分散的 exos 调用。第一阶段，可以先做简单的封装，把公共的配置拦截其抽出来，形成一个基础的 api client。 但这还不够，他还缺乏 mcp 特有的绘画和流逝能力。第二阶段，就在 api client 之上引入一个专门的 mcp 指令，他能理解并执行 call two 这样的 mcp 指令。 第三阶段，把这个 m c p client 的 能力封装成 react hook， 也就是我们今天的主角 use mactwo， 最后再逐步完善，加入审批、审计、监控等治理功能。 这就是我们精心打磨的 use mactwo 的 核心代码。别看它有点长，但结构很清晰，它利用了 react， use state， use ref， use effect 这些基本功。 关键在于 call to 函数，它封装了发起请求处理、流式响应、重试、取消以及审计上报的全流程。注意，这里对 content type 的 判断区分了流式和非流式路径。 流式处理中，我们用 readable stream 逐块读取，配合 text decoder 解码，并通过 set chunks 来累积中间结果， 非流式则直接解析 jason 还有 about controller 用于取消请求， navigator send beacon， 保证审计日制可靠上报。这个 hook 就是 我们从 axles 走向 m c p 新时代的基石。 流势响应是 m c p 的 灵魂。我们主要会遇到三种， s e h t t p chunked stream， 也就是常说的 jason lines 以及 web socket。 sse 适合服务器单向推送，浏览器原声支持简单直接， fetched 流更通用。通过 readable stream 处理，可以应对各种分段返回的数据。 web socket 则提供了双向通信的能力，是和需要实时交互的场景。 但不管哪种流势，都不能傻乎乎地把每一小段数据都立刻更新到 ui， 那 样会导致页面疯狂重绘，用户体验极差。 所以一定要做渲染截流，比如攒一波再更新，或者使用虚拟列表技术，只渲染格式区域内的数据。网络请求嘛，出错是常态，不能指望一次成功，我们需要一套健壮的错误处理策略。 首先得区分错误类型，哪些是网络抖动导致的可以重试，哪些是权限问题，重试也没用，哪些是业务逻辑本身的问题。针对可重试错误，我们采用直述退币策略，避免短时间内密集重试压垮后端。 同时对于写操作，强烈建议引入密等性机制，比如通过 iding 确保重复请求不会产生副作用。 当然，最终呈现给用户的错误信息一定要清晰明了，告诉用户发生了什么，下一步该怎么办。最好还能提供一个审计 id 链接，方便他们自己去后台查详细日记 工程实践，细节决定成败。性能方面，处理大流量数据时，解析逻辑最好扔到 web worker 里跑。解放竹县城 渲染也要讲究策略，批量更新虚拟化列表都是好办法毫测试方面，单元测试要冒个好网络层，覆盖各种成功、失败、流逝、非流逝、重试取消的场景。 集成测试要搭个环境跑起来，看看端到端的流程是否顺畅。负债测试也不能少，模拟高并发症，看看系统能不能扛得住。 调试的时候有个清单很有用，检查 header 对 不对， content type 是 不是预期的 network 面板里看响应细节，还可以在 hock 里加个 on debug 回调输出关键时间方便定位问题。 代码写好了，上线部署和运维同样重要。 mcp server 作为核心服务，必须保证高可用、多副本。负债均衡是标配。 提供短期凭证的服务，比如 token service 也得足够稳定，万一挂了或者需要快速撤销凭证，整个系统就得瘫痪。 审计日质量通常很大，得用像 kf 加 elastic search 这样的组合权来存储和解锁，并且要有合理的数据保留策略。监控和告警更是重中之重， 成功率、延迟错误率这些核心指标要实时监控，设置好告警规则，一旦异常能及时发现。 对于可能影响数据一致性的写操作，还要有完善的补偿机制和前端回滚入口，确保系统在出错时也能恢复。总结一下，将 m c p 工具调用，从分散的 xls 升级为统一的 usmike two hook 是提升前端工程化水平、保障系统健壮性和安全性的必经之路。它不仅解决了代码领域维护困难的问题，还通过标准化的流势处理、严格的审计和安全策略，让我们能够更好地驾驭 m c p 带来的复杂交互。 现在给大家一个三步走的落地清单。第一步，先把现有的 exos 调用迁移到统一的 m c p client。 第二步，引入 usmike。 二，从最关键的几个场景开始替换验证效果。第三步，别忘了接入审计和监控，建立告警体系，最好再来一次故障演练，确保万无一失。 这里附上了两个参考视例，一个是 mcp 接口的 open api 规范片段，展示了基本的请求体和响应的 content type 声明。 另一个是审计事件的 jason skima， 简化版列出了关键字段，比如事件 id 时间戳绘画 id 用户 id 工具名称状态等等，这些可以帮助大家更好地理解和实现相关的接口与数据结构。

升级的处理呢？它的内容里面大家注意观察，这个里面有个细节啊，这里有个 secweb socket key 是 干嘛的呢？ 哎，这个就是它们之间的悄悄话小秘密啊，这个秘密给到后端去了之后，后端对它加盐啊，对它这个 crypto 做一个加密处理，什么生成一个另外的这个混淆字段之后再给它返回回来，再给它返回回来 协商的过程啊。好，我们来看一下这个具体的协商。怎么来协商呢？就是在 server on 里面通过去监听一个 upgrade 就 ok 了。对啊，我现在监听 upgrade 好， 我来打印一下啊，同学们，来把这三个参数都打印一下，看一看最后的效果，这三个参数 保存，然后呢再来重启一下，重启之后我们再在这个地方点一下发送。 哎，太棒了，你看 on upgrade 里面是不是得到东西了呀？ on upgrade 里面得到东西了，得到的中东西里面我们也看到了刚才在前端的那个 sec 什么什么什么 k， 对 吧？ sec 什么什么 k 也在这个里面，你看现在前端的已经挂起了，这 它是没有任何响应，回去接下来你就要去对它进行处理。怎么处理呢？首先啊，你要从它的请求头上面，从这个 request 的 请求头上面去拿到那个 set web socket key， 叫 sec 杠 web socket key， 这个呢用于生成一个叫 sec web socket act。 呃，这个 excite accept 就是 我跟你说我要升级，你跟我说我接受了，好就可以了嘛，对吧？流程是这样的，那我们现在再来看一看，那我们是不是要获取到这个 key？ 这个 key 怎么获取呢？就直接从 request 上面的 headers 里面拿到这个 sec， sec socket， web socket。 key 拿到它以后，我们要生成一个 accept value， 这个 accept value 用谁生成呢？就是用这个 key 来生成这个。具体的算法呀，我不跟大家去细讲了啊，具体的算法我不跟大家去细讲了，我就直接拿过来， 我放在最后面啊，放在最后面这个地方呢会有一个 crypto， crypto 是 用来去做 这个，大家从这里可以看得到生成了一个 shan， 然后呢？ base 六十四 digits base 六十四，然后呢做了一个加盐的处理好，这个时候我们就生成了一个 accept value， 有 了这个 accept value 之后，这里呢我们就生成这个 accept value， 等于它传进去，把这个 key 啊， 把前端升级请求得过来的这个内容呢，放进去，放进去拿到 accept value 生成，它就可以给到前端响应的里面去，这个时候呢相当于协商成功。 但是接下来还没完，你把这些内容给到之后，你就要往前端的 socket 套接字，现在就变成套接字了，同学们注意啊，这个地方现在就变成套接字了，要 socket 往前端去发送 web socket 切换协议的响应头 怎么写怎么怎么写呢？就是 socket 点 right 啊，就是 socket 点 right right， 这个里面写什么呢？就是从 r e s header， 我们从 l e s headers 里面，我们这里给它定义一个啊，我们给它定义一个 l e s header， 因为要写很多很多的请求头，我们就直接把它定义到这个里面。这个啊，想一头啊，想一头，说错了，想一头里面要给些什么呢？第一个，第一个是切换协议，切换协议啊， 切换协议的这个叫什么呢？就是直接是 http， 幺零幺， switch and protocol 啊，这些协议，大家去看这个，这个 web socket， 这里去看幺零幺，这里都能看到，对吧？你看这个就是 服务器握手响应的参数，那其实就是这些了，这些我就我就，我就不写了啊，我直接复制过来的，这个节省时间，因为它是官方的官方势力，我们呢把这些全部都给到它这里呢，这些地方给个逗号啊， 好，大家都好，最后还差最后的一个就是什么呢？就是这个 sec web socket accept， 把它也给它拿过来啊，这个里面呢给它传进去，放进去，把这个结果也传进去，这样你的响应头就组装成功了。 大家到这里还能不能跟上？可以跟上，同学在评论区扣个一啊，这个叫升级协议。好，协议升级完之后，这里呢就直接 r n 杠 n 去切换一下 啊，去接去加一个这个杠 n 切换，就是换成这个响应头，最终的这个数据，杠 n 杠 r 嘛，杠 n 杠 r 就 可以了。好，这个时候呢，我们就能够切换了， 能不能成功呢？我们先来试一下啊，现在写完之后再来启动一下哦，这个，嗯，哦，不好意思，这个地方我因为我们是用的 g s 写的啊，用 g s 写的，改一下再来连接，成功了吧。 看到同学在评论区来扣个一，这就是 web socket 协议升级的原理，是不是把 任督二脉打通了？简单吧啊？概念呢？你只要有学习方法对了，学习方向对了，其实很多概念是比较容易的， 你看他的这个文档，那我估计你从头到尾看太难了。这个怎么看呢？这上面又是请求的，又是响应升级的，又是这个什么 sec、 web socket、 accept， 太复杂了，太复杂了，怎么办呢？哎，你看，给大家缩减出来，因为我一直以来啊，不管是自己写代码，还是在这个，不管是平常这个工作中还是什么，我都是追求极简主义啊，追求不管，只要能够 sop 化，能够标准化东西我绝对不来第二遍， 所以你看非常清晰，第一步，第二步，第三步。好，就完成了握手的过程和升级协议的过程，刚才我们从这里就看到了吧，我可以点断开，你看这就断开了吧，我点连接，哎， ws 就 连接成功了，这个就连接成功了啊，连接成功我就可以去看了呀。 在哪看呢？你看，这里不是 message 吗？这里就 message， 这个 message 就 可以看。那比如说我往后端去发一个乒乓乒乓乒乓，是不是心跳？好，我发一个拼过去，你看拼是不是过去了？我再，哎，没反应啊，没反应。我再发一个，拼，好，有没有反应？没反应。再发一个，拼，也没反应，再发一个，还是没反应。为什么呢？因为 我们现在的这边处理数据帧的这个逻辑啊，在这没有做，没有做怎么办呢？

大家好，今天我们将深入对比 web socket 和 http 协议。这两种协议在现代 web 开发中都扮演着重要角色，但它们的通信模式和应用场景有很大不同。 h t t p 是 无状态的请求响应协议，每次交互都需要客户端发起请求，而 web socket 是 全双工通信协议通过 h t t p upgrade 机制建立连接后，客户端和服务端可以双向主动通信。 在核心差异方面， h t t p 是 单向通信，需要客户端主动发起请求，而 web socket 支持全双工通信。 h t t p 的 连接是短期的， web socket 是 持久连接。 在协议开销上， h t t p 每个请求都有完整头部， web socket 建立连接后只有很小的针头。 websocket 通过 http upgrade 机制建立连接，客户端发送包含 upgrade 头的请求，服务端返回一百零一状态码确认协议切换。建立连接后，数据通过轻量级的二禁制真传输，大大减少了协议开销。 在选择协议时，传统请求响应场景如静态资源获取和 restful api 适合使用 h t t p， 而需要频繁双向通信的实时应用，如聊天、在线游戏、携同编辑等场景， web socket 是 更好的选择。 在高级话题中，需要注意的是， h t p r 的 server push 与 web socket 不 同，它只是将资源推送到客户端缓存。 在性能优化方面， wik socket 需要设置心跳包和二禁制协议，而 h t t p 可以 通过启用 h t t p 二和使用 c d n 来优化。 面试中常见的问题包括 wik socket 如何穿透防火墙，以及为什么比 h t t p 长轮询更高效 web socket 通过附用 http 端口和 upgrade 机制解决穿透问题，其高效性体现在避免重复连接，减少头部开销和真正的双向通信。 第三个常见问题是 web socket 的 安全注意事项，必须使用安全的 wss 协议验证路由请求伪造攻击并实施消息速率限制来防止滥用。 通过本课程的学习，我们深入理解了 web socket 和 http 协议的核心差异。 http 适合传统的请求响应场景，而 web socket 在 需要实时双向通信的应用中表现更佳。 在实际开发中，应根据具体的业务需求和通信模式来选择合适的协议。