SOCKS5
# SOCKS5
# SOCKS5 效果
相比http代理更稳定，速度更快。
# SOCKS5 原理
# SOCKS5
基础理论: 浅谈云函数的利用面 (opens new window)
在云函数(FC)的限制下，大佬提出了一种通过vps建立起socks5隧道的模式，从模式上来看，更像是一种反向连接。
但是这种模式，需要一台VPS。对于穷逼的脚本小子的我，实在是不够优雅。
FC的不成熟的确限制了大部分的玩法，比如触发器种类，比如协议，比如端口限制等等。
在这种大环境下，我们无力去变更云函数的生态(其实也有可能云函数并没有为我们这种使用方式进行设计)，只能自寻出路。
想要优雅的正向连接，只能在HTTP上做文章。
突然联想到早些年，做安全服务时拿到了WebShell后如何进行内网渗透？这就想起了一个利器工具，也是我们今天的主角：
这个工具提供了各种语言的脚本，能够通过HTTP隧道的方式，结合本地客户端，建立socks连接代理。
他的原理其实是依赖于，socks属于一种建立在TCP层的接口，是对TCP/IP协议的封装，而在应用层的HTTP协议也是同样属于对TCP/IP协议的封装。
通俗来说，socks就是爸爸，而HTTP只是他众多的接口调用实现方而已，相互之间的转化是存在某种方式的。
举个例子，如python中的urllib库，底层就是使用sockets实现的HTTP。
因此，我们云函数socks代理的模型就可以画出来了:
用户 -> socks -> client -> 转化为HTTP -> FC云函数 -> 解析HTTP -> 发送socks
用户 <- 转化为socks <- client <- 转化为HTTP <- FC云函数 <- socks数据
我们的client开启一个socks的监听，然后将监听到的数据转化为http请求发给fc处理， fc根据http提供的数据发起socks连接，获取数据。之后fc函数再将数据通过http 返回byte字节码，client端接收到响应，再根据协议降级为socks。
理论存在，实践开始。 根据原理分析，我们要做的事情就比较明显了：
- 在云函数部署好一个接受HTTP响应，并转化为socks连接的服务
- 在本地启动client端，监听一个socks端口，将该端口的数据按照协议转化为HTTP请求发送给云函数
参考reGeorg (opens new window) 和他的的重构版Neo-reGeorg (opens new window), 复制了一个GO版本的客户端和服务端。
也就是说，你也可以选择连接 reGeorg 的shell作为http代理，启动一个本地的socks连接。
以PHP为例，reGeorg将状态、IO全部存储在了session内。
我们的云函数是没有状态的，所以不能够通过这种断开连接的方式再重新找到状态进行读取，要重新寻找出路。
经过一周的改写，我发现虽然思路可行，但是reGeorg的项目实在太老了，而重构版Neo-reGeorg又因为各种加密等原因离谱的乱，导致最终socks建立起的连接无法再次read的相应的socks。
终于在苦找下，发现了大佬做了这样的事情：将客户端socks5升级至http/https/websocket等应用层协议，同时还提供了UDP的解决方案！
但是测试发现，http触发器存在最大连接超时时间，虽然阿里云已经把这个数值调整到了24小时，依旧存在隐患，不够完美。
于是，替换者websockets触发器完美出现，解决了所有的问题。
因为本身websockets就是一种类sockets的http连接，现在我们只要通过 io.copy 将双端的输入输出绑定，即可构成通信信道。
最后就是处理好断开连接问题，来防止异常断开导致的panic，和节约云函数计费成本。
最终达成上图效果。