分类： Record

写点见解之类的

SSL证书更换为Let’s Encrypt

　　StartSSL的免费证书总不太稳定，尤其在Chrome下表现更是离奇，这不最近在将macOS Chrome升级到最新版的时候，花图影铺的一个二级域名证书就被列为不信任了，但根域名又是正常的，而在火狐或Safari或iOS 10中都是正常的，真是莫名其妙。正好最近Let’s Encrypt比较火，干脆趁这个国庆节将证书换一下。

1. 下载安装证书

git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt/
./letsencrypt-auto certonly --standalone --email admin@snapast.com -d snapast.com -d www.snapast.com -d abc.snapast.com

　　这里Let’s Encrypt简化了安装步骤，只需要确保域名解析到本机服务器，并且未占用服务器的80和443端口即可创建成功，默认位置在/etc/letsencrypt/live/snapast.com里面，fullchain.pem即是公钥，包含证书链，privkey.pem私钥。

　　需要注意的是，有二级域名未解析到本机的不可以，比如使用了CDN，临时改一下问题不大，本机有nginx之类的占用80端口的，也得临时停一下，反正很快，网络好的情况下几秒钟就可以了。如果站点流量大到几分钟都不能停，那想必也没必要用Let’s Encrypt了，毕竟一次申请的有效期也才三个月。

2. nginx配置

ssl_certificate                 /etc/letsencrypt/live/snapast.com/fullchain.pem;
ssl_certificate_key             /etc/letsencrypt/live/snapast.com/privkey.pem;

　　配置好nginx，reload一下就生效了，CDN后台的证书也一并替换掉，大功告成。

初探麦理浩径

　　得知这条著名的徒步线路也有蛮多年了，依稀记得还是在一个人的Google Blog上得知，沿路风景独美，却一直没敢尝试。加之一直认为以人名命名的地方都是有故事的地方，必有其独特之处。时间一晃就到了现在，正逢离职之际，便有了此行。

　　早在半个月前已约好同事三人出行，结果各种临时情况未能凑到一起，加之立秋之后阵雨不断，实在不好计划，而签注也快到期，于是做了个比较激进的决定：独自出行。实际上我是比较偏向独自出行的，一来自由，二来可以更注重自己的感受，美景可以多逗留点时间。

img_3428

　　惯例先列出出行装备：背包 F-stop Lotus + Small Pro ICU 内胆包正好满足一机两镜，CPL及其支架等。佳能EOS 6D + EF1635，本来计划带EF70200，幸好没带，减重不少，其实后面一直下雨，单反就没拿出来了，全程手机拍照。零食，水就不用说了，放塑料袋捆好压在ICU上面妥妥的。下雨天山路必备的伞，拖鞋，趟水用。GPS记录仪，并非导航用，用于整理游记照片用。移动电源。湿纸巾，可湿水纸巾。防蚊水，没这个可不行。装备基本上就这些了。

　　行进轨迹规划：由于是走山路，分差多，难免迷路，提前规划好线路是很有必要的，借助Google Map可以轻松画出行走线路，标出沿途风景点，以免错过。在“您的地点”里面可以创建地图，顺便做好备用线路。下图是我画的麦理浩径一段与二段线路，中间那段是返回用的。在手机端同样地方打开这个地图，便可以实时导航了，即使走偏了也可以及时发现。地图可以导出为kmz，同步到一些带GPS地图的运动手表就更方便了。

轨迹图

　　一个人出行我一般优先选择公交通行，一来以更local的出行方式来体验香港，有路怒症的人真应该来学习下，香港是如何礼让与遵守规则的，二来节省费用。通关上地铁这些都没啥说的，但这里要提的是福田口岸中午12点前后是接送跨境就学儿童高峰期，这时候持本式通行证会排很长队，在这里被耽误了很长一段时间。上了东铁线到大学站，出来便是巴士站，附近有不少便利店，茶餐厅，可以解决一餐。找到807B小巴，坐到终点站黄竹湾，费用HK$8。走到马路对面的麦边站换乘94或96r到上窑，费用HK$6.4，这里便是麦理浩径一段的起点了。这里要说明的是等车时间也超级久，可能工作日时间开行班次不多吧，人也很少。

　　不幸的是坐过站了，忘了按铃提醒司机，不过也没事，再往前几个站到北潭凹，这里正好是第二段的终点，第三段的起点，从二段终点走向一段起点也是不错的选择。接下来就是漫漫山路，直到走到西湾附近有座必经的桥正好在维修，不让过，拖鞋就派上用场了，涉水而过，水不深。

　　走完二段到一二段分界点的时候已经6点多了，天色已晚，于是放弃一段，在吹筒凹交汇点开始返回，走到西湾亭就是行车路，夜间安全点，虽然也没路灯，漆黑一片。据说旅游高峰期这里也很多的士，方便回去，可惜当时整个山上都不见人别说车了，于是快步走到一段起点，看能不能等到公交车，中途试了下Uber，很明显没人接单的。走到公园管理处正好一辆的士停在边上，于是果断上了的士，半个小时就回到大学站了，一路上我说普通话，的士师傅说粤语，也聊的挺开心的，最后费用给了HK$120。

GPS轨迹

　　行山时间4个半小时，GPS显示15.5公里。一路上收集标距柱也是蛮有意思的，可惜只收集了M030～M048，每500米有一个标距柱，全程100公里，有200个。其实如果继续走完一段，也就再多5公里，体力还ok，带的东西也还够吃，就怕没车回来了，安全第一。

　　沿途照片：https://snapast.com/albums/steve/7eNNM5rqBJkpd2c9jovWeE

当开发时间被压缩后

　　记得有一部纪录片《人类消失后的世界》说的是当人类突然从地球消失后，过多少时间后会发生什么事，有兴趣的可以在网上找到视频。而在软件研发过程中压缩时间也会有很趣的事情发生，主要从技术角度来分析下。

　　前端：可能没办法适配非自己浏览器大小的尺寸，输入框的字数限制可能就没有了，校验也只剩必填。一些被设计为公用的枚举，样式，出现了差异，特殊化。页面整体风格和以前系统不一致。表单多列的可能就成了单列了。弹出/遮罩这些效果可能被其他组件遮盖掉。

　　后端：数据合法性校验可能没了，不注重设计模式，复用，耦合度高。控制器层多了业务逻辑，服务层被架空。数据库表设计可能会没有索引，甚至注释也没了。组合查询效率慢，批量操作变成循环实现，并发控制百分之百会被忽略。修改版本没有记录，日志乱输出或者没有日志，导致后期调试困难。接口文档更新不及时。

　　测试：之前整常的功能没有回归测试，没有压力测试。

　　最终这一切又要以bug形式花时间来修正。

魔界之地黑岩角

　　黑岩角位于深圳南澳镇最南端，当地人叫西尾，意思是西冲尾，一般人很少会去这里，大部分都是在西冲海滩玩。

　　计划来此也是有许久了，一来是这里号称深圳“魔界”之地，其独特的岩石，表面上看呈灰黑色，常年的海风腐蚀成如刀刃般锋利，很有层次感，也使得这里更具险峻，稍不留意可能伤到皮肤，这不脚上就被岩石划伤了，还好准备了创可贴。

　　早早在附近定好了民宿，和夜叔两人驱车来这里，由于两个人都不熟悉登山路线，车到酒店稍做休整后便出发先行踩点，以准备早上拍摄黑岩角日出，然而车到南西路尽头却发现是军事区，出于谨慎考虑，便没再前行。于是采取B方案，包快艇前去。

　　驱车进入西冲一号沙滩，和快艇租赁的人聊了几句，开始都说到不了，在他们看来黑岩角是位于牛奶排或者更远的地方，因为那边根本没办法让船靠岸。后来给他们看了网上的样片后，才明白原来就是在西尾，很多拍婚纱的也是租他们的快艇过去的。最后以200块的价格送我们两过去，实际上行驶时间也就5分钟不到。

　　上去后发现已经有不少摄影爱好者在上面了，这里可走动的面积也不多。询问得知他们都是山上爬下来的，抬头一看天啦，海拔大概也就100米样子，坡度几乎接近垂直于地面，没有任何扶手，下面还是坚硬的岩石，想想就觉得可怕了。不过看到陆续有人爬下来，何不挑战下。顺利爬到山顶观景平台，居然就是之前的军事区，和上面的人聊天得知，其实这一段是废弃了的。走出停车观景平台可以发现是两条路，一条是继续上山的军事区，而且也有自动门拦着的，而下山的路就是回到了南西路。

　　就当是交了200的学费。后来想想，其实不必这么拼，200还是很划得来的，可惜人家最早也要6点半才出海，我们要在5点之前赶到，乌漆麻黑的爬这个坡更危险了，还带着这么重的器材。

　　其实之前在网上也做了很多功课，却没人能说清楚究竟怎么去，这里我放上一张GPS线路图，供大伙参考。红圈是停车观景平台，车可以一直开到这上面，也可以露营。然后有石板路走到一个圆形的岗亭，之后就只能走泥地了，非常陡峭，下雨就不要尝试了，安全第一。

黑岩角GPS路径

　　黑岩角只能看到日出，太阳从山后面升起，并不是海平面，并且天亮的很快，这次准备的还不够充分。本次拍摄的一些照片：https://snapast.com/albums/steve/A1EDibze1nFPDMheBKM6Gh

一次DDOS攻击记录

　　就在昨天儿童节的时候，大概9点半左右收到微信公众号的报警信息，发现是服务器没有响应，5分钟内6次请求没有及时返回。当时并没有过多在意，因为之前也有过1~2次失败，都是是偶然因素。过了几分钟又收到dnspod的邮件报警，内容是snapast.com主站连接超时，这才意识到可能服务器宕机了。

　　立刻手动访问一次，果然是打不开了，ssh也连接不上，下意识认为可能是服务器被重启了，因为之前托管在linkcloud的时候，隔个把月总会挂掉一下，但迁移到阿里云后一直很稳定，不太会出问题。

　　登录到阿里云后台，在实例监控看到CPU一直满负荷运行，入网流量达到22M/s（云盾基础防护中显示有接近30M/s，忘了PPS多少来着），出网也已经塞满2M带宽。

实例监控

　　通过阿里的终端登录到主机上，发现CPU是被4个nginx进程占满，后端几个tomcat负载并不高，说明并不是一般的大规模http请求（cc攻击）。而且nginx access log也是正常，但error log有很多xxx worker_connections are not enough，说明确实连接数较高，超过设定值。通过netstat统计居然有1.6w左右的连接数，远高于平时的300左右。

root@snapast:~# netstat -an | wc -l
16089

　　到这里基本能判断极有可能是SYN Flood，想到云盾有一定抵抗DDOS的能力，试着开启流量清洗看看，原来人家的默认触发条件是流量100M/s，PPS是1w，我这点攻击还没办法触发呢，于是手动设置了一个最低条件达到10M/s就开始清洗，然而事实证明清洗毫无用处，依旧连接超时。但有个好处是开始清理后可以抓包。

　　下载cap到本地用Wireshark打开一看，好家伙，果然是SYN握手攻击，大量的不同IP（美国为主）往443端口发SYN请求，极少数有回应RST，我猜应该是上层路由回的。云盾的抓包并不是你主机网卡包，而是在接入口的设备上。这下明了了，对于这种TCP层的攻击也没啥好办法抵御的，考虑到目前仅有相册用了https，所以先停掉nginx监听443端口，将机器负载降了下来，但也没办法彻底解决。有意思的是当时阿里云解析也出了故障没办法修改域名解析，屋漏偏逢连夜雨。

抓包

　　就这么瞎折腾了2个小时，攻击才停止，一切也都恢复正常。今天来看，在微信接口调用统计中失败次数最为“壮观”的一天。

　　现在想想其实也有一些办法可以减小宕机损失：比如将受攻击的域名临时解析到别处。再如将多个业务分离开来，用不同的域名，不同的IP接入，iptables将多次密集连接请求的IP drop掉。