程序猿家的 skr 家庭组网

人设背景

作者帝都 IT 民工，对技术抱有极高的兴趣。房子是三居，刚装修不久，性冷淡风格系。虽然作者是 IT 民工，但对于家装，把自己家里装得像个科技馆一样，这是不能接受的，所以，所有复杂的设计全部应该隐藏在背后，对外表现是简单的风格。

此文中的方案是作者对已实现场景的记录，全都是干货，但设计略为复杂，甚至粗略看，有些设计是“画蛇添足”，当然每一个看起来“画蛇添足”之处都有作者的用意，可能需要一定的基础知识作为背景。

另外，作为 IT 民工，每个人或多或少都有 “Python是世界上最好的语言” 这种情节，作者意图不是试图改变某某固件粉丝的想法，所以也会自动忽略 “一个 K2P 解决全部问题” 之类评论。

总体设计

先不解释这个图，先简要提下这个设计实现的独特设计点：
1、速度更快的 Internet 接入方案，具体查看 “Internet接入” 部分。
2、速度更快的 VPN 访问方案，具体查看“公司 VPN 接入”部分。
3、无限扩展终端的 IPTV 方案，具体查看 “IPTV 接入”部分。
4、千兆级的 QoS 方案，具体查看 “QoS” 部分。

在这之前，先简单介绍一下这个图中的核心设备，从上往下：

MA5671

光猫。原来电信送的是 SA1456C。用 iperf 测试，MA5671比SA1456C 的桥接性能（交换机的性能）要好，MA5671 的千兆网口基本能达到 950M-1000M，而 SA1456C 只有600M 左右，如果网口做了 VLAN 绑定，千兆网口桥接性能只有 400M 左右。

VLAN Switch

国产杂牌 8 口 VLAN 交换机，售价大概 140 元左右，他的作用是扩展路由器的 WAN 口，因为下面出场的 UBNT USG 只有两个 WAN 口，如果需要使用更多的 WAN 口就要在路由的 WAN 口上划分 VLAN，然后再用 VLAN 交换机扩展路由的 WAN 口（2WAN 扩展为 6WAN）。对这个 VLAN 交换机的功能不要求太多，能对网口设置 VLAN 即可，国产VLAN 交换机一般使用 RTK 芯片，性能还过得去，VLAN 交换速度近 1000M 没问题。

UBNT USG

网关

主角之一，具体参数网上有很多介绍，这里就不贴了，这里选择他的原因主要是：

1、性价比不错，750元左右，具有百万小包转发率（1Mpps），普通路由器不到100Kpps。
2、UniFi 全家桶核心成员，统一管理设备和客户端。
当然，这个路由器的缺点也很明显：
1、CPU 性能低，500Mhz，只有开启 了Hardware NAT（UBNT 称之为 offload）才能到1Mpps 转发率，如果靠 CPU 转发，性能连 100 块的路由都比不上。所以，想在 USG 上跑个第三方软件，尝试一下就行了。
2、QoS 功能和 Hardware NAT 冲突，如果启动 QoS，那就得靠 CPU 转发数据包了，性能参见第一条。
所以，本方案既然使用了 USG，那就得针对这两缺点，通过额外的设计方案来补充，才能形成一个整体方案。

X86-J1900

隐藏的第二网关，他的出现是因为 USG 的 CPU 性能太低，所以一些需要 CPU 完成的任务就通过 X86-J1900 来完成，X86-J1900 价格大约在 700-800 元左右，整机功耗约 10W。设个方案使用 X86-J1900 是因为在 X86 架构在计算，尤其加密解密等运算方面，和ARM/MIPS架构对比，简直就是秒杀。用数据表达就是， aes256-gcm、chacha20-ietf-poly1305 等加密算法，高端的 ARM 路由（价格大于 2000 元），大约能跑到 50-60M/s 的吞吐量，而 X86-J1900 轻松 200M/s 以上（ USG 的 MIPS CPU，实测 20M/s左右），所以，X86-J1900，承担了整个方案中所有需要 CPU 参与的工作。对于客户端来说，X86-J1900 是透明的，客户端看到的只有一个网关，即 USG，是感觉不到 X86-J1900 作为第二网关存在的，所以叫隐藏的第二网关。

UBNT US-8-60W
  

PoE 交换机，UniFi 核心成员之一。作用：核心交换机；为 AP 供电。

这个设备有太多的介绍，不多说了。这里主要提一下我选这个设备的原因：性价比高。当然，我知道，某某 Link 一个 PoE+ 的交换机也就这个交换机的 1/3 价钱，如果是国产杂牌PoE交换机，还会更便宜。何来性价比？其实 US-8-60W 这个交换机是支持三层 QoS的，当然官方并没有明确支持这个功能，需要 ssh 到交换机上，然后根据 EdgeSwitch 的CLI 命令来配置，虽然很麻烦，但终归是能实现，这个交换机很好的弥补的 USG 不能开QoS 的缺点。后文为会有 QoS 的设计说明，主要是这个设备来完成。所以，你想限制一下玩客云，或者想让 FaceTime 不卡顿，都是可以通过这个交换机来实现的，而同等功能的交换机，思科大概在 5000 左右，Netgare 大概在 3000 左右，所以，这个交换机 700-800 元是极具性价比的。

UAP-AC-IW、UAP-AC-Lite

这两设备 UBNT 876M 的 AP 产品，UAP-AC-IW 带有两个支持 VLAN 的网口，网上有太多介绍了，不多说了。

Raspberry Pi

UniFi 云端管理，和 UBNT UCCK 一样的功能，但比较便宜，还可以当作智能家庭的中枢。

核心的设备就这么多了，剩下都是客户端设备：比如 IPTV 盒子，NAS，PS4 等等，不做介绍了。

Zone区域设计

上部为 WAN 域，下面为 LAN 域，每个小域以 VLAN 隔离，承担的功能都不同。
WAN域：
1、PPPoE(s)Zone：Internet 连入，所有访问 Internet 的流量都要进入这个 Zone。
2、IPTV_WAN：所有 IPTV 的流量都要进入这个 Zone。
3、Company VPN Zone：所有访问公司的流量都要被路由到这个 Zone
4、AD Block Sites Zone：部分特定的网站（比如：youku.com）的流量要被路由到这Zone，去除广告。

5、Admin_WAN Zone：访问 WAN 域的设备管理流量，比如访问光猫的管理 WEB 的流量，都会被路由到这个 Zone。

LAN域：
1、Family Zone：LAN 的核心域，几乎所有家庭的客户端、智能设备都在这个区域。
2、IPTV_LAN Zone：IPTV 盒子单独划分了一个域，用来阻隔组播的风暴。
3、Guest Zone：访客网络，只能访问 Internet，不能访问其他域。

WAN域设计

1、Internet 接入 / PPPoE(s) Zone 的实现 

这里采用了多拨的方案，这个方案与常见的方案有两点不同：
1、在 USG 的 WAN口上划分了VLAN
每个 VLAN 里面绑定 PPPoE，这种设计是 USG 的特性决定了，因为 USG，在 VLAN、PPPoE、NAT 等功能上是有硬模块（Offload），划分 VLAN，然后在每个 VLAN 里生成了一个 MAC 地址进行 PPPoE 拨号，这个效率是最快的。
2、在 USG 和光猫之间用了一个 VLAN 交换机
其实最开始并没有使用VLAN交换机，而是直接在光猫上设置了 VLAN 绑定，光猫可以直接接收 VLAN 数据包，但最后实测，光猫接收 VLAN 的速度并不高，在电信送的SA1456C 上实测，做了 VLAN 绑定后，交换（桥接）速度只有 400M/s 左右，所以，增加了一个 VLAN 交换机。这样的好处是，光猫不用超级管理账号，不用改设置，另外，VLAN Switch的 VLAN Tag 操作效率非常高，950M-1000M/s 的线性速度，妥妥的。

这个方案的特点
一个字，快！真的很快！
作者的宽带单拨是 100M下行 4M 上行，用 SpeedTest 测速大概能测到 140M 下行 4M 上行左右，运营商给了较多的下行余量。
用 USG 多拨，负载均衡后，最后实测的带宽结果如下：
SpeedTest 测速
看结果之前，先解释一下，SpeedTest 的测试结果和后面从其他几个方面测试的结果有比较大的差异。其实，SpeedTest 并不能准确测出多拨的叠加带宽总和，原因是 SpeedTest后台大约发起 6 个连接测速（Chrome 的开发工具可以看到，但有时是 4 个连接），这种情况下，如果 6 个连接正好随机分配到了6个不同PPPoE出去，那测出的速度是 6 个 PPPoE带宽总和，这是准确的，但如果有 2 个连接被分配到了同一个PPPoE上，那测出的速度是 5 个 PPPoE 带宽的总和，依次类推，所以，SpeedTest 在多拨的场景中测速，每次结果差异都很大，6 个连接要正好随机分配到 6 个不同的 PPPoE，这种概率很小。所以，下图测速只能做参考，真实叠加带宽比这个数值要大。

USG 的管理端，迅雷全速下载时，UniFi Controller 中显示吞吐量为 844Mbps：

迅雷全速下载时，Windows 任务管理器中，网卡显示的带宽主要在 600-800Mbps 区间浮动

迅雷全速下载速度总和，在 80-90MB/S 波动：

当然这个方案的缺点是：
1、实现比较复杂，USG 的 WEB 功能并不支持上述功能，需要 SSH 到 USG 上以及配合json 文件，自己写配置来实现。
2、多拨受运营商限制，并不是每个地区都能多拨，或者多拨后带宽增加。

IPTV 接入设计 /IPTV_WAN ZONE 和 IPTV_LAN ZONE 的实现
IPTV 服务的总体设计如下图：

上图，设计时主要考虑两点需求：
1、IPTV 盒子不能直接连接光猫，只能放到 USG 路由的后面（客厅只有一跟网线的场景）；
2、能扩展 IPTV 终端，在其他设备上观看 IPTV 直播。
上图比较复杂，用一个简化版的图来描述过程如下：

首先，USG “冒充 ”IPTV 盒子认证。USG 克隆 IPTV 盒子的信息通过认证以后，接入运营商的 IPTV 专有网络。本地运营商对 IPTV 盒子采取的 DHCP 认证，也就是 IPOE 认证，根据抓包分析，运营商根据 IPTV 盒子的 MAC 地址、HostName、Vendor来认证。

然后，USG 为 IPTV 盒子创建一个 IPTV_LAN Zone，即 VLAN 2，并在 VLAN 2上“冒充”运营商网关为 IPTV 盒子分配一个内网 IP，比如192.168.5.2/24。根据抓包分析，本地运营商下发 IP 时并没有特殊的信息，不像上海，网关在下发 IP 时会带着 option125 信息，IPTV 盒子会认证这个 option125。

接着，在 USG 上，利用策略路由，把所有来自 VLAN2 的请求，即 192.168.5.0/24网段的流量，NAT 转发到 IPTV_WAN Zone（VLAN 13）网关，这样， IPTV 盒子与服务器的认证交互、点播业务、回看都能正常使用了。

最后，在 USG 中用 IGMP Proxy 把 IPTV_WAN Zone（VLAN 13）的组播数据，代理到IPTV_LAN Zone（VLAN 2），这样 IPTV 盒子直播也能正常使用了。

上面图中特意忽略了一个核心设备，UAP-UAP-IW，这里补上：
   

UAP-AC-IW 可以理解为一个 VLAN 交换机+AP的合体，这个设备装在客厅电视机附近的86盒里，有效解决客厅只有一根网线的场景，背面网口连接对应上图的 VLAN Trunk，左边的网口划分为 VLAN2 接 IPTV 盒子（IPTV_LAN Zone，充满组播数据流一个 Zone）；右边网口划分为 VLAN1 接其他内网设备（Family Zone），该设备还有AP的功能。

接下来，要解决另外一个问题，因为运营商只送了一个 IPTV 盒子，如果想在第二台电视上观看 IPTV 直播还需要进一步设计方案。比较简单的方案（最开始用的这个方案），在 USG 上用 IGMP Proxy 把组播复制到小米盒子所在 Family Zone（VLAN 1），小米盒子上安装 Kodi，Kodi 是可以接收组播视频流的，但这个方案会让 Family Zone（VLAN 1）中充满组播风暴，降低整个 Family Zone 的效率。所以，这个方案被放弃了，最后实现的方案如上图 X86-J1900 的部分。X86-J1900 同时接入 IPTV_LAN Zone（VLAN 2）和Family Zone（VLAN 1），在上文中 IPTV_LAN Zone(VLAN 2) 已经是一个组播视频流的域，所以，X86 在 IPTV_LAN Zone（VLAN2）上可以直接接收组播视频流，然后用udpxy 把组播流转化成 HTTP 点播流，在 Family Zone（VLAN1）上提供点播服务，这样就变成单播了，避免了 Family Zone（VLAN1）的组播风暴。

最后实施效果如下，IPTV 盒子分配到的是一个自己规划的内网 IP，IPTV 盒子通过路由器连入IPTV专网（不占 Internet 带宽），所有业务都正常使用：

电脑 VLC 通过 HTTP 点播流收看 IPTV 直播：

iPad 装上 VLC 也可以光看 IPTV 直播。

同样，小米盒子装上 Kod i能观看 IPTV 直播（盒子截图导出来麻烦，就不上图了）。

总结一下，这个 IPTV 方案的优点是：
1、解决了客厅只有一根网线的场景 2、光猫不需要超级管理员账号，原来 IPTV 盒子接光猫 iTV 的网口，现在还是接 iTV 口，不需要设置光猫。
3、在 LAN 侧划分了一个 IPTV Zone(VLAN 2) 给 IPTV 盒子，有效的把组播控制在这个范围里面。
4、解决第二台电视和其他设备观看 IPTV 直播的需求。
5、无限扩展 IPTV 终端。运营商网关并不知道，接入 IPTV 专用网络的交互对象是一个路由器（因为克隆了 IPTV 盒子的信息），所以，在路由器背后可以任意增加IPTV客户端，如上文提到的 X86-J1900，其实就是一个 IPTV 客户端（接收组播视频流）。。
6、在内网核心域，即 Family Zone 中以单播的方式提供 IPTV 直播服务，既满足了 IPTV直播观看的需求，又能保证 Family Zone 的整体效率。

缺点：
1、其他设备只能看直播，回看和点播只能在 IPTV 盒子中。点播业务 IPTV 盒子需要向网关 HTTPS 登录。
2、实现较为复杂，以上所有的配置，USG 都不能通过 WEB 完成，手工写配置写死人！
3、公司 VPN 接入实现 /Company VPN Zone

上图说明了 Company VPN Zone 的实现方式，但便于阐述具体过程，所以，上图按照数据流的流向做了稍许变化，如下图：

1、首先客户端访问公司的地址，以 apple.com 为例。
2、在 USG 上，定义了一个公司地址范围，apple.com 位于这个范围中，因此被策略路由发送到 VLAN20 的next hop，即 X86-J1900。
3、X86-J1900 上部署了公司 VPN 客户端，把来至于 VLAN20 的流量全部转发到 VPN Tunnel，而公司 VPN 客户端连入 Internet 的方式是通过 USG，所以，X86 的 VPN 流量通过 LAN 再一次回到 USG。
4、这一次 USG 会把 VPN 客户端的流量当作正常流量发送到 Internet。

这个方案的特点是：
1、利用了 X86 架构的高性能运算能力。
2、USG 的 NAT、交换机的转发都是线性速度，虽然数据流来回转了很多次，对延迟并没影响。
3、客户端透明，无需额外设置，而且客户端并不知道 apple.com 的流量被 USG 路由到了 X86 去处理，客户端无需任何操作。

4、速度很快，真的、真的很快。

测速结果：
通过接入公司 VPN 网络（加密方式 AES256-GCM），SpeedTest 的测速能达到200+M/s：

另外从上图可以看出，虽然数据流在各个设备来来回回好几次，ping 延时并没有受到影响，公司接入服务器位于香港，直连 ping 值也在 50ms 左右波动。

视频网站测速，5K 视频，如下图：

该方案的缺点：
实现较为复杂，以上所有的配置，USG 都不能通过 WEB 完成，手工写配置写死人！（后面这个点不说了，下文中几乎所有的实现都要手工配置）

广告服务设计/AD Block Sites Zone 

上图说明了 AD Block Sites Zone 的实现方式，和 Company VPN Zone 类似，其数据流向如下：

上图过程和 Company VPN Zone 的数据流向极为相似，不再复述，这里阐述一下和其他去广告方案设计的比较：
1、与屏蔽广告 dns 的方案相比，比如：利用 dnsmasq 把广告的 dns 解析到一个不存在的ip，或者干脆直接使用 pi hole 作为 dns server。此方案中的 adbyby 和 koolproxy 可以自动更新去广告的规则，自动调整 WEB 页面，把屏蔽的广告部位清除，不会出现满屏的 404错误，对广告去除比较精准。
2、与直接在路由器上运行 adbyby/koolproxy 方案比较，此方案中，利用策略路由在 USG中进行一次筛选，只把少部分需要去广告网站的流量路由到 X86，大大减轻 X86 的压力。同时，adbyby/koolproxy 是两款比较占系统资源的应用，在 X86 上运行的效率比ARM/MPIS 其他架构效率要高很多。
3、客户端透明，客户端不需要额外设置，而且客户端并不知道是 X86 完成了去广告的处理过程。

WAN_ADMIN ZONE/WAN管理域区

这个 Zone 的设计主要是能够满足为与 LAN 的客户端能够对 WAN 的设备进行维护（光猫、VLAN 交换机）。

LAN 域设计

1、LAN的总体规划
核心成员，Unifi全家桶，前面已经出场过了

UniFi  Controller 部署在 Raspberry Pi 上，为什么选 Raspberry Pi，因为便宜。一共四个AP，两个卧室各一个 UAP-AC-LITE，书房和客厅有网口的需求，所以用的是 UAP-AC-IW。

整个内网划分了三个 Zone（VLANs）

IPTV_LAN，前文 IPTV 部分已经介绍过了，IPTV 盒子所在的 Zone。

Guest Zone 是访客网络，这个 Zone 是只能访问 Internet，不能访问其他 Zone。

Family Zone 就是内网核心 Zone，所有的内网设备都在这个 Zone 里面，按照完美的角度来说，这个 Zone 其实还可以进一步分成 Admin Zone 和 User Zone，把设备的管理都放到Admin Zone 里面，普通用户在User Zone里面，但是，懒，就这样了。

2、AP 布置
四个 AP 分布和网关分布如下：

由于受到装修时布线所限，就这样了。另外，由于高密度部署 AP，所以 AP 的摆放不是依照信号为原则，每个房间一个 AP，避免金属物遮挡，怎么摆其实信号都差不多，所以，AP 布局主要是以美观为主，其实就是怎么能把AP藏起来。最后呈现的效果，几乎没有客人能发现家里无线在哪。

网关、交换机、X86 网关的安置

不要误会放错照片了，哪来莫名奇妙的一个鞋柜，因为没有办法接受在家弄上一个机柜，和装修太不搭了，所以用了一个鞋柜，挡在弱电箱前面。

鞋柜后面的弱电箱，比较小，只能放上交换机，线比较乱，反正看不到。

鞋柜里面的网关。

客厅的 AP

全部的 AP 采用了隐藏设计，上图你能找到 AP 在哪吗？

上图，缩小一下范围，在电视左下角。

答案是：柜子后面，给个特写，UAP-AC-IW。

卧室的 AP

你能找到 AP 在哪吗？

答案：在窗帘后面，墙装的。

书房的 AP

书房的 AP 在书桌下面，UAP-AC-IW 和插线板放一块，没图，忘拍了。

虽然 AP 有遮挡，但信号总的来说，还过得去。

3、无线频率规划
没什么好规划的，两个离得近的 AP 用频率离得远的 Channel 就好了。

4、无线 SSID 规划

无线 SSID 规划的原则是 2G 和 5G 的 SSID 分开。其实，UBNT 是支持 2G 和 5G 使用同一个 SSID，AP 引导 5G 终端连到 5G 上，但实际测速过程中，部分智能 2G 终端对这种技术支持并不好，所以，让 2G 和 5G 使用不同的 SSID。智能设备全部在2G，而手机、平板、笔记本连5G，并可以漫游。

5、QoS 设计
前文提到过 USG 的 QoS 功能和 HWNAT（Offload）是冲突的，一打开 QoS，USG 的转发速度能从 800M/s 掉到 5M/s，是的 5M/s，你没有看错，用了多拨以后，USG 的 CPU 就只有 5M/s 的转发能力，5M/s 不能再多了。
家里有一个玩客云，（后来在高价的时候被我卖了），如果不限制他，他的上传速度能上天，但又不能一刀切，毕竟在闲时，还可以补贴一些电费，所以，QoS 必须的。

最后，这个 QoS 的任务落到了UniFi 全家桶核心成员之一 US-8-60W 交换机（USW）上。
如下图（以数据流出站方向看）：

这个方案是把 QoS 设置在交换机的uplink端口上，uplink 的上级是 USG，
数据包到达交换机后，交换机根据 IP，MAC 地址、DSCP 值来进行队列排序，让优先级高的数据先从 uplink 出去，先达到 USG 路由被处理，这样 USG 不用开 QoS，也可以保证高优先级的业务。
对于电脑这种多业务的终端，只能利用操作系统的 DSCP 功能，让操作系统把迅雷这个进程产生的流量打上一个较低的 DSCP 值，让IE的流量打上较高的 DSCP 值，数据包到达交换机后，交换机直接信任这个 IP 的 DSCP 值，这里，举一个不信任的例子，比如玩客云，就算玩客云把自己的流量 DSCP 值设置很高，交换机直接忽略，只要是这个 IP 的流量都被重新赋予一个较低的 DSCP 值，然后，交换机根据 DSCP 进行 QoS，迅雷的流量就被降权了，因此，边下载边看网页，网页也不会卡顿。

测试结果：

上图是没有应用 QoS 的场景，可以从右下角，迅雷，可以看到，目前速度 50MB/s，但ping 延时已经高达 557ms，整体网络效率变慢了。

上图是应用了 QoS 的结果，可以从右下角，迅雷，可以看到，目前下载速度已经近70MB/s，但ping 延时还是比较正常。

这个方案的优点：
1、初步解决了 UniFi 全家桶中主路由 USG 不能做 QoS 的缺陷（和 Hardware NAT 冲突）。
2、QoS 速度很快，交换机有 Hardware 做 QoS，速度是线性速度。
3、QoS 对玩客云、赚钱宝等业务效果比好，既不影响收益也不影响正常上网。
缺点是：
1、首先，US-8-60W，这个交换机只能在 ingress 上做 QoS，不支持在 egress 上做 QoS。所以，如果 0 口是 uplink，那 QoS 策略只能做在 1-7 口的 ingress 上。
2、对于整个架构来说，流量是针对 Internet 出站流量做 QoS。对于入站流量，这个方案的瓶颈在 USG，当数据包已经进入到交换机的 uplink 端口后，已经没有做入站流量 QoS 的必要了，交换机的交换速度没有性能瓶颈。只能在出站流量上做 QoS 的意思，并不是说出站流量的 QoS 解决不了问题，首先对于上传类业务，比如限制玩客云、赚钱宝，效果是100%，对于下载类，比如迅雷，如果一个迅雷下载的数据包 QoS 降权，以低优先级发出，对端服务器收到包的等待时间就会变长，应答的速率就会变慢，迅雷下载入站的流量就会降低，USG 就能够处理更多其他业务的入站流量，从而间接保障了其他业务的流畅（比如上图测试结果就取得了很好的效果）。后记：从作者后期使用的来看，如果迅雷的并发数特别多，尤其是同时下载 4-5 个任务，USG 的入站流量被大量迅雷下载流量占据，效果并不是特别明显，没有上图作者测试时的效果，这也是不直接做 ingress qos 的妥协。
3、官方主要是通过 UniFi Controller 管理交换机，并没有打算让 UniFi 交换机能够支持CLI手写配置。所以，这个 QoS 方案最严重的缺陷：目前手写的 CLI 配置生效没问题，但不能保存，用 write memory 完全没用，重启就没了！！！在全球论坛提过这个问题，官方的答复是，我们开放 CLI，并不是打算让你写配置的，主要是让你用 show xxxx 看看配置。
4、复杂，实现很复杂。

安全设计

证书服务

利用 Let's Encrypt 给 UniFi 颁发免费的证书，放在 Raspberry Pi 上可以到期自动续签，如下图， UniFi 使用了 SSL 证书，除此之外，还可以为 NAS 提供 SSL 证书。

Guest Portal
这个是 UniFi 自带的功能，可以用密码二次登录，很好解决了，访客不小心把密码分享到WIFI 万能钥匙的问题。这个安全功能是必须的，因为家里的智能设备比较多，一旦被别人连入 WIFI，后果太严重了。

智能家庭设计

这个是一个应用场景设计，也是最炫的一个设计，也是作者给客人得瑟最多的设： 
视频效果：（不会贴视频）v.youku.com/v_show/id_XMzcyNDIyNjEzMg