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

1,831 阅读3分钟

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

  • 首先祝:今晚 4x100 接力,中国队必胜!!!✊✊✊

认清需求

认清需求是第一步!实战中需求是这样的:

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

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

脑图如下:

IAEvdh.md.png

实战代码

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

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

重点说明:

  1. 因为拿到 回执 callBack 后前端就主动断开了,所以断开分为:【正常断开】和【异常断开】;
  2. 异常断开要有重连机制,正常断开不用;
  3. 要有心跳发送机制;每隔 10 s 发送(send)一个 'ping' 到后端;
  4. send 失败也要重连;
  • websocket.js 实战代码(参数做了简化,可直接复制在控制台上调用测试

IAEBq2.md.png

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 }
}

调用:

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; ......

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

看到这里,喜欢就点个赞吧~👍👍👍后续会有更多关于实战的分享!

实践是检验真理的唯一标准!

我是掘进安东尼,输出暴露输入,技术洞见生活,下次再会~