DEV Community: xilio

【最新】基于Netty实现的开源免费内网穿透神器vin，即装即用，再也不用花大钱了，安全高效多客户端多协议穿透

xilio — Sun, 22 Jun 2025 14:01:20 +0000

介绍

内网穿透 主要用于将内网的服务，例如MySQL、Redis、Tomcat等服务暴露到公网，解决服务器内存严重不足且费用高的问题，这在系统测试时非常有用。市面上有一些三方的代理如花生壳，不仅价格昂贵，而且还存在数据泄漏风险（最主要还是太贵😄）。

vine是一个基于Java生态的内网穿透工具（类似于Go语言实现的frp），目前版本支持TCP/HTTP协议穿透。

🔥Github开源地址：https://github.com/xilio-dev/vine

## Github截图

更多细节访问Github： https://github.com/xilio-dev/vine

Bug：io.netty.util.IllegalReferenceCountException: refCnt: 0, decrement: 1

xilio — Sat, 21 Jun 2025 03:04:56 +0000

我在使用netty做项目的时候发生了错误，错误堆栈信息如下：

io.netty.util.IllegalReferenceCountException: refCnt: 0, decrement: 1
    at io.netty.util.internal.ReferenceCountUpdater.toLiveRealRefCnt(ReferenceCountUpdater.java:83)
    at io.netty.util.internal.ReferenceCountUpdater.release(ReferenceCountUpdater.java:148)
    at io.netty.buffer.AbstractReferenceCountedByteBuf.release(AbstractReferenceCountedByteBuf.java:101)
    at io.netty.util.ReferenceCountUtil.release(ReferenceCountUtil.java:90)
    at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:106)

原因分析

发生错误的原因是重复释放ByteBuf缓冲区，我在处理器中手动调用了release释放buf，然而该buf是由netty底层进行管理的，会被再次调用，所以出现了该错误！

解决方案

删除ReferenceCountUtil.release(buf)该行代码。

protected void channelRead0(ChannelHandlerContext ctx, ByteBuf buf) {
  try {

  }finally {
     //ReferenceCountUtil.release(buf);//删除该行代码，buf由netty底层进行管理
  }     

}

Gitee隐私保护机制导致无法push解决方案

xilio — Sun, 15 Jun 2025 03:26:06 +0000

问题是由于 Gitee 的邮箱隐私保护机制阻止了推送，因为提交中包含隐藏的邮箱地址。


11:17:19.414: [xilio-doc] git -c credential.helper= -c core.quotepath=false -c log.showSignature=false push --progress --porcelain origin refs/heads/main:main
11:17:40.485: [xilio-doc] git -c credential.helper= -c core.quotepath=false -c log.showSignature=false fetch origin --recurse-submodules=no --progress --prune
11:17:58.256: [xilio-doc] git -c credential.helper= -c core.quotepath=false -c log.showSignature=false push --progress --porcelain gitee refs/heads/main:main
Enumerating objects: 12, done.
Counting objects:   8% (1/12)
Counting objects:  16% (2/12)
Counting objects:  25% (3/12)
Counting objects:  33% (4/12)
Counting objects:  41% (5/12)
Counting objects:  50% (6/12)
Counting objects:  58% (7/12)
Counting objects:  66% (8/12)
Counting objects:  75% (9/12)
Counting objects:  83% (10/12)
Counting objects:  91% (11/12)
Counting objects: 100% (12/12)
Counting objects: 100% (12/12), done.
Delta compression using up to 8 threads
Compressing objects:  14% (1/7)
Compressing objects:  28% (2/7)
Compressing objects:  42% (3/7)
Compressing objects:  57% (4/7)
Compressing objects:  71% (5/7)
Compressing objects:  85% (6/7)
Compressing objects: 100% (7/7)
Compressing objects: 100% (7/7), done.
Writing objects:  14% (1/7)
Writing objects:  28% (2/7)
Writing objects:  42% (3/7)
Writing objects:  57% (4/7)
Writing objects:  71% (5/7)
Writing objects:  85% (6/7)
Writing objects: 100% (7/7)
Writing objects: 100% (7/7), 53.60 KiB | 17.87 MiB/s, done.
Total 7 (delta 4), reused 0 (delta 0), pack-reused 0
remote: Powered by GITEE.COM [1.1.5]        
remote: Set trace flag 0a432682        
remote: Push will publish a hidden email, make email public or abandon related commits        
remote: error: hook declined to update refs/heads/main        
error: failed to push some refs to 'gitee.com:xilio/xilio-doc.git'
To gitee.com:xilio/xilio-doc.git
!   refs/heads/main:refs/heads/main [remote rejected] (hook declined)
Done

解决方案：公开邮箱

图文讲解Netty编解码器解决沾包和半包问题，透析本质

xilio — Sun, 15 Jun 2025 03:11:18 +0000

TCP是以流的方式进行字节传输的，所以无法知道数据的边界，也就意味着无法区分出一串数据，比如一段二进制由于没有边界，客户端收到以后随意截取就会导致数据错乱，不是期望收到的数据。

下面一段代码是一个基本的解码器的案例：

public class CustomDecoder extends ByteToMessageDecoder {
    @Override
    protected void decode(ChannelHandlerContext ctx, ByteBuf in, List<Object> out) throws Exception {
        if (in.readableBytes() < 4) return; // 检查是否有足够的字节读取长度字段 【1】
        int length = in.readInt(); // 读取4字节的长度字段 【2】
        if (in.readableBytes() < length) {  //【3】
            in.resetReaderIndex(); // 数据不足，重置读取位置 【4】
            return;
        }
        ByteBuf frame = in.readBytes(length); // 读取消息体【5】
        out.add(frame); // 输出到下游 【6】
    }
}

代码详解：

【1】in.readableBytes() < 4

这段代码的效果是从TCP流中读取4个字节（想象从TCP流的最开始位置），这4个字节是用来记录后面Body数据的长度的，这样就可以确定后面数据的边界，确定后面的数据边界以后，通过偏移量就可以得到下一个Head，通过Head又可以得到后面Body的长度，
以此类推，这样一来字节流就形成了边界，就可以组装成正确的数据了；那为什么是4而不是其他的呢？其实也可以是其他的（比如2、8字节等），因为4字节可以记录的长度在java中是32位，已经可以得到足够大的整数了，几乎可以满足所有的场景，这也是一个折中的选择
如果用2字节表示的长度又太小，后面的Body内容实际可能很长，如果用8字节，那可能没必要，因为后面的Body大多数场景实际的数据没有那么长，如果用8的话就会造成浪费，完全没必要，所以这就是为什么要用4的原因。

【2】in.readInt()

这段代码的效果是读取4字节（我们规定的是4字节表示头），可以读取到一个整数表示后面Body的长度，连续读取该长度就可以得到一个正常的数据。

【3】in.readableBytes() < length

通过Head头我们知道后面Body应该读取多少长度的数据，但是由于TCP基于流的，可能会将一个很长的消息进行拆分传输，导致没有收到完整的的数据，也就是常常说的半包问题，
因此需要做一个判断，等下次数据满足Head要读取的长度后再读取。

【4】in.resetReaderIndex()
将索引恢复到上次的位置，不然下次读取就会错乱，原因在于调用in.readableBytes()会导致索引先后移动，竟然这次都没有读取成功，肯定要恢复。

【5】in.readBytes(length)

终于可以读取指定长度（来自Head）的字节数量了，得到的就是实际的Body内容，也就是发送者单次实际发送的数据。

TCP协议和UDP协议有什么区别？

xilio — Tue, 10 Jun 2025 12:16:57 +0000

TCP协议是流式协议，基于字节流传输，没有数据的边界需要在应用层解决粘包和半包的问题，而UDP协议是基于数据报传输的，有明确的数据边界。
UDP是无序传输，不保证数据包的顺序，可能会出现丢包和乱序的情况，同时属于无连接协议，不具备可靠性，TCP则相反。

基于TCP的上层协议如HTTP/HTTPS、WebSocket、MQTT等协议都有各自的消息边界，所以在使用这些协议的时候，开发者不需要解决粘包和半包的问题。