总结使用libwebsockets开发接入层

Posted 2022-06-03 祁峰

• 作者：邹祁峰
• 邮箱：[e-mail]
• 博客：http://blog.csdn.net/qifengzou
• 日期：2015.12.13~2015.12.14
• 转载请注明来自"祁峰"的CSDN博客

1 引言

    WebSockets是html5支持的一种让浏览器与服务器全双工通信的协议，其以更小的开销高效的提供了Web连接。相较于经常推送实时数据到客户端甚至通过维护两个HTTP连接来模拟全双工连接的旧的轮询或长轮询来说，这将有效的减少网络流量与延迟。如果想知道更多关于WS协议的信息，请自行查找，在此不再复述。本篇的重点是讲述如何使用C语言实现的libwebsockets进行进一步的开发。    由于之前系统上线时间紧迫，为了缩短开发时间，因此使用nginx作为WS代理，让其将接收WS连接请求，并将WS协议传输的数据BODY转发到接入层。但是使用nginx作为WS代理时，当终端与nginx建立一个WS连接，nginx就会与接入层建立一个TCP连接。因此，这将造成不管单台nginx服务器的配置多么牛逼，该服务器最多只能支持65535个并发，并且多了一个代理层，性能也会受到一定影响。    解决以上问题的办法就是：让接入层直接支持WS协议。由于系统接入层使用的是C语言开发，因此，本人选择以开源软件libwebsockets为基础，与原系统接入层进行融合。以下是系统改造前后的架构对比图：[注：后文将libwebsockets简写为LWS]
图1 改造对比图

2 改造LWS

2.1 支持libev

   由于LWS库默认情况下使用poll机制管理ws连接，为了让系统更高效的管理更多的并发，需要开启对libev的支持。可将CMakeLists.txt中的LWS_WITH_LIBEV选项由OFF改为ON来实现，如下图所示:

图2 开启LIBEV

2.2 改造libev

   从图1中的改造后的架构图中可以看出，改造后的WS接入层需要管理与终端的ws连接，同时需要管理与路由层各服务器的TCP连接，还得负责相邻层次间数据的转发工作。而目前LWS并未支持多线程，如果采用多线程的方式改造WS接入层，将可能出现无法预估的后果。因此，本人决定使用单进程单线程的方式，并使用LWS架构接管WS接入层与路由层之间的TCP连接。而要实现让LWS架构接管WS接入层与路由层之间的TCP连接，则需要对LWS库进行如下改造：

2.2.1 函数定义

   由于LWS库的Makefile编译选项中设置了-fvisibility=hidden，因此，如果想让LWS库中实现的函数能被库外调用，则在函数实现时必须使用LWS_VISIBLE进行显示说明。在LWS库中的libev.c中添加如下函数：[注：关于libev的用法, 请自行查询]

/******************************************************************************
 **函数名称: lws_libev_timer_start
 **功    能: 添加计时器
 **输入参数:
 **     context: lws上下文
 **     timer: 计时器
 **输出参数: NONE
 **返    回: VOID
 **实现描述: 将计时器加入到libev loop对象
 **注意事项:
 **作    者: # Qifeng.zou # 2015.12.10 #
 ******************************************************************************/
LWS_VISIBLE void lws_libev_timer_start(struct lws_context *context, ev_timer *timer)

    ev_timer_start(context->io_loop, timer);


/******************************************************************************
 **函数名称: lws_libev_timer_stop
 **功    能: 停止计时器
 **输入参数:
 **     context: lws上下文
 **     timer: 计时器
 **输出参数: NONE
 **返    回: VOID
 **实现描述: 将计时器从libev loop中删除
 **注意事项:
 **作    者: # Qifeng.zou # 2015.12.10 #
 ******************************************************************************/
LWS_VISIBLE void lws_libev_timer_stop(struct lws_context *context, ev_timer *timer)

    ev_timer_stop(context->io_loop, timer);


/******************************************************************************
 **函数名称: lws_libev_io_start
 **功    能: 开启IO帧听
 **输入参数:
 **     context: lws上下文
 **     io: IO对象
 **输出参数: NONE
 **返    回: VOID
 **实现描述: 将io对象加入到libev loop中
 **注意事项:
 **作    者: # Qifeng.zou # 2015.12.10 #
 ******************************************************************************/
LWS_VISIBLE void lws_libev_io_start(struct lws_context *context, ev_io *io)

    ev_io_start(context->io_loop, io);


/******************************************************************************
 **函数名称: lws_libev_io_stop
 **功    能: 停止IO帧听
 **输入参数:
 **     context: lws上下文
 **     io: IO对象
 **输出参数: NONE
 **返    回: VOID
 **实现描述: 将io对象从libev loop中删除
 **注意事项:
 **作    者: # Qifeng.zou # 2015.12.10 #
 ******************************************************************************/
LWS_VISIBLE void lws_libev_io_stop(struct lws_context *context, ev_io *io)

    ev_io_stop(context->io_loop, io);

代码1 函数定义

2.2.2 函数声明

   完成以上函数的定义后，还需按照如下的格式在libwebsockets.h中进行函数声明。如下所示：

LWS_VISIBLE LWS_EXTERN void lws_libev_timer_start(struct lws_context *context, ev_timer *timer);
LWS_VISIBLE LWS_EXTERN void lws_libev_timer_stop(struct lws_context *context, ev_timer *timer);
LWS_VISIBLE LWS_EXTERN void lws_libev_io_start(struct lws_context *context, ev_io *io);
LWS_VISIBLE LWS_EXTERN void lws_libev_io_stop(struct lws_context *context, ev_io *io);

代码2 函数声明

   完成对LWS库中libev的改造后，重新编译和安装LWS库，这时便可利用以上函数将外部建立的TCP连接注入到LWS框架，让LWS框架中的libev接管外部TCP连接的数据接收、数据发送、超时处理等处理。WS接入层与路由层之间的TCP连接，就是通过这种方式让LWS框架接管的。[注意：一定要按照以上格式声明函数，否则可能导致依赖此库的程序无法访问声明的函数]

3 使用LWS

3.1 注册协议回调

   终端向WS服务器发起ws连接请求时，一般会在协议头中通过Sec-WebSockets-Protocol指明协议名。而开源libwebsockets库通过对外提供注册协议回调的接口为用户自定义协议提供服务，注册协议回调的接口中将会指明协议名、以及对应的处理回调、自定义数据的大小等字段。其注册的方式如下所示：

/* 注册协议回调配置表 */
struct libwebsocket_protocols g_aws_protocols[] =

    
        "chat",                                         /* 协议名：其与Sec-Websockets-Protocol字段对应 */
        aws_callback_im_hdl,                            /* 回调函数：协议对应的回调处理函数 */
        sizeof(aws_im_session_data_t),                  /* 自定义数据空间大小：每个ws连接均会分配一个自定义数据空间 */
        0,                                              /* max frame size / rx buffer */
    ,
    
        "push",                                         /* 协议名 */
        aws_callback_push_hdl,                          /* 回调函数 */
        sizeof(aws_push_session_data_t),                /* 自定义数据空间大小 */
        0,                                              /* max frame size / rx buffer */
    ,
     NULL, NULL, 0, 0                                 /* 结束标识 */
;

代码3 注册协议回调    注意：如果终端向WS服务器发起的ws连接请求中并未指明Sec-WebSockets-Protocol字段，那么libwebsockets库默认使用注册协议回调配置表中的第一个配置项为该ws连接的提供服务。

3.2 回调函数参数

   回调函数用于处理对应协议各阶段的数据。该回调函数的各参数含义见表１所示： 表1 回调函数参数

序号	变量名	类型	含义
01	context	struct lws_context *	含义：全局上下文 备注：这是libwebsockets框架的上下文，负责所有ws连接的维护和管理
02	wsi	struct lws *	含义：WS连接对象 备注：每个ws连接均有一个wsi对象与之对应
03	reason	enum lws_callback_reasons	含义：调用回调的原因 备注：一个协议只对应回调函数，但是调用回调函数的情况很多，且回调原因不同，参数in的含义也会发生变化。
04	user	void *	含义：用户自定义数据 备注：每个ws连接均会带有一个用户自定义数据，可在其中放入用户关心的信息。其大小与协议回调注册表中对应配置项中的sizeof()向对应。
05	in	void *	含义：输入数据 备注：根据调用回调的原因，该输入数据的含义发生变化
06	len	size_t	含义：输入数据的长度

    回调函数参数中的reason指明了调用回调函数的原因，其也代表了ws连接正处于哪个处理阶段或状态。比如：在ws连接创建成功后，应该进行自定义数据的初始化；在ws连接销毁阶段，应该释放自定义数据中用户分配的空间等。因此，要正确的编写协议回调函数就必须对reason各状态值有正确的理解。以下将对服务器端开发者需要关心的reason状态值的进行解释： 表2 reason状态值

序号	状态值	含义
01	LWS_CALLBACK_WSI_CREATE	含义：正在创建ws连接对象 备注：此时表1中的wsi对象和user对象依然为空指针，因此，还不能初始化用户自定义对象。 回调函数的参数含义：     context: 全局上下文     wsi: 空指针     user: 空指针 　in: 空指针 　len: 0
02	LWS_CALLBACK_FILTER_PROTOCOL_CONNECTION	含义：使用lws库的人员可以在此过滤协议。 备注：在此处返回非0值时，lws库将会关闭该链接；该处返回0时，表示ws连接已经建立成功。此时表1中的wsi对象和user对象已不为空，因此，此时可以对用户自定义对象user进行初始化处理。 回调函数的参数含义：     context: 全局上下文     wsi: ws连接对象     user: 用户自定义数据 　in: 空指针 　len: 0 [注意：测试中发现同一个wsi可能多次由该reason调用回调，且该wsi对象的用户自定义数据的指针会发生变化，导致用户设置的数据丢失，造成严重后果。解决方案：不让lws维护对象，而是我们自己申请和维护数据！]
03	LWS_CALLBACK_LOCK_POLL	含义：添加保护ws连接状态的互斥锁 备注：当采用的是多线程编程，则在此添加互斥锁保护ws连接相关状态，防止冲突。如果是单进程方式，则无需做任何操作。
04	LWS_CALLBACK_UNLOCK_POLL	含义：解除保护ws连接状态的互斥锁 备注：当采用的是多线程编程，则在此解除互斥锁。如果是单进程方式，则无需做任何操作。
05	LWS_CALLBACK_RECEIVE	含义：收到一帧完整数据 备注：表示ＷＳ服务端收到客户端发送过来的一帧完整数据，此时表1中的in表示收到的数据，len表示收到的数据长度。需要注意的是：指针in的回收、释放始终由LWS框架管理，只要出了回调函数，该空间就会被LWS框架回收。因此，开发者若想将接收的数据进行转发，则必须对该数据进行拷贝。 回调函数的参数含义：     context: 全局上下文     wsi: ws连接对象     user: 用户自定义数据     in: 接收数据的起始地址     len: 接收数据的长度
06	LWS_CALLBACK_SERVER_WRITEABLE	含义：此ws连接为可写状态 备注：表示wsi对应的ws连接当前处于可写状态，即：可发送数据至客户端。 回调函数的参数含义：     context: 全局上下文     wsi: ws连接对象     user: 用户自定义数据 　in: 空指针 　len: 0
07	LWS_CALLBACK_CLOSED	含义：ws连接已经断开 备注：不能在此释放内存空间，否则存在内存泄漏的风险！！！因为连接断开时，并不总是会回调LWS_CALLBACK_CLOSED的处理！
	LWS_CALLBACK_WSI_DESTROY	含义：正在销毁ws连接对象 备注：表示libwebsockets框架即将销毁wsi对象。此时如果用户自定义对象中存在动态分配的空间，则需要在此时进行释放。 回调函数的参数含义：     context: 全局上下文     wsi: ws连接对象     user: 用户自定义数据 　in: 空指针 　len: 0

3.3 重要函数说明

   由于libwebsockets库未能对其能控制ws连接状态的函数进行重点说明，致使本人在使用过程中走了很多弯路。故，在此列出相关函数进行重点说明。

表3 重要函数列表

序号	函数名	功能
01	lws_get_peer_write_allowance	功能：该ws连接允许发送的字节数 备注：如果有发送字节限制，则返回正数；如果无发送字节限制，则返回-1。
02	lws_send_pipe_choked	功能：判断ws连接是否阻塞 备注：如果ws连接阻塞，则返回1，否则返回0。
03	lws_write	功能：将数据发送给对端 备注：函数参数说明   wsi: ws连接对象   buf: 需要发送数据的起始地址。          注意：必须在指针buf前预留长度为LWS_SEND_BUFFER_PRE_PADDING的空间，同时在指针buf+len后预留长度为LWS_SEND_BUFFER_POST_PADDING的空间。   len: 需要发送数据的长度   protocol: 如果该连接是http连接，则该参数的值为LWS_WRITE_HTTP；如果该连接是ws连接，则该参数的值为LWS_WRITE_BINARY，但如果第一次发送的数据长度n < len，则发送后续长度为(len - n)字节的数据时，该参数值改为LWS_WRITE_HTTP。
04	lws_http_transaction_completed	功能：当前连接为http连接，而非ws连接时，如果当前http请求的应答数据发送完毕，则可使用该函数重置http连接的相关状态，只有收到新的http请求才能激活该http连接。 备注：如果当前连接为ws连接，则千万不要调用此函数，其将导致服务端则无法再激活可写事件。
05	lws_callback_on_writable	功能：将ws连接加入可写事件监听
06	lws_callback_on_writable_all_protocol	功能：将某个协议的所有ws连接加入可写事件监听 备注：在网络中存在各种情况可能导致服务端并不知道与客户端的连接已经断开，比如：客户端掉电。为了应对这种情况的存在，需要每隔一段时间执行该函数。再在该协议的回调函数的LWS_CALLBACK_SERVER_WRITEABLE事件中判断一下连接是否超时，如果超时则返回非零值。

4 存在问题

 问题1：之前网上很多描述libwebsockets库优点包括：节省内存空间。而从实际使用的情况上分析，libwebsockets库消耗了大量的内存空间。比如：快速的建立1000个并发，将会导致消耗200MB的内存空间，且前1000个并发断开后，再此建立1000个并发时，内存还会快速的增长！之前本人还以为存在内存泄漏的情况，后经反复使用valgrind进行内存泄漏的分析，发现并不存在内存泄漏的情况，因此，本人认为libwebsockets库的内存管理策略存在严重问题。

  问题2：测试中发现同一个wsi可能多次由原因LWS_CALLBACK_FILTER_PROTOCOL_CONNECTION调用回调，且该wsi对象的用户自定义数据的指针会发生变化，导致用户设置的数据丢失，造成严重数据丢失和程序CRASH。解决方案：不让lws维护对象，而是我们自己申请和维护数据！