共计 3060 个字符，预计需要花费 8 分钟才能阅读完成。
因为业务需要，接触了 ws 协定以及在实时语音辨认中的使用，总体的感觉还是挺有意思，并且理解到很多人其实是没有用过这个协定的，所以还是值得分享记录一下。
本文将分为以下几个模块去讲述 WebSocket，1. 以理论场景引入来剖析传统形式实现实时数据传输存在的弊病，由此引出 ws 的作用和特点。2. 介绍 ws 协定的工作流程，握手过程以及对于心跳机制的一些了解。3. 结合实际的业务场景去看看 ws 协定是怎么应用的，并且实现了什么样的价值。
理论场景
大家在玩股票的时候，不晓得有没有认真的想过一个问题，它这个价格的实时变动是怎么做的呢？说两种比拟常见的形式，第一种形式就是明天要讲的 ws 协定，还有一种形式是 grpc 框架的服务端流模式，咱们平时 soa 的接口其实是 grpc 一种最常见的简略模式，他还有几种形式，如：客户端流模式，服务断流模式，客户端服务端流模式，这几种形式前面大家都能够理解一下。那么在没有 ws 或者 grpc 服务端流模式的时候，最古老的形式是怎么去做实时的响应呢？如图示：
http 短轮询：
以周期性的形式，去一直地拜访服务端，问服务端是否有后果给返回，当初两种状况，假如拜访的周期过长，那么实际上曾经对实时性产生了影响，如果拜访的周期很短，一直的申请是很容易造成资源节约的，因为并不是每次的申请都能拿到实时的数据。
http 长轮询：
作为短轮询的一种演进形式，让申请在服务端去期待，直到拿到后果，或者申请时长达到了超时工夫主动断开，这种演进能够说是在肯定水平上缩小了申请的频次，假如服务端无更新，就不会始终从新发动申请。但其实毛病仍旧显著，如果 sever 不更新的话，这个申请就会始终在服务端 hold 住，仍旧是资源节约。
总结下：其实这两种形式在 client 数量很多的时候，是存在连接数容易被顶满的危险的。
那么咱们心愿有一种全双工的通信协议，使得服务端和客户端都可能被动或者被动的发送或者承受音讯，并且可能缩小相似于 http 申请的频次，发送数据的时候又不会每次都须要从新建设连贯上下文（如申请头），那 ws 协定正好能满足这些要求。
ws 协定的呈现其实是为了补救 http 申请存在的缺点的，次要解决了 http 的两个痛点。1.http 协定的被动性，因为 http 协定他是个申请 - 响应模型，一个申请触发一个响应，在没有申请的前提下，响应不会被触发。这就是被动性。2.http 的无状态性，所谓无状态性，其实就是每次申请 - 响应实现，其实他的生命周期曾经完结了，如果开始下一个生命周期，那必须要从新建设连贯上下文。
很多人会问，http1.1 不是反对长连贯吗，为何每次连贯还是要从新建设连贯上下文呢？其实 http 的长连贯他是一个 ” 伪 ” 长连贯，他的长连贯只是基于一个 tcp 通道的复用而已，而应用层的 http 连贯仍旧是须要每次连贯断开，再连，断开，再连。
其实说到这里大家应该很明确，ws 的特点和劣势在于哪里了，那上面就次要介绍下，ws 协定的根本工作流程，握手流程以及对于 ws 协定应用层心跳机制的一些了解。
ws 协定介绍
总体说下 ws 的工作流程，ws 协定须要利用 http 进行一次握手，那么首先就得进行三次握手进行 tcp 连贯，而后在进行 http 的握手操作，在握手实现之后其实就没有 http 的什么事件了，这里 ws 连贯就可被建设，sever 端和 client 端都可进行 OnMessage 的音讯互传，实现当前，server 和 client 都能够进行被动或者被动的敞开连贯，触发 tcp 四次挥手。
对于 ws 协定的握手：
对于 ws 协定心跳机制：
这里抛两个问题，其一，咱们都晓得 tcp 他本身是存在 keep-alive 机制的，那为何咱们还须要去做应用层的心跳检测（起因如 123），这里得解释下，这个 keep-alive 和 http 那个 keep-alive 不是一个概念，tcp 的 keep-alive 是为了检测 client 和 server 是否处于存活状态。
1. 第一个起因是 tcp 自身默认的 keep-alive-time 是 2h，这也就认为着，当两端无数据传输之后，要期待两个小时，而后 keep-alive-probe 通知 tcp 检测断开的次数，并且两头必须要距离 keep-alive-inval 的工夫，就从这个过程来说是否流程太长又太简单。
2. 网络自身其实是很不稳固的，当 client 遇到断电，断网的时候，就很容易呈现 tcp 假死的状况，客户端其实曾经挂了，而服务端这个时候还认为这个连贯活着，于是仍旧一直去发送数据。
3.java 的封装机制使得在应用层去操作传输层不太不便。
其二，当客户端异样断开的时候，各端的解决机制，如图表：
| client | sever 解决形式 | client 解决形式 | 解决思路 |
|---|---|---|---|
| 过程被杀死 | 触发 onerror 和 onclose 办法 | / | 此时端口被敞开，触发 tcp 四次挥手。内部断开的 tcp 会触发异样 |
| 断电断网 | 检测 client 最初心跳上报工夫 | 触发 onclose | 如果无心跳检测机制，此时网络复原，客户端发动重连，那么就是一个新 session，假死的 tcp 仍旧在发数据，相同，server 可及时敞开旧 session |
ws 在语音辨认中的使用
先介绍下业务背景流程：
当用户在关上页面的时候，麦克风其实就曾经在监听的状态了，当说出唤醒词的时候，性能被唤醒，前面须要去指挥这个性能去干点什么事件，比方开锁，关锁，导航等命令词，前端会进行音频的分包切片传输，在通一个通道发送给 asr 辨认引擎，后通过一个规定过滤或模型加强（针对非凡场景的过滤和优化），最初辨认出指令，触发相干的动作。
后期踩过的坑
后期是间接和服务端对接的，是心愿以 soa 的形式去提供服务，后期尝试的形式如下图，两种形式，一种形式是疏忽了语音数据他其实是个间断的并且存在上下文关系特色的数据，第二种形式是耗时太久了，这种架构一旦设计起来，问题也会一堆。
当初的问题是，假如咱们要去用 soa 这种形式去调用接口，咱们要做些什么？第一，保障一个用户的所有 pcm 切片是有序传输的。第二，要本人去做负载，保障一个用户所有的 pcm 片是打到一台 asr 引擎上的，综合这两点，老本其实很高，那其实就是以 soa 这种形式其实曾经不适合了。
零碎的整体设计
用户首先通过一层的握手鉴权，而后进行录音采集，并且分包发送，数据是在一个通道传输的，最初是通过 asr 引擎的辨认，随着输出的不断完善，辨认的出的后果也在不断完善，并且能够依据前面的语境去纠正之前的辨认后果，最初咱们会把相干的数据进行存储，以便前期的模型强化。这里以两个用户为例的目标是为了阐明，两个用户是各自领有本人的通道和 task 的，互不烦扰。
WS-JAVA 服务端的实现形式 (两种)
1. 基于 tomcat 的 websocket 实现，注解 @ServerEndPoint(“url”)，几个重要的办法：onopen，onerror，onclose，onmessage。毛病：握手拦挡如鉴权，比拟艰难。相应的性能如图：
2. 基于 Springboot 的 WebSocket 实现，几个重要的办法：afterConnectionEstablished，handleMessage，handleTransportError，afterConnectionClosed。长处：可能在握手前后，拓展本人的业务逻辑。别离对应于 tomcat 的 onopen，onmessage，onerror，onclose。
各个办法的执行程序：
（本文作者：张豪杰）
本文系哈啰技术团队出品，未经许可，不得进行商业性转载或者应用。非商业目标转载或应用本文内容，敬请注明“内容转载自哈啰技术团队”。
