socks5服务器编写经验总结

一、Socks5服务器实现设计

本Socks5服务器是之前做的一个项目中的一个小部分东西,该项目是一个可以实现多级转发代理网络通讯的项目,能够隐藏网络数据包的源IP地址和端口,能够为上网的用户提供安全保障,使得那些不怀好意的人无法追踪到数据包的源头,这里面由于涉及到商业方面的东西,所以只能把Socks5服务器抽离出来给说说。所谓Socks5协议,它是一种代理通讯协议,由于其直接转发数据的形式,所以它可以支持很多种协议。在我的实现中使用的是Proxifier作为客户端发起者,将客户端所有的网络协议均转为Socks5代理协议与我的服务器通讯。

在我的Socks5服务器中,大概的设计方案如下:

1. 使用一个线程来监听1080(一般默认的代理端口)端口,该线程接收对1080端口的所有TCP连接,并会验证其身份和合法性,验证结束之后继续监听1080端口。(这里其实可以把该线程的功能更加简短化,只做监听和接收连接的功能,然后将接收到的连接交给后续的工作线程处理。)

2. 当有一个连接到来并且验证成功之后,将会启动一个工作线程,将连接交给工作线程进行后续工作,既Socks5协议中协商目标机的部分了,此时客户端会将想要访问的目标IP和地址按照Socks5协议的格式发送给我,我会为其连接好服务器之后,将我这边使用的IP和端口按照Socks5协议规定的格式返回给客户端,这个时候一旦将返回包send给客户端之后就标志着Socks5协议的交互阶段结束,正式进入通讯阶段,工作线程会等待着第3步里面的通讯线程全部结束之后将资源回收。

3. 此时我会启动四个通讯线程,分别负责客户端<--->Socks5服务器,Socks5服务器<--->目标服务器总共四条通讯线路,这样做的好处是四条线路的线程代码完全一样,都是先收数据,然后发送出去,只是设置的收发的套接字不一样。当遇到接收或者发送失败的时候说明连接已经断开,则跳出线程里的循环,最终挂起的工作线程会继续进行,将通讯线程运行之后使用的资源给完全回收。

4. 最初做的时候没有加入线程池的概念,之后会加入线程池的概念来重新支持服务器中的线程的使用和回收,如果一直开启线程关闭线程,遇到大量连接的时候,效率会变得低下。

后面的内容因为一些原因暂时隐藏一下

上一篇:sass相关随笔


下一篇:Module build failed: TypeError: this.getResolve is not a function at Object.loader 使用vue-cli 创建项目 使用sass时报错 -- 等其他sass 报错 ./node_modules/css-loader?{"sourceMap":true}!./node_modules/vue-loader/lib