这是一个创建于 836 天前的主题，其中的信息可能已经有所发展或是发生改变。
SG 的诞生简史
-
致谢花生壳
关于内网穿透，从技术的角度上讲，是个比较老的话题。我最早使用花生壳免费版实现反向域名解析，后来随着运营商网络调整，家用宽带进入 NAT3 时代，无法外网直连了，迫于代理网速过于感人，不得已的告别让我欠着花生壳一个会员，也让我重新思考：究竟需要什么样的内网穿透工具？
-
蜿蜒的路
很奇怪，技术人员的脑回路就是有些曲折，往往不是直达目标。那时的我，还是一个北漂的架构师，于是非常合理的决定先做网络引擎，当时 nginx 还不那么火，libev 尚不成熟，几经周折（业余时间少），做了个比 nginx 当时版本快了 40%左右的引擎（ 24 线程 2.4MH 单服务器 双千兆网络，http empty QPS 为 130w+），同时也顺便做了个 c++ framework 框架（原由是觉得 ACE/boost 等框架太臃肿低效），这一晃又是几年过去了，后来为了写 framework 的 demo 时终于想起来：我是不是曾经想做个内网穿透工具呢？
到这个时候，智能手机已经是主流了，记得应该是 Android5.0 时代吧。或许各位看官脑袋里会有个问号了：这么久了怎么都没看到你说的穿透工具呢？不要怀疑，归根结底是源自内心深处的懒癌～，有人说“好的程序猿是懒的程序猿”，我是不是好的程序猿不知道，但一定是懒的和你比的那个。 -
由来
事情的起因是源于某一次的交流，客户现场的 PPT 材料版本中有个附件不是最新的，新版本在异地电脑上，且在家里，各种的因素（不凑巧）造成了交流前最终没能拿到最新版本（所幸未对结果造成影响）…于是，理由充分便有了 SG ，初衷是：我需要一个拿着手机就能一切搞定的安全穿透工具
SG 简介
- SG 全称：smarGate （不要追问为何不是 smartGate---谁会承认是当初漏写了一个字母懒得改？）
- SG 的定位是：安全、便捷、多功能的远程端口映射工具。
- 安全性体现在：P2P 点对点，使用 TCP 协议，支持 TLS 加密，手机作为建议的访问入口（私有网络，安全性高）
- 便捷性体现在：手机的移动性，有网络的地方都能通过手机进行穿透访问；手机 app 端一点配置
-
多功能体现在：既能支持基于手机 app 的安全代理访问，也能支持类似其它穿透工具的服务器到服务器间的穿透访问（ v0.31 后版本）
- 安全穿透：“内网”到“内网”的穿透---自己使用（场景：摄像头、NAS 、RDP 、家中路由器、物联网等）
- 共享穿透：“外网”到“内网”的穿透---大家都能用（场景：自建 web 服务等）
- 多协议：支持 TCP （包括 HTTP/HTTPs/SOCKS5 及 UDP 协议）
-
其它非功能性特点：
- 体积小（ mini 版 1M 左右），无需安装，解压即可用
- 跨平台（支持 windows 、linux 、MacOS 、openwrt 、android 等）
- 稳定性高，满足 7x24 不间断访问需求，避免异地设备重启不便问题
- cpu 及内存资源占用少（部分路由器设备资源有限）
- 网络变化时自动感知适应（自动识别并支持 IPv6 及 IPv4 ），无需人工干预
- 服务端最小化配置（可理解为只需配置设备 ID ）
有关开源统一回复一下吧：首先我不认为这类工具有多大的技术含量，其次我认为开源的本质是协作，需求及工作量超过作者能承担范围协作及贡献才有价值。SG 目前功能需求迭代不多，工作量很小,满足必要性即开源。
链接就不放了，感兴趣的 V 友可移步 github ，搜索 smargate
 |
1
tairan2006 2022-08-08 16:29:07 +08:00
呃，相比 frp 的优势在哪…
|
 |
2
wslzy007 OP  1
@tairan2006
很久没关注 frp 了，记得之前版本 frp 对于穿透到外网时，是通过 frps 的控制台进行配置的，而 xtcp 模式则需要两个 frpc 分别配置重启，貌似 p2p 选项还需要指定。。。网络切换时也会连不上，不清楚现在的版本得到改善了没有 sg 直接在 app 上配就行了，新增删除比较方便。功能上都是端口映射的没有本质区别，只是 frp 使用 UDP 进行打洞，sg 采用 TCP |
 |
3
kchenzhi 2022-08-09 09:30:24 +08:00
占楼请教一下，我有个场景是这样的：两个不同的子网，它们仅支持 http 协议连接，其实就是两边各放了一个 nginx 监听 http 协议，我无权修改。但是我又想基于这个 http 层之上封装一层，实现 TCP 层的链接，这样俩子网之间的 tcp 服务就能互相访问了。 大概得思路是在两个子网各放一个代理节点，监听 tcp 端口，然后将收到的 tcp 报文转成 http 的形式投递到对端代理，对端代理接收到 http 请求后取得报文，再发起 tcp 连接真实的目标端服务。
不知道有没有开源的组件能实现这个需求？ |
|
4
wslzy007 OP @kchenzhi
你的场景应该说明为什么会有这样的网络设置？这种设置为了解决什么问题？无权修改，究竟有哪些权限？少了很多上下文，难以回答。 举个极端例子：微信支付，阿里服务器开放 https 接口，你自己服务器开放 https 回调接口。。。让黑客来试试吧 事实上，可行与否取决于你能否将报文投递到对端 自己的代理上 。首先得有在对端有安装权限吧 。对端 nginx 监听端口你得有权限修改并重启吧 。满足上面条件后，你才能鸠占鹊巢，开心的玩你的代理转发 |
 |
5
aQuQ 2022-08-09 22:09:20 +08:00
印象中好像很久前就用过 lz 的这款工具，在内网穿透工具中确实算简单易上手的
|
Select Language