大二学生眼中的Netty？基于Netty实现内网穿透！

CodeCodeBond

已于 2024-06-22 12:14:06 修改

阅读量777

点赞数 18

分类专栏： Netty开发文章标签：网络编程 Netty 内网穿透 Java

于 2024-06-22 01:33:30 首次发布

本文链接：https://blog.csdn.net/2201_75299492/article/details/139872646

版权

Netty开发专栏收录该内容

1 篇文章 0 订阅

订阅专栏

爷的开场白

CSDN的朋友们大家好！我是新来的Java练习生 CodeCodeBond！

这段时间呢，博主在学习Netty，想做一个自己感兴趣好玩的东西，那就是内网穿透！！（已经实现主要代理功能但有待优化）

后面会介绍到我个人的一些思路（能把学校内网的电控系统穿出来玩玩嘿嘿嘿

老实求放过说明：博主对Netty底层知识仅仅是了解一下皮毛，哈哈哈精巧的框架让像我这种黄毛小子短时间熟悉精通确实不是那么容易的，需要时间的沉淀（#沉淀 orz）

什么！连Netty的底层知识都不懂！居然还会用Netty做开发网络编程？？？我想这也是框架的意义所在吧！将复杂繁琐的底层封装成简单好用且高性能的API，让开发者快速上手。（大多数Java混子curdBoy不也不知道Spring框架, Mysql的底层么…os:真是自己骂自己）

简单聊聊我眼中Netty是什么

Netty是一个优雅著称的高性能网络编程框架，用于快速开发可维护的高性能协议服务器和客户端。Netty被广泛应用于各类网络应用开发，尤其是需要高性能和低延迟的场景，如游戏服务器、各种中间件和分布式系统等等。

Netty在我的眼里，是Java领域内高性能网络编程的基石。在网络编程的地位非常之高，有多高呢，有三四百层楼那么高吧。

可能身边的同学们还在用各种RPC、MQ…ES的时候，还不知道Netty在里面吧！（一种精通…咳咳，了解Netty的快感油然而生~）

没错，我们熟知的Dubbo，grpc的java端，rocket mq等等底层都有Netty的相关实现。Spring的web相关组件也是大量用到Netty，比如webFlux等。足以说明Netty的地位。

我认为Netty有两大特点，异步和回调。这使得Netty在高并发下仍能保持良好的性能以及处理各种事件。

问题来了，不熟悉网络编程的我在一开始上手十分困难，异步的机制和回调的代码书写让我感到十分难受，后来越来越被这种特点着迷，实际上Netty异步回调的代码实现的非常优雅。

它大量用到前人总结的设计模式，例如handler处理时候自定义的责任链模式，回调函数Listener的观察者模式… 真正的让开发者自由扩展，优雅编程。

下面我来简单说说Netty开发时的常用组件

常用组件

EventLoop（事件循环对象）

EventLoop 本质是一个单线程执行器，同时维护了一个Selector，里面有run方法处理Channel上源源不断地io事件。

它有两条继承线：

1、java并发包下的 j.u.c.ScheduledExecutorService 包含所有线程池的方法

2、Netty自身OrderedEventExecutor，

提供了 isEventLoop(Thread thread) 方法判断这个线程是否属于它

提供了parent方法来看自己属于哪个EventLoopGroup

EventLoopGroup (事件循环组)

事件循环组

eventloopgroup是一组eventloop,channel一般会调用eventloopgroup的register方法来绑定其中一个

eventloop,后续这个（hannel 上的10事件都由此eventloop来处理（保证了io事件处理时的线程安全）

继承自 netty 自己的 ececutorgroup

实现了 iterable接口提供遍历 eventloop的的能力

另有next 方法获取集合中下一个eventloop

ps: 其实一般开发就用两个，如果是接收多端的服务端ServerBootstrap那就一个BossGroup一个WorkerGroup，boss处理accept连接，而worker则处理io事件。如果是连接一个服务端的客户端，那么就只需要一个worker就可以啦

Channel

channel的主要作用及其常用函数

close()可以用来关闭channel

closefuture0用来处理channel的关闭

sync方法作用是同步等待channel关闭

而ad addlistener 方法是异步等待channel 关闭

pipeline()方法添加处理器，(自定义处理器，编解码处理器等等，Idle保活等等)

write()方法将数据写入

writeandflush0方法将数据写入并刷出

Future

搭配Promise既可以同步也可以异步，可以用的十分丰富炫酷，可以搭配juc去配套食用理解。

EmbeddedChannle

一般用来测试自己的处理器，很方便，可以直接将数据刷入站，读入站的数据。出站同理。

我就用来测试自己消息传输协议的编解码器，很方便的。

ByteBuf

池化与非池化，减少建立连接的开销
直接内存与堆内存，直接内存读写快，堆内存分配快，相辅相成
自动扩容机制，每次检测是否够空间()-> 不够 { 小于512直接扩容到512，如果大于512都是*2处理 }

没错，仅需要这些组件（还有一些Handler要知道）就可以开始愉快的网络编程了。起飞~

我认为Netty能干嘛

掌握了这些，我能做什么。掌握了这些，你可以自由开发你能想到的网络编程，甚至是做一个服务器去代替Tomcat，咳咳（我相信有部分公司应该是不用tomcat的…吧）精通了Netty，那真的是非常之牛掰了，真正的掌握JUC、NIO、Socket编程的王Orz

比如能干嘛呢？比如你可以基于Netty可以实现简单的聊天室功能了（被写烂了）参考某马程序员的Netty课程。如果要实现的比较正式高级的聊天室，可以到某站搜索程序员老罗，他的仿微信项目中的聊天业务使用的Netty比较好！开源精神o(￣▽￣)ｄ；

我对内网穿透比较有兴趣，所以我学完Netty的基础后捏，就快速的上手手搓了一个简单的内网穿透项目，嗨嗨嗨！

（等我完善好哈，我一定要开源出来，做到简单配置，简单使用，简单扩展，覆盖大多数人的需求。/加油，xdm双击点波关注上车了喂）

我的内网穿透分析

下面是我实现内网穿透的思路，有更好的思路欢迎讨论一起交流进步！

概括起来其实主要分为三步：

1、自定义消息传输协议 protocol。消息类包括type，data…当然还要有编解码器。

2、监听访客端，代理服务端，代理客户端，内网服务端。四端以及他们的对应的自定义Handler。

3、设计什么时候建立什么通道，什么时候用什么通道发送数据，什么时候关闭通道。并且如何维护这条通道，不会乱窜。

一、自定义消息传输协议

既然是协议，那肯定有消息体，有编解码。

首先ProxyMsg这个类你可以随便造，最简单的必须要有的也就是type和data，两个属性，其他消息流水号、指令消息等等可以自由发挥~ 这里是一个PeoxyMsg示例：

@Data
@EqualsAndHashCode
public class ProxyMsg {
    /** 心跳 */
    public static final byte TYPE_HEARTBEAT = 0x00;

    /** 数据传输 */
    public static final byte TYPE_TRANSFER = 0x01;

    /** 连接 */
    public static final byte TYPE_CONNECT = 0x10;

    /** 连接断开 */
    public static final byte TYPE_DISCONNECT = 0x11;

//-----------------------------------------------------
    /** 消息类型 */
    private byte type;
    /** 消息携带数据 */
    private byte[] data;

}

因为Netty是基于字节流的（ByteBuf）数据传输时自然会有粘包、半包的问题。所以编解码器要去解决这个问题。ProxyMsgEncoder和ProxyMsgDecoder。

如何去解决粘包问题呢？ Netty提供了一个解决方案，使用LengthFieldBasedFrameDecoder实现定长解码器，通过定义一条消息的各部分的实际长度，控制解码读取字节的时候不多读，不少读，按照规定字段长度读！

这里提供同样，也提供一个ProxyMsgDecoder的示例哈：

@Slf4j
public class ProxyMsgDecoder extends LengthFieldBasedFrameDecoder {
    public ProxyMsgDecoder(){
        super(Integer.MAX_VALUE, 0, 4, 0, 0);
    }
    @Override
    protected ProxyMsg decode(ChannelHandlerContext ctx, ByteBuf in2) throws Exception {
        ByteBuf in = (ByteBuf) super.decode(ctx, in2);
        log.info("in:{}",in);

        if(in==null||in.readableBytes()<4){
            return null;
        }

        int dataLen = in.readInt();
        byte type = in.readByte();
        ProxyMsg msg = new ProxyMsg();
        msg.setType(type);
        if(dataLen>1){
            byte[] data = new byte[dataLen - 1];
            in.readBytes(data);
            msg.setData(data);
        }
//        log.info("msg:{}",msg);
        in.release();
        return msg;
    }
}

既然消息的解码器你已经想好了，将ByteBuf进行编码成ProxyMsg就很简单了，这里是ProxyEncoder类示例：

@Slf4j
public class ProxyMsgEncoder extends MessageToByteEncoder<ProxyMsg> {

    //提供空参构造
    public ProxyMsgEncoder(){}
    @Override
    protected void encode(ChannelHandlerContext ctx, ProxyMsg msg, ByteBuf out) throws Exception {
//        log.info("msg encode:{}",msg);
        int bodyLen = 1;  //一个字节表示类型长度嘛，这个必须有的

        if(msg.getData() != null){
            bodyLen += msg.getData().length;
        }
        //先写入消息体长度 单位字节
        out.writeInt(bodyLen);
        //写入消息体类型
        out.writeByte(msg.getType());
        //写入消息携带的data
        if (msg.getData() != null) {
            out.writeBytes(msg.getData());
        }
    }
}

ok，这样就做好了最简单的消息协议了，是不是发现协议其实也就是一种约定罢了，但是真正的协议其实要复杂的多。这里就不赘述了 O.o

用刚刚说到的EmbeddedChannel来测试一下吧！

public class Test {
    public static void main(String[] args) {
        EmbeddedChannel channel = new EmbeddedChannel();
        ProxyMsg msg = new ProxyMsg();
        msg.setType(ProxyMsg.TYPE_HEARTBEAT);
        msg.setData("11111".getBytes());

        channel.pipeline().addLast(new ProxyMsgDecoder())
                .addLast(new ProxyMsgEncoder());

        channel.writeOutbound(msg);

        ByteBuf encodedMsg = channel.readOutbound();
        channel.writeInbound(encodedMsg);
        ProxyMsg decodedMsg = channel.readInbound();

        System.out.println("Type: " + decodedMsg.getType());
        System.out.println("Data: " + new String(decodedMsg.getData()));
        System.out.println(0x10);
    }
}

测试结果不出所料，没错，日志打出来的就是我们想要的嘛。

直到这里，我们真正的建立好了简单的消息传输协议，可以开始着手做Socket的开发了。

二、我选择设计四个Socket

我将按照访客 => 代理服务端 => 代理客户端 => 内网服务; 这样的顺序来讲
反之同理

首先我觉得有必要说一下启动的流程: 是
先把代理两端也就是Netty做的代理服务端和客户端启动并相连接，当客户端连接上服务端后建立一条，客户端Connect.addListener()发送一条TYPE_CONNECT的消息，服务端收到解析后，注册这条主通道。

注册好主通道后，启动访客端，监听公网某某端口，接收访客的请求数据。当有访客连接，建立访客通道

启动内网服务端，connect.addListener()连接成功的话，就建立起内网服务真实通道。

因为Netty是异步的，每个启动中的步骤他都是一起执行的。所以这些操作只需要注意启动的顺序就可以了,代理服务器启动-> 代理客户端-> 内网服务端&&访客端启动

以下是实现的端口以及handler的分析

内网服务Socket\代理客户端 : Bootstrap

访客代理Socket\代理服务端 : ServerBootstrap

为什么呢？其实判断他是单端的，还是多端的，就会明白！

VisitorSocket&Handler 他会启动一个服务器并监听某个端口，用于给访客访问。当访客访问端口的时候，建立起一个访客通道，并发送访问请求的数据到ServerSocket(代理服务端);
ServerSocket&Handler 启动代理服务端，根据消息类型的不同，处理消息的转发。当第一次和代理客户端相连接注册起主通道用来传输指令和唤起路由通道。
ProxySocket&Handler 启动代理客户端，接收访客数据并解析转发给内网服务。
ServiceSocket&Handler 启动内网服务端，新建一条路由通道发送CONNECT消息给代理服务端注册该通道。处理器对响应（Read到的）数据进行封装成TYPE_TRANSFER的消息，转发给代理服务端转发对应的访客通道。

四个Socket端，和对应四个Handler，和对应protocol协议，你数数加起来才几个类？
1234… 是的，也就才十一个类，再加一个server和client两个模块下的Constant，也才13个类就完成了Netty实现的内网穿透，是不是非常简单呢？