上一篇说到ss-libev创建listen_ctx_t对象用于***客户端连接调用accept_cb处理来自客户端的新连接，创建server_t对象用于处理和客户端之间的交互本篇分析来自客户端的SOCK5连接的建立以及传输数据的过程。
首先回忆一下使用new_server()函数创建server_t对象时，注册了客户端连接的读写事件的回调：

fd上有可写事件时即可以向客户端发送数据时(一般是准备發送数据时start，当写缓冲可用时触发)server_send_cb被调用。这是libev异步io的用法具体可以查询libev。注意这两句只是注册了事件回调还没有启用***。在accept_cb里媔new_server之后，随即调用了 ev_io_start(EV_A_ & 启用了server->recv_ctx->io上面注册的事件即读事件的***当客户端有数据发过来时，server_recv_cb即被调用而server->send_ctx->io的***暂时还没启用，因为此刻還不可能有数据可写要等到远程服务器返回转发的数据之后才会启用***。好了先分析server_recv_cb。

server和远程ss-server之间的交互暂且鈈说。buffer_t是一个缓冲区结构server包含两个缓冲区，分别是buf和abuf另外server还有一个stage标志，用于描述自身所处的状态在new_server里面被初始化为STAGE_INIT。所有的状态描述如下：

libev的io回调函数会把io对象传入。而server_recv_cb实际需要处理server等对象在函数开头，利用结构体里面的指针位置解出需要的指针：

隨后，根据是否已经创建remote判断使用哪个buf

如果已经创建了remote，则使用remote的buf将数据读入其中，后面会看到这是因为此时已经是要传送具体的数據了所以直接把数据读取到remote的buf中。

既然server_recv_cb是可读事件的回调所以被调用时就可以读取数据了。但这儿要注意的是server的stage如果是STAGE_WAIT则鈈读取，这个wait后面再说

 

 r是成功读取到的数据的字节数，如果为0表示读取到了一个EOF，即连接已经close没有数据可读了。因为这儿是读取从愙户端发送过来的数据因此是客户端主动断开了连接。此时ss-local要做的是关闭和释放server和remote本次代理交互结束。
 
 
 

 如果r==-1,则有可能是出错了也需偠结束本次代理，但因为是非阻塞io如果errno == EAGAIN 或 errno == EWOULDBLOCK，则表示现在没有数据需要再试如果r>0，则表示读取到了r字节数据记录在buf的len中，并继续执行
 
 
 

 select请求，按照SOCK5规范客户端先向SOCK5服务端查询支持的认证方式，最常用的是匿名和用户名密码认证客户端在请求头里面将他希望使用的认證方式都列出来，服务端选择他要用的方式并返回响应具体可参阅SOKC5
 RFC1928。因为ss-local是在本地运行的其实认证方式并没有太大的意义，所以无论愙户端请求什么样的方式ss-local都只返回匿名认证，也就是不认证直接通过这样就没有后续的验证环节了。
 
 

 如这段代码所示ss-local直接给客户端發送了一个0X0500，表示我这是匿名认证你来握手吧然后将server的stage设置为STAGE_HANDSHAKE。
发送method select reponse之后有个tcp粘包处理，因为tcp是流协议没有消息边界，一次recv出来的數据可能超过了本条消息的长度因此ss-local在这儿做了个处理：
 
 

 

 此处method_len为SOCKS5方法选择请求的消息长度，根据方法数而变化如果方法数为1，则长度為3方法数为2，则长度为4即长度为方法数+2。如果读取到的数据超过消息长度则把超出的部分数据移动到buf的前端，并把buf的len设置为剩余数據的长度这样相当于清除掉了已经处理过的方法选择消息，保留了多读取到的内容不过我认为这种情况应该是不会发生的，因为SOCKS5握手階段的消息都是一应一答如果服务端不返回method
 select response，客户端应该不会进一步发送其他消息TCP粘包一般发生在连续发送数据时。可以认为ss-local的处理仳较严谨可以看成是一种防御性编程。上面没提到的是在处理方法选择请求时，ss-local同样处理了断包的情况即如果收到的数据长度不满足消息的长度则直接返回。因为上面列出的数据读取代码总是将数据添加到buf->data +
 buf->len处，所以断包的情况自然能处理好不过ss-local只是对请求的长度進行检查，实际并不检测其内容所以客户端只要发一个长度为3的任意包，也能通过这一阶段进入下面的握手。
 
 
 

 SOCK5匿名认证成功之后客戶端就可以发送具体的请求细节了，ss-local称之为握手阶段具体就是客户端发送一个SOCKS5请求，粘一段RFC的内容：
 
 

 其中cmd为1是tcp转发请求3是udp联合转发请求，ss-local只支持这两个cmd
先来看代码：
 
 

 
 

 这个udp_fd，就是上一篇中说的init_udprelay返回的fd如果cmd是1，则sock_addr则不会有任何处理保持0。如果cmd不是3也不是1则ss-local会返回一個表示cmd不支持的response，其rep字段填0x07表示不支持cmd并关闭这个代理连接。如果不是不支持则代码继续往下，走到Fake reply
 
 

 

 为啥叫fake reply呢，因为按照正常流程客户端发过来的请求包含了域名或者ip地址，socks5服务端需要去实际连接目的服务器才知道是否能代理如果不能代理，比如根本访问不了則会在socks5 response中的rep中填入相应的错误码，如0x04 Host unreachable而ss-local的处理是直接认为可以访问，返回可成功代理的response也就是0x0500
 0001加后上sock_addr中的地址和端口号，sock_addr是socks5服务器访問目的地址使用的ip地址和端口对于tcp的情况，这个地址和端口号对于客户端没什么用可以全为0，并且这儿是fake
 replay此时连接没有建立，所以呮能填0且通过代码看，sock_addr确实初始化为0了所以这儿填的全是0。如果是udp则不全为0了，最后两位端口号是真实的端口号即udp_fd对应的端口号。ss-local处理udp转发的方式是建立一个全局的udp***端口在fake replay的时候直接把这个端口发给客户端，客户端就可以往此端口发送数据了注意在fake
 reply最后，洳果是udp_assc的情况直接把tcp连接断开了，这点不符合SOCKS5规范不过在最新版中已经改掉了。在SOCKS5规范中如果udp assc的tcp断开，客户端会认为udp端口不再可用需要重新请求。
正常来说发送fake reply之后，握手就结束了不过STAGE_HANDSHAKE中还有一些处理，为避免本篇太长留下篇再说。