FRP —— 高性能反代工具

前言

折腾过游戏服务器或一些Web服务（例如个人博客）的朋友在最初应该都遇到过一个问题：自己好不容易在本机搭建起来的服务，查到IP和端口后，开开心心将其分享给远方的朋友。结果换来的却是一个无法连接，回过头来还以为是别人的教程写错了。这实际就是一个在当今运营商层层NAT封锁下，个人用户对外提供服务面临的困境局面。

我们知道：

处于NAT环境的设备，其设备主动出站的流量是可以经网关后进入公网环境的。而设备主动访问的对端，也能顺着这条连接找进来给我们回包。从宏观上就是我们本地主动请求服务，位于公网的服务回复数据包向我们提供服务。

但是一旦身份反转，例如外面想主动连接我们的内网设备，就会因为NAT的性质——必须先由内网发起请求并由NAT记录，指定对端的包才能被网关NAT放进来；若没有内网主动发出的请求，则网关根本不知道该把包转给谁，只能直接丢弃。因此NAT死死挡住了这条由外向内的连接，这就是为什么位于不同内网中的两个设备都能上网，但是互相无法直接通信的根因。所以，不同内网设备要想建立通信，直接连接是行不通的。

---

这里还有一种方法——P2P连接，也就是我们常说的“打洞”。这个原理很简单：由STUN服务器作为中间人，交换双方在各自NAT上的端口映射与IP地址，随后双方同时发包命中对方与STUN维持连接的端口，如果顺利的话那么将能够打出一条直通对方设备的网络通道，届时通信速度将非常快。这也是为什么Radmin这些软件第一策略都是先尝试打洞的原因。

当然打洞不是万能的，甚至在目前来看只会越来越难。NAT有四种形态（讲过太多遍了，此处就不赘述了），其中双方都必须是锥形才有几率成功，但凡有一方是对称NAT那么打洞基本都不可能成。而现在在运营商多层CGNAT的套子下，不管是家宽也好还是什么网络，其出网网关基本都是对称型NAT，打洞很难成功。

既然直连不行，打洞也很大概率失败，那么能供稳定备选的方案就是我们的公网中继手段了，FRP就是其中一个典型例子。其本质就一句话：既然大家互相都找不到对方，那我们去找个中间人牵线搭桥不就行了？

---

什么是 FRP？

FRP 是一个常用于内网穿透的反向代理工具，反向代理这个概念指的是——代理服务器始终暴露在公网环境，挡在最前面，替背后的真实源站接收外部请求以及搬运数据的。在内网穿透这个场景下，反代多指由外向内打洞建立隧道后再反向复用这么一个模型。

FRP 一个常见的用途是将内网客户端的某个端口映射到公网环境中，从而实现外网对内网的访问。你可以这么理解：frp 是一根”反着插的管子”：公网服务器在明处等客（frps），家里的机器主动挖一条长连接过去（frpc），再把公网端口接进内网——外面的人看到的是公网服务器，数据实际都流进了你家。

再说得直白一些：FRP 其实就是通过在具有公网IP的中间节点上部署服务端，通过两根数据管道（其实准确来说应该是三根，为什么？下文详述）在你的本地服务与外网设备之间来回搬运数据。通过桥接在宏观上实现一种两台内网机之间的顺畅通信。

---

中继原理

在阐述通信原理之前首先需要明白两个概念：

• frps(Server)：作为“前台”部署在公网侧，负责服务端口暴露（门在哪）、入口流量代理登记（你是谁）、出口流量分发（要去哪）。
• frpc(Client)：作为内网“办事处”，负责搭建通信隧道、心跳保活以及事务处理。

这里Server和CLient的概念与常规意义上的有所区别，一定要分清。此处的frps并不对外提供本质上的服务，它只作为中间人负责两台内网设备之间的通信桥接，也就是说虽然叫Server但是服务器不在它这里！而frpc虽然叫Client，但是具体的服务（比如游戏服务器、语音服务器等）是跑在这里的，由frpc产生具体业务数据后通过frps进而与其它内网设备产生联系。

这你可能会问：为什么不直接把服务跑在云端，这样不就不需要frp技术了吗？理论上这完全成立，但是需要考虑实际成本。对于游戏服务器等一些计算量大的工程，需要云端服务器具备比较高的配置，而云端服务器是非常贵的，我们手头的个人PC普遍配置较高，因此使用frp并不是多此一举，而是对于个人服务提供的一笔经济账。

扯远了，回来。现在来看看frpc+frps这个框架是怎么运作的：

内网frpc客户端首先向公网frps服务端主动发起通信建立通信隧道，而后双方通过共享Token来进行握手验证，若握手失败服务端则主动断开连接；握手成功后，frpc会向frps注册代理——Token握手以及代理注册这些行为是一套frp的应用层私有协议，此处不展开讨论。只需要知道frpc会要求frps监听在指定端口，并会指定代理的协议类型(tcp/udp等)。

• 关于Token认证：

  Token就是安全密钥，在frps的配置文件中由用户自主进行配置，同时还需要配置frpc端的Token，通信双方的Token必须保持一致。在TCP连接建立后，在frpc侧会主动将自己的Token打包成特定协议格式发往frps服务端，服务端收到后验证密钥是否与自己配置的相同，相同则承认该客户端，若不同则主动断开连接。

• 为什么需要Token验证？

  因为frps服务端是公网环境，具备公网IP，也就意味着全世界都能连过来。假如没有验证，只要有人扫到你的端口，就可以写一个frpc连接上了，以你的机器为跳板隐藏自身源IP去发动攻击行为。

• 心跳保活：

  当frpc与frps之间连接正式建立并验证Token之后，frpc客户端会定时发送心跳探测包给云端，云端收到后会回复该包，这就是FRP应用层的Ping-Pong连接保活机制，目的是保证通信隧道正常存活。因为FRP本质上是依赖内网设备主动出网并且在网关NAT会话表上留下的记录来进行双端通信的，而网关NAT会话表是有超时时间的，因此为了保持通道一直存活，在超时之前会通过探测包来刷新时间，维持长连接。