ss-libev 源码解析local篇(3): server_r
上一篇看到STAGE_HANDSHAKE中的处理，到发出fake reply。这之后会从socks5 request中解析出remote addr and port，即客户端实际想要访问的服务器地址和端口。根据request->atyp，有三种情况，atyp为1，请求中带的是ipv4的地址，为3是域名，为4是ipv6地址。ss-local会把remote addr & port填入server->abuf中，可以认为abuf中是要发送到ss-server的内容。
buffer_t *abuf = server->abuf;
abuf->idx = 0;
abuf->len = 0;
abuf->data[abuf->len++] = request->atyp;
abuf第一个字节，填入地址类型，即atyp，1，3 or 4。之后会根据地址类型填入地址和端口号，以ipv4为例：
if (atyp == 1) {
// IP V4
size_t in_addr_len = sizeof(struct in_addr);
if (buf->len < request_len + in_addr_len + 2) {
return;
}
memcpy(abuf->data + abuf->len, buf->data + 4, in_addr_len + 2);
abuf->len += in_addr_len + 2;
}
此时的buf是server->buf，因为正在处理socks5 request，buf中自带了地址和端口，所以这儿是直接从buf拷贝到abuf。buf->data+4是因为要跳过请求的前4个字节，从第5字节开始是地址和端口。域名和ipv6的情况也类似，可以认为此时的abuf就是buf的第4字节开始的内容。之所以要分开处理，是因为还要解析出host, ip,端口给acl使用。
在这之后，会进入sni阶段。
SNI: 从http/https中探测出要访问的域名
size_t abuf_len = abuf->len;
int sni_detected = 0;
if (atyp == 1 || atyp == 4) {
char *hostname = NULL;
uint16_t p = ntohs(*(uint16_t *)(abuf->data + abuf->len - 2));
int ret = 0;
if (p == http_protocol->default_port)
ret = http_protocol->parse_packet(buf->data + 3 + abuf->len,
buf->len - 3 - abuf->len, &hostname);
else if (p == tls_protocol->default_port)
ret = tls_protocol->parse_packet(buf->data + 3 + abuf->len,
buf->len - 3 - abuf->len, &hostname);
if (ret == -1 && buf->len < BUF_SIZE) {
server->stage = STAGE_PARSE;
return;
} else if (ret > 0) {
sni_detected = 1;
// Reconstruct address buffer
abuf->len = 0;
abuf->data[abuf->len++] = 3;
abuf->data[abuf->len++] = ret;
memcpy(abuf->data + abuf->len, hostname, ret);
abuf->len += ret;
p = htons(p);
memcpy(abuf->data + abuf->len, &p, 2);
abuf->len += 2;
if (acl || verbose || logDetail) {
memcpy(host, hostname, ret);
host[ret] = '\0';
//wh
if(logDetail){
if(server->dest_host!=NULL){
ss_free(server->dest_host);
}
server->dest_host = (char*)malloc(sizeof(host));
memcpy(server->dest_host, host, sizeof(host));
if(verbose){
LOGI("reset host by parse [%s:%s]",server->dest_host,server->dest_port);
}
}
//wh
}
ss_free(hostname);
}
}
这一段代码的主要目的是从http头或https的tls握手中解析出http/https请求要访问的域名。首先，浏览器访问url时，会先调用系统的dns解析将域名解析为ip地址，所以socks5客户端收到的就是包含ip地址的请求，当然也可能还有包含域名的请求，比如在socks5之前又使用了一个http代理。在某些网络环境中，系统解析出来的ip地址可能是不正确的，比如被dns劫持了等，ss-local在这儿会去分析http的头或者https的tls握手内容，分析出hostname，然后修改abuf，将原本是ip地址类型的abuf，修改为域名类型的abuf，这样socks5服务器将会去解析这个域名，从而避免DNS污染。下面具体分析这段代码。
首先，只对atyp为1或4，即ip地址的情况进行处理，开始先从abuf中解析出端口号，如果端口号为80或443则分别进行http/https的探测。探测的内容为，buf中buf->data + 3 + abuf->len开始的位置，长度为buf->len - 3 - abuf->len。回忆一下buf的结构，前4个字节加上后面的地址和端口，buf->data+3的位置是atyp，而abuf是相当于buf中从atyp往后的内容，所以buf->data + 3 + abuf->len相当于buf中整个socks5请求消息体的后面。而长度buf->len - 3 - abuf->len相当于buf中刨去socks5请求体剩余内容的长度。这是什么意思呢？我们一路看过来，此时是客户端给ss-local发送一个socks5请求，并没有其他内容，那解析的是啥？别急继续看。首先我们看下parse_packet的返回值，大于0表示解析出的hostname的长度，-1表示Incomplete request即要分析的内容是不完整的。那么一开始就只能返回-1，因为此时消息体后啥都没有。而ret返回-1的结果就是server->stage进入STAGE_PARSE状态并从server_recv_cb函数返回，等待下一次server_recv_cb的调用。
STAGE_PARSE：数据再次读入和分析
server进入STAGE_PARSE后，因为之前已经发送了fake reply，此时客户端会认为已经可以发送实际要代理的数据了，对于http会发送http消息体，其中最开始的是http头，对于https会先进行tls握手。而根据recv的代码，新来的数据总是添加到当前buf内容的最后，即buf->data+buf->len，回忆一下：
r = recv(server->fd, buf->data + buf->len, BUF_SIZE - buf->len, 0);
因为之前的步骤并没有清除buf，此时buf中是SOCKS5 request的内容，即4字节+地址端口。新来的数据就被添加到这个request之后。而上一篇我们看到，处理STAGE_PARSE和处理STAGE_HANDSHAKE是同一段代码：
else if (server->stage == STAGE_HANDSHAKE || server->stage == STAGE_PARSE)
也就是说，在STAGE_PARSE状态，我们会重新分析一遍整个buf，(当然不会再发送fake reply,因为已有状态区分），然后代码继续走到SNI的部分，此时parse_packet就有可能返回一个大于0的数了，表示解析出了hostname，如果读入的内容还是不够，则继续ret==-1的退出当前函数，等待更多数据的到来。其实ret除了大于0或-1，还有其他值，ss-local这儿没有具体处理，只是在ret为-1时还检查了一下buf->len:
if (ret == -1 && buf->len < BUF_SIZE) {
server->stage = STAGE_PARSE;
return;
}
即如果buf->len大于BUF_SIZE则不会继续进入STAGE_PARSE了，而是跳过SNI部分，进入正式的STAGE_STREAM状态。这是为了防止一直解析不出hostname。毕竟ss-local只是根据端口号就去探测，没准探测的数据并不是http/s的，这种情况parse_packet会返回表示其他错误的ret，ss-local采取这种方法统一处理了各种不成功的可能，总之就是我解析到BUF_SIZE为止，如果还不行就放弃SNI。另外这儿判断小于BUF_SIZE也因为buf的大小就是BUF_SIZE，不能超过。
当然后ret为大于0的数时，表示SNI成功，探测到hostname。此时ss-local就会重建abuf的内容：
// Reconstruct address buffer
abuf->len = 0;
abuf->data[abuf->len++] = 3;
abuf->data[abuf->len++] = ret;
memcpy(abuf->data + abuf->len, hostname, ret);
abuf->len += ret;
p = htons(p);
memcpy(abuf->data + abuf->len, &p, 2);
abuf->len += 2;
abuf第一个字节填3表示是域名，第二个字节填ret，因为ret就是hostname的长度，之后填入hostname，之后填入端口号。
SNI完成或者放弃后，代码继续：
server->stage = STAGE_STREAM;
buf->len -= (3 + abuf_len);
if (buf->len > 0) {
memmove(buf->data, buf->data + 3 + abuf_len, buf->len);
}
首先将状态设置为STAGE_STREAM表示要转发实际的数据了。buf->len -= (3 + abuf_len);实际就是将buf中的SOCKS5 request消息清除，如果buf->len>0，表示除了request还有其他内容，比如SNI成功的情况，这个其他内容就是http头或者tls握手，需要保留这些内容，因为通过memmove移动到buf头部。这儿3 + abuf_len就相当于request的长度。
下面是acl的部分，这部分简单说下吧。acl其实就是白名单了，白名单里面的域名ip不通过ss代理，而是直接发送到目的服务器，这儿的处理是生成一个remote：
remote = create_remote(server->listener, (struct sockaddr *)&storage);
if (remote != NULL)
remote->direct = 1;
storage的地址是目的服务器的地址，所以说这种情况remote就不对应ss-server了，而是直接对应目的服务器，remote->direct = 1表示这个remote是直连的，会和ss-server的代理有区别。
继续往下，如果acl没符合，则就建立一个到远端ss-server的remote。
// Not match ACL
if (remote == NULL) {
remote = create_remote(server->listener, NULL);
}
这个server->listener就是启动ss-local时创建的那个全局唯一的listen_ctx_t对象，create_remote里面会用到listener里面存储的remote_addr即ss-server服务器地址来创建到ss-server的socket连接，对于create_remote和里面调用的new_remote在分析remote时再说吧。这儿就知道创建了一个到ss-server的remote对象就可以了。继续，
if (!remote->direct) {
int err = crypto->encrypt(abuf, server->e_ctx, BUF_SIZE);
这是将abuf进行加密。继续，
if (buf->len > 0) {
memcpy(remote->buf->data, buf->data, buf->len);
remote->buf->len = buf->len;
}
server->remote = remote;
remote->server = server;
如果buf去掉request之后还有内容（见上面），则把这些数据拷贝到remote的buf中，至于为什么这么做，回忆之前的代码，server_recv_cb一开始读取数据的时候，如果有remote存在，则读取到remote的buf中，因为这儿已经创建了remote，下一次再读取就使用remote的buf，所以先将这部分待处理的数据放到remote的buf中。然后是将server和remote互相关联起来，方便以后使用。
整个handshake & parse的过程就结束了，在退出server_recv_cb之前，ss-local还启动了一个timer:
ev_timer_start(EV_A_ & server->delayed_connect_watcher);
这个timer是做啥用的呢？刚刚说过，如果buf中有内容就copy到remote的buf中等待下一次处理，但是如果没有下一次了呢？如果buf中的内容就是本次tcp转发的所有数据了，server_recv_cb下一次被调用就是客户端主动close了，这样就会在recv到0之后直接关闭连接，这样remote buf中的数据就全丢失了。。于是乎，ss-local在本次退出server_recv_cb时启动了这个timer，这个timer是在new_server中建立的：
ev_timer_init(&server->delayed_connect_watcher,
delayed_connect_cb, 0.05, 0);
0.05秒后会调用delayed_connect_cb：
static void
delayed_connect_cb(EV_P_ ev_timer *watcher, int revents)
{
server_t *server = cork_container_of(watcher, server_t,
delayed_connect_watcher);
server->stage = STAGE_WAIT;
server_recv_cb(EV_A_ & server->recv_ctx->io, revents);
}
很简单，将server设置为wait状态，然后立刻主动调用server_recv_cb。这样回到server_recv_cb一开始的地方：
if (server->stage != STAGE_WAIT) {
r = recv(server->fd, buf->data + buf->len, BUF_SIZE - buf->len, 0);
.....
} else {
server->stage = STAGE_STREAM;
}
不读取数据，直接进入STAGE_STREAM去处理已有的数据。
这儿有个小问题，通过timer调用server_recv_cb时，如果io有数据可读也要调用server_recv_cb怎么办？我猜测libev是单线程的，所以会等一个事件处理完毕再发送另一个事件，否则这儿会有问题的。
下一篇具体分析STAGE_STREAM的过程。
