近日入坑了pt站点，并在NAS上新增了一个12T的希捷银河氦气盘，在闲暇之余下载一些大包刷刷上传量之外，总是逮着喜欢的资源就肆无忌惮的下载（上传量能刷得很快哈哈哈），不得不说，pt站的资源确实是优质，和普罗大众共用的bt确实不同，种子资源、做种量根本都是不能比拟的。
然而随之而来的问题就是，优质的资源它总得要播放才能看才能听吧？而播放过程中某个环节出了问题，则会影响整体的观感体验，没错，我就遇到了。
原有网络拓扑
下载的资源大多都是1080P、2K、4K的视频格式文件，而后两者大多还是蓝光原盘的ios或者是BDMV包，1080P的视频一两个小时可以从2G到10多G不等，而到了2K、4K级别的资源，少说也是一个多小时得有个20G到80G不等，这样就对NAS这种网络存储设备使用场景产生一定的考验，或者说是整条网络链路质量的考验。
现在手上的涉及到这一套基于网络的播放、网络设备就这么几个，电信给的普通光猫，K2P，蜗牛星际A款，小米电视E55A。
为啥要说是普通光猫呢？因为它就是最典型的单千兆+三百兆配置，其中千兆桥接出来给K2P拨号上网代理家庭网络上网，其他接口暂时没有使用。
K2P这么一款经典的全千兆良心路由器就没有什么好多说的了，刷了padavan（老毛子），更新了hiboy的v5驱动版本。而作为经典矿渣的蜗牛，我的这个蜗牛星际A款是第一批上的车，里头还是原装绿色主板，J1900，16G内存，单千兆网口，刷了黑群晖6.1.7（DS3617xs）。
小米电视和K2P之间使用5G wifi连接，使用小米自带的测速功能，测试与公网之间的速度可以达到20MB/S，算是还行的程度，但是尚未知电视和NAS之间的速度，并且公网与内网之间的差别还有延迟等各种问题，以及延迟对小量数据的随机读取的影响等等。
总览一下，原来的网络拓扑如下图所示：
现象
基于以上这一套网络拓扑，在通过小米电视观看1080P视频文件的时候就还好，而如果是观看2K以上清晰度视频的时候，就会出现播放一会，就要转圈圈读取一会的情况，频率大概是10s一次，非常影响观影体验。遇到这种情况，就算不是强迫症，也会想要去改善一番。
在尝试过将蓝光原盘拷贝到U盘中插入电视进行本地播放，并且非常顺畅之后，基本上就确认问题出现在视频文件数据传输到电视上这个环节了。
而影响视频文件从NAS通过wifi传输到电视上速度的因素也有很多，比如硬盘读速度、NAS到路由器的传输速率、路由器到电视之间的wifi传输速率、路由器各网口之间的交换速率，都有可能影响，所以我又开始了漫漫的排错之路。
排错
在排错的策略上，我采取的是由易到难的顺序进行的。每个环节按照排错难易度来排序，以我个人的理解，可以排成下面这样：
- 路由器到NAS（或者其他有线连接的终端）
- 路由器网口之间的交换性能
- NAS中的硬盘读取速度
- 路由器通过wifi到电视（这基本没法测，因为电视的操作系统没法进入后台，只能直接放电影来观察现象）
路由器到NAS
测试链路带宽质量，最方便也最普适的方法应该就是iperf了吧。
Padavan虽说是华硕自家的系统，但是也内置了opkg，opkg是一个开源的包管理系统，是Open PacKaGe management的缩写。直接进入K2P的后台使用opkg安装iperf3即可。
1 | opkg update |
而在群晖上使用iperf3就更加简单了。只需要从docker套件中，安装iperf3的镜像，然后在配置容器的时候按照iperf3的语法规则配置启动命令即可。附上一个张大妈的参考文章：
运行iperf3。iperf3和iperf相同，有服务端和客户端两种运行模式，在测试的时候需要自己确定哪个设备是服务端，哪个设备是客户端。
1 | # 服务端启动 |
测试之后，只能说，很遗憾，问题也不是出在路由器到NAS之间的链路上。
路由器网口之间的交换性能
由于每个厂商的路由器设计不同，每个网口的工作行为虽然在用户侧看来是相同的，但是在内部实现上却是不同的。
例如大部分家用路由器只需要支持单WAN口，+N个LAN口的工作模式，这时候路由器厂商在设计时，是在CPU后方接一个带网管的交换机，通过不同的vLAN来区分WAN、LAN、DMZ等。在这种设计模式下，同属于LAN区域或者DMZ区域的流量会直接经过交换机里头的交换芯片，而不通过CPU，这样交换效率就会比较高。
而另一些工业级、企业级的路由器上，由于需要满足自定义网口配置（例如多WAN口、自定义WAN口、自定义vLAN等），这时候则可能将路由器内部实现为每个网口都是一个独立的网卡，每个网卡都直接接通CPU，在配置LAN区是某几个网口时，CPU会在系统内建立一个虚拟网卡（例如eth0）去桥接每个需要绑定在LAN区的网口（例如ge0、ge3、ge4），将其上的流量在CPU上模拟出来的交换机（虚拟网卡）上进行交换。在这种设计模式下，由于没有硬件交换机芯片，交换机功能是通过CPU模拟出来的，这时候同区域的网络流量的交换在经过CPU的时候就会产生性能的损失。
基于这种情况，所以需要看看是否是这一环节出了问题。为了排查这个影响因素，我还去专门买了一个USB3.0转2.5G RJ45口的网卡【捂脸】。
结果一顿操作猛如虎，一测，路由器到电脑有线连接跑iperf3可以跑满千兆，NAS到电脑中间经过路由器有线连接跑iperf3还是可以跑满千兆。
哦豁，这一波，白亏一个USB网卡。
NAS中的硬盘读取速度
由于具备了上面的条件，就可以直接通过电脑拷贝NAS上的文件到本地来测试NAS上硬盘的读取速度了。
拷贝一个3G的文件到本地，速度可以维持在100到130MB/S之间，这样的速度测试，反正看下来也是没啥问题，千兆极限妥妥的。
一个题外话，使用windows电脑就可以跑满速度，而使用mac就跑不满，估计这mac系统也有问题，mmp…
解决方案
到了这里，大概可以确定问题就出现在数据到达电视的“最后一公里”——接入网络的介质——上了。
本来是想着换一个牛批一点的路由器比如华硕AC86U或者小米AX3600这种以通过高功率wifi信号传输更大的带宽稳定性到电视。但是经过仔细分析，K2P原先号称千元最强不仅仅是因为它性价比、0元薅、全千兆，更是因为K2P的wifi信号的强大。有大佬拆机分析之后发现，K2P的硬件系统，对2.4G和5G wifi模块都有各自独立的功放，我的一个朋友甚至说在一楼都能收到K2P在6楼发出的信号，连上之后还能上网，不可谓牛哉。所以，在当下有如此强大的无线信号下，还是有这样的问题，那么通过更换路由器来改善网络的程度是非常不确定的。
放弃了走无线的思路后，我把目光转向了有线连接。但是再来看看这个难顶的网络拓扑结构和户型图：
在这样的户型结构下，光猫啥的还可以放在电视柜后面或者弱电箱中，而想要把K2P挪到客厅几乎是不可能的，因为客厅还有猫（真·猫，一只豹猫，一只橘猫，一只英短），把路由器搞挂了那就是真的挂了，毕竟影响到全家的上网。
那么现在只能寄希望于光猫。光猫除了一个千兆（LAN）口桥接给到K2P做PPPoE之外，还有三个百兆口。其中一个绑定了IPTV的vlan没法改（也不是没法改，就是怕改了出问题），剩下两个可以用于光猫的LAN区域。
电视接入光猫剩余的两个网口，此时对于光猫的LAN端和K2P的WAN端以及电视的网口之间，组成了一个无外网权限，也无K2P内网权限的局域网，或者可以说是城域网（MAN）。以下是对MAN城域网的一些定义：
wikipedia
都会网域（Metropolitan Area Network，MAN）指大型的计算机网络，属于IEEE802.6标准，是介于LAN和WAN之间能传输语音与资料的公用网络。MAN是改进LAN（局域网）中的传输介质，扩大局域网的范围，达到包含一个大学校园、城市或都会区。它是较大型的局域网，需要的成本较高，但可以提供更快的传输速率。例如：某一家企业把在一个城市或同一国家内的服务据点连接起来，就可以称为一个或多个城域网。一些常用于城市区网的技术包括：以太网（10Gbps/100Gbps）、WiMAX（全球互通微波访问）。PPPoE协议和MAN访问 这个是什么东西? - 恩山
BYFAN:man是一个网络工程术语，全称是Metropolitan Area Network，意思是城域网，指大型的计算机网络，属于IEEE802.6标准，是介于LAN和WAN之间能传输语音与数据的公用网络。
光猫会给你分配一个光猫的IP，然后你的路由PPPOE拨号会拿到运营商给你的外网IP
man网关是光猫分配的地址。
在组成WAN和LAN之间的中间网络MAN城域网之后，此时就形成了同网段下，电视需要使用K2P做网关，也就是熟知的旁路由场景，但是这个旁路由又有那么点不一样。
既然说这个旁路由不那么一样，那它究竟不一样在哪里呢？
传统旁路由并非是接入广域网的最后一关，而是旁路由自身还有一个指向的网关，用于旁路由的流量的下一跳，而旁路由自己则负责同网段内其他设备流量的加密解密以及各种转发策略等。
- K2P要充当拨号上网的总网关来代理它自己LAN端的流量上网。
- K2P要参与MAN端的组网，充当MAN端的旁路由代理电视流量上网以及访问K2P的LAN端设备（NAS）。
所以说K2P一个设备既要做流量出口，又要做旁路由，这就给K2P的配置带来了一些纠结。K2P在刷了Padavan后，是有做AP的功能的，也就是可以在这个模式下用于做旁路由，但又要K2P运行pppd来拨号上网，那么又需要它运行在网关模式下。
本着优先不影响环境上网的原则，K2P是肯定要配置在网关模式下拨号上网的。基于这个原则，就开始折腾了。
配置思路&方法
注：以下提及的MAN、WAN、LAN都是从K2P的角度来讨论的。
MAN端需要访问LAN端
需求：
MAN端需要访问LAN端设备。
MAN端网段为192.168.1.0/24，而LAN端网段为192.168.2.0/24，需要满足192.168.1.4/24之间192.168.2.65/24互访。
思路：
实现电视可以访问NAS，总体思路就无非以下几点，电视访问NAS的请求可以正确到达K2P，而K2P又能正确转发请求到NAS，并且反向可通。
其一，请求可达网关。这一点由于电视和K2P都属于MAN网段，即同一个广播域，电视发出的请求自然可以到达K2P，但是为了不被光猫转发到它的外部（因为我们不知道光猫外部的网络环境是什么样的），则需要手动指派发往LAN端的流量到K2P，也就是配置一个静态路由。
其二，K2P能够转发MAN端的流量到LAN端。这一点则需要手动放通防火墙规则，因为在默认情况下，路由器固件编写者是不会放通MAN到LAN的转发的，这样的场景实在是少之又少。而我们做的放通，也并非是完全放通，而是仅针对MAN端地址进行放通，因为我们不知道运营商PPPoE给到K2P的网段中是否有图谋不轨的人，对同网段进行端口扫描或者网络扫描等不良行为。毕竟安全大过天。
配置步骤：
光猫配置静态路由将MAN端（192.168.1.0/24）中目的地址为LAN端（192.168.2.0/24）的流量定向转发到K2P。
- 使用光猫的运营商管理员账号登录光猫后台，像电信的运营商管理员账号为
telecomadmin，密码或者其他的运营商可以去网上搜索。- 进入用户侧网络配置 - 静态路由配置
- 添加静态路由：
目的地址 下一跳地址 网络接口 192.168.2.65/24
（NAS）192.168.1.2/24
（K2P）LAN
（这里的LAN代表光猫的LAN，就是K2P的MAN）192.168.2.1/24
（K2P - LAN IP）192.168.1.2/24
（K2P - MAN IP）LAN
配置K2P开放MAN端到LAN端流量的转发
在Padavan的自定义设置 - 脚本配置中 -
在防火墙规则启动后执行:中添加以下iptables规则：
1 | ## 放通FORWARD放通K2P的流量转发，可让电视访问nas |
代理MAN端设备上网
需求：
K2P要代理MAN端设备上网。
MAN端设备需要配置网关和DNS为K2P地址。
思路：
基于这个需求，可以看出MAN端设备的请求不仅需要能够被K2P转发，还需要能够进入K2P。为什么要进入K2P呢？因为：
- 需要使用K2P作DNS服务器，也就是请求K2P本身的服务。
- 需要通过K2P代理上网。
这里明确一下，请求被转发和被代理是不同的概念，转发是将请求报文原封不动地再发出去，而代理则是将请求报文中的源地址从原来真实的地址换成自身的地址之后，再发出去，以起到“代理”的作用。
这里的能够进入，指的就是请求进到K2P中，被K2P接收之后处理完成后再发出去。在这个场景中就是我们常说的NAT——网络地址转换——也是一种代理方式。
明确了以上的定义之后，也就明确了，为什么需要满足流量可以进入K2P了。
配置步骤：
有了上面光猫的配置之后，我们就只需要配置电视和K2P即可。
电视配置以下网络参数：
键 值 IP 192.168.1.4 掩码 255.255.255.0 网关 192.168.2.1
或者是
192.168.1.2DNS 192.168.2.1
K2P还是在Padavan的自定义设置 - 脚本配置中 - 在防火墙规则启动后执行:中添加以下iptables规则：
1 | ## 放通INPUT 和OUTPUT 可以让MAN端的电视访问K2P做DNS代理 |
至此，已经全部实现MAN端的电视可以访问LAN端的NAS以及通过K2P代理上网了。并且访问NAS播放蓝光原盘也可以没有卡顿得播放了。所以说这一套操作还是对了的。
后记&展望
需求被满足了，但是新的需求永远都会产生。例如如果说我以后需要在K2P的LAN端网络中添加一个旁路由用于代理全网流量出国留学，那么就只需要配置电视的网关为旁路由的IP即可，而不是需要配置更多的参数。
所以说这一套方案实际上是已经考虑到了未来的拓展性的。
而另外一个因素，还记得前面说的电视通过wifi进行广域网测速可以跑到20M/S吧？20MB/S，也就是200Mbps（二百兆比特每秒）而接入光猫的接口只有100Mbps（百兆比特每秒），带宽整整小了一半。但是文件播放的顺畅程度却提高了，所以可以断言，影响NAS上文件的播放的因素不仅仅只是带宽，更多的可能是时延和抖动。
如果我采取了将K2P挪到客厅，将电视连接到K2P的LAN端的方案，将来添加旁路由的时候又需要在K2P上插一个设备，而在宠物猫眼底下多添加一个设备就是多一份危险。当然，除去使用交换机的场景（我认为家里的网络设备规模还打不到使用交换机的地步哈哈哈）。
如果有大佬朋友也有这样的需求，又正好看到了我的这个记录，那么在看到有纰漏的地方，请指出，感谢！
