当前位置:   article > 正文

通过LiveGo学习WebSocket

livego

一直对网络直播、在线互动的前端应用特比感兴趣,偶然间在Gitee上看到了livego的开源代码,是基于golang的直播服务实现。代码量不大,于是抽丝剥茧的分析了一下其设计思路,觉得还蛮有意思的。

所以,用户至少具备两个基本属性,用户的id和关联数据推送的WebSocket连接。除了这两个基本信息外,可根据实际业务需要增加其他信息,如用户名、头像等。上线用户的临时组管理无用户认证、用户信息管理等复杂业务逻辑,也没有数据信息的持久化处理。

对于消息的定义有如下字段:消息类型-MType、消息内容-Data和源用户的头像信息-Img。消息类型的串行化处理采用了json.Marshall。

  1. 1. 直播中的业务处理

  2. 直播是一端数据上传,多端数据分发的过程。数据的上传和转发都要借助长连接,所以在livego中采用了WebSocket。livego是一个简易的开放式聊天服务,在线群组管理做的比较简单:

  3. 1) 为请求连接的用户创建唯一标识,若连接成功则在群组中保留;否则将其移除;

  4. 2) 消息转发过程中,根据数据推送的状态更新群群组状态,如数据推送失败则断开连接,并将用户剔除。

所以,用户至少具备两个基本属性,用户的id和关联数据推送的WebSocket连接。除了这两个基本信息外,可根据实际业务需要增加其他信息,如用户名、头像等。上线用户的临时组管理无用户认证、用户信息管理等复杂业务逻辑,也没有数据信息的持久化处理。

对于消息的定义有如下字段:消息类型-MType、消息内容-Data和源用户的头像信息-Img。消息类型的串行化处理采用了json.Marshall。

2.  WebSocket会话

WebSocket会话直播服务的核心基础构件。在livego中自带了一套websocket的封装,协议字段的定义、ws帧解析参考规范文档,draft-ietf-hybi-thewebsocketprotocol-10。这个文档是可以网上找到的,对照文档解读源码,思路会比较清晰易懂。

从WebSocket客户端请求说起。WebSocket请求处理的第一补是解析ws的url,其格式与http的URL格式类似,不同的是把scheme换成了ws或wss,该scheme的处理策略是创建ws连接。处理如下:

1) 根据URL及origin够构造DiagConfig,该配置参数会用于后续的TCP连接的建立和参数配置1

  1. // Dial opens a new client connection to a WebSocket.
  2. func Dial(url_, protocol, origin string) (ws *Conn, err error) {
  3.     config, err := NewConfig(url_, origin)
  4.     if err != nil {
  5.         return nil, err
  6.     }
  7.     if protocol != "" {
  8.         config.Protocol = []string{protocol}
  9.     }
  10.     return DialConfig(config)
  11. }
  12. Ø 借助golang的net库,创建TCP连接
  13. func dialWithDialer(dialer *net.Dialer, config *Config) (conn net.Conn, err error) {
  14.     switch config.Location.Scheme {
  15.     case "ws":
  16.         conn, err = dialer.Dial("tcp", parseAuthority(config.Location))
  17.     case "wss":
  18.         conn, err = tls.DialWithDialer(dialer, "tcp", parseAuthority(config.Location), config.TlsConfig)
  19.     default:
  20.         err = ErrBadScheme
  21.     }
  22.     return
  23. }

2)借助golang的net库,创建TCP连接

  1. func dialWithDialer(dialer *net.Dialer, config *Config) (conn net.Conn, err error) {
  2.     switch config.Location.Scheme {
  3.     case "ws":
  4.         conn, err = dialer.Dial("tcp", parseAuthority(config.Location))
  5.     case "wss":
  6.         conn, err = tls.DialWithDialer(dialer, "tcp", parseAuthority(config.Location), config.TlsConfig)
  7.     default:
  8.         err = ErrBadScheme
  9.     }
  10.     return
  11. }

  3)TCP连接创建成功后,构造WS Client

  1. // DialConfig opens a new client connection to a WebSocket with a config.
  2. func DialConfig(config *Config) (ws *Conn, err error) {
  3.     var client net.Conn
  4.     if config.Location == nil {
  5.         return nil, &DialError{config, ErrBadWebSocketLocation}
  6.     }
  7.     if config.Origin == nil {
  8.         return nil, &DialError{config, ErrBadWebSocketOrigin}
  9.     }
  10.     dialer := config.Dialer
  11.     if dialer == nil {
  12.         dialer = &net.Dialer{}
  13.     }
  14. // client是TCP连接对象
  15.     client, err = dialWithDialer(dialer, config)
  16.     if err != nil {
  17.         goto Error
  18.     }
  19. // 基于TCP连接创建ws连接
  20.     ws, err = NewClient(config, client)
  21.     if err != nil {
  22.         client.Close()
  23.         goto Error
  24.     }
  25.     return
  26. Error:
  27.     return nil, &DialError{config, err}
  28. }

4) rwc是tcp连接对象,并由此构造缓冲读写的对象br,bw。并开始执行WS会话中的关键步骤-握手。握手完成后随即构造WS连接对象。hybiClientHandshake实现是纯HTTP的协议交互,按照HTTP的协议规范构造协议内容,如头部、请求体等,发送给对端,根据对端返回的状态码及必要字段的合法性判断握手过程是否成功。

  1. // NewClient creates a new WebSocket client connection over rwc.
  2. func NewClient(config *Config, rwc io.ReadWriteCloser) (ws *Conn, err error) {
  3.     br := bufio.NewReader(rwc)
  4.     bw := bufio.NewWriter(rwc)
  5.     err = hybiClientHandshake(config, br, bw)
  6.     if err != nil {
  7.         return
  8.     }
  9.     buf := bufio.NewReadWriter(br, bw)
  10.     ws = newHybiClientConn(config, buf, rwc)
  11.     return
  12. }
  13. Ø WS连接创建的过程即为Conn对象的构造和初始化过程,各自字段的含义及备注说明如下:
  14. // newHybiConn creates a new WebSocket connection speaking hybi draft protocol.
  15. func newHybiConn(config *Config, buf *bufio.ReadWriter, rwc io.ReadWriteCloser, request *http.Request) *Conn {
  16.     if buf == nil {
  17.         br := bufio.NewReader(rwc)
  18.         bw := bufio.NewWriter(rwc)
  19.         buf = bufio.NewReadWriter(br, bw)
  20.     }
  21.     ws := &Conn{config: config, request: request, buf: buf, rwc: rwc,
  22.         frameReaderFactory: hybiFrameReaderFactory{buf.Reader},
  23.         frameWriterFactory: hybiFrameWriterFactory{
  24.             buf.Writer, request == nil},
  25.         PayloadType:        TextFrame,
  26.         defaultCloseStatus: closeStatusNormal}
  27.     ws.frameHandler = &hybiFrameHandler{conn: ws}
  28.     return ws
  29. }
  30. // Conn represents a WebSocket connection.
  31. //
  32. // Multiple goroutines may invoke methods on a Conn simultaneously.
  33. type Conn struct {
  34.     config  *Config // 连接建立的基础参数配置
  35.     request *http.Request // 服务端WS处理用,保存对端WS连接的握手请求对象
  36.     buf *bufio.ReadWriter // TCP连接的缓存读写
  37.     rwc io.ReadWriteCloser // 关闭连接的接口对象
  38.     rio sync.Mutex
  39.     frameReaderFactory // 工厂类-构造帧读对象
  40.     frameReader // 读对象记录:每次的读都要构造新的读对象,用于处理连接中的数据。该对象记录用于读取上一次读操作后剩余的数据
  41.     wio sync.Mutex
  42.     frameWriterFactory // 工厂类-构造写对象
  43.     frameHandler // 读操作中的中继处理,如连续读中的状态码记录和转换
  44.     PayloadType        byte // 与conn对象绑定,写数据时默认的数据类型
  45.     defaultCloseStatus int
  46.     // MaxPayloadBytes limits the size of frame payload received over Conn
  47.     // by Codec's Receive method. If zero, DefaultMaxPayloadBytes is used.
  48.     MaxPayloadBytes int // 读数据时最大的有效长度,超长直接报错
  49. }

5) 连接建立之后,就是WS帧的读写操作。WS帧的结构为:

|------------- Frame Header -----------------|------------------- PlayLoad ----------------|

FrameHeader是对帧状态、长度等的基本信息描述,对PayLoad的读取起决定作用。

先看读操作

  1. func (ws *Conn) Read(msg []byte) (n int, err error) {
  2.     ws.rio.Lock()
  3.     defer ws.rio.Unlock()
  4. again:
  5.     if ws.frameReader == nil {
  6. // 构造读对象。实现上是从连接中读数据,构造ws帧的描述信息,即Frame Header,包含状态位,帧长度等;
  7.         frame, err := ws.frameReaderFactory.NewFrameReader()
  8.         if err != nil {
  9.             return 0, err
  10.         }
  11. // 可能是中间读,所以通过handler校正下PayloadType
  12.         ws.frameReader, err = ws.frameHandler.HandleFrame(frame)
  13.         if err != nil {
  14.             return 0, err
  15.         }
  16.         if ws.frameReader == nil {
  17.             goto again
  18.         }
  19.     }
  20.     // 根据FrameHeader描述,读取连接中的PayLoad数据。如果当前的OperateCode是FinishFrame则表示
  21. // 整个帧读取结束,返回io.EOF
  22.     n, err = ws.frameReader.Read(msg)
  23.     if err == io.EOF {
  24.         if trailer := ws.frameReader.TrailerReader(); trailer != nil {
  25.             io.Copy(ioutil.Discard, trailer)
  26.         }
  27.         ws.frameReader = nil
  28.         goto again //再未遇到CloseFrame之前,要多次、连续读
  29.     }
  30.     return n, err
  31. }

6) 写操作与读类似,读是分头解析和数据读取,那么写自然也是分两部分。值得注意是,写操作是一次性将所有数据单帧写入到连接,不做拆分,每一帧都结束帧,不存在中间连续帧的情况。

  1. // Write implements the io.Writer interface:
  2. // it writes data as a frame to the WebSocket connection.
  3. func (ws *Conn) Write(msg []byte) (n int, err error) {
  4.     ws.wio.Lock()
  5.     defer ws.wio.Unlock()
  6. // 构造FrameHeader对象,完成Header中描述字段的初始化赋值
  7.     w, err := ws.frameWriterFactory.NewFrameWriter(ws.PayloadType)
  8.     if err != nil {
  9.         return 0, err
  10.     }
  11. // 写Header和PayLoad数据
  12.     n, err = w.Write(msg)
  13.     w.Close()
  14.     return n, err
  15. }

至此,WS客户端的WS建立及数据读写过程就说完了。其实WS Client的建立和读写操作对服务同样适用,剩下的是服务端如何处理WS的握手请求并建立WS连接的。首先从http的请求分发开始

1) 服务启动时会注册如下的http请求处理,表示如果是chat请求则走WS的握手过程

  1. func main() {
  2.     //fmt.Printf("LiveGoServer is ready...\n")
  3.     go func() {
  4.         http.Handle("/chat", websocket.Handler(pwint)) //这里是将函数对象强转为Handler类型
  5.     }()

2) Handler是实现了http.Handler接口的类型,自然在接口的实现中开始处理对端的WS握手请求

  1. // Handler是函数类型别名
  2. type Handler func(*Conn)
  3. // ServeHTTP implements the http.Handler interface for a WebSocket
  4. func (h Handler) ServeHTTP(w http.ResponseWriter, req *http.Request) {
  5.     s := Server{Handler: h, Handshake: checkOrigin}
  6.     s.serveWebSocket(w, req)
  7. }

3)serveWebSocket是完成握手过程,创建WS连接

  1. func (s Server) serveWebSocket(w http.ResponseWriter, req *http.Request) {
  2.     rwc, buf, err := w.(http.Hijacker).Hijack() // 接管http的tcp连接对象
  3.     if err != nil {
  4.         panic("Hijack failed: " + err.Error())
  5.     }
  6.     // The server should abort the WebSocket connection if it finds
  7.     // the client did not send a handshake that matches with protocol
  8.     // specification.
  9.     defer rwc.Close() // 直播业务结束后,断开tcp连接
  10. // 创建WS连接
  11.     conn, err := newServerConn(rwc, buf, req, &s.Config, s.Handshake)
  12.     if err != nil {
  13.         return
  14.     }
  15.     if conn == nil {
  16.         panic("unexpected nil conn")
  17.     }
  18. // 这里类似接口回调,转发到上方的pwint接口中。pwint为阻塞接口,持续的连接读写。
  19.     s.Handler(conn)
  20. }

4) 最后看一下pwint,可以发现是最上层的业务处理:更新临时组、从当前的连接中读后转发给其他连接,完成直播中的多端分发处理。

好了,没写多少文字,大部分都是在分析代码,相信应该知道websocket是怎么回事了,这就是与new WebSocket而后Send、Receive调用相比有意思的地方的,就是可以看到背后的细节。

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/小小林熬夜学编程/article/detail/157559
推荐阅读
相关标签
  

闽ICP备14008679号