redsocks源码阅读

最近有机会了解和使用了开源软件redsocks，这是一个运行在设备端的代理服务器（proxy server）前端，在linux下能很好地支持iptables，实现系统级的透明代理。

http://s7/bmiddle/001VVBA0zy6MrT2go5w36&690

redsocks是单线程的，包括所依赖的库libevent也是单线程的，因此适合运行在资源有限的嵌入式设备上，效率很高。在Android上也有一些应用程序（app）是基于redsocks开发的，比如ProxyDroid是一个Android上的透明代理软件，底层直接使用了redsocks，但是去掉了对DNS、UDP的支持。

redsocks处理网络通信、消息循环、缓冲区管理等都是基于开源库libevent的，因此在阅读 redsocks 源码前应先对 libevent 的 bufferevent、evbuffer 等有所了解，好在虽然libevent代码量远比redsocks大，但有详细的官方文档可读，不需要理解它的工作原理只需要知道怎么用就行了，libevent的参考手册在http://www.wangafu.net/~nickm/libevent-book/，据说Google的Chrome浏览器中也用了libevent。

redsocks用C语言写成，全部源码仅有7K余行，可从https://github.com/darkk/redsocks下载，虽然该开源项目已有两三年没有被维护过，但代码质量很高，可读性也很好。

本文仅针对 http-relay 的情形（也就是一般的HTTP代理）阅读了相关代码，主要对app、redsocks、proxy server三者之间的数据传输流程进行了分析。下面主要是自己的阅读笔记，供日后备忘，可能写得有些凌乱（原文放在Evernote上，此处内容有所删改）。

redsocks 创建两个socket，一个是 client 端的，在 redsocks.c 中的 redsocks_accept_client 中，accept 应用程序后得到 client_fd，并基于 client_fd 调用 bufferevent_new 创建了 client->client：

client->client = bufferevent_new(client_fd, NULL, NULL, redsocks_event_error, client);

 

然后调用 bufferevent_enable 设置 read 回调函数：

if (bufferevent_enable(client->client, EV_READ) != 0) {

    redsocks_log_errno(client, LOG_ERR, "bufferevent_enable");

    goto fail;

}

 

然后

if (self->relay_ss->connect_relay)

    self->relay_ss->connect_relay(client);

else

redsocks_connect_relay(client);

 

会调用 httpr_connect_relay，挂上读回调函数 httpr_client_read_cb：

client->client->readcb = httpr_client_read_cb;

 

所以 client 那边第一次有数据过来时，也就是 HTTP Request 头过来时，应该是 httpr_client_read_cb 会被调用，在 httpr_client_read_cb 里面从 buffev->input 中逐行读入 HTTP Request 头并分析、复制到 httpr->client_buffer 中，读取完后，connect_relay 被设为 1，先调用 httpr_client_read_content 将紧跟在 HTTP Request 头之后的一些数据也复制到 httpr->client_buffer 中，然后去调用 redsocks_connect_relay。

redsocks_connect_relay 调用 red_connect_relay，其中创建了另一个 socket，即 relay 端的 relay_fd，基于 relay_fd 调用 bufferevent_new 创建了 client->relay，回调函数 redsocks_relay_connected 作为写回调被挂上。

在 redsocks_relay_connected 中，将 httpr_relay_read_cb 和 httpr_relay_write_cb 分别作为 client->relay 的读、写回调被挂上（因此刚才的写回调 redsocks_relay_connected 被顶替掉了），并立即调用写回调 httpr_relay_write_cb，在该函数中将刚才读入到 httpr->client_buffer 中的 HTTP Request 头（及紧跟其后的一些数据）写入到 client->relay 中，其间还处理了认证信息，最后使能了 client->relay 的读事件（这里 buffev 就是 client->relay）：

buffev->wm_read.low = 1;
buffev->wm_read.high = HTTP_HEAD_WM_HIGH;
bufferevent_enable(buffev, EV_READ);

 

当 relay 端有数据（即 HTTP Response）回来时，回调 httpr_relay_read_cb 被调用，从 buffev->input 中逐行读入 HTTP Response 头并分析、复制到 httpr->relay_buffer 中（这里 buffev 就是 client->relay），当 HTTP Response 正常并且 HTTP Response 头全部读完后再将 httpr->relay_buffer 中的数据全部写入到 client->client 中也就是送给应用程序，之后去调用 redsocks_start_relay，在该函数中将 client->client 和 client->relay 如下挂上新的读、写回调，原来的回调都被顶替掉了：

client->client->readcb = redsocks_relay_clientreadcb;
client->client->writecb = redsocks_relay_clientwritecb;
client->relay->readcb = redsocks_relay_relayreadcb;
client->relay->writecb = redsocks_relay_relaywritecb;

 

所以这 4 个回调处理的是 HTTP Request 和 Response 中除了头信息之外的数据，它们的工作就是搬运数据（不涉及内存复制所以效率很高）并带有流量控制。这 4 个回调函数的第 2 个参数 _client 都是 client，第 1 个参数 from 或 to 就是 client->client 或 client->relay，所以它们的第 1 个参数都没被使用而只使用了第 2 个参数。

httpr_relay_read_cb 返回时，client->relay->input 中可能仍剩有数据（也就是紧跟在 HTTP Response 头之后的一些数据），这些数据会被回调 redsocks_relay_clientwritecb 或者 redsocks_relay_relayreadcb 读走送往 client 端。

阅读上述 4 个回调函数的代码，不难发现：

redsocks_relay_relayreadcb 与 redsocks_relay_clientwritecb 所做的工作部分重复了；

redsocks_relay_clientreadcb 与 redsocks_relay_relaywritecb 所做的工作部分重复了。

 

可以把它们分别看成是一个推一个拉，前一个回调是当有数据过来时就推到另一端，后一个回调是当数据都送走以后再去另一端拉新的数据，两个并不会发生冲突。

在函数 redsocks_relay_writecb（在 redsocks_relay_relaywritecb 和 redsocks_relay_clientwritecb 中被调用）中判断是否传输结束，若结束则调用 redsocks_shutdown 结束整个流程。

每当 client 端有新的 HTTP Request 过来时，又重复执行上面的流程。

最后看一下传输结束时的处理流程。

先看回调函数 redsocks_event_error，该回调函数是在函数 redsocks_connect_relay 中创建 client->relay 时挂上的错误处理回调函数；另一方面，该回调函数也是在函数 redsocks_accept_client 中创建 client->client 时挂上的错误处理回调函数，也就是说这个回调函数身兼 client->relay 与 client->client 二者的错误处理回调函数。

当 relay 端向 client 端传输 HTTP Response 结束时，回调函数 redsocks_event_error 被调用（应该是由 relay 端的 socket 事件触发的），其参数 what 的值为 17（即 EVBUFFER_READ|EVBUFFER_EOF），buffev 等于 client->relay，看下面代码：

if (what == (EVBUFFER_READ|EVBUFFER_EOF)) {

    struct bufferevent *antiev;

    if (buffev == client->relay)

        antiev = client->client;

    else

        antiev = client->relay;

 

    redsocks_shutdown(client, buffev, SHUT_RD);

 

    if (antiev != NULL && EVBUFFER_LENGTH(antiev->output) == 0)

        redsocks_shutdown(client, antiev, SHUT_WR);

}

 

antiev 将等于 client->client，然后函数 redsocks_shutdown 被调用，将 client->relay_evshut 置上 EV_READ，接下来，如果 EVBUFFER_LENGTH(antiev->output) == 0 也就是 client->client->output 已经空了，就再调用函数 redsocks_shutdown 将 client->client_evshut 置上 EV_WRITE。至此从 relay 端向 client 端的传输完全结束了。

反过来，当 client 端向 relay 端传输 HTTP Request 结束时，回调函数 redsocks_event_error 也被调用（应该是由 client 端的 socket 事件触发的），其参数 what 的值也为 17，buffev 则等于 client->client，跟上面相似的，也将导致函数 redsocks_shutdown 被调用两次，最后使得 client->client_evshut 被置上 EV_READ 及 client->relay_evshut 被置上 EV_WRITE，至此两个方向的传输都完全结束了，这样一来，在函数 redsocks_shutdown 的最后：

if (client->relay_evshut == (EV_READ|EV_WRITE) && client->client_evshut == (EV_READ|EV_WRITE)) {

    redsocks_log_error(client, LOG_DEBUG, "both client and server disconnected");

    redsocks_drop_client(client);

}

条件判断结果将为真，导致函数 redsocks_drop_client 被调用，该函数进行一系列的清除和释放资源动作，包括释放 client 数据结构本身，至此本 client 完全终结。

附：redsocks中的几个关键概念和数据结构：

client 端：即应用程序（app）端；

relay 端：即代理服务器（proxy server）端；

client：应用程序与 redsocks 建立连接后创建的数据结构，应用程序每次与 redsocks 建立连接会创建一个新的 client；

client_fd 和 relay_fd：分别是与 client 端通信和与 relay 端通信的 socket 句柄；

client->client 和 client->relay：分别是与 client_fd 和 relay_fd 关联的 bufferevent 对象；

httpr->client_buffer 和 httpr->relay_buffer：分别是在 http-relay 中用来分析、处理 HTTP Request 和 Response 头的缓冲区。httpr->client_buffer 中除了 HTTP Request 头，还有紧跟其后的一些数据；而 httpr->relay_buffer 中只有 HTTP Response 头。