OPTMAN

Hole-Punching Rust库

optman -

上篇说libp2p终于支持hole punching了，可以支持很多应用场景了。为此，我还写了一个简单的应用p2p-tun。不仅实现了端口转发，还实现tun2socks了。但也发现了一些局限，比如不支持udp，比如relay不会自动重连等等。还有，libp2p是基于stream的。虽然也可以在tcp基础上传输udp，但是效率太低，现实意义不大。另外也发现libp2p委实太过臃肿，占用资源太多，Bug坑也不少。libp2p想要承担基础网络的功能，复杂是必然的。但是，对于一个普通的应用来说，带上这么一个臃肿的包袱是否合适呢？平台的事情就应该由平台来做，应用本身就可以就很简单。比如TCP/IP的协议很简单，但TCP/IP的支撑网络很复杂。socket应用接口很简单，internet的路由很复杂。因为libp2p的DHT实际上承载了internet路由的功能，所以很耗费资源。还有，libp2p的打孔功能，号称是分布式的。实际上呢，是先借助公网的Peer实现中转连接，然后才完成打孔（这不禁让我想起“国产凌凌漆”里那个有光才会亮而没有光绝对不会亮的手电筒）。现在是不依赖于特定的中转服务器了，但是寻找中转的效率太低，连接速度太慢。如果不非得追求分布式，直接依赖一台中心服务器来帮忙，那效率就高多了，也简单得多。

于是就想，有没有简单的打孔库呢？不需要复杂功能，不需要中转数据，只需要能完成打孔即可，其它的交由上层应用处理。事实上，我手头就刚刚完成几个vpn和proxy的程序，由于没有打孔功能，只能在公网环境下使用。如果能有一个模块，能够代为完成打孔，那岂不是很好。实际上打孔的原理很简单，就是要通讯的双方同时（几十秒之内）都给对方发消息，就可以打开NAT映射和防火墙规则了。只需要在通讯建立之前，由一台服务器代为中转消息即可。还有一个关键点是，与服务器通讯的port和Peer通讯的port必须相同。正好最近看了cloudflare的几篇blog，里面很详尽讲述了他们是如何利用SO_REUSEADDR和SO_REUSEPORT搞定海量连接问题的。看起来也就是几行代码的事情，说干就干，于是就有了rndz库（rendezvous缩写）。rndz完成的事情很简单，对于客户端，给一个目标peer的id，帮你完成打孔动作，然后把原始的socket（没有额外的封装）交给你，直接用就行--就是简单把connect函数替换一下。对于服务端，则是把listen替换一下。

TCP

use rndz::tcp::Client;

let c1 = Client::new(rndz_server_addr, "c1", None)?;
c1.listen()?;
while let Ok(stream) = c1.accept()?{
//...
}

use rndz::tcp::Client;
let c2 = Client::new(rndz_server_addr, "c2", None)?;
let stream = c.connect("c1")?;

UDP

use rndz::udp::Client;

let c1 = Client::new(rndz_server_addr, "c1", None)?;
c1.listen()?;
c1.as_socket().recv_from(...)?;

use rndz::udp::Client;
let c2 = Client::new(rndz_server_addr, "c2", None)?;
c.connect("c1")?;
c.as_socket().send(b'hello')?;

对于TCP，还提供基于tokio的异步版本AsyncClient。

接着是对之前的程序进行改造，以支持打孔。比如 minivtun-rs是一个基于udp的vpn，还有quic-tun是基于quic的tcp端口转发。因为rndz提供了原生的socket，所以改造成本很低！以上都是基于udp，我还需要改造一个基于tcp的实用应用。正在不久前，我发现过一个基于libp2p实现的文件传输程序pcp，理念挺不错，缺点就是libp2p建立连接的过程太漫长。现在要找一个rust写的(因为rndz是rust写的，因为之前的minivtun-rs也是rust)，简单实用的，最好还有续传的。于是发现了teleport，这个没有对网络传输进行epoll优化什么的，而直接用了rust原生TcpStream。这样把TcpStream和TcpListener简单替换一下，搞定！有了这个支持打孔的文件传输工具，就可以轻松在各虚拟机之间轻松传递文件，而不必依赖ssh，也不必考虑子网互通的问题了！

之前以为ipv6时代不需要打孔的，现实情况是，还得要！所以rndz库的存在，是有着现实意义的。实际上，目前的rndz client会自动根据rndz服务器的解析地址来选择本地绑定是使用ipv4还是ipv6地址。我目前临时提供两个测试server（ipv4: rndz.optman.net:8888 ipv6: rndz6.optman.net:8888），可以实测一下打孔效果。有一个好的测试工具很重要，我之前说过电信同城ipv4不互通，是不对的，其实是可以通的。

peer1

$ rndz client --id c1 --server-addr rndz.optman.net:8888

peer2

$ rndz client --id c2 --server-addr rndz.optman.net:8888 --remote-peer c1

rndz目前只是简单实现了功能，有很多细节并没有考虑。比如id的生成和校验问题，通讯是否要加密等等。我认为呢，id生成交由上层应用或者用户根据业务生成更方便灵活。而加密问题更应该是上层tls等考虑的，底层尽量简单，毕竟这做的是连接建立之前的工作，原本就是不安全的飞地。