type
status
date
slug
summary
tags
category
icon
password
思路
- 家宽没公网 IP，不过一级路由设 DMZ 可以做到 NAT1
- 接上，NATMap 维持 TCP / UDP 端口没有难度；UDP P2P成功率也很高
- 游戏服务器暴露端口为UDP 8211，但连接时可以输入任意端口
- 游戏不支持 SRV 记录（为什么大家都不喜欢 SRV 记录啊，资本主义不需要 NAT Tranversal 吗）
访客可能有：
- 香港人
- 大陆人
- 日本人（大概不会有吧）
网络结构大概是
我个人信念是若无必要勿增实体（这句话真的是这么用的吗），因此大致思路如下：
- 游戏服务器运行 frp，穿透到腾讯云，作为香港人入口
- 路由器跑 DDNS 绑上公网 IP，再跑个 NATMap，把游戏服务器的8211端口映射到暴露出来的公网端口上。大陆人就可以用DDNS域名:动态端口访问了
- 真来了日本人，Webarena 开个端口，iptables 或者其他工具直球转发到腾讯云
坑点
高度怀疑
frpc <--> frps 的连接默认使用 TCP 通信，而 local <--> frpc 则是根据配置的协议通信。为什么捏？调试防火墙时，frps 的
server_ip 以及 server_port 挡住 UDP 是不影响 frpc 的 UDP 应用项通信的；而如果挡住 TCP，frp 就会断线。frp 配置
quic_bind_port = [udp port] 时会使用 UDP 通信，这时防火墙挡住对应的 TCP 端口也不会断线。但挡住 UDP 就会断线。优化
综上所述，我之前另外买了个流量转发服务。只开启 udp 转发模式下，不使用
quic_bind_port 时 frpc 无法通过转发服务连接到腾讯云。使用 QUIC 后则可在 UDP 转发下正常使用。（伪）专线延迟和稳定性其实还行，至少在没有 CN2 线路时够撑一下了。
不过 QUIC 的重传机制 + 国内运营商 QoS，其是否有 TCP 转发稳定还要打个问号。待后续观察了。
总结
- 考虑到腾讯云直连国内的线路稳定性，额外开了一个 UDP 转发给 frp 暴露到腾讯云当作主力给香港人。
- 流量转发爆炸时走腾讯云直连国内
- 大陆人用DDNS:动态端口的方式直连。上海电信连过来游戏内延迟大约 55ms。实际 ping 的话大约 30ms？
- 日本人还没来玩，等有人来玩了再说（游戏内延迟估计要上百）