不同情况下的内网穿透
技术说明
- ddns:将动态的公网 ip 地址绑定到一个域名上
- 通过 VPN 访问内网:在互联网上建立一个隧道,通过隧道可实现访问内网设备
- 端口转发:将发送给 A 的某个端口的数据转发给 B 的某个端口。对于访问者来说,访问的是 A,实际响应的是 B
网络状况
设备 A 位于路由器后,设备 B 想要远程连接 A。以下是设备 B 分别使用 ipv4 和 ipv6 访问 A 时不同情况的处理方式。
设备 A 位于路由器后,设备 B 想要远程连接 A。以下是设备 B 分别使用 ipv4 和 ipv6 访问 A 时不同情况的处理方式。
起因是想在 openwrt 上装上openclash插件,但路由器空间不够了(路由器为 mi4a 千兆版,有一个 16M 的 NOR flash。通过在编译时设置块大小为 512KB,成功安装了zerotier
,wireguard
,python
等软件,编译的镜像大小为 13,894,754 B),因此参考官方教程:[OpenWrt Wiki] Saving firmware space and RAM,在编译时关闭了一些内核相关的选项,并将块大小设置为了 1MB。最后成功生成镜像,大小为 14,943,330 B。
可没想到在更新系统后路由器无法正确启动,于是需要先使用小米官方工具恢复,然后再重刷 openwrt 系统。但考虑到之后如果要多次尝试的话,每次失败都需要先恢复官方系统然后重新刷比较麻烦。于是这一次重装,我选择了刷breed引导程序。这样,下次刷失败后便可以通过 breed 直接重刷固件。
然而,不知是否是因为操作过程中的一个失误,我使用 breed 刷 openwrt 会失败,路由器会无限重启。并且在刷回官方固件后,甚至无法上网。最后,我从原厂固件直接刷回了 openwrt,但是却发现 openwrt 中的5GHz 的无线最大发射功率 (Maximum transmit power) 居然变为了 1mW(3dBm),这导致路由器的 5G 信号非常弱,即使是 1m 的距离,信号也很弱。于是我各种尝试去修复这个问题,以下是记录的过程。
我姐的电脑是 15-16 年买的,型号为 Acer Aspire V15 Nitro Black Edition(暗影骑士 2,精确型号为 Aspire VN7-592G-58NG),ZOL上的商品信息
不得不说这台电脑确实是非常厉害了,有以下这些亮眼的地方。
下面这些即使是现在也是完全够用的,特别是那个支持 2x2 MU-MIMO 的无线网卡。
而不仅限于此,这台电脑的扩展性是真的非常不错。
下面是发现这台电脑支持 NVMe 协议的固态的曲折过程:
在阅读之前,需要以下知识:
因为学校的 overleaf 无法通过 latex 代码定位到 pdf 位置。因此想在本地搭建一个 latex 环境,而如果在 windows 里安装 texlive+ 配置 VS code 比较麻烦,且以后重装系统又无法保留,因此考虑在 ubuntu 虚拟机里安装。
这里考虑同样搭建一个 overleaf,毕竟在主机里打开浏览器直接就能用就很方便,且界面也更美观。
overleaf 采用了 docker 进行部署,因此需要先安装 docker。
更新
在 virtualbox 虚拟机搭建后发现存在性能问题。以编译计组指导书为例,每次修改编译需要 1 分钟,并且经常出现编译 2-3 分钟然后失败的情况。
在查阅 wsl 性能比较后,发现 wsl2 的性能已经比较好了,有些场合接近原生 linux 的性能。参考Windows 10 May 2020 Performance For WSL vs. WSL2
于是补充了在 wsl2 上搭建的内容。
由于目前在电脑上运行一个虚拟机已经比较流畅,而虚拟机又有着真机无法比拟的优势,如:
因此我配置了一台 Ubuntu18.0 的虚拟机,并做了以下配置:
其中,关于最后一点。刚开始我采用了桥接网络 + 静态 ip 的方案。但是发现当主机网络环境改变时,ssh 便连接不上了,于是便有了这篇博客。
重写了 bad-apple 的代码,利用了多进程的方式进行视频转换。
以下是各个配置转换 bad apple.mp4 的时间
线性执行 | 4 线程 | 1 进程 | 2 进程 | 4 进程 | 8 进程 | 16 进程 | |
---|---|---|---|---|---|---|---|
时间 (秒) | 34.97 | 34.70 | 35.05 | 24.15 | 18.11 | 18.09 | 18 |
其中线程为采用 threading 库,进程则采用 multiprocessing 库
我的电脑配置为:
CPU | intel(R) Core(TM) i5-7200U CPU @ 2.50GHz 2.70GHz |
---|---|
RAM | 8.00 GB |
Windows | Windows10 家庭版 1909 18363.720 |
官方文档说明了 threading 库底层实现时仍只有一个线程,因而只适用于大量 I/O 并发的情况。而我们的图片转换成字符画的过程主要是计算密集型,因此基本没有改善性能。
而采用多进程时,刚好对应我电脑的 4 线程(2 核,采用超线程技术可以有 4 个线程,其实这里进程线程有点晕)时提升最大。
于是便想知道 32 个核时,能提升多少,便想在服务器上跑跑看。以下是配置运行过程。
出人意料的结果:
1 进程 | 4 线程 | 8 进程 | 16 进程 | 32 进程 | |
---|---|---|---|---|---|
时间 (秒) | 51 | 24 | 23.22 | 21.57 | 21.14 |
可能进程多了后,写文件的速度反而成了瓶颈,查看 top 发现各个核的 cpu 利用率都只有 10% 左右,在代码中输出 cvt_frame.qsize() 也发现几乎都是满的。(在自己电脑上大多数都是 0,表明 cvt_frame 供不应求)