使用 PHP 实现的的内网穿透工具 “Spike”

2017-06-27 23:00:08 +08:00
 slince

Spike https://github.com/slince/spike;

之前由于要与一个同事远程协作开发一款 app 需要用到内网穿透服务,在网上找到了 frp 与 ngrok ;后来我在想能不能用 php 也写出来一个这样的服务软件?大家都知道 php 多进程多线程不够友好,在 window 上还不支持;写服务确实很吃力;不过幸运的是有ReactPHP的存在,关于 ReactPHP 不做赘述有兴趣的同学可以自行百度。

基于 ReactPHP 的 IO 多路复用,使得 Spike 并没有比 Frp 性能差太多;下面是我简单做的一个 benchmark,基于 apache ab 检验 http 隧道的服务性能;客户端与服务端都搭在本地,代理同事电脑上的 http 服务。不是特别符合应用场景,大家简单看一下。

从下面的信息可以看出 Spike 性能似乎是稍微好点的,不过这个地方有点不公平,我在做 spike 的测试时只开启了服务端的日志,客户端的日志是关闭的;而 FRP 的两端日志都是开启的;我不知道怎么关 frp 的日志;

在这里简单提一点由于 Spike 的日志 IO 是同步的所以日志的读写会耗掉部分性能,提升日志等级减少日志写入可以提升不少的性能;

这个项目是我比较上心的一个作品,算是证明了一点,php 除了可以做网站也可以做服务,并且也没有太差。 最后再次附上项目地址: https://github.com/slince/spike 欢迎 star,欢迎 fork

Spike:

Concurrency Level:      10
Time taken for tests:   37.727 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      2569900 bytes
HTML transferred:       2514600 bytes
Requests per second:    2.65 [#/sec] (mean)
Time per request:       3772.747 [ms] (mean)
Time per request:       377.275 [ms] (mean, across all concurrent requests)
Transfer rate:          66.52 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.4      0       3
Processing:   533 3602 591.9   3714    4096
Waiting:      516 3587 592.3   3701    4076
Total:        534 3602 591.9   3715    4097

Percentage of the requests served within a certain time (ms)
  50%   3715
  66%   3791
  75%   3822
  80%   3844
  90%   3970
  95%   4015
  98%   4053
  99%   4097
 100%   4097 (longest request)

Frp:

Concurrency Level:      10
Time taken for tests:   38.230 seconds
Complete requests:      100
Failed requests:        0
Total transferred:      2569900 bytes
HTML transferred:       2514600 bytes
Requests per second:    2.62 [#/sec] (mean)
Time per request:       3823.045 [ms] (mean)
Time per request:       382.304 [ms] (mean, across all concurrent requests)
Transfer rate:          65.65 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.2      0       1
Processing:   379 3650 644.4   3809    4140
Waiting:      360 3633 645.5   3789    4124
Total:        380 3650 644.4   3809    4140

Percentage of the requests served within a certain time (ms)
  50%   3809
  66%   3847
  75%   3909
  80%   3923
  90%   4026
  95%   4053
  98%   4129
  99%   4140
 100%   4140 (longest request)
9997 次点击
所在节点    分享创造
35 条回复
slince
2017-06-28 10:18:36 +08:00
@wu1990 swoole 一样的问题 win 下面不可用
slince
2017-06-28 10:22:01 +08:00
@shuimugan react 其实有一些实际应用了,不过基本上都被当做实验性质,这点比较遗憾;

ps: 除了 reactphp 还有一个项目也值得关注 amphp( https://github.com/amphp ) 跟 reactphp 一样的原理,名气差点
ajan
2017-06-28 11:09:09 +08:00
ngrok 不是有 php 版么?
slince
2017-06-28 11:24:32 +08:00
@ajan 那个服务端还有一定的功能阉割而且用起来不方便,包装成可执行命令更方便;
ajan
2017-06-28 11:39:10 +08:00
@slince #24 表示只是看到过,没有玩过。 要是不用命令行运行就爽了
hhacker
2017-06-28 11:46:58 +08:00
已 star 好东西啊
slince
2017-06-28 13:02:17 +08:00
@ajan 命令行不是更方便吗;现在的 php 项目基本都是多文件的;不像以前都写着一个文件里;把文件下载下来执行下了事了
slince
2017-06-28 13:03:11 +08:00
jz361
2017-06-28 15:52:04 +08:00
顶,来学习的
Actrace
2017-06-28 16:44:58 +08:00
CLI 领域,PHP 确实有很多独到之处,因为 PHP 核心代码是很稳定的。比菜鸡自己用其他语言实现相同功能更稳定跟快速。

但是,php 封装了不少挺潮流的东西,本身来说,socket 也只是给标准 socket 库套了一下。其他类似的东西,比如 ev,libev,event 都有,什么多路复用,多线程都能搞。问题就在于大多数的库都没有把 bug 修完,偶尔会埋个坑,然后隔个几年才发现。对于生产环境来说,这是难以接受的(以前用 pthreads 写过服务,发现很多坑,隔了一年才修复)。

另外的一点就是内存的控制了,因为自动类型,这一块完全就是由 PHP 内核在管理,然后目前为止,内存的回收都还没有做完美。有些服务要运行个 1 年 2 年,结果就是内存不够用了,悲剧。
slince
2017-06-28 19:27:39 +08:00
@Actrace 对的内存回收是个麻烦,这个也是我目前比较担心的问题,为此我在项目中加了不少定时器去维护几个核心的集合防止内存溢出,好在现在看起来并没有什么异常
Actrace
2017-06-28 20:13:52 +08:00
@slince 目前唯一靠谱的解决方案是学 apache 或者 fastcgi,就是负责业务的进程在执行一定次数的业务后结束掉,由守护进程再开新的业务进程。然后守护进程尽量写简单一些,尽量少点在守护进程里进行创建变量之类的操作。
dailaosan
2017-06-28 21:41:49 +08:00
Jj
a308057848
2017-06-30 09:52:33 +08:00
👍 厉害了.
slince
2017-06-30 12:53:39 +08:00

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/371529

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX