序章

最近在校招面试的时候顺手翻了一下TCP/IP详解卷一，然后就想起来VpnService刚出来的时候写过一个移动端抓包应用，写得非常累，还不少bug。其实proxy，sniffer之类的应用，在Android上实现都差不多，所以就趁着这个机会，看了一下圈内知名app shadowsocks Android端的实现。

proxy原理

proxy原理细节就不再赘述，简单地说，proxy其实就是起到了接收请求，返回响应的作用。Android上不是所有的应用都允许配置代理服务器的，所以我们必须实现一个透明代理（Transproxy）那么要在Android上实现一个Transproxy，我们需要做什么呢？首先我们需要实现一个client，负责和proxy server建立连接，转发流量，然后我们需要把整个系统的流量都拦截下来，转发到我们的client处理，最后再把处理完的响应交给系统，由系统分发到各个进程。

流量拦截

先说说流量转发，这一块的实现在Android平台上有一个艰辛的演进之路。在Android 4.0之前，Android SDK是没有提供接口让应用拦截系统流量的，因此需要实现全局透明代理，必须从更底层的Linux下手，Linux内核有一个netfilter模块，提供了包过滤，NAT等功能，上层的iptables就是基于netfilter实现的，4.0之前的流量拦截就是基于iptables实现的。Android 4.0之后，Android提供了VpnService类，允许用户实现自定义的Vpn服务，因此可以用这个类来拦截流量，很多proxy和sniffer都是基于这种方案实现，但是VpnService在这个时候API还不够完善，比如不拦截指定app流量依然无法实现，直到Android 5.0才实现了这个功能。

iptables实现

Android平台的透明代理早期都是基于NAT来实现的，netfilter模块内部有三张表，mangle, filter和nat。我们用的最多的可能是filter，如果要实现地址转换或者端口转发，就需要用到nat表。通俗一点来说，netfilter的存在，允许Linux被当作一个路由器使用，而NAT涉及到在IP包经过路由时，修改其源地址，端口或目标地址，端口。在Android 2.3时代，有一个很知名的代理软件，GAEProxy，全局代理功能就是通过iptables来实现的。shadowsocks早期为了实现分应用代理，也是使用iptables来实现全局代理的。这部分的代码都太过久远，现在很难找了，不过shadowsocks-libev提供了ss-redir的功能，里面也配置了iptables的规则，目的也是一样，为了实现在Linux上的透明代理，我们可以参考一下这部分规则，原理也是一样的。

# Create new chain
iptables -t nat -N SHADOWSOCKS
iptables -t mangle -N SHADOWSOCKS

# Ignore your shadowsocks server's addresses
# It's very IMPORTANT, just be careful.
iptables -t nat -A SHADOWSOCKS -d 123.123.123.123 -j RETURN

# Ignore LANs and any other addresses you'd like to bypass the proxy
# See Wikipedia and RFC5735 for full list of reserved networks.
# See ashi009/bestroutetb for a highly optimized CHN route list.
iptables -t nat -A SHADOWSOCKS -d 0.0.0.0/8 -j RETURN
iptables -t nat -A SHADOWSOCKS -d 10.0.0.0/8 -j RETURN
iptables -t nat -A SHADOWSOCKS -d 127.0.0.0/8 -j RETURN
iptables -t nat -A SHADOWSOCKS -d 169.254.0.0/16 -j RETURN
iptables -t nat -A SHADOWSOCKS -d 172.16.0.0/12 -j RETURN
iptables -t nat -A SHADOWSOCKS -d 192.168.0.0/16 -j RETURN
iptables -t nat -A SHADOWSOCKS -d 224.0.0.0/4 -j RETURN
iptables -t nat -A SHADOWSOCKS -d 240.0.0.0/4 -j RETURN

# Anything else should be redirected to shadowsocks's local port
iptables -t nat -A SHADOWSOCKS -p tcp -j REDIRECT --to-ports 12345

# Add any UDP rules
ip route add local default dev lo table 100
ip rule add fwmark 1 lookup 100
iptables -t mangle -A SHADOWSOCKS -p udp --dport 53 -j TPROXY --on-port 12345 --tproxy-mark 0x01/0x01

# Apply the rules
iptables -t nat -A PREROUTING -p tcp -j SHADOWSOCKS
iptables -t mangle -A PREROUTING -j SHADOWSOCKS

首先创建了一个叫做SHADOWSOCKS的链，然后把服务端地址排除，否则会造成死循环，接下来一段过滤掉局域网地址，然后把其他所有TCP流量都重定向到shadowsocks本地监听的端口。这里要注意的是，iptables规则匹配是从前往后进行的，一旦匹配上一条就不再匹配后面的了，所以可以这么写。
接下来一段是关于UDP的规则，UDP是由TPROXY来处理的，这是因为通过NAT转发的包会修改目标地址，而代理软件是需要知道原始目标地址的，TCP包能获取到原始地址是因为netfilter的连接跟踪机制，而UDP包不行，所以需要由TPROXY来处理，TPROXY也是内核的一个模块，就是用来实现透明代理的，细节可以参考官方文档：https://www.kernel.org/doc/Documentation/networking/tproxy.txt
最后两行应用配置好的规则，综上，全局透明代理在Android早期版本就是这么实现的，因为配置iptables需要root权限，所以早期要实现全局透明代理必须root。

VpnService实现

早期的Android版本只支持内置的VPN连接，VPN服务器必须是标准的PPTP或者L2TP/IPSec实现，从Android 4.0开始，SDK提供了VpnService系列的接口，允许开发者实现自定义的VPN协议。这套API提供了拦截IP包的能力，给开发者提供了高度的可定制性。从官网摘了一张图，很清楚的描述了VpnService的实现原理。

可以看到，系统为VpnService实现了一个TUN设备，TUN设备可以理解为一个工作在OSI参考模型第三层的虚拟网卡，说得形象一点，物理网卡是通过网线收发数据包，而TUN设备通过/dev/tun这个文件来收发数据包。因为TUN设备工作在网络层，所以它没有MAC地址，其他方面与物理网卡没有区别。
从图中可以很清晰地看到，自定义的VpnService直接与TUN设备交互，当VpnService运行的时候，对于应用的出口流量，系统会通过TUN设备转发给VpnService，VpnService再通过一个被保护的连接（不再经过VpnService，否则会死循环）与VPN服务端交互，当产生回包时，VpnService把回包写入TUN设备，再由系统分发给应用程序。
在Android 4.0之后，全局透明代理基本都改为了这种方式实现，相比于iptables的实现，VpnService更稳定，而且不需要root，大大降低了使用门槛。
VpnService有很高的权限，可以获取系统的所有IP数据包，所以任何VpnService在启用前，都需要弹窗让用户确认，并且在建立连接后会在系统通知栏出现一条无法划掉的通知。任何时刻最多只能有一个VpnService被启用，后启动的VpnService会替代前一个。

分应用代理

上一节说到了VpnService是不需要root即可实现透明代理的，但是shadowsocks在VpnService出来之后很长一段时间还是保留了需要root的NAT方案，这显然不是作者忘了删除，而是因为VpnService早期API不全，分应用代理的功能无法实现。总不能更新版本后，原有的功能反而不支持了吧，所以NAT实现必须留着。直到Android 5.0，VpnService.Builder才加上了如下两个接口：

public VpnService.Builder addAllowedApplication (String packageName)
public VpnService.Builder addDisallowedApplication (String packageName)

这两个接口类似于黑名单和白名单，这两个接口是互斥的，调用addAllowedApplication会导致只有指定app通过VPN通信，其他的app是直连的，就像没有VPN一样，调用addDisallowedApplication会导致只有指定app直连，其他的app流量都通过VPN。
那么Android 5.0之前是通过什么方式实现分应用代理的呢？还是ipbtales，iptables有通过uid和gid匹配的扩展，可以筛选指定用户和用户组的流量。我们知道，Android上每个安装的app都有自己独立的uid，通过iptables很容易配置匹配规则，这里从redsocks里摘了两行样例：

# Any tcp connection made by `luser' should be redirected.
root# iptables -t nat -A OUTPUT -p tcp -m owner --uid-owner luser -j REDSOCKS

# You can also control that in more precise way using `gid-owner` from
# iptables.
root# groupadd socksified
root# usermod --append --groups socksified luser
root# iptables -t nat -A OUTPUT -p tcp -m owner --gid-owner socksified -j REDSOCKS

这里的OUTPUT代表所有本机产生的流量，上面两段分别演示了按uid筛选和按gid筛选的方法。

shadowsocks-android源码分析

整体架构

要了解shadowsocks-android的整体架构，可以先从安装后的文件结构入手，这里可以看到，安装后的lib目录下有三个so文件。

:/data/app/com.github.shadowsocks-D1d-hk6w1vgWFxEyIY-e3g==/lib/arm64 # 
ls -l
total 1228
-rwxr-xr-x 1 system system 274296 1979-11-30 00:00 libredsocks.so
-rwxr-xr-x 1 system system 642440 1979-11-30 00:00 libss-local.so
-rwxr-xr-x 1 system system 324152 1979-11-30 00:00 libtun2socks.so

翻一下编译脚本，会发现这三个so后缀的文件，其实全部都是ELF可执行文件。Android.mk里有这么一句：

BUILD_SHARED_EXECUTABLE := $(LOCAL_PATH)/build-shared-executable.mk

然后build-shared-executable.mk文件内容如下：

LOCAL_BUILD_SCRIPT := BUILD_EXECUTABLE
LOCAL_MAKEFILE     := $(local-makefile)
$(call check-defined-LOCAL_MODULE,$(LOCAL_BUILD_SCRIPT))
$(call check-LOCAL_MODULE,$(LOCAL_MAKEFILE))
$(call check-LOCAL_MODULE_FILENAME)
# we are building target objects
my := TARGET_
$(call handle-module-filename,lib,$(TARGET_SONAME_EXTENSION))
$(call handle-module-built)
LOCAL_MODULE_CLASS := EXECUTABLE
include $(BUILD_SYSTEM)/build-module.mk

相比BUILD_EXECUTABLE，改动只有一行$(call handle-module-filename,lib,$(TARGET_SONAME_EXTENSION))，把可执行文件按so来命名。其实这么改主要是为了省事，后缀改为so，后续直接被当成so打包进apk，实际上还是可执行文件。
这三个文件，libredsocks.so主要用来实现透明代理，目前已经废弃，我们先不看，libss-local.so既是一个SOCKS5服务器，也是用来和remote通信的客户端，是整个shadowsocks-android的核心，libtun2socks.so用来实现从tun设备读取数据包到SOCKS5协议的转换。我们先上一张整体的架构图表明各个部分的关系，后面详细讲各个部分的逻辑。

从图上可以看到，上层的VpnService只用来获取tun设备的fd，获取到fd之后通过sock_path这个LocalSocket传递给tun2socks，tun2socks获取到fd之后从tun读取数据包，然后转发给ss-local，ss-local负责与远程服务端建立连接，并把这个fd通过protect_path回传给VpnService，VpnService再把这个fd protect起来，防止死循环。

VpnService实现

VpnService的逻辑写得相当简单，逻辑都在startProcesses方法里。

override suspend fun startProcesses(hosts: HostsFile) {
    worker = ProtectWorker().apply { start() }
    super.startProcesses(hosts)
    sendFd(startVpn())
}

这里一共做了四件事情：

启动libss-local.so，也就是本地的SOCKS5服务器
启动libtun2socks.so，用来做协议转换
启动一个线程，用于监听和remote建连成功的fd，并protect起来
将tun设备的fd发送给tun2socks
我这里debug了一下，前两步执行的命令是：

#/lib/arm64/libss-local.so -b 127.0.0.1 -l 1080 -t 600 -S /data/user_de/0/com.github.shadowsocks/no_backup/stat_main -c /data/user/0/com.github.shadowsocks/no_backup/shadowsocks.conf -V -u -D --fast-open

#/lib/arm64/libtun2socks.so --netif-ipaddr 172.19.0.2 --socks-server-addr 127.0.0.1:1080 --tunmtu 1500 --sock-path sock_path --dnsgw 127.0.0.1:5450 --loglevel warning --netif-ip6addr fdfe:dcba:9876::2 --enable-udprelay

命令具体的参数我们后面的章节慢慢分析，这里只需要注意，两条命令中127.0.0.1:1080是相同的。tun2socks和ss-local正是通过这个socket通信的。
这里需要特别注意的是第三和第四步，这两个fd的传递体现了VpnService的关键作用。

fd的传递

这里传递的有两个fd，分别通过sock_path和protect_path两个local socket传递，我们从Java到native code来分析一下两个fd的传递过程以及作用。

VpnService -> tun2socks

VpnService中通过sock_path发送出去了一个fd，这里传入的fd其实就是VpnService.Builder.establish()方法返回的fd，也就是tun设备的fd。

private suspend fun sendFd(fd: FileDescriptor) {
    var tries = 0
    val path = File(Core.deviceStorage.noBackupFilesDir, "sock_path").absolutePath
    while (true) try {
        delay(50L shl tries)
        LocalSocket().use { localSocket ->
            localSocket.connect(LocalSocketAddress(path, LocalSocketAddress.Namespace.FILESYSTEM))
            localSocket.setFileDescriptorsForSend(arrayOf(fd))
            localSocket.outputStream.write(42)
        }
        return
    } catch (e: IOException) {
        if (tries > 5) throw e
        tries += 1
    }
}

启动tun2socks的命令中，也通过--sock-path sock_path参数指定了这个local socket，那么看一下native code中对sock_path的处理。
tun2socks的入口是tun2socks.c的main方法，解析命令行参数的方法是

int parse_arguments (int argc, char *argv[])

命令行参数最后会被解析到如下结构体：

// command-line options
struct {
    int help;
    int version;
    int logger;
    #ifndef BADVPN_USE_WINAPI
    char *logger_syslog_facility;
    char *logger_syslog_ident;
    #endif
    int loglevel;
    int loglevels[BLOG_NUM_CHANNELS];
    char *netif_ipaddr;
    char *netif_netmask;
    char *netif_ip6addr;
    char *socks_server_addr;
    char *username;
    char *password;
    char *password_file;
    int append_source_to_username;
    char *udpgw_remote_server_addr;
    int udpgw_max_connections;
    int udpgw_connection_buffer_size;
    int udpgw_transparent_dns;
#ifdef __ANDROID__
    int tun_mtu;
    int fake_proc;
    char *sock_path;
    char *pid;
    char *dnsgw;
#else
    char *tundev;
#endif
} options;

那么再看一下对char *sock_path的引用，整个方法比较简短：

#ifdef __ANDROID__
int wait_for_fd()
{
    int fd, sock;
    struct sockaddr_un addr;

    if ((sock = socket(AF_UNIX, SOCK_STREAM, 0)) == -1) {
        BLog(BLOG_ERROR, "socket() failed: %s (socket sock = %d)\n", strerror(errno), sock);
        return -1;
    }

    int flags;
    if (-1 == (flags = fcntl(fd, F_GETFL, 0))) {
            flags = 0;
    }
    fcntl(sock, F_SETFL, flags | O_NONBLOCK);

    char *path = "/data/data/com.github.shadowsocks/sock_path";
    if (options.sock_path != NULL) {
        path = options.sock_path;
    }
    unlink(path);
    memset(&addr, 0, sizeof(addr));
    addr.sun_family = AF_UNIX;
    strncpy(addr.sun_path, path, sizeof(addr.sun_path)-1);

    if (bind(sock, (struct sockaddr*)&addr, sizeof(addr)) == -1) {
        BLog(BLOG_ERROR, "bind() failed: %s (sock = %d)\n", strerror(errno), sock);
        close(sock);
        return -1;
    }

    if (listen(sock, 5) == -1) {
        BLog(BLOG_ERROR, "listen() failed: %s (sock = %d)\n", strerror(errno), sock);
        close(sock);
        return -1;
    }

    fd_set set;
    FD_ZERO (&set);
    FD_SET (sock, &set);

    struct timeval tv = {10, 0};

    for (;;) {
        if (select(sock + 1, &set, NULL, NULL, &tv) < 0) {
            BLog(BLOG_ERROR, "select() failed: %s\n", strerror(errno));
            break;
        }

        int sock2;
        struct sockaddr_un remote;
        int t = sizeof(remote);
        if ((sock2 = accept(sock, (struct sockaddr *)&remote, &t)) == -1) {
            BLog(BLOG_ERROR, "accept() failed: %s (sock = %d)\n", strerror(errno), sock);
            break;
        }

        if (ancil_recv_fd(sock2, &fd)) {
            BLog(BLOG_ERROR, "ancil_recv_fd: %s (sock = %d)\n", strerror(errno), sock2);
            close(sock2);
            break;
        } else {
            close(sock2);
            BLog(BLOG_INFO, "received fd = %d", fd);
            break;
        }
    }

    close(sock);

    return fd;
}
#endif

这一段做的事情就是创建了一个UNIX域socket，对应VpnService中的LocalSocket，通过ancil_recv_fd接收VpnService发送过来的tun fd。ancil_recv_fd方法是libancillary提供的，这个库的作用就是通过UNIX域socket跨进程传递fd，库的实现就不展开分析。这个方法最后返回了接收到的fd，这个fd如何使用，我们在tun2socks一节里分析。

ss-local -> VpnService

还有一个fd，是由ss-local发送给VpnService，同样是通过libancillary发送，实现如下：

int
protect_socket(int fd)
{
    int sock;
    struct sockaddr_un addr;

    if ((sock = socket(AF_UNIX, SOCK_STREAM, 0)) == -1) {
        LOGE("[android] socket() failed: %s (socket fd = %d)\n", strerror(errno), sock);
        return -1;
    }

    // Set timeout to 3s
    struct timeval tv;
    tv.tv_sec  = 3;
    tv.tv_usec = 0;
    setsockopt(sock, SOL_SOCKET, SO_RCVTIMEO, (char *)&tv, sizeof(struct timeval));
    setsockopt(sock, SOL_SOCKET, SO_SNDTIMEO, (char *)&tv, sizeof(struct timeval));

    memset(&addr, 0, sizeof(addr));
    addr.sun_family = AF_UNIX;
    strncpy(addr.sun_path, "protect_path", sizeof(addr.sun_path) - 1);

    if (connect(sock, (struct sockaddr *)&addr, sizeof(addr)) == -1) {
        LOGE("[android] connect() failed for protect_path: %s (socket fd = %d)\n",
             strerror(errno), sock);
        close(sock);
        return -1;
    }

    if (ancil_send_fd(sock, fd)) {
        ERROR("[android] ancil_send_fd");
        close(sock);
        return -1;
    }

    char ret = 0;

    if (recv(sock, &ret, 1, 0) == -1) {
        ERROR("[android] recv");
        close(sock);
        return -1;
    }

    close(sock);
    return ret;
}

查看调用发现在如下方法中。

static void
server_stream(EV_P_ ev_io *w, buffer_t *buf) {
    // ...
    #ifdef __ANDROID__
        if (vpn) {
            int not_protect = 0;
            if (remote->addr.ss_family == AF_INET) {
                struct sockaddr_in *s = (struct sockaddr_in *)&remote->addr;
                if (s->sin_addr.s_addr == inet_addr("127.0.0.1"))
                    not_protect = 1;
            }
            if (!not_protect) {
                if (protect_socket(remote->fd) == -1) {
                    ERROR("protect_socket");
                    close_and_free_remote(EV_A_ remote);
                    close_and_free_server(EV_A_ server);
                    return;
                }
            }
        }
    #endif
    // ...
}

这个方法太长，只贴了相关的一部分，这里涉及到shadowsocks基于libev实现的事件驱动，在ss-local一节会详细分析，这里我们只需要知道，通过libancillary发送给VpnService的，其实是ss-local和远程服务端建立连接的fd。我们看VpnService对fd的处理：

private inner class ProtectWorker : ConcurrentLocalSocketListener("ShadowsocksVpnThread",
        File(Core.deviceStorage.noBackupFilesDir, "protect_path")) {
    override fun acceptInternal(socket: LocalSocket) {
        socket.inputStream.read()
        val fd = socket.ancillaryFileDescriptors!!.single()!!
        CloseableFd(fd).use {
            socket.outputStream.write(if (underlyingNetwork.let { network ->
                        if (network != null && Build.VERSION.SDK_INT >= 23) try {
                            network.bindSocket(fd)
                            true
                        } catch (e: IOException) {
                            // suppress ENONET (Machine is not on the network)
                            if ((e.cause as? ErrnoException)?.errno != 64) printLog(e)
                            false
                        } else protect(getInt.invoke(fd) as Int)
                    }) 0 else 1)
        }
    }
}

上层通过LocalSocket接收了ss-local发过来的fd，并通过平台API给fd添加了例外，使得这个fd的数据读写不经过tun设备。

tun2socks实现

上一节说到，tun2socks在wait_for_fd方法中通过UNIX域socket获取到了fd，我们来看一下接下来对fd的处理。
首先是一堆初始化操作：

// initialize network
if (!BNetwork_GlobalInit()) {
    BLog(BLOG_ERROR, "BNetwork_GlobalInit failed");
    goto fail1;
}

// process arguments
if (!process_arguments()) {
    BLog(BLOG_ERROR, "Failed to process arguments");
    goto fail1;
}

// init time
BTime_Init();

// init reactor
if (!BReactor_Init(&ss)) {
    BLog(BLOG_ERROR, "BReactor_Init failed");
    goto fail1;
}

// set not quitting
quitting = 0;

// setup signal handler
if (!BSignal_Init(&ss, signal_handler, NULL)) {
    BLog(BLOG_ERROR, "BSignal_Init failed");
    goto fail2;
}

这一段里最关键的是BReactor_Init方法，它初始化了一个BReactor结构，我们看一下这个结构定义：

typedef struct {
    int exiting;
    int exit_code;
    
    // jobs
    BPendingGroup pending_jobs;
    
    // timers
    BReactor__TimersTree timers_tree;
    LinkedList1 timers_expired_list;
    
    // limits
    LinkedList1 active_limits_list;
    
    #ifdef BADVPN_USE_WINAPI
    LinkedList1 iocp_list;
    HANDLE iocp_handle;
    LinkedList1 iocp_ready_list;
    #endif
    
    #ifdef BADVPN_USE_EPOLL
    int efd; // epoll fd
    struct epoll_event epoll_results[BSYSTEM_MAX_RESULTS]; // epoll returned events buffer
    int epoll_results_num; // number of events in the array
    int epoll_results_pos; // number of events processed so far
    #endif
    
    #ifdef BADVPN_USE_KEVENT
    int kqueue_fd;
    struct kevent kevent_results[BSYSTEM_MAX_RESULTS];
    int kevent_prev_event[BSYSTEM_MAX_RESULTS];
    int kevent_results_num;
    int kevent_results_pos;
    #endif
    
    #ifdef BADVPN_USE_POLL
    LinkedList1 poll_enabled_fds_list;
    int poll_num_enabled_fds;
    int poll_results_num;
    int poll_results_pos;
    struct pollfd *poll_results_pollfds;
    BFileDescriptor **poll_results_bfds;
    #endif
    
    DebugObject d_obj;
    #ifndef BADVPN_USE_WINAPI
    DebugCounter d_fds_counter;
    #endif
    #ifdef BADVPN_USE_KEVENT
    DebugCounter d_kevent_ctr;
    #endif
    DebugCounter d_limits_ctr;
} BReactor;

BReactor其实是一个封装了各平台差异的结构，上层可以直接通过BReactor结构来实现事件驱动，而不用关心各平台底层的实现，无论是epoll，poll还是kevent。shadowsocks-android在编译的时候传入了BADVPN_USE_EPOLL，因此我们只要关心epoll相关的实现。
efd在BReactor_Init中被初始化，就是epoll_create返回的fd，这样就简单了，我们只需要看一下epoll_ctl的调用，看看哪些fd被挂到了epoll上，就能理清整体的逻辑。
epoll_ctl一共在三个方法被调用，三个方法分别是：

int BReactor_AddFileDescriptor (BReactor *bsys, BFileDescriptor *bs)
void BReactor_RemoveFileDescriptor (BReactor *bsys, BFileDescriptor *bs)
void BReactor_SetFileDescriptorEvents (BReactor *bsys, BFileDescriptor *bs, int events)

分别对应EPOLL_CTL_ADD，EPOLL_CTL_DEL和EPOLL_CTL_MOD操作。这里我们重点关注一下EPOLL_CTL_ADD，查一下BReactor_AddFileDescriptor的调用，每个BReactor_AddFileDescriptor都是和BFileDescriptor_Init成对出现的，BFileDescriptor_Init的实现：

void BFileDescriptor_Init (BFileDescriptor *bs, int fd, BFileDescriptor_handler handler, void *user)
{
    bs->fd = fd;
    bs->handler = handler;
    bs->user = user;
    bs->active = 0;
}

结合BFileDescriptor的定义：

/**
 * File descriptor object used with {@link BReactor}.
 */
typedef struct BFileDescriptor_t {
    int fd;
    BFileDescriptor_handler handler;
    void *user;
    int active;
    int waitEvents;
    
    #ifdef BADVPN_USE_EPOLL
    struct BFileDescriptor_t **epoll_returned_ptr;
    #endif
    
    #ifdef BADVPN_USE_KEVENT
    int kevent_tag;
    int kevent_last_event;
    #endif
    
    #ifdef BADVPN_USE_POLL
    LinkedList1Node poll_enabled_fds_list_node;
    int poll_returned_index;
    #endif
} BFileDescriptor;

不难看出，BFileDescriptor_Init把真正的fd和处理事件的callback绑定起来了，BFileDescriptor则是用于封装底层实现的结构体。所以只要找到各个fd对应的BFileDescriptor_handler实现，就能理清tun2socks的整体逻辑。

ss-local实现

libev

LocalDnsService实现

redsocks实现透明代理

UDP协议代理

加解密实现

gfwlist

郑重声明

本文所涉及到的所有内容仅用于技术学习研究，任何非法用途产生的后果自负，与本人无关

Android Proxy实现分析（未完待续）

曙晨

曙晨

序章

proxy原理

流量拦截

iptables实现

VpnService实现

分应用代理

shadowsocks-android源码分析

整体架构

VpnService实现

fd的传递

VpnService -> tun2socks

ss-local -> VpnService

tun2socks实现

ss-local实现

libev

LocalDnsService实现

redsocks实现透明代理

UDP协议代理

加解密实现

gfwlist

郑重声明

海南之行