记一次 websocket 实战，“我没有拿到回执呀”

---

theme: channing-cyan

这是我参与8月更文挑战的第6天，活动详情查看：8月更文挑战

• 首先祝：今晚 4x100 接力，中国队必胜！！！✊✊✊

认清需求

认清需求是第一步！实战中需求是这样的：

web 前端 A1 与后端 C1 建立 websocket，等后端 C2 推送给 C1 一个 callBack 消息后，C1 再将这个消息推回给 A1，最后 A1 拿到这个回执后渲染界面；

额外说明：这个回执是由内嵌在 A1 iframe 里的 web 前端 A2 的用户输入的。

脑图如下：

实战代码

弄清需求后，就开始刷刷刷写代码了✍（这里实现 web 前端 A1 的逻辑）

此处通过wss://echo.websocket.org 来模拟连接地址：

重点说明：

1. 因为拿到 回执 callBack 后前端就主动断开了，所以断开分为：【正常断开】和【异常断开】；
2. 异常断开要有重连机制，正常断开不用；
3. 要有心跳发送机制；每隔 10 s 发送（send）一个 'ping' 到后端；
4. send 失败也要重连；

• websocket.js 实战代码（参数做了简化，可直接复制在控制台上调用测试）

代码语言：javascript复制

var limitConnect = 20 // 断线重连次数
var timeConnect = 0

const service = 'wss://echo.websocket.org'

// socket初始化
const webSocketInit = function() {

  var ws = new WebSocket(service)

  let ws_close_correctly = false

  ws.onopen = function() {
    console.log('已连接TCP服务器')
  }
  ws.onmessage = function(msg) {
    if (msg.data === 'callBack') { //
      ws.close()
      ws_close_correctly = true
      console.log("拿到回执，渲染界面")
    }
  }
  ws.onclose = function() {
    console.log(ws_close_correctly ? 'ws 正常断开' : 'ws 异常断开')
    reconnect(service)
  }

  // 重连
  function reconnect(service) {
    if (ws_close_correctly) return

    if (limitConnect > 0) {
      limitConnect--
      timeConnect  
      console.log('第'   timeConnect   '次重连')
      setTimeout(function() {
         webSocketInit()
      }, 2000)
    } else {
      console.log('TCP连接已超时')
    }
  }

  //  心跳 * 发送

  var timer = setInterval(function() {
    if (!isOpen(ws)) {
      console.log('ws 已断开，不用发 ping')
      clearInterval(timer)
      return false
    }
    if (ws.readyState === 3) {
      console.log('发送 send 失败，重连')
      clearInterval(timer)
      reconnect(service)
    }

    ws.send('ping')
  }, 1000 * 10)

  function isOpen(ws) { return ws.readyState === ws.OPEN }
}

调用：

代码语言：javascript复制

webSocketInit()

有些疑问

功能确实是实现了，但是还有些疑问：

• 心跳包是由前端发更好，还是后端发更好？或者说：由前端发，发了之后，后端再返回一个，类似：ping、pong、ping、pong......（必要性又有多少？）
• 心跳包设置多久发一次比较合理？
• 在本瓜这个实战场景中，消息还可能丢失！！ 比如：在 A2 中用户输入传递给了 C2，然后 C2 把回执给了 C1，如果此时 websocket 是中断的，等待重连后，C1 是否还能把消息准确推给 A1？C1 和 C2 之间需要有一个机制来记录，A1 是否准确收到了回执！
• 页面崩溃下的 websocket 断开如何处理？
• “我没拿到回执呀”，websocket 因为网络环境断开的可能情况是什么？websocket 断开在不同浏览器下的表现是怎样的？......

哭了，基本需求是解决了，但是这些开放性的问题一个接着一个，等待去回答！！

在逐层理解的过程中，就会对 websocket 有新的认识~

要点整理

通过这次实战，也梳理了些概念点：

1. WebSocket 与 HTTP 和 HTTPS 使用相同的 TCP 端口；
2. RFC 6455 中规定：WebSocket 被设计为在 HTTP 80 和 443 端口上工作，并支持 HTTP 代理和中介，从而使其与 HTTP 协议兼容；
3. socket 本质是对 TCP/IP 协议栈的封装，它提供了一个针对 TCP 或者 UDP 编程的接口，并不是另一种协议；
4. WebSocket.readyState：0 (WebSocket.CONNECTING)正在链接中、1 (WebSocket.OPEN)已经链接并且可以通讯、2 (WebSocket.CLOSING)连接正在关闭、3 (WebSocket.CLOSED)连接已关闭或者没有链接成功；
5. websocket 基本属性和方法-MDN; ......

还有很多点可以去探究，可以把代码拷在控制台上玩一玩儿~

看到这里，喜欢就点个赞吧~