Giuem Blog RSS Feed

聊聊博客近期的更新

Sun, 29 Aug 2021 14:00:24 GMT

最近对博客进行了一次比较大的更新改版，距离上一次更新已经 4 年多了，那时还信誓旦旦的说会好好的写博客。结果如今 3 年过去了才写了 9 篇文章，18 年更新了 4 篇文章，19 年更新了 3 篇，20 年更新只更新了一篇。通过观察每年更新的数量不难发现规律，每次更新博客的主题总能刺激写作的欲望，随着时间推移写作的热情逐渐消耗殆尽。

嗯，看来是时候对博客进行一波重构，刺激一下创作的欲望了。

技术栈调整

博客框架

最早我的博客是运行在 WordPress 上的，但是发现我的博客本来更新的频率就不高，完全没必要使用动态博客引擎。那会应该是 15 年吧，静态站点生成器可以选择的并不多，只记得 Hexo 很多人在用，当时的一大趋势就是从 Jekyll 迁移到 Hexo、从动态博客迁移到静态博客。我就是在那时从 WordPress 迁移到 Hexo，并写下了第一款主题 giuem/hexo-theme-naive，这款主题也得到了很多人的喜欢（衍生版本有 300 多 star），后来因为我自己看腻了就重新写了一款主题：giuem/hexo-theme-iris。

在写主题的过程中就会发现，这些基于模板引擎的站点生成器，太过原始（仅个人观点），打包的方式是通过 gulp 甚至没有打包，工程化也很难做起来，每次模板间的引用传参、模板与 JavaScript 的交互都是两眼一抹黑，心里特没底，不知道到底有没有这个参数，各种优化手段（如资源预加载，Service Worker 等）需要靠非常人工的方式去维护。而且当初主题系统设计得特别 💩，只能通过拷贝文件夹的方式来安装主题（不过后面好像支持通过 NPM 方式安装了）。

这两年国外对于 JAMStack 这一概念炒得特别火，冒出了很多相关的站点生成器，Gatsby 就是其中人气较高的一款。

Gatsby 是基于 React/Webpack 技术栈的站点生成器，这意味着你能使用上丰富的 React 和 Webpack 生态，它本身也有非常强大的插件生态。同时一些前端工程化、组件化的方案也能直接拿来使用。Gatsby 还提供了很多开箱即用的优化手段，比如资源的 Preload/Prefetch、响应式图片、内联样式、首屏优化、module/nomodule polyfill 优化，资源拆分等等，默认状态下就能达到 95 分左右的性能体验。

说起 React 生态的站点生成器，Next.js 也是一个很好的选择，但之前在公司内有使用过（踩过坑）Gatsby 的经验，所以我的博客也就选择了 Gatsby。

Pnpm 与 Monorepo

这次还有一个比较大的调整就是使用了 Pnpm 作为 NPM 包管理工具，Pnpm Workspace 来管理组织代码仓库（Monorepo）。

Pnpm 即 performance npm，相比其他的包管理工具性能更好，使用 Webpack 那一套编译工具就意味着你要装一大堆相关的 NPM 包，使用 Pnpm 能在博客部署时提供更好的性能。实测在有缓存时，目前博客安装依赖（node_modules 体积 ~558M）的时间仅为 20 秒。

使用 Monorepo 的主要原因是当社区的插件不能满足需求时，想自己开发插件又不想发包或者不想每次手动的更新 package.json 和 lock 文件中的版本号时，可以通过 Monorepo 的方式把插件代码和博客的代码都放到一个代码仓库中维护，不通过发版就可以使用到最新的插件代码了。Monorepo 还有一个好处是所有的代码都共享一份最佳实践，代码规则的更新只需要修改一个 repo 就可以。

~~我的最终目标是：所有开源的代码都放到这一个仓库中进行维护。~~

样式

选择 React/Webpack 技术栈，可以选择的技术就很多了，像 PostCSS, CSS Modules, CSS in JS, utility-first CSS 等等。这几年 utility-first CSS 也是非常火；如果熟悉我博客风格，一定知道我的博客走的是性冷淡风格，注重排版和阅读体验，不会有太多花里胡哨的特效。这么一看 Utility-first CSS 就非常适合我的博客，之前简单统计过，博客主题中用的最多的 CSS 属性和特性是 color, font-size, margin, padding 和 flexbox。所以 Utility-first CSS 对于我完全足够了，不需要使用复杂的预处理器来编译 CSS，而且使用 Utility-first CSS 还有一个好处就是可以把数值都固定到可枚举的常量中，不会出现一个 margin 出现 1234567890 种不同的数值。

框架上选择了老大哥 Tailwind CSS，虽然最近又出了个 Windi CSS，号称编译的速度更快，但是我在尝试从 Tailwind 切换到 Windi 后发现 typography 插件存在一点 BUG，暂时还是先使用 Tailwind CSS。

杂项

这里是一些微小的改动，不适合单独拎出来介绍，但是我又觉得有必要讲一讲的

统计工具用回了 Google Analytics，ga-proxy 已经不再维护和提供服务了 😭
部署方式是 Cloudflare -> Vercel -> GitHub，Cloudflare 回源到 Vercel，GitHub 的更新会触发 Vercel 编译博客
由于有图片懒加载，暂时下掉了国内 CDN 节点，静态资源和图片全部走 Cloudflare CDN
暂时关闭了 Service Worker，目前发现 Service Worker 和深浅色主题切换有冲突，会出现 flash，等待排查

反向升级：减法

之前我的博客主题其实就已经做了很多减法，相比于市面上正常的博客，主要少了：

标签/分类
文章导航（上一页/下一页）

这版主题会进一步优化，删除更多的元素。

首先被我删除的是首页头图，这个头图其实和文章内容没有半毛钱关系，当时设计这个头图是作为点缀，为了让博客看起来不会那么单调。后面发现其实不要这个图片也是 OK 的，而且头图还会影响到首屏的加载性能。

首页文章的分页也被我删除了，通过统计数据发现后面的页面其实点击率很低，而且和归档页面在功能定位上存在冲突。试想一下，读者想翻看之前的文章，是一页页的查找更方便呢，还是一步到位在归档页面查看效率更高？答案显然是后者。所以我首页只保留了 6 篇最新的文章，增加一个按钮来链接到归档页面。

另外一个被我删除的东西是文章的发布时间，无论是在首页还是归档页、或者是文章页面都看不到任何时间信息。~~因为我博客更新的频率本来就不高，展示时间岂不是让你们知道我拖更了多久？~~当然你可以通过其他的方式来查看更新的时间，比如 RSS 或者 Sitemap。

一些加法

还没做。应该可以再水一篇文章。😘

目前想到的一些功能：

灯箱
代码块优化
站外链接增加图标
文章页头图
搜索功能
……

最后

之前我的博客源码一直都是放在私有仓库，这次我也是把博客完整的开源了，如果有人也想尝试 Gatsby 希望我的代码能起到一点帮助吧~~，也希望有人能帮我 fix typo 和 bug~~。

最近游戏荒了，正好该给博客除除草了。

小米 AX 9000 简单开箱测试

Sun, 04 Apr 2021 20:01:14 GMT

先介绍下我目前住的地方的网络环境吧：1000M 的电信光纤入户，主路由是自己组的 OpenWRT 软路由用于拨号上网，下面挂了一台网件 R6300V2 和一台斐讯 K3 作为 AP。路由器放在客厅和我的卧室隔了一道承重墙，这导致我的卧室 5G 信号不是很好，躺在床上看手机经常一个翻身连接速率就会骤降甚至断网。正巧前不久小米发布新旗舰路由器 AX9000，而且听说小米 Wi-Fi 6 系列的路由器口碑不错，就买了一台试试水。

BTW, 这篇文章的成文日期是清明节，不过当你们看到时应该已经6月初了，中间的这段时间可能被谁吃掉了（

参数简介

参数部分就不过多介绍了，具体可以看小米官网。这里列几个比较关键的参数：

搭载了高通 IPQ8072 处理器，4 核 14nm A53 架构和一个双核的 NPU，搭载 1G 内存和 256M ROM，官方宣称可以同时支持 1000 台设备连接。
提供一个 2.5G 的网口和 4 个千兆网口，其中 2.5G 网口可以在 WAN 和 LAN 间切换。比较可惜不是全 2.5 G 口不能战未来。
无线同时支持 2.4G/5.2G/5.8G 三个频段
- 2.4G 规格为 4x4 MIMO 1148Mbps
- 5.2G 规格为 4×4 MIMO 4804Mbps
- 5.8G 规格为 4×4 MIMO 2402Mbps，支持 2x2 4K QAM
主动式散热，增加稳定性但是积灰属性++
支持 USB3.0，这个说实话用不上而且 3.0 还会影响到 2.4G Wi-Fi

开箱

我是首发当天在狗东上买的，当时还显示采购中，没想到当天夜里就有货了，第二天下午就送到了。刚拿到手上发现这包装是真的大，比我的台式机机箱还大，不知道的还以为我买了台电脑呢。

背面介绍了一堆路由器的参数和特性。

打开包装后是一个巨大的海绵箱子。

打开保护盒后就可以看到路由器本体和配件盒。

AX9000 本体

天线展开角度可以接近 180 度，正面有四条 RGB 灯带，可以在软件中设置颜色和光效。

AX9000 的四面都有接口，正面是电源和网络指示灯

背面是四个 LAN 口和一个 WAN 口，右侧的 LAN 口和 WAN 口可以切换 2.5G

AX9000 比较有槽点的设计是网口和电源线接口不是在同一侧，电源线开机键和 RESET 键放到另一侧，导致接线时有两侧需要连线

另一侧是 USB3.0 接口和一个 Mesh 一键组网按键

再来看看配件盒，配件盒内的东西不多，就一个电源适配器、一条网线和一张说明书

电源适配器的尺寸不算小，输出是 12V 4A

开箱完毕，接下来开始配置路由器。

路由器设置

现在这些互联网公司出品的路由器设置起来都非常傻瓜化了，简单几步就能上网。接上电源线和网线后开机，打开 Wi-Fi 会看到一个没有密码的无线网络，我这里是 xiaomi-router-ra70_xxx，具体的 Wi-Fi 名可以在底部的铭牌中查到。

连接后会弹出一个 portal 认证网页，根据步骤设置完就能上网了。

之后你还可以把路由器添加到米家 APP 中，注意这里可能需要更新到最新版本的米家 APP，打开米家会自动发现路由器并提示你添加。

加入米家后，就可以远程设置路由器了

米家 APP 中的设置很全面，已经可以代替网页管理后台了

打开 RGB 灯效设置页，可以设置呼吸灯、彩虹灯等各种灯效。但这对于我来说是一个毫无软用的功能，我选择关闭所有的灯光。对于我来说，一台路由器只要静静地躺在角落里稳定的运行就足够了。

另外还有需要注意的是，USB3.0 默认也是打开的需要关闭，否则会影响到 2.4G 的 Wi-Fi。

无线测试

配置完成后，和之前的 K3 路由器做一个简单的对比测试。测试不保证严谨，仅供参考。因为路由器只作为无线 AP 使用，所以只对无线传输速度进行测试，目前我手上没有万兆网络设备只能测千兆下的速度表现。我们使用 LibreSpeed 进行测试，测试节点在内网的一台服务器上。测试设备为 iPhone 11 Pro，最大 PHY 数据速率为 1200 Mbps。

第一组测试：将测试设备贴到路由器旁，可以看到 AX9000 可以的下行速率可以跑到 875Mbps，而 K3 的速率只有 661Mbps。

AX9000	K3

第二组测试：将测试设备放到卧室最角落，隔了一堵承重墙。可以看到隔了一堵墙后，两款路由器的传输速率能有很大幅度的下降，但是 AX9000 还是能达到接近百兆的传输速率，是 K3 的两倍多。

AX9000	K3

总结

从测试结果来看，AX9000 的无线性能已经大幅度超过了原来的 K3 路由器，算是比较令我满意的一次设备升级。但是穿墙能力只能算是差强人意，好在小米 AX 系列路由器现在已经支持 AP Mesh 组网，未来的某一天如果现在的无线信号不能满足我的需求，可以再买一台 AX 系列路由器组 Mesh 网络，增强无线信号的强度。

给博客增加深色模式支持

Fri, 24 Apr 2020 17:45:18 GMT

目前主流操作系统（macOS Mojave, Windows 10, iOS 13, Android 10）都已经支持深色模式。最近也给博客主题加上了深色模式（Dark Mode）的支持，本文做一些记录。

Dark Mode ≠ Night Mode

首先需要明确一个概念，深色模式不是夜间模式。

从使用场景来说，夜间模式是在弱光环境下使用（比如在被窝里），主要目的是保护眼睛，减少强光对眼睛的刺激；而深色模式则没有这个限制，在大白天也能正常使用（我在 macOS 上就常年开着深色模式），可以理解为 Dark Mode 是一个黑色主题。

从功能上来说，夜间模式就是为了夜晚使用不刺眼（前面提过）；而深色模式有如下功能（个人总结）

省电。现在很多手机都使用 OLED 屏幕，OLED 屏幕的每个像素点是独立发光的，黑色像素点不发光。
让用户更加专注。大片留白会分散注意力。

如何实现

Media Query

可以通过 CSS 媒体查询 prefers-color-scheme 来判断系统当前的主题，兼容性如下（数据来源 caniuse）。

其实只要系统支持深色模式就支持特性，所以完全可以放心使用。

/* normal/light css */
@media (prefers-color-scheme: dark) {
  /* dark css here */
}

落地到具体实现方式有两种：CSS Variable 和 Override。

CSS Variable

如果网站本来就是使用 CSS Variable，那就再定义一份深色模式的 color scheme 即可。这是最简单的方式，对于不支持 CSS Variable 的客户端也有 polyfill。如果你的构建工具使用的是 PostCSS，那配合 postcss-css-variables 插件可以实现更好的兼容性。

:root {
  --color-text: #000;
}

@media (prefers-color-scheme: dark) {
  :root {
    --color-text: #fff;
  }
}

body {
  color: var(--color-text);
}

CSS Override

但如果网站由于历史原因或 trade-off，没有使用 CSS Variable，也可以通过覆盖 CSS 样式的方法实现。比如我的博客，早期没有选择 CSS Variable，打算迁移时发现工作量还是挺大的，就直接暴力覆写 CSS 了（简单粗暴，风险小）。

我的方案是写了一个 mixin，然后全文搜索用到颜色的地方，通过 mixin 覆写一份深色主题。

@mixin dark {
  @media screen and (prefers-color-scheme: dark) {
    @content;
  }
}

body {
  color: #000;
  @include dark {
    color: #fff;
  }
}

颜色选择

敲定实现方案后，现在又有一个世纪难题，如何选择合理的颜色？

深色颜色要能同时兼顾白天和夜晚的使用场景。
深色模式并不是一劳永逸的设置绝对黑底白字，两者的对比度是最高的（21:1），这容易产生阅读疲劳，不利于长时间阅读。

站在巨人的肩膀上，通过借鉴一些设计比较好的产品是如何实现深色模式的，再基于实际情况，选择适合自己的颜色方案。

背景色

背景色有两种取法：选择中性黑或带有自己品牌颜色的“黑”。

iOS 的系统界面使用纯黑 #000000，这样的好处是可以省电；Twitter 的黑是带有深蓝色的 #15202b；而 Material Design 建议使用 #121212作为背景色，说是深灰色相比纯黑可以更好表达。

因为我的博客也没有特别的品牌颜色，最终选择和 Material Design 一样的 #121212。

文字

文字尽量不使用纯白，亮度太高刺眼，可以选择稍微暗一点的颜色。这里我直接抄了 Material Design 的作业。

When light text appears on dark backgrounds it should use the following opacity levels:
High-emphasis text has an opacity of 87%
Medium-emphasis text and hint text have opacities of 60%
Disabled text has an opacity of 38%

正文颜色使用 hsla(0,0%,100%,.87)
标签、时间等辅助元素使用 hsla(0,0%,100%,.6)

颜色对比度

选取好颜色后接下来就是仔细检查网站上各个元素的颜色是否符合 WCAG 2.0 标准。该标准主要是针对有视觉障碍用户，保证你的内容对他们来说是可读的。对于颜色对比度的要求如下：

1.4.3 Contrast (Minimum): The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following: (Level AA)
Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 3:1;
Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.
Logotypes: Text that is part of a logo or brand name has no minimum contrast requirement.
1.4.6 Contrast (Enhanced): The visual presentation of text and images of text has a contrast ratio of at least 7:1, except for the following: (Level AAA)
Large Text: Large-scale text and images of large-scale text have a contrast ratio of at least 4.5:1;
Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.
Logotypes: Text that is part of a logo or brand name has no minimum contrast requirement.

主要是要满足这两点：

AA 级：文字与背景的对比度至少为 4.5:1，大号文字为 3:1。
AAA 级：文字与背景的对比度至少为 7:1，大号文字为 4.5:1。

你可以用 Chrome Devtools 逐一查看各个元素的对比度：

也可以通过 Lighthouse 一键检测网页上所有的元素。

如果有不符合标准的颜色，可以通过这个网站选取合适对比度的颜色。

层级表现

深色模式下表现层级无法通过阴影实现，因为背景已经是深色，阴影效果会被弱化。如果要表现不同的层级，可以通过背景色区分。比如我的博客在移动端右上角会有一个下拉菜单，在深色模式下取消了原本的阴影，使用亮一点的灰色作为背景。

我的博客有多快？

Sat, 08 Jun 2019 21:37:56 GMT

如果你看过我之前的文章，应该知道我使用自己写的程序 ga-proxy 在后端将统计信息通过 Google Analytics Measurement Protocol 传给 Google Analytics 服务器。当时写的功能比较简单，只有统计页面访问量的功能。后来看到 Sukka 在博客中提到了 Measurement Protocol 还支持统计网站加载速度，于是在今年二月我给 ga-proxy 加上了这个功能。几个月过去了，今天就来看看我博客实际的加载速度吧。

博客的优化

开始之前，先谈谈博客的基本信息和一些优化。

DNS：CloudXNS
CDN
- 主站：中国大陆为腾讯云上海机房单点部署，海外是 CloudFlare -> Netlify
- 公共库：jsDelivr
- 图床：自建，七牛 + CloudFlare
前端优化
- 使用 critical 提取内联关键 CSS
- 使用 tiny-cache 缓存 JS 资源，脚本本身内联
- 使用 Workbox 作为 Service Worker 解决方案，缓存各种请求
服务器优化
- HTTP/2
- TLS1.3
- ECC + RSA 双证书
- Brotli 压缩算法

数据收集

再来看看我收集了哪些数据。

Google Analytics Measurement Protocol 支持发送的数据类型有：

网页加载时间
DNS 时间
网页下载时间
重定向响应时间
TCP 连接时间
服务器响应时间
DOM 互动时间
内容加载时间

以上这些数据都可以通过 Navigation Timing API 获取，关于这些数据的的具体意义，可以看这里。

我比较关注的数据主要有：

DNS 查询时间
内容加载时间，DOM 和 CSSOM 均准备就绪的时间。
网页加载时间，表示网页及其所有子资源都准备就绪的时间。

开始

统计时间范围从 2019 年 3 月 1 日到 2019 年 6 月 1 日。

DNS 查询时间

平均查询时间为 0.13 秒，大部分落在 0 - 0.01 秒之间，这部分主要是由于 DNS 缓存。大于 1 秒仅占 2.81%。（CloudXNS 似乎可以一用？

内容加载时间

平均内容加载时间 1 秒，0 - 0.5 秒接近 50%，1 秒以下占比 73%。加载时间在 3 秒以内是一个合理的数值，如果 3 秒内页面的内容还没显示，就会造成用户的流失。

网页加载时间

这部分数据不太好看，平均加载时间达到 9.87 秒。

主要有两点原因：

没有使用 Lazy Loading 加载图片，最近几篇文章的图片较多；
评论使用 Disqus，部分地区访问会出现异常。

未来计划

下一步主要是针对图片加载作优化，除了 Lazy Loading 外，还会采用 Responsive images 对图片进行处理，根据分辨率加载合适大小的图片。

同时，需要注意的是加载时间并不代表用户实际的体验：

A second example of a performance myth is that performance is only a concern at load time.
[…]
Likewise, traditional performance metrics like load time or DOMContentLoaded time are extremely unreliable since when they occur may or may not correspond to when the user thinks the app is loaded.

我会尝试使用 PerformanceObserver 监控以用户为中心的性能指标：首次绘制、首次内容绘制和首次有效绘制时间等。

参考

流体排版简介

Thu, 02 May 2019 17:27:49 GMT

在传统网页排版中，字体大小一般是固定不变的，例如 16px 在桌面端和移动端都能有不错的显示效果。但是，随着显示器分辨率越来越多样，从 4k 到 5k 甚至 8k，固定字号似乎行不通了。不可能存在一个完美的字体大小覆盖所有的分辨率！好在我们可以采用媒体查询（Media queries）设置断点，然后根据不同的可视宽度设置不同字号。但这种方法并不完美，当处于断点之间时，整个页面会发生突变!

幸好，这一切可以通过流体排版解决。

什么是流体排版

事先声明，流体排版这个词是我自己瞎翻的，英文单词为 Fluid Typography。所以如果你发现搜索「流体排版」好像查不到什么，不妨试试搜索 “Fluid Typography”。

维基百科是这样定义流体的：

流体（英语：Fluid）就是在承受剪应力时将会发生连续变形的物体，包括气体和液体。流体没有一定形状，几乎可以任意改变形态，或者分裂。

那么流体排版也有流体二字，那么肯定和流体有关咯~

是的，流体排版指的是根据浏览器的视口（viewport）大小，响应式地改变字体大小。这和开头说的通过媒体查询方式实现的“伪”响应式不同，它的变化是连续的，不会出现突变。

在网页开发中，我们可以利用视口单位（Viewport units）实现流体排版：

vw：视口宽度的 1/100
vh：视口高度的 1/100
vmin：视口宽度和高度较小者的 1/100
vmax：视口宽度和高度较大者的 1/100

通过使用视口单位，我们可以很容易实现流体排版，

html {
  font-size: 1.5vw;
}

但是单纯使用视口单位实现流体排版其实并不完美：我们无法限制最大最小字体大小。

更好的方式

单纯使用视口单位不能限制最大最小字体大小，但结合前面提到的媒体查询，分别在最小和最大视口宽度处设置断点就可以了。

这个问题可以变为已知坐标轴（x 轴为视口宽度；y 轴为字体大小）上两点，给定任意一个 x，求经过这两点构成直线上的 y 值。

比如我们的字体大小变化访问为 16px - 24px，对应视口宽度为 320px - 2560px，那么，

font-size 初始为 16px；
当 min-witdh = 240px 时，font-size 为 (16 + (24 - 16) * ([当前视口宽度] - 320) / (2560 - 320))px，其中涉及计算，需要使用 calc()。翻译成 CSS 就是 calc(16px + 8 * (100vw - 320px) / 2240)；
当 min-witdh = 2560px 时，font-size 为 24px。

最终的 CSS 长这样，

html {
  font-size: 16px;
}

@media screen and (min-width: 320px) {
  html {
    font-size: calc(16px + 8 * (100vw - 320px) / 2240);
  }
}

@media screen and (min-width: 2560px) {
  html {
    font-size: 24px;
  }
}

以上设定和代码来自本博客，你可以尝试更改浏览器窗口大小来体验字体大小的变化。

同时，为了更好的阅读体验，我们希望在桌面设备上不同标题字体尽可能区分，而在移动端不同标题的差距应该缩小，对于 h1 - h6 也要设置不同的缩放比例。

这种方式在现在浏览器上能完美工作，如果要兼容 IE 等其他过气浏览器，我推荐使用 Textblock。

扩展阅读

J1900 灵车上车小记

Sat, 09 Mar 2019 17:51:12 GMT

上了最近很火的“蜗牛星际”J1900 NAS 矿车。一般说到矿车，都是大功率电源、显卡这些。这批 J1900 矿车其实挖的是另一种矿—— IPFS / CAI。一开始卖 5000 多一套，都后来 CAI 价格跌到谷底，矿老板清盘，这才有了这批车。

目前这批车主要有 4 种车型。（图转）

我上的是 B 款双网口，闲鱼找了一家说是带纸箱，全新未下矿的。360 大洋入手。现在价格偏高，我认为比较合理的价格应该是双网口 300 左右，单网口 220 左右。据说市场上有 20 万台存货，如果不急可以先等等，后续应该会降价不少的。

等待快递到达的过程中，不少网友说双网口翻车了（见上图翻车点）。我想着我买的 B 款双网口，这不完了吗！结果快递到了后一看竟然寄来的是单网口版本的，成功漂移，车翻回来了。不过，现在双网口的好像也能安全下车了。

开箱

机箱是万由 NAS 的，颜值还可以。

看机箱屁股，确认是单网口版的，有两个 USB 3.0 接口。根据型号表可得出网卡为 I211。

150W 的山寨 1U 电源，感觉不是很放心，为了硬盘安全最好换一个好点的。

CPU 由于是 J1900，TDP 只有 10 W。整个机箱一共两个风扇，一个后置机箱风扇和一个电源风扇。

风扇声音非常大，3 PIN 接口不支持 PWM 调速，bios 里也没有 DC 调速选项，果断加一条减速线解决。

看了下主板好像不是很好拆，就没接着拆解了。

NAS 系统选择

谈到 NAS 系统，大部分人首先想到是黑群晖。但是黑裙每次升级都要小心翼翼，一不小心系统整崩了就完了。其实除了黑裙，还有其他不错的 NAS 系统可供选择，比如 FreeNAS, OpenMediaVault, Unraid 等等。

经过对比，FreeNAS 的硬件需求太高，这套配置带不起；Unraid 收费不考虑；而 OMV (OpenMediaVault) 的硬件需求极低，你甚至可以用树莓派运行它。所以我决定选用 OMV 作为 NAS 系统。

系统安装

OMV 可以通过两种方式进行安装：

直接通过官方 ISO 安装
基于 Debian 9 系统安装

这里我使用第二种方式，因为官方 ISO 不支持 UEFI 安装。

制作安装 U 盘

因为系统盘只有 16 G，需要最小化安装 Debian 9。

下载最小光盘映像，然后通过 Win32 Disk Imager 将映像文件写入 U 盘。

安装系统

插上 U 盘，开机按 F7，选择 U 盘启动。安装教程网上一堆，这里不作过多展示。不过有几点需要注意。

由于采用 UEFI 方式，需要建一个 EFI 分区。我的分区方式为 500 MB 的 EFI 分区，4G 的 Swap，剩下的全给根目录（就 16G 没啥好分的）。
为了最小的系统空间占用，要安装软件只选择 SSH server。

安装完后，登录系统，输入 ip a 看一下内网 IP。然后就可以机器丢一边，用 SSH 连接咯。

安装 OMV

添加 OMV 源

cat <<EOF >> /etc/apt/sources.list.d/openmediavault.list
deb http://packages.openmediavault.org/public arrakis main
# deb http://downloads.sourceforge.net/project/openmediavault/packages arrakis main
## Uncomment the following line to add software from the proposed repository.
# deb http://packages.openmediavault.org/public arrakis-proposed main
# deb http://downloads.sourceforge.net/project/openmediavault/packages arrakis-proposed main
## This software is not part of OpenMediaVault, but is offered by third-party
## developers as a service to OpenMediaVault users.
# deb http://packages.openmediavault.org/public arrakis partner
# deb http://downloads.sourceforge.net/project/openmediavault/packages arrakis partner
EOF

使用 Root 用户进行安装

export LANG=C
export DEBIAN_FRONTEND=noninteractive
export APT_LISTCHANGES_FRONTEND=none
apt-get update
apt-get --allow-unauthenticated install openmediavault-keyring
apt-get update
apt-get --yes --auto-remove --show-upgraded \
    --allow-downgrades --allow-change-held-packages \
    --no-install-recommends \
    --option Dpkg::Options::="--force-confdef" \
    --option DPkg::Options::="--force-confold" \
    install postfix openmediavault
# Initialize the system and database.
omv-initsystem

安装完成后，浏览器输入 NAS 的 IP 地址即可登录到管理界面。默认用户名密码为 admin / openmediavault。

安装 OMV-Extras

OMV-Extras 提供一些额外的插件，比如 ZFS，Docker，Downloader 等等。安装方式很简单，参考官方说明。

一些优化

BIOS 设置

关闭通电自启：Advanced - ACPI Settings - PWRON After Power Loss - Always off
开启热插拔：Advanced - SATA Configure - SATA Port1 HotPlug - Enabled

更换国内镜像

sed -i 's/deb.debian.org/mirrors.ustc.edu.cn/g' /etc/apt/sources.list
sed -i 's|security.debian.org/debian-security|mirrors.ustc.edu.cn/debian-security|g' /etc/apt/sources.list

sed -i 's/download.docker.com/mirrors.ustc.edu.cn\/docker-ce/g' /etc/apt/sources.list.d/omv-extras-org.list

sed -i 's/httpredir.debian.org/mirrors.ustc.edu.cn/g' /etc/apt/sources.list.d/openmediavault-kernel-backports.list

关闭蜂鸣器

rmmod pcspkr
echo "blacklist pcspkr" >> /etc/modprobe.d/blacklist

OMV 配置

懒得写了，就简单说一下一些必要的配置

系统 - 常规设置：修改登录密码
系统 - 插件：安装插件，推荐 Docker，shellinabox，transmissionbt
系统 - OMV-Extras：开启 Docker CE，开启 backports（可选）
储存器 - 磁盘：配置磁盘的电源策略
储存器 - S.M.A.R.T：开启 S.M.A.R.T
储存器 - RAID 管理：建立软 RAID（可选）
储存器 - 文件系统：创建文件系统，推荐 EXT4
访问权限管理 - 用户：新建用户访问关系文件夹
访问权限管理 - 共享文件夹：创建共享文件夹，可以设置访问权限。（关于访问权限设置，你需要更改文件夹的特权，而不是 ACL）
服务 - SMB：开启 SMB 服务，设置共享文件夹

也可以看 B 站这个视频，虽然是 3.x 版本的，但操作基本一样。

测试

测试硬盘为希捷酷鱼 1T，局域网内跑满千兆没有翻车~

不过还是不够快呐，本来想双网口搞链路聚合的（小声）

参考链接

最强空气盘？HUS728T8TALE6L4 开箱与非专业简评

Sun, 16 Dec 2018 15:31:17 GMT

迫于最近沉迷 PT，加上学校 200M/80M 的带宽，电脑存了各种原盘 4K 电影，原来的存储空间已经完全不够用了。思来想去，在马云家剁了块 8T 硬盘 HUS728T8TALE6L4，双十二到手价 1496 元。

平时各种评测见得多了，这次就试着也做一期评测。(本文共 19 张图片，4.71 MB)

开箱评测

到手开箱，这包装不算特别厚实，感觉可以再来几层气泡纸。

拿掉气泡纸，又是一层包装。

除了硬盘本体，还附赠一根 SATA3 数据线和 4 颗螺丝。

正面标签，生产于 2018 年 8 月 22 日泰国。这块盘是业界首款 5 碟 8TB 的机械硬盘，缓存 256M。LOGO 显示是西数，但其实是 HGST 的盘体。

上螺丝，准备装机。送的螺丝用不上，这里用的是机箱的螺丝。

组装完成。

机箱型号 Fractal Design Define C TG，有 2 个 3.5" 硬盘位和 3 个 2.5" SSD 槽。其中一个 3.5" 硬盘位已经装了一块 1TB 的西数绿盘。（请不要在意理线，等我有钱了一定买定制线）

上机，稍微理了下线，然而还是很丑。

开机，磁盘管理器已经识别出来了，显示 7452 GB。

格式化。

OK。

其他两块硬盘已经红了。。你们装不下的东西，让大哥帮忙扛着！

使用 HD Tune 查看信息，通电次数 2 次，通电时间 0 小时。

CrystalDiskInfo 基本信息。（这时正在扫描扇区，已经持续了一个多小时。温度有点高。噪音由于是静音机箱，所以不是很明显）

坏道扫描，扫了 11 个小时。。。

HD Tune 持续读写测试，各方面都非常优秀。特别是写入时的存取时间竟然只有 0.4 ms。

实际写入测试，从固态硬盘中拷贝「神探夏洛克」第一季，3 个文件共 110 G。速度在 240 MB/s 上下浮动，非常稳定！

实际读取测试，从机械拷到固态，速度稳定在 240 ~ 250 MB/s。

4K 读取这里就不测了，机械硬盘更多是作为仓储盘使用，4K 性能我并不是很关心。

更多测试可以看这里 HGST Ultrastar 7K8/DC HC320 8TB HUS728T8TALE6L4 小测

总结

总的来说，这块盘某宝价格在 1550 元左右，算下来每 TB 价格只有 193.75 元；同时性能表现非常不错，日常使用读写速度在 240 MB/s 左右，基本到达机械硬盘的天花板。

性价比超高，值得购买！

大话 TLS 1.3

Wed, 19 Sep 2018 10:30:45 GMT

2018 年 8 月，在 TLS 1.2 发布 10 年之际，TLS 1.3（RFC 8446）正式定稿。一看到这个消息，我就想给我的 Nginx 服务器添加 TLS 1.3 的支持，但是这时的 OpenSSL 1.1.1 仍处于 pre 版本，虽然已经支持 TLS 1.3 final，但是线上服务器一般来说还是得用正式版。终于，在一个月后，OpenSSL 1.1.1 发布，作为新的长期支持（LTS）版本代替了 1.0.2。

现在，是时候更新 Nginx 了。

从 TLS 1.2 说起

在 TLS 1.3 之前，TLS 1.2 的握手方式饱受诟病。TLS 1.2 的握手流程如下所示：

      Client                                               Server

      ClientHello                  -------->
                                                      ServerHello
                                                     Certificate*
                                               ServerKeyExchange*
                                              CertificateRequest*
                                   <--------      ServerHelloDone
      Certificate*
      ClientKeyExchange
      CertificateVerify*
      [ChangeCipherSpec]
      Finished                     -------->
                                               [ChangeCipherSpec]
                                   <--------             Finished
      Application Data             <------->     Application Data

客户端发送一个 ClientHello 的信息到服务端，这个包含信息主要包含了客户端所支持的加密套件（cipher_suites）、支持的TLS 版本（client_version）、会话 ID（session_id）等数据。
服务器在收到这个 ClientHello 后，会选则一个合适的加密套件，然后返回一个 ServerHello 的信息，这当中包括了选中的加密套件。初此以外，还会发送证书以及密钥交换（ServerKeyExchange）。密钥交换的数据由选中的加密套件决定，比如使用 ECDHE 时，发送数据有椭圆曲线域参数、公钥的值（详情见 RFC 4492 section 5.4）。
客户端收到 ServerHello 后，会对收到的证书进行验证。如果验证通过，则继续进行密钥交换流程：将客户端生成的公钥和服务端的结合，计算出本次会话的密钥，然后把公钥发送给服务端，最后再发送一个 Finished 信息。
服务器收到客户端公钥信息，也会计算得出密钥，然后发送 Finished 信息。
至此，握手阶段结束，加密连接开始。

从中可以看出，整个握手流程需要 2-RTT，这在网络延迟较高的情况下是非常糟糕的，可能导致握手延迟增加几百毫秒。更糟糕的是，握手阶段的数据（如 ServerHello 阶段的信息），并不是加密的，中间人稍加利用，从中选择比较弱的加密算法，就可以带来降级攻击（Downgrade Attack）。

TLS 1.3 的改进

TLS 1.2 的握手方式，是基于之前的版本 TLS 1.1 改进而来。可以说从 TLS 1.0 开始的握手方式基本没有太多的改变：2-RTT、未加密的 ServerHello 等等… 所以，在我看来 TLS 1.3 最大的改进，就在于握手方式改变。

TLS 1.3 的握手流程如下所示：

       Client                                           Server

Key  ^ ClientHello
Exch | + key_share*
     | + signature_algorithms*
     | + psk_key_exchange_modes*
     v + pre_shared_key*       -------->
                                                  ServerHello  ^ Key
                                                 + key_share*  | Exch
                                            + pre_shared_key*  v
                                        {EncryptedExtensions}  ^  Server
                                        {CertificateRequest*}  v  Params
                                               {Certificate*}  ^
                                         {CertificateVerify*}  | Auth
                                                   {Finished}  v
                               <--------  [Application Data*]
     ^ {Certificate*}
Auth | {CertificateVerify*}
     v {Finished}              -------->
       [Application Data]      <------->  [Application Data]

现在客户端在发送 ClientHello 信息时，不仅包含支持的加密套件等数据，还会猜测服务器可能会选择的加密算法，并以此计算并发送共享密钥（pre_shared_key）。
服务器收到 ClientHello 后，选择合适的加密套件，然后发送ServerHello，包含共享密钥、证书等数据。而这些数据，这时候已经是加密的了！
客户端收到服务端的共享密钥后，计算出密钥，加密连接开始。

可以看到，整个握手流程变成了 1-RTT，握手时间明显减少，而且 ServerHello 之后的数据都是加密的，安全性大大提高。

同时，在客户端在之前有过 TLS 连接的情况下，TLS 1.2 也可以做到 1-RTT。那么 TLS 1.3 呢？0-RTT！对于最近访问过的站点，可以直接在 ClientHello 阶段发送加密的数据（如 HTTP GET）。但是，值得注意的是，这种方式不具备前向安全性，可能会有重放攻击，使用该功能需谨慎。

除此之外，TLS 1.3 相比 TLS 1.2，还做了一些安全性上的改进：

废除不安全的加密算法
新的加密套件
禁用 TLS 压缩
……

详尽的更新信息见文末的参考资料

TLS 1.3 in Nginx

目前，Chrome 和 Firefox 的最新版本已经支持 TLS 1.3 draft 28，Can I Use 的统计数据显示：TLS 1.3 的全球覆盖率为 65%。无论如何，为了更快、更安全的 TLS 连接，提前给 Nginx 服务器加上 TLS 1.3 的支持是很有必要的。

在 Nginx 上开启 TLS 1.3 是非常简单的。

首先，需要下载 Nginx 1.15.4 和 OpenSSL 1.1.1。这里为 OpenSSL 打一个 patch，主要作用是同时开启 TLS 1.3 draft 23 + 26 + 28 + final 的支持，同时可以自定义加密套件。

wget -c https://www.openssl.org/source/openssl-1.1.1.tar.gz -O openssl-1.1.1.tar.gz && tar zxf openssl-1.1.1.tar.gz && rm openssl-1.1.1.tar.gz
cd openssl-1.1.1 && curl https://raw.githubusercontent.com/hakasenyang/openssl-patch/master/openssl-equal-1.1.1_ciphers.patch | patch -p1 && cd ../
wget -c https://nginx.org/download/nginx-1.15.4.tar.gz -O nginx-1.15.4.tar.gz && tar zxf nginx-1.15.4.tar.gz

然后编译 Nginx，

cd nginx-1.15.4
./configure --with-openssl=../openssl-1.1.1
make && make install

TLS 1.3 的相关配置推荐：

ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
ssl_ciphers [TLS13+AESGCM+AES128|TLS13+AESGCM+AES256|TLS13+CHACHA20]:[EECDH+ECDSA+AESGCM+AES128|EECDH+ECDSA+CHACHA20]:EECDH+ECDSA+AESGCM+AES256:EECDH+ECDSA+AES128+SHA:EECDH+ECDSA+AES256+SHA:[EECDH+aRSA+AESGCM+AES128|EECDH+aRSA+CHACHA20]:EECDH+aRSA+AESGCM+AES256:EECDH+aRSA+AES128+SHA:EECDH+aRSA+AES256+SHA:RSA+AES128+SHA:RSA+AES256+SHA:RSA+3DES;
ssl_ecdh_curve X25519:P-256:P-384:P-224:P-521;
ssl_prefer_server_ciphers on;

# 0-RTT（谨慎使用）
ssl_early_data on;

这里只做了一个最简单的演示，不包含具体的编译参数等信息。

我在 GitHub 上开源了我服务器上 Nginx 的编译脚本和一些配置文件，可供参考使用。

https://github.com/giuem/nginx-giuem

参考资料

新的开始：好好写博客

Thu, 30 Aug 2018 17:08:34 GMT

这几年我博客基本是废了，没有好好的写过一篇完整详细的文章，都是随便糊弄一下，没有深度。博客的主题也快 3 年没有换了，看着都有点审美疲劳了。也是借着这个暑假的时间，对博客进行了一番大改版。

主题

原来的主题实在是看腻了，这次也是重新写了一个。

这几年我对博客主题的审美逐渐趋于简洁。所以这次主题，我采用了单栏风格，原来的友链移至内页。首页为了不显得那么单调，加了一个头图，这个设计主要参考了 tcdw 的 egoist。

同时，还做了很多没什么卵用的优化：内联样式、缓存脚本文件、使用 System fonts、还有各种 prefetch 等等。一套下来，整个站点的单页请求缩减到只有几个（不包括启用 Disqus 的页面），速度还是非常快的。Google PageSpeed Insights 的得分为 100。

主题现在仍处在开发中，等开发完成，会开源并做一个详细的介绍。

内容

一个字：删！

博客建立初期，我的文章基本都是和百度贴吧相关的。这些文章大多都时效性，现在来看，基本都已经失效；加上我现在已经不再玩贴吧了，这些内容等于是不再维护了（包括曾经写的贴吧机器人）。所以索性就把这些内容都给删除了，还有一些很水很水的文章，也被我砍掉了。

以后更新的文章，可能会更加硬核（暗示咕咕咕）。

架构

博客的架构也进行了一次大改版。

之前我博客的部署流程是比较麻烦的，使用 Travis CI, GitHub Webhook（见《使用 Travis CI 自动部署 HEXO 博客》）。这次也是简化了流程，直接在云主机上搭了一个 Minio 私有云存储，然后在 CI 构建的时候直接把静态文件 push 过去。之前因为 GitHub 在国内访问速度不佳，导致主动拉取的速度很慢很慢，有时候还会 timeout。这次改版后，构建发布的时间基本不超过一分半。

博客的 CDN 也做了修改，国内仍然是使用腾讯云主机。国外之前的使用 Firebase Hosting，速度是还可以，但是配置不太灵活，这次换成了 CloudFlare 回源 Netlify 的方式。CloudFlare 是 Pro Plan（由云锤提供），可以直接 CNAME 接入，方便 GeoDNS；还有 30 条 Page Rules。

66云（66.To）磁盘扩展小记

Wed, 14 Feb 2018 21:05:54 GMT

最近在 66 云买了一台服务器，他家的面板采用的是 Azure Pack。看起来很高大上，但是因为文档太太太简略了，对像我种垃圾来说很不友好。

过程记录

66 云上创建的虚拟服务器默认是只有 40G 的磁盘大小，套餐是 80G，需要手动扩展或挂载一个新的磁盘。为了方便，我直接扩展原磁盘。

首先去面板里把服务器关机，把磁盘扩展到 80G，在开机就行了。

你以为就这么简单？才不是呢！重启服务器后查看磁盘大小还是 40G。。。通过 fdisk 查看分区发现模板创建的系统使用的是 Linux LVM，然后扩展是加了一个 40G 的Extended 分区，可以说是非常睿智了。

$ fdisk -u /dev/sda

Command (m for help): p
Disk /dev/sda: 80 GiB, 85899345920 bytes, 167772160 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x32a7a126

Device     Boot   Start      End  Sectors  Size Id Type
/dev/sda1  *       2048   999423   997376  487M 83 Linux
/dev/sda2       1001470 83884031 82882562 39.5G  5 Extended
/dev/sda5       1001472 83884031 82882560 39.5G 8e Linux LVM

Partition 2 does not start on physical sector boundary.

所以接下来要重建分区，这里要记下 LVM 分区的开始扇区位置 1001472

先删除 Extended 分区 (/dev/sda2)。

Command (m for help): d
Partition number (1,2,5, default 5): 2

Partition 2 has been deleted.

然后创建新分区，并写入。

Command (m for help): n
Partition type
   p   primary (1 primary, 0 extended, 3 free)
   e   extended (container for logical partitions)
Select (default p): p
Partition number (2-4, default 2): 2
First sector (999424-167772159, default 999424): 1001472
Last sector, +sectors or +size{K,M,G,T,P} (1001472-167772159, default 167772159): [ENTER]

Created a new partition 2 of type 'Linux' and of size 79.5 GiB.

Command (m for help): t
Partition number (1,2, default 2): 2
Partition type (type L to list all types): 8e

Changed type of partition 'Linux' to 'Linux LVM'.

Command (m for help): w

然后 reboot 重启服务器。

接下来重置 LVM 的大小。

首先重置 PV（物理卷）。

$ pvresize /dev/sda2

再重置 LV（逻辑卷）。通过 pvdisplay 查看 Free PE 的大小，不出意外的话应该是 40G。通过 lvdisplay 查看需要扩展的逻辑卷，这里是 /dev/ubuntu-vg/root。

$ lvresize -L+40G /dev/ubuntu-vg/root

最后再更新一下文件系统就行了。通过 df -T 得知 /dev/mapper/ubuntu--vg-root 文件系统类型是 ext4。

$ resize2fs /dev/mapper/ubuntu--vg-root

参考资料

组台与折腾

Sun, 03 Dec 2017 00:48:47 GMT

双十一组了台式机，使用了近一个月，体验不错，能在 1080P 中高画质下流畅运行各种游戏。但是因为预算暂时不是很充沛，考虑到后期还会升级配置，所以目前的配置是有点畸形的。（多图预警）

装机思路

CPU

CPU 的话暂定 Ryzen 5 1600X，因为狗东双十一有活动，可以做到 1499 的价格，非常划算。虽说 Intel i5 8400 性价比更高，淘宝散片价格 1200 - 1300，但是主板价格实在是太贵了！等明年出 B360 系列主板才划算点。

主板

既然确定是 1600X，基本也不用怎么折腾 CPU 超频了，所以选择 B350 主板。翻车嘉不考虑，华硕太贵，就选择口碑还算好的菌龟星。

显卡

鉴于 11 系的显卡也快发布了，而且现在显卡价格偏高（好吧，其实是预算不足，打算之后升级），所以暂时购买二手显卡。GTX970 我认为是一个不错的选择，1100 左右的价格，性能接近 1063，价格却少了 200 元。

内存

内存嘛，价格是真的贵，去年这时候 8G*2 六七百就能拿下，现在真是堪比金条… 所以呢，我就挑便宜的买。反正到手肯定是要 OC 的（Ryzen 平台不上 3000 频就废了

其他

固态首选三星，960PRO 买不起就只能买 OEM 条了。

电源的话，考虑后期扩展，而且这东西基本可以当传家宝了，就选择了贼船。

其他的就没啥好说的了。机械 1T 不存小姐姐足够了。散热也是传家宝系列，选了百元价位最强的赤兔马。

最终方案

类型	型号	价格
CPU	Ryzen 5 1600X	1599
主板	MSI B350M MORTAR	549
显卡	EVGA GTX970 4G SC	1100
内存	英睿达普条 DDR4 2400 8G*2	1168
SSD	SM961 256G	790
HDD	希捷酷鱼 1T	280
电源	海盗船 RM650x	869
机箱	乔斯伯 C3	273
散热	大镰刀赤兔马 PLUS	123
各种优惠		-491
总计		6260

折腾

CPU 就不超了，1600X 默频全核 3.7，通过 Ryzen XFR 技术可以单核 4.1、双核 4.0，日常游戏足够了。

显卡频率有点低，才 1140/1753 MHz，默电小超了一下，+125/+250，稍微提升一点。毕竟二手卡过保了，就不要草太狠了。

内存默频 2400 MHz，这肯定是要超的，Ryzen 平台极度依赖内存频率。刚开始我是直接超到 3200，可以进系统，但是跑 Memtest 出现错误，怎么调参数都没用，最后是降到 3066 Mhz 才顺利通过测试。看来镁光的颗粒还是不适合折腾啊。

跑分

跑分软件太多了，懒得一个个跑，我这里就测了 3DMark 和 R15。分数凑合，中高端水平吧，显卡很明显拖了后腿。

第一次的 CUMCM

Thu, 21 Sep 2017 20:10:46 GMT

最近参加了全国大学生数学建模竞赛，挺好玩的，故作此文记录。

起因

上学期大项目组队，本来我们是三个人，结果其中一个队友拉了一个小姐姐进来。刚开始以为小姐姐是来抱大腿的（大腿不是我），后来发现她虽然代码写的不好，但是很积极，给的任务也很快地完成……唔好像跑题了

反正，就是这样，我认识了她。然后这个小姐姐高数可厉害了，直接免考拿优 Orz。

之后，她就找我谈组队的事。一开始我是不想参加的，因为我对算法很不感冒，怕拖后腿。但是她劝我说，数学建模的算法都是确定的，可以查资料。好嘛，不就是实现算法嘛。于是，我就答应了。

队伍详情

我们的队伍有我、小姐姐、还有一个学物理的。其中只有小姐姐有数模经验（校赛），还没有获奖。队伍配置应该是所有参赛队里最渣的了

Day 0

晚上 8 点钟，题目出来了。A 题是 CT 相关，需要很强的数学和编程能力，涉及图像重建、矩阵变化、傅立叶变化；B 题是拍照定价，主要是数据挖掘，数据处理方面的，与机器学习有关系，也是需要编程。

我个人倾向于选 B，这题比较贴合当前的热点，感觉比较好玩。但是另外两个队友觉得 A 好，毕竟队友全是工科的，解题有优势。

确定 A 题后，我们开始查资料，求解第一问。

本来以为学校提供的教室可以通宵肛的，没想到这才刚到十点，门口老大爷就开始赶人了……于是我们只好转移阵地，来到 GC 俱乐部。

直到凌晨三点，我们对于第一问，还没有一个有效的解决方案。唯一的发现就是，椭圆投影最大值在 141，长轴长 80；而小圆投影最大值在 14，直径为 8。由此可以假设厚度与投影值是正相关，然后通过数据拟合出一条直线。

无奈，太晚了，还是回宿舍吧。

Day 1

醒来的时候已经十点半了，吃完早午饭就去图书馆和队友讨论去了。

昨晚已经求出了厚度和投影的关系，然后小姐姐通过复杂的推导，得出 X 关照射方向的计算方法。但是，对于旋转中心的确定，仍然没有思路。

一直到晚上十二点，我们都一直在查各种资料，但是还是没有思路。

翻车了。

Day 2

昨天回宿舍后，越想越难受，于是想去网上看看有没有人分享思路。果然，看到有人用附近二的数据作了一张热点图，一条清晰的正弦显示在图中！

有思路了。

所以今天我起了个大早，把那张图做了出来。把图发给小姐姐看，她一下就有了想法。

以为第一题做出来了（图像重建的论文很多，大概知道这题可以用滤波反投影法计算），我就放松了警惕，那天下午打了会开箱 GO（逃

然而，到了晚上，真要写起代码时却发现，算法是知道了，但是各种论文写的都非常简单，根本不知道怎么操作。大概看了一个小时，边调试边写代码，才总算是把图像重建好了。然而，我只看懂了直接反投影法，不知道怎么加滤波函数，重建出来的图像十分模糊。研究了好久，无果。

于是，我想去知乎找找思路，发现有人提到 MATLAB 里有一个函数 iradon 直接可以重建还特别清晰，emmmm。我用的是 Python 啊！难道要手写 Radon 逆变换？不不不，搜索后找到 skimage 提供了变换函数，和 MATLAB 用法一样。

只剩下吸收率的问题了。

Day 3

今天主要问题就是求出吸收率，以及把论文写完。关于吸收率，有一个想法就是根据附件一的数据和附件二逆变换后形成的矩阵求出一个比值，再带到附件三。事实证明，这种做法是正确的。然而，逆变换生成的矩阵是 362 * 362 的，题目要求的是 256 * 256，方向也和题目给出的图像不同。

我尝试了一下午，都没能把附件二的重建图像变成原来的大小方向（我好菜啊）。到了晚上，也没啥心思研究了，图是歪的就歪吧。我把所有的代码和数据打包整理发给队友，然后就开始水 Telegram 了……

我们在十二点前就交了论文，然后就回宿舍了。三天四夜的脑力活动，非常累，明天还是周一，要早起，所有一回宿舍扭头就睡了。

总结

因为是第一次参加数学建模，经验不足，浪费了许多时间。比如，最后一天写论文的时候，我们三个是同时在自己的电脑上修改，然后再发送汇总，效率低下，如果使用云文档来实现团队协助会好很多；然后就是我自己的原因了，没有提前熟悉 Numpy 库，导致使用时还要查文档。

对于这次建模呢，其实最后的结果什么的已经不重要了。我觉得建模的过程很有趣啊，通过查找资料，把一个自己之前完全不知道的东西弄懂，并通过自己的思考，不断地尝试去优化模型。

这次建模，总算让我对自己的水平有了点 B 数，我好菜啊！！！

为 SSH 开启两步验证

Mon, 14 Aug 2017 16:18:25 GMT

下午爆出 Xshell 的多个版本存在后门，会上传用户名密码，一直在用的表示很受伤 QAQ（当初因为 PuTTY 有后门才转的 Xshell。。我第一时间更新了版本，并更换 SSH 密钥。不过看登录日志和后台程序，没有发现任何异常。但是为了保险起见，我给 SSH 加上了两步验证。

我之前一直使用的就是 Authy，这次也不例外，选择 Authy 作为两步验证器。（没用过 Google Authenticator，有没有用过的过来分享一下）

按照官网的说明很轻松的就配置好了。这里有点坑的是居然还要去 Twilio 再注册一个帐号获取 API key。

效果

三次失败后断开连接

开始使用 Caddy

Fri, 04 Aug 2017 16:14:16 GMT

一直以来，我都是使用 Nginx 作为 Web 服务器，但是配置可以说是非常麻烦了。每次我要新开一个域名，都要先使用 acme.sh 签发 SSL 证书，然后再写配置，大概要花上 5 分钟的时间。曾经想过写个脚本自动完成这些工作，但是苦于对 Linux 的了解不多，也就作罢了。

最近看到了 Caddy，一个用 Go 写的 Web 服务器，它的配置简洁，同时能自动开启 HTTPS、支持 HTTP/2 && QUIC，完全符合我的需求啊，研究一番，就在我的服务器部署了，本文作一个简单记录。

我的操作系统是 Debian Jessie ，理论上只要是带有 Systemd 的系统都适用本文。

下载安装

首先去 Download Caddy，选择你系统平台、插件、是否开启监控（TELEMETRY）、许可证；例如我选的是

Platform: Linux 64
Plugins: http.cache, http.cors, http.expires, http.filter, http.git, tls.dns.cloudflare
TELEMETRY: ON
License: Personal

然后复制下方的 One-step installer script (bash)，在命令行运行就可以了。

CADDY_TELEMETRY=on curl https://getcaddy.com | bash -s personal http.cache,http.cors,http.expires,http.filter,http.git,tls.dns.cloudflare

安装完后输入 which caddy，不出意外的话会输出 /usr/local/bin/caddy

至此，安装完毕，但是目前它不会开机自启，只是简单地把二进制文件下载下来，所以下一步要注册服务。

注册服务

这里我使用的是官方提供的脚本 caddy.service，其他系统也可以在这里找到相应的脚本。

把这个文件下载到 /etc/systemd/system/ 。

sudo curl -s https://raw.githubusercontent.com/mholt/caddy/master/dist/init/linux-systemd/caddy.service -o /etc/systemd/system/caddy.service

创建所需目录，我图方便没有修改脚本直接使用默认值了，如果有特殊需求，可以自己更改目录。

sudo mkdir /etc/caddy
sudo chown -R root:www-data /etc/caddy
sudo touch /etc/caddy/Caddyfile

sudo mkdir /etc/ssl/caddy
sudo chown -R www-data:root /etc/ssl/caddy
sudo chmod 0770 /etc/ssl/caddy

sudo mkdir /var/www
sudo chown www-data:www-data /var/www

上面创建了三个目录，/etc/caddy 用了存放 Caddy 的配置文件，/etc/ssl/caddy 存放证书，/var/www 是默认的网站目录。

接着，重新加载 systemd daemon，让配置生效。

sudo systemctl daemon-reload

让 Caddy 开机自启。

sudo systemctl enable caddy.service

至此，Caddy 已经成功注册服务，并能够开机自启了。

配置

这部分的内容我不打算详细记录，主要是官方文档已经写的很详细了。

下面是我的配置，

example.com {
  proxy / 127.0.0.1:9001 {
    header_upstream Host {host}
    header_upstream X-Real-IP {remote}
    header_upstream X-Forwarded-For {remote}
    header_upstream X-Forwarded-Proto {scheme}
  }
  gzip
  header / -Server
  header / Strict-Transport-Security "max-age=31536000;"
  tls user@example.com {
    protocols tls1.0 tls1.2
    dns cloudflare
  }
}

如果要使用 DNS 的方式认证域名的话，需要设置环境变量，修改 /etc/systemd/system/caddy.service ，加入环境变量，我使用的是 CloudFlare 的 DNS，所以我需要添加 CLOUDFLARE_EMAIL 和 CLOUDFLARE_API_KEY ，其他 DNS 看这里。

[Service]
...
...

Environment=CADDYPATH=/etc/ssl/caddy
+ Environment=CLOUDFLARE_EMAIL=xxx
+ Environment=CLOUDFLARE_API_KEY=xxx

...
...

写完配置后输入 sudo systemctl start caddy.service 启动 Caddy。

输入 journalctl --boot -u caddy.service 可以查看日志。

启用 QUIC

关于 QUIC 的介绍，可以看一下这篇文章，一句话概况呢就是减少 TLS 握手次数，加快网站速度。

修改 /etc/systemd/system/caddy.service ，在 ExecStart=/usr/local/bin/caddy -log stdout -agree=true -conf=/etc/caddy/Caddyfile -root=/var/tmp 后面加上 -quic ，即

ExecStart=/usr/local/bin/caddy -log stdout -agree=true -conf=/etc/caddy/Caddyfile -root=/var/tmp -quic

然后重新加载 Systemd，并重启 Caddy

sudo systemctl daemon-reload
sudo systemctl restart caddy.service

同时，别忘了给主机开放 443 (UDP) 端口。

~~目前 QUIC 只有 Chrome 支持，并且需要手动开启（默认只有白名单域名启用）。访问 chrome://flags/#enable-quic，切换为 Enabled 即可。~~

目前 Chrome 已对所有域名开放 QUIC，同时 HTTP/3 将使用 QUIC。开启后，重启 Chrome，访问网站，通过 Chrome DevTools - Security 可以看到协议已经是 QUIC 了。

关于性能

Caddy 是 Go 写的，性能方面是稍落后于 Nginx 的，但其实对于小站来说，这一点性能差距是可以忽略的，毕竟 You Are Not Google 。

Google Analytics 加载优化

Mon, 17 Jul 2017 18:54:48 GMT

最近给网站加上了 Google Analytics（大概两年前，我刚换到 Hexo 的时候，我就把统计撤了，看到 LWL 的群里在晒统计结果，心里痒痒又加上了）。但是直接使用 Google Analytics 有一点弊端：一是会被各种广告屏蔽软件屏蔽，导致统计结果不准确；二是在国内加载不稳定。

因此，我给 Google Analytics 加了一层代理，优化加载速度同时防止被屏蔽。

GitHub Repo （求 Star🌚

序

目前关于 Google Analytics 大致有两种方案，一种是本文使用介绍的，另一种是利用 Nginx 的 post_action。

前者需要多一次 HTTP 请求，后者有点麻烦，还要过滤搜索引擎 UA，不适用于使用 CDN 的网站。

本文所采用的方案是基于 Google Analytics 异步请求（服务端请求）提供的代码修改的 Go 版本。

使用方法

1. 使用我提供的服务

将下面的代码加到你的网站的任意位置，同时修改 "UA-xxxx-x" 为你自己的跟踪代码。

!(function (a, b, c, d, e) {
  var f = c.screen,
    g = encodeURIComponent,
    h = [
      'ga=' + a,
      'dt=' + g(d.title),
      'dr=' + g(d.referrer),
      'ul=' + (e.language || e.browserLanguage || e.userLanguage),
      'sd=' + f.colorDepth + '-bit',
      'sr=' + f.width + 'x' + f.height,
      'vp=' +
        Math.max(d.documentElement.clientWidth, c.innerWidth || 0) +
        'x' +
        Math.max(d.documentElement.clientHeight, c.innerHeight || 0),
      'z=' + +new Date(),
    ];
  (c.__ga_img = new Image()), (c.__ga_img.src = b + '?' + h.join('&'));
})('UA-xxxx-x', 'https://ga.giuem.com', window, document, navigator, location);

目前已经部署海外线路（由 CloudFlare 提供），国内为腾讯云上海机房

2. 自己部署服务

安装
你可以选择自己编译或者从 release 下载我编译好的二进制文件。

运行

./ga_proxy [arguments]

参数：

-d, -debug 输出调试信息
-s, -skip_ssl 跳过 SSL 验证
-l, -listen 监听地址

要使用后台运行，你可以借助 nohup 或 screen 或 Docker。

添加 JavaScript 代码
把上面的那段代码里的 "https://ga.giuem.com" 改成你自己的地址就行了。

使用效果

整个请求花费 33 ms, 156 B 流量可以说是非常快了。服务器的 Ping 值在 29 ms 左右，中间 4 ms 的损失主要花在 SSL 上了，速度还是挺不错的。

相比之下，原生的请求先加载了一个 12.3 KB 大小的 JS 文件，然后才发送统计，总耗时 300 ms，emmmmm 我就不作过多评价了。

使用 Travis CI 自动部署 HEXO 博客

Sat, 13 May 2017 15:02:47 GMT

If you see this post, then it works!

用得好好，就不要瞎折腾

缘起

最近因为 Coding Pages 的自定义域名收费了，一时也找不到比较好的支持 SSL 的 Pages 服务（GitLab Pages 虽然支持 SSL，但是要自己提供证书，感觉还不是很方便）。看了这个帖子后，还是决定将博客放到自己的 VPS 上。

流程

博客的源代码放在 GitHub 上，一更新就通过 Travis CI 自动 generate 并 push 到另外一个 repo，这个 repo 通过 webhook 的方式通知 vps，vps 更新文件。

整个流程可以说是非常非常麻烦，我弄好后突然发现可以通过 Dropbox 进行本地与 vps 的同步。。。

一些参考

.travis.yml

language: node_js
node_js:
  - '6'

cache:
  directories:
    - node_modules

branches:
  only:
    - master

install:
  - npm install

script:
  - hexo cl
  - hexo g

after_script:
  - cd ./public
  - git init
  - git config user.name "giuem"
  - git config user.email "email_adress"
  - git add .
  - git commit -m "auto deploy via Travis CI."
  - git push --force --quiet "path-to-your-repo" master:pages

为了方便，我直接把存放源文件和静态页面放在同一个 repo 的不同分支下，这样就不用在添加 ssh 密钥了。

deploy

~~这个我直接做成 Docker 镜像了~~

发现有几个配置写死了，直接给代码好了

deploy.sh

#!/bin/sh

rm pages -rf
git clone -b pages https://$GITHUB_TOKEN@github.com/giuem/blog.git pages

webhook.js

const http = require('http');
const crypto = require('crypto');
const exec = require('child_process').exec;

const secret = process.env.SECRET || false;
const port = process.env.PORT || 8089;

function verify_signature(sign, body) {
  if (!secret) return true;
  return (
    sign ===
    'sha1=' + crypto.createHmac('sha1', secret).update(body).digest('hex')
  );
}

http
  .createServer((req, res) => {
    if (
      req.method === 'POST' &&
      req.url === '/auto-deploy' &&
      req.headers['x-github-event'] === 'push'
    ) {
      let body = '';
      let sign = req.headers['x-hub-signature'];

      req.on('data', (buffer) => {
        body += buffer;
        if (body.length > 1e6) {
          req.connection.destroy();
        }
      });

      req.on('end', () => {
        if (verify_signature(sign, body)) {
          let json = JSON.parse(body);
          if (json['ref'].indexOf('pages') !== -1) {
            console.log('Verify successfully, now start deploying...');
            exec('sh ./deploy.sh');
          }
        }
        res.end();
      });
    } else {
      res.end();
    }
  })
  .listen(port, () => {
    console.log('service start at', port);
  });

总结

折腾了一圈突然发现还是动态博客好，重新体验了下。发现 WordPress 还是不支持 Markdown，Ghost 新版用了 mobiledoc 听都没听过，最后又滚回 HEXO 了。。。

没事真的别折腾，不如多写几道高数题！

Gogs + Docker 建立自己的 Git 服务器

Sun, 02 Apr 2017 23:20:35 GMT

Github 的私有仓库是收费的，学生包申请很麻烦，就一直没去弄，至于国内的一些 Git 托管……请给云计算一点宽容。所以就利用 Gogs 搭建自己的 Git 服务器来托管一些个人项目。

~~演示地址（关闭注册，强制登录浏览，所以只有登陆页面）~~

已经改为使用 GitHub 私有仓库了，学校的邮箱申请秒过，自己维护感觉还是太麻烦了（囧

Gitlab or Gogs

Gitlab 对服务器的配置要求太高，手上的服务器全都是捡垃圾来的小鸡，所以就没有考虑。

而 Gogs 对配置基本没有要求，甚至只要一块树莓派就能运行，虽然说现在还有许多 bug ，Github 上那么多的 issue 和 pr 没解决。（不过反正是自己用，有什么问题忍忍就过去了

安装

我是利用 Docker 进行部署的，关于 Docker 有时间可能会写一篇文章安利下。总之，Docker 部署各种应用真是不要太简单，几行命令敲一敲就行了，不用关心宿主机的环境依赖。

如果还没主机上没有安装 Docker，可以看下安装方法

拉取镜像

$ docker pull gogs/gogs

建立目录

$ mkdir -p /var/gogs

目录不一定是 /var/gogs，你也可以放在 /home 下

初始化

docker run --name=gogs -p 10022:22 -p 10080:3000 -v /var/gogs:/data gogs/gogs

这里的 /var/gogs 需要改成上一步创建的目录，端口号 10022、10080 可以换成其它的。

之后如果要管理 Gogs 就可以直接输

$ docker [start|stop|restart] gogs

配置

访问 http://<ip>:<port> 进行配置

配置中有几个参数是比较重要的：

Repository Root Path 和 Run User ：保持默认
Domain：改成你要设置的域名或 ip 地址，如 git.giuem.com
SSH Port 和 HTTP Port ：改为启动时暴露的端口，如 10022 和 10080
Application URL：完整的访问地址，如 https://git.giuem.com

数据库我选择的是 SQLite3，考虑到内存占用，没有选择 MySQL，而且个人使用 SQLite3 足够了。

其他的配置可以 看这里，配置文件在 /var/gogs/gogs/conf/app.ini，改完配置重启 Docker 容器就行。

备份数据

Gitlab 误删数据库，所有的备份方法都失效的事件才发生不久。我也是吸取了教训，搭完 Gogs 立马写了个脚本定时备份。

目前采用的方案是每天凌晨自动打包 /var/gogs 目录下所有文件上传到 Dropbox，用的是 Dropbox Uploader

等过段时间再折腾下 rsync 就稳了。。

附

运行时资源占用图

后台界面

在 Linux 上搭建一个求生之路 2 服务器

Tue, 27 Dec 2016 23:22:52 GMT

圣诞节 Steam 特惠，几个室友约着一起买了求生之路 2，13 元的价格还算便宜。但打了一把后发现官方服务器卡的不行，根本不能秀操作。然后因为我们是每人一台路由器，局域网联机不是特别方便，于是我自告奋勇搭了个服务器。当然，主要是我又想折腾那台学生机了。

我使用的是官方提供的 SteamCMD 搭建的，后来我发现竟然有个工具，搭建起来方便多了。不过那时我已经搭好了，就没折腾这个工具。

服务器

基本配置：1 核 1GB 1Mbps
硬盘：20G
系统：Ubuntu Server 16.04.1 LTS 64 位

我这配置跑服务器 CPU 利用率大概在 20%，内存使用不超过 40%，占用带宽大约为 0.4 Mbps。但要注意的是，整个求生之路大约占 8G 硬盘空间，所以确保你的服务器有这么多的空间。以下操作都是基于 Ubuntu，其他系统可以看一下官方文档。

安装 32 位运行库

如果你使用的是 64 位的系统，则需要安装 32 位的运行库。

sudo apt-get install lib32gcc1

下载 Left 4 Dead 2 Dedicated Server

mkdir ~/steamcmd
cd ~/steamcmd
wget https://steamcdn-a.akamaihd.net/client/installer/steamcmd_linux.tar.gz
tar -zxvf steamcmd_linux.tar.gz
./steamcmd.sh

完成后，匿名登陆服务器。（某些游戏不能匿名登陆下载，具体看这https://developer.valvesoftware.com/wiki/Dedicated_Servers_List）

Steam>login anonymous

指定下载目录

Steam>force_install_dir /home/ubuntu/l4d2

下载服务端，下载指令是 app_update <app_id> [-beta <betaname>] [-betapassword <password>] [validate] app_id 可以在上面的链接找到。

Steam>app_update 222860 validate

下载完成后会提示 Success! App '222860' fully installed.，这时候输入 quit 退出即可。

因为我的机器在国内，由于不可抗拒的因素，下载不稳定，所以下载前我还特意开了梯子。

配置 Left 4 Dead 2 Dedicated Server

新建配置文件

cd /home/ubuntu/l4d2/left4dead2/cfg/
vi server.cfg

配置文件内容如下：

hostname "servername"    //游戏服务器名
rcon_password "password" //远程管理密码
//sv_search_key yourkey  //搜索此服务器的关键词
//sv_region 255          //服务器地区，255表示全球
//sv_gametypes "coop,versus,survival,scavenge" //游戏模式
//map c5m1_waterfront    //游戏地图
//sv_voiceenable 1       //开启语音服务
//sv_lan 0               //是否是局域网游戏
//sv_cheats "0"          //是否允许作弊

//sv_steamgroup "01234"  //Steam组号
//sv_steamgroup_exclusive 1 //将服务器设为Steam组私有

事实上，我们只需要这几句就够了

hostname "xxx"     //游戏服务器名
sv_steamgroup "12345"     //Steam组号
sv_steamgroup_exclusive 1 //将服务器设为Steam组私有

然后创建一个组，把好友拉进去，这样就行。

运行服务器

cd /home/ubuntu/l4d2
./srcds_run -game left4dead2 +exec server.cfg

运行成功后，记得开放对应的端口，端口默认是 27015 ，具体端口可在显示的信息中找到。

这时如果关了 SSH 窗口，服务器就关闭了，可以借助 screen 或 nohup 实现后台运行。

参考

搭了一个签到站

Sat, 24 Dec 2016 22:14:31 GMT

最近要期末了，感觉就很忙（这学期太浪了，天天打屁股。前段时间抢了一台腾讯学生机，闲着也是闲着，就搭了一个签到站，顺便学了下怎么配置 SSL。

网站程序

这个签到站使用了 binux / qiandao ，闲着无聊没事干可以自己搭，不过我还是推荐自己使用作者本人的网站 qiandao.today

SSL

8 月 4 日更新，目前已经转到 Caddy -> Ref.

网站地址 https://qd.gops.win/ ，在 SSL LABS 得分 A+。

要 A+ 其实很简单的，照着屈屈的这篇文章配就行了。

目前使用的是 le 的 ECC + RSA 双证书，安利 acme.sh 这个脚本，用了来签发证书挺方便的。

（这个博客感觉要被我荒废了，哎，还是太懒了，不想更新

另外，祝大家圣诞快乐，鸡年大吉吧。

网页字体优化之字体异步加载

Sat, 24 Sep 2016 22:01:14 GMT

网页字体一直以来都是一个令人头疼的问题，一方面想要页面更美观引入字体，另一方面又想要加快页面加载速度。而今天我要介绍的这款 JS 库，很好的解决了这个问题，它能将你的字体文件异步加载，不影响页面渲染。

引子

说起网页字体的优化，我很容易就想到了下面几种方法：

使用 CDN 分发你的字体文件，对于 Google Fonts 可以更换为国内反代的 CDN（虽然目前 Google Fonts 的服务器已近指向国内，但是速度、稳定性不是很理想）。
内联字，以 Base64 的方式将字体文件嵌入 CSS 文件中。https://amio.github.io/embedded-google-fonts/ 是 V2EX 上一个人写的小程序，可以将 Google Fonts 转化为 Base64 内联到 CSS 中。用这种方法再结合 CDN，效果还不错。
使用字蛛精简字体文件。本方法尽针对中文字体，具体实现方式移步：字蛛（好吧，我承认第三点是我拿来凑数的- -）

而我今天要介绍的，是一个能将字体异步加载的 JS 库，它的地址是：typekit/webfontloader 。好了，本文到此结束。

哈，开个玩笑。虽然说原文档讲得很详细了，但我觉得我还是要简单说明一下。

使用方法

这里我只是讲解一下异步加载 Google Fonts 的方法，以及这里面藏着的一个小坑。

引入 JS

首先，当然是要先引入 JS。演示代码使用的是七牛（staticfile）提供的 CDN。

<script src="//staticfile.qnssl.com/webfont/1.6.16/webfontloader.js"></script>

我博客目前的方案是我之前介绍过的 basket.js ，感兴趣的话可以 Ctrl + U 看一下具体实现方式。

运行 webfontloader

官方给出的例子非常简单

WebFont.load({
  google: {
    families: ['Droid Sans', 'Droid Serif'],
  },
});

但是这样子只能使用原生的 Google Fonts，不能使用反代的 CDN，怎么办呢？这里就是我上面讲的那个小坑，官方文档并没有说明。

刚开始发现这个问题的时候，我就去翻看源代码，想把原地址替换成国内反代的 CDN，然而我不小心发现了一个参数，可以指定 API。

于是代码变成下面这样：（其中 https://cdn.moefont.com/fonts/css 是自定义的 API 地址，你可以换成其他的）

WebFont.load({
  google: {
    families: ['Droid Sans', 'Droid Serif'],
    api: 'https://cdn.moefont.com/fonts/css',
  },
});

好了，添加完 JS，让我们来看一下效果如何吧。咦，页面的加载怎么还是老样子？？好吧，其实还要最后一步：修改 CSS

修改 CSS

第二布，我们需要对原有的 CSS 进行修改。

这里我举个简单例子：

我们原来的 CSS 是这个样子的：

body {
  font-family: 'Open Sans', 'Microsoft YaHei';
}

Open Sans 是 Google Fonts，也是造成页面字体空白的元凶。现在我们要把它揪出来，代码变成这样：

body {
  font-family: 'Microsoft YaHei';
}

然后再加上一行但字体文件载入时的 font-family

.wf-active body {
  font-family: 'Open Sans', 'Microsoft YaHei';
}

这样再浏览页面，可以发现 webfontloader 生效了。

我这里只是讲一下简单的用法，其他比如加载 iconfont 等本地字体还有一些高级用法请看官方文档。

效果演示

为了说明 webfontloader 给用户体验带来的提升，我做了一个对比。为了模拟极端环境，我利用 Chrome DevTools 把网络模拟为 GPRS。上面为普通加载方式，下面使用 webfontloader 加载。

一些题外话

高考完的这几个月疯狂划水，玩了一暑假屁股，无暇更新博客。。现在上大学了，生活也稍微规律点，接下来会逐步发表一些文章。嗯，我要扯的就这些。

高考成绩出来辣

Thu, 23 Jun 2016 20:25:04 GMT

下午 4 点多成绩就出来了，查询的时候手一直在抖。我之前有预想到我会考砸，没想到发挥还算正常。害得我这几天一直提心吊胆的，连博客都没有及时更新。现在成绩出来了，等填完志愿博客就恢复正常啦。

至于我的成绩，总分 628 分，全省 900+ 名（福建省教育就是这么渣

对于填报志愿，不知道大家有没有什么建议？

自定义百度网盘分享密码 (Javascript)

Sat, 05 Mar 2016 20:46:37 GMT

最近看到几个小伙伴的博客都在说这个自定义密码的，作为高三狗的我忍不住也要插上一脚了。。

首先看下效果吧。（一不小心就开车了）

地址：http://pan.baidu.com/s/1o7bIomm
密码：帅B

原理

分析代码发现，百度网盘的自定义密码是在本地生成的

这也就给了我们玩耍的机会。

实现方法

不二和 LiesAuer 他们都是采用构造请求的方法，我觉得不够 hacker，而且不太方便。

所以我决定采用 JS 的方式修改密码。

方法很简单：修改 makePrivatePassword 这一函数即可。

具体代码

说明：代码可以转载，但请不要说是你原创之类的话！！！

压缩版

javascript: require([
  'function-widget-1:share/util/service/createLinkShare.js',
]).prototype.makePrivatePassword = function () {
  return prompt('请输入自定义的密码', '1234');
};

原版

require([
  'function-widget-1:share/util/service/createLinkShare.js',
]).prototype.makePrivatePassword = () => {
  return prompt('请输入自定义的密码', '1234');
};

使用方法

别急，你可别复制走代码就用了，一不小心就会出现这样的错误：

Uncaught Error: Cannot find module `function-widget-1:share/util/service/createLinkShare.js`(…)

首先，选择要分享的文件，点击分享按钮。

这时候，按 F12 打开控制台，切换至 Console ，输入代码按回车即可。当然，你也可以存为书签，点一下书签。

然后点击创建私密链接，会弹出输入框，输入密码即可！

注意使用代码前要先点一下 分享 按钮，相关模块才会载入，这时候用代码才有效果。

密码类型

必须是 4 个字符。如：

abcd
1234
ab12
啊 a （中文加一个数字或字母）

其他类型请各位自己探索，可在下方给我留言。好像如果密码有中文，第一次访问时会提示错误，刷新一下才正常。

PS：这可能是高考前最后一次更新了，各位可别想我啊

使用 basket.js 缓存页面静态文件

Sun, 20 Dec 2015 14:55:50 GMT

最近对博客进行了一次很大的修改，比如使用 jQuery 和 Pjax。当然，还有本文要介绍的 basket.js。

basket.js 是什么

basket.js 是一个 javascript 类库（废话），它可以将页面中的 css、js 文件缓存到 localStorage 中，下次访问时直接读取 localStorage 的内容，大大减少了加载时间。而且 basket.js 本身非常小，gzip 压缩后只有 5 kb 左右。

使用

首先引入 javascript 代码，推荐使用下面 cdn （支持 SSL）。

//dn-staticfile.qbox.me/basket.js/0.5.2/basket.full.min.js
//cdn.css.net/libs/basket.js/0.5.2/basket.full.min.js
//cdn.bootcss.com/basket.js/0.5.2/basket.full.min.js

使用也很简单，看一段我博客的代码就知道了。

basket
  .require(
    // 引入 jQuery
    { url: '//dn-staticfile.qbox.me/jquery/2.1.4/jquery.min.js' }
  )
  .then(function () {
    // 按顺序引入，避免 jQuery Plugin 先于 jQuery 引入
    basket.require({ url: '/js/main.js', unique: '1' });
  });

具体使用方法看官方文档（其实是我翻译不下去了，哈哈）

效果

首次访问

二次访问不缓存

二次访问缓存

可以看到，效果还是不错的，如果页面不引入字体的话，还可以更快。

如何删除 Wormhole 后门

Sun, 08 Nov 2015 15:02:38 GMT

上文我们提到了 Wormhole 的相关危害，既然百度目前没有删除这个后门的打算，那么我就应该采取一些手段主动删除这个后门。

漏洞自检

使用终端模拟器

$ netstat

查看 40310/6259 是否被监听

从上图可以看到，我手机上的 40310 端口被监听了

删除漏洞

未 Root

对于未 Root 用户，最好的方法就是卸载所有百度的 APP

已 Root

如果你的手机已经 Root ,那么我们可以使用神器 My Android Tools 禁用相关服务。

首先，选择 服务 ，找到百度系的 APP （如：百度地图）进入。然后禁用 MoPlusService。

一般禁用了这个，后门就关闭了。如果不放心，可以选择 广播接收器 禁用以 MoPlus 开头的组件，如：MoPlusReceiver 之类的。

最后别忘了检查一下对应的端口是否关闭，如果没有关闭，那说明还有其他 APP 存在这个后门。

浅谈 Wormhole 及相关测试

Sat, 07 Nov 2015 20:33:33 GMT

葫芦娃葫芦娃，一根藤上七朵花，风吹雨打都不怕，啦啦啦啦，叮当咚咚当当，葫芦娃。看到这个 Wormhole 漏洞，脑海里不知不觉就浮现出这一小段歌词。

那么，这个漏洞到底是什么呢？切确的说，这是一个有“漏洞”的后门。百度开放这个后门，主要是为了方便 XX。它通过监听本地 40310/6259 端口，从而使网页端（百度搜索，百度统计等）和 APP 进行“通信”。

漏洞伊始

这个后门是通过判断 remote-addr 请求头来确定是否为本机访问，但不幸的是，这个字段是可以伪造的，导致任意联网上的设备都可以通过这个后门来获取、修改你手机上的敏感信息！

功(wei)能(hai)

从图中可以看到，这个后门有如下功能：

geolocation 获取用户手机的 GPS 地理位置（城市，经度，纬度） getsearchboxinfo 获取手机百度的版本信息 getapn 获取当前的网络状况（WIFI/3G/4G 运营商） getserviceinfo 获取提供 nano http 的应用信息 getpackageinfo 获取手机应用的版本信息 sendintent 发送任意 intent 可以用来打开网页或者与其他 app 交互 > getcuid 获取 imei getlocstring 获取本地字符串信息 scandownloadfile 扫描下载文件(UCDownloads/QQDownloads/360Download...) > addcontactinfo 给手机增加联系人 > getapplist 获取全部安装 app 信息 > downloadfile 下载任意文件到指定路径如果文件是 apk 则进行安装 > uploadfile 上传任意文件到指定路径如果文件是 apk 则进行安装

利用

既然漏洞并没有被修复，那么我们就可以对其就行利(wan)用(shua)。前面已经说到，由于对请求来源的判断可以伪造，所以只要你的手机暴露与公网之上，那么就有被入侵的危险。

由于这个漏洞有较大危害，所以我这里就不放出代码了。

获取手机安装的 APP 信息

获取 GPS 地理位置

其他

我还尝试打开任意网页和添加联系人的功能，但由于对 java 的理解有限，不能很好解读代码，其他的功能就不演示了。

可能的利用方法

扫描 IP
在网站中插入恶意的 JS ，调用 Wormhole

扩展阅读

我是如何去除烦人的泰文字符的

Sat, 12 Sep 2015 17:16:36 GMT

相信你们一定在一些社交网站上看到有人发泰文字符，严重影响了正常的阅读。作为开发者，我们应该采取一些措施解决这个问题。

PHP

首先，我想到的就是在后端处理，数据入库前清除所有泰文字符。至于清除方法，自然是用正则了。从维基百科上我们可以得到泰文的 Unicode 范围：U+0E00–U+0E7F。不过后来我翻了下 PHP 手册，其实不用写 Unicode 范围，直接使用 Thai即可。代码大概是这样：

function fuckThai($str){
    return preg_replace('/\p{Thai}/u','',$str);
}

或者是

function fuckThai($str){
    return preg_replace_callback('/\p{Thai}/u',
        function(){
            return '';
    },$str);
}

使用的话就是fuckThai('泰文')

这样一劳永逸，不过如果网站有泰国的用户就不太好了。。

CSS

用 CSS 也是可以解决的，不过不太完美，只能让泰文字符不“乱飞”。

具体效果如图：（红色边框是我为了更好显示特意加上去的）

方法很简单，给对应元素加上 overflow: hidden 的 CSS 即可。

最后

如果我们想在浏览贴吧时不被这些泰文烦恼，我们可以写一个 油猴 脚本对内容就行处理，思路同上面的PHP，具体代码我这里就不写了。其实是没写过油猴的，不会写（逃

参考

PHP:Unicode 字符属性

纯 CSS 实现小三角形

Mon, 22 Jun 2015 21:32:05 GMT

最近写 CSS 时正好需要一个小三角形来修饰 tooltip。尝试几种写法都不太满意，因为我的需要的三角形是没有颜色但有边框的，后来果断选择使用 border 实现。

先上效果图：

没错，这就是我那个写了很久的评论系统（其实是因为偷懒）。

问题思考

开头已经说过，我使用的是 border，但 border 不能设置边框（就是周围那一圈），有什么办法解决呢？

刚开始时，我想不出办法，于是想用特殊符号 ▼ 结合 text-shadow 实现，但这个三角形太丑了，而且和字体有关，所以这个方案被我舍去了。

后来仔细一想：我可以用两个 border 实现啊，第一个和第二个上下间距为 1px，上面覆盖下面，下面那个颜色为边框颜色，不就可以了。尝试之，果然可以！

代码

因为我有洁癖，就是尽可能少写 HTML，所以三角形功能用的是 CSS 伪类 ::before 和 ::after。这样代码会多出几行，其实你们可以将伪类改为元素。

HTML

<div class="tooltip">This is a tooltip.</div>

CSS

.tooltip {
  background-color: #fff;
  border: 1px solid #eee;
  position: relative;
  max-width: 300px;
  padding: 10px;
}
.tooltip::before {
  position: absolute;
  color: #eee;
  width: 0;
  height: 0;
  content: '';
  border-width: 5px 4px 0;
  border-style: solid;
  border-left-color: transparent;
  border-right-color: transparent;
  bottom: -5px;
  left: 10px;
}
.tooltip::after {
  position: absolute;
  color: #fff;
  width: 0;
  height: 0;
  content: '';
  border-width: 5px 4px 0;
  border-style: solid;
  border-left-color: transparent;
  border-right-color: transparent;
  bottom: -4px;
  left: 10px;
}

为了方便显示，这里的 tooltip 的 position 是 relative，我在实际使用中是 absolute + JavaScript 计算地址修改 top 和 left。

说说 CloudXNS，一个免费DNS解析服务

Fri, 19 Jun 2015 19:17:08 GMT

使用 CloudXNS 已有 3 个多月了，还记得当初是看到 TYPCN 在博客上的推荐，才“入坑”的。

0x00 为什么是 CloudXNS？

随着网络的发展，用户处在不同的运营商网络中，当用户跨运营商跨地区访问的时候，智能 DNS 平台使访问网站的联通用户访问联通的服务器，电信的用户访问电信的服务器，提升网站速率。 CloudXNS 是在传统 DNS 系统上加入策略解析后的高级智能 DNS 系统，可以判断用户来源，就近访问调度。不但拥有主流 DNS 产品的全部功能，而且扩展有自己独有的解析记录类型，在解析速度方面也明显优于国内其他同类产品，它的解析速度比传统 DNS 快两到三倍，DNS 配置生效更快，可做到实时生效。

详情：了解 XNS:选择 CloudXNS 的九大优势

0x01 CloudXNS 拥有众多线路

因为我目前只是一个小博客，暂时没有这方面的需求，所以这个功能对我来说用处并不是很大。但是因为它，使我的博客在备案期间伪关站。

我将线路切换到 海外默认 和 搜索引擎默认 保证了搜索引擎的正常抓取以及部分有特殊上网技巧的人可以访问的我博客。

0x02 CloudXNS 提供实时宕机报警，并且可以智能切换节点

我在用 Gitcafe Page 的时候，他们提供服务器经常宕机，多亏 CloudXNS 让我可以及时了解服务器动态（不过我那时并没有在 GitHub Page 上搭建备用博客，所以没有尝试智能切换）

0x03 统计数据全面

这是我今天（2015/6/19）的解析统计：

按运营商查看：

0x04 CloudXNS 提供免费的 CDN 服务

MX 和 CNAME 记录是不能共存的，如果我想在裸域上使用 CDN 又不影响邮箱服务，很明显是不大可能的。

但是 CloudXNS 提供的 CDN 就完美的解决了问题。

点击启用：

设置页面：

0x005 END

本文只是介绍我目前所使用到的功能，想了解更多 CloudXNS 的功能（如：利用 CNAMEX 实现多 CDN），请访问官网。

也谈最近PHP的漏洞 CVE-2015-4024

Sat, 23 May 2015 18:58:34 GMT

5.20 本是一个对于我来说十分宁静的日子，然而就当我在 V2EX 瞎逛的时候，发现了一个令我高潮的贴子宇宙最强语言 PHP 爆出 DoS 漏洞,可以直接灌满 CPU，我 X！这是什么鬼！

进去一看，原来是 PHP 最新的 DoS 漏洞，想了解详情移步：https://bugs.php.net/bug.php?id=69364，本文不再说明漏洞产生原因。

利用

本来想等回家了再写个利用脚本，没想到 typcn 当天就写出来了。那么，我们就使用他的代码吧。据说，利用这个 BUG 10M 带宽就可以崩掉集群。

GitHub | PHP 压力测试脚本 - 10M 带宽秒杀集群

适用 PHP 版本：

PHP 5.6.9 以下版本
PHP 5.5.25 以下版本
PHP 5.4.41 以下版本
PHP 5.3 及所有以前的版本

使用方法

python xxx.py -t "地址" -x "线程数" -r "350000"

PS: 用自家网络攻击可能效果不明显，我家上行 2M 打了 sae 半天都没反应。。线程一般 50 - 100 就行，太高电脑直接卡了。

修复

升级 PHP 版本，具体请看PHP 官网。
如果你使用虚拟主机，可以提醒主机商升级。

拓展

PHP multipart/form-data 远程 DOS 漏洞

扯淡（以下内容与本文无关）

最近我又开始想换博客程序了，挺看好 Ghost 的，但虚拟主机支持 Node.js 好像很少吧？就国内那几个 PaaS 平台。然后，我又想把网站备案了，迁入国内服务器，真是太纠结了。。。

PHP中“==”的一些坑

Sat, 09 May 2015 21:14:35 GMT

PHP 是弱类型的语言，会自动进行数据类型转换，这无疑给我们的开发带来了极大的方便。可事实真是如此吗？今天我们就从==说起。

栗子

首先，看一下这段代码。猜猜看结果会是什么

<?php
var_dump(md5('240610708') == md5('QNKCDZO'));
var_dump(md5('aabg7XSs') == md5('aabC9RqS'));
var_dump(sha1('aaroZmOk') == sha1('aaK1STfY'));
var_dump(sha1('aaO8zKZF') == sha1('aa3OFF9m'));
var_dump('0010e2' == '1e3');
var_dump('0x1234Ab' == '1193131');
var_dump('0xABCdef' == ' 0xABCdef');

var_dump(0 == 'abcdefg');
var_dump(1 == '1abcdef');
?>

一眼看过，很明显肯定都是false吧，但运行代码后发现全是true！

WTF!

为什么会这样

开头我已经说过了，PHP 是弱类型的语言。使用==对比两个变量时，当有一个变量为整数，另外一个变量也会转换为整数。这也就解释了，为什么0 == 'abcdefg'和1 == '1abcdef'会成立。

但是，其他的代码呢？字符串难道还会转换？

PHP 手册上为我们提供了解释说明。

If you compare a number with a string or the comparison involves numerical strings, then each string is converted to a number and the comparison performed numerically.

也就是说，如果你比较的两个字符串涉及到数字（如："0"），那么每个字符串都会转换成数字。

在这里，我不得不说：PHP 是最好的语言！

危害

当我们的网站是直接MD5或Sha1加密而没有加盐，碰巧某用户密码加密涉及到数字，那么就有可能被碰撞破解！

解决

在开发过程中尽可能避免使用==判断两个变量的值
密码加密最好使用password_hash()或者加盐md5($pwd.$salt)

参考 && 拓展阅读

把树莓派变成一个下载机

Sat, 04 Apr 2015 15:45:01 GMT

树莓派入手一段时间了，一直就当成贴吧云签到。最近买了块 1T 移动硬盘，加上家里的 20M 光纤，正好拿来做 NAS。

准备工作

树莓派的电源是带不动移动硬盘的，所以需要一个带有独立电源的 USB HUB。然后我上淘宝买了个绿联的 4 口 USB HUB，18 元包邮。（一条 5 毛，发贴记得删除括号里内容！）

挂载硬盘

格式支持。

sudo apt-get install ntfs-3g
sudo apt-get install exfat-nofuse

挂载

输入 fdisk -l 查看是否挂载成功。如果成功，你会看到类似下图的信息。

然后新建一个目录作为挂载点

mkdir /mnt/nas
nano /etc/fstab
# 在最后一行加入
/dev/sda1 /mnt/nas ntfs-3g defaults,noexec,umask=0000 0 0

然后重启。

aria2

我打算使用 aria2 作为下载工具（迅雷渣渣）

安装

sudo apt-get install aria2 apache2
sudo visudo
# 在底部增加这一行
www-data ALL=(ALL) NOPASSWD: ALL

mkdir ~/.aria2
touch ~/.aria2/aria2.session
nano ~/.aria2/aria2.conf

在 aria2.conf 写这些

# 下载默认的目录
dir=/mnt/nas
disable-ipv6=true
enable-rpc=true
rpc-allow-origin-all=true
rpc-listen-all=true
#rpc-listen-port=6800
continue=true
#刚才touch命令的那个文件，路径要绝对路径
input-file=/root/.aria2/aria2.session
#同上，这个文件的作用是保存你的下载列表，不保存的话重启后所有下载都木有了
save-session=/root/.aria2/aria2.session
max-concurrent-downloads=3

之后运行 aria2c –conf-path=/root/.aria2/aria2.conf ，没有错误就可以退出了。

把 aria2 做成系统的服务： sudo nano /etc/init.d/aria2c

#!/bin/sh
### BEGIN INIT INFO
# Provides:          aria2
# Required-Start:    $remote_fs $network
# Required-Stop:     $remote_fs $network
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Aria2 Downloader
### END INIT INFO

case "$1" in
start)

echo -n "Starting aria2c"
sudo -u root aria2c --conf-path=/root/.aria2/aria2.conf -D
#sudo -u后面的是你正在使用的用户名
;;
stop)

echo -n "Shutting down aria2c "
killall aria2c
;;
restart)

killall aria2c
sudo -u root aria2c --conf-path=/root/.aria2/aria2.conf -D
#同上面的一样，根据自己的用户名改。
;;
esac
exit

然后设置这个文件的权限：

sudo chmod 755 /etc/init.d/aria2c

测试服务是否可以启动：

sudo service aria2c start

如果只显示 Starting aria2c，没有其他错误提示的话就成功了。

添加 aria2c 服务自动运行：

sudo update-rc.d aria2c defaults

Aria2 相关的好了，下面开始网页控制 aria2 下载。

cd /var/www
git clone https://github.com/binux/yaaw

这个是别人汉化好的，不过在 GitHub 下载速度可能有点慢。

然后访问 ip/yaaw，如我的是 192.168.0.137/yaaw。就可以开始下载了。

文件下载测试

PHP判断一个字符串是否是有效的邮箱地址

Sat, 04 Apr 2015 14:19:23 GMT

清明放假回家刚好有一点时间，于是开始写评论系统了。而我本身非常注重程序的安全性，所以自然是要对所有的输入进行检查。做到邮箱检查时，本来想使用正则来判断，但感到非常不优雅，就上 Google 查了些资料。

filter_var

不得不说，这个函数其实我也是今天才见到。在 PHP 5.2 以上版本才有，不过现在至少都 5.4 了吧。

if (!filter_var($email, FILTER_VALIDATE_EMAIL)) {
    // invalid emailaddress
}

这个代码只能检测邮箱地址是否有效，如果我想检测是否存在这个邮箱呢？

办法是有的。

checkdnsrr

用 checkdnsrr 函数可以检测主机的 DNS，只要我们检测一下邮箱对应的域名是否有 MX 记录，就能知道这个邮箱是否真实存在了。

其中 domain 还需你自己从邮箱中取出来。

if (!checkdnsrr($domain, 'MX')) {
    // domain is not valid
}

参考

获取Bing每日壁纸用作首屏大图

Tue, 24 Feb 2015 20:46:27 GMT

Bing 搜索每天都会更换一张精美的图片作为壁纸，除了特殊时候不太好看外（比如春节那几天），没多大问题。移动端还有上每日故事，与图片现配。现在我的博客首屏图片就是 Bing 每日壁纸，有没有感觉 B 格满满^_^。本文将介绍如何把 Bing 每日壁纸和故事扒到自己博客。

获取 API 接口

首先我们进入Bing 首页，会发现自动转到中国版。不过这没关系，中国版更符合国情，速度也比国际版快一些。

通过抓包，可以发现http://www.bing.com/HPImageArchive.aspx?format=js&idx=0&n=1这里可以获取到无水印的图片。

那每日故事呢？通过模拟 UA，访问移动版。同样发现了 API 接口http://cn.bing.com/cnhp/coverstory/。不过这里的图片是有水印的。

接口已经得到了，接下来就是写代码了。因为我既想使用无水印的图片，也想获取每日故事，所以我把两个接口结合起来使用。

代码

<?php
/**
  * 获取Bing每日壁纸和故事
  * @author giuem
  */
function bingImgFetch(){
    $ch = curl_init();
    curl_setopt($ch, CURLOPT_URL, 'http://www.bing.com/HPImageArchive.aspx?format=js&idx=0&n=1');
    curl_setopt($ch, CURLOPT_HTTPHEADER, array(
        'User-Agent: Mozilla/5.0 (Windows NT 6.2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.137 Safari/537.36'
    ));
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
    $re = curl_exec($ch);
    curl_close($ch);
    $re = json_decode($re,1);//电脑版返回内容
    $re2 = json_decode(file_get_contents('http://cn.bing.com/cnhp/coverstory/'),1);//移动版返回内容
    return array(
        /* 更改图片尺寸，减小体积 */
        'url' => str_replace('1920x1080','1366x768',$re['images'][0]['url']),
        /* 结束日期 */
        'date' => date('j',strtotime($re['images'][0]['enddate'])),
        /* 故事标题 */
        'title' => $re2['title'],
        /* 内容 */
        'd' => $re2['para1']
    );
}
?>

使用示例

如果是 wordpress，可以把上面的代码丢进function.php，然后该怎么用就怎么用。

$bingimg= bingImgFetch();
echo $bingimg['url'];//输出图片地址
echo $bingimg['title'];
echo $bingimg['d'];

我的使用方法

因为我用的是静态博客，不能在后端完成这些操作，所以只能通过 js 获取。同时把代码放在国内访问较快的SAE中，使用Memcache缓存内容。而且我在获取后还把数据储存在localStorage中，这样可以减少请求次数。

为什么要缓存？因为不缓存的话，别人每访问一次你都要获取一次，IP 可能会被被 Bing ban 了。

当然，你也可以缓存到数据库中，这些你都可以结合实际情况修改代码。

PHP in SAE

<?php
header('Access-Control-Allow-Origin: *');
$mmc=memcache_init();
if($mmc==false){
    /* 如果memcache启动失败，直接获取 */
    $bingimg = json_encode(bingImgFetch());
}else {
    $bingimg = memcache_get($mmc,'bing_url');
    $date = memcache_get($mmc,'bing_url_date');
    /* 判断日期进行更新 */
    if(date('j') != $date || !$bingimg || !$date){
        $bingimg = json_encode(bingImgFetch());
        /* 写入 */
        memcache_set($mmc,"bing_url",$bingimg);
        memcache_set($mmc,"bing_url_date",date('j'));
    }
}
echo $bingimg;
function bingImgFetch(){
    $ch = curl_init();
    curl_setopt($ch, CURLOPT_URL, 'http://www.bing.com/HPImageArchive.aspx?format=js&idx=0&n=1');
    curl_setopt($ch, CURLOPT_HTTPHEADER, array(
        'User-Agent: Mozilla/5.0 (Windows NT 6.2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.137 Safari/537.36'
    ));
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
    $re = curl_exec($ch);
    curl_close($ch);
    $re = json_decode($re,1);
    $re2 = json_decode(file_get_contents('http://cn.bing.com/cnhp/coverstory/'),1);
    return array(
        'url' => str_replace('1920x1080','1366x768',$re['images'][0]['url']),
        'date' => date('j',strtotime($re['images'][0]['enddate'])),
        'title' => $re2['title'],
        'd' => $re2['para1']
    );
}

HTML

<section id="hero">
  <div class="hero-warp">
    <p id="hero-title"></p>
    <p id="hero-d"></p>
  </div>
</section>

CSS

html,
body {
  height: 100%;
}
#hero {
  position: relative;
  height: 100%;
  background-color: rgba(0, 0, 0, 0.6);
  background-position: center center;
  background-repeat: no-repeat;
  background-size: cover;
  background-attachment: fixed;
  width: 100%;
  text-align: center;
  color: #fff;
  display: table;
}
.hero-warp {
  display: table-cell;
  vertical-align: middle;
  text-align: center;
}
#hero-title {
  font-size: 28px;
  margin-bottom: 8px;
}
#hero-d {
  width: 80%;
  margin: 0 auto;
}

JS

如果你使用jQuery，可以把这里的 ajax 换成$.ajax()实现。

(function () {
  //bing pic load
  var $data = {
    title: localStorage.getItem('bing_title')
      ? localStorage.getItem('bing_title')
      : '',
    d: localStorage.getItem('bing_d') ? localStorage.getItem('bing_d') : '',
    url: localStorage.getItem('bing_url')
      ? localStorage.getItem('bing_url')
      : '',
    date: localStorage.getItem('bing_date')
      ? localStorage.getItem('bing_date')
      : '',
  };
  if (
    new Date().getDate() != $data.date ||
    $data.title == '' ||
    $data.d == '' ||
    $data.url == ''
  ) {
    ajax('GET', '//giuem.sinaapp.com/bing/', function ($data) {
      localStorage.setItem('bing_title', $data.title);
      localStorage.setItem('bing_d', $data.d);
      localStorage.setItem('bing_url', $data.url);
      localStorage.setItem('bing_date', new Date().getDate());
      setHero($data);
    });
  } else {
    setHero($data);
  }
})();
function setHero($data) {
  var $hero = document.getElementById('hero');
  if (!$hero) {
    return;
  }
  if ($data) {
    $hero.style.cssText += 'background-image:url(' + $data.url + ')';
    document.getElementById('hero-title').innerHTML = $data.title;
    document.getElementById('hero-d').innerHTML = $data.d;
  }
}
function ajax(type, url, opts, callback) {
  var xhr = new XMLHttpRequest();
  if (typeof opts === 'function') {
    callback = opts;
    opts = null;
  }
  xhr.open(type, url);
  var fd = new FormData();
  if (type === 'POST' && opts) {
    for (var key in opts) {
      fd.append(key, JSON.stringify(opts[key]));
    }
  }
  xhr.onload = function () {
    callback(JSON.parse(xhr.response));
  };
  xhr.send(opts ? fd : null);
}

通过JS获取真实的外网IP和内网IP

Fri, 13 Feb 2015 21:35:22 GMT

通过 JS 获取你真实的外网 IP 和内网 IP，就算开代理也没有，想想真是太可怕了，还能不能愉快的装逼了！

Demo

Demo：https://diafygi.github.io/webrtc-ips/

代码

//get the IP addresses associated with an account
function getIPs(callback) {
  var ip_dups = {};

  //compatibility for firefox and chrome
  var RTCPeerConnection =
    window.RTCPeerConnection ||
    window.mozRTCPeerConnection ||
    window.webkitRTCPeerConnection;

  //bypass naive webrtc blocking
  if (!RTCPeerConnection) {
    var iframe = document.createElement('iframe');
    //invalidate content script
    iframe.sandbox = 'allow-same-origin';
    iframe.style.display = 'none';
    document.body.appendChild(iframe);
    var win = iframe.contentWindow;
    window.RTCPeerConnection = win.RTCPeerConnection;
    window.mozRTCPeerConnection = win.mozRTCPeerConnection;
    window.webkitRTCPeerConnection = win.webkitRTCPeerConnection;
    RTCPeerConnection =
      window.RTCPeerConnection ||
      window.mozRTCPeerConnection ||
      window.webkitRTCPeerConnection;
  }

  //minimal requirements for data connection
  var mediaConstraints = {
    optional: [{ RtpDataChannels: true }],
  };

  //firefox already has a default stun server in about:config
  //    media.peerconnection.default_iceservers =
  //    [{"url": "stun:stun.services.mozilla.com"}]
  var servers = undefined;

  //add same stun server for chrome
  if (window.webkitRTCPeerConnection)
    servers = { iceServers: [{ urls: 'stun:stun.services.mozilla.com' }] };

  //construct a new RTCPeerConnection
  var pc = new RTCPeerConnection(servers, mediaConstraints);

  //listen for candidate events
  pc.onicecandidate = function (ice) {
    //skip non-candidate events
    if (ice.candidate) {
      //match just the IP address
      var ip_regex = /([0-9]{1,3}(\.[0-9]{1,3}){3})/;
      var ip_addr = ip_regex.exec(ice.candidate.candidate)[1];

      //remove duplicates
      if (ip_dups[ip_addr] === undefined) callback(ip_addr);

      ip_dups[ip_addr] = true;
    }
  };

  //create a bogus data channel
  pc.createDataChannel('');

  //create an offer sdp
  pc.createOffer(
    function (result) {
      //trigger the stun server request
      pc.setLocalDescription(
        result,
        function () {},
        function () {}
      );
    },
    function () {}
  );
}

//Test: Print the IP addresses into the console
getIPs(function (ip) {
  console.log(ip);
});

因为Firefox和Chrome支持WebRTC，可以向 STUN 服务器请求，返回内外网 IP，不同于 XMLHttpRequest 请求，STUN 请求开发者工具当中看不到网络请求的。

解决办法

那我们有没有办法继续装逼呢？答案是肯定的。我们可以关闭WebRTC。

Chrome

安装插件 https://chrome.google.com/webstore/detail/webrtc-block/nphkkbaidamjmhfanlpblblcadhfbkdm?hl=en

无法下载的一定是你上网姿势不科学。

Firefox

用 media.peerconnection.enabled 禁用。BTW，方法网上看到了，电脑没装 Firefox，所以你们自己摸索吧。

参考资料

HTML中head头结构

Sun, 23 Nov 2014 15:31:08 GMT

HTML head 头部分的标签、元素有很多，涉及到浏览器对网页的渲染，SEO 等等，而各个浏览器内核以及各个国内浏览器厂商都有些自己的标签元素,这就造成了很多差异性。移动互联网时代，head 头部结构，移动端的 meta 元素，显得更为重要。了解每个标签的意义，写出满足自己需求的 head 头标签，是本文的目的。本篇以一丝的文章为基础，进行扩展总结介绍常用的 head 中各个标签、元素的意义以及使用场景。

DOCTYPE

DOCTYPE(Document Type)，该声明位于文档中最前面的位置，处于html 标签之前，此标签告知浏览器文档使用哪种 HTML 或者 XHTML 规范。

DTD(Document Type Definition) 声明以<!DOCTYPE> 开始，不区分大小写，前面没有任何内容，如果有其他内容(空格除外)会使浏览器在 IE 下开启怪异模式(quirks mode)渲染网页。公共 DTD，名称格式为注册//组织//类型标签//语言,注册指组织是否由国际标准化组织(ISO)注册，+表示是，-表示不是。组织即组织名称，如：W3C。类型一般是 DTD。标签是指定公开文本描述，即对所引用的公开文本的唯一描述性名称，后面可附带版本号。最后语言是 DTD 语言的 ISO 639 语言标识符，如：EN 表示英文，ZH 表示中文。XHTML 1.0 可声明三种 DTD 类型。分别表示严格版本，过渡版本，以及基于框架的 HTML 文档。

HTML 4.01 strict

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

HTML 4.01 Transitional

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

HTML 4.01 Frameset

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">

最新 HTML5 推出更加简洁的书写，它向前向后兼容，推荐使用。

<!DOCTYPE html>

在 HTML 中 doctype 有两个主要目的。

对文档进行有效性验证。它告诉用户代理和校验器这个文档是按照什么 DTD 写的。这个动作是被动的，每次页面加载时，浏览器并不会下载 DTD 并检查合法性，只有当手动校验页面时才启用。
决定浏览器的呈现模式对于实际操作，通知浏览器读取文档时用哪种解析算法。如果没有写，则浏览器则根据自身的规则对代码进行解析，可能会严重影响 html 排版布局。浏览器有三种方式解析 HTML 文档。
```
*   非怪异（标准）模式
*   怪异模式
*   部分怪异（近乎标准）模式
```
关于 IE 浏览器的文档模式，浏览器模式，严格模式，怪异模式，DOCTYPE 标签，可详细阅读模式？标准！的内容。

charset

声明文档使用的字符编码，

<meta charset="utf-8" />

html5 之前网页中会这样写：

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

这两个是等效的，具体可移步阅读：\<meta charset='utf-8'> vs \<meta http-equiv='Content-Type'>，所以建议使用较短的，易于记忆。

lang 属性

简体中文

<html lang="zh-cmn-Hans"></html>

繁体中文

<html lang="zh-cmn-Hant"></html>

为什么lang="zh-cmn-Hans" 而不是我们通常写的lang="zh-CN" 呢，请移步阅读: 页头部的声明应该是用 lang="zh" 还是 lang="zh-cn"。

优先使用 IE 最新版本和 Chrome

<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1" />

360 使用 Google Chrome Frame

<meta name="renderer" content="webkit" />

360 浏览器就会在读取到这个标签后，立即切换对应的极速核。另外为了保险起见再加入

<meta http-equiv="X-UA-Compatible" content="IE=Edge,chrome=1" />

这样写可以达到的效果是如果安装了 Google Chrome Frame，则使用 GCF 来渲染页面，如果没有安装 GCF，则使用最高版本的 IE 内核进行渲染。

相关链接：浏览器内核控制 Meta 标签说明文档

百度禁止转码

通过百度手机打开网页时，百度可能会对你的网页进行转码，脱下你的衣服，往你的身上贴狗皮膏药的广告，为此可在 head 内添加

<meta http-equiv="Cache-Control" content="no-siteapp" />

SEO 优化部分

页面标题<title>标签(head 头部必须)

<title>your title</title>

页面关键词 keywords

<meta name="keywords" content="your keywords" />

页面描述内容 description

<meta name="description" content="your description" />

定义网页作者 author

<meta name="author" content="author,email address" />

定义网页搜索引擎索引方式,robotterms 是一组使用英文逗号「,」分割的值，通常有如下几种取值：none，noindex，nofollow，all，index 和 follow。

<meta name="robots" content="index,follow" />

相关链接：WEB1038 - 标记包含无效的值

viewport

viewport 可以让布局在移动浏览器上显示的更好。通常会写

<meta name="viewport" content="width=device-width, initial-scale=1.0" />

width=device-width 会导致 iPhone 5 添加到主屏后以 WebApp 全屏模式打开页面时出现黑边(http://bigc.at/ios-webapp-viewport-meta.orz)

content 参数：

width viewport 宽度(数值/device-width)
height viewport 高度(数值/device-height)
initial-scale 初始缩放比例
maximum-scale 最大缩放比例
minimum-scale 最小缩放比例
user-scalable 是否允许用户缩放(yes/no)
minimal-ui iOS 7.1 beta 2 中新增属性，可以在页面加载时最小化上下状态栏。这是一个布尔值，可以直接这样写：

<meta
  name="viewport"
  content="width=device-width, initial-scale=1, minimal-ui"
/>

而如果你的网站不是响应式的，请不要使用 initial-scale 或者禁用缩放。

<meta name="viewport" content="width=device-width,user-scalable=yes" />

相关链接：非响应式设计的 viewport

适配 iPhone 6 和 iPhone 6plus 则需要写：

<meta name="viewport" content="width=375" />
<meta name="viewport" content="width=414" />

大部分 4.7~5 寸的安卓设备的 viewport 宽设为 360px，iPhone 6 上却是 375px，大部分 5.5 寸安卓机器（比如说三星 Note）的 viewport 宽为 400，iPhone 6 plus 上是 414px。

ios 设备

添加到主屏后的标题（iOS 6 新增）

<meta name="apple-mobile-web-app-title" content="标题" />
<!-- 添加到主屏后的标题（iOS 6 新增） -->

是否启用 WebApp 全屏模式

<meta name="apple-mobile-web-app-capable" content="yes" />
<!-- 是否启用 WebApp 全屏模式 -->

设置状态栏的背景颜色

<meta
  name="apple-mobile-web-app-status-bar-style"
  content="black-translucent"
/>
<!-- 设置状态栏的背景颜色，只有在 `"apple-mobile-web-app-capable" content="yes"` 时生效 -->

只有在 "apple-mobile-web-app-capable" content="yes" 时生效

content 参数：

default 默认值。
black 状态栏背景是黑色。
black-translucent 状态栏背景是黑色半透明。如果设置为 default 或 black ,网页内容从状态栏底部开始。如果设置为 black-translucent ,网页内容充满整个屏幕，顶部会被状态栏遮挡。禁止数字识自动别为电话号码

<meta name="format-detection" content="telephone=no" />
<!-- 禁止数字识自动别为电话号码 -->

iOS 图标

rel 参数： apple-touch-icon 图片自动处理成圆角和高光等效果。 apple-touch-icon-precomposed 禁止系统自动添加效果，直接显示设计原图。 iPhone 和 iTouch，默认 57x57 像素，必须有

<link
  rel="apple-touch-icon-precomposed"
  href="/apple-touch-icon-57x57-precomposed.png"
/>
<!-- iPhone 和 iTouch，默认 57x57 像素，必须有 -->

iPad，72x72 像素，可以没有，但推荐有

<link
  rel="apple-touch-icon-precomposed"
  sizes="72x72"
  href="/apple-touch-icon-72x72-precomposed.png"
/>
<!-- iPad，72x72 像素，可以没有，但推荐有 -->

Retina iPhone 和 Retina iTouch，114x114 像素，可以没有，但推荐有

<link
  rel="apple-touch-icon-precomposed"
  sizes="114x114"
  href="/apple-touch-icon-114x114-precomposed.png"
/>
<!-- Retina iPhone 和 Retina iTouch，114x114 像素，可以没有，但推荐有 -->

Retina iPad，144x144 像素，可以没有，但推荐有

<link
  rel="apple-touch-icon-precomposed"
  sizes="144x144"
  href="/apple-touch-icon-144x144-precomposed.png"
/>
<!-- Retina iPad，144x144 像素，可以没有，但推荐有 -->

IOS 图标大小在 iPhone 6 plus 上是 180×180，iPhone 6 是 120x120。适配 iPhone 6 plus，则需要在<head>中加上这段

<link
  rel="apple-touch-icon-precomposed"
  sizes="180x180"
  href="retinahd_icon.png"
/>

iOS 启动画面

官方文档：https://developer.apple.com/library/ios/qa/qa1686/_index.html 参考文章：http://wxd.ctrip.com/blog/2013/09/ios7-hig-24/

iPad 的启动画面是不包括状态栏区域的。

iPad 竖屏 768 x 1004（标准分辨率）

<link
  rel="apple-touch-startup-image"
  sizes="768x1004"
  href="/splash-screen-768x1004.png"
/>
<!-- iPad 竖屏 768 x 1004（标准分辨率） -->

iPad 竖屏 1536x2008（Retina）

<link
  rel="apple-touch-startup-image"
  sizes="1536x2008"
  href="/splash-screen-1536x2008.png"
/>
<!-- iPad 竖屏 1536x2008（Retina） -->

iPad 横屏 1024x748（标准分辨率）

<link
  rel="apple-touch-startup-image"
  sizes="1024x748"
  href="/Default-Portrait-1024x748.png"
/>
<!-- iPad 横屏 1024x748（标准分辨率） -->

iPad 横屏 2048x1496（Retina）

<link
  rel="apple-touch-startup-image"
  sizes="2048x1496"
  href="/splash-screen-2048x1496.png"
/>
<!-- iPad 横屏 2048x1496（Retina） -->

iPhone 和 iPod touch 的启动画面是包含状态栏区域的。

iPhone/iPod Touch 竖屏 320x480 (标准分辨率)

<link rel="apple-touch-startup-image" href="/splash-screen-320x480.png" />
<!-- iPhone/iPod Touch 竖屏 320x480 (标准分辨率) -->

iPhone/iPod Touch 竖屏 640x960 (Retina)

<link
  rel="apple-touch-startup-image"
  sizes="640x960"
  href="/splash-screen-640x960.png"
/>
<!-- iPhone/iPod Touch 竖屏 640x960 (Retina) -->

iPhone 5/iPod Touch 5 竖屏 640x1136 (Retina)

<link
  rel="apple-touch-startup-image"
  sizes="640x1136"
  href="/splash-screen-640x1136.png"
/>
<!-- iPhone 5/iPod Touch 5 竖屏 640x1136 (Retina) -->

添加智能 App 广告条 Smart App Banner（iOS 6+ Safari）

<meta
  name="apple-itunes-app"
  content="app-id=myAppStoreID, affiliate-data=myAffiliateData, app-argument=myURL"
/>
<!-- 添加智能 App 广告条 Smart App Banner（iOS 6+ Safari） -->

iPhone 6 对应的图片大小是 750×1294，iPhone 6 Plus 对应的是 1242×2148 。

<link
  rel="apple-touch-startup-image"
  href="launch6.png"
  media="(device-width: 375px)"
/>

<link
  rel="apple-touch-startup-image"
  href="launch6plus.png"
  media="(device-width: 414px)"
/>

Windows 8

Windows 8 磁贴颜色

<meta name="msapplication-TileColor" content="#000" />
<!-- Windows 8 磁贴颜色 -->

Windows 8 磁贴图标

<meta name="msapplication-TileImage" content="icon.png" />
<!-- Windows 8 磁贴图标 -->

rss 订阅

<link rel="alternate" type="application/rss+xml" title="RSS" href="/rss.xml" />
<!-- 添加 RSS 订阅 -->

favicon icon

<link rel="shortcut icon" type="image/ico" href="/favicon.ico" />
<!-- 添加 favicon icon -->

比较详细的 favicon 介绍可参考https://github.com/audreyr/favicon-cheat-sheet

移动端的 meta

<meta
  name="viewport"
  content="width=device-width, initial-scale=1, user-scalable=no"
/>
<meta name="apple-mobile-web-app-capable" content="yes" />
<meta name="apple-mobile-web-app-status-bar-style" content="black" />
<meta name="format-detection" content="telephone=no, email=no" />
<meta
  name="viewport"
  content="width=device-width, initial-scale=1, user-scalable=no"
/>
<meta
  name="apple-mobile-web-app-capable"
  content="yes"
/><!-- 删除苹果默认的工具栏和菜单栏 -->
<meta
  name="apple-mobile-web-app-status-bar-style"
  content="black"
/><!-- 设置苹果工具栏颜色 -->
<meta
  name="format-detection"
  content="telphone=no, email=no"
/><!-- 忽略页面中的数字识别为电话，忽略email识别 -->
<!-- 启用360浏览器的极速模式(webkit) -->
<meta name="renderer" content="webkit" />
<!-- 避免IE使用兼容模式 -->
<meta http-equiv="X-UA-Compatible" content="IE=edge" />
<!-- 针对手持设备优化，主要是针对一些老的不识别viewport的浏览器，比如黑莓 -->
<meta name="HandheldFriendly" content="true" />
<!-- 微软的老式浏览器 -->
<meta name="MobileOptimized" content="320" />
<!-- uc强制竖屏 -->
<meta name="screen-orientation" content="portrait" />
<!-- QQ强制竖屏 -->
<meta name="x5-orientation" content="portrait" />
<!-- UC强制全屏 -->
<meta name="full-screen" content="yes" />
<!-- QQ强制全屏 -->
<meta name="x5-fullscreen" content="true" />
<!-- UC应用模式 -->
<meta name="browsermode" content="application" />
<!-- QQ应用模式 -->
<meta name="x5-page-mode" content="app" />
<!-- windows phone 点击无高光 -->
<meta name="msapplication-tap-highlight" content="no" />
<!-- 适应移动端end -->

这是来自toobug的分享总结。

更多的 meta 标签参考

原文

http://segmentfault.com/blog/paddingme/1190000000697532