注意，此文档有时效性。

由于公司网络的关系，在线听音乐经常会被断断续续，于是考虑批量将音乐（高清）下载到本地。同时，由于熊孩子的缘故，在自己的音乐榜单上「小苹果」等歌曲一直在前排，显得很没有「格调」，于是就萌生了折腾云音乐接口的想法。

网易云音乐的接口相对而言还是比较简单，尤其是大部分前端与服务器端通信的逻辑都已经在 core.js 里面，虽然加了压缩但是没有混淆因此还是很好去处理和理解。

访问云音乐接口每次都需要带个名为 csrf_token 的 GET 参数，这个参数很好找就在 Cookie 里面，而且还是持久化的。

剩下的两个参数大部分都是 POST 过去，分别名为 params 和 encSecKey，里面的字符串经过 encodeURIComponent 处理过。

加密和解密的方法还是在 core.js 这个文件里面能够找到，AES CBC 加密，客户端自己生成 Pair 。两个加密解密的方法都暴露在全局作用域下，分别名为 window.asrsea 以及 window.ecnonasr 。

部分的接口，例如 feedback/weblog 是没有做任何重复请求处理的，换句话说可以刷。上面说到 csrf_token 其实是持久化的，也没有来源判断等，因此拿到 Cookie 以后就可以自己构造请求。

不过话说回来网易的平台设置做得的确财大气粗，乃至多点并发去做请求都能撑得下来（估计是我的小水管还不够人家的零头）。

顺便提一句，再深入研究下其实可以发现非会员也可以下载收费资源，这里不铺开讲了。

总结下一些看起来是「大道理」的心得：

1. csrf_token 这些参数应该和时间和请求次数挂钩，更不应该加入到 Cookie 里；
2. 客户端和服务器端的加密一直是安全方面讨论的主要课题，我的倾向是轻客户端重服务器端，不要把所有的逻辑都写在客户端中；
3. 前端脚本代码的打包方面尽可能的不要污染全局空间，尤其是框架方面的代码；
4. 服务器端应该对用户异常行为作出判断，例如业务方面用户频繁下载以及标记打星是否合理；
5. PS，网易云音乐考虑下 WebSocket？
6. 查找和 Hook 网络接口这块可以从请求方法入手，通常现在端架方面请求都会放在一个方法中处理；
7. 有点废话，抓取的时候使用 HTTP Keep-Alive 头能够明显的加快请求速度；
8. 可以考虑多个 IP （代理）去抓取数据，以免实际地址被服务器 Block；
9. 实际情况中需要考虑的外部因素有很多，例如尽可能的在预算范围内购买足量的存储空间…；
10. Charles 很好用，这钱花得值…

-- EOF --

自从多年前开始使用 NAS 存储和备份数据，就慢慢得养成了习惯越来越离不开它了。我使用的是群晖低端的 212J，由于仅仅是备份数据没有离线下载等需求，使用至今都没有出现过性能方面的顾虑。

这次考虑折腾 NAS 是从一开始升级硬盘说起。

选择硬盘

因为预算的问题，一直没有购买新的硬盘，使用的是原先移动硬盘拆下来的两块 320g 笔记本硬盘。

时光推进， 320g 的容量越来越明显感觉到捉襟见肘，加上原有的硬盘使用时间也比较长（从 09 年至今），因此更换硬盘的想法就提上了心头。

根据目前的行情，还是考虑购买了两个不同品牌的监控硬盘，分别是 希捷（Seagate）的 SV35 系列 和 西数（WD） 的 AV-GP 系列，容量都是 2T。

选择不同个品牌，是因为考虑同个品牌可能会同一个批次出现一样的问题。同时，不选择西数的红盘是因为 AV-GP 系列性价比稍微更高些而已（虽然只有 20 大洋）。

后记：新的硬盘安装进去以后，发现工作温度希捷的稍微比西数的要高些。不过两者硬盘性能似乎没有区别，组 Raid1 运行相互之间不会有谁拖谁的后腿之说。

硬件&改造

NAS 属于不折腾的那种硬件，稳定第一。但由于通常都是放在不起眼的地方，灰尘和散热都是我所担心的，毕竟宝贵的数据全部在这小东西的肚子里。

群晖 212J 的原有风扇是 Y.S.Tech 的，从购买至今使用起来一直都很勤勤恳恳，对它唯一诟病的地方就是声音和振动都有点大。思前想去，毕竟风扇是 NAS 唯一的主动散热设备，所以还是咬咬牙从淘宝上购买了 SANYO DENKI 的 9S 风扇（俗称「9S」）。

这个风扇相信玩家都会认识，无论从风噪还是可靠性来讲都比原先的风扇好太多（当然价格也是原有风扇的两倍）。

同时购买了快散热片加装到了原有主板的主控芯片上，其实这部没多大必要但装了也总比没有要好。

顺便给风扇加装了块滤尘网，同时在各个出风口上用双面胶粘贴了防尘垫，用于一般基本的防尘。最后，在安装硬盘的螺丝上加装了橡胶垫子，这里再次感谢下卖家的小心思，替我考虑得很周到。

经过这些步骤以后，重新合上盖子的时候感觉密封性更好了，希望能够使用得更久些。

迁移数据

恢复原有 Raid1 盘的内容并不轻松，我没有使用 Synology Hybrid RAID （幸好没用，这玩意很坑），原先认为使用 USB 硬盘盒接上即可读取，发现行不通。

搜索了下，后来才知道群晖的 Raid1 是 Raid1 。于是将原先 NAS 的其中一块硬盘挂在 Linux 下。

先安装必要的软件：

apt-get install mdadm lvm2

安装完成以后查看硬盘的分区

fdisk -l /dev/sdb

发现有几个分区块，先测试下最大得分区块

mdadm --examine /dev/sdb5

发现的确是软件 Raid1 分区，接下来映射成块设备

mdadm -A -R /dev/md9 /dev/sdb5

其实到达这一步，使用其他分区格式的可以直接使用 /dev/md9 设备 mount 到系统了，但是群晖使用了 LVM 分区，因此还需要多几个步骤。

vgscan && vgchange -ay vg1

激活逻辑卷，然后系统会提示你卷下有几个分区，然后用这些映射设备 mount 即可。

mount /dev/vg1/volume1 /media/hd

然后在 NAS 上开个 NFS 分区也一并 mount 过来就可以拷贝文件了。

后来发现有网友直接使用 NAS 的 Raid1 的恢复迁移数据，早知道这个方法会方便很多。

下面是些参考资料：

• https://en.wikipedia.org/wiki/Logical_Volume_Manager_(Linux)
• http://www.chiphell.com/forum.php?mod=viewthread&tid=708972
• http://www.linux-sxs.org/storage/fedora2ubuntu.html
• https://blog.sleeplessbeastie.eu/2012/05/08/how-to-mount-software-raid1-member-using-mdadm/
• http://serverfault.com/questions/451781/mounting-an-old-lvm-hard-drive-in-fedora-17-gives-error-message

Tips

差不多是最后了，数据方面的迁移和保存毕竟是很谨慎的事情，下面总结下小的 Tips 也算是经验总结了。

• 数据定期使用移动硬盘联机备份，虽然是 Raid1 但也不排除同时出问题的情况
• 关闭所有可以设置为自动更新的选项，其中包括系统、软件包等
• 硬件方面 NAS 最怕的还是散热和灰尘，当然还有电流
• 不要把 NAS 放在任何人员嘈杂的地方，有条件的还是将其放入深闺中吧

接下来考虑是否购入台 UPS 将 NAS 接入到不间断电源中，出于预算考虑估计还得缓缓 :^)

-- eof --

可能是由于夏天雨季雨水多的缘故，原车的倒车影像开始非常的模糊，然后有天就突然的不工作了。本着省钱的心理作怪，决定先自己拆开看看到底是什么问题。

拆开摄像头很简单，原先就是使用卡扣卡上去的，稍微将卡扣掰下摄像头就能扯出来了。然而，看见原车摄像头腐蚀的情况，看来更换是难免的了。

因为摄像头的布线是隐藏在车的保险杠中的，因此需要拆除车子的保险杠，于是这工程量就大上去了。好在两厢车的保险杠还算好拆，后备箱的工具也够用。

因为同时还有倒车雷达的布线，所以暂时将倒车雷达关闭布线用胶布缠绕起来。为了安全起见防止别人追尾，顺手加上了个告示（有人说这是「此地无银三百两」）。

过了几天，在万能的淘宝上拍到的新摄像头到了。考虑到晚上视线不好的缘故，特地买了升级版本带红外的。

为了防止以后类似情况的发生，因此给裸露金属以及接线的部分加注了玻璃胶。

原车的布线由于已经安装好，更换摄像头也就是更换原来的线头，因此干活的过程中就没有记录下来。

接头部分为了加固我采用了焊锡点焊，同时使用防水胶布缠绕的办法。

这是晚上使用红外线摄像头的效果，可以看见外部环境已经丝毫没有任何灯光了，但是倒车摄像头还是很清晰。

至于价格方面，红外摄像头比普通摄像头贵个几十元钱，但对于安全和效果而言还是值得的。

顺便顺手给另外一侧的牌照灯也换成了 LED 的，这样子更耐用一点。稍微有点不尽如人意的地方，就是 LED 晚上牌照灯似乎有点太亮。

总的来讲更换倒车影像摄像头难度并不高，但是需要卸下后保险杠是个脏活累活。下面列下需要用到的材料以及所购买的费用：

• 红外线摄像头 x1 168RMB
• LED 灯 x2 16RMB
• 防水绝缘胶布 x1 5RMB
• 线扎若干

- EOF -