代理网关设计与实现(基于NETTY)
简介:本文重点在代理网关本身的设计与实现,而非代理资源的管理与维护。
作者 | 新然
来源 | 阿里技术公众号
一 问题背景
- 平台端购置一批裸代理,来做广告异地展现审核。从外部购置的代理,使用方式为:
- 通过给定的HTTP 的 API 提取代理 IP:PORT,返回的结果会给出代理的有效时长 3~5 分钟,以及代理所属地域;
从提取的代理中,选取指定地域,添加认证信息,请求获取结果;
本文设计实现一个通过的代理网关:
- 管理维护代理资源,并做代理的认证鉴权;
- 对外暴露统一的代理入口,而非动态变化的代理IP:PORT;
- 流量过滤及限流,比如:静态资源不走代理;
本文重点在代理网关本身的设计与实现,而非代理资源的管理与维护。
注:本文包含大量可执行的JAVA代码以解释代理相关的原理
二 技术路线
本文的技术路线。在实现代理网关之前,首先介绍下代理相关的原理及如何实现
- 透明代理;
- 非透明代理;
- 透明的上游代理;
- 非透明的上游代理;
最后,本文要构建代理网关,本质上就是一个非透明的上游代理,并给出详细的设计与实现。
1 透明代理
透明代理是代理网关的基础,本文采用JAVA原生的NIO进行详细介绍。在实现代理网关时,实际使用的为NETTY框架。原生NIO的实现对理解NETTY的实现有帮助。
透明代理设计三个交互方,客户端、代理服务、服务端,其原理是:
- 代理服务在收到连接请求时,判定:如果是CONNECT请求,需要回应代理连接成功消息到客户端;
- CONNECT请求回应结束后,代理服务需要连接到CONNECT指定的远程服务器,然后直接转发客户端和远程服务通信;
- 代理服务在收到非CONNECT请求时,需要解析出请求的远程服务器,然后直接转发客户端和远程服务通信;
需要注意的点是:
- 通常HTTPS请求,在通过代理前,会发送CONNECT请求;连接成功后,会在信道上进行加密通信的握手协议;因此连接远程的时机是在CONNECT请求收到时,因为此后是加密数据;
- 透明代理在收到CONNECT请求时,不需要传递到远程服务(远程服务不识别此请求);
- 透明代理在收到非CONNECT请求时,要无条件转发;
完整的透明代理的实现不到约300行代码,完整摘录如下:
以上,借鉴NETTY:
- 首先初始化REACTOR线程,然后开启代理监听,当收到代理请求时处理。
- 代理服务在收到代理请求时,首先做代理的预处理,然后又SocketPipe做客户端和远程服务端双向转发。
- 代理预处理,首先读取第一个HTTP请求,解析出METHOD, HOST, PORT。
- 如果是CONNECT请求,发送回应Connection Established,然后连接远程服务端,并返回SocketChannel
- 如果是非CONNECT请求,连接远程服务端,写入原始请求,并返回SocketChannel
- SocketPipe在客户端和远程服务端,做双向的转发;其本身是将客户端和服务端的SocketChannel注册到REACTOR
- REACTOR在监测到READABLE的CHANNEL,派发给SocketPipe做双向转发。
测试
代理的测试比较简单,指向代码后,代理服务监听8006端口,此时:
curl -x 'localhost:8006'
curl -x 'localhost:8006'
注意,此时代理服务代理了HTTPS请求,但是并不需要-k选项,指示非安全的代理。因为代理服务本身并没有作为一个中间人,并没有解析出客户端和远程服务端通信的内容。在非透明代理时,需要解决这个问题。
2 非透明代理
非透明代理,需要解析出客户端和远程服务端传输的内容,并做相应的处理。
当传输为HTTP协议时,SocketPipe传输的数据即为明文的数据,可以拦截后直接做处理。
当传输为HTTPS协议时,SocketPipe传输的有效数据为加密数据,并不能透明处理。
另外,无论是传输的HTTP协议还是HTTPS协议,SocketPipe读到的都为非完整的数据,需要做聚批的处理。
- SocketPipe聚批问题,可以采用类似BufferedInputStream对InputStream做Decorate的模式来实现,相对比较简单;详细可以参考NETTY的HttpObjectAggregator;
- HTTPS原始请求和结果数据的加密和解密的处理,需要实现的NIO的SOCKET CHANNEL;
SslSocketChannel封装原理
考虑到目前JDK自带的NIO的SocketChannel并不支持SSL;已有的SSLSocket是阻塞的OIO。如图:
- 每次入站数据和出站数据都需要 SSL SESSION 做握手;
- 入站数据做解密,出站数据做加密;
- 握手,数据加密和数据解密是统一的一套状态机;
- 基于 SSL 协议,实现统一的握手动作;
- 分别实现读取的解密,和写入的加密方法;
- 将 SslSocketChannel 实现为 SocketChannel的Decorator;
SslSocketChannel测试服务端
基于以上封装,简单测试服务端如下
- 由于是NIO,简单的测试需要用到NIO的基础组件Selector进行测试;
- 首先初始化ServerSocketChannel,监听8006端口;
- 接收到请求后,将SocketChannel封装为SslSocketChannel,注册到Selector
- 接收到数据后,通过SslSocketChannel做read和write;
SslSocketChannel测试客户端
基于以上服务端封装,简单测试客户端如下
以上:
- 客户端的封装测试,是为了验证封装 SSL 协议双向都是OK的,
- 在后文的非透明上游代理中,会同时使用 SslSocketChannel做服务端和客户端
- 以上封装与服务端封装类似,不同的是初始化 SocketChannel,做connect而非bind
总结
以上:
- 非透明代理需要拿到完整的请求数据,可以通过 Decorator模式,聚批实现;
- 非透明代理需要拿到解密后的HTTPS请求数据,可以通过SslSocketChannel对原始的SocketChannel做封装实现;
- 最后,拿到请求后,做相应的处理,最终实现非透明的代理。
3 透明上游代理
透明上游代理相比透明代理要简单,区别是
- 透明代理需要响应 CONNECT请求,透明上游代理不需要,直接转发即可;
- 透明代理需要解析CONNECT请求中的HOST和PORT,并连接服务端;透明上游代理只需要连接下游代理的IP:PORT,直接转发请求即可;
- 透明的上游代理,只是一个简单的SocketChannel管道;确定下游的代理服务端,连接转发请求;
只需要对透明代理做以上简单的修改,即可实现透明的上游代理。
4 非透明上游代理
非透明的上游代理,相比非透明的代理要复杂一些
- 如果是HTTP的请求,数据直接通过 客户端<->ServerHandler<->ClientHandler<->服务端,代理网关只需要做简单的请求聚批,就可以应用相应的管理策略;
- 如果是HTTPS请求,代理作为客户端和服务端的中间人,只能拿到加密的数据;因此,代理网关需要作为HTTPS的服务方与客户端通信;然后作为HTTPS的客户端与服务端通信;
- 代理作为HTTPS服务方时,需要考虑到其本身是个非透明的代理,需要实现非透明代理相关的协议;
- 代理作为HTTPS客户端时,需要考虑到其下游是个透明的代理,真正的服务方是客户端请求的服务方;
三 设计与实现
本文需要构建的是非透明上游代理,以下采用NETTY框架给出详细的设计实现。上文将统一代理网关分为两大部分,ServerHandler和ClientHandler,以下
- 介绍代理网关服务端相关实现;
- 介绍代理网关客户端相关实现;
1 代理网关服务端
主要包括
- 初始化代理网关服务端
- 初始化服务端处理器
- 服务端协议升级与处理
初始化代理网关服务
代理网关初始化相对简单,
- bossGroup线程组,负责接收请求
- workerGroup线程组,负责处理接收的请求数据,具体处理逻辑封装在ServerChannelInitializer中。
代理网关服务的请求处理器在 ServerChannelInitializer中定义为
首先解析HTTP请求,然后做聚批的处理,最后ServerChannelHandler实现代理网关协议;
代理网关协议:
- 判定是否是CONNECT请求,如果是,会存储CONNECT请求;暂停读取,发送代理成功的响应,并在回应成功后,升级协议;
- 升级引擎,本质上是采用SslSocketChannel对原SocketChannel做透明的封装;
- 最后根据CONNECT请求连接远程服务端;
详细实现为:
代理网关服务端需要连接远程服务,进入代理网关客户端部分。
代理网关客户端初始化:
以上:
- 复用代理网关服务端的workerGroup线程组;
- 请求和结果的处理封装在ClientChannelInitializer;
- 连接的远程服务端的HOST和PORT在服务端收到的请求中可以解析到。
代理网关客户端的处理器的初始化逻辑:
以上:
- 如果下游是代理,那么会采用HttpProxyHandler,经由下游代理与远程服务端通信;
- 如果当前需要升级为SSL协议,会对SocketChannel做透明的封装,实现SSL通信。
- 最后,ClientChannelHandler只是简单消息的转发;唯一的不同是,由于代理网关拦截了第一个请求,此时需要将拦截的请求,转发到服务端。
四 其他问题
代理网关实现可能面临的问题:
1 内存问题
代理通常面临的问题是OOM。本文在实现代理网关时保证内存中缓存时当前正在处理的HTTP/HTTPS请求体。内存使用的上限理论上为实时处理的请求数量*请求体的平均大小,HTTP/HTTPS的请求结果,直接使用堆外内存,零拷贝转发。
2 性能问题
性能问题不应提早考虑。本文使用NETTY框架实现的代理网关,内部大量使用堆外内存,零拷贝转发,避免了性能问题。
代理网关一期上线后曾面临一个长连接导致的性能问题,
- CLIENT和SERVER建立TCP长连接后(比如,TCP心跳检测),通常要么是CLIENT关闭TCP连接,或者是SERVER关闭;
- 如果双方长时间占用TCP连接资源而不关闭,就会导致SOCKET资源泄漏;现象是:CPU资源爆满,处理空闲连接;新连接无法建立;
使用IdleStateHandler定时监控空闲的TCP连接,强制关闭;解决了该问题。
五 总结
本文聚焦于统一代理网关的核心,详细介绍了代理相关的技术原理。
代理网关的管理部分,可以在ServerHandler部分维护,也可以在ClientHandler部分维护;
- ServerHandler可以拦截转换请求
- ClientHanlder可控制请求的出口
注:本文使用Netty的零拷贝;存储请求以解析处理;但并未实现对RESPONSE的处理;也就是RESPONSE是直接通过网关,此方面避免了常见的代理实现,内存泄漏OOM相关问题;
最后,本文实现代理网关后,针对代理的资源和流经代理网关的请求做了相应的控制,主要包括:
- 当遇到静态资源的请求时,代理网关会直接请求远程服务端,不会通过下游代理
- 当请求HEADER中包含地域标识时,代理网关会尽力保证请求打入指定的地域代理,经由地域代理访问远程服务端
原文链接
本文为阿里云原创内容,未经允许不得转载。
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· AI与.NET技术实操系列(二):开始使用ML.NET
· 记一次.NET内存居高不下排查解决与启示
· 探究高空视频全景AR技术的实现原理
· 理解Rust引用及其生命周期标识(上)
· 浏览器原生「磁吸」效果!Anchor Positioning 锚点定位神器解析
· DeepSeek 开源周回顾「GitHub 热点速览」
· 物流快递公司核心技术能力-地址解析分单基础技术分享
· .NET 10首个预览版发布:重大改进与新特性概览!
· AI与.NET技术实操系列(二):开始使用ML.NET
· 单线程的Redis速度为什么快?
2020-11-26 深度解读 MongoDB 最全面的增强版本 4.4 新特性
2019-11-26 阿里云基于OSS的云上统一数据保护方案2.0正式发布
2018-11-26 阿里工业互联网平台“思考”:一场从0到1的蜕变
2018-11-26 关于Flutter初始化流程,我必须告诉你的是...
2018-11-26 用深度学习预测专业棋手走法
2018-11-26 阿里AI设计师一秒出图,小撒连连惊呼,真相是...
2018-11-26 想成为数据科学家?先做到这6点吧!