`。新版的应用块支持了引文（Citation）。
47 | * 视频块（Video）：对应上一版的 WordPress 编辑器中的 `video` Shortcode。
48 | * 分割线（Separator）：对应原先的 `
`。
49 | * 多行代码块（Preformatted）：对应原先的 ``。
50 | * 代码块（Code）：也支持多行，对应原先的 `` 和 `` 组合。
51 |
52 | ### 新增的一些块
53 |
54 | 新版本中新增了很多块，通过使用这些块，你可以直接可视化地插入一些你想要的内容，而不用编辑源代码或者是使用插件。
55 |
56 | * 自定义 HTML 块（Custom HTML）：尽管你可以在许多块中使用编辑源代码（Edit as HTML），但如果真的需要插入自定义 HTML，建议使用这个块。
57 | * 空白块（Spacer）：在文章中插入一定高度的空白。
58 | * 画廊（Gallery）：插入多张照片组成的画廊。
59 | * 音频（Audio）
60 | * 文件（File）
61 | * 背景图（Cover）：使用此块可以在插入的图片上方添加文字。
62 | * 表格（Table）：你终于可以在 WordPress 中可视化的插入表格了。
63 | * 重要引述（Pull Quote）：与引用块的样式有所不同，也是引用。
64 | * 韵文（Verse）：类似多行代码块，也是使用 `` 实现的。可以实现英文字符的等宽显示。
65 | * 按钮（Button）：可以添加按钮样式的超链接了。
66 | * 分栏（Columns）
67 | * 分页（Page Break）
68 | * 媒体和文字（Media & Text）：用于左右显示媒体和文字。
69 |
70 | 以下内容原本可以作为 Widgets 在网页菜单中添加。现在还可以作为块在文章中直接添加。
71 |
72 | * 归档
73 | * 分类
74 | * 最新文章
75 | * 最新评论
76 |
77 | 除此之外，现在还有了嵌入（Embed）功能，可以直接嵌入第三方内容了，如 Twitter、YouTube、SoundCloud 等。
78 |
79 | ## 2019 主题
80 |
81 | 为了更好的配合新的编辑器的所有排版功能，WordPress 同时推出了全新的 2019 默认主题。[详情](https://make.wordpress.org/core/2018/10/16/introducing-twenty-nineteen/)
82 |
83 | 
84 |
85 |
86 | 正如以往的默认主题一样，新的 WordPress 主题也是十分通用的。然而我感觉新的 2019 主题不如上一个 2017 主题（即本 Blog 正在使用的主题）简洁。
87 |
88 | 
89 |
90 | ## 是否应该升级？该如何升级？
91 |
92 | WordPress 不保证老版本继续提供安全性更新，所以你应该升级到最新的 5.0 版本。然而实际上，从 WordPress 的版本历史可以看出，目前 WordPress 仍在维护 3.7（发布于 2013-10-24）及之后的所有版本。所以即使你不更新 5.0 版本，你也可能继续收到安全性更新。
93 |
94 | 需要注意的是，每次更新 WordPress 版本，尤其是大版本更新，其源代码中的一些函数功能会有所改变，这意味着并不保证你的插件能够在新的 WordPress 中正确运行。你应当检查一下你所启用的插件是否能够在最新版本上正确运行，或者已经发布了适配新版本的更新。如果你是插件开发者，你应该有安装测试版 WordPress 的站点，并早该让你的插件适配最新的版本。
95 |
96 | 在升级前，请务必备份你的站点。对于 WordPress 而言，你需要备份 WordPress 的代码目录以及数据库内容。
97 |
--------------------------------------------------------------------------------
/source/_posts/2015-08-17-using-srcset.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: 使用 srcset + sizes 属性与 w 标识符解决一切响应式图片问题
3 | tags:
4 | - HTML5
5 | - 响应式设计
6 | id: '4019'
7 | categories:
8 | - - 开发
9 | date: 2015-08-17 09:07:34
10 | languages:
11 | en-US: https://www.ze3kr.com/2015/08/using-srcset/
12 | ---
13 |
14 | 使用 srcset 属性可以解决一切响应式图片问题，但这里分为两种情况，确定和不确定宽度的照片。相比之下，不确定宽度的照片更复杂些。
15 |
16 | ## 确定宽度的照片
17 |
18 | 此处指的确定宽度照片，是指样式属性宽度设置为一个确定了多少 px 的照片。 随着越来越多的高设备像素比（指 device pixel ratio，下同）显示器出现，网站需要更高像素的照片来适配这些显示器。 比如有一张照片显示宽度为 200px，它在@1x（即设备像素比为 1 的显示器，下同） 的显示器上，是占了 200 个物理像素（即实际所占的像素，下同）；它在 @2x 的显示器上，实际上是占了 400 个物理像素；在 @3x 的显示器上，实际上是占了 600 个物理像素；同样的，在 @4x 的显示器上就是占了 800 个物理像素。 如果这个照片只提供 200 像素的版本，那么在 @2x\~@4x 的显示器上看起来就很模糊。如果只提供 800 像素的版本，那么在 @1x\~@3x 的设备上会加载不必要的内容，也就意味着更长的不必要时间（尤其是在手机上）。 此时，就需要使用响应式图片这个方法，最简单高效的方式是使用 srcset 来解决。比如现在提供了 4 个宽度分别为 200、400、600、800 像素的照片，通过 srcset 属性，能够实现在 @1x~@4x 设备像素比的显示器上分别显示这 4 张照片，这样在每个显示器上都能显示最适合它的照片。这四张图片的文件名分别为 200px.png, 400px.png, 600px.png, 800px.png。 总结一下，就是确定宽度的照片所占物理的像素只与设备像素比有关，所以只需要 srcset 属性的 x 标识符。
19 |
20 | ```
21 | 
22 | ```
23 |
24 | 这样加上 srcset 属性，浏览器就会根据自己的设备像素比来加载不同的照片，不支持 srcset 属性的浏览器就默认加载 200px.png 这张照片。这个方法是向下兼容的。
25 |
26 | ## 不确定宽度的照片
27 |
28 | 此处指的不确定宽度的照片，是指样式属性宽度设置为一个确定了多少百分比的照片。 如果是不确定宽度的照片的话（或者是手机上不确定图片宽度，电脑上确定宽度等），也可以通过 srcset 解决。由于像素是不能确定的，所以很难达到照片本身和照片所占物理像素是一样的，因为用户的窗口大小是不确定的。 如果只准备 5 张照片，宽度分别是 400~3200 像素，文件名是400px.png, 800px.png, 1600px, 2400px, 3200px。通常，如果没有对应图像所占的物理像素的照片的话，则会加载比所占的物理像素稍大一些的图片。例如照片占屏幕的 500 个物理像素，那么就应该选择加载 800px.png。这样加载稍大的照片仍然可以达到最佳的显示效果，同时最大限度的节省网络资源。 总结一下，就是不确定宽度的照片所占物理的像素与设备像素比和所占宽度有关，然而使用了 srcset 属性的 w 标识符后，你只需要指定宽度，浏览器会自动根据设备像素比来选择最优图片。 如果这个图片占整个窗口的 100% 大小（即 100vw 宽，下同），那么只需要这样设置 srcset 就能达到效果。 抛开设备像素比的概念吧，这个全新的 srcset 属性的 w 标识符能够让浏览器自己适应所要加载的照片。
29 |
30 | ```
31 | 
32 | ```
33 |
34 | 不过此时还有一个小问题，浏览器比较笨，它会认为图片宽度始终是整个窗口的 100% 宽，如果图片不是占整个窗口的 100%，两边留有边框怎么办呢？此时就需要使用 size 属性。 sizes 属性里制定图片的宽度，不能使用百分比单位，但可以使用 vw、px 等单位（100vw 就是整个窗口的宽度)，也可以使用 calc 运算，同时支持媒体查询。要保证使用 sizes 里计算出来的宽度始终是图片所占屏幕宽度，剩下的事情都只需要浏览器完成了。 以下几种典型案例示范：
35 |
36 | ### 两边边框为百分比
37 |
38 | 如果图片两侧边框（指图片边缘到窗口边缘长度）始终是占屏幕的一定的百分比时，那么图片总会有一个相对于整个窗口的百分比。比如图片两侧边框始终是整个窗口的 10%，那么 size 属性就可以如下设置：
39 |
40 | ```
41 | sizes="80vw"
42 | ```
43 |
44 | 如果图片已经在一个宽度是整个窗口的 70% 的元素下，而且元素内图片两侧还留有 10% 的边框，那么 size 属性就可以如下设置：
45 |
46 | ```
47 | sizes="50vw"
48 | ```
49 |
50 | ### 两边边框为确定的像素
51 |
52 | 比如图片两侧边框始终是 10px，那么 size 属性就可以如下设置：
53 |
54 | ```
55 | sizes="calc( 100vw - 10px )"
56 | ```
57 |
58 | 如果图片已经在一个宽度是整个窗口的 70% 的元素下，而且元素内图片两侧边框始终是 10p，那么 size 属性就可以如下设置：
59 |
60 | ```
61 | sizes="calc( 70vw - 10px )"
62 | ```
63 |
64 | ### 图片有最大尺寸
65 |
66 | 比如图片两侧边框始终是 10px，但是图片最大只能是 1000px，那么 size 属性就可以如下设置：
67 |
68 | ```
69 | sizes="(min-width: 1020px) 1000px, calc( 100vw - 10px )"
70 | ```
71 |
72 | 其中 `(min-width: 1020px) 1000px` 代表当屏幕像素宽度大于 1020px 时，图片宽度为 1000px。
73 |
74 | ### 实际效果
75 |
76 | 此处以我的网站为例，我的网站图片边框适中是 1.875rem，这个图片本身就是在一个元素下，这个元素默认宽度是整个窗口的 100%，但在屏幕宽度大于 40.063rem 的情况下，这个元素占整个窗口的 50%，并且这个元素有最大尺寸 500px，现在把 size 属性和用 w 标识符的 srcset 属性放在一起，就完美解决了。
77 |
78 | ```
79 |
80 | ```
81 |
82 | 然后你就可以在浏览器中测试了，达到了适配所有屏幕尺寸，所有设备像素比的效果。
83 |
84 | ### 关于兼容性
85 |
86 | 通常情况下，srcset 属性的 x 标识符支持的比 w 标识符更好，因为 w 标识符是一个新的属性。不过好消息是 Chrome 38+、Firefox 38+、Safari 9+、Opera 30+、Android 5.0+、iOS 9+（没错，IE/Edge、Windows Phone 截止到写文章之日都不支持） 都纷纷支持了 w 标识符，所以我认为现在很适合换用 srcset 属性的 w 标识符来做响应式图片了。而且这个方法是完美向下兼容的，即使不支持也没关系。 你也可以[在 CanIUse.com 上查询](http://caniuse.com/#feat=srcset)关于 secset 属性的完整的兼容性列表
87 |
--------------------------------------------------------------------------------
/source/_posts/2024-02-04-vision-pro-experience.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Vision Pro 首发体验
3 | date: 2024-02-05 3:00:00
4 | tags:
5 | - 智能设备
6 | categories:
7 | - 科技
8 | languages:
9 | en-US: https://www.ze3kr.com/2024/02/vision-pro-experience/
10 | ---
11 |
12 | 美东时间 2.2 日早上 8:00 自提的设备，本人不佩戴眼镜，因此已经使用了完整两天，这里更新下自己的一些发现。
13 |
14 | ## 配置选择
15 |
16 | 我选择的是 512GB 的版本，主要考虑是 Vision Pro 上的一些软件/游戏可能会有更多的 3D 场景，会更消耗存储空间。但大多数时候又是在 Wi-Fi 环境下使用，所以 1TB 版本又没有那么有必要。
17 |
18 | ## UI 显示效果
19 |
20 | 本人之前没有使用过其他 VR/AR 类产品（排除 Google Cardboard😂），所以并没有感觉到 Vision Pro 有多么的好。相反，我的感觉是 Vision Pro 的显示效果其实完全无法代替 Studio Display。与其它类型的显示器相比，它有这些特点
21 |
22 | **清晰度：**5K 显示器有着**明显**锐利的多的画面，并且能肉眼感觉到显示器的色彩空间也更好。目前看来 Vision Pro 的显示清晰度大约相当于 2.5K 的水平，显示效果：高端显示器 >> Vision Pro > 高端投影。仔细观察，我是可以看到 Vision Pro 中的像素的。我的视力也并非完美水平，处于轻微近视，在不配矫正镜片的时候依然能察觉到像素。
23 |
24 | **HDR 效果：**得益于 micro-LED，HDR 效果还是相对突出的，好于显示器和投影，但高光的亮度又比不过 iPhone 的 OLED 或者是 MacBook Pro 的 miniLED。
25 |
26 | **自适应的渲染：**之前的清晰度是我将窗口调整到我平时操作显示器的大小时进行的比较。但 Vision Pro 的窗口是可以调节的，包括远近和大小。此外，眼镜在物理世界里的位移也会影响到显示：当你贴近时，可以看到更清晰的画面。如果说视网膜屏幕是 @2x-@3x，那么 Vision Pro 则是 @1x-@9x（9x是打个比方）。Vision Pro 中的所有系统UI（包括网页上的SVG/文字）都是矢量渲染的，不需要 Zoom In，只需要人走进显示区域，就会发现每一个小字/矢量图都会变的无限清晰。
27 |
28 | **亮度：**感觉达不到 500nits，如果在白天摘下眼镜，会明显感觉到真实世界更亮。但这一点不是特别影响体验。
29 |
30 | ## 透视效果
31 |
32 | 透视的清晰度则是远差于 UI 显示的清晰度，摄像头的分辨率其实不高，看真实世界完全到不了 4K 水平。但可以感觉到其曝光控制非常优秀，画面里没有过曝或者欠曝，是可以戴着它生活的（如吃饭）。但无法使用它阅读小一点的文字（过于模糊，无法阅读；比如食品配料表或者手机上的小字都是看不清的）
33 |
34 | 透视效果属于能用的水平，在家里时我佩戴并四处走动是没有任何问题的。
35 |
36 | ## 舒适度和重量
37 |
38 | 一开始使用 Solo Band 的时候用久了还是挺不舒服的，但我现在换用 Dual Loop 并仔细调整后，发现比刚开始戴的时候舒服了非常多，感觉用个一两小时是没问题的。Dual Loop 有两个地方可以调整，建议多试，太紧或者太松都会导致不舒服。躺着用反而不舒服，比较压脸颊。重量肯定是能感知到的，希望有一天可以做到跟眼镜一样轻。
39 |
40 | ## 操控
41 |
42 | 操控总体而言比较方便，如果Mac的触摸板操控是 10/10 分，iPad 算 9/10 分的话，Vision Pro 现阶段已经能达到 8.5/10 分（除打字外）。滚动非常跟手，滚动是有高刷的感觉的，明显好于 60Hz。但有时候手放在了摄像头看不见的位置（比如桌子下面），这种神奇的体验就没了，然后就会想起：啊，原来是摄像头捕捉的我的手势。
43 |
44 | 除了捏合 🤌 控制，直接点击按钮也是可以交互的，把窗口“拉近”，然后像iPad那样拿食指直接点空中屏幕就可以操作，对电脑版网站按钮很小的还是很有用的。YouTube 网页版就属于适配的不那么好的网站之一，有一些按钮之间离得近，用点击的方式会更方便。
45 |
46 | 对于 iPad compatible 应用，操控体验也还不错。非常多软件（包括苹果曾经宣传过支持 Vision Pro 的 Apps），其实都只是 iPad compatible 版。试了 iPad 版的：Lightroom 、Paramount+、Maps 等，会发现 iPad 版的 App 体验已经惊人的好了。最大问题还是 Typing 体验差。细想起来，苹果在 iPad 上加的前台调度、鼠标指针、Apple Pencil 的 Hover 功能，都跟 Vision Pro 的交互惊人的相似，所以支持了以上功能的 iPad Apps 在 Vision Pro 上体验很好。
47 |
48 | 打字的话现在我最喜欢的方式是用双手食指点键盘。现在已经逐渐习惯了，但还是差于iPhone的小屏幕键盘。蓝牙键盘还有待尝试。
49 |
50 | 用久了 Vision Pro 后，每当我在现实世界里看到个屏幕觉得离我远/位置不对，就想要 🤌 把它调整下，但却发现不行 😂。感觉这会是未来人下意识的一种手势，类似刘慈欣三体里描述的情形。
51 |
52 | ## 软件体验
53 |
54 | 软件我感觉只做到了苹果的后期 Beta 水平，还算不上正式版。首先就是目前只能输入英文，其他任何语言的输入（比如中文）都不支持，包括键盘和 Siri 语音。其次就是我发现 visionOS 1.0.2 并不支持 iOS 17.2 推出的 [iMessage 信息联系人密钥验证](https://support.apple.com/zh-cn/HT213465)。这点其实 Xcode 也已经暗示了：如果在 Xcode 15.2 中将软件的 Minimum Deployment 设置为 17.2，那软件将无法在 visionOS 1.0.2 中运行。因此得出结论：visionOS 1.0.2 = iOS 7.1。这点就可以看出 Apple 发布 Vision Pro 还是很急的，或许是苹果觉得 visionOS 1.1 的 Bug 太多了，所以苹果就没有发布，导致了现在功能不匹配。顺便一提：iOS 17.1 发布时间是 2023 年 10 月 25 日，iOS 17.2 发布时间是 2023 年 12 月 11 日。
55 |
56 | 
57 |
58 | ## 外接 USB 设备
59 |
60 | 没有任何外接 USB 的能力，这点比 iPhone 和 iPad 都差。因此 Vision Pro 也不支持 YubiKey 5C NFC，因为既没有 USB 口，也没有 NFC。如果你想登录一个网站但你只配置了 YubiKey，那抱歉，登录不了。当然 Passkey 是支持的。
61 |
62 | ## Mac 扩展屏幕
63 |
64 | 很多人对扩展 Mac 屏幕很感兴趣。个人觉得扩展屏幕体验还是远差于真正的显示器的。同样价格可以买到比 Vision Pro 显示效果好得多的显示器。但如果你主打的是便携，比如希望在飞机上、酒店里也有显示器，或者希望隐私，比如不想让其他人看到你的屏幕，那它还有点用。
65 |
66 | 个人感觉 Vision Pro 显示效果是略差于中端 4K 显示器（$1000 美元左右）的。延迟也还是有的，具体体验可以参考 iPad 作为扩展屏的延迟。我个人不会拿 Vision Pro 主要作这个用途。
67 |
68 | ## Persona (Beta)
69 |
70 | 属于能用，但只还原了人脸的 90-95%。已经有点恐怖谷效应了。有总是比没有强的，我觉得我使用它参加视频会议不会特别尴尬。
71 |
72 | ## 坐车体验
73 |
74 | **坐车使用完全不可行**，哪怕启用了 Travel Mode，至少小汽车是不行的。首先Vision Pro会错误定位，因为窗户的存在，有时会认为你在快速移动，有时则定位失败。但这个其实好说，属于软件问题，但下一个问题就是物理问题了：就是因为它比较重，在有颠簸车上受加速度影响脸部会异常难受。因此起飞/降落/Taxiing/气流颠簸时都不建议用，小心脸疼。
75 |
76 | 因此坐车时还是 iPhone/iPad 体验更好。我以后不会在坐车时使用 Vision Pro。
77 |
78 | ## 其他缺点
79 |
80 | EyeSight 非常鸡肋，亮度很低并且分辨率也很低。iFixit 的拆解也得出了原因，是为了还原眼镜的 3D 效果不得不做出的妥协。眼睛的还原必须是立体的，不然外人将无法知道你在看谁。
81 |
82 | ## 总结
83 |
84 | 我认为 Vision Pro 已经接近成熟了，软件上已经达到了最后一个 Beta 版本的可用性。软件上相对欠缺，但我觉得未来几个月内会迅速弥补上。
85 |
--------------------------------------------------------------------------------
/source/files/ze3kr.pem:
--------------------------------------------------------------------------------
1 | -----BEGIN CERTIFICATE-----
2 | MIIFAzCCA+ugAwIBAgIQJ6pj/Spvba1vJ1yqn8ZcrjANBgkqhkiG9w0BAQsFADCB
3 | ljELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
4 | A1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQD
5 | EzVTZWN0aWdvIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBF
6 | bWFpbCBDQTAeFw0yMjA3MjcwMDAwMDBaFw0yNTA3MjYyMzU5NTlaMBwxGjAYBgkq
7 | hkiG9w0BCQEWC2lAemUza3IuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
8 | CgKCAQEAtu63ZLqF/2wUL5QImiTmcfmxGGU6Topuf0xU2MGpne3gfY4PkgUyWPX6
9 | EwaA38EaQGhBeRY0OcaRvCMYL+4+5+ZxZcsTrprTjIA58NT36YFIk5Ju+6fIkslV
10 | WxUO4VONMCp6zdxAzODwiZmPBQEN7QZ5rTRBCMlcbIl2mJcDSTqkz/Zxe9BBEyDL
11 | 52GWAy0RN86lx0hkY+PNkbwnYLPNyrKy3cHxTQUYzcN/gXuFJ2xpJfsP5t3pP9wO
12 | jmR9ixBBk3lSJs1BsI5OmyrxfbvxMLvUu+W9OXCPJgYhPtVRvGIdfNKLPIT3zl7E
13 | GxjfDf9DxmljoxGeai/UMsD5GqiaEwIDAQABo4IBxDCCAcAwHwYDVR0jBBgwFoAU
14 | CcDy/AvalNtf/ivfqJlCz8ngrQAwHQYDVR0OBBYEFNY2WSQ/LkoVyme7QmpwhgTE
15 | nSJXMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsG
16 | AQUFBwMEBggrBgEFBQcDAjBABgNVHSAEOTA3MDUGDCsGAQQBsjEBAgEBATAlMCMG
17 | CCsGAQUFBwIBFhdodHRwczovL3NlY3RpZ28uY29tL0NQUzBaBgNVHR8EUzBRME+g
18 | TaBLhklodHRwOi8vY3JsLnNlY3RpZ28uY29tL1NlY3RpZ29SU0FDbGllbnRBdXRo
19 | ZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGKBggrBgEFBQcBAQR+MHww
20 | VQYIKwYBBQUHMAKGSWh0dHA6Ly9jcnQuc2VjdGlnby5jb20vU2VjdGlnb1JTQUNs
21 | aWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwIwYIKwYBBQUH
22 | MAGGF2h0dHA6Ly9vY3NwLnNlY3RpZ28uY29tMBYGA1UdEQQPMA2BC2lAemUza3Iu
23 | Y29tMA0GCSqGSIb3DQEBCwUAA4IBAQCLo7oOc8+/SdpII0t0bZusXUErhKAnhtrI
24 | OVR8BvwVTYHkmrElNCb0MMBGqT3UHEEWdeHbRmoGFZqh7SHXacF9t2qM6w/VwpdN
25 | p37iMU0Tm5tptvfyE21dHJ2SMDZkZQSpbxwA3IL0z8TLBe2PLXQTXVx37irm5Iqa
26 | JFv9shx0SsiQqCCXikf0GHoPyS/VT30aAhLK3fVLG9a6/gQ7cRw4EWgpbpllH3Wi
27 | 9MLG18rPhqijV/cgigHvBl6OgS0G2bKqEql4b9ZwH9K5cHlnv7ME40S7lh5/7+ZN
28 | 7XNF/9TIbz4XSLAlsOUac5Fpl7Xxp+jfdSIUcOppVV6x+PnXr+OX
29 | -----END CERTIFICATE-----
30 | -----BEGIN CERTIFICATE-----
31 | MIIGEDCCA/igAwIBAgIQTZQsENQ74JQJxYEtOisGTzANBgkqhkiG9w0BAQwFADCB
32 | iDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC0pl
33 | cnNleSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxLjAsBgNV
34 | BAMTJVVTRVJUcnVzdCBSU0EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMTgx
35 | MTAyMDAwMDAwWhcNMzAxMjMxMjM1OTU5WjCBljELMAkGA1UEBhMCR0IxGzAZBgNV
36 | BAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEYMBYGA1UE
37 | ChMPU2VjdGlnbyBMaW1pdGVkMT4wPAYDVQQDEzVTZWN0aWdvIFJTQSBDbGllbnQg
38 | QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcN
39 | AQEBBQADggEPADCCAQoCggEBAMo87ZQKQf/e+Ua56NY75tqSvysQTqoavIK9viYc
40 | KSoq0s2cUIE/bZQu85eoZ9X140qOTKl1HyLTJbazGl6nBEibivHbSuejQkq6uIgy
41 | miqvTcTlxZql19szfBxxo0Nm9l79L9S+TZNTEDygNfcXlkHKRhBhVFHdJDfqB6Mf
42 | i/Wlda43zYgo92yZOpCWjj2mz4tudN55/yE1+XvFnz5xsOFbme/SoY9WAa39uJOR
43 | HtbC0x7C7aYivToxuIkEQXaumf05Vcf4RgHs+Yd+mwSTManRy6XcCFJE6k/LHt3n
44 | dD3sA3If/JBz6OX2ZebtQdHnKav7Azf+bAhudg7PkFOTuRMCAwEAAaOCAWQwggFg
45 | MB8GA1UdIwQYMBaAFFN5v1qqK0rPVIDh2JvAnfKyA2bLMB0GA1UdDgQWBBQJwPL8
46 | C9qU21/+K9+omULPyeCtADAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB
47 | /wIBADAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAG
48 | BgRVHSAAMFAGA1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9jcmwudXNlcnRydXN0LmNv
49 | bS9VU0VSVHJ1c3RSU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNybDB2BggrBgEF
50 | BQcBAQRqMGgwPwYIKwYBBQUHMAKGM2h0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9V
51 | U0VSVHJ1c3RSU0FBZGRUcnVzdENBLmNydDAlBggrBgEFBQcwAYYZaHR0cDovL29j
52 | c3AudXNlcnRydXN0LmNvbTANBgkqhkiG9w0BAQwFAAOCAgEAQUR1AKs5whX13o6V
53 | bTJxaIwA3RfXehwQOJDI47G9FzGR87bjgrShfsbMIYdhqpFuSUKzPM1ZVPgNlT+9
54 | istp5UQNRsJiD4KLu+E2f102qxxvM3TEoGg65FWM89YN5yFTvSB5PelcLGnCLwRf
55 | CX6iLPvGlh9j30lKzcT+mLO1NLGWMeK1w+vnKhav2VuQVHwpTf64ZNnXUF8p+5JJ
56 | pGtkUG/XfdJ5jR3YCq8H0OPZkNoVkDQ5CSSF8Co2AOlVEf32VBXglIrHQ3v9AAS0
57 | yPo4Xl1FdXqGFe5TcDQSqXh3TbjugGnG+d9yZX3lB8bwc/Tn2FlIl7tPbDAL4jNd
58 | UNA7jGee+tAnTtlZ6bFz+CsWmCIb6j6lDFqkXVsp+3KyLTZGXq6F2nnBtN4t5jO3
59 | ZIj2gpIKHAYNBAWLG2Q2fG7Bt2tPC8BLC9WIM90gbMhAmtMGquITn/2fORdsNmaV
60 | 3z/sPKuIn8DvdEhmWVfh0fyYeqxGlTw0RfwhBlakdYYrkDmdWC+XszE19GUi8K8p
61 | lBNKcIvyg2omAdebrMIHiAHAOiczxX/aS5ABRVrNUDcjfvp4hYbDOO6qHcfzy/uY
62 | 0fO5ssebmHQREJJA3PpSgdVnLernF6pthJrGkNDPeUI05svqw1o5A2HcNzLOpklh
63 | NwZ+4uWYLcAi14ACHuVvJsmzNic=
64 | -----END CERTIFICATE-----
65 |
--------------------------------------------------------------------------------
/source/_posts/2016-01-29-wordpress-plugins.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: WordPress 上的几个推荐安装的插件
3 | tags:
4 | - WordPress
5 | id: '96'
6 | categories:
7 | - - 开发
8 | date: 2016-01-29 10:19:00
9 | languages:
10 | en-US: https://www.ze3kr.com/2016/01/wordpress-plugins/
11 | ---
12 |
13 | ## EWWW Image Optimizer
14 |
15 | 无损及有损压缩 JPEG 和 PNG 图像，支持压缩已有的图像，可以加快访问者加载图片的速度。同时支持 JPEG 的渐进式加载。正常情况下，网速低时，图片是一点点从上往下加载，**而使用渐进式加载，则是先加载这个图片的低分辨率版本，然后逐渐变得清晰。**我已经成为这个插件的付费用户，能够进一步有损压缩 PNG 和 JPEG 格式图片、降低服务器 CPU 占用（否则每上传一张图片，CPU 都消耗很多）。不过最近使用了 Cloudflare 的 Polish 功能，就没有再在服务器上安装同类软件了。
16 |
17 | ## Autoptimize
18 |
19 | 这个插件能够自动的合并 CSS 和 JS，并对其压缩，非常的方便。而且一些主题会有大量的 inline CSS，当开启了合并 CSS 后，这些 inline CSS 会自动添加到文件中。 我在这个插件中的**一些配置**，分享出来：
20 |
21 | ### Exclude scripts from Autoptimize
22 |
23 | functions.js,player,mediaelement,sparkline,toolbar,admin,akismet,themes
24 |
25 | * functions.js,themes：排除所有主体主题相关的脚本，全面解决合并后会导致菜单的交互出现问题
26 | * player,mediaelement：排除 WordPress 播放器的合并，因为这部分文件有的页面有，有的页面没有
27 | * sparkline,toolbar,admin：这些文件只有用户登录后才会加载
28 | * akismet：安装了 akismet 插件后推荐添加
29 |
30 | ### Exclude CSS from Autoptimize
31 |
32 | admin,mediaelement,wordfence,piwik,toolbar,dashicons,crayon-syntax-highlighter/themes,crayon-syntax-highlighter/fonts
33 |
34 | * admin,mediaelement,toolbar,dashicons：同上，只有管理员才会加载，或者是只有部分页面才会加载的东西
35 | * crayon-syntax-highlighter/themes,crayon-syntax-highlighter/fonts：排除 Crayon Syntax Highlighter 插件仅在部分页面才会加载的 CSS
36 | * wordfence,piwik：排除一些插件
37 |
38 | ### 建议开启
39 |
40 | * **Optimize HTML Code**：优化 HTML 代码，能减少页面大小
41 | * **Optimize JavaScript Code**：优化 JS 代码，能减少 JS 大小并合并 JS
42 | * **Force JavaScript in ``**：能提前加载 JS
43 | * **Optimize CSS Code**：优化 CSS 代码，能减少 CSS 大小并合并 CSS
44 | * **Generate data: URIs for images**：将文件直接嵌入 CSS 中，减少请求数
45 | * **Remove Google Fonts**：移除 Google 字体，这种字体文件都是只对西文有效的，对于中文没有意义。
46 | * **Also aggregate inline CSS**：将 Inline 的 CSS 放到 CSS 文件里，能减少页面大小
47 | * **Save aggregated script/css as static files**：能提高处理性能
48 |
49 | ### 建议关闭
50 |
51 | * **Keep HTML comments**：有些时候 HTML comments 是有作用的
52 | * **Also aggregate inline JS**：每个页面的 JS 都不同，不要开启
53 | * **Add try-catch wrapping**：没有什么意义的东西
54 | * **Inline and Defer CSS**：将 CSS 全面嵌入到页面里，会极大增加页面大小，但能减少请求数，但是真的大多数情况下只会让网站更慢。
55 | * **Inline all CSS**：同上
56 |
57 | ## AMP
58 |
59 | 插件作者是：Automattic ，为 Google 优化，搜索结果中展示超快的 AMP 页面。详情：[使用 AMP 构建超快的移动页面](https://www.guozeyu.com/2016/10/amp-html/)
60 |
61 | ## Google Authenticator
62 |
63 | 二部认证器（需要配合同名手机客户端，或者 1Password 专业版）。你可曾听说过 Heart Bleed 漏洞？有了二部认证，就算再有 Heart Bleed 漏洞，都无需害怕。 原理：手机生成器上扫描二维码保存密钥，然后生成器根据时间变量生成6位数字。这6位数字有有效期，并且只能用一次。安全性甚至大于短信验证码
64 |
65 | ## IP Dependent Cookies
66 |
67 | 更换 IP 后需要重新登录，就算使用 HTTP 也可以一定程度上避免 Cookie 泄漏的风险
68 |
69 | ## Wordfence
70 |
71 | WordPress #1 的**安全防御**插件，可限制密码尝试次数防止暴力破解，可为你的 WordPress 增加 WAF 功能，查看实时访问。通过查看它的日志我才发现，原来我的 WordPress 一直在被恶意的暴力破解，有时一天几千次，**几乎天天都有**。不过还好只要尝试 3 次错误密码，IP 会直接被屏蔽掉，这也是 Failed Logins 数量不多的原因。 像这种是基于应用层面的防御，并不是 Cloudflare 等云加速，抗 DDOS 服务所能防御的。
72 |
73 | ## Crayon Syntax Highlighter
74 |
75 | 这个插件能够让 WordPress 上展示自动高亮的源代码，有多种主题可以选择，支持多种编程语言。
76 |
77 | ## Slimpack
78 |
79 | 
80 |
81 | 这是 Jetpack 的简化版，没有 Jetpack 那一堆没用的特性，不需要登录到 wordpress.com，功能齐全，使用起来也非常简便。
82 |
83 | ## XML Sitemap & Google News feeds
84 |
85 | 这个插件能够自动生成网站的 `sitemap.xml` 和 `robots.txt`，你可以直接将 `sitemap.xml` 提交到百度和 Google，这样搜索引擎就不会漏掉你的网站上的每一篇文章了。 这个插件支持 WordPress 的多站点，不需要任何配置，推荐在整个网络上启用。
86 |
87 | ## WP-Piwik
88 |
89 | 
90 |
91 | 这个插件能够让你的整个网站拥有统计功能，支持 WordPress 的多站点，推荐在整个网络上启用。关于 Piwik 配合 WordPress，请参见这篇文章：[Piwik 与 WordPress 配合使用，建立强大统计系统](https://www.guozeyu.com/2016/01/piwik-wordpress/)。
92 |
93 | ## Blubrry PowerPress
94 |
95 | 这个插件能够让你的 WordPress 生成一个 Podcast Feed，让你有一个播客平台，你也可以把这个 Feed 直接提交到 iTunes 等地方。
96 |
97 | 
98 |
99 | ## Exif Caption
100 |
101 | 这个插件可以让你将图片的 Exif 信息插入到图片的说明中，缺点是需要上传图片后手动添加，但是它可以批量添加，还算方便。将 Exif 信息插入到图片的说明后，再将这个图片插入到文章中，Exif 信息就能够显示在文章中。
102 |
--------------------------------------------------------------------------------
/source/_posts/2016-08-22-back-to-wordpress-builtin-comment-system.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: 用回 WordPress 自带评论系统
3 | tags:
4 | - WordPress
5 | id: '1922'
6 | categories:
7 | - - 开发
8 | date: 2016-08-22 11:32:57
9 | languages:
10 | en-US: https://www.ze3kr.com/2016/08/back-to-wordpress-builtin-comment-system/
11 | ---
12 |
13 | 最近 Disqus 被某国的墙搞的十分不稳定，于是又用回了 WordPress 自带的评论系统，但是这个评论系统却不带评论者被回复时的邮件提醒。我有自己的发信服务器（AWS SES）系统，所以理论上可以配合插件实现这个效果。但是我看了很多插件，基本上操作页面都太复杂，而且回复的邮件通常不支持中文，我只需要一个简单的回复系统，不用那么麻烦，于是干脆自己开发一个，最终比较完美的实现了这个功能。
14 |
15 | 我开发的这个功能特点是：当评论者被回复时，邮件标题是 “Re: \[文章标题\]”，这样评论者的一个留言被多个人回复时，会被自动在本地邮件客户端上归为一类；而且评论者收到邮件后可以直接回复邮件，会**直接**给回复的发出者发邮件（不会显示在网站上，我也无法看到，这将是两人的私聊）。
16 |
17 | 邮件内容简洁，无额外无用的东西，不会被认定为 Spam。
18 |
19 | 
20 |
21 | 所有代码已经放到 [GitHub Gist](https://gist.github.com/ZE3kr/8c51a6349462935cefd2e636e96e93f8) 上。
22 |
23 | ```
24 | comment_parent ? $comment->comment_parent : '';
29 | $spam_confirmed = $comment->comment_approved;
30 | $from = $comment->comment_author_email;
31 | $to = get_comment($parent_id)->comment_author_email;
32 | if (($parent_id != '') && ($spam_confirmed != 'spam') && $from != $to && $to != get_bloginfo('admin_email') ) {
33 | $blog_name = get_option('blogname');
34 | $blog_url = site_url();
35 | $post_url = get_permalink( $comment->comment_post_ID );
36 | $comment_author = $comment->comment_author;
37 | $subject = 'Re: '.html_entity_decode(get_the_title($comment->comment_post_ID));
38 | $headers[] = 'Reply-To: '.$comment_author.' <'.$comment->comment_author_email.'>';
39 | $comment_parent = get_comment($parent_id);
40 | $comment_parent_date = tlo_get_comment_date( $comment_parent );
41 | $comment_parent_time = tlo_get_comment_time( $comment_parent );
42 | $message = <<
44 |
45 |
46 |
47 | $blog_name
48 |
49 |
50 |
55 |
56 |
57 |
$comment->comment_content
58 |
59 |
70 |
71 |
72 |
73 |
74 |
$comment_parent->comment_content
75 |
76 |
78 |
79 |
80 | HTML;
81 | add_filter( 'wp_mail_content_type', 'tlo_mail_content_type' );
82 | add_filter( 'wp_mail_from_name', 'tlo_mail_from_name' );
83 | wp_mail( $to, $subject, $message, $headers );
84 | }
85 | }
86 | add_action('tlo_comment_post_async', 'tlo_comment_mail_notify');
87 |
88 | function tlo_comment_mail_notify_async($comment_id) {
89 | wp_schedule_single_event( time(), 'tlo_comment_post_async', [$comment_id] );
90 | }
91 | add_action('comment_post', 'tlo_comment_mail_notify_async');
92 | // add_action('comment_post', 'tlo_comment_mail_notify');
93 |
94 | function tlo_mail_content_type() {
95 | return 'text/html';
96 | }
97 | function tlo_mail_from_name() {
98 | global $comment_author;
99 | return $comment_author;
100 | }
101 |
102 | function tlo_get_comment_time( $comment ) {
103 | $date = mysql2date(get_option('time_format'), $comment->comment_date, true);
104 |
105 | return apply_filters( 'tlo_get_comment_time', $date, $comment );
106 | }
107 | function tlo_get_comment_date( $comment ) {
108 | $date = mysql2date(get_option('date_format'), $comment->comment_date);
109 |
110 | return apply_filters( 'tlo_get_comment_date', $date, $comment );
111 | }
112 | ```
--------------------------------------------------------------------------------
/source/_posts/2016-08-09-talk-about-config-ipv6-on-server.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: 如何配置以实现纯 IPv6-Only 网络访问
3 | tags:
4 | - 网络
5 | id: '1804'
6 | categories:
7 | - - 开发
8 | date: 2016-08-09 20:32:16
9 | languages:
10 | en-US: https://www.ze3kr.com/2016/08/talk-about-config-ipv6-on-server/
11 | cover: 
12 | ---
13 |
14 | 在今年 5 月 4 日，Apple 就开始要求新的应用程序支持 IPv6 DNS64/NAT64 网络，这意味着苹果开始力推 IPv6 网络，在[苹果的官网上](https://developer.apple.com/library/mac/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html#//apple_ref/doc/uid/TP40010220-CH213-SW1)就有介绍一些 IPv6 的优势，主要来说就是对移动网络更加友好，并能提高一些性能，减少一些传输上的开销。 最近，我也将我的所有服务器全面部署 IPv6，完全支持 IPv6-Only 网络。
15 |
16 |
17 | 什么是 IPv6-Only 网络 严格上来讲，IPv6-Only 网络下只能连接上 IPv6 地址，这也就意味着 DNS 缓存服务器也必须是 IPv6 地址，只能连接上支持 IPv6 的服务器。如果要解析一个域名，这个域名本身及其所属的根域名的 DNS 服务器也必须统统支持 IPv6。总之，在整个过程中不存在 IPv4。所以想要支持 IPv6-Only 网络，几乎需要在所有的环节下功夫。
18 |
19 | ## 使用支持 IPv6 的根域名和 DNS 服务器
20 |
21 | 为了支持 IPv6，首先你所使用的根域名必须支持 IPv6，好在大多数根域名都支持 IPv6 了。[从这里](http://bgp.he.net/ipv6-progress-report.cgi)可以看到已经有 98% 的根域名都支持了 IPv6。 一般大家还是喜欢使用第三方的 DNS 而不是去自建，那么这就需要给自己使用支持 IPv6 的 DNS 服务器。好在也有不少 DNS 服务器支持 IPv6 了，比如 CloudFlare、OVH、Vultr、DNSimple、Rage4 等等大多数国外 DNS 解析，哦，除了 Route53；国内目前就见到了百度云加速、sDNS 的 DNS 解析支持，其他常用的 CloudXNS、DNSPod、阿里云等等都不支持。 检测根域名或者是某个域名所使用的 DNS 服务器是否支持 IPv6，只需要执行指令，替换其中的 `` 为根域名（如 com）或者任意一级域名（如 example.com）：
22 |
23 | ```
24 | $ dig -t AAAA `dig ns +short` +short
25 | ```
26 |
27 | 然后查看输出的 IP 中是否全是 IPv6 地址，如果什么也没有输出，说明 DNS 服务器不支持 IPv6。 正确配置 IPv6 的例子：
28 |
29 | 
30 |
31 | 如果想要自建 DNS 服务器，可以参考[自建 PowerDNS 方法](https://www.guozeyu.com/2016/08/self-host-dns/)。 如果你的根域名不支持 IPv6，那么你可以联系根域名那里让他们去支持，或者换一个根域名。如果你的一级域名不支持 IPv6，那就联系 DNS 解析商让他们支持，或者直接换走。
32 |
33 | ## 让网站、API 等服务器支持 IPv6
34 |
35 | ### 方案一，直接配置 IPv6
36 |
37 | 也就是让你自己的服务器支持 IPv6，这需要联系你的服务器提供商，让他们给你分配一个 IPv6 地址，如果还是不支持 IPv6，那么可以使用 IPv6 Tunnel Broker，比如 Hurricane Electric 的免费 Tunnel Broker，这样通常没有服务商给你的原生的 IPv6 好，但是在服务商支持原生 IPv6 之前只能先用着。Tunnel Broker **相当于建立在网络层（第三层）上的代理**，需要你的服务器的操作系统支持，而且服务器必须要有一个固定的 IPv4 地址。为了使用它你需要在系统里重新配置网卡（所以共享主机就没戏了），然后就能按照正常方法使用 IPv6 了，简直零成本支持 IPv6。注意，主机到 Tunnel Broker 传输是明文，不过只要应用程序都使用安全的协议（如 HTTPS、SMB、SFTP、SSH），这不是问题。
38 |
39 | 很可惜，我目前的两个服务器暂时都没有原生的 IPv6 可以用，于是只能用 Tunnel Broker 了，使用后发现虽然是免费的，但是效果也不错：下载时似乎没有限速，我 100M 的独享带宽在原生的 IPv4 上下载速度为 12Mbyte/s，在 IPv6 上还几乎是这个速度。Ping 延迟还是会有一些增加的，主要是因为 Tunnel Broker 的服务器连接到你的服务器会有一些延迟，它相当于一个代理，所以创建时一定要选择离你服务器最近的 Tunnel Broker（延迟最短的），而不是里用户最近的 Tunnel Broker。
40 |
41 | 注意，强烈不建议国内主机使用 HE 的 Tunnel Broker，原因是中国连接 HE 都会绕道美国，最终会给 IPv6 增加 500ms 的 Ping 延迟，1000ms 以上的 TCP 延迟和好几秒的 HTTPS 延迟。建议国内主机使用方案二。
42 |
43 | 在服务器支持了 IPv6 后，确保域名上也新设置了 AAAA 记录解析到了 IPv6 地址上。
44 |
45 | ### 方案二，上 CDN/HTTP Proxy
46 |
47 | 刚才所介绍的方案是直接支持，或者使用 Tunnel Broker 建立在网络层的代理。当然还有另一种代理的方式，那就是建立在应用层（第七层）上的，建立在第七层上的其实就是 HTTP Proxy，不过大多数提供 HTTP Proxy 功能的地方都能够缓存静态内容，所以也就是 CDN。 最佳解决方案是直接使用免费的 CloudFlare，然后开启 CDN 功能，这需要更换 DNS 服务器，甚至还可以配置 IPv4 回源，仅使用 IPv6 CDN)，不过这样的话连 DNS 在内的所有服务都能支持 IPv6 了，类似的还有 Akamai，它们在代理了之后都能给你 IPv6 支持。 但是如果使用这种方案，原先收集用户真实 IP 的功能就会失效，包括防火墙和 Web 应用程序在内。但只需要配置稍作一些修改，就又能收集访客 IP 了。
48 |
49 | * * *
50 |
51 | 在做好了这些配置之后，网站就能够被 IPv6-Only 的网络访问了。然而这只是其中一步，别忘了网站上的 CDN 和域名上的邮件服务还没支持 IPv6 哦，最后，我来列一下：
52 |
53 | ## 一些支持 IPv6 的服务列表
54 |
55 | ### CDN
56 |
57 | * CloudFlare
58 | * Akamai
59 |
60 | ### VPS
61 |
62 | * [Vultr](https://www.vultr.com/?ref=6886257)
63 | * Linode
64 | * DigitalOcean
65 | * OVH
66 |
67 | ### DNS
68 |
69 | 注：CDN、VPS 中列出的那几家服务自己都提供了支持 IPv6 的 DNS，在此不再列出（其中 Linode 和 DigitalOcean 所提供的 DNS 服务实际上也是 CloudFlare 的）
70 |
71 | * Rage4
72 | * Hurricane Electric DNS
73 | * Route 53
74 | * Google Cloud DNS
75 |
76 | ### Tunnel Broker
77 |
78 | * Hurricane Electric Tunnel Broker
79 |
80 | ### 邮件服务
81 |
82 | * Gmail / G Suit (Gmail for Work)
83 |
84 | * * *
85 |
86 | 当你配置好后，你可以[在 IPv6 Test 上测试你的网站](http://ipv6-test.com/validate.php)。
87 |
88 |
89 |
90 | 直至现在，支持 IPv6-Only 网络访问在生产中仍然不是必须的，因为实际上很少存在 IPv6-Only 的网络，一般都兼容 IPv4，很多大网站也完全不支持 IPv6。苹果所说的要求支持 IPv6-Only，只是程序内部要使用 IPv6 通信，程序中不能有 IPv4 地址，能够在只分配了 IPv6 地址的运营商使用（然而实际上这些运营商还是支持 IPv4 的）。
91 |
--------------------------------------------------------------------------------
/source/_posts/2017-05-20-cloudflare-argo.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Cloudflare Argo 与 Railgun 对比测试，CDN 加速的黑科技
3 | tags:
4 | - CDN
5 | - 网络
6 | id: '3108'
7 | categories:
8 | - 科技
9 | date: 2017-05-20 19:52:23
10 | languages:
11 | en-US: https://www.ze3kr.com/2017/05/cloudflare-argo/
12 | ---
13 |
14 | 本网站曾经一直将国外解析到 CloudFront 实现为国外加速，最近看到 Cloudflare 支持了 [Argo](https://blog.cloudflare.com/argo/) 这一新功能，于是就把国外的 CDN 从 CloudFront 换到了 Cloudflare 并开启了 Argo 来试一下效果，官方宣称无缓存时能明显降低 TTFB（首字节延迟），有缓存时也能提高缓存命中率。本文还会将其与 Cloudflare 的另一个企业级的 CDN 加速黑科技——Railgun 进行对比。
15 |
16 |
17 | # Cloudflare Argo
18 |
19 | ## 提升缓存命中率，Argo Tiered Cache
20 |
21 | Cloudflare 的节点很多，但是节点太多有时不是一件好事——**大多数 CDN 之间的节点是相对独立的**。首先要先明白 CDN 的工作原理，CDN 通常不会预先缓存内容，而是在访客访问时充当代理的同时对可缓存的内容缓存。就拿本站来说，本站用的是[香港虚拟主机](https://domain.tloxygen.com/web-hosting/index.php)，如果有英国伦敦的访客访问了我的网站，那么由于我的网站是可被缓存的，他就会连接到伦敦的节点并被缓存在这个节点。那么如果是英国曼彻斯特的访客访问了呢？由于 CDN 在曼彻斯特另有节点，访客会直接连接到曼彻斯特节点，然而曼彻斯特上并没有缓存，所以该节点会回源到香港。而显然的是，如果曼彻斯特回源到伦敦，使用伦敦的缓存会更快。 综上，如果能选择性的从其他节点上获取资源，TTFB 会更低，缓存命中率也会相应提高。但是一般的 CDN 不会去这样做，因为节点相互独立，节点之间并不知道对方是否已经缓存。一般的解决方法是节点与源站之间先经过为数不多的几个节点，这几个节点可能只是分布在几个州，比如整个欧洲就只有一个这种节点。这样的话，伦敦的访客访问后，同时也被欧洲的那个节点缓存。这样，当再有欧洲其他地区的访客连接到一个没有缓存的节点时，这些节点会直接提供欧洲的那个节点的缓存。CloudFront 和 KeyCDN 就利用了这样的技术。 Cloudflare 是如何实现的他们官方没有详细说明。然而在实际测试时，并没有观察到缓存率上有明显提升，远比不过 CloudFront 的效果。下图是通过这些节点测试的 TTFB，请求是逐个发起的。
22 |
23 | 
24 |
25 | 
26 |
27 | ## 降低 TTFB，Argo Smart Routing
28 |
29 | 通常情况下，节点与源站的连接是直接的，这之间的网络很大程度上取决于主机的网络接入。然而，有了 Argo Smart Routing，Cloudflare 会使用自己的线路。图片来自 Cloudflare.com。
30 |
31 | 
32 |
33 | 国外请求测试地址，其中的 via 字段就是 Cloudflare 与本站建立的连接的 IP 地址。通过 GeoIP 服务查询，发现是香港的 IP。Cloudflare 将自己的节点之间都建立了长连接，并在离源站最近的服务器上与源站也提前建立了连接。这样，就能大大降低首次连接所需要的时间。如果回源是 HTTPS 的，那么效果更明显。我的另一个测试地址是没有开启这个功能的，用来对比，它的回源与本站建立的 IP 就不是香港的。
34 |
35 | ### 使用 Flexible SSL 的 TTFB 对比
36 |
37 | 
38 |
39 | 
40 |
41 | ### 使用 Full SSL 的 TTFB 对比
42 |
43 |
44 | 
45 |
46 | 
47 |
48 | 速度的确有一定的提升，但是不是特别明显，而且似乎开启了之后一些节点反而更不稳定——原本都是比较稳定的一个速度，开了这个之后一些节点反而忽快忽慢。看来提速的最佳方法还是半程加密。
49 |
50 | # Cloudflare Railgun
51 |
52 | Railgun 是 Cloudflare 专门为 Business 和 Enterprise 企业级客户提供的终极加速方案。要使用它，先需要升级网站套餐为 Business 或 Enterprise，然后还需要在服务器上安装必要软件并在 Cloudflare 上完成配置。这相当于是一个双边加速的软件，其实现原理是让服务器与 Cloudflare 建立一个长久的 TCP 加密连接，使用 Railgun 独有协议而不是 HTTP 协议，这样显然能减少连接延迟。此外，它还会对动态页面缓存：考虑到大多动态页面都包含了大量相同的 HTML 信息，在用户请求一个新的页面时，服务器将只发送那些变化了的内容。这相当于一种多次的 Gzip 压缩。
53 |
54 | 
55 |
56 | 官方宣称，使用 Railgun 能够实现 99.6% 的压缩率，并实现两倍的速度。实际体验也确实如此：
57 |
58 | 
59 |
60 | Railgun 的加速效果还是非常之明显的，明显强于 Argo。
61 |
62 | # 总结
63 |
64 | Argo 并没有想象中的那么好用，而且 **$5/mo** 的起步价和 **$0.10/GB** 的流量并不便宜。当然也有可能需要一段时间 Argo 去分析线路延迟才能更好的进行优化。本文预计将在一个月后补充更新。 Railgun 效果还是极其显著的，但是它需要企业版套餐才能够使用，并不亲民。
65 |
66 | ## 动态内容
67 |
68 | **延迟**：Google Cloud CDN 延迟最低，Cloudflare Railgun 仅次。 **流量**：对于普通的动态 CMS，Cloudflare Railgun 大约能节省 10 倍以上流量，Google Cloud CDN 是做不到的。 我在[国内外几家全站 CDN 对比](https://www.guozeyu.com/2017/01/wordpress-full-site-cdn/)中测试 Google Cloud CDN 时，其极低的 TTFB 令我惊讶，仔细研究后发现节点是与主机之间建立长连接，而且会保持很长一段时间，此外所有网络都走 Google 内网，本质上与 Argo 和 Railgun 类似。所以目前服务动态内容最快的应该还属 Google Cloud CDN 了，Railgun 基本与之相当。
69 |
70 | ## 静态内容
71 |
72 | CloudFront 自带的 Regional Edge Caches 在**缓存静态内容**和**提高缓存命中率**上要比 Argo Tiered Cache 和 Railgun 好，但是 Argo Smart Routing 在服务于动态的不可缓存的内容上更显出优势。Railgun 和 Google Cloud CDN 除了会在边缘节点缓存之外没有其他专门的优化。
73 |
74 | ## 关于本站的分区解析
75 |
76 | 本站的解析没有使用 Cloudflare 而是 自建的 DNS，因为我的 Cloudflare 域名是通过 CNAME 接入的。Cloudflare 分配的 IP 在很长时间内都不会变动，所以我直接把其 IP 设置为了海外线路。使用自建的DNS是为了在备案后，为国内分区解析配置 CDN 线路。 PS: 大家应该都知道启用这个功能后并不会提升国内连接 Cloudflare 的速度，如果想要用 Cloudflare 并且希望国内快一点，源站最好就用美国西岸的。
77 |
--------------------------------------------------------------------------------
/source/_posts/2016-06-09-wordpress-optimize.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: 几个 WordPress 的加速建议
3 | tags:
4 | - HTML5
5 | - WordPress
6 | - 响应式设计
7 | - 网站
8 | - 网络
9 | id: '1709'
10 | categories:
11 | - - 开发
12 | date: 2016-06-09 17:36:00
13 | languages:
14 | en-US: https://www.ze3kr.com/2016/06/wordpress-optimize/
15 | ---
16 |
17 | WordPress 是目前最流行的内容管理系统，本网站正是使用着它。但对于一个全新安装的 WordPress 来说，它的性能并不是很高，当网站的访问量突然增加时，优化性能就显得十分重要了。通过实施以下几个方案，可以大大提升 WordPress 访问速度：
18 |
19 |
20 | ## 配置缓存
21 |
22 | WordPress 是一个动态的系统，如果不配置缓存，每次请求都需要服务器去读取数据库，生成页面内容，对于不同性能的主机，这可能就需要 20ms~1000ms 甚至更慢。如果能够正确配置缓存，就可以明显的加速，并且减少主机的运算资源。
23 |
24 | ### 配置页面缓存
25 |
26 | 使用插件来配置缓存是最简单的方法。在此推荐 [WP Super Cache](https://wordpress.org/plugins/wp-super-cache/)，这是 WordPress.com 出品的缓存插件，就页面缓存来说，功能非常全面，它支持多种缓存模式，包括 `mod_rewrite`，如果你使用 Nginx，那么[可以使用我这个配置文件](https://gist.github.com/ZE3kr/3c28029ffa4c91392045e9a579599646)，这样可以直接跳过 PHP 而直接服务静态文件，页面相应速度有显著提升。 同时，为浏览器返回正确的 `Cache-Control` 也是十分有必要的，尤其是 CSS 和 JS 文件。
27 |
28 | ### 配置对象缓存
29 |
30 | 对象缓存比页面缓存更灵活，使用范围更广，但速度肯定不如页面缓存。在此推荐 APCu 缓存系统。在 Ubuntu/Debian 安装方法如下：
31 |
32 | $ apt install php-apcu
33 |
34 | 然后重启 Web server，[安装 APCu Object Cache Backend](https://wordpress.org/plugins/apcu/installation/) 即可。 Redis、Memcached 等都算此类型的缓存，不过 APCu 配置最为简单，速度也很快。
35 |
36 | ### 建立分布式缓存系统
37 |
38 | 比如我的网站使用北美东岸（主要）和亚洲的 VPS，主服务器配置了 Nginx，PHP 和 MySQL；亚洲的服务器只配置了 Nginx。在这些服务器上都配置好缓存，并用 lsyncd 同步缓存内容。每次访问时 Nginx 检查缓存，仅当没有缓存时代理，这样可以大大减少首页面的延迟。
39 |
40 | ## 使用 CDN
41 |
42 | ### 使用全站 CDN
43 |
44 | 使用全站 CDN，可以免去在自己的服务器上配置缓存的问题，还可以为服务器增加 HTTPS、HTTP/2 等功能，同时还能过滤非法流量，防御 DDOS（前提是你的 IP 没有被暴露，或者你设置好了白名单）。 除此之外，使用 CDN 后还能更加明显的提高网站加载速度，让访客从中受益。
45 |
46 | #### 使用 CloudFlare
47 |
48 | CloudFlare 是可以免费使用的，使用 CloudFlare 前需要更改 DNS 服务商，然后无需额外配置就能使用了。但是它只会缓存 CSS、JS 和多媒体文件，不会缓存 HTML 页面，也就是说用户每次访问时还是会返回到原始服务器，页面本身的速度不会有明显提高，在原始服务器上配置缓存也是必要的。
49 |
50 | #### 使用 KeyCDN 并配合插件
51 |
52 | [KeyCDN](https://app.keycdn.com/signup?a=7126) 是一个按流量使用付费的 CDN 提供商，使用我制作的插件 [Full Site Cache for KeyCDN](https://wordpress.org/plugins/full-site-cache-kc/) 可以简单的对其配置，这个插件会自动刷新缓存。 KeyCDN 相比 CloudFlare，可以缓存 HTML 页面，大大减少源服务器的压力，同时在刷新缓存时可以通过 Tag 方式刷新，避免不必要的刷新。 在网站访问量较大时，使用 KeyCDN 就能明显的提高速度，缓存命中率也会有很大的提高。
53 |
54 | ### 仅资源部份使用 CDN
55 |
56 | 你可以配置另一个域名，在那个域名上使用 CDN，然后通过插件重写页面地址实现部分 CDN。上文提到的 WP Super Cache 就能配置 CDN，或者使用 [CDN Enabler](https://wordpress.org/plugins/cdn-enabler/) 也能实现部分 CDN 功能。至于 CDN 的选择无所谓，只要支持 [Origin Pull](http://knowledgelayer.softlayer.com/questions/365/How+does+Origin+Pull+work%3F)（也就是请求回源）就行。
57 |
58 | ## 服务器性能
59 |
60 | 提高服务器本身的性能是最简单的方法，使用更大的内存，更多核心的 CPU 能明显提速。除此之外，提高服务器上应用的性能也很重要：
61 |
62 | ### 脚本性能
63 |
64 | PHP 脚本的处理速度是 WordPress 的一大瓶颈，使用最新版本的 PHP，可以获得更高的性能，例如 [7.0 就比 5.6 快了 3 倍](https://www.zend.com/en/resources/php7_infographic)。
65 |
66 | 其次，少用插件能减少 PHP 需要执行的脚本，因为在加载每一个页面时，WordPress 都会加载一遍所有的插件。少量的插件（10个以下）对 WordPress 速度的影响不大，当然也取决于插件本身。
67 |
68 | ### 数据库性能
69 |
70 | 数据库是 WordPress 性能的瓶颈之一，在数据库上优化能提高一定的速度。 一般情况下，如果正确的使用 WordPress，并不需要清理数据库。但可能会有某些插件可能在数据库中创建了太多没用的表，这时服务器的响应速度就会大大降低（约 1～3 倍），推荐使用 [WP-Optimize](https://wordpress.org/plugins/wp-optimize/) 进行清理。 不是太多的文章数量，是不太会的影响加载速度（1 万篇文章以下速度其实都还能接受，不过你写那么多文章干嘛，质量比数量更重要嘛）。
71 |
72 | ## 图片优化
73 |
74 | 图片占据着网页中很大一部分的大小，同时也关系着用户体验。
75 |
76 | ### 图片压缩
77 |
78 | 对图片压缩不仅可以提高访问时图片加载速度，还能减少服务器带宽 推荐使用免费的 [EWWW Image Optimizer](https://wordpress.org/plugins/ewww-image-optimizer/)，可以在服务器上对图片进行处理。如果你的服务器性能有限，可以使用 [Optimus](https://optimus.io/en/) 在线处理，免费版功能十分有限。
79 |
80 | ### 响应式图片
81 |
82 | 对于不同的设备加载不同的图片，比如在手机上加载的图片，就可以比视网膜屏幕的电脑上要加载的图片小的多。使用[本站曾经提到过的 srcset 技术](https://www.guozeyu.com/2015/08/using-srcset/)可以最简单的实现这个功能，只要你的主题支持就可以了（官方的最新默认主题已经支持），如果主题本身不支持，也可以通过插件实现。
83 |
84 | ## 禁用不需要的服务
85 |
86 | WordPress 中有一些自带的服务你可能并不需要，禁用它们可以减少页面所需要加载的资源以及服务器需要做的事情。
87 |
88 | ### Emoji 支持
89 |
90 | WordPress 支持 Emoji 表情符号，但会因此在页面中引入额外的 CSS，[使用这个脚本](https://gist.github.com/MaruscaGabriel/fc7c069860406c77304a)可以禁用它（如果你不需要的话）。
91 |
92 | ### Google Fonts
93 |
94 | Google Font 在国内加载非常慢，而且加载完成之前页面会一直白屏。你可以专门安装 Disable Google Fonts 的插件，或者在下文要提到的 Autoptimize 插件中的设置里禁用它。
95 |
96 | ### Pingback
97 |
98 | 进入 设置 => 讨论 中可以禁用 “尝试通知文章中链接的博客” 和 “允许其他博客发送链接通知（pingback和trackback）到新文章” 功能（如果你不需要的话）。 此功能并不影响页面加载时间。
99 |
100 | ## 减少请求数和页面大小
101 |
102 | 减少请求数在也一些情况下也能提高加载速度，减少页面大小能缩短下载页面所需要的时间。推荐使用 [Autoptimize](https://wordpress.org/plugins/autoptimize/)，它可以 minify CSS、JS 和 HTML，还能 combine CSS 和 JS 以减少请求数。
103 |
104 | 然而，如果你的博客启用了 HTTP/2 协议，那么减少请求数就没什么必要了，不过为了启用 HTTP/2，必须要使用 HTTPS，所以最终下来是快是慢也不好说。不过还是强烈推荐使用 HTTPS，为了安全，牺牲点速度算什么。
105 |
106 | ## 总结
107 |
108 | 做到上面几点，就能有效提速了，我的网站做到以上几点，在国内无缓存的 Wi-Fi 情况下本网站的时间线如下：
109 |
110 | 
111 |
--------------------------------------------------------------------------------
/source/_posts/2022-02-20-iphone-5g-mmwave.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: 毫米波 5G 有多快? 2000Mbps! 快来看看你的 iPhone 是否支持毫米波
3 | tags:
4 | - Apple
5 | - iPhone
6 | categories:
7 | - 科技
8 | date: 2022-02-20 23:59:59
9 | languages:
10 | en-US: https://www.ze3kr.com/2022/02/iphone-5g-mmwave/
11 | excerpt: 本文对比了中频 5G 和毫米波 5G 的速度差异，提供了判断 iPhone 是否使用毫米波的方法，讲述了 5G 不同图标的含义，对比了 5G 的低频、中频和毫米波，并列举了 iPhone/iPad 不同型号对毫米波支持的情况。最近分别使用手头上的国行和美版 iPhone 对比了一下中频和毫米波 5G。都是相同运营商 (Verizon Prepaid) 的相同套餐 (Unlimited Plus)，使用实体 SIM 卡，在完全相同的地理位置进行的测试。
12 | ---
13 |
14 | 本文对比了中频 5G 和毫米波 5G 的速度差异，提供了判断 iPhone 是否使用毫米波的方法，讲述了 5G 不同图标的含义，对比了 5G 的低频、中频和毫米波，并列举了 iPhone/iPad 不同型号对毫米波支持的情况。
15 |
16 | 最近分别使用手头上的国行和美版 iPhone 对比了一下中频和毫米波 5G。都是相同运营商 (Verizon Prepaid) 的相同套餐 (Unlimited Plus)，使用实体 SIM 卡，在完全相同的地理位置进行的测试。
17 |
18 |
19 |
20 | 
21 |
22 | 可以看到，毫米波 5G (高频，mmWave) 轻松跑到了 2000Mbps。
23 |
24 | 
25 |
26 | 如上图所示，[也有人在 Reddit 上](https://www.reddit.com/r/verizon/comments/sv5eit/fastest_5g_uw_and_4g_lte_speeds_known_to_man/)跑出了接近理论峰值的 4000Mbps。但我试了多次最高 “也就” 2000Mbps。
27 |
28 | 
29 |
30 | 中频 5G (Mid-Band) “只” 跑到了 929Mbps。
31 |
32 | 就本次测试看来，毫米波 5G 要比中频 5G 快 2 倍左右。在各自的理想情况下，毫米波 5G 可以比中频 5G 快 2-3 倍。
33 |
34 | ## 如何判断 iPhone 是否使用毫米波？
35 |
36 | 在系统的通话页面输入 `*3001#12345#*`，然后点击呼叫。随后我们就可以看到下方视频所示的 Field Test Mode。选择 5G 中的 Nr ConnectionStats。若看不到 5G 相关选项，则说明当前没有 5G 信号，或机型/运营商不支持 5G。然后看 Band 中的数字。该视频中 band 数字为 78，为中频 5G。
37 |
38 |
39 |
40 | 查询当前使用的 5G 频段
41 |
42 |
43 | 若数字小于 200 (如上图)，则说明没有使用毫米波。若显示大于 200 (常见的有 257-262)，则说明已经连接到了毫米波 5G。具体使用的频率可以参考[这个表格](https://en.wikipedia.org/wiki/5G_NR_frequency_bands#Frequency_bands)。
44 |
45 | 并非所有支持 5G 的 iPhone 都支持毫米波 5G。目前只有在美国购买的 iPhone 12、13、14 系列在美国才能使用毫米波 5G 网络。
46 |
47 | ## 5G 图标
48 |
49 | 根据[苹果官网](https://support.apple.com/zh-cn/HT211828)，5G 是有多种图标的。如果只显示 5G，则是连接到了最普通的 5G，速度比较慢。若看到了 5G+、5G UW 和 5G UC，则说明可能连接到了毫米波 5G，速度更快。但实际上，显示 5G+、5G UW 和 5G UC 并不代表使用了毫米波 5G (也可能只是中频 5G)。此外，在美国之外的其他国家即使连接到了中频 5G，也只显示 5G。
50 |
51 | 
52 |
53 | ## 5G 常见的三种频段：低频、中频、毫米波
54 |
55 | 低频的范围在 1 GHz 以内，中频在 1-6 GHz，毫米波则在 24-40 GHz。
56 |
57 | 低频 5G，也叫 5G Nationwide (Verizon)、Extended Range 5G (T-Mobile)、5G (AT&T)。是覆盖最广的 5G，但速度也不是很理想，有的时候甚至不如 4G/LTE 的速度。目前现有的很多 4G 基站都可以比较轻松的升级为低频 5G。在我看来只是准 5G 网络。
58 |
59 | 中频和毫米波 5G，也叫 5G Ultra Wideband (Verizon)、Ultra Capacity 5G (T-Mobile)、5G+ (AT&T)。是真正意义上的 5G 网络。
60 |
61 | 目前在中国，所有运营商的 5G 均使用中频。相比毫米波，中频在相同的基站数量情况下，覆盖的更广。这是因为中频的波长更长，传播时相比毫米波更不容易被障碍物遮挡。
62 |
63 | LTE-Advance，也叫 5G Evolution (AT&T)。是指使用了载波聚合、4x4 MIMO 和 256 QAM 等技术的 4G 网络。这种网络根本不是 5G 网络，只是比较快的 4G 网络。
64 |
65 | ## iPhone 不同型号支持的 5G 一览
66 |
67 | 在[苹果官网](https://www.apple.com.cn/iphone/cellular/)搜索你的手机型号（如 A2629、A2634、A2639、A2644 则为中国大陆及港澳地区的 iPhone 13 系列的型号），然后查看是否支持 n257-262 中的任何一个频段。截止到目前，只有在美国销售的 iPhone 12/13/14 支持了毫米波。你可以在机身背面看到型号。目前支持毫米波的型号有：
68 |
69 | + A2650: iPhone 14 Pro
70 | + A2651: iPhone 14 Pro Max
71 | + A2649: iPhone 14
72 | + A2632: iPhone 14 Plus
73 | + A2483: iPhone 13 Pro
74 | + A2484: iPhone 13 Pro Max
75 | + A2482: iPhone 13
76 | + A2481: iPhone 13 mini
77 | + A2341: iPhone 12 Pro
78 | + A2342: iPhone 12 Pro Max
79 | + A2172: iPhone 12
80 | + A2176: iPhone 12 mini
81 |
82 | 还有一个更简单的方法：看 iPhone 右侧是否有毫米波天线的开口（图源 Apple）
83 |
84 | 
85 |
86 | 
87 |
88 | 这个毫米波天线开口很像 iPad 系列 Apple Pencil 的无线充电开口，但他们确实不是一个东西，不要混淆。
89 |
90 | 其次，如果你手持 iPhone 14，判断方法更为简单，只要没有实体 SIM 卡槽，就是支持毫米波的美版。
91 |
92 | ## iPad 不同型号支持的 5G 一览
93 |
94 | 同样的，你可以在[苹果官网](https://www.apple.com.cn/ipad/cellular/networks/)搜索你的 iPad 型号。你可以在机身背面看到型号。目前支持毫米波的型号有：
95 |
96 | + A2379: 12.9 英寸 iPad Pro (第五代)
97 | + A2301: 11 英寸 iPad Pro (第三代)
98 |
--------------------------------------------------------------------------------
/source/_posts/2016-06-25-use-gitlab-on-own-server.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: 在自己服务器上安装 GitLab，代替 GitHub！
3 | tags:
4 | - Git
5 | - VPS
6 | - 安全
7 | - 效率
8 | - 网站
9 | - 软件
10 | id: '1731'
11 | categories:
12 | - - 开发
13 | date: 2016-06-25 21:12:08
14 | languages:
15 | en-US: https://www.ze3kr.com/2016/06/use-gitlab-on-own-server/
16 | ---
17 |
18 | 我的服务器上部署的代码、配置文件等内容大多是使用 Git 进行版本控制。为了能够使用、配置起来更方便，通常使用一整套系统去管理。很显然，在一些代码和配置文件里会有一些机密的内容，如一些密钥什么的，所以必须不能公开。GitHub.com 虽然提供了 Private 存放处功能，但是由于此功能是付费的，而且对于 Organization 的 Plan 还是极贵，并不十分划算；就算能有免费的 Private 存放处，把自己的很多重要的密钥放在第三方服务器上还是很不安全，所以能够 Host 在自己的主机上的，并且能够替代 GitHub.com 的软件/服务就是不错的选择。 本文将讲一下我在自己服务器上安装 GitLab 遇到的坑，进阶使用，包括使用 `.gitlab-ci.yml` 文件实现自动 Build，实时同步镜像到 GitHub。
19 |
20 |
21 | 能够 Host 在自己的服务器上的软件/服务其实有很多，比如 GitHub Enterprise，Bitbucket Server。不过再此还是推荐完全开源、免费、由社区维护的 GitLab Community Edition，没有任何限制，只是相比 Enterprise Edition 少了些本来也用不着的功能。
22 |
23 | ## 安装及遇到的坑
24 |
25 | 具体安装方法[见文档](https://about.gitlab.com/downloads/)，目前官方推荐的系统环境是 Ubuntu 16.04 LTS，安装起来非常简便，整个 Web 环境都会配置好。安装后的更多配置请[参见文档](http://docs.gitlab.com/omnibus/)。如果你的主机上跑了不只一个 Web 程序，那就需要对现有的 Web 软件做修改，需要参见官方的 Nginx 的配置文档。我的代码中使用了 `sub_filter` 来实现替换默认的标题，实现更好的 SEO，更加品牌化。 然后为了能达到更好的使用效果，还应该配置 SMTP 发件服务器，我使用的是 AWS SES；然后还需要一个支持 IMAP 的收件服务器实现 Reply by email，我使用的是 Gmail，收邮件的限制总比发邮件的限制少吧～这些的具体设置方法官方文档里都有。 安装后默认是允许注册的，如果你不想让外人注册，你需要直接去 Web 后台禁用。如果你想要开放注册，那么最好先想好新注册用户能干什么，比如和我一样：只允许新用户创建 Issues 和 Snippets，那就在 Web 后台将 Default projects limit 设置为 `0`，然后编辑后台的配置文件，禁止新用户创建 Group。同时建议在 Web 后台启用 reCAPTCHA 和 Akismet，防止恶意注册和恶意发 Issues。既然允许注册，那么也建议[使用 OmniAuth](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/integration/omniauth.md) 来支持第三方 OAuth 的方式登陆。
26 |
27 | ## GitLab Runner
28 |
29 | [GitLab Runner](https://gitlab.com/gitlab-org/gitlab-ci-multi-runner) 十分强大，但是并不是内置的，它可以极其方便的实现自动部署等非常有用的功能。安装配置好 Runner 后，在项目根目录下添加一个名为 `.gitlab-ci.yml` 的文件，以 master 分支为例，为了实现每次 commit 到 master 都将文件部署到 `/var/gitlab/myapp` ，那么文件内容应该是这样的：
30 |
31 | ```
32 | pages:
33 | stage: deploy
34 | script:
35 | - mkdir -p /var/gitlab/myapp
36 | - git --work-tree=/var/gitlab/myapp checkout -f
37 | only:
38 | - master
39 | ```
40 |
41 | 注意，你需要先创建 `/var/gitlab` 文件夹，并设置这个文件夹的用户组为 `gitlab-runner:gitlab-runner`
42 |
43 | ```
44 | $ sudo chown -R gitlab-runner:gitlab-runner /var/gitlab
45 | ```
46 |
47 | `.gitlab-ci.yml` 核心的部分就是 `script:` ，这里的脚本都是由用户 `gitlab-runner` 执行的，你可以根据需要修改，后文中也给了几种范例。 然后 commit，去设置页面里里激活这个项目的 Runner。建议在设置里设置 Builds 为 `git clone` 而不是 `git fetch` ，因为后者常常出现奇奇怪怪的问题，前者的速度瓶颈主要在于网络传输。
48 |
49 | ### 部署 Runner 在同一个主机上，Or not？
50 |
51 | 官方的文档里强烈不推荐把 Runner 部署在同一个主机上，其实这种说法并不正确。官方不推荐这样做是因为一些 build 会花费很长时间，占用很多的 CPU 和内存资源。但是如果你执行的 build 脚本并不会这样，那么安装在同一个主机上也未尝不可。
52 |
53 | ### 常见的部署范例
54 |
55 | 这几种部署是我比较常用的，大家可以当作范例，具体根据自己的需要弄各种不同的部署。 以下几种 Web 的部署方式所消耗的系统资源都不多，而且由于使用了 `nice` ，并不会阻塞其他任务，可以部署在同一台主机上。
56 |
57 | #### Jekyll
58 |
59 | 修改之前那个 `.gitlab-ci.yml` 文件的 `git checkout` 一行，替换为：
60 |
61 | ```
62 | jekyll build --incremental -d /var/gitlab/myapp
63 | ```
64 |
65 | #### 检查 PHP 的编译错误
66 |
67 | 也是添加以下代码到 `.gitlab-ci.yml` 即可自动检查所有 PHP 文件的编译错误，编译通过的文件不会显示，只会显示编译错误的：
68 |
69 | ```
70 | if find . -type f -name "*.php" -exec nice php -l {} \; grep -v "No syntax errors"; then false; else echo "No syntax errors"; fi
71 | ```
72 |
73 | #### 自动与 GitHub 同步
74 |
75 | 以下过程需要 root 权限登陆到主机，或者在每行命令前添加 `sudo`。 首先，需要先给 `gitlab-runner` 用户一个单独的 SSH Key：
76 |
77 | ```
78 | $ ssh-keygen -f /home/gitlab-runner/.ssh/id_rsa
79 | ```
80 |
81 | 然后，创建 `/home/gitlab-runner/.ssh/known_hosts` ，内容是：
82 |
83 | ```
84 | github.com ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAq2A7hRGmdnm9tUDbO9IDSwBK6TbQa+PXYPCPy6rbTrTtw7PHkccKrpp0yVhp5HdEIcKr6pLlVDBfOLX9QUsyCOV0wzfjIJNlGEYsdlLJizHhbn2mUjvSAHQqZETYP81eFzLQNnPHt4EVVUh7VfDESU84KezmD5QlWpXLmvU31/yMf+Se8xhHTvKSCZIFImWwoG6mbUoWf9nzpIoaSjB+weqqUUmpaaasXVal72J+UX2B+2RPW3RcT0eOzQgqlJL3RKrTJvdsjE3JEAvGq3lGHSZXy28G3skua2SmVi/w4yCE6gbODqnTWlg7+wC604ydGXA8VJiS5ap43JXiUFFAaQ==
85 | ```
86 |
87 | 之后，获取 `/home/gitlab-runner/.ssh/id_rsa.pub` 文件内容，[在 GitHub 上添加这个 SSH Key](https://github.com/settings/keys)。 由于是使用 root 帐号，弄完了之后不要忘了修改用户组：
88 |
89 | ```
90 | $ sudo chown -R gitlab-runner:gitlab-runner /home/gitlab-runner/.ssh
91 | ```
92 |
93 | 然后，同样是通过 `.gitlab-ci.yml` 实现自动同步：
94 |
95 | ```
96 | git push --force --mirror git@github.com:[Organization]/[Project].git
97 | ```
98 |
99 | 修改 `[Organization]` 和 `[Project]` 为你自己的名称即可。
100 |
101 | ## 谈谈安装在自己服务器上的 GitLab 的好处
102 |
103 | 文件都存储在自己的服务器里，安全性比较有保障，自己有最高权限，不会遇到项目被删的情况。部署时延迟极低，可靠性也高，不会遇到自己服务器没问题但是第三方服务宕机导致无法部署的窘况。 可以根据情况部署到离自己最近的服务器，或者是内部服务器，像 GitHub 的服务器就在美国东岸，亚洲这边连接并不快，国内也不稳定。 最关键的是，如果你本来就有个 VPS 什么的，也有很大的空闲，那么相当于你可以免费获得私有存放处，但是[要注意性能需求](http://docs.gitlab.com/ce/install/requirements.html#hardware-requirements)，没有足够的空闲还是不要启用。 由于能够配置好实时同步镜像到 GitHub，GitLab 还有那么多 GitHub 没有的功能，其实已经可以完全使用 GitLab 作为主要的版本控制工具，GitHub 只是存一份镜像备用。
104 |
--------------------------------------------------------------------------------
/source/_posts/2018-08-25-backup.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: 谈谈数据备份
3 | tags:
4 | - 备份
5 | - 安全
6 | categories:
7 | - 科技
8 | id: '3603'
9 | date: 2018-08-25 14:05:21
10 | languages:
11 | en-US: https://www.ze3kr.com/2018/08/backup/
12 | ---
13 |
14 | 谁也不希望丢失数据，但这很难避免：文件误删除、意外停电、硬盘损坏、硬盘丢失、自然灾害……以上这些都会导致数据丢失，并且很可能无法直接恢复。相信很多人都有过这样的苦恼。本文将简单介绍备份的 321 原则，以及云端备份和本地备份的最佳实践。
15 |
16 |
17 | ## 典型的数据丢失案例
18 |
19 | * 比如 GitLab.com 的运维人员就曾经误删除过数据：2017 年 2 月 1 日，运维人员使用了 root 账户错误登录到了主服务器上删除了核心服务数据。更严重的是，其中有五种备份方式都失效了。但幸好还留存着一个六小时前的备份，尽管网站在几个小时内无法访问，并且丢失了在备份之后产生的的很多数据，但最终还是恢复了绝大部分的数据，[事件详情](https://about.gitlab.com/2017/02/01/gitlab-dot-com-database-incident/)。
20 | * WannaCry 病毒导致的数据丢失：WannaCry 是一种勒索病毒，针对 Windows 系统的一个漏洞去加密系统上的用户文件，导致用户无法访问这些文件，除非向一个比特币账户转账 $300 ~ $600（相当于几千人民币）。据报道有超过 30 万台电脑受到此病毒的感染。众多企业，包括银行、医院、铁路系统因病毒而无法正常运转。在中国，众多使用教育网的高校学生电脑受此病毒攻击，导致文件丢失。
21 |
22 | 以上的数据丢失都给人们带来了巨大的损失，但倘若我们能够提前做好数据备份，那么就能够降低数据后的损失。
23 |
24 | ## 最佳备份原则：321 原则
25 |
26 | 在进行备份的过程中，我们应该施行 321 原则，这样才能保证备份的可靠性与有效性。
27 |
28 | * **三份**数据拷贝：除了原始的数据之外，要**另存两份数据的备份**。倘若这三个拷贝丢失的概率相互独立（均为 1%），那么三份拷贝同时丢失的概率就仅有 0.0001% 了，这比两个拷贝同时丢失的概率更低。
29 | * **两种**存储介质：在同一种类型的存储介质上的数据更有可能同时丢失。比如你在电脑的内置存储器上存了三份数据拷贝，但如果电脑的磁盘彻底损坏、误格式化磁盘或者丢失了电脑，那么这些数据便一同丢失了。在上述案例中，另一种类型的存储介质可以是移动硬盘、SD 卡、U 盘、CD、DVD 等。
30 | * **一个**异地备份：多个备份间的物理隔离是很重要的。如果这些备份都放在一个房间里，那么一场火灾就足以毁掉所有的备份。如果条件允许，跨城市（间隔 100km 以上）存储备份就已经很安全了。在家和公司分别存放备份也算作异地备份。
31 |
32 | 此外也应该注意备份的**时效性**，如果可能，要尽量缩短备份周期。比如每分钟备份的时效性就强于每小时备份。在数据丢失时，前者只会丢失最近 1 分钟的工作，而后者会丢失最近 1 小时的工作。
33 |
34 | ## 云端备份
35 |
36 | 通常，云端备份是非常可靠的。云端服务器都会帮你做好 321 原则，你只需要选择一家云存储服务商并将要备份的文件上传上去即可。
37 |
38 | 建议选择提供了自动化备份功能的服务商，这样可以省去手动选择文件上传的步骤。通常自动备份还会对文件进行增量备份，即每次备份只上传上一次备份后有改动的文件，这样能大大节省上传时间。
39 |
40 | 一个典型的云端备份的例子是 iOS 中的 iCloud 备份功能，开启该功能后，iOS 设备会自动将图片、通讯录、文档、聊天记录、软件存档等个人数据上传到云端。在购买新的 iOS 设备后，这些数据都能够从云端自动恢复到新设备上。
41 |
42 | ### 使用对象存储进行简单的备份
43 |
44 | 定期将服务器上的重要文件打包上传到对象存储，即可实现简单的备份。可以直接使用 Amazon S3、Google Cloud Storage、阿里云 OSS、腾讯云 COS 的对象存储，上述服务均提供 99.999999999% 的持久性，即文件一旦上传完毕，几乎不可能意外丢失。云服务中的对象存储通常是在一个区域内的多个可用区（通常至少三个）进行存储，每个可用区内也包含文件的多个副本。各个可用区之间有一定的距离，所以这实现了**异地**。[关于区域和可用区，可以详细参考 AWS 的这篇文章](http://docs.aws.amazon.com/zh_cn/AWSEC2/latest/UserGuide/using-regions-availability-zones.html)。
45 |
46 | 云服务的对象存储一般都可以选择地区。通常选择地理位置最近的地区以获得最低的延迟。这些服务通常是按照使用量计费的，主要包括在一定时间内占用的存储空间以及传输数据所用的流量费用。比如你要备份 1GB 的数据，那么每月可能只需要几块钱或几毛钱，甚至是免费的。（不同服务商收费不一）
47 |
48 | 很多服务器上的软件已经集成了使用对象存储进行备份的功能：在服务提供商开通了对象存储后，只需要在软件中配置好授权密钥，就可以使用对象存储进行备份了。如果软件没有集成这种备份功能，那么也可以手动实现简单的备份。比如，使用 `mysqldump` 导出数据库文件，使用 `gzip` 、 `tar` 命令压缩、打包要备份的文件。通常对象存储的提供商也有提供命令行工具，使用这些工具可以简单的将文件上传到对象存储中。如 AWS 有 `aws`，支持 S3 操作；Google Cloud Storage 有 `gsutil`；阿里云 OSS 有 `ossutil`；腾讯云有 `tccli`，支持 COS 操作。
49 |
50 | ### 使用快照对服务器进行全磁盘备份
51 |
52 | 通常快照可以备份服务器磁盘上的所有数据。从快照中恢复也十分方便。这甚至都不需要服务器上的软件支持备份功能。不管是服务器磁盘损坏、系统文件丢失，还是文件删除，都可以从快照中恢复。
53 |
54 | 如果条件允许，建议同时使用对象存储备份和快照备份。
55 |
56 | ## 本地备份
57 |
58 | 尽管云端备份简单、持久性高，但备份大容量的数据的速度与带宽成正比。何况备份所需要的是上行带宽，这通常是运营商所标称的下行带宽的几分之一。而**仅仅是使用普通的机械硬盘进行备份，其速度就已经达到了千兆网络的速度**，而千兆网络普及率低且价格极其昂贵。所以，遇到数据量大、带宽受限、备份/恢复时间有限等一种或几种情况时，本地备份也许更为合适。
59 |
60 | 在本地备份则需要自己做好 321 原则。你需要将数据备份到两个硬盘上（通过局域网或有线连接），并将其中一个硬盘存放在异地。很多桌面操作系统都支持了备份，你可以在最新的 Windows 系统的控制面板中找到备份功能，在 macOS 上使用时间机器（Time Machine）进行备份。建议配置好自动备份。
61 |
62 | 如果条件允许，建议在本地备份的同时，将较重要的文件再备份到云端。
63 |
64 | ## 历史版本的保留
65 |
66 | 我们应该保留文件的早期版本，以便不时之需。保留多个历史版本的文件使用增量备份有助于节省存储空间。如果条件允许，应保留尽可能多的历史版本。
67 |
68 | 早期的版本可以有相对更长的时间间隔，以便节省空间：像 macOS 中的时间机器（Time Machine），它会保留过去 24 小时的每小时备份、过去一个月内的每日备份、以及过去一个月以上的尽可能多的每周备份，直到磁盘空间填满。
69 |
70 | 一些网络存储会自动保留历史版本，比如 Dropbox、Google 云端磁盘、iCloud 等。一些软件也会在本地磁盘里保留历史版本。比如 Git 就会保留每一次提交的历史。
71 |
72 | 建议首先对重要文件保留历史版本，如果可能对所有文件保留历史版本。
73 |
74 | ## 其他
75 |
76 | ### 对象存储的存储类别（Storage Class）
77 |
78 | 通常对象存储提供多种存储类别，不同存储类别有不同的定价和使用场景，合理的使用多种存储类别可以节省支出。
79 |
80 | #### Amazon S3 的主要存储类型
81 |
82 | 按存储价格由高到低排序，持久性均为 99.999999999%，均为多个可用区。
83 |
84 | * **STANDARD**：默认，适合频繁访问的文件
85 | * **STANDARD\_IA**：存储单价更低（默认的 54%），但有额外的检索费用。此外，此类型至少存储 30 天，至少 128kb。
86 | * **GLACIER**：存储单价最低（默认的 17%），不可实时访问，也有额外的检索费用
87 |
88 | 大于 128kb 的且不经常访问的备份建议存储到 STANDARD\_IA，几乎不会再访问的早期的历史版本可以存储到 GLACIER。
89 |
90 | #### Google Cloud Storage 的主要存储类型
91 |
92 | 按存储价格由高到低排序，持久性均为 99.999999999%，均为多个可用区。
93 |
94 | * **Multi-Regional**：多地区存储（比多可用区更强），此存储类型会在一个洲内的多个城市/国家存放文件。按照官网说法上传后的文件会在至少间隔 160 公里的至少两个数据中心存储。适合存放在全球频繁访问的文件
95 | * **Regional**：对应 S3 的 STANDARD
96 | * **Nearline**：对应 S3 的 STANDARD\_IA，是 Regional 价格的 50%，没有最低文件大小限制
97 | * **Coldline**：对应 S3 的 GLACIER，且至少存储 90 天，但支持实时访问，是 Regional 价格的 35%，检索费用比 Nearline 更高。
98 |
99 | 同样的，不经常访问的备份建议存储到 **Nearline**，几乎不会再访问的早期的历史版本可以存储到 **Coldline**。
100 |
101 | #### 阿里云 OSS 的主要存储类型
102 |
103 | 按存储价格由高到低排序，持久性均为 99.999999999%，均为多个可用区。
104 |
105 | * **标准型**：对应 S3 的 STANDARD
106 | * **低频访问型**：对应 S3 的 STANDARD\_IA，是标准型价格的 67%，至少存储 30 天，至少 64kb。
107 | * **归档型**：对应 S3 的 GLACIER，是标准型价格的 28%，至少 64kb。至少存储 60 天，检索费用比低频访问型更高。
108 |
109 | 同样的，不经常访问的备份建议存储到**低频访问型**，几乎不会再访问的早期的历史版本可以存储到**归档型**。
110 |
--------------------------------------------------------------------------------
/source/_posts/2016-02-18-canon-releases-new-aps-c-model-80d-powerful-video-recording-new-af-system-and-cmos.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: 佳能发布新 APS-C 机型 EOS 80D，强悍视频录制、全新的对焦系统和 CMOS
3 | tags:
4 | - 硬件
5 | id: '1277'
6 | categories:
7 | - - 科技
8 | date: 2016-02-18 16:45:10
9 | languages:
10 | en-US: https://www.ze3kr.com/2016/02/canon-releases-new-aps-c-model-80d-powerful-video-recording-new-af-system-and-cmos/
11 | ---
12 |
13 | 80D 就是 70D 的升级版，在 APS-C 中算中高端，目前仅次于 7D Mark II。这次升级亮点不少，而且视频录制也成为 EOS 系列中最好的之一。不少原先在 7D Mark II 上独有的视频拍摄特性，都被添加在了 1DX Mark II 和 80D 上。其次这次升级还使用了全新的 45 点全十字对焦和 2420 万 CMOS。[在亚马逊上购买正品](https://www.amazon.cn/gp/product/B01HPBXKXU?tag=ze3kr-23)
14 |
15 | ## 视频录制
16 |
17 | 并没有什么全新的高级功能，都是以前就有的，或者是软件上的小升级。
18 |
19 |
20 | ### 可有可无的新功能－短片创意滤镜
21 |
22 | 然并卵，电脑后期都可以做的嘛
23 |
24 | > 通过短片创意滤镜功能，可以拍摄得到添加了特殊滤镜效果的短片。这得益于影像处理器的不断进化。包括原有的微缩景观效果短片在内，还有回忆、梦幻、老电影以及黑白分明共5种滤镜效果可供选择。
25 |
26 | ### 视频间隔拍摄
27 |
28 | 就是拍摄多张照片并自动合成视频。据我的理解，应该每次快门都是电子快门，这样可以大大节约快门寿命和电池续航。并且由于自动合成的是 1080p 视频，所以也很省空间，这个功能应该是支持手动模式的。
29 |
30 | > 将按照一定间隔拍摄的静止图像拼接在一起并进行快放的短片形式就是延时短片。可以充分发挥EOS 80D静止图像的画质优势，得到高质量的MOV全高清短片（约30p、25p）。适合拍摄云朵的流动或天空中繁星的运动等，与普通短片相比，被摄体的变化被浓缩在短时间内，效果更加令人印象深刻。拍摄时间间隔的设置范围为从1秒到99小时59分59秒，拍摄张数的设置范围为2张到3600张。
31 |
32 | 然而这是在逗我吗？为什么合成的短片是全高清而不是 4K 呢？ 不得不说，以上两个功能只是软件上的升级而已，将来可能通过软件升级的形式让其它 EOS 相机也具有这些功能。而下面的其它功能中所列的，才是硬件上的升级。
33 |
34 | ### 其它功能
35 |
36 | 这些功能已经在其他的 EOS 相机中有了，但却是曾经 70D 没有的功能。
37 |
38 | * 1080p 下支持 60 帧
39 | * 短片 HDR
40 | * 短片伺服自动对焦时可设置自动对焦速度
41 | * 同时拥有耳机监听口和麦克风口
42 |
43 | ## 全新对焦
44 |
45 | 全新用了 45 点全十字对焦，这相比 70D 的 19 点已经提高了不少了，但是从数字上来看，似乎并不如原先发布的 7D Mark II 上的 65 点全十字对焦，然而实际真的如此吗？
46 |
47 | > 全45点十字型自动对焦感应器，是能够对应F2.8、F4、F5.6光束的自动对焦系统，部分自动对焦点能够兼容F8光束。当使用最大光圈为F5.6及更明亮的大光圈的镜头时，最多可使用45个十字型自动对焦点进行对焦。根据所搭配镜头最大光圈大小，自动对焦点的性质也将随之产生变化。搭配不同镜头或设置不同长宽比时，可使用的对焦点数及对焦方式会有所不同。
48 |
49 | 经过我一番研究，发现一个惊人的新特性：在 F8 下也能有 27 个自动对焦点（其中 9 个是十字对焦），这是 EOS 系列中在 F8 下拥有自动对焦点第二多的机身了（仅次于 1DX Mark II），这样的话即使是长焦配了增倍镜光圈变得非常小后，也能方便的对焦了。
50 |
51 | > 在EF 100-400mm f/4.5-5.6L IS II USM上安装增倍镜 EF 1.4X III，远摄端最大光圈降为F8时也有27个对焦点可以使用。
52 |
53 | 对比一下不同对焦系统在 F8 下的对焦能力：
54 |
55 | 
56 |
57 | 
58 |
59 | 
60 |
61 | 
62 |
63 | 哇塞！80D 好厉害，不过有哪些镜头支持它的 G组的自动对焦呢？
64 |
65 | 1. EF 100-400mm f/4.5-5.6L IS II USM + 增倍镜 EF 1.4X III
66 | 2. EF 200-400mm f/4L IS USM EXTENDER 1.4X + 增倍镜 EF 2X III
67 |
68 | 额，感觉被忽悠了。那不支持的镜头在 F8 下有几个对焦点呢？
69 |
70 | 
71 |
72 | 一个，只有一个，连辅助对焦点都没有，不过至少相比 70D 已经好了些了。 除此之外，全新的 45 点全十字对焦应该是各方面都不如 65 点全十字对焦了。
73 |
74 | ## “全新” CMOS
75 |
76 | > EOS 80D配备了佳能自主研发制造的新CMOS图像感应器，有效像素约2420万。CMOS半导体制造工程导入新的精细化工艺，并采用无间隙微透镜，缩短了微透镜与光电二极管的距离，提高了聚光率。且优化了像素结构，提高了信噪比。与DIGIC 6数字影像处理器联动，在暗光场景下也能得到高解像感，实现精细的表现。
77 |
78 | 这个像素在 APS-C 相机中已经算高的了，然而，这次并没有提升 ISO 的上线，如果不做像素上的升级，ISO 上线能翻一番，到 51200。 然而这块 CMOS 和 760D 的完全一样～ 为什么说它们是一样的？因为从这里可以看出似乎是一样的：
79 |
80 | 1. 全是“7560像素 RGB+红外 测光感应器”
81 | 2. 全支持短片HDR
82 | 3. 像素，能扩展的感光度一样
83 | 4. 都是三重除尘系统
84 |
85 | 但是，有两点不同：
86 |
87 | 1. 80D 上配备的有 Dual Pixel CMOS AF，但是 760D 是 Hybrid CMOS AF III。
88 | 2. 80D 上的常用感光度高一档
89 |
90 | 值得在意的是对焦系统，Hybrid CMOS AF III 只在 750/760D 上出现过，性能表现出色，或许就是限制了的 Dual Pixel CMOS AF。[详情参考 YouTube 上的测试](https://www.youtube.com/watch?v=-86nrBo7_T0)
91 |
92 | ## 其它改进
93 |
94 | ### 100%的光学取景器
95 |
96 | 佳能在EOS的2位数机型上首次配备了视野率约为100%的光学取景器，这个功能还是很重要的。而且 80D 取景器里也多了些新元素，我称其为 “（伪）电子水准仪”
97 |
98 | 
99 |
100 | 为什么是伪呢？因为它的能力有限：
101 |
102 | 
103 |
104 | 正版是这样的，看见正上方的水准仪了吗？双轴的。
105 |
106 | 
107 |
108 | ### 特殊场景模式
109 |
110 | 看到这个模式我就呵呵了，再一次印证了 80D 不会是专业或准专业水准的相机。
111 |
112 | 
113 |
114 | > 特殊场景模式中汇集了一些有代表性的拍摄场景，相机可以配合具体场景进行相应拍摄设置。可选场景有手持夜景、烛光、儿童等共10种。拍摄时操作简便，只要像使用智能手机一样，通过在液晶监视器上滑动手指，触摸选择图标，相机就可以根据被摄体及拍摄环境的特点找到合适的设置拍出好照片。
115 |
116 | ## 购买建议
117 |
118 | 如果你是非专业人士，在 7D Mark II 和 80D 之间选择的话，我推荐 80D，它有触摸屏和 Wi-Fi，确实方便了不少。7D Mark II 在对焦、连拍、耐久度都优于 80D，但是其它方面不一定比它强多少，像素还低一些。 如果是在 5D Mark III、6D 和 80D 之间选择，你的预算不高，并且有录制视频的需求，还是推荐 80D，它的对焦和快门速度都要好于前两者。至于全画幅还是 APS-C，那就是另一个值得讨论的问题了。[关于 80D 的更多信息，可参考佳能官方新闻稿](http://www.canon.com.cn/news/products/2016/pr_2016_02_18-15_00_00.html)
119 |
--------------------------------------------------------------------------------
/source/_posts/2018-11-15-azure-dns-ns1-constellix-compare.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Azure DNS、NS1、Constellix，三家海外 GeoDNS 服务商对比
3 | tags:
4 | - CDN
5 | - DNS
6 | - 网络
7 | id: '3718'
8 | categories:
9 | - 科技
10 | date: 2018-11-15 11:45:54
11 | languages:
12 | en-US: https://www.ze3kr.com/2018/11/azure-dns-ns1-constellix-compare/
13 | ---
14 |
15 | 最近 DNSPod 的解析服务器[宕机了一段时间](https://www.ithome.com/0/394/009.htm)，导致许多 DNSPod 用户的网站无法访问。本文将推荐几个提供 100% SLA 的海外 GeoDNS 服务，可用于替代不稳定的 DNSPod。并介绍一下使用多家 DNS 提供商来提高服务可用性的方法。
16 |
17 | 本文包括 Azure DNS、NS1、Constellix 的全面对比。
18 |
19 |
20 | ## 简介
21 |
22 | 这次推荐的三家 DNS 均是海外的支持 GeoDNS 的服务商，并都支持 Anycast。其中的 Azure DNS 和 NS1 在国内的速度都非常好，是直接走的香港/亚洲线路，平均延迟能够在 50ms 以内，不输国内 DNS 服务商。而这三家的海外速度都是极快的，可以秒杀 DNSPod、CloudXNS、阿里云解析等国内提供商。
23 |
24 | 关于 GeoDNS，精细度最好的是 Constellix：支持国家、省、市（包括中国的省、市），甚至是 AS 号（可以实现分运营商解析）、IP 段。NS1 支持国家、美国的州，也支持 AS 号、IP 段。至于 Azure DNS，通过使用 Traffic Manager，可以支持国家、部分国家的州、IP 段。由于都支持 IP 段，所以理论上支持任意精度的 GeoDNS 了。
25 |
26 | 至于价格，NS1 提供了免费额度（每月 500k 请求），对于小流量网站而言是够用的，可一旦超出这个免费额度，那么收费是很高的：**$8/百万个请求**。相比而言，Azure DNS 和 Constellix 的价格都很便宜了，其中 Constellix 有 **$5/月** 的起价。
27 |
28 | ## 使用多家 DNS 服务商
29 |
30 | 同时使用多家 DNS 服务商是可行的，只要使用服务商的 DNS 记录保持相同即可。这要求所使用的服务商能够配置主域名的 NS 记录（建议但不是必须）。这次介绍的 Azure DNS、NS1、Constellix 三家，以及以前介绍过的 Route 53、Google Cloud DNS、Rage4、阿里云解析均可配置主域名的 NS 记录（其中阿里云解析和 Azure DNS 只能额外添加第三方记录；其他几家可以完全自定义 NS 记录）。而 Cloudflare 以及国内的 DNSPod、CloudXNS、阿里云解析由于不能配置主域名下的 NS 记录，意味着你不能很好的进行 DNS 混用。
31 |
32 | 要使用多家 DNS，有两种实现方法：主服务商和从服务商方式以及两个主服务商方式。完成配置后，将多家的 NS 服务器配置到权威 NS 记录以及域名注册商下的 NS 列表。
33 |
34 | 使用两家服务商会增加配置难度，但可以提高 DNS 服务的稳定性。如最近的 [DNSPod 宕机](https://www.ithome.com/0/394/009.htm)以及 [2016 年的 Dyn 宕机](https://en.wikipedia.org/wiki/2016_Dyn_cyberattack)所导致的众多网站无法访问，均是因为众多网站仅使用了一家 DNS 提供商。如果使用了多家 DNS 提供商，则网站仅会在所使用的所有服务商均发生宕机事故时才会无法访问，而这显然发生概率很小。
35 |
36 | ### 主服务商和从服务商
37 |
38 | 要想这样配置，需要从服务商支持使用 AXFR 从主服务商获取记录，还需要主服务商也支持 AXFR 传输。其中，NS1、Constellix 均可作为主服务商或从服务商，意味着你可以同时使用这两家，并选择任何一家作为主服务商，另一家作为从服务商。
39 |
40 | ### 两个主服务商
41 |
42 | 你也可以使用两个主服务商，并保持所有的记录（包括主域名下的 NS 记录）相同（建议，但不是必须）。建议也将 SOA 的序列号同步。
43 |
44 | ### 样例
45 |
46 | `github.com.` 这个域名就同时使用了 Route 53 和 DYN 的服务。这可以使用 dig 工具验证。
47 |
48 | ```
49 | $ dig github.com ns +short
50 | ns1.p16.dynect.net.
51 | ns2.p16.dynect.net.
52 | ns3.p16.dynect.net.
53 | ns4.p16.dynect.net.
54 | ns-1283.awsdns-32.org.
55 | ns-421.awsdns-52.com.
56 | ns-1707.awsdns-21.co.uk.
57 | ns-520.awsdns-01.net.
58 | ```
59 |
60 | 经检验，在两家 DNS 服务商也配置了相同的记录。
61 |
62 | ```
63 | $ dig @ns1.p16.dynect.net. github.com a +short
64 | 13.229.188.59
65 | 13.250.177.223
66 | 52.74.223.119
67 | $ dig @ns-1283.awsdns-32.org. github.com a +short
68 | 13.229.188.59
69 | 13.250.177.223
70 | 52.74.223.119
71 | ```
72 |
73 | * * *
74 |
75 | 下面逐个介绍一下这三家 DNS 提供商。
76 |
77 | [所有 DNS 测评一览](https://wiki.tloxygen.com/DNS_提供商)（还包括 CloudXNS、Route 53、Cloudflare、Google Cloud DNS、Rage4 以及阿里云解析）
78 |
79 | ## Azure DNS
80 |
81 | 微软 Azure 产品线下的 DNS 服务。使用 Anycast 技术，并且国内能够直接连接到香港/亚洲节点，所以速度很快。
82 |
83 | 值得注意的是，类似 Route 53，Azure 所分配的四个服务器使用的是不同的网段、不同的线路，可能有更高的可用性。
84 |
85 | 注意：Azure 的 DNS 的分区解析可能不兼容 IPv6，这意味的解析结果可能会被 Fallback 到默认线路。
86 |
87 | * 国外速度：★★★★☆，36 ms
88 | * 北美速度：★★★★☆，27 ms
89 | * 亚洲速度：★★★★☆，39 ms
90 | * 欧洲速度：★★★★☆，29 ms
91 | * 国内速度：★★★★☆，49 ms
92 | * 最短 TTL：**0s**
93 | * 国内分区解析：★★★★★，支持配置到中国，支持 IP 段配置（配合 Traffic Manager）
94 | * 国外分区解析：★★★★★，支持配置到大州、国家以及部分国家的州，支持 IP 段配置（配合 Traffic Manager）
95 | * DNSSEC：**不支持**
96 | * IPv6：**支持**
97 | * 记录类型：支持 A、AAAA、CNAME、NS、MX、TXT、SRV、CAA、PTR。
98 | * 根域名 CNAME 优化：**不支持**
99 | * 优先级：**支持**（配合 Traffic Manager）
100 | * 自定义 NS：**仅支持添加额外的 NS**
101 | * 价格：每个域名 $0.5/月，**$0.4/百万个请求**
102 | * 用例 A 价格：**$0.90**
103 | * 用例 B 价格：**$10.50**
104 | * SLA：100%
105 |
106 | ## NS1
107 |
108 | NS1 也使用了 Anycast 技术，并且国内能够直接连接到香港/亚洲节点，所以速度很快。
109 |
110 | * 国外速度：★★★★★，23 ms
111 | * 北美速度：★★★★★，9 ms
112 | * 亚洲速度：★★★★☆，40 ms
113 | * 欧洲速度：★★★★★，20 ms
114 | * 国内速度：★★★☆☆，65 ms
115 | * 最短 TTL：**0s**
116 | * 国内分区解析：★★★★★，支持配置到中国，支持 IP 段配置。
117 | * 国外分区解析：★★★★★，支持配置到大州、国家、美国的州，支持 AS 号、IP 段配置。
118 | * DNSSEC：**支持**
119 | * IPv6：**不支持**
120 | * 记录类型：支持 A、AAAA、AFSDB、CAA、CERT、CNAME、DS、HINFO、MX、NAPTR、NS、PTR、RP、SPF、SRV、TXT。
121 | * 根域名 CNAME 优化：**支持**
122 | * 优先级：**支持**（配合 Traffic Manager）
123 | * 自定义 NS：**仅支持添加额外的 NS**
124 | * 价格：每月前 500k 请求免费，超出部分 **$8.0/百万个请求**
125 | * 用例 A 价格：**$4**
126 | * 用例 B 价格：**$156**
127 | * 用例 C 价格：**$156**
128 | * SLA：100%
129 |
130 | ## Constellix
131 |
132 | 此 DNS 以 GeoDNS 优势著称，使用了 Anycast 保证最低的延迟。
133 |
134 | Constellix 三组有六个 DNS 服务器，每一组使用了不太相同的线路。
135 |
136 | * 国外速度：★★★★☆，31.51 ms
137 | * 北美速度：★★★★★，9.81 ms
138 | * 亚洲速度：★★★★☆，48.87 ms
139 | * 欧洲速度：★★★★★，23.77 ms
140 | * 国内速度：★★☆☆☆，108.9 ms
141 | * 最短 TTL：**0s**
142 | * 国内分区解析：★★★★★，可以精确到每一个省、市，可以配置 ASN 以实现运营商分区解析。
143 | * 国外分区解析：★★★★★，精确到了各个国家、省、市
144 | * DNSSEC：**不支持**
145 | * IPv6：**支持**
146 | * 记录类型：**更加**齐全，只支持 A、AAAA、CNAME、NS、MX、TXT、SRV、HINFO、NAPTR、CAA、CERT、PTR、RP、SPF。
147 | * 根域名 CNAME 优化：**支持**
148 | * 优先级：**支持**
149 | * 自定义 NS：**支持**
150 | * 价格：第一个域名 **$5/月**，此后每个域名 **$0.5/月**。**$0.4/百万个请求**。分区解析 $0.6/百万个请求
151 | * 用例 A 价格：**$5.39**
152 | * 用例 B 价格：**$14.90**
153 | * 用例 C 价格：**$19.30**
154 | * 统计功能：**支持**，可以看到每个国家、城市的请求数。甚至还可以启用日志，看到每一个请求的客户端 IP、IP 数据包类型等等。
155 | * SLA：100%
156 |
--------------------------------------------------------------------------------
/source/_posts/2025-11-14-hertz-debt-collection.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Hertz 租车被讨债总结，我起诉讨债公司的经历
3 | date: 2025-11-15 8:00:00
4 | tags:
5 | - 理财
6 | categories:
7 | - 日志
8 | languages:
9 | en-US: https://www.ze3kr.com/2025/11/hertz-debt-collection/
10 | ---
11 |
12 | > 免责声明：本文不是法律建议。本文信息仅适用起诉讨债公司违反 FDCPA，其他类型诉讼请咨询专业律师。文中所有金额近似到了最近的 $100。
13 |
14 | 既然 Court filing 也是公开的，那我就公布这一页草稿好了，好奇讨债公司/律所的直接看这张图：
15 |
16 | 
17 |
18 | > **TL;DR**
19 | > 1. 还车时不要多说话
20 | > 2. 讨债来讨债时，立刻寄挂号信 (certified mail) 要求债务验证 (debt verification) 并要求停止电话 (cease call)
21 | > 3. 对方继续打电话 → 免费咨询 fee shifting 律师，按FDCPA 维权。（法定赔偿通常每案最高 $1,000）
22 | > 4. 决定起诉后，律师把案件提交到了联邦地区法院
23 | > 5. 提交到法院后，我跟讨债公司达成让我满意的庭前和解，具体和解条款无法公开
24 |
25 | 首先，推荐阅读这篇文章：[经验分享 - 如何正确的与讨债公司作斗争？ - 美国信用卡指南](https://www.uscreditcardguide.com/jingyanfenxiang-ruhezhengquedeyutaozhaigongsizuodouzheng/)。在此我引用一下这篇文章中的一些对付讨债公司的通用内容：
26 |
27 | > 一般的讨债公司要么帮委托方追债，然后拿分成，要么就是以很低的价格买来坏账（比如一万块的债两百块买来），然后想尽办法（无论是威逼利诱还是恐吓威胁）逼着你付钱。只要一百个人里有两三个人付钱，他们就能赚钱。当然，对于不付钱的人，他们有上报信用局毁掉对方信用记录的特权。 正因为如此，FTC专门为他们准备了一部法律来管理规范他们的行为 （否则任何人都可以通过讨债公司找任何人追债并影响对方信用记录，乱套了）- Fair Debt Collection Practices Act
28 |
29 | 我起诉讨债公司的核心点正是因为讨债公司违反了 FDCPA：**在收到我停止电话通知后，仍然给我打了电话**。是的，就是因为不知道哪个 agent 不小心打电话打到我头上了，才有了精彩的反转
30 |
31 | ## 背景
32 |
33 | + 起因是一次 Hertz 租车。取车时我没拍照检查。开出去十分钟才注意到前挡风玻璃有约 1cm 的小碎痕，极大概率是既有损坏，当时想着信用卡有保险就没深究。还车时我主动说明了刚取车就遇到的玻璃问题（事后看来这是最大教训：很多既有的小划痕/小裂痕，在流程中本来就可能被忽略；我主动自证，反而给了对方坑我的可能）
34 | + 门店在原本租金 $200 的基础上直接**加了 “Return on Damage” $400**（这是店员当场在 Google 上搜到的这款车前挡风玻璃的价格），没有提供任何正式的损坏/定损文件，只说“会去调监控检查取车时的画面，如果是既有损坏会撤销”。因此门店从我信用卡中扣除了 $600。之后我再也联系不上门店
35 | + 我向 AmEx 提交保险理赔，因为缺材料被卡住。我多次找 Hertz 要定损/维修凭证未果，于是我用 ChatGPT 写小作文对这 $600 中的 $400 发起了 Partial Dispute，后来也赢了，退回了 Return on Damage 单项，实际支付 $200
36 | + 后续 Hertz 重新发来了定损，是 $900 多，这次是有明细的，于是重新提交 AmEx 保险，AmEx 也全额报销了 $900。Hertz 之后也跟进，我提供给他们了 AmEx 的 Claim number，他们在线查询后电话告诉我“恭喜，你的保险公司已经全额付了”
37 |
38 | ## 事情并未结束：讨债公司登场
39 |
40 | - 过了大概半年，一个第三方讨债公司代表 Hertz 来电，要我支付当初还车时被柜台加上的那 $400，这也正是我 Dispute 掉的那部分金额。
41 | - 我电话里要求使用 Apple Intelligence 录音，对方也同意录音。电话中对方坚称这个费用是租车费，不是维修费。我在电话里要求对方提供 debt verification（债务验证），结果他们只给了我还车时 Hertz 店员给我加上 $400 的原始收据。
42 | - 我非常生气，于是按 FDCPA，和 ChatGPT 一起写了书面债务验证（debt verification）+停止来电（cease call）的挂号信（certified mail）。寄信成本 ~$10（使用的是[Certified Mail Labels.com](https://www.certifiedmaillabels.com)），虽然需要我付钱，但能换来安静与证据链，很值。信以[那篇文章上的](https://www.uscreditcardguide.com/jingyanfenxiang-ruhezhengquedeyutaozhaigongsizuodouzheng/)为模版，要求他们提供由第三方出具的 $400 “Return on Damage” 的 itemized cost。
43 | - 期间我也再次确认了保险理赔情况：AmEx 表示已经给 Hertz 寄了支票（是否兑付当时无法确认），而 Hertz 客服继续打不通。
44 |
45 | ## 大反转：对方持续骚扰
46 |
47 | 正在我等着对方给我邮寄过来他们不可能提供清楚的 Debt Verification 时，转折来了：
48 |
49 | - 大约一个月后，讨债公司无视我的挂号信，再次给我来电。接电话后我立刻要求录音，对方同意后，在电话中声称“已经邮寄验证材料”（我这边从未收到任何讨债公司的回复），以及声称这笔费用是 Return on Damage。还直接问我“现在可以刷卡付款吗？”
50 | - **这一步是触发 FDCPA 保护的关键：我已书面要求停止电话联系，但他们仍打电话骚扰我。**
51 | - 这次来电讨债公司彻底把我激怒了。我之所以要求停止来电，就是因为他们每次打电话语气都非常恶劣，十分影响我心情，间接影响我生活和工作。
52 | - 我随即向 CFPB/BBB 投诉，请求停止骚扰并主张对方赔偿 FDCPA $1,000 statutory damage。对方只答复“关闭债务账户、不再上信报、不再致电”。但对方并未赔偿，也并未承认错误或道歉，因此我不打算放过他们。
53 |
54 | ## 起诉！
55 |
56 | 我把所有的信息全都喂给了当时最好的模型：ChatGPT o3-mini-high，同时也使用了 Deep Research 功能要求它帮我分析已有案例的判决，询问能否获得赔偿。GPT 给到我的是：基本稳赢。GPT 甚至查到了别人因为骚扰电话起诉同一个讨债公司的案例，并给我提供了真实的链接。GPT 更建议我找 fee shifting 的 FDCPA 律师，而不是 small claim court。我随即让 ChatGPT 找了个曾经赢过多次类似 FDCPA 的律所。
57 |
58 | - 我在律所网站线上提交了表格，对方约了个免费律师评估。律师认为除了违反 FDCPA，还可能有 TCPA 角度的问题。告知我最终我能拿到最多 $1,000，如果有 TCPA 违规的话还可以拿 $500/通电话。
59 | - 这个律所和大多数 FDCPA 律师一样：不需要我先付费。**赢了后由讨债公司付我的律师费，我也能拿到赔偿；输了的话律师自己承担产生费用**。只有中途我反悔不想打了，才可能产生费用风险。综合考虑后我决定起诉。
60 | - 我给律师提供了我寄的挂号信、挂号信送达 receipt、来电截图、电话录音、AmEx 赔偿收据、CFPB/BBB 投诉信以及整个事情的来龙去脉。我跟律师之间享有 Attorney-client privilege，所以我把能提供的所有信息都发过去了。
61 | - 律师收到所有资料后，起草了很长的起诉状（Complaint），核心要求包括：
62 | - 要求法院依据 15 U.S.C. § 1692k(a)(2)(A) 判给最高 $1,000 的法定赔偿；
63 | - 要求法院禁止该讨债公司今后再通过电话联系我；
64 | - 要求法院依据 15 U.S.C. § 1692k(a)(1) 判给实际损失赔偿；
65 | - 要求惩罚性赔偿；
66 | - 要求依据 15 U.S.C. § 1692k(a)(3) 由对方承担诉讼费用及合理律师费；
67 | - 以及法院认为合理、公正的其他救济。
68 |
69 | ## 后续：达成和解
70 |
71 | 在案件提交到联邦地区法院后，对方和我的律所商量出来了一个和解方案，我也满意接受了。因为和解保密条款，具体条款不便公开。
72 |
73 | ## 总结
74 |
75 | 1. 还车别多说：一旦主观性描述，很容易被当场加钱，后续追回麻烦。任何 damage 应该交给定损部门定损。
76 | 2. 可疑账单先要“书面凭证”：只给收据截图不等于合法的验证材料。
77 | 3. 讨债来电的第一步是“挂号信”：
78 | - 寄债务验证（debt verification） 请求；
79 | - 明确要求停止电话联系（只接受书面信件/电子邮件）；
80 | - 用 certified mail。
81 | 4. 保存所有证据：账单、短信、通话时间、来电号码、邮寄回执、录音。
82 | 5. 多个投诉渠道同时：信用卡争议（chargeback/dispute）可以控制自己经济损失；CFPB/BBB 投诉也成功让他们进一步调查，并关闭了我的债务账户并书面回复我不再打电话。
83 | 6. 想要拿钱就请律师：这类案件很多是风险代理或由对方承担律师费；自己前期一分钱都不用出（但注意税务问题）
84 |
85 | ## 常见问题
86 |
87 | ### 会被租车公司“拉黑”吗？
88 |
89 | 我起诉的是讨债公司，不是 Hertz 租车公司。我的 Hertz 账户在达成和解后也一直可以正常用。
90 |
91 | ### 是不是小额法庭？要自己出庭吗？
92 |
93 | 这类联邦 FDCPA 案件通常不是小额法庭。如果找了律师，全程不需要自己做什么。我的案件由律师提交到了**联邦地方法院**（U.S. District Court）；全程我只提供了资料，然后签了几个字。我对我的律所很满意，找律师会比小额法庭省事很多，而且律所会帮你争取更高的赔偿。
94 |
95 | ### 能拿多少钱？
96 |
97 | 我无法公开我的和解条款，因此**我无法透露我拿到了多少钱**。这件事因案而异，很多案件以和解收尾。对于达成和解这种情况，对方给的和解金通常考虑到了律师费。我的律师收费是和解金的 45%，其中诉讼的费用（大约 $500）我来承担（换言之我可以拿到 X \* 55% - $500）。需要注意的是如果是达成和解，对方的赔偿金需要全额纳税，律师费和诉讼费不一定能抵税（[Commissioner v. Banks, 543 U.S. 426 (2005)](https://en.wikipedia.org/wiki/Commissioner_v._Banks)）。因此如果当年税率高的话，存在被 IRS 返薅的可能！（**非税务建议**）
98 |
99 | ## 附件：我寄出的挂号信
100 |
101 | 
102 |
--------------------------------------------------------------------------------
/source/_posts/2022-08-09-choose-a-web-service.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: 云服务推荐及选择指南
3 | date: 2022-08-09 09:40:00
4 | # ads: false
5 | tags:
6 | - 网站
7 | - 网络
8 | categories:
9 | - 开发
10 | ---
11 |
12 | 本文推荐一些本人用过或者正在使用的云服务，持续更新。未来还会增加购买建议。
13 |
14 | ## 云计算 Compute/VPS/EC2
15 |
16 | ### 最便宜: Scaleway Stardust
17 |
18 | 0.5GB RAM ，每月 €0.36，限速 100Mbps 不限流量（该价格为**仅 IPv6** 的价格，约¥2.48）[购买链接](https://console.scaleway.com/instance/servers/create?area=fr-par-1&imageKey=1123148c-7660-4cb2-9fd3-7b5b4896f72f&offerName=STARDUST1-S)
19 |
20 | | 内存 | 存储 | CPU 核心数 | CPU 基线 | 带宽 | 价格 |
21 | | --- | --- | --- | --- | --- | --- |
22 | | 1GB | 10GB SSD | 1 | N/A | 100Mbps | €0.36 |
23 |
24 | > * N/A 代表共享核心
25 |
26 | 目前只有 Paris 1 和 Amsterdam 1 有。前往上方购买链接（如果跳转到了登录/注册页面，请在登录后再点一次，即可直达 Stardust 购买页面），如果遇到无货，就拉到最底部复制 API，用 API 创建机器一般可以绕过前端的无货购买限制。
27 |
28 |
35 |
36 | ### 性价比: BuyVM
37 |
38 | 1GB RAM ，每月 CA$3.50 ，1Gbps 不限流量（约¥17.77 ）。[购买链接](https://my.frantech.ca/aff.php?aff=5211)。注意，BuyVM 的计费周期是每月 1 日，所以若购买时不是 1 日，那么首月的价格会有所变化（因为到下个月或下下个月的 1 日不是整一个月）。
39 |
40 | | 内存 | 存储 | CPU 核心数 | CPU 基线* | 带宽 | 价格 |
41 | | --- | --- | --- | --- | --- | --- |
42 | | 1GB | 20GB SSD | 1 | N/A | 1000Mbps | CA$3.50 |
43 | | 2GB | 40GB SSD | 1 | N/A | 1000Mbps | CA$7.00 |
44 | | 4GB | 80GB SSD | 1 | 100% | 1000Mbps | CA$15.00 |
45 | | 8GB | 160GB SSD | 2 | 100% | 1000Mbps | CA$30.00 |
46 |
47 | > * N/A 代表共享核心，100% 代表每个核心均为独立核心
48 |
49 | 配置更高的主机价格是同比例增加的，可以参考 4GB 版本乘以 N。
50 |
51 | 付款时使用支付宝即可使用 CA$ 同币值缴费，相对要比美元便宜很多。本网站就在使用 BuyVM，如果你从美国西部访问此页面，那就会使用 BuyVM 的服务器。
52 |
53 | BuyVM 还可以购买 Block Storage Slab，每 TB 仅需要 $5.00，最低每月 $1.25 就可以买到 256GB。
54 |
55 | ### 国内网络好: AWS Lightsail
56 |
57 | 0.5GB RAM ，每月$3.50 ，限流量 1TB ，可开日本、法兰克福、美国西部均可直连（约¥22.21 ）[购买链接](https://aws.amazon.com/lightsail/)
58 |
59 | | 内存 | 存储 | CPU 核心数 | CPU 基线 | 流量 | 价格 |
60 | | --- | --- | --- | --- | --- | --- |
61 | | 0.5GB | 20GB SSD | 1 | 5% | 1TB | $3.50 |
62 | | 1GB | 40GB SSD | 1 | 10% | 2TB | $5.00 |
63 | | 2GB | 60GB SSD | 1 | 20% | 3TB | $10.00 |
64 | | 4GB | 80GB SSD | 2 | 20% | 4TB | $20.00 |
65 |
66 | > * 代表每个 CPU 的基线性能，均可 Burst，[Lightsail CPU 基线详情](https://lightsail.aws.amazon.com/ls/docs/en_us/articles/amazon-lightsail-viewing-instance-burst-capacity)
67 |
68 | 本网站就在使用 Lightsail，如果你从美国东部或者亚洲 (中国大陆外) 访问此页面，那就会使用 Lightsail 的服务器。Lightsail 可以免费附加静态 IPv4；IPv6 则是随机器附带的，暂不可保留或迁移。此外，Lightsail 的自动快照功能是免费的，可以作为自动备份。
69 |
70 | #### 与其他同类产品对比
71 |
72 | Vultr/Linode/Digital Ocean 都是与 Lightsail 类似的产品，价格也与 Lightsail 十分接近。他们可能没有 CPU 基线的限制，但这也未必是好事，因为失去了限制更有可能受到邻居（同机器上其他用户）的影响。这里有一些优惠码：
73 |
74 | + [Vultr $100 优惠码](https://www.vultr.com/?ref=8963265-8H): 赠金 14 日内有效
75 | + [DigitalOcean $100 优惠码](https://m.do.co/c/3676c36d032c): 赠金 60 日内有效
76 |
77 | ### 大内存、多 IP: OVH VPS
78 |
79 | 2GB RAM，每月 $3.5（或 3 欧元），限速 100Mbps 不限流量，法兰克福可直连中国，但美国可能绕欧洲。OVH 两欧就可以买一个额外 IPv4 ，该 IPv4 没有月费，只要机器在 IP 就一直是你的。一个账户可以买 16 个额外 IPv4。[美国区购买链接](https://us.ovhcloud.com/vps/)、[国际美元区购买链接](https://www.ovhcloud.com/en/vps/)、[国际欧元区购买链接](https://www.ovhcloud.com/en-ie/vps/)
80 |
81 | 美国境内机器只有美国区可以购买，其他位置机器需去国际区购买。
82 |
83 | | 内存 | 存储 | CPU 核心数 | CPU 基线* | 带宽 | 价格 |
84 | | --- | --- | --- | --- | --- | --- |
85 | | 2GB | 20GB SSD | 1 | N/A | 100Mbps | $3.50/€3.00 |
86 | | 2GB | 40GB SSD | 1 | N/A | 250Mbps | $6.00/€5.00 |
87 | | 4GB | 80GB SSD | 1 | N/A | 500Mbps | $11.50/€10.00 |
88 | | 8GB | 160GB SSD | 2 | N/A | 1000Mbps | $23.00/€20.00 |
89 |
90 | > * N/A 代表共享核心
91 |
92 | 本网站就在使用 OVH，如果你从欧洲访问此页面，那就会使用 OVH 的服务器。
93 |
94 | ### 永久免费: Google Cloud Compute Engine
95 |
96 | 美国 `us-central-1`，`us-west-1`，`us-east-1` 区域，1GB RAM ，30GB 最基础的盘，仅 IPv4 ，出站流量自费。这个试用期过了也免费！
97 |
98 | | 内存 | 存储 | CPU 核心数 | CPU 基线* | 流量 | 价格 |
99 | | --- | --- | --- | --- | --- | --- |
100 | | 1GB | 30GB HDD | 2 | 12.5% | 按量计费 | 永久免费 |
101 |
102 | > * 12.5% 代表每个 CPU 可以有 12.5% CPU time，可 Burst，[GCP E2 共享 CPU 详情](https://cloud.google.com/compute/docs/general-purpose-machines#e2-shared-core)
103 |
104 | ### 最灵活: AWS EC2
105 |
106 | [AWS 国际区](https://aws.amazon.com/ec2/)，[AWS 中国区](https://www.amazonaws.cn/ec2/)
107 |
108 | 本网站就在使用 EC2 (中国区)，如果你从中国大陆访问此页面，那就会使用 EC2 的服务器。目前 AWS 中国区仅限企业注册。
109 |
110 | #### 与 Google Cloud 的 Compute Engine 和 Azure 的 VMs 对比
111 |
112 | Google Cloud 的按量付费可能是三者中的最便宜的，此外个人感觉 Google Cloud 的操作页面使用起来相比 Azure 和 AWS 更简单。这几家提供的产品都大同小异，此外他们也都可以预留实例一年到三年，实现最大化折扣
113 |
114 | #### 与阿里云、腾讯云对比
115 |
116 | 最大的区别是计费模式。AWS 无论是国内版还是国际版，均默认使用后付费模式，即类似信用卡，每月支付上一个月结算的账单。而阿里云和腾讯云无论是个人用户还是企业用户，均使用预付费模式。哪怕使用的是按量付费的机器，竟然也需要提前充值；余额耗尽后会直接停机。所以用阿里云或腾讯云的按量计费服务之前，无比要保证有充足的余额，不然将欠费了将直接影响生产环境。
117 |
118 | 此外，阿里云和腾讯云在 API 使用上没有 AWS 方便。虽然 AWS 国内版在国内没有阿里云那么大的占有率，但由于 AWS 国内版和国际版 API 保持了一致，因此 AWS 的文档资源要远比阿里云、腾讯云丰富的多。
119 |
120 | 个人认为，AWS 国际版完胜阿里云、腾讯云的海外区域，AWS 国内版核心问题是支持的可用区太少，只支持北京和宁夏两个区域；Azure 国内版支持的区域比 AWS 国内版要多一点；阿里云和腾讯云在国内区域数量上是远多于 AWS 的。不过在网络方面，目前 AWS 国内版也是 BGP 接入，线路完全不比阿里云差。
121 |
122 | 数据跨境方面（指中国大陆境内与境外之间的跨境），阿里云提供了香港精品网、云企业网，这是 AWS 所没有的。
123 |
124 | ## CDN
125 |
126 | 等待补充
127 |
130 |
131 | ## DNS
132 |
133 | 等待补充
134 |
135 | ## 域名注册类
136 |
137 | 等待补充
138 |
--------------------------------------------------------------------------------
/source/_posts/2016-05-29-rage4-best-dns.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: CloudXNS、Route 53、阿里云解析等 DNS 服务的全面对比
3 | tags:
4 | - DNS
5 | - 网站
6 | - 网络
7 | id: '1668'
8 | categories:
9 | - - 科技
10 | date: 2016-05-29 14:43:00
11 | languages:
12 | en-US: https://www.ze3kr.com/2016/05/rage4-best-dns/
13 | ---
14 |
15 | DNS（[域名系统](https://zh.wikipedia.org/wiki/域名系统)）是因特网的一项服务。它能够将域名指向一个 IP（服务器），这样你就可以通过域名来访问一个网站。能够通过域名访问的网站，都需要一个 DNS 服务器。这里指的是给站长的域名使用的权威 DNS 而并非缓存 DNS。本文包括 CloudXNS、Route 53、Cloudflare、Google Cloud DNS、Rage4 以及阿里云解析的全面对比。
16 |
17 |
18 | ## CloudXNS
19 |
20 | **备注**：CloudXNS 不支持 TCP。
21 |
22 | 国内免费 DNS 中最好用的，作为 DNS 服务来说其功能也算齐全。CloudXNS 的服务器国内有不少，但没有使用 Anycast 技术，所以谈任何国外的服务器都是白搭。
23 |
24 | CloudXNS 通过 GeoDNS 对其 NS 服务器的域名进行分区解析，国内的解析到国内服务器，国外的解析到国外服务器。然而其根域名的 Glue Record 中的四个仍是国内的四个服务器，实际解析中会优先使用 Glue Record，所以并不会用上任何国外的服务器。
25 |
26 | 为什么不将这些国外服务器也添加到 Glue Record 上？因为 Glue Record 并不支持 GeoDNS，所以解析器将会随机选择服务器，所以如果这样的话会导致国内的一部分请求也走到美国服务器，反而减速。
27 |
28 | * 国外速度：★☆☆☆☆，248 ms
29 | * 北美速度：★☆☆☆☆，272 ms
30 | * 亚洲速度：★★☆☆☆，196 ms
31 | * 欧洲速度：★☆☆☆☆，283 ms
32 | * 国内速度：★★★★☆，32 ms
33 | * 最短 TTL：**60s**
34 | * 国内分区解析：★★★★★，精确到绝大多数的运营商和省
35 | * 国外分区解析：★★☆☆☆，精确到了大洲和一些国家，而没有城市
36 | * DNSSEC：**不支持**
37 | * IPv6：**不支持**
38 | * 记录类型：**基本**齐全，只支持 A、AAAA、CNAME、NS、MX、TXT、SRV。
39 | * 根域名 CNAME 优化：**不支持**
40 | * 优先级：**支持**，可以配置解析到不同的服务器的优先级
41 | * 自定义 NS：**不支持**，由于它不支持修改根域名下的 SOA 和 NS，所以这是做不到的
42 | * 价格：**免费，按功能收费**
43 | * 用例 A 价格：**免费**
44 | * 用例 B 价格：**免费**
45 | * 用例 C 价格：**免费**
46 | * 统计功能：**支持**，能精确到国家和省份、运营商
47 | * SLA：99.9%。(超出防护峰值或账户月解析量时降为98%)
48 |
49 | ## Route 53
50 |
51 | 国外相当流行的 DNS 服务，必要的那些功能也算齐全。服务器都遍布全球，使用了 Anycast 保证最低的延迟。
52 |
53 | * 国外速度：★★★☆☆，84 ms
54 | * 北美速度：★★★☆☆，61 ms
55 | * 亚洲速度：★★★☆☆，79 ms
56 | * 欧洲速度：★★★☆☆，82 ms
57 | * 国内速度：☆☆☆☆☆，328 ms
58 | * 最短 TTL：**0s**
59 | * 国内分区解析：★★½☆☆，只能为中国这一个地区作单独设置，不支持省和运营商。若使用 Regional 智能解析，那么可以设置偏向于宁夏和北京的两个服务器。
60 | * 国外分区解析：★★★★★，精确到了各个国家，众多的国家还精确到了省/市
61 | * DNSSEC：**不支持**
62 | * IPv6：**支持**
63 | * 记录类型：**更加**齐全，支持 A、AAAA、CNAME、NS、MX、TXT、SRV、PTR、SPF、NAPTR、CAA。
64 | * 根域名 CNAME 优化：**不支持**
65 | * 优先级：**支持**
66 | * 自定义 NS：**支持**，同时也可以修改根域名下的 SOA 和 NS
67 | * 价格：每个域名 **$0.5/月**，**$0.4/百万**个请求，分区解析 $0.7/百万个请求
68 | * 用例 A 价格：**$0.90**
69 | * 用例 B 价格：**$10.50**
70 | * 用例 C 价格：**$16.50**
71 | * 统计功能：基本**不支持**，只有在每月最后结算的账单中看到
72 | * SLA：100%
73 |
74 | ## Cloudflare
75 |
76 | 国外占有量相当大的免费 DNS，服务器都遍布全球，使用了 Anycast 保证最低的延迟。
77 |
78 | * 国外速度：★★★★★，13 ms
79 | * 北美速度：★★★★★，10 ms
80 | * 亚洲速度：★★★★☆，30 ms
81 | * 欧洲速度：★★★★★，8 ms
82 | * 国内速度：★★☆☆☆，193 ms
83 | * 最短 TTL：**120s**
84 | * 国内分区解析：☆☆☆☆☆，完全不支持国内的分区解析，国内的请求一般会被认作美国西岸。
85 | * 国外分区解析：★★★☆☆，如果购买了 Load Balancing 服务后，可以根据不同的区域配置分区解析。虽然没有按国家和城市区分，但是有时却比国家还精细（比如它支持为北美洲东西中部不同地区作分区解析）
86 | * DNSSEC：**支持**，同样支持 DNSSEC 特有的记录，包括 SSHFP、TLSA、DNSKEY、DS
87 | * IPv6：**支持**
88 | * 记录类型：**更加**齐全，支持 A、AAAA、CNAME、TXT、SRV、LOC、MX、NS、SPF、CERT、NAPTR、SMIMEA、URI
89 | * 根域名 CNAME 优化：**支持**
90 | * 优先级：支持，需要购买了 Load Balancing 服务
91 | * 自定义 NS：**不支持**，购买 $200/月的 Business 版本后才能支持
92 | * 价格：**免费**
93 | * 用例 A 价格：**免费**
94 | * 用例 B 价格：**免费**
95 | * 用例 C 价格：**$20.00**
96 | * 统计功能：部分**支持**，免费用户可以看到的统计有限
97 | * SLA：无（Business 和 Enterprise 版本有 100% 的 SLA 保障）
98 |
99 | ## Google Cloud DNS
100 |
101 | 价格低廉，提供 100% 的 SLA，使用了 Anycast 保证最低的延迟。
102 |
103 | * 国外速度：★★★☆☆，60 ms
104 | * 北美速度：★★★☆☆，53 ms
105 | * 亚洲速度：★★★☆☆，95 ms
106 | * 欧洲速度：★★★★☆，30 ms
107 | * 国内速度：★★☆☆☆，171 ms
108 | * 最短 TTL：**0s**
109 | * 分区解析：☆☆☆☆☆，**不支持**
110 | * DNSSEC：**支持**，同样支持 DNSSEC 特有的记录，包括 IPSECKEY、SSHFP、TLSA、DNSKEY、DS
111 | * IPv6：**支持**
112 | * 记录类型：**几乎完全齐全**，支持 A、AAAA、CNAME、NS、MX、TXT、SRV、SPF、LOC、NAPTR、PTR、CAA 以及上方列出的 DNSSEC 相关记录。
113 | * 根域名 CNAME 优化：**不支持**
114 | * 自定义 NS：**支持**
115 | * 价格：每个域名 **$0.2/月**，**$0.4/百万个请求**。
116 | * 统计功能：基本**不支持**，只有在每月最后结算的账单中看到
117 | * SLA：100%
118 |
119 | ## Rage4
120 |
121 | 同时支持 DNSSEC 和分区解析，使用了 Anycast 保证最低的延迟。
122 |
123 | * 国外速度：★★★★☆，30 ms
124 | * 北美速度：★★★★★，18 ms
125 | * 亚洲速度：★★★☆☆，59 ms
126 | * 欧洲速度：★★★★☆，26 ms
127 | * 国内速度：★★☆☆☆，153 ms
128 | * 最短 TTL：**根据套餐情况而定**
129 | * 国内分区解析：★★☆☆☆，只能为亚洲东部为中国配置解析
130 | * 国外分区解析：★★★★☆，可以根据不同的区域配置分区解析
131 | * DNSSEC：**支持**
132 | * IPv6：**支持**
133 | * 记录类型：**更加**齐全，支持 SOA、NS、A、AAAA、CNAME、TXT、MX、SRV、PTR、SPF、SSHFP、TLSA、LOC、NAPTR
134 | * 根域名 CNAME 优化：**支持**
135 | * 优先级：**支持**
136 | * 自定义 NS：**支持**，同时也可以修改根域名下的 SOA 和 NS
137 | * 价格：每个域名 **€2/月** 起，根据功能而非使用量定价
138 | * 用例 A 价格：**€2**
139 | * 用例 B 价格：**€10**
140 | * 用例 C 价格：**€100**
141 | * 统计功能：**支持**，能精确到国家
142 | * SLA：99.99%
143 |
144 | ## 阿里云解析
145 |
146 | 阿里云旗下产品，解析服务器全部使用阿里云机房，有速度保障。按照使用功能而非解析量收费。服务器国内有不少，但没有使用 Anycast 技术，所以国外速度很差。 测速基准：
147 |
148 | ns1.alidns.com. 106.11.141.111
149 |
150 | 阿里云付费版与免费版线路有所不同，付费版含有海外线路，但由于没有 Anycast，所以最终线路是随机选择的，所以付费版与免费版相比，其在国外的响应时间稍短，在国内的解析时间稍长。 **备注**：阿里云 DNS 不支持 TCP。
151 |
152 | * 国外速度：★☆☆☆☆，238 ms
153 | * 北美速度：★☆☆☆☆，229 ms
154 | * 亚洲速度：★★☆☆☆，186 ms
155 | * 欧洲速度：★☆☆☆☆，251 ms
156 | * 国内速度：★★★★☆，33 ms
157 | * 最短 TTL：免费套餐：**600s**；付费套餐：1~120s
158 | * 国内分区解析：★★★★★，免费版支持运营商，付费版支持地域解析
159 | * 国外分区解析：★★★☆☆，免费版仅支持海外，付费版可以支持到洲、国家
160 | * DNSSEC：**不支持**
161 | * IPv6：**不支持**
162 | * 记录类型：支持 A、AAAA、CNAME、NS、MX、TXT、SRV。其中 CAA 仅限付费版。
163 | * 根域名 CNAME 优化：**不支持**
164 | * 优先级：**支持**
165 | * 自定义 NS：**不支持**
166 | * 价格：**免费，按功能收费**
167 | * 用例 A 价格：**免费**
168 | * 用例 B 价格：**免费**
169 | * 用例 C 价格：**免费**
170 | * 统计功能：**仅限付费版**
171 | * SLA：99.95%
172 |
--------------------------------------------------------------------------------
/source/_posts/2017-01-07-suggestion-on-hosting.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: 关于建站和服务选购的一些建议
3 | tags:
4 | - VPS
5 | - 网站
6 | - 网络
7 | id: '1752'
8 | categories:
9 | - - 科技
10 | date: 2017-01-07 07:00:18
11 | languages:
12 | en-US: https://www.ze3kr.com/2017/01/suggestion-on-hosting/
13 | ---
14 |
15 | 建立网站、建立软件（或游戏）的服务器等，可能会有很多纠结的地方，也有很多坑，这篇文章根据我个人的经验来帮助大家选择最适合自己的方案，以及一些建议，在最后列出来一些我推荐的服务。
16 |
17 | ## 服务的三种类型
18 |
19 | 一般的，建站所需要购买的服务也是属于这三种服务之间的。从 SaaS、Paas 到 IaaS，依次从使用简便到复杂，从可拓展性低到高。了解这三种服务类型有助于选择合适的服务。
20 |
21 |
22 | + **SaaS，软件即服务**：比如 WordPress.com 等提供了一整套服务（包括了域名、主机、平台和软件）的，就算是 SaaS，这种服务对于初学者使用起来最方便，专业人士也能玩出不少花样，但可拓展性受到软件的限制，通常这种服务都有较高的可用性，并且是分布式的。
23 | + **PaaS，平台即服务**：比如基于 cPanel、Plesk 面板的虚拟主机，你可以在平台上安装已有的开源软件，或者将自己软件代码上传，总体使用几乎和 SaaS 一样简单，使用特定的操作系统和代码语言，安装各种程序。PaaS 有普通的也有分布式的，后者的在可用性和数据保障，以及可拓展性上都要好于前者。
24 | + **IaaS，基础设施即服务**：包括 VPS、独立服务器、云 VPS 和共有/私有云服务器。VPS 和独立服务器相比主要差距是在配置上，包括 CPU、内存、硬盘等，后者的配置会高很多，可用性方面没有太大区别。云 VPS 和共有/私有云实际上是基于云端分布式的 VPS 和独立服务器，一样的，他们的在可用性和数据保障，以及可拓展性上都要好于 VPS 和独立服务器。IaaS 需要自己选择操作系统，所有的服务和软件都是自己配置，通常都给你 root 权限。
25 |
26 | ## 服务的选择
27 |
28 | + **位置选择之国内**：首先需要考虑的是国内还是国外？如果选择国内，首先你得域名需要经过备案，这可能需要将近一个月时间，这无疑为建网站增加了不少成本。而且国内的服务器普遍较贵。不过如果要选择国内，我比较推荐的主机是新浪的 SAE，它价格很低，是按需付费，并且还有免费额度，它属于分布式的 PaaS，提供高可用率的服务，**支持 Docker 容器**、DDOS 防御。不过 SAE 对于非企业用户不提供 CDN 和自定义域名 HTTPS，我推荐你使用 UPYUN 来实现 CDN 和自定义域名 HTTPS 功能。国内的优点：可以保证网络延迟低，并能符合目前的一些法律政策。
29 | + **位置选择之国外**：不少亚洲的主机（包括但不限于香港、日本、新加坡）从大陆连接会 “绕道”，导致延迟很高，购买前需要先了解清楚，香港便宜的共享主机推荐 [TlOxygen](https://domain.tloxygen.com/web-hosting/index.php?promo=ze3kr)。亚洲的主机普遍网络带宽不大，流量比较少，如果不选择亚洲的，那就建议先选北美的。国外的主机通常会有比国内很多主机更低的价格，更好的国际带宽。 如果有条件，可以配置多个服务器，**两个服务器**推荐的解决方案是**亚洲 + 北美**东岸，并将亚洲和大洋洲都指向亚洲，其余的都指向北美。如果有条件配置更多服务器，那么可以同时配置**北美东岸 + 北美西岸 + 欧洲 + 亚洲**的四个服务器并分区解析，就我的实际测试而言，把非洲指向欧洲，把大洋洲指向北美西岸能达到最快的速度。
30 |
31 | **一些可能需要的特性**：基于要实现的不同功能，可能需要在以下方面有要求，在选择服务的时候需要优先考虑。
32 |
33 | * **高数据可靠性**：几乎所有的网站或是和网络相关的软件，都需要存储用户的数据，所以高数据可靠性是十分重要的。所以磁盘阵列为 RAID1 和 RAID10 是首选。而且用户数据的备份也是十分重要的，可以存储在第三方如 AWS S3。一些服务提供商提供了备份功能，其实也是能够保证高数据可靠性。
34 | * **防御攻击的能力**：攻击的成本已经越来越低，种类也很多。通常最难防御的攻击种类是 DDOS，其余的几乎都可以通过软件实现。建议在选择服务器时就要选择有 DDOS 防御的服务器，或者直接使用 CloudFlare 之类的基于第七层的防御。
35 | * **可伸缩，按需付费**：最简单的例子就是网络的计费方式不是按照带宽计费，而是按照每 GB 多少钱计费，不限带宽，能够避免不必要的支出的同时还会让用户享受最快的速度。同样的道理，按照系统资源的使用来计费的模式是最好的选择。一般的，基于云端的 PaaS 都是这种计费方式，IaaS 则需要自行配置来实现资源不够时升级配置，资源过剩时回收配置（也可以是 Auto Balancing），所以按小时（或分钟、秒种）级别的计费 IaaS 计费方式最适合这样伸缩以达到按需付费的目的。
36 | * **网络可靠性**：网络可靠性也十分重要，如果服务的网络不好，那么将极大的影响用户体验，导致用户不可以使用服务。
37 | * **SLA**：重要的服务都需要 SLA，SLA 能给你承诺服务的可用率，当服务没有满足承诺时，服务提供商会给你赔偿。
38 | * **IPv6**：就目前来看，如果不支持 IPv6 也没什么问题。但是能有原生的 IPv6 支持总比没有好，而且现在正在有越来越多的运营商支持 IPv6，使用 IPv6 有可能会有更低的网络延迟，同时配置 IPsec 也有优势。
39 |
40 | ## 其他
41 |
42 | + **域名相关**：不管你是选择使用虚拟主机、VPS 或是独立服务器，通常你还需要自己买一个域名，配置 DNS 解析等等，推荐免费的 DNS 解析有 CloudFlare、Rage4，国内还有 CloudXNS，一些虚拟主机商以及域名注册商也提供免费的解析，但不如前面介绍的那几个（[详细关于 DNS 的介绍请见此](https://www.guozeyu.com/2016/05/rage4-best-dns/)）。如果选择使用 CloudFlare，那么你还可以在 DNS 后台选择开启 Proxy（CDN），这样能为你的网站缓存并加速（但实际上对于国内来说有可能反而减速），并获得一些基础的 DDOS 防护，并隐藏你的源站 IP 地址。
43 | + **域名注册商的选择**：首先，要保证总的域名保有量大；其次，要域名后缀种类齐全；第三，最好能附加免费的企业邮箱和高级的隐私保护；第四，域名注册后要能删除并退款，防止手抖注册错了；第五，价格不能太贵。在我做的 [TlOxygen](https://domain.tloxygen.com/?promo=ze3kr) 这个公共域名注册服务上，使用的域名注册商是全球前十大域名注册商；有 500 多种域名后缀，数量超过 GoDaddy；赠送企业邮箱，可以配置无限个转发邮箱，甚至还可以配置子域名邮箱，还支持 DKIM；大多数种类域名删除可以拿到退款；价格比 Godaddy 便宜很多，续费价格没那么坑，基本上是 7 折；域名隐私保护只有 5 元，但功能比很多免费的高级：即使开了域名隐私保护，别人给你发邮件时，会收到表格，还能继续填写表格与你联系。
44 |
45 | ## 一些服务商的推荐
46 |
47 | 排列的顺序只是与添加在这个列表里的时间有关，新添加的会被放在后面。此处添加的服务商全是个人的推荐的，以后还会持续更新。 标注列表：
48 |
49 | * (6)：全面支持 IPv6
50 | * (6)：部分支持 IPv6
51 | * (D)：支持免费 DDOS 防御
52 |
53 | ### SaaS
54 |
55 | #### 建立网站
56 |
57 | * [WordPress.com](https://wordpress.com)
58 | * [Tumblr](https://www.tumblr.coom) (6)
59 | * [GitHub Pages](https://pages.github.com)
60 |
61 | #### CDN
62 |
63 | 以下 CDN 都支持 HTTPS 与 IPv6
64 |
65 | * [UPYUN/又拍云](https://www.upyun.com) (6)
66 | * [CloudFront](https://aws.amazon.com/cloudfront/) (6)
67 | * [CloudFlare](https://www.cloudflare.com) (6、D)
68 |
69 | #### DNS
70 |
71 | * [Route 53](https://aws.amazon.com/route53/) (6)
72 | * [Rage4](https://rage4.com) (6、D)
73 |
74 | #### 数据存储
75 |
76 | * [AWS S3](https://aws.amazon.com/s3/)
77 |
78 | #### 代码托管
79 |
80 | * [GitHub](https://github.com)
81 | * [GitLab.com](https://gitlab.com)
82 | * [Coding](https://coding.net)
83 |
84 | SaaS 还有很多，太多的东西都是 SaaS 了，所以这里只能算举几个例子。
85 |
86 | ### PaaS
87 |
88 | #### 虚拟主机
89 |
90 | * [BlueHost](https://www.bluehost.com/shared)
91 |
92 | #### 云主机
93 |
94 | 或者说是分布式的虚拟主机，但是有独立的 CPU 和内存资源。
95 |
96 | * [ResellerClub](https://www.resellerclub.com/cloud-hosting)
97 | * [BlueHost](https://cloud.bluehost.com/products/cloud-sites/)
98 |
99 | #### 可自选软件语言的/Docker 容器
100 |
101 | * [新浪 SAE](https://sae.sina.com.cn) (6¹、D)
102 | * [OpenShift](https://www.openshift.com)
103 | * [AWS Elastic Beanstalk](https://aws.amazon.com/elasticbeanstalk/)
104 | * [AWS EC2 Container Registry](https://aws.amazon.com/ecr/)
105 |
106 | ### IaaS
107 |
108 | #### VPS/Cloud
109 |
110 | 标注列表：
111 |
112 | * (U)：独享 CPU³
113 | * (C)：基于云端的技术，高可用性
114 | * (S)：关机后不计费
115 |
116 | * [Vultr](https://www.vultr.com/?ref=6886257) (6、D⁶)
117 | * [OVH](https://www.ovh.com) (6²、D、C⁴)
118 | * [Google Compute Engine](https://cloud.google.com/compute/) (D⁵、C、U、S)
119 | * [Linode](https://www.linode.com) (6)
120 | * [DigitalOcean](https://www.digitalocean.com) (6)
121 | * [AWS EC2](https://aws.amazon.com/ec2/) (S)
122 | * [QingCloud/青云](https://www.qingcloud.com) (S)
123 | * [腾讯云](https://www.qcloud.com)
124 |
125 | ### 备注
126 |
127 | 1. SAE 的 IPv6 的激活需要额外的月付
128 | 2. OVH 的 SSD VPS 暂时不支持 IPv6
129 | 3. 在购买某种配置时，若告知你是共享 CPU，那么还是共享 CPU
130 | 4. OVH 只有 Cloud VPS 是基于云端的 VPS
131 | 5. Google 官方并没有明确说明提供 DDOS 防御，但实际上是有能力防御的
132 | 6. Vultr 的 DDOS 防御需要额外购买，且仅部分地区支持，最大防御仅 10Gbps
133 |
--------------------------------------------------------------------------------
/source/_posts/2022-04-10-own-domain-1.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: 从零开始建立自己的域名和企业邮箱
3 | date: 2022-04-10 04:40:00
4 | # ads: false
5 | tags:
6 | - 建站教程
7 | - 网站
8 | - 网络
9 | - DNS
10 | categories:
11 | - 开发
12 | ---
13 |
14 | 本文将带领你注册属于自己的域名，并获得以自己的域名结尾的专属邮箱。全程仅需不到 10 分钟\[1\]。你只需要一台可以上网的设备，支付方式（微信/PayPal/银行卡）和一个现有邮箱。通过本文提到的域名注册商注册的 .com 域名价格为 CN¥79.20/年，并且续费不涨价。该域名注册商免费提供企业邮箱服务，因此不需要额外付费。
15 |
16 |
17 |
18 | > \[1\]：由于全球 DNS 服务器同步需要时间，可能需要 24-72 小时后域名上的服务才能够使用。若注册 `.cn` 等中国域名还需要进行实名认证，需要额外的时间。其他国际域名（如 `.com`）则不需要实名认证。
19 |
20 | ## 注册域名
21 |
22 | 首先，你需要注册一个属于自己的域名。域名的注册门槛很低，基本在几分钟内就可以完成注册，并且包括 .com 在内的众多域名后缀均不需要进行实名登记。通常，大多数域名都是按年进行购买。
23 |
24 | 本文推荐的是 [氧熙域名注册](https://yangxi.tech/) (原 TlOxygen)。该注册商是本站站长亲自建立，是[全球第 7 大](https://domainnamestat.com/statistics/registrar/others)的域名注册商 PDR Ltd. 的最高级代理之一，提供更多的支付方式和更低的价格。从这里购买域名可以帮助本站持续发展。并且本站域名注册提供了域名删除与退款服务、免费企业邮箱和域名锁等服务。
25 |
26 | 首先，前往 [氧熙域名注册](https://yangxi.tech/)主页（也可以浏览器地址输入 `yangxi.tech` 前往），进行域名搜索。比如，如果想要注册 `guozeyu.com`，只需要在搜索框里输入这个域名并点击搜索。如果你不确定想要注册什么后缀，那么也可以不输入后缀，如 `guozeyu`。如果你更习惯英语界面，或者需要以美元计费的结算方式，请前往 [International Version](https://www.tloxygen.com/)。
27 |
28 | 
29 |
30 | 
31 |
32 | 可以看到，咱们心仪的域名已经被注册了。但是页面下方可以看到更多的 “其他可注册的匹配域名”。
33 |
34 | 
35 |
36 | 我们这里选择 `guozeyu.online`。注意划线价为域名续费的价格，为了可以方便地给域名续费，建议选择续费价格较低的域名。比如 `.com` 域名续费只需 CN¥79.20/年（国际版为 US$12.59/年），而 `.online` 的续费价为 CN¥270.00。我对域名的价格一向非常透明，我承认这绝不是市面上最低的价格。下表列出了一些注册商 `.com` 域名的**续费价格**
37 |
38 | | 注册商 | 美元/年 | 人民币/年 |
39 | | ----- | ----- | ----- |
40 | | **氧熙/TlOxygen** | **13.79** | **87.60** |
41 | | 阿里云万网 \[2\] | 10.99 | 79.00 |
42 | | DNSPod \[2\] | - | 72.00 |
43 | | NameCheap | 14.58 | - |
44 | | GoDaddy | 19.99 | - |
45 | | Cloudflare Registrar \[3\] | 9.15 | — |
46 | | NameSilo | 10.95 | — |
47 | | Google | 12.00 | — |
48 |
49 | > \[2\]：阿里云万网/DNSPod 注册 .com 域名需要实名认证，可能需要几天后域名才能够正常使用
50 | > \[3\]：Cloudflare Registrar 上注册的域名不支持修改 DNS 解析商、NS 记录，以及粘附记录（Glue Record）
51 |
52 | 完整的价格列表：[中国大陆（人民币）](https://www.yangxi.tech/domain-registration/domain-registration-price.php)， [International Version (USD)](https://www.tloxygen.com/domain-registration/domain-registration-price.php)
53 |
54 | **注意，本文后续的内容仅适用于在氧熙注册的域名。在其他注册商注册的域名配置有所不同。此外，并不是所有注册商都免费提供 DNS、企业邮箱和域名转发服务。**
55 |
56 | 然后进行结账。结账时建议选择免费的 “隐私保护” 功能，这样你的注册信息（包括邮箱、手机号、地址）就不会公开：
57 |
58 | 
59 |
60 | 然后填写注册信息。请确保注册信息是有效的（可以通过电子邮件联系到你），否则域名注册可能会失败。注册完成后即可选择支付方式了。目前支持的支付方式有微信支付、银行卡、PayPal
61 |
62 | 
63 |
64 | 
65 |
66 |
67 |
68 | 付款完毕后，会自动跳转到支付成功页，点击 “继续管理订单” 进入后台管理页面。
69 |
70 | 
71 |
72 | 此时，你就可以看到你新注册的域名了。
73 |
74 | 
75 |
76 | ## 配置 DNS
77 |
78 | 点击你刚刚注册的域名，然后前往 DNS 管理菜单，点击 “管理DNS” 以激活 DNS：
79 |
80 | 
81 |
82 | 如果你看到 “您即将提交的信息不安全” 提示，请选择 “仍然发送”。随后看到如下页面即说明已经激活了：
83 |
84 | 
85 |
86 | ## 配置企业邮箱
87 |
88 | 此时我们已经拥有了域名，但该域名下还没有任何服务。我们首先配置企业邮箱，实现任何发往 `@guozeyu.online` 的邮件都转发到自己的邮箱里。这样有很多好处，比如你可以在注册微博的时候使用 `weibo@guozeyu.online`，在注册 GitHub 时使用 `github@guozeyu.online`，这样可以区分不同服务商发来的邮件；也可知道是谁卖了自己的邮箱信息，给自己发送垃圾邮件。
89 |
90 | 前往电子邮件菜单，点击 “管理电子邮件” 以激活企业邮箱：
91 |
92 | 
93 |
94 | 如果看到 “待验证域所有权 (Pending Domain Ownership Verification)”，则说明 DNS 尚未完成激活，请在 24-72 小时后尝试。新注册的域名默认使用我们提供的 DNS 服务器，邮件记录已经自动配置好了，所以无需手动添加记录。同时，你也可以点击 “设置 (Settings)”，选择 “修改语言偏好 (Modify Language Preference)” 然后选择 “Chinese (Simplified)” 以切换语言到简体中文。此外，如果你知道自己在做什么，也可以将域名换到其他 DNS 服务商，手动配置 DNS 记录。
95 |
96 | 待 24-72 小时，完成域名所有权验证后，你将看到如下页面，这时我们选择 “添加只转发帐户”：
97 |
98 | 
99 |
100 | 这里我们用户名输入字母 `i`，“转发至” 输入自己的邮箱。这里只是拿我的邮箱演示。
101 |
102 | 
103 |
104 | 添加成功后，发往 `i@guozeyu.online` 的邮件就会转发到你刚刚配置的 “转发至” 邮箱了。但发往其他用户名的邮件依然会被拒收。此时我们需要配置 Catch-All：
105 |
106 | 
107 |
108 | 然后选择 “转发到以下用户/账户”，并输入刚刚设置的用户名 `i`，然后点击 “应用” 即可。
109 |
110 | 
111 |
112 | ## 配置域名转发
113 |
114 | 目前，浏览器里的网站是无法访问的，因为我们还没有配置用于 Web 的服务器，也没有建立自己的网站。但我们可以配置域名转发，将访问到域名的的流量跳转到其他 URL。比如，你可以设置跳转到自己的微博、GitHub 等网站。具体操作如下：
115 |
116 | 前往域名转发菜单，点击 “管理域名转发” 以激活域名转发：
117 |
118 | 
119 |
120 | 此时，你可以配置要转发的域名和要转发到的地址：
121 |
122 | 
123 |
124 | 同时，也可以选择高级设置。我建议关闭 “URL掩蔽 / 重定向 / URL隐藏”。
125 |
126 | 
127 |
128 | 同样，该配置需要 24-72 小时后才能生效。
129 |
130 | ## 总结
131 |
132 | 本文介绍了如何注册属于自己的域名，建立以自己域名结尾的的企业邮箱，以及配置域名转发。后续的文章将会更新如何建立属于自己的个人网站。可以点击页面顶部的关于按钮订阅本网站，这样就不会错过后续的内容啦～
133 |
--------------------------------------------------------------------------------
/_config.yml:
--------------------------------------------------------------------------------
1 | # Hexo Configuration
2 | ## Docs: https://hexo.io/docs/configuration.html
3 | ## Source: https://github.com/hexojs/hexo/
4 |
5 | # Site
6 | title: 郭泽宇的博客 (@ZE3kr)
7 | subtitle: ''
8 | description: '这里发布以科技、编程、摄影为主的原创文章、视频、图片等。'
9 | keywords:
10 | author: James Guo
11 | language: zh-CN
12 | timezone: 'Asia/Shanghai' # use this https://time.is/Shanghai
13 |
14 | # URL
15 | ## Set your site url here. For example, if you use GitHub Page, set url as 'https://username.github.io/project'
16 | url: https://www.guozeyu.com
17 | permalink: :year/:month/:title/
18 | permalink_defaults:
19 | pretty_urls:
20 | trailing_index: true # Set to false to remove trailing 'index.html' from permalinks
21 | trailing_html: true # Set to false to remove trailing '.html' from permalinks
22 |
23 | # Directory
24 | source_dir: source
25 | public_dir: public
26 | tag_dir: tags
27 | archive_dir: archives
28 | category_dir: categories
29 | code_dir: downloads/code
30 | i18n_dir: :lang
31 | skip_render:
32 |
33 | # Writing
34 | new_post_name: :year-:month-:day-:title.md # File name of new posts
35 | default_layout: post
36 | titlecase: false # Transform title into titlecase
37 | external_link:
38 | enable: true # Open external links in new tab
39 | field: site # Apply to the whole site
40 | exclude: ''
41 | filename_case: 0
42 | render_drafts: false
43 | post_asset_folder: false
44 | relative_link: false
45 | future: true
46 | highlight:
47 | enable: false
48 | line_number: true
49 | auto_detect: false
50 | tab_replace: ''
51 | wrap: true
52 | hljs: false
53 | prismjs:
54 | enable: false
55 | preprocess: true
56 | line_number: true
57 | tab_replace: ''
58 |
59 | # Home page setting
60 | # path: Root path for your blogs index page. (default = '')
61 | # per_page: Posts displayed per page. (0 = disable pagination)
62 | # order_by: Posts order. (Order by date descending by default)
63 | index_generator:
64 | path: ''
65 | per_page: 10
66 | order_by: -date
67 |
68 | # Category & Tag
69 | default_category: uncategorized
70 | category_map:
71 | tag_map:
72 |
73 | # Metadata elements
74 | ## https://developer.mozilla.org/en-US/docs/Web/HTML/Element/meta
75 | meta_generator: true
76 |
77 | # Date / Time format
78 | ## Hexo uses Moment.js to parse and display date
79 | ## You can customize the date format as defined in
80 | ## http://momentjs.com/docs/#/displaying/format/
81 | date_format: YYYY-MM-DD
82 | time_format: HH:mm:ss
83 | ## updated_option supports 'mtime', 'date', 'empty'
84 | updated_option: 'mtime'
85 |
86 | # Pagination
87 | ## Set per_page to 0 to disable pagination
88 | per_page: 10
89 | pagination_dir: page
90 |
91 | # Include / Exclude file(s)
92 | ## include:/exclude: options only apply to the 'source/' folder
93 | include:
94 | - _headers
95 | - _redirects
96 | exclude:
97 | ignore:
98 |
99 | # Extensions
100 | ## Plugins: https://hexo.io/plugins/
101 | ## Themes: https://hexo.io/themes/
102 | theme: hexo-theme-claudia
103 |
104 | # Deployment
105 | ## Docs: https://hexo.io/docs/one-command-deployment
106 | deploy:
107 | type: git
108 | repo:
109 | bj1-aws: ze3kr@bj1-aws.s.tlo.xyz:~/sync/GuoZeyu.com.git,main
110 | hk1-ali: ze3kr@hk1-ali.s.tlo.xyz:~/sync/GuoZeyu.com.git,main
111 | us1-gcp: ~/sync/GuoZeyu.com.git,main
112 | de1-ovh: ze3kr@de1-ovh.s.tlo.xyz:~/sync/GuoZeyu.com.git,main
113 |
114 | feed:
115 | enable: true
116 | type: atom
117 | path: feed.atom
118 | limit: false
119 | hub:
120 |
121 | theme_config:
122 | title: 郭泽宇 (@ZE3kr)
123 | short: 博客
124 | short2: ZE3kr
125 | piwik: 3
126 |
127 | # main menu navigation
128 | menu:
129 | 主页: /
130 | About: /about/
131 | 友链: /links/
132 | English: https://www.ze3kr.com/
133 | # Archive: /archives
134 |
135 | license: |-
136 | CC BY-SA 4.0
137 |
138 | highlight: true
139 |
140 | widgets:
141 | - tag
142 | - category
143 | - profile
144 | - adsense
145 |
146 | ads:
147 | - title: 域名注册
148 | link: https://www.yangxi.tech
149 | content: |-
150 | 
151 |
152 | # adsense: ca-pub-5523331422060800
153 |
154 | adb: |-
155 | 哦不！😭你似乎拦截了本站的广告
156 | 本站依赖广告进行创收，请考虑关闭广告拦截插件，以帮助本站持续发展。关闭后此内容将会自动消失。了解更多
157 |
158 |
159 |
160 | 
161 |
162 |
163 | iframe: https://www.ze3kr.com/widget/
164 |
165 | # links_title: 支持本站
166 | # links:
167 | # - title: 关闭广告屏蔽/内容过滤
168 | # url: /ads/
169 | # domain: 谢谢
170 | # tloC: true
171 | # - title: 域名注册
172 | # url: https://www.yangxi.tech
173 | # domain: 免费企业邮箱
174 | # tloB: true
175 | # - title: 香港 CN2 虚拟主机
176 | # url: https://www.yangxi.tech/web-hosting/index.php
177 | # domain: ¥9.6/月
178 | # - title: 2核2GB SSD VPS
179 | # url: https://www.yangxi.tech/virtualserverlinux-hosting.php
180 | # domain: ¥34.8/月
181 |
182 | # social config
183 | social:
184 | # twitter: ZE3kr
185 | # instagram: ZE3kr
186 | # mastodon: https://mastodon.tlo.xyz/@ZE3kr
187 | # matrix: https://matrix.to/#/@james:matrix.tlo.xyz
188 | bluesky: https://bsky.app/profile/ze3kr.com
189 | telegram: ZE3kr
190 | github: ZE3kr
191 | email: i@ze3kr.com
192 |
193 | user:
194 | name: 郭泽宇
195 | avatar: https://cdn.tloxygen.com/images/95dfd986-381d-47fa-4942-c57cf3f27900/medium
196 | location: 美国 西雅图
197 | description: 🎯 专注中
198 | footnotes: |-
199 | 京ICP备17005542号-3
200 |
201 | # documents: https://github.com/utterance/utterances
202 | # API config: https://utteranc.es/
203 | comment_utteranc:
204 | enable: true
205 | repo: ZE3kr/guozeyu.com
206 |
207 | # documents: https://valine.js.org/quickstart.html
208 | comment_valine:
209 | enable: false
210 | appId:
211 | appKey:
212 |
213 | comment_disqus:
214 | enable: false
215 | url: # the url of your website main domain like this https://xxx.xxx/
216 | name: # the short name in disqus
217 |
218 | # dark
219 | # light
220 | # user-can-set
221 | appearance: auto # Default value is auto
222 |
223 | # Miscellaneous
224 | favicon: https://cdn.tloxygen.com/images/95dfd986-381d-47fa-4942-c57cf3f27900/thumbnail
225 | favicon_svg: /favicon.svg
226 |
227 | # picture of about page
228 | about_pic: https://cdn.tloxygen.com/images/95dfd986-381d-47fa-4942-c57cf3f27900/extra
229 |
--------------------------------------------------------------------------------
/source/_posts/2016-10-01-asia-google-compute-engine.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Google Compute Engine 新手教程及使用体验
3 | tags:
4 | - Google Cloud Platform
5 | - VPS
6 | - 网络
7 | id: '1933'
8 | categories:
9 | - - 开发
10 | date: 2016-10-01 11:00:48
11 | cover: 
12 | ---
13 |
14 | 2017 年 4 月更新：由于 GCE 在国内经常不稳定，本站主机已经换到了 [TlOxygen 的虚拟主机](https://domain.tloxygen.com/web-hosting/index.php)上了。 最近想要寻找按流量计费、连接中国速度比较快的 VPS，最终选择了 Google Compute Engine（下文简称 GCE）的亚洲区。GCE 的后台配置页面虽不能在中国访问，但是其 GCE 实例是可以在中国访问的。 创建一个新的 GCE 的流程十分简单，只需要自定义配置、选择操作系统、配置 SSH Key，然后选择创建就好了，整个流程十分像 VPS，但是可自定义的功能却远比 VPS 多。
15 |
16 |
17 | ## 价格与配置
18 |
19 | [具体价格请参见官方价格表](https://cloud.google.com/compute/pricing)。（由于有持续使用折扣，每月实际价格比按照每小时更低） GCE 的价格比较亲民，最低配 (f1-micro) 1 共享核-0.6 GB 内存-10GB HDD 每月只需要不到 5 美元，而且由于 CPU、内存大小和磁盘大小都是可调的，所以可以根据自己的需要去购买最适合的，能省去不必要的开销。 而且对于北美的部分机房而言，账户首个最低配 (f1-micro) 实例可以享受到[永久免费配额](https://cloud.google.com/free/?hl=zh-cn)，对于建站而言 (再配合 Cloudflare 使用) 还是很划算的。流量的话对于所有的可用区，**连中国大陆 $0.23/Gbyte**、美欧地区 $0.12/Gbyte，流量的价格有些小贵，但是如果是连接 Google 自己的服务的话（包括但不限于 Gmail、YouTube），流量不计费（但是流量是双向的，所以是本地通过 GCE 上传完全免费，下载还是原价）。 GCE 还有一点比较特殊的是它是按分钟计费的，当服务处于终止状态（相当于关机，磁盘数据保留）时，不收取费用（除了少量的磁盘使用费用）。每次计算 Uptime 时，如果不到 10 分钟则一律按十分钟算，超过 10 分钟后才是真正的按分钟计费，不过还是很划算了。
20 |
21 | ### 关于共享核的实例的补充
22 |
23 | f1-micro（0.6 GB）和 g1-small（1.7GB）这两个版本使用的是共享核心（其余配置都是独立核心），根据 Google 的说明，0.60GB 是 0.2 vCPU，1.70GB 是 0.5 vCPU。但是却支持 Bursting，也就是短时间内最高能使用到 1.0 vCPU。 那么 1.0 vCPU 是多少呢？查 cpuinfo，是 Intel(R) Xeon(R) CPU @ 2.50GHz。也就是说这两个版本最高能占用到 2.5GHz。但是假如长时间占用，速度就会压缩到 0.5GHz 和 1.75 GHz。
24 |
25 | 
26 |
27 | 我的 f1-micro 装了监控软件，对比 GCE 给的 CPU 占用率（深蓝色）和系统自己监控到的占用率（浅蓝色），发现 GCE 图表上统计的 CPU 占用率正好是本地统计的 5 倍，也就是说如果本地看到的 CPU 占用是 20%，GCE 图表上显示的就正好是 100%，本地为 20~100%，GCE 图表上就是 100~500%，这时就算作 Bursting 了。 和其他 VPS 对比，其他的 VPS 也几乎都是共享核心，但你却无从判断是否超售。比如有 10 个用户共用一个核心，如果那 10 个人都在不停的占用 CPU，那么你的 CPU 速度会低于单核的十分之一。而 Google 的共享核心，保证了一个最低的速度（0.2 vCPU 和 0.5 vCPU），就算其他用户用的再狠，也能给你保证一定的速度。
28 |
29 | ## 使用流程以及配置方法
30 |
31 | 首先需要前往[创建实例](https://console.cloud.google.com/compute/instancesAdd)的页面，然后进行配置
32 |
33 | ### 基础配置
34 |
35 |
36 |
37 | ### 其他一些选项配置介绍
38 |
39 | * **“抢占”**：该模式能够获得更低廉的价格，但是不能用做需要长期保持在线的服务（比如 Web 服务），它最长的使用期限是 24 小时，然而在我的使用中，它有时候不到 1 小时就会被终止使用。它只适合短时间去计算一些东西，计算完后中止它，平常的一般使用不要开启此功能。
40 | * **自动重启**：推荐开启，以获得在云端的好处，以及更好的 Uptime
41 | * **主机维护期间**：推荐选择 “迁移”，原因同上
42 | * **IP 转发**：建议关闭，几乎不会用得着此功能，关闭有助于提高安全性
43 | * **SSH**：这可能不同于其他一些 VPS，它默认不自动生成用户密码，所以为了远程登录必须配置好公钥私钥。而且所填写的公钥末尾的用户名是有作用的，所填写的用户名就是所需要登录的用户名，默认不支持 root 登陆，除非你将用户名设置成了 root。
44 |
45 | 
46 |
47 | ### 防火墙配置
48 |
49 | GCE 默认开启了防火墙且不能关闭，只能允许你自己指定的协议和端口的流量；经过我自己的实际测试，GCE 能够自动过滤相当的 DDOS 攻击流量。 由于防火墙不能关闭，所以不能配置类似 IPv6 Tunnel 的服务，所以导致目前的 GCE 是不能够支持 IPv6 的，不过相信以后 Google 还是会启用 IPv6 支持。 在 “网络” 里，可以找到[防火墙规则](https://console.cloud.google.com/networking/firewalls/list)，然后可以[添加防火墙规则](https://console.cloud.google.com/networking/firewalls/add)。 默认已经允许了 SSH 和 ICMP 等（以 default 开头的）
50 |
51 | 
52 |
53 | 
54 |
55 | 我只需要另一个主机去访问 SNMP 监控，不需要将其公开到互联网上，所以限制了 IP。
56 |
57 | 
58 |
59 | 有的 DNS 请求是通过 TCP 发送的，所以需要同样启用 TCP 请求。 如果配置了目标标记，那么就不是默认应用到所有实例的防火墙规则，还需要在实例上配置好同样的标记才可以。
60 |
61 | 
62 |
63 | ## 网络——如同 Google 自身一样棒
64 |
65 | 由于 GCE 是 Google 的，其网络其实也是 Google 的 AS15169，于是不用想也知道连接 Google 旗下的服务会很快，但是实际使用后发现远比我想象的快，GCE 连接 Google 的服务简直就像内网一样。
66 |
67 | ```
68 | $ ping google.com
69 | PING google.com (74.125.203.102) 56(84) bytes of data.
70 | 64 bytes from th-in-f102.1e100.net (74.125.203.102): icmp_seq=1 ttl=53 time=0.631 ms
71 | 64 bytes from th-in-f102.1e100.net (74.125.203.102): icmp_seq=2 ttl=53 time=0.433 ms
72 | 64 bytes from th-in-f102.1e100.net (74.125.203.102): icmp_seq=3 ttl=53 time=0.330 ms
73 | 64 bytes from th-in-f102.1e100.net (74.125.203.102): icmp_seq=4 ttl=53 time=0.378 ms
74 | 64 bytes from th-in-f102.1e100.net (74.125.203.102): icmp_seq=5 ttl=53 time=0.413 ms
75 | ^C
76 | --- google.com ping statistics ---
77 | 5 packets transmitted, 5 received, 0% packet loss, time 3999ms
78 | rtt min/avg/max/mdev = 0.330/0.437/0.631/0.103 ms
79 | ```
80 |
81 | 要是 traceroute 的话就更神奇了：
82 |
83 | ```
84 | $ traceroute google.com
85 | traceroute to google.com (64.233.189.113), 64 hops max
86 | 1 64.233.189.113 0.826ms 0.313ms 0.435ms
87 | ```
88 |
89 | 中国目前连接 GCE 亚洲区的速度还算不错，按流量计费，实际测试能够超过 100M 带宽。亚洲区的位置在台湾，中国连接通常会绕香港，然后从香港到台湾这条路线走的是 Google 自己的骨干网，所以最终的结果只是比香港服务器慢了十几毫秒而已。
90 |
91 | 其他国家连接的话优势就更明显了，Google 的网络实在太强大，无论是亚洲还是欧美，几乎还没有出这个城市/国家就立即跳进 Google 的骨干网络里了，然后 Google 自身的骨干网的选路通常要比运营商的选路要好一些，几乎不会出现绕路的情况。
92 |
93 | ### 配置 Anycast
94 |
95 | **详细内容已在[下一篇文章](https://www.guozeyu.com/2016/10/build-a-anycast-network-gce/)中介绍**，通过 Load Balancing 可以分配到一个**独立的** IPv4 地址，还能够有原生的 IPv6，支持 CDN 和 HTTPS。Google 的 Anycast 有多快？和 Google 一样快。
96 |
97 | ### 内部网络互通
98 |
99 | 每个实例都有其对应的内网 IP，方便两个主机间建立直接的连接，这个内网 IP 的神奇之处在于：它可以跨可用区使用，包括跨大洲。经过实际测试，使用内网 IP 建立的连接速度会稍快，而且收取的价格（如果是跨州的话）也有优惠。
100 |
101 | ## 功能
102 |
103 | ### 统计功能
104 |
105 | 在 GCE 的后台，能够显示长达 30 天的 CPU 利用率、磁盘字节数、磁盘操作字节数、网络字节数、网络数据包量等数据，都能够精确到分钟级别的记录，而且是实时更新的。
106 |
107 | ### 快照
108 |
109 | 你可以为主机增加快照，方便在其他实例中恢复快照，或者用做备份功能。GCE 的快照是增量备份，这意味着如果有两个快照，第二份快照只备份与第一份快照的差异部分。[使用这个脚本](https://github.com/jacksegal/google-compute-snapshot)可以实现自动备份，并且能够实现到期自动删除老备份。
110 |
111 | ### 附加硬盘
112 |
113 | 你可以轻松的添加任意（大于 10 GB）大小的硬盘，有多种磁盘种类可供选择。经过我的测试，如果执行长时间的高 I/O 操作，硬盘读写速度会明显地降低。而且并不一定 SSD 就比 HDD 快，硬盘的大小与吞吐量限制和随机 IOPS 限制呈正相关，也就是说 40G 的 HDD 的速度相当于 10G 的 SSD。
114 |
115 | ## 适用场景
116 |
117 | 低配置的版本用来建站或者是当 “梯子” 都很不错，每月 5 美元的价格还是很吸引人的（做 “梯子” 的一定要注意流量价格！）。已经相当完善的 Web 控制页面可以大大降低使用和学习的门槛。高配置的版本拥有独立 CPU，而且可伸缩性很大。与 Google Cloud 各种功能配合使用，可以搭建大型网站或者[游戏服务器](https://cloud.google.com/solutions/gaming/)。
118 |
119 | ## GCE 的一些坑
120 |
121 | 下面来讲一讲它的一些坑，尤其是从传统 VPS 转到 GCE 会遇到的一些问题。由于 GCE 是基于云端的，所以有很多东西都不太一样。
122 |
123 | ### 主机的外网 IP 并不是直接分配的
124 |
125 | GCE 虽然是提供独立 IP 的，但是当你执行 `ifconfig -a` 时，你会看到默认分配的 IP 是一个内网的保留 IP（形如 10.123.0.1），这是为了方便 instance 里之间互相连接的 IP。当你配置一些需要外网的服务要 bind 到指定 IP 时，你只需要 bind 到这个 IP 即可，所分配给你的外网 IP 会自动将流量转发到这个 IP 上。而且，你的主机并不知道那个外网 IP 就是主机本身，所以所有发向主机对应的外网 IP 的流量都会经过一个路由器，然后再由路由器返回，并且会应用防火墙策略。所以，如果需要本地的通讯，建议尽量多使用环回地址（如 127.0.0.1，::1）或那个内网地址。
126 |
127 | ### 防火墙
128 |
129 | 不能关闭的防火墙对于初次接触的人来说可能有些不适，不过一旦习惯后便会爱上这个功能，这个基于在路由器上的防火墙功能要比在 iptables 里做限制更方便。强烈建议利用好防火墙功能，不要默认允许所有端口。比如你的网站流量全部经过 Cloudflare，那么就可以通过防火墙来只允许 Cloudflare 的 IP 与你的主机连接。
130 |
131 | ### 不支持多 IP 与 IPv6
132 |
133 | GCE 上不能通过加钱的方式去购买多个 IPv4 地址，所以一个实例只能有一个 IPv4 地址，需要多个 IPv4 需求的可以尝试多个实例（或者可以通过 Load Balancing 来实现多个 IP 地址）。 同时，GCE 目前不支持 IPv6，这实在是很可惜的。目前已经可以[通过负载均衡器来实现 IPv6](https://www.guozeyu.com/2016/10/build-a-anycast-network-gce/)。
134 |
--------------------------------------------------------------------------------
/source/_posts/2015-12-13-https-everywhere-is-coming.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: 全面 HTTPS 时代即将到来
3 | tags:
4 | - 安全
5 | id: '4020'
6 | categories:
7 | - - 开发
8 | date: 2015-12-13 09:19:00
9 | languages:
10 | en-US: https://www.ze3kr.com/2015/12/https-everywhere-is-coming/
11 | ---
12 |
13 | HTTPS 是一种网络安全传输协议，网址以 `https://` 开头，就代表是使用了这个协议。 苹果最新发布的移动端操作系统 iOS 9，除了带来了许多新的功能之外，还提升了整个系统安全性，正如[iOS 开发者资源](https://developer.apple.com/library/prerelease/ios/releasenotes/General/WhatsNewIniOS/Articles/iOS9.html)所说
14 |
15 | > If you’re developing a new app, you should use HTTPS exclusively. If you have an existing app, you should use HTTPS as much as you can right now, and create a plan for migrating the rest of your app as soon as possible. In addition, your communication through higher-level APIs needs to be encrypted using TLS version 1.2 with forward secrecy. If you try to make a connection that doesn't follow this requirement, an error is thrown. 如果你正在开发一个新的程序，你仅应该使用 HTTPS。如果你已经有一个程序，你现在就应该尽可能多的使用 HTTPS，并准备好对剩下部分迁移的计划。另外，如果你的程序使用更高层级的 API 进行通信，则需要使用 TLS 1.2 或以上的版本。如果你试图建立一个不遵守这些需求的通信，就会引发错误。
16 |
17 | 没错，从 iOS 9 开始，将逐步禁用非 HTTPS 请求！ 即使现在已有的程序在 iOS 9 中仍可以在非 HTTPS 情况下工作。但是相信在不久的将来，所有程序都会使用 HTTPS，而且 HTTP 将会完全淘汰。 那么为什么要使用 HTTPS？那些情况下要使用HTTPS呢？
18 |
19 | ## 使用 HTTPS 原因
20 |
21 | HTTPS 能够加密数据传输，防止中间人截取或是修改。能够实现加密用户信息和网站内容。 比如使用大众所说的 “不安全的免费 Wi-Fi”，如果用户访问的网页全部是 HTTPS 的，那么这个 Wi-Fi 对用户没有任何影响。也就是说，媒体报道的 “免费 Wi-Fi 不安全” 纯属造谣，没有任何道理。当启用了 HTTPS 和 HSTS 后，免费 Wi-Fi 完全不能截获到用户密码等任何信息，用户可以安心的进行付款等操作。显然央视 315 没有任何专业知识及解释就在骗大家 “免费 Wi-Fi 不安全”，完全就是恐吓观众。之所以微信朋友圈所有照片都能被获取，是因为**微信朋友圈的上传是明文的**，这分明是微信自己的问题，显然并不是所有的软件都存在这样的问题。随着 iOS 9 的发布以及强制 HTTPS 措施，这一类问题将不复存在了。 其次，使用 HTTPS 不仅仅是为了防止信息被盗窃，还可以防止信息被中途修改。比如中国联通和中国移动会修改网站内容，投放自己的广告让用户升级产品，而这些广告并不是网站主准备的，网站主事先也不知道。虽然它们这样做就是没有行业道德底线，但是我们仅需要使用 HTTPS，这些运营商就统统无能为力了。 包括小米路由器的 “404错误页面优化” 也是利用了同样的原理，对非 HTTPS 页面进行篡改，给用户提供自己的广告从而谋取利益。其本身就是**劫持**，**绝没有夸大之言**。除此之外，有的用户还发现就算是正常页面，也有小米通过**劫持**网页**代码注入**而加入的广告信息。但当 HTTPS 普及之后，这一切都会无影无踪。然而在 HTTPS 普及之前，一些不支持 HTTPS 的网站主只能忍受被运营商、路由器的劫持了。
22 |
23 | ## 使用 HTTPS 的地方
24 |
25 | 我认为，**所有的网页以及程序**都有必要**全部且强制的使用 HTTPS**，可以避免上述情况的发生。包括个人网站在内，也应该全面启用 HTTPS，防止因为被篡改植入的广告而流失读者。 使用 HTTPS 并不会增加太多的成本，还可以让页面速度变得更快。SPDY 协议可以最小化网络延迟，提升网络速度，优化用户的网络使用体验，然而 SPDY 协议只支持 HTTPS。 随着现在的趋势，越来越多的站长会主动或被迫的使用 HTTPS，HTTPS 即将成为主流。中国是 HTTPS 普及程度最小的国家，但是随着百度全站 HTTPS 以及 UPYUN 支持自定义域名的 HTTPS，将推动整个行业 HTTPS 的发展。
26 |
27 | ## 使用 HTTPS 的优点
28 |
29 | ### 加密传输
30 |
31 | 如果一个网页没有使用 HTTPS，那么就意味着页面上的内容，你正在搜索的关键词，甚至是用户名和密码都没有加密，“中间人”可以进行读取、篡改这些没有加密的内容。比如说你连接的免费 Wi-Fi、运营商等都可能会对网页内容进行修改。这些中间人会在你未经允许的情况下在网页上添加他们的广告、修改 404 页面样式、读取你微信朋友圈的图片。 但当这个网页启用了 HTTPS 之后，页面的数据就会被加密，正常情况下中间人就不能获取到你的数据，但是如果中间人替换掉了原有的 HTTPS 后，攻击依然是可能的，所以 HTTPS 站点必须包含一个证书用于验证。
32 |
33 | ### 验证
34 |
35 | 由于 HTTPS 站点必须包含一个证书用于验证，那么就可以验证这个服务器是否被域名所有者许可（以防止连接到中间人的服务器）。通常浏览器都会检验这个证书，如果证书错误会警告用户正在访问的网站有问题。假如用户的 DNS 服务被污染，那么就可能伪造身份，到另一个主机（IP 地址），这个甚至比中间人攻击更可怕，能做到更多的事。当用户使用 HTTPS 访问时，浏览器会验证这个网站的证书，如果证书报错则会警告，甚至无法访问。 但是假如用户访问的时候使用的是 HTTP，那么就不会对服务器进行验证。只有网站进行强制 HTTPS （也就是禁用 HTTP 链接）并启用了 HSTS，那么才能够进行全面的认证。一旦启用 HSTS，那么这个域名的所有页面在设定的有效期内就只能通过 HTTPS 访问。
36 |
37 | ### 加密提示
38 |
39 | 对于站点下所有资源都使用 HTTPS 协议的页面，很多浏览器都会有加密提示，以告知用户这个站点是加密的，让整个网站更高大上。不过我想在此提醒用户，并不是所有使用 HTTPS 的页面就是安全的，任何网站都能轻易申请到 SSL 证书，所以仍然需要辨别域名本身。但是对于直接显示其公司名称的 HTTPS 站点就更值得被信任，因为这种证书是需要纸质证明材料的验证的。下方为使用 Mac 版 Chrome 访问一些 HTTPS 站点的加密提示，Chrome 的加密提示菜单中分为两部分，前一部分验证，后一部分是加密，通常可以分为以下 4 种：
40 |
41 | 
42 |
43 | 
44 |
45 | 其中第一种和第二种情况代表使用了足够安全的加密方式（但是第二种没有提供任何 Certificate Transparency 信息），只是证书的签名等级不同，与加密方式以及验证的安全性无关，这两种情况下都能保证证书不是伪造的。
46 |
47 | 
48 |
49 | 第三种情况是包含不安全资源，网站的外观可能会被改变，但 HTML 文本本身是可靠的。
50 |
51 | 
52 |
53 | 第四种情况是使用了 SHA-1 签名的证书，由于 SHA-1 不是足够的安全，也就是说验证的安全性不够，由于这种证书伪造的成本越来越低，所以可能不安全。这种站点的加密仍然是足够的。
54 |
55 | 
56 |
57 | 第五种情况代表当前可能正在被中间人攻击（因为没有提供任何 Certificate Transparency 信息，而且还使用了 SHA-1）。
58 |
59 | 
60 |
61 | 第六种情况表示这个网站使用不被信任的根证书签发的证书（或者证书中不包含当前域名）。 [关于 Chrome 的加密提示](https://support.google.com/chrome/answer/95617) 无论如何，我都不推荐你使用 SHA-1 签名的证书，值得注意的是最新版 Safari 也可以选择不信任 SHA-1 签名的证书了，SHA-1 即将淘汰。
62 |
63 | ### 搜索引擎
64 |
65 | Google 对 HTTPS 站点的抓取很友好，官方说使用 HTTPS 还会提高排名。Google 也支持使用 SNI 协议的 HTTPS 站点。 百度近期支持了对 HTTPS 站点的抓取，并会相应提高排名，经测试并不是所有证书都支持，但是也支持 SNI 协议。
66 |
67 | ## 使用 HTTPS 的缺点
68 |
69 | ### 更慢的加载速度
70 |
71 | 不得不说使用 HTTPS 的确会增大延迟，这种延迟主要体现在加载首个页面，进入下一个页面就会快很多了。在我这里测试启用 HTTPS 后会多出 2~5 倍的延迟。如果还有资源在别的域，那么这些资源也会多出这么多的延迟。
72 |
73 | ### 兼容性问题
74 |
75 | SNI 协议已经被大量的使用，但是仍然有一些设备是不兼容的，比如 Windows XP 的 IE8 及以前的浏览器都不兼容。截止到目前，[中国支持 SNI 的浏览器使用率已经达到了 95%](http://caniuse.com/#feat=sni)。
76 |
77 | ### 搜索引擎
78 |
79 | 有些搜索引擎对 HTTPS 很好，但是也有一些搜索引擎不支持它。不过目前越来越多的搜索引擎都在逐步支持 HTTPS，我觉得不必担心。
80 |
81 | ### 成本
82 |
83 | 使用 HTTPS 必须需要得到一个证书。现在已经有越来越多的免费 SSL 证书了，总体来说实现 HTTPS 的成本越来越低了。但是随着证书颁发的成本越来越低，HTTPS 作为验证的功能将会变的更小，但是作为加密的功能还是存在的。
84 |
85 | ## 其它
86 |
87 | HTTPS 只能在一定程度上防止篡改，但是并不能抵制一些强大的[网络封锁](https://zh.wikipedia.org/wiki/%E9%98%B2%E7%81%AB%E9%95%BF%E5%9F%8E)。 目前一些“流氓”浏览器竟然不验证证书，大大减弱安全性。如果不验证证书，虽然还有加密的效果，但是如果 DNS 被污染，中间人攻击依然可行。 如果 DNS 被污染，但仍需要使用 HTTPS，那么就将无法访问站点。所以 DNS 也是十分需要加密的。如果能早日支持 DNSSEC 或者是 “HTTPS DNS”（即使用 HTTPS 协议解析 DNS），那么 HTTPS 作为验证则显得不那么重要，完全没有中间人攻击的日子指日可待（但是没有网络封锁还是不可能的）。 或许以后的浏览器只能访问 HTTPS 站点，就像 iOS 9 大力推动 HTTPS 一样，这样就能大大提高安全性，抵制中间人攻击。
88 |
89 | ### 使用 .htaccess 强制 HTTPS
90 |
91 | 下方为在 Apache 里的 `.htaccess` 中配置
92 |
93 | ```
94 | RewriteEngine on
95 | RewriteCond %{HTTP:X-Forwarded-Proto} =http
96 | RewriteRule ^ https://%{HTTP\_HOST}%{REQUEST\_URI} \[L,R=301\] # 禁用 HTTP 协议
97 | ```
98 |
99 | ### HSTS 以及 HSTS Preload List
100 |
101 | HSTS（HTTP Strict Transport Security, HTTP 严格传输安全）是一种让浏览器强制 HTTPS 的方法，当用户访问 HTTPS 站点时，由服务器返回一个 Header，告知浏览器在这个域名下必须强制 HTTPS，在有效期内，浏览器访问此域名将只使用 HTTPS，下方为在 Apache 里的 `.htaccess` 中配置。
102 |
103 | ```
104 | Header set Strict-Transport-Security "max-age=315360000; preload; includeSubDomains" env=HTTPS
105 | ```
106 |
107 | 比如首次访问 `http://tlo.xyz` 时，浏览器会被 301 跳转到 `https://tlo.xyz` 下，然后就会收到这个 Header，在 10 年内，tlo.xyz 下所有的域名都只会使用 HTTPS，包括二级域名 `ze3kr.tlo.xyz`。 但这一切还没有结束，假如浏览器第一次访问时，网站就已经被 HTTPS 劫持攻击了，那么这样做是毫无意义的，所以需要在启动 HSTS 后，包含 `preload` 参数，然后去[提交](https://hstspreload.appspot.com)，注意好要求。 当你提交了之后，一段时间后就能在各大浏览器的源码里看到你的域名了。
108 |
109 | * [Chromium 源码](https://code.google.com/p/chromium/codesearch#chromium/src/net/http/transport_security_state_static.json)
110 | * [FireFox 源码](https://mxr.mozilla.org/mozilla-aurora/source/security/manager/ssl/nsSTSPreloadList.inc)
111 |
112 | ### 检查你的 SSL 配置
113 |
114 | 前往 [SSL Server Test](https://www.ssllabs.com/ssltest/index.html)，就能给你的服务器的 SSL 配置给出一个评分。 哎，这差距
115 |
116 | 
117 |
118 | 
119 |
120 | ## 小提示
121 |
122 | * 一旦设置了强制 HTTPS 协议或者启用了 HSTS 后很难再退回 HTTP 协议（尤其是后者），如果突然关闭了 HTTPS 协议，用户可能在很长一段时间内无法访问网站，或者证书报错，大量流失用户。所以决定强制 HTTPS 前请仔细做好考虑。
123 |
--------------------------------------------------------------------------------
/source/_posts/2021-11-26-mac-mini.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Mac mini 有什么用？组建家庭服务器！
3 | tags:
4 | - Apple
5 | - Mac
6 | categories:
7 | - 科技
8 | date: 2021-11-27 22:00:00
9 | cover: 
10 | ---
11 |
12 | 最近我从闲鱼上购入了一个二手 Mac mini，2020 年 M1 版。我选择的是配有 8GB 内存和 256GB 存储空间的最低配置，当时大约花了 CN¥3,600 左右。目前已经使用有一个月左右，用它组建了旁路由、远程时间机器（Time Machine）备份、SMB 文件共享、远程桌面连接、内网穿透等功能，可以说是物超所值了。
13 |
14 |
15 |
16 | ## 谈谈 2020 M1 Mac mini 的配置
17 |
18 | Mac mini 是苹果的小主机，类似 Intel® NUC 这种迷你 PC。它不配备键盘、鼠标、显示器，因此相比 iMac 也更加实惠。
19 |
20 | 这一代 Mac mini 是首款搭载 Apple Silicon 的 Mac mini，基于 ARM 架构的它拥有更优秀的能耗比以及更好的性能。它的 Geekbench 4 跑分为 7422，高于基于 Intel 芯片的最高配 Mac mini 的 5488 分。不过，受 M1 芯片限制，它只有两个雷电 3 接口，而不是 4 个，而且它只支持连接最多两个显示器。不过，相比搭载 M1 芯片的 MacBook Air 和 MacBook Pro，它的接口要更丰富——它额外有一个 HDMI 2.0、千兆网口（可升级到 10Gb 网口）和两个 USB-A 接口。
21 |
22 | 个人认为 Mac mini 的定位大于等于 MacBook Air，小于等于 iMac、MacBook Pro 系列。所以在未来，苹果也有可能推出搭载 M1 Pro/M1 Max 芯片的 Mac mini。
23 |
24 | ## 作为服务器需要修改的一些设置
25 |
26 | ### 自动登录
27 |
28 | 自动登录是非常重要的一个功能。启用自动登录可以实现在更新 macOS、重启电脑后，不需要输入密码即可自动登录到用户界面，并启动相关的服务。可以说是将 Mac mini 作为服务器，尤其是远程服务器所必须要打开的一个功能。具体的操作方式请参考[这个文档](https://support.apple.com/zh-cn/HT201476)。需要[停用文件保险箱](https://support.apple.com/zh-cn/HT204837)才可以启用这个功能。
29 |
30 | ### 配置防火墙和路由器
31 |
32 | macOS 的共享功能会监听所有的网络接口。如果你的运营商提供了公网 IPv4，则可以通过端口转发或者 DMZ 主机的方式将 SMB 暴露在公网即可。如果需要 IPv6 访问，则需要关闭光猫以及路由器上的防火墙，允许外部传入的 IPv6 连接。
33 |
34 | ### 远程登录和远程管理
35 |
36 | 开启远程登录和远程管理不仅可以方便的远程管理 Mac mini，还可以直接使用 macOS 环境去执行应用程序。开启远程登录后可以使用 SSH 连接。开启远程管理后可以进行远程屏幕连接。
37 |
38 | 
39 |
40 | 在 macOS/iOS 上，我使用 Screens 去远程连接 Mac mini。如果你在 iPad 上使用，我推荐安装 SwitchResX 来自定义屏幕分辨率，实现完美适配 iPad 的效果。需要注意的是，iPad 底部可能会留有部分安全距离，这在设置分辨率时需要减去。在我的 11-inch iPad Pro 上，底部有 40 像素的安全距离。除了分辨率之外，我还将刷新率降低到了 30Hz，以减少网络传输上的压力。
41 |
42 | 
43 |
44 | 需要注意的是，开启远程登录和远程管理前，一定要为你的 Mac 设置强密码，否则极有可能密码被暴力破解。
45 |
46 | 通过远程连接，甚至可以在 iPad 上使用 Final Cut Pro。经过本人实际体验，在同城市通过互联网连接操控时，感觉不到明显卡顿，完全可用。需要注意的是，使用 Final Cut Pro 时屏幕宽度必须大于 1280px（HiDPI 时为 2560 个像素点）。可以使用 SwitchResX 根据应用程序自动切换分辨率。下面这张截图是在 11-inch iPad Pro 上缩放显示的，因此有些许模糊。
47 |
48 | 
49 |
50 | ## Mac mini 作为 NAS 使用
51 |
52 | macOS 的文件共享功能可以直接将 Mac mini 变成一个 NAS。只需要打开系统偏好设置——共享，然后启用 “文件共享”，就可以实现 NAS 了。Mac 使用的是 SMB 协议。建议使用有线网络以确保稳定性。
53 |
54 | 
55 |
56 | 注意，你可能需要进入高级选项，然后启用 “Windows 文件共享”，才能在某些客户端上连接 SMB。
57 |
58 | 
59 |
60 | 如果你想允许访客访问，你不仅需要在用户里添加 “任何人”，还需要在高级选项里打开 “允许客人用户”。此外，还需要在系统偏好设置——用户与群组——客人用户中启用 “允许客人用户连接到共享文件夹”。这时候，可以以用户名 “Guest”，密码空的方式连接 SMB。
61 |
62 | 
63 |
64 | 
65 |
66 | 
67 |
68 | ### 共享外部硬盘
69 |
70 | Mac mini 的雷电 3 和 USB Type-A 接口很适合用于连接外部硬盘，连接的外部硬盘也可以通过文件共享去分享，只需要在添加外部硬盘到 “共享文件夹” 中即可。
71 |
72 | #### 组建 RAID 和 Fusion Drive
73 |
74 | 我为我的外部硬盘配置了 RAID 和 Fusion Drive。我使用了 4 个 3TB 3.5 英寸 HDD 和一个 1TB SSD。其中 4 个 HDD 是通过四盘位硬盘盒的方式使用 USB Type-A 口连接到 Mac mini，SSD 使用雷电 3/USB 4 硬盘盒连接到 Mac mini。我在硬盘盒上做了 RAID5，将 4 个 3TB HDD 变成了 9TB 的存储空间。然后在此之上又使用 Fusion Drive 将其与 SSD 融合，最终达到了 10TB 的容量。Fusion Drive 配置方法我参考的是[这篇文章](https://www.econtechnologies.com/chronosync/tn-cs-apfs-fusion-drive.html)。
75 |
76 | 我选择使用 APFS 作为文件系统。主要是因为新版本 macOS 已经不支持新建 HFS+ 加密分区，而且由于有 SSD 的加持，并不是很担心性能下降。
77 |
78 | ### 作为时间机器（Time Machine）备份目的位置
79 |
80 | 同样是在高级选项中，打开 “共享为时间机器备份目的位置” 即可。在需要进行备份的 Mac 上，使用访达（Finder）菜单栏中的前往——连接服务器（⌘K）连接到这台 Mac，然后就可以在系统偏好设置中的 “时间机器” 里找到通过文件共享的文件夹了。
81 |
82 | 
83 |
84 | 我目前是通过 Internet 的方式连接到 Mac mini 实现异地备份的，首次备份花了大约 6 小时，之后每次备份都能在半小时内完成。我还添加了一个通过 USB 连接的 HDD，系统会使用两个磁盘轮流备份，成功实现了一个异地备份、三个存储介质和三份拷贝，符合[备份 3-2-1 原则](https://www.guozeyu.com/2018/08/backup/#最佳备份原则：321-原则)。
85 |
86 | 
87 |
88 | ### 对 NAS 上的数据进行备份
89 |
90 | 为了更好的安全性，还可以对 NAS 上的数据进行备份。我选择使用 Mac mini 上安装的 Carbon Copy Cloner，将 NAS 上部分重要数据再次备份到本地局域网的 AirPort Time Capsule 上。我选择备份到 APFS 文件系统的 Sparse Bundle 上以实现快照和加密。
91 |
92 | 
93 |
94 | ### 同步照片——Lightroom Classic CC
95 |
96 | 由于有了这个 10TB 的 NAS，我果断将我的 Adobe 订阅从 Lightroom (1TB) 换到了 Photography (20GB)。Photography (20GB) 相比 Lightroom (1TB) 多了 Photoshop CC 和 Lightroom Classic CC。其中 Lightroom Classic CC 使用的是本地的照片库，同时还可以与 Lightroom CC 进行同步。我在 Mac mini 上安装了 Lightroom Classic CC，并打开了同步功能，将之前所有的 Lightroom CC 图片均存储在了本地，然后在 Lightroom Classic CC 上对这些图片取消同步。很快，我的云空间就全部释放了。然后，我再将这些照片重新添加到同步文件夹中。此时，Lightroom Classic CC 只会上传这些照片的智能预览（就是相对低分辨率的 RAW 格式），这些照片不占用云端存储空间。以后，当 Lightroom CC 的空间再次不足时，我依然可以使用这个方法释放 Lightroom CC 的空间。
97 |
98 | 
99 |
100 | 现在，我可以在我的任何安装了 Lightroom CC 的设备上对照片进行编辑。不过，如果需要导出原图，则仍需要在 Mac mini 上的 Lightroom Classic CC 操作。为了能够在其他桌面设备上导出原图，我需要在其他设备上拥有——1. 原图文件、2. 资料库。我选择使用 ChronoSync Express 对原图文件进行双向定时同步，使用 iCloud 云盘同步资料库（包括标准预览、1:1预览、智能预览）。经过我实际测试，发现 iCloud 是支持增量同步的，即每次修改资料库后只会同步资料库文件中改动的文件块。
101 |
102 | 需要注意的是，`Lightroom Catalog*` 文件必须在同一个目录下。如有必要，可以使用软链接的方式实现在不同位置存储它们的原始文件。我一般会将原始文件存储在外置硬盘中，这样可以节省本机空间。当外置硬盘不可用时，依然可以使用智能预览进行编辑。
103 |
104 | ## 旁路由
105 |
106 | 我使用 Surge 这个软件的 DHCP 服务器实现旁路由。Surge 可以接管局域网设备上的请求，对其重写、抓包、解密、代理等，十分方便。需要关闭路由器/光猫上的 DHCP 服务器。
107 |
108 | 
109 |
110 | 打开 Surge 的增强模式，然后在 DHCP 页面中右键选择设备，然后开启 “使用 Surge 作为网关”。将那台设备重新连接到网络，其流量就会被 Surge 接管。
111 |
112 | ## 内网穿透
113 |
114 | 同样是使用 Surge，在其配置文件中加入如下内容：
115 |
116 | ```
117 | [Snell Server]
118 | interface = ::
119 | port = 6160
120 | psk = SOME_RANDOM_PASSWORD
121 | obfs = off
122 | ipv6=true
123 | ```
124 |
125 | 然后，在其他设备上的 Surge 加入如下代理配置：
126 |
127 | ```
128 | [Proxy]
129 | Mac mini = snell, mac-mini.sgddns, 6160, psk=SOME_RANDOM_PASSWORD, udp-relay=true, tfo=true
130 |
131 | [Rule]
132 | IP-CIDR, 192.168.1.0/24, Mac mini
133 | ```
134 |
135 | 需要更改 `SOME_RANDOM_PASSWORD` 为一段随机字符串，更改 `192.168.1.0/24` 为你的内网 IP 段。现在，就可以实现内网穿透了。
136 |
137 |
138 |
139 | ## 下载器——qBittorrent
140 |
141 | 我推荐使用 qBittorrent 作为下载器。其内置的 Web UI 可以方便的在其他设备上控制 qBittorrent.
142 |
143 | 
144 |
145 | 
146 |
147 | ## Mac mini 的替代品
148 |
149 | 有些人可能觉得使用树莓派就行了。实际上，树莓派确实可以实现大多数功能，但是它却没有 macOS 环境，无法安装 Lightroom Classic CC、Final Cut Pro 等软件。
150 |
151 | 当然也可以使用 Intel® NUC 等 Windows 主机来代替 Mac mini，可以实现类似的效果。
152 |
--------------------------------------------------------------------------------
/source/_posts/2016-08-21-install-nginx-1-11-on-ubuntu.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: 使用免费 Let's Encrypt 实现 ECDSA/RSA 双证书
3 | tags:
4 | - 安全
5 | - 网络
6 | id: '1904'
7 | categories:
8 | - - 开发
9 | date: 2016-08-21 10:52:13
10 | languages:
11 | en-US: https://www.ze3kr.com/2016/08/install-nginx-1-11-on-ubuntu/
12 | cover: 
13 | ---
14 |
15 | Ubuntu 16.04.01 自带的软件源中的是 Nginx 1.10.0，但是这个版本的 Nginx 的 HTTP/2 模块中存在 Bug，[具体见此](https://imququ.com/post/nginx-http2-post-bug.html)。现在 Nginx 1.12 Stable 已经推出，直接安装 Stable 版本即可。 2018-06 更新：如果你使用 Ubuntu 18.04 或者是以后的版本，那么系统默认的软件源的 Nginx 版本（1.14）就足够了。
16 |
17 |
18 | 关于双证书，**仅建议使用独立 IP 的人去使用**，如果没有独立 IP，那么就需要启用 SNI 功能——然而几乎所有支持 SNI 功能的浏览器也都支持了 ECC 证书，所以可以跳过升级步骤，直接换 Let's Encrypt 的 ECC 证书，不使用 RSA 证书。 我有不止一个服务器，如果都使用自己编译的 Nginx，那么太麻烦了，于是我决定使用添加软件源的方法，通过 `apt` 升级，方法如下： 首先需要先添加 Nginx mainline 的软件源：
19 |
20 | ```
21 | $ sudo add-apt-repository ppa:nginx/stable # sudo apt install software-properties-common
22 | $ sudo apt update
23 | ```
24 |
25 | 然后移除现有 Nginx 并安装新版本：
26 |
27 | ```
28 | $ sudo apt remove nginx nginx-common nginx-core
29 | $ sudo apt install nginx
30 | ```
31 |
32 | 安装时可能会询问是否替换原来默认的配置文件，选择 N 即可。 此时安装的 Nginx 已经包含了几乎所有的必要和常用模块，比如包括但不限于 GeoIP Module、HTTP Substitutions Filter Module、HTTP Echo Module。我安装的 Nginx 的 OpenSSL 版本是 1.0.2g-fips，所以并不支持 CHACHA20，想要支持 CHACHA20 只能使用 [CloudFlare 的 Patch](https://github.com/cloudflare/sslconfig) 然后自己编译。安装完成后就可以验证 Nginx 版本了：
33 |
34 | ```
35 | $ nginx -V
36 | nginx version: nginx/1.12.0
37 | built with OpenSSL 1.0.2g 1 Mar 2016
38 | TLS SNI support enabled
39 | configure arguments: --with-cc-opt='-g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -fPIC -Wdate-time -D_FORTIFY_SOURCE=2' --with-ld-opt='-Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z,relro -Wl,-z,now -fPIC' --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --modules-path=/usr/lib/nginx/modules --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-pcre-jit --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_v2_module --with-http_dav_module --with-http_slice_module --with-threads --with-http_addition_module --with-http_geoip_module=dynamic --with-http_gunzip_module --with-http_gzip_static_module --with-http_image_filter_module=dynamic --with-http_sub_module --with-http_xslt_module=dynamic --with-stream=dynamic --with-stream_ssl_module --with-stream_ssl_preread_module --with-mail=dynamic --with-mail_ssl_module --add-dynamic-module=/build/nginx-DYnRGx/nginx-1.12.0/debian/modules/nginx-auth-pam --add-dynamic-module=/build/nginx-DYnRGx/nginx-1.12.0/debian/modules/nginx-dav-ext-module --add-dynamic-module=/build/nginx-DYnRGx/nginx-1.12.0/debian/modules/nginx-echo --add-dynamic-module=/build/nginx-DYnRGx/nginx-1.12.0/debian/modules/nginx-upstream-fair --add-dynamic-module=/build/nginx-DYnRGx/nginx-1.12.0/debian/modules/ngx_http_substitutions_filter_module
40 | ```
41 |
42 | 此时，你的服务器就没有 Nginx 的 HTTP/2 bug 了，既然使用了最新版的 Nginx，那么就能够配置 ECDSA/RSA 双证书了。
43 |
44 | ### Nginx 升级的小坑
45 |
46 | 在我升级的时候，遇到了 GeoIP 模块无法使用的问题，经研究发现是新版本将 GeoIP 改成动态调用模块的方式实现了，在 Nginx 的 `http {}` 配置中添加下方代码得以解决：
47 |
48 | ```
49 | load_module "modules/ngx_http_geoip_module.so";
50 | ```
51 |
52 | ## 使用 Let's Encrypt 签发免费多域名证书
53 |
54 | Let's Encrypt 提供完全面为免费，并且是自动化签发的证书，一张证书最多能签 100 个域名，暂不支持通配。 为了配置双证书，你首先应该签发下来两张证书，以下以 [acme.sh](https://github.com/Neilpang/acme.sh) 为例，首先先建立目录（以下所有案例均使用 `example.com` 作为例子，实际使用需自行替换）：
55 |
56 | ```
57 | $ mkdir -p /etc/letsencrypt
58 | $ mkdir -p /etc/letsencrypt/rsa
59 | $ mkdir -p /etc/letsencrypt/ecdsa
60 | ```
61 |
62 | 然后修改 Nginx 配置文件，确保所有在监听 80 端口的都有 `location ^~ /.well-known/acme-challenge/` 区块，本配置文件是强制跳转 HTTPS 的案例，这是源站的配置：
63 |
64 | ```
65 | server {
66 | listen 80 default_server;
67 | listen [::]:80 default_server;
68 | location ^~ /.well-known/acme-challenge/ {
69 | root /var/www/html;
70 | }
71 | location / {
72 | # Redirect all HTTP requests to HTTPS with a 301 Moved Permanently response.
73 | return 301 https://$host$request_uri;
74 | }
75 | }
76 | ```
77 |
78 | 在签发之前，确保所有要签发的域名都指向了你自己的服务器！ 然后签发 RSA 证书（如果需要多域名证书，只需要多个 `-d` 即可，下同，不过保存的文件目录以及证书显示名称均为第一个域名）：
79 |
80 | $ acme.sh --issue --reloadcmd "nginx -s reload" -w /var/www/html -d example.com --certhome /etc/letsencrypt/rsa
81 |
82 | 然后再签发 ECDSA 证书：
83 |
84 | $ acme.sh --issue --reloadcmd "nginx -s reload" -w /var/www/html -d example.com -k ec-256 --certhome /etc/letsencrypt/ecdsa
85 |
86 | 卸载 `acme.sh` 自带的 cron，自己重新配置：
87 |
88 | $ acme.sh --uninstallcronjob
89 | $ vim /etc/cron.d/renew-letsencrypt
90 |
91 | 输入以下内容，注意替换 `acme.sh` 的路径为你安装的绝对路径：
92 |
93 | ```
94 | 15 02 * * * root /path/to/acme.sh --cron --certhome /etc/letsencrypt/rsa
95 | 20 02 * * * root /path/to/acme.sh --cron --ecc --certhome /etc/letsencrypt/ecdsa
96 | ```
97 |
98 | 然后就完成了，证书会自动续签。
99 |
100 | ### 给证书添加或删除域名
101 |
102 | 因为 Let's Encrypt 使用的不是通配符域名，所以会经常遇到有新的子域的情况，此时就需要给证书添加域名，一张证书最多可以添加 100 个域名。最简单的添加方法如下： 首先，修改证书的配置文件，两个证书的配置文件都要修改：
103 |
104 | ```
105 | $ vim /etc/letsencrypt/rsa/example.com/example.com.conf
106 | $ vim /etc/letsencrypt/ecdsa/example.com\_ecc/example.com.conf
107 | ```
108 |
109 | 找到 `Le_Alt` 一行，将新的域名添加进后面（每个域名用逗号隔开，总共不能超过 100 个）。然后开始重新签发这个证书，需要添加 `-f`。
110 |
111 | ```
112 | $ acme.sh --renew -d example.com --certhome /etc/letsencrypt/rsa -f
113 | $ acme.sh --renew -d example.com --ecc --certhome /etc/letsencrypt/ecdsa -f
114 | ```
115 |
116 | 要注意的一点是，目前 Let's Encrypt 签发的 ECC 证书的中间证书和根证书暂且不是 ECC 证书，这将会在以后支持，详情见 [Upcoming Features](https://letsencrypt.org/upcoming-features/#ecdsa-intermediates)。
117 |
118 | ## 配置 Nginx
119 |
120 | 首先需要生成几个 Key：
121 |
122 | ```
123 | $ openssl rand 48 > /etc/nginx/ticket.key
124 | $ openssl dhparam -out /etc/nginx/dhparam.pem 2048
125 | ```
126 |
127 | 然后添加以下内容进 Nginx，放在 http 或 server 区块下，虽然不支持 CHACHA20，但是添加进去也没影响。
128 |
129 | ```
130 | ##
131 | # SSL Settings
132 | ##
133 | ssl_certificate /etc/letsencrypt/rsa/example.com/fullchain.cer;
134 | ssl_certificate_key /etc/letsencrypt/rsa/tlo.xyz/example.com.key;
135 | ssl_certificate /etc/letsencrypt/ecdsa/example.com_ecc/fullchain.cer;
136 | ssl_certificate_key /etc/letsencrypt/ecdsa/example.com_ecc/example.com.key;
137 | ssl_session_timeout 1d;
138 | ssl_session_cache shared:SSL:50m;
139 | ssl_session_tickets off;
140 | ssl_dhparam dhparam.pem;
141 | ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
142 | ssl_prefer_server_ciphers on;
143 | ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS';
144 | ssl_stapling on;
145 | ssl_stapling_verify on;
146 | ```
147 |
148 | 最后不要忘了 `nginx -s reload`，然后 [前往 SSL Labs](https://www.ssllabs.com/ssltest/index.html) 检查配置，可以看到旧的浏览器使用了 RSA 证书（我的服务器有独立 IP，所以无 SNI 支持的也能访问）：
149 |
150 | 
151 |
152 | 至此，ECDSA/RSA 双证书配置完成，你可以在浏览器里查看到证书类型：
153 |
154 |
155 |
--------------------------------------------------------------------------------
/source/_posts/2020-04-20-magic-keyboard-for-ipad-pro.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Magic Keyboard (妙控键盘) for iPad Pro 使用体验
3 | tags:
4 | - Apple
5 | - iOS
6 | id: '3939'
7 | categories:
8 | - 科技
9 | date: 2020-04-20 15:43:16
10 | languages:
11 | en-US: https://www.ze3kr.com/2020/04/magic-keyboard-for-ipad-pro/
12 | ---
13 |
14 | 刚刚收到了 Magic Keyboard (妙控键盘) for iPad Pro (11-inch)。Apple 在今年年初悄无声息的发布了配备双摄的 iPad Pro 2020 款，性能变化不大，主要是起配 128GB、价格下调。最主要的更新就是适配鼠标和触摸板的 iPadOS 13.4 以及刚刚开卖的 Magic Keyboard for iPad Pro。新的键盘同时支持 2018 和 2020 款 iPad Pro。这一代有着更好的支撑模式，改进了键盘，新增了 Type-C 充电，并增配了类似 Mac 的多点触控板。
15 |
16 |
17 | ## 功能概述
18 |
19 | * 可以无极的调整倾斜角度
20 | * 使用最新的的剪刀式结构键盘
21 | * 支持键盘背光
22 | * 多点触控触摸板（物理按压，非 Haptic Feedback）
23 | * 为 iPad 增加一个 USB-C 充电口（不支持数据传输）
24 |
25 | 需要注意的是，该键盘使用专门的协议与 iPad 通信，**不支持蓝牙**。也就是说，**只能给 iPad Pro 使用**。
26 |
27 | 重量：论重量，该键盘重量远大于 Magic Keyboard for Mac 加上 Magic Trackpad for Mac 的重量。因此便携度还是 Mac 所配的键盘和触摸板更优。11-inch 键盘的重量为 600g 左右。作为参考，11-inch iPad Pro 重量为 471g；11-inch 智能键盘夹（Smart Keyboard Folio）为 300g 左右；Magic Keyboard for Mac 加上 Magic Trackpad for Mac 的重量为 231g + 231g = 462g，何况后者比 iPad 的触摸板还要大很多，并支持 Haptic Feedback。安装上该键盘会使设备增重一倍多，实在有点夸张。主要问题是双面保护的问题，如果能够省去背面的保护，重量应该能轻不少。
28 |
29 |
30 |
31 |
32 | | 类别 |
33 | 型号 |
34 | 重量 |
35 |
36 |
37 |
38 |
39 | | iPad 11-inch |
40 | Magic Keyboard |
41 | 593g |
42 |
43 |
44 | | 机身 |
45 | 471g |
46 |
47 |
48 | | Smart Keyboard Folio |
49 | 297g |
50 |
51 |
52 | | 机身 + Magic Keyboard |
53 | 1.06kg |
54 |
55 |
56 | | iPad 12.9-inch |
57 | Magic Keyboard |
58 | 699g |
59 |
60 |
61 | | 机身 |
62 | 641g |
63 |
64 |
65 | | Smart Keyboard Folio |
66 | 407g |
67 |
68 |
69 | | 机身 + Magic Keyboard |
70 | 1.34kg |
71 |
72 |
73 | | Mac |
74 | Magic Keyboard |
75 | 231g |
76 |
77 |
78 | | Magic Trackpad |
79 | 231g |
80 |
81 |
82 | | MacBook |
83 | 13-inch Air |
84 | 1.29kg |
85 |
86 |
87 | | 13-inch Pro |
88 | 1.37kg |
89 |
90 |
91 | | 16-inch Pro |
92 | 2.0kg |
93 |
94 |
95 |
96 |
97 | \* Magic Keyboard for iPad Pro 和 Smart Keyboard Folio 的重量均**不是**官方数据
98 |
99 | ## 图片
100 |
101 | 
102 |
103 | 
104 |
105 | 
106 |
107 | 
108 |
109 | 
110 |
111 | 
112 |
113 | 
114 |
115 | 
116 |
117 | ## 功能配置
118 |
119 | ### 三指手势配置
120 |
121 | 我的触摸板默认没有开启三指切换多任务的手势。需要进入设置、主屏幕与程序坞、多任务中找到 “手势” 开关开启。开启后在屏幕上四指也会出发多任务。
122 |
123 | 
124 |
125 |
126 |
127 | 三指手势 屏幕录制
128 |
129 |
130 | ### 指针动画和触摸板惯性
131 |
132 | 
133 |
134 | 若开启**指针动画**，当移动到按钮上方时，指针会消失，取而代之的是按钮高亮的吸附效果。此功能可以关闭，关闭后更接近在 macOS 上的使用体验。
135 |
136 |
137 |
138 | 开启指针动画
139 |
140 |
141 |
142 |
143 | 关闭指针动画
144 |
145 |
146 | 同样的，默认 iPadOS 会开启触摸板惯性，关闭此功能会更接近在 macOS 上的使用体验。
147 |
148 |
149 |
150 | 开启触摸板惯性
151 |
152 |
153 |
154 |
155 | 关闭触摸板惯性
156 |
157 |
158 | ### 辅助点按
159 |
160 | 类似 Mac，iPad 也推出了辅助点按功能，可以代替 Haptic Touch，非常好用。
161 |
162 | 两指按下辅助点按
163 |
164 | ## 使用体验
165 |
166 | 根据我的个人体验以及网上的说法，该触摸板明显比第三方的好用，效果与 Magic Trackpad for Mac 相当。似乎苹果目前对第三方触摸板在多点触控以及移动光标的流畅度上有 Bug（也可能是有意而为）。
167 |
168 | 该键盘使用最新的的剪刀式结构，介于最新的 16-inch MacBook Pro 和 Magic Keyboard for Mac 的手感。相比智能键盘夹（Smart Keyboard Folio）打字体验好太多。
169 |
170 | 尽管触摸板不支持 Haptic Feedback，但整个触摸板均可物理按压，不存在某一个角不好用一说。
171 |
172 | 两个角度控制的地方阻尼足够，无论什么角度放置，仅凭借 iPad 自身重量均无法使其自己转动。可放在腿部使用。
173 |
174 | 总体使用体验尚可，唯一缺点就是太重且两个面都很厚（背面由于支持充电和角度调整，也远大于普通双面夹）。此外就是似乎本次外壳材质较上一代没有变化，使用久了会严重变质。
175 |
176 | ## 购买方式
177 |
178 | 可以前往 Apple Store 实体店或者在线商店购买。**使用教育优惠可以便宜 ¥200，学生教师均可使用**。购买时注意选择键盘样式，我购买的是美式英语。国内实体店**可能只有简体拼音版**。
179 |
180 | + [在线商店地址](https://www.apple.com.cn/shop/product/MXQT2CH/A)
181 | + [教育在线商店](https://www.apple.com.cn/cn-k12/shop/product/MXQT2CH/A)
182 |
--------------------------------------------------------------------------------
/source/_posts/2016-10-04-build-a-anycast-network-gce.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: 利用 GCE 建立一个 Anycast 网络，超快的香港节点，Google Cloud CDN
3 | tags:
4 | - Google Cloud Platform
5 | - VPS
6 | - 网络
7 | id: '1998'
8 | categories:
9 | - - 开发
10 | date: 2016-10-04 09:27:00
11 | languages:
12 | en-US: https://www.ze3kr.com/2016/10/cloudflare-2016-new-feature/
13 | cover: 
14 | ---
15 |
16 | [在上一篇文章](https://www.guozeyu.com/2016/10/asia-google-compute-engine/)中，我简单的介绍了 Google Compute Engine（简称 GCE）的基础使用。这篇文章我将介绍如何利用 GCE 建立一个 Anycast 网络，并测试了其速度。 想要实现这个功能，就需要使用 [Cross-Region Load Balancing](https://cloud.google.com/compute/docs/load-balancing/http/cross-region-example)（跨地区的负载均衡），此功能就相当于一个 HTTP(S) 的反向代理，所以只能针对 HTTP/HTTPS 请求进行负载均衡。
17 |
18 |
19 | ## 简要概述
20 |
21 | GCE 上所实现的这个功能是基于第七层的网络代理，所以其拓扑图是这样的： 用户 —> 边缘服务器 —> 实例
22 |
23 | * **用户到边缘服务器之间的连接**：使用 HTTP 或 HTTPS；如果是 HTTPS 连接，那么 TLS 加密过程是在边缘服务器上实现。
24 | * **边缘服务器到实例的连接**：使用 HTTP 或 HTTPS 连接，之前的网络是走的 Google 的专线。
25 |
26 | 不论配置了几个位置的实例，边缘服务器都是使用 Google 全部的边缘服务器。 启用这个功能后，就会得到另一个 Anycast 的 IP 地址，这是个独享的 IP 地址。
27 |
28 | 什么是 Anycast？Anycast 能够让多个主机使用一个 IP 地址，当用户连接这个 IP 地址的时候，连接到的只是这多个主机中的其中之一，通常会选择最快的线路，能有效的降低延迟，所以很多 DNS/CDN 提供商都使用了 Anycast。
29 |
30 | 此外，目前使用负载均衡是唯一能让其原生支持 IPv6 的方法。具体可以参见其文档：[IPv6 Termination for HTTP(S), SSL Proxy, and TCP Proxy Load Balancing](https://cloud.google.com/compute/docs/load-balancing/ipv6)
31 |
32 | 
33 |
34 | ## 配置方法
35 |
36 | ### 建立实例
37 |
38 | 首先，需要前往到 GCE 后台，建立至少两个不同地区的实例，我专门为测试 Anycast 功能建立了两个新的实例：
39 |
40 | 
41 |
42 | 每个地区也可以建立多个实例以提高可用性，而我只给每个地区建立了一个实例，这两个实例分别叫 anycast-asia 和 anycast-us。
43 |
44 | ### 建立实例组
45 |
46 | 然后，需要给每个地区的实例[建立一个实例组](https://console.cloud.google.com/compute/instanceGroups/add)：
47 |
48 | 
49 |
50 | 需要注意的是，实例组配置页面中位置里的 “多地区（Multi-zone）” 是指同一个**地区**（Region）的不同**可用区域**（Zone），而不是多个不同的地区，所以这实际上是翻译的错误，应该叫做 “多可用区域” 才对。
51 |
52 | * * *
53 |
54 | 刚接触云服务的人可能不理解可用区域的概念，可以参考 [AWS 的这篇文章](http://docs.aws.amazon.com/zh_cn/AWSEC2/latest/UserGuide/using-regions-availability-zones.html)来理解。简单点说，地区这个概念就是指离得很远的地区（比如城市之间，如北京和上海），所有在北京的服务器都算北京地区，所有在上海的服务器都算上海地区。但是为了能达到更高的可用性，通常还会在同一个地区设立多个数据中心，也就是可用区域。这些可用区域虽在一个地区中，其之间的距离可能相隔几十甚至几百公里，但这些可用区域之间的距离和不同地区之间的距离相比起来要小得多，所以这些可用区域之间的网络延迟也很低。
55 |
56 | 设立多个可用区域的意义是：可以能加更高的可用性（主要是为了避免外界因素：比如说火灾等），虽然是异地分布，但是可用区域之间的距离并不远，所以网络延迟可以忽略。
57 |
58 | 我只给每个地区建立了一个实例，所以我只需要选择 “单地区（Single-zone）”。每个地区都需要建立一个实例组，所以一共需要建立两个（或更多的）实例组。我配置了两个实例组，分别叫 asia-group 和 us-group。
59 |
60 | ### 建立负载均衡
61 |
62 | 完成前两步之后，就需要建立负载均衡的规则了，需要选择 “HTTP(S) 负载平衡” 来实现 Anycast 的功能。
63 |
64 | 
65 |
66 | 在负载均衡的配置界面，把这两个实例组都添加到 “后端” 中。 该功能还需要创建一个运行状态检查（相当于监控功能），当主机宕机后能实现切换。
67 |
68 | 
69 |
70 | 
71 |
72 | 
73 |
74 | 创建成功后，可以看到如下界面，其中的 IP 地址就是 Anycast IP 了。
75 |
76 | 
77 |
78 | ### Nginx 的配置
79 |
80 | 这里的配置只是为了方便调试，实际使用不用额外修改 Nginx 的配置。 在这两个主机上都安装 Nginx，然后稍微改动默认的配置文件：增加两个 Header，然后 Reload。
81 |
82 | ```
83 | add_header X-Tlo-Hostname $hostname always;
84 | add_header Cache-Control "max-age=36000, public";
85 | ```
86 |
87 | ### 检测是否可用
88 |
89 | 在测试 Anycast 之前，先测试这两个主机是否存在问题。为了方便阅读，我将 curl 的 IP 地址换为主机名，并省略两个主机都相同的 Header 字段
90 |
91 | ```
92 | $ curl anycast-us -I
93 | HTTP/1.1 200 OK
94 | …
95 | ETag: "57ef2cb9-264"
96 | X-Tlo-Hostname: **anycast-us**
97 | $ curl anycast-asia -I
98 | HTTP/1.1 200 OK
99 | …
100 | ETag: "57ef2b3b-264"
101 | X-Tlo-Hostname: anycast-asia
102 | ```
103 |
104 | 可以看到这两个主机都没有什么问题。然后，我用我的电脑去测试那个 Anycast IP：
105 |
106 | ```
107 | $ curl anycast-ip -I
108 | HTTP/1.1 200 OK
109 | …
110 | ETag: "57ef2b3b-264"
111 | X-Tlo-Hostname: anycast-asia
112 | Accept-Ranges: bytes
113 | Via: 1.1 google
114 | ```
115 |
116 | 可以看到，这是 anycast-asia 主机响应的。现在我使用另一个在美国的主机继续测试这个 Anycast IP：
117 |
118 | ```
119 | $ curl anycast-ip -I
120 | HTTP/1.1 200 OK
121 | …
122 | ETag: "57ef2cb9-264"
123 | X-Tlo-Hostname: anycast-us
124 | Accept-Ranges: bytes
125 | Via: 1.1 google
126 | ```
127 |
128 | 此时就是 anycast-us 主机响应的，是因为客户端离这个服务器更近。 当通过 Anycast IP 访问时，就可以看到 HTTP Header 中的 `Via: 1.1 google` 字段。
129 |
130 | ## 速度测试
131 |
132 | ### Ping 测试
133 |
134 | Ping 测试发现速度很快，看来反代的操作是放在 Google 的边缘服务器上了。**速度堪比 Google 啊！**
135 |
136 | 
137 |
138 | 中国的速度那更是一流的快，Google 有香港的边缘节点，所以基本上是直接走的香港节点，比原本的连接台湾可用区快不少。（只有部分 IP 段是完全直连的）
139 |
140 | 
141 |
142 | ### HTTP GET 测试
143 |
144 | 在开启 CDN 功能之前，负载均衡器是不会对任何内容缓存的，所以会发现 Connect 的速度很快，但是 TTFB 延迟还是有不少。
145 |
146 | 
147 |
148 | 可以预测，如果启用了 HTTPS 功能，其 TLS 所需要的等待时间也会很短，TTFB 时间不变，总时长不会延长太多。
149 |
150 | #### 开启 CDN 后进行 HTTP GET 测试
151 |
152 | 当将 CDN 开启后，负载均衡器就会自动地对静态资源做缓存了，当缓存命中后会显示 Age 字段，这个字段是表示自缓存命中了，后面的数字代表这是多少秒之前缓存的内容。
153 |
154 | curl anycast-ip -I
155 | HTTP/1.1 200 OK
156 | …
157 | Via: 1.1 google
158 | Age: 10
159 |
160 | 经过多次执行这个指令，会发现有一定几率 Age 字段消失，这可能是流量指到了同一个地区的不同可用区上。但总之，是缓存命中率不高，即使之前曾访问过了。
161 |
162 | 
163 |
164 | 多次运行测试确保有缓存之后，发现速度似乎并没有太多明显的提升。能够明显的看出改善的是：巴黎和阿姆斯特丹的 TTFB 延迟从 200ms 减少到了 100ms，然而还是不尽人意。可能的原因是：Google 并没有将内容缓存到离访客最近的边缘节点上，而是别的节点上。 [CDN 缓存服务器的位置列表](https://cloud.google.com/cdn/docs/locations)
165 |
166 |
167 |
168 | ## 统计与日志
169 |
170 | 开启了 Load Balancing 后，就会自动在 Google Cloud Platform 下记录一些信息了。
171 |
172 | ### 实时流量查看
173 |
174 | 在网页后台的 Network，Load balancing，advanced menu 的 Backend service 下，可以查看实时的流量情况：
175 |
176 | 
177 |
178 | ### 延迟日志
179 |
180 | 在网页后台的 Stackdriver，Trace 下，可以看到延迟日志：
181 |
182 | 
183 |
184 | 
185 |
186 | 这里的延迟包含了网络延迟和服务器响应延迟
187 |
188 | ## 总结
189 |
190 | GCE 所能实现的 Anycast 功能，只能通过 HTTP 代理（第七层）的方式实现，所以只能代理 HTTP 请求，其他功能（如 DNS）无法实现。所以很多功能受限于负载均衡器的功能（比如证书和 HTTP2 都需要在负载均衡器上配置），然而由于 TLS 加解密过程是在边缘服务器上实现，而且其本身也带有 CDN 功能，所以会比单纯的 Anycast（比如基于 IP 层，或是 TCP/UDP 层）的更快一些。
191 |
192 | ### 价格
193 |
194 | 前五个 Rules **$18/月**，流量费用相比 GCE 不变，已经被缓存的内容的流量有一点优惠。
195 |
196 | ## 对比
197 |
198 | ### Cloudflare
199 |
200 | 通过使用 Cloudflare 所提供的服务也能实现 Anycast，也是基于第七层的，即将也能实现 Cross-Region Load Balancing 的功能。虽然它还不能根据主机的 CPU 占用率去调整权重（毕竟它拿不到这些数据），却有强大的 Page Rules 功能以及 WAF 功能。 CloudFlare 并不提供独立 IP 地址，不过这不是什么大问题。 由于它属于第三方服务，不受服务提供商的限制，于是就可以给多种不同的服务提供商去做 Anycast 功能；而且无论服务商是否支持，都能够使用。 连接速度上，GCE 的在中国连接速度有明显的优势。
201 |
202 | ### BuyVM
203 |
204 | BuyVM 是一家 VPS 提供商，却提供免费的 Anycast 功能，其 Anycast 功能是直接基于 IP 层的 Anycast，所以可以配置 HTTP 之外的各种服务。BuyVM 没有所谓的边缘服务器一说，只能有三个节点，Ping 的结果不像前两家那么快，而且 TLS 过程也是在原本的主机（这三个主机中里用户最近的一个）上进行，也会有一定延迟。 BuyVM 并不提供任何亚洲的主机，所以中国的连接速度也没有比 Cloudflare 快多少，整个亚洲的速度也不是很快。
205 |
--------------------------------------------------------------------------------
/source/_posts/2019-08-30-powerdns-2.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: 自建 PowerDNS 进阶：分区解析，dnsdist，Lua 记录
3 | tags: []
4 | id: '3728'
5 | categories:
6 | - 开发
7 | date: 2019-08-30 19:41:41
8 | ---
9 |
10 | 本文将讲一下使用 PowerDNS 的 GeoIP Backend 建立自己的 DNS 权威服务器（服务于自己的域名，这不是公共 DNS 缓存服务器）。
11 |
12 | 通过使用 PowerDNS，你可以在自己的服务器上搭建支持分区解析（精细到国家、城市、ASN、自定义 IP 段）、EDNS-Client-Subnet、DNSSEC、IPv6 的 DNS 服务器。
13 |
14 | 本文面向域名所有者和站长，讲述的是权威 DNS 服务器而非 DNS 缓存服务器。如果你想要了解更多的关于 DNS 的知识，请参考 [DNS 域名解析系统详解——基础篇](https://www.guozeyu.com/2016/12/domain-name-system/) 以及 [DNSSEC 简介，签名的工作原理](https://www.guozeyu.com/2018/03/dnssec/)。
15 |
16 | 本文是对[自建 PowerDNS 智能解析服务器](https://www.guozeyu.com/2016/08/self-host-dns/)的更新。自建 DNS 的优缺点、配置 DNSSEC 以及分布式 DNS 服务在之前的那篇文章有所描述，本文将其省略。本文主要更新以下内容：
17 |
18 | 1. 本文适用于最新的 **PowerDNS 4.2.0**
19 | 2. 使用 MaxMind GeoIP 2 mmdb 格式的数据库
20 | 3. 讲述如何为根域名设置分区解析
21 | 4. 使用 dnsdist 以实现 IP 访问速率的限制，防御 DOS 攻击。
22 |
23 |
24 | ## 安装 PowerDNS Authoritative Server 和 dnsdist
25 |
26 | 考虑到操作系统软件源默认版本不一，建议**前往** [**PowerDNS repositories**](https://repo.powerdns.com) **重新为 PowerDNS Authoritative Server 配置软件源**（请添加 **4.2 或以上版本**）。同样你也可以配置 dnsdist 的软件源（请添加 1.2 或以上版本）。
27 |
28 | 添加软件源后，更新软件列表并安装 `pdns-server` 和 `pdns-backend-geoip` 即可。在 Debian/Ubuntu 下：
29 |
30 | ```
31 | sudo apt-get install pdns-server pdns-backend-geoip
32 | ```
33 |
34 | 需要注意的是，在 Ubuntu 18.04 LTS 后可能默认包含了 `systemd-resolved` 服务，这个服务占用了 loopback 地址的的 53 端口，这与 PowerDNS 所需要使用的端口（`0.0.0.0:53`）冲突。你可以：1. 禁用这个服务，2. 修改 PowerDNS 的 [local-address](https://doc.powerdns.com/md/authoritative/settings/#local-address) 和 [local-ipv6](https://doc.powerdns.com/md/authoritative/settings/#local-ipv6) 配置仅监听外网 IP 地址，3. 修改 [local-port](https://doc.powerdns.com/md/authoritative/settings/#local-port) 为非 53 端口，并使用 dnsdist 进行转发（详见后文）。
35 |
36 | 如果你想要配置用户侧 IP 访问速率，请安装 dnsdist：
37 |
38 | ```
39 | sudo apt-get install dnsdist
40 | ```
41 |
42 | ### 禁用 systemd-resolved
43 |
44 | 如果你选择禁用 `systemd-resolved`，可以执行以下代码：
45 |
46 | ```
47 | sudo systemctl disable systemd-resolved.service
48 | sudo systemctl stop systemd-resolved
49 | ```
50 |
51 | ### 安装 geoipupdate 并下载 GeoIP2
52 |
53 | 为了实现分区解析，我们需要 GeoIP 数据库。最新版的 PowerDNS GeoIP Backend（4.2.0）已经支持了 GeoIP2 的 mmdb 格式，同时也支持 dat 格式。而老板的只支持 dat 格式的数据库。由于 [MaxMind 已经停止](https://support.maxmind.com/geolite-legacy-discontinuation-notice/)维护免费的 dat 格式数据库，因此**强烈建议使用 4.2 版本及以上的 PowerDNS 并换用 mmdb 格式的 IP 数据库**。
54 |
55 | 首先建立配置文件，创建 `/etc/GeoIP.conf` 为如下内容（包含了 IPv4 和 IPv6 的国家、城市、ASN 数据）：
56 |
57 | ```
58 | ProductIds GeoLite2-Country GeoLite2-City GeoLite2-ASN
59 | DatabaseDirectory /usr/share/GeoIP
60 | ```
61 |
62 | 建议安装 [geoipupdate](https://github.com/maxmind/geoipupdate)，在 Ubuntu 下可以这样安装：
63 |
64 | ```
65 | sudo add-apt-repository ppa:maxmind/ppa
66 | sudo apt update
67 | sudo apt install geoipupdate
68 | ```
69 |
70 | 然后下载/更新 GeoIP2：
71 |
72 | ```
73 | sudo geoipupdate -v
74 | ```
75 |
76 | All done!
77 |
78 | 同时建议配置 Crontab 定期执行上面指令更新数据库文件（并重载 PowerDNS 服务），以更新 GeoIP 数据库。
79 |
80 | ## 配置 PowerDNS
81 |
82 | PowerDNS（下简称 pdns）的配置文件位于 `/etc/powerdns`，首先删除 PowerDNS 原本的 demo 配置，然后建立文件夹以存储 DNSSEC 的密钥文件：
83 |
84 | ```
85 | sudo rm /etc/powerdns/pdns.d/*
86 | sudo mkdir /etc/powerdns/keys
87 | ```
88 |
89 | 然后创建文件，创建 `/etc/powerdns/pdns.d/geoip.conf` 为如下内容：
90 |
91 | ```
92 | launch=geoip
93 | geoip-database-files=/usr/share/GeoIP/GeoLite2-Country.mmdb /usr/share/GeoIP/GeoLite2-City.mmdb /usr/share/GeoIP/GeoLite2-ASN.mmdb
94 | geoip-zones-file=/etc/powerdns/zones.yaml
95 | geoip-dnssec-keydir=/etc/powerdns/key
96 | ```
97 |
98 | 在 `geoip-database` 选项中，你可以按照需要设置自己所需要的一个或多个 GeoIP 数据库。
99 |
100 | ### 配置 DNS 记录
101 |
102 | 你可以建立文件 `/etc/powerdns/zones.yaml` 以配置 DNS 记录。具体格式参见 [Zonefile format](https://doc.powerdns.com/authoritative/backends/geoip.html#zonefile-format)。
103 |
104 | 需要注意的是，若使用 mmdb，则 `%re` 是 ISO3166 的两位区域缩写。若使用 dat，则是 [GeoIP 的区域代码](http://geolite.maxmind.com/download/geoip/misc/region_codes.csv)。
105 |
106 | 由于 PowerDNS GeoIP Backend 仅支持按域名配置分区解析，而不支持按记录配置按记录配置分区解析，所以若要配置根域名分区解析，可以参考如下配置（YAML 格式，下同）：
107 |
108 | ```
109 | domains:
110 | - domain: example.com
111 | ttl: 300
112 | records:
113 | unknown.cn.example.com:
114 | - soa: &soa ns1.example.com hostmaster.example.com 2014090125 7200 3600 1209600 3600
115 | - ns: &ns1
116 | content: ns1.example.com
117 | ttl: 600
118 | - ns: &ns2 ns2.example.com
119 | - mx: &mx 10 mx.example.com
120 | - a: 10.1.1.1
121 | bj.cn.example.com:
122 | - soa: *soa
123 | - ns: *ns1
124 | - ns: *ns2
125 | - mx: *mx
126 | - a: 10.1.2.1
127 | unknown.unknown.example.com:
128 | - soa: *soa
129 | - ns: *ns1
130 | - ns: *ns2
131 | - mx: *mx
132 | - a: 10.1.3.1
133 | ns1.example.com:
134 | - a: 10.0.1.1
135 | - aaaa: ::1
136 | ns2.example.com:
137 | - a: 10.0.2.1
138 | services:
139 | example.com: [ '%ci.%cc.service.geo.example.com', 'unknown.%cc.service.geo.example.com', 'unknown.unknown.service.geo.example.com']
140 | ```
141 |
142 | 可以看到，为了配置跟域名分区域解析，我们需要为每个区域配置所有类型的记录。而根域名通常有很多记录类型，所以配置起来相对繁琐。上述 YAML 写法使用了变量，这样可以减少配置重复的记录。（`&variable` 设置变量，`*variable` 使用变量）
143 |
144 | ## 调试
145 |
146 | 你可以通过配置如下记录进行调试：
147 |
148 | ```
149 | debug.tlo.xyz:
150 | - a: "%ip4"
151 | - aaaa: "%ip6"
152 | - txt: "co: %co; cc: %cc; cn: %cn; af: %af; re: %re; na: %na; as: %as; ci: %ci; ip: %ip"
153 | ```
154 |
155 | 在客户端通过类似下方的指令进行测试（替换 `10.11.12.13` 为服务所监听的 IP 地址），有如下结果：
156 |
157 | ```
158 | $ dig @10.11.12.13 debug.example.com
159 |
160 | debug.example.com. 3600 IN TXT "co: us; cc: us; cn: na; af: v4; re: ca; na: quadranet enterprises llc; as: 8100; ci: los angeles; ip: 10.11.12.13"
161 | debug.example.com. 3600 IN A 10.11.12.13
162 | ```
163 |
164 | 这样你就可以看到每一个变量的具体值了。
165 |
166 | ## Lua 记录
167 |
168 | 在 PowerDNS 4.2 中，新增了 [Lua 记录功能](https://doc.powerdns.com/authoritative/lua-records/index.html)。其 Lua 记录的最主要的功能是可以配置宕机自动切换记录。
169 |
170 | 由于 Lua 记录可以使用 Lua 编程语言执行任意代码，相对危险，所以 PowerDNS 默认关闭了这个功能，需要在配置文件中开启：
171 |
172 | ```
173 | enable-lua-records=yes
174 | ```
175 |
176 | 配置如下记录，将返回动态的可用 A 记录。如果两个 IP 的端口都可用（这里是 443 端口），则随机返回一个 IP 地址，若有一个不可用，则只返回可用 IP 的地址，否则同时返回两个 IP：
177 |
178 | ```
179 | sub.example.com:
180 | - lua: A "ifportup(443, {'192.0.2.1', '192.0.2.2'})"
181 | ```
182 |
183 | 配置如下记录，就可以自动对指定 URL 进行状态检查，默认返回第一组 IP 地址，若第一组 IP 地址不可用，则返回第二组：
184 |
185 | ```
186 | sub.example.com:
187 | - lua: A "ifurlup('https://sub.example.com/', {{'192.0.2.1', '192.0.2.2'}, {'198.51.100.1'}})"
188 | ```
189 |
190 | Lua 记录可以与 GeoIP 功能共同使用，且可以与其他类型的记录共存。另外，状态检查并非与请求同步，而是在后台周期性的检查是否可用，所以使用状态检查不会增加 DNS 请求的延迟。
191 |
192 | ## 配置 dnsdist
193 |
194 | 截止到现在，你的 DNS 服务器应该已经可以工作了。下面将介绍配置 dnsdist。
195 |
196 | dnsdist 相当于在 pdns 之上加了一层代理，可以为其配置访问速率的限制，起到抗 DOS 的作用。正常情况下，安装完成 dnsdist 后，其服务就自动启动了。
197 |
198 | 在这个样例中，将 pdns 的主程序监听改为 `127.0.0.1:8053`。创建或修改文件 `/etc/dnsdist/dnsdist.conf` 为以下内容：
199 |
200 | ```
201 | newServer{address="127.0.0.1:8053",useClientSubnet=true}
202 | setLocal("10.0.1.1")
203 | setACL({'0.0.0.0/0', '::/0'})
204 | setECSSourcePrefixV4(32)
205 | setECSSourcePrefixV6(128)
206 | addAction(MaxQPSIPRule(10, 32, 56), TCAction())
207 | addAction(MaxQPSIPRule(20, 32, 56), DropAction())
208 | addAction(MaxQPSIPRule(40, 24, 48), TCAction())
209 | addAction(MaxQPSIPRule(80, 24, 48), DropAction())
210 | addAction(MaxQPSIPRule(160, 16, 40), TCAction())
211 | addAction(MaxQPSIPRule(320, 16, 40), DropAction())
212 | ```
213 |
214 | `newServer` 语句设置了 dnsdist 所代理的服务器，也就是 pdns 所监听的 IP 地址和端口号。`setLocal` 设置了 dnsdist 的监听 ip 地址。`setACL` 设置了允许的 IP 地址，这里允许了所有的 IPv6 和 IPv4 访问。`setECSSourcePrefixV4` 和 `setECSSourcePrefixV6` 设置了 EDNS Client Subnet Client 功能传输 IP 地址的比特数，这里为 IPv4 设置了 32 位，IPv6 设置了 128 位，也就是保留了 IP 地址的完整长度。实际生产中也可以设置比这个更小的值。
215 |
216 | 后几行 `addAction` 和 `MaxQPSIPRule` 定义了访问速率限制。其中 `MaxQPSIPRule` 拥有三个参数。第一个参数是 qps，即 queries per second，每秒钟请求数。第二个参数是 IPv4 的 CIDR 值，默认为 32，第三个参数是 IPv6 的 CIDR 值，默认为 64。`TCAction` 代表要求客户端使用 TCP 请求，`DropAction` 代表拒绝请求。普通的客户端在收到 DNS 服务器要求使用 TCP 时，会使用 TCP 进行 DNS 请求，这样不影响普通用户的使用。而 DOS 一般不会对 TCP DNS 服务进行攻击。
217 |
218 | 举例，下面语句的意思是：
219 |
220 | ```
221 | addAction(MaxQPSIPRule(40, 24, 48), TCAction())
222 | ```
223 |
224 | 限制 /24 的 IPv4 地址（256 个）和 /48 的 IPv6 地址（2^80 个）的 qps 为 40，若超出则要求客户端使用 TCP 请求。
225 |
226 | 除了 TCAction 和 DropAction，还可以使用 DelayAction（一个整数参数，代表为延迟的毫秒数）和 NoRecurseAction（专门用于限制标记了递归((RD))的请求）。
227 |
228 | 因此，将 dnsdist 与 pdns 配合使用，就可以使 DNS 服务有一定的抗 DOS 能力。
229 |
--------------------------------------------------------------------------------
/source/_posts/2019-02-26-ssd-usb-and-wtg.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: SSD U盘、Windows To Go 与 Mac
3 | tags:
4 | - 硬件
5 | id: '3776'
6 | categories:
7 | - 科技
8 | date: 2019-02-26 16:49:52
9 | languages:
10 | en-US: https://www.ze3kr.com/2019/02/ssd-usb-and-wtg/
11 | cover: 
12 | ---
13 |
14 | 最近，我先后购买了 SSD U盘和 SSD 硬盘。我在我的 SSD U盘上安装了 Windows To Go，并在 Mac 设备上良好使用。本文将分享一下我的体验。
15 |
16 |
17 | ## SSD U盘/移动硬盘
18 |
19 | ### SSD VS HDD
20 |
21 | TL;DR：固态硬盘（SSD）的性能比机械硬盘（HDD）高 10 倍左右，体积与重量也明显小于 HDD，但单位容量的价格也高了近 10 倍。
22 |
23 | 固态硬盘（SSD）已经成为了一个比较流行的概念。通常，固态硬盘的各个性能要好于传统机械硬盘（HDD），包括但不限于读写速度、IOPS 等指标。一个普通的机械硬盘的读写速度大概在 100Mbyte/s 左右，而固态硬盘则能达到 1000Mbyte/s 以上，速度比移动硬盘快了近 10 倍。SSD 的 IOPS 性能相比 HDD 可以提升近 100 倍。这些性能提升体现在各个方面：拷贝文件、打开存储在硬盘上的文档和软件软件、启动系统等，最高能有十几倍的速度提升（如果瓶颈是在硬盘读写的话）。当然 SSD 的价格也能比 HDD 高近 10 倍。此外，HDD 相比 SSD 噪音要大很多，SSD 基本是无声的。
24 |
25 | 市面上销售的移动硬盘多数都是低速的 HDD，因为普通消费者最常关心的是容量和价格，HDD 的每 GB 价格更低，SSD 则贵很多，所以 SSD 的销量也相对的低很多。花 300 块可以买到一个 1TB 的 HDD，而 1TB 的 SSD 可能需要 3000 块。
26 |
27 | **我是否需要 SSD？**要看是否有高性能需求。比如，**操作系统和软件就适合安装在 SSD 上**，这样启动时间会大大缩短。一些文档、图片和视频等数据则可能不是那么需要 SSD。如果你是图像/视频工作者，需要存储高画质的图像/视频，那么 SSD 就会很有用，它可以大大缩短文件的加载时间；当然很多软件也为低性能设备做了优化，比如 Lightroom Classic CC 可以生成预览（Preview）以减少文件大小；Final Cut Pro 和 Premiere CC 可以为原始素材生成代理（Proxy）以减少文件大小，你可以将预览或代理存储在 SSD 上，原始文件存储在 HDD 上以节省成本。此外，一些访问频率很低的数据也可以存储在 HDD 上以节省成本，如数据备份、监控视频、日志等。
28 |
29 | 
30 |
31 | 此外，SSD 能有更轻的重量，更小的体积，以至于 SSD 可以做成 U 盘大小。而 HDD 就会大很多。以现在常用的最小的 2.5英寸 HDD 为例，其长度为 10cm，宽度为 7cm，这还不包含外壳部分。上图所示的 SSD 的长宽高仅有 3.0cm \* 2.7cm \* 0.4cm，重量也不到 40g。其长度不到 HDD 的三分之一。
32 |
33 | SSD 也可以做到很大的容量，比如 15英寸 MacBook Pro 甚至可以选择高达 4TB 容量的 SSD。但由于 SSD 的价格过于昂贵，导致大容量的 SSD 并不流行。
34 |
35 | ### SSD U盘与移动硬盘
36 |
37 | SSD 外设有着如此之高的读写速度，以至于只有使用 5Gbps 的 USB3.0 和 USB3.1 Gen1，或者 10Gbps USB3.1 Gen2 才能体现出它的性能，这些接口的速度对于 SATA SSD 已经够了。然而，若要发挥出其全部性能，则需要使用 20Gbps Thunderbolt 2 或者 40Gbps Thunderbolt 3 接口，因为多数的 NVMe SSD 读写性能大于 10Gbps 而不超过 20Gbps。使用 480Mbps USB2.0 的 SSD 几乎是无意义的，所以你也很难找到这种产品。不同接口的 SSD 外设价格也区分的很明确，使用的接口越高端就越贵。使用 Thunderbolt 接口的移动 SSD 价格会比使用 USB 接口的贵 2~3 倍（速度快 2~4 倍）。
38 |
39 | 
40 |
41 | Thunderbolt3 接口的外形与 USB Type-C 外形完全一样，有些移动硬盘使用了 Type-C 接口，但不代表它就是 Thunderbolt3。你可能需要通过观察其是否有 Thunderbolt 的 ⚡️标志来判断是否支持 Thunderbolt。此外，使用 Thunderbolt3 接口的移动硬盘未必支持 USB 协议，例如我购买的 HP P800 移动硬盘，就不支持 USB 协议，且不能转接成 USB，同时也不能转接成 Thunderbolt2，所以其兼容性就大打折扣。而 USB3.x 的设备通常兼容 USB2.0，且 USB Type-A 与 Type-C 也能相互转接，所以 USB 设备有着更好的兼容性。
42 |
43 | **SSD 移动硬盘**类似与普通的移动硬盘（基于 HDD），但有着更高的性能。通常，SSD 移动硬盘的体积也会更小。
44 |
45 | **SSD U盘**相当于更小的 SSD 移动硬盘，其体积可能和普通的 U 盘相近。由于体积的减小，SSD U盘读写性能与散热性能通常不如 SSD 移动硬盘。且更少有支持 Thunderbolt 的 U 盘。
46 |
47 | 
48 |
49 | | | HP P800 SSD | CHIPFANCIER SSD |
50 | | ----- | ----- | ----- |
51 | | 接口 | Thunderbolt3 | USB3.1 Gen2 Type-C |
52 | | 类型 | 移动硬盘 | U 盘 |
53 | | 大小（毫米） | 141x72x19 | 72x18x9 |
54 | | 读取速度 | 2400Mbyte/s |
55 | | 约 500Mbyte/s |
56 | | 写入速度 | 1200Mbyte/s | 约 450Mbyte/s |
57 | | 容量 | 256GB/512GB/1TB/2TB |
58 | | （2TB 版本尚未发布） | 128GB/256GB/512GB/1TB |
59 |
60 |
61 |
62 | ## 磁盘格式的选择
63 |
64 | 通常硬盘需要格式化后再使用。在格式化硬盘时，你就需要选择磁盘格式。在这里比较一下四种格式：APFS、NTFS、exFAT 和 FAT32。（某些软件和文档只能安装或存储到特定的磁盘格式中，就不再表里列举了）
65 |
66 | | | APFS | NTFS (v3.1) | exFAT | FAT32 |
67 | | ----- | ----- | ----- | ----- | ----- |
68 | | 发布年份 | 2017 | 2001 | 2006 | 1977 |
69 | | 适用介质 | 建议 SSD |
70 | | 不限 | 不限 | 不限 |
71 | | Windows 兼容 | – | 支持 | 7+**** |
72 | | 支持 |
73 | | macOS 兼容 | 10.12+ |
74 | | (Sierra) | 支持* | 支持 | 支持 |
75 | | Linux 兼容 | – | 支持* | – | 支持 |
76 | | 移动兼容 | – | – | 支持 | 支持 |
77 | | 快照 | Snapshots | Shadow Copy** | – | – |
78 | | 加密 | FileVault | BitLocker** | – | – |
79 | | Copy-on-Write | 支持 | – | – | – |
80 | | 空间共享 | 支持 | – | – | – |
81 | | 最大文件大小*** | ∞ | ∞ | ∞ | 4GB |
82 | | 最大分区大小*** | ∞ | ∞ | ∞ | 32GB |
83 |
84 | * \* macOS 和 Linux 默认只能读取 NTFS 磁盘数据，而不能写入。Mac 可以通过调整系统设置实现读写，Mac 与 Linux 也均通过第三方软件实现 NTFS 的读写。
85 | * \*\* Shadow Copy 和 BitLocker 通常只支持 Windows
86 | * \*\*\* 这里使用字节数而非比特数。大于 1000TB 的这里就当作 ∞。**FAT32 在部分操作系统中可以有更大的分区大小（如 2TB）。**
87 | * \*\*\*\* 尽管原始版本的 Windows XP 和 WIndows Vista，但 Windows XP 在安装 KB955704 后，Windows Vista 在安装 SP1 或 SP2 更新后，也可部在某种程度上支持 exFAT。
88 |
89 | **关于操作系统兼容**，若该操作系统绝大多数主流版本都支持，则算作 “支持”。_移动兼容_只要同时兼容 iOS 和安卓就算 “支持”。
90 |
91 | **关于 iOS**，目前 iOS 系统仅支持导入外置存储的图片和视频，且外置存储的图片和视频必须按照相机文件结构命名；尽管 iOS 内置存储使用的是 APFS，但还不支持基于 APFS 的外部存储。
92 |
93 | 磁盘格式对硬盘性能影响不大，主要看其兼容性与功能。但兼容性好的功能少，功能多的兼容性差。
94 |
95 | ## 进阶: Windows To Go
96 |
97 | 通过使用 SSD 外设，可以在保证较高的性能的同时扩展电脑的储存。然而，你甚至可以把电脑操作系统安装在 U 盘上，这样你不用分区也能使用目标操作系统开机。如果你将操作系统安装到 HDD 移动硬盘上，其启动速度就会很慢；如果安装到普通 U盘上，其启动速度几乎是不能忍受的。因此**建议将操作系统安装到 SSD 外设上**。
98 |
99 | macOS、Windows 和 Linux 都可以被安装在 U盘或者移动硬盘上。但 Windows 对各种硬件兼容的最好，如果你需要在 PC 机上使用，那么只推荐 Windows 系统。Windows 10 企业版支持 Windows To Go 功能，专门为安装在 U 盘或移动硬盘上时进行了优化。
100 |
101 | 要安装 Windows To Go（WTG） 需要有 Windows 环境，可以是安装 Windows 的 PC、使用 BootCamp 的 Mac，或者是运行有 Windows 的虚拟机。如果你恰好使用 Windows 10 企业版，那么你可以使用系统控制面板中的 WTG 工具（然而我用系统自带的工具安装失败了）。否则你只能使用第三方工具安装 WTG。这里推荐[这个 WTG 辅助工具](https://bbs.luobotou.org/thread-761-1-1.html)。
102 |
103 | 安装成功后，你可以在电脑启动时选择从 U 盘启动，或者在虚拟机里从 U 盘启动。这里展示一下在 Mac 上启动 WTG 以及 macOS 上的 VMware Fusion 中启动 WTG。
104 |
105 |
106 |
107 | MacBook Pro 开机启动到 Windows To Go。
108 |
109 |
110 | 以上视频是在 Mac 上开机直接进入 WTG。如果你的 Mac 配备了 T2 安全芯片，那么你需要[关闭启动安全性检查](https://support.apple.com/zh-cn/HT208330)（无安全性、允许从外部介质启动）才能够从外部设备启动 Windows。你可以考虑开启固件密码以继续保证安全性（没有 T2 芯片的 Mac 也可以开启固件密码）。提示：请牢记固件密码，固件密码一旦忘记只能返厂修。
111 |
112 | 刚安装完的 Windows 可能没有 Mac 的鼠标和触摸板的驱动。你需要通过 USB 鼠标和触摸板来完成安装工作（Magic Keyboard 2 和 Magic Trackpad 2 连线后也可作为 USB 外设）。
113 |
114 | 你需要为 Windows 安装 Mac 的驱动。在 Mac 的 “启动转换”（Boot Camp）软件中的 “操作” 菜单里可以手动 “下载 Windows 支持软件”（驱动）。注意，不同型号的 Mac 的驱动不同，建议使用系统的软件下载。如果你需要在多个 Mac 上使用一个 WTG，你需要安装多个驱动。启动转换助理是帮助用户在 Mac 本地硬盘上安装 Windows 双系统的，**不能**用来安装 Windows To Go，这里**只是用它安装驱动**。
115 |
116 | 
117 |
118 | **建议将驱动保存在另一个 Windows 可以识别的 U盘上**（见本文的 “磁盘格式的选择”）。然后再次开机进入 WTG 后就能安装了。
119 |
120 |
121 |
122 | macOS 使用 VMware Fusion 进入 WTG。
123 |
124 |
125 | 如果你有虚拟机，你也可以在虚拟机里从 U 盘启动。
126 |
127 | ### BitLocker
128 |
129 | 如果不启用 BitLocker，那么 U盘上所有用户文档都是明文存储的，也就是说只要有了你的 U盘，就能读取所有的用户数据。若启用了 BitLocker，那么磁盘数据安全性就能得到保证。然而 Mac 没有 BitLocker 的相关硬件支持，默认无法启动 WTG 中的 BitLocker，需要修改 Windows 下的配置文件。
130 |
131 | 启用 BitLocker 后会些许增加系统的 CPU 占用，略微降低磁盘性能。此外，启动了 BitLocker 的磁盘 macOS 无法识别，意味着在 macOS 系统上无法读取开启了 BitLocker 的 Windows 分区。建议谨慎开启。
132 |
133 | ### 使用体验
134 |
135 | 将 Windows 安装到 U盘不但节省了电脑内的磁盘空间，还有了一个可以随身携带的操作系统，可以在 Mac 和 PC 机上使用。我没有开启 BitLocker。我在 macOS 上开启了 NTFS 读写，所以其 Windows 分区还可以被当作 U盘共享数据使用。
136 |
137 | 我在 WTG 上安装了一些常用软件，在其他 PC 机上未必需要进入 WTG 系统以使用这些软件，而直接进入 WTG 根目录下 Program Files 文件夹里访问这些软件就行了。
138 |
139 | 我将 Windows 安装到了 CHIPFANCIER 出的 SSD U盘上，其特色是使用了 USB3.1 Gen2 Type-C 接口，这样不需要转接就能够在新 Mac 上使用。然后我又购买了绿联的 Type-C 转 Type-A 的转接头（USB 3.0），可以将此 U 盘转接到 Type-A 设备上。
140 |
141 | 
142 |
143 | 
144 |
--------------------------------------------------------------------------------
/source/_posts/2022-03-14-website-optimization.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: 本站改版后的架构与优化——Hexo，分区解析，CDN，图像压缩等
3 | date: 2022-03-14 11:59:59
4 | tags:
5 | - 响应式设计
6 | - 网站
7 | - CDN
8 | categories:
9 | - 开发
10 | ---
11 |
12 | 去年，我把我的网站从 WordPress 迁移到了 Hexo。随后的一段时间里，我对 Hexo 进行了大量定制，包括修改主题，实现图片自适应，适配视频等。
13 |
14 | ## 基础架构
15 |
16 | 本站使用 [Hexo](https://hexo.io/zh-cn/) 博客框架生成静态网页，使用 Nginx 服务器分发静态网页、图片等。本站的静态文件和图片同时部署在全球四台服务器上，使用 Route 53 实现了分区解析和宕机后自动切换，使用 CloudFront 和 UPYUN CDN 分发视频。
17 |
18 |
19 |
20 | ## 主题
21 |
22 | 本站主题是在 [Claudia](https://github.com/Haojen/hexo-theme-Claudia) 的基础上进行[定制与魔改](https://github.com/ZE3kr/hexo-theme-Claudia)。原主题就有如下功能：
23 |
24 | + 移动端适配
25 | + 评论插件集成
26 | + 页面边栏 (个人信息，最近文章等)
27 | + 自适应设备的深色模式
28 | + 目录自动生成
29 | + 现代化的设计语言
30 |
31 | 
32 |
33 | 我对其增加的功能主要如下：
34 |
35 | ### 图片
36 |
37 | + 自动为文章中图片增加 srcset 和 sizes 属性
38 | + 支持全屏展示
39 | + 支持全屏后缩放，并按需加载缩放后的分辨率
40 | + 移动端 `100vw` 宽度无边距
41 | + 自动将图片转化为 `` 并展示图片描述
42 |
43 | ### 视频
44 |
45 | + 自动解析 `
54 | 网站搜索演示
55 |
56 |
57 |
58 | ## 分区解析与 CDN
59 |
60 | 我的网站目前同时部署在国内外多个主机上，使用着相同的配置。域名使用 Route 53 的延迟记录进行分区解析，并开启了 “运行状况检查” 实现宕机后自动切换服务器目前本站使用了 5 个服务器，分别部署在北京、东京（日本）和拉斯维加斯 (美国)、蒙特利尔 (加拿大) 和法兰克福 (德国)。
61 |
62 | 选择使用 Route 53 作为解析服务器的原因是：
63 |
64 | + 它使用了 Anycast 技术，在全球访问速度都很快
65 | + 国内连接 Route 53 的 DNS 服务器可以连接到延迟小于 50ms 的日本节点，
66 | + 支持 DNSSEC 和 IPv6
67 | + 支持按地区的分区解析、延迟解析等。在美国可以细分到州，其他地方也可以细分到国家
68 | + 支持 “运行状况检查”
69 | + 按量计费。起步价每个域名 $0.50 /月，“运行状况检查” 每个服务器 $0.50 /月。上述的所有功能也均是按量付费，没有固定月费。
70 |
71 | ### 视频 CDN
72 |
73 | 本站视频虽然是使用 Cloudflare Stream 存储和转码，但实际分发使用的是 CloudFront 和阿里云 CDN。主要是 Cloudflare 的视频是按量计费，其单价比 CloudFront 要贵。其次是 Cloudflare Stream 不提供国内节点，因此为国内提使用阿里云 CDN。
74 |
75 | #### 双 CDN 配置——Nginx 替换 CDN URL
76 |
77 | 实现双 CDN 有两种方法，第一种是使用 Nginx 根据访客国家替换 CDN URL。这样做相比分区解析的好处是即便用户配置的 DNS 服务器非用户所在地服务器，替换 CDN URL 方式依然会让用户使用正确的 CDN。可以采用了 Nginx 根据客户端 IP 的国家进行 CDN 域名的替换，具体配置——在 `http` 中：
78 |
79 | ```
80 | geoip2 /usr/share/GeoIP/GeoLite2-Country.mmdb {
81 | auto_reload 1d;
82 | $geoip2_data_country_code default=CN country iso_code;
83 | }
84 |
85 | map $geoip2_data_country_code $tlo_domain {
86 | default "tlo.xyz";
87 | "CN" "tloxygen.com";
88 | }
89 | ```
90 |
91 | 在 `server` 中：
92 |
93 | ```
94 | sub_filter '//videodelivery.net/' "//video.${tlo_domain}/";
95 | ```
96 |
97 | 这样一来，用户访问网站时，服务器会根据用户访问网站时的 IP 地址（而非 DNS 提供的 IP 地址）来选择合适的 CDN。
98 |
99 | #### 双 CDN 配置——分区解析
100 |
101 | 这就不用多说了，将两个 CDN 绑定在一个域名上，使用 GeoDNS 对不同地区的访客返回不同的结果。
102 |
103 | ### 图像 CDN
104 |
105 | 本站的图片均使用 Cloudflare Images 进行压缩与存储，并通过 Nginx 进行代理与缓存。Nginx 配置如下，实现了根据设备兼容性优先提供 AVIF、WebP 和 JPEG。这是因为 Cloudflare Images 在国内的速度不佳。此外 Cloudflare Images 可以在访问时自动将图片调整分辨率和格式。当用户访问相对路径 `/cdn-cgi/imagedelivery/` 时，网站就会加载相应的图片，还省去了与新的域名建立 HTTP 连接的时间。
106 |
107 | #### Nginx 配置
108 |
109 | 在 `http` 中：
110 |
111 | ```
112 | map $http_accept $suffix {
113 | default "jpeg";
114 | "~image/avif" "avif";
115 | "~image/webp" "webp";
116 | "~image/apng" "apng";
117 | }
118 |
119 | map $http_accept $png_suffix {
120 | default "png";
121 | "~image/avif" "avif";
122 | "~image/webp" "webp";
123 | "~image/apng" "apng";
124 | }
125 |
126 | map $http_accept $gif_suffix {
127 | default "gif";
128 | "~image/avif" "avif";
129 | "~image/webp" "webp";
130 | "~image/apng" "apng";
131 | }
132 |
133 | map $http_accept $default_suffix {
134 | default "default";
135 | "~image/avif" "avif";
136 | "~image/webp" "webp";
137 | "~image/apng" "apng";
138 | }
139 |
140 | map $sent_http_Content_Type $file_name {
141 | default "default";
142 | "image/avif" "avif";
143 | "image/webp" "webp";
144 | "image/apng" "apng";
145 | "image/jpeg" "jpeg";
146 | "image/png" "png";
147 | "image/gif" "gif";
148 | }
149 | ```
150 |
151 | 在 `server` 中
152 |
153 | ```
154 | proxy_store /var/www/images$uri/image.$file_name;
155 |
156 | location /cdn-cgi/imagedelivery/6T-behmofKYLsxlrK0l_MQ/ {
157 | root /var/www/images/;
158 |
159 | try_files $uri/image.$suffix $uri/image.$png_suffix $uri/image.$gif_suffix $uri/image.$default_suffix @proxy;
160 | }
161 |
162 | location @proxy {
163 | proxy_ssl_name imagedelivery.net;
164 | proxy_ssl_server_name on;
165 | proxy_ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
166 | proxy_set_header Host imagedelivery.net;
167 | proxy_set_header Upgrade $http_upgrade;
168 | proxy_set_header Connection upgrade;
169 | proxy_hide_header Upgrade;
170 | proxy_hide_header Alt-Svc;
171 | proxy_hide_header Expect-CT;
172 | proxy_http_version 1.1;
173 | proxy_set_header Connection "";
174 | if ($uri ~* '^https://cdn.tloxygen.com/images/(.*)$') {
175 | add_header X-Cache-Status "MISS";
176 | proxy_pass https://cdn.tloxygen.com/images/$1;
177 | break;
178 | }
179 | }
180 | ```
181 |
182 | 通过 `proxy_store`，图片将会在第一次请求后永久的存储在本地，并在下次访问时从本地提供。在存储时，图片的变体名和格式会作为文件名的一部分进行存储。在访问时，服务器会根据客户端发送的 `http_accept` 请求头去查找对应文件。
183 |
184 | AVIF 格式比 WebP 的压缩效率更好，而 WebP 格式比 JPEG 的压缩效率更好。然而对于兼容性而言，JPEG > WebP > AVIF。尽量不要在网站上使用 GIF，如果需要展示动画，可以使用静音自动循环播放的 `
16 |
17 | 其实，在 TL-PA500 的说明书中，写明了它的网线端口为 10/100Mbps 端口，也就是说它根本无法达到 100M 以上的速度…… 其实我并不相信这个电力猫真的能达到 500M 的速度，于是我对其进行了测试，在连接另一个 AirPort 基站（无线）的情况下，拷贝一个 3 GB 的文件到 AirPort Time Capsule。并在直接连接 AirPort Time Capsule （无线）情况下拷贝，对比时间，两个基站距离约 15m。 特别要注意的是，另一个基站（AirPort Extreme）是不支持 802.11ac 的，而 AirPort Time Capsule 是支持的。二者都支持 5GHz 频段，拷贝时都使用了它。 经过了电力猫之后，传输这个 3GB 的文件消耗了 **8 分钟**，大约达到了 **50M** 的速度，没有达到 802.11n 在 5GHz 下的极限。 直接传输，消耗了 **2 分 20 秒**，大约是 **170M**。 所以，经过了电力猫之后，传输速度被限制在了 50M 左右（但或许是用了网线也是这个速度），这个速度还是可以接受的，因为中国地区普遍的网速都没有达到这个极限，用来部署互联网还是完全可行的。 然而最终还是重新走了暗线，全家局域网终于达到 1000M，可算是够用了。
18 |
--------------------------------------------------------------------------------
/source/favicon.svg:
--------------------------------------------------------------------------------
1 |
--------------------------------------------------------------------------------
/source/_posts/2015-11-20-activite-pop.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Withings Activité Pop 智能手表推荐，睡眠跟踪、运动记录、智能闹钟
3 | tags:
4 | - 智能设备
5 | - 硬件
6 | id: 220
7 | categories:
8 | - - 科技
9 | date: 2015-11-20 17:27:29
10 | cover: https://customer-qz3v4c7e4vfly110.cloudflarestream.com/12d9fb47f8bf1560187d3b57c26816f1/thumbnails/thumbnail.jpg?time=1m4s
11 | video: 12d9fb47f8bf1560187d3b57c26816f1
12 | languages:
13 | en-US: https://www.ze3kr.com/2015/11/activite-pop/
14 | ---
15 |
16 | 这个智能手表与众多现有智能手表不同的是，他拥有实体的指针。[在亚马逊上购买正品](https://www.amazon.cn/gp/product/B00S5I9H4O?tag=ze3kr-23)
17 |
18 |
19 | ## 记录健康数据
20 |
21 | Activité Pop 可以自动的检测走路、跑步、游泳以及睡眠。你根本不需要去进行任何设置，他就能正确的识别出当前的运动类型，包括睡眠记录也是如此。 它可以记录运动时长、步行/跑步距离、运动中消耗的卡路里，还有睡眠总时长、醒来的次数、深睡眠时长、浅睡眠时长。这一切都是自动的。
22 |
23 | ## 智能闹钟
24 |
25 | Activité Pop 有震动闹钟功能，不仅如此，它还拥有智能唤醒功能，当即将到已经设定的时间，并且它检测到你已经醒来后或者进入浅睡眠时就提前唤醒你。
26 |
27 | 
28 |
29 | ## 超长续航
30 |
31 | 续航时间长达 8 个月，使用标准纽扣电池。
32 |
33 | ## 视频
34 |
35 | 
22 |
23 | 
24 |
25 | ## 屏蔽好搜
26 |
27 | 首先能做的事情就是屏蔽它，我特意看了[它们的文档](http://www.haosou.com/help/help_3_2.html) 然后我发现了啥？好搜竟然不支持使用 `robots.txt` 文件协议单独屏蔽它，好搜跪着求我：“不要屏蔽我，我还想那你的内容赚钱，你要非要屏蔽就把所有的都屏蔽了吧！” 当然，我是不怕这些的，我直接屏蔽你的 User Agent 不就好了。于是我在 `.htaccess` 文件下加入了如下内容：
28 |
29 | ```
30 | RewriteEngine on
31 | SetEnvIfNoCase User-Agent "360Spider" bad_bot # 屏蔽垃圾搜索引擎
32 | SetEnvIfNoCase User-Agent "HaoSouSpider" bad_bot # 屏蔽垃圾搜索引擎
33 | SetEnvIfNoCase User-Agent "360Spider-Image" bad_bot # 屏蔽垃圾搜索引擎
34 | SetEnvIfNoCase User-Agent "360Spider-Video" bad_bot # 屏蔽垃圾搜索引擎
35 | Deny from env=bad_bot
36 | ```
37 |
38 | 然后我竟然发现了就算这样也依然没有效果！看来好搜为了不想让别的网站屏蔽可是下了功夫啊，没关系，我还有方法。
39 |
40 | ### 利用 Referer 屏蔽它加载图片
41 |
42 | 嗯，很成功，图片加载不了了，但是并没有完全屏蔽它。
43 |
44 | 
45 |
46 | ### 利用好搜缺陷屏蔽它
47 |
48 | 于是，我发现好搜并不支持抓取 HTTPS 站点，那好，我强制 HTTPS。好搜终于怂了。
49 |
--------------------------------------------------------------------------------
/source/_posts/2015-07-19-eye-fi.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Eyefi Mobi 立刻让你的相机支持 Wi-Fi
3 | tags:
4 | - 智能设备
5 | - 相机
6 | - 硬件
7 | id: '138'
8 | categories:
9 | - - 科技
10 | date: 2015-07-19 12:40:14
11 | languages:
12 | en-US: https://www.ze3kr.com/2015/07/eye-fi/
13 | ---
14 |
15 | Eyefi Mobi 是一张有 Wi-Fi 功能的 SD 卡。当配置好后，相机每照完一张照片，手机上就能立即显示并分享它。[在亚马逊上购买正品](https://www.amazon.cn/gp/product/B00CS4WPD6?tag=ze3kr-23)
16 |
17 | ## 兼容性
18 |
19 | [兼容绝大多数能安装 SD 卡的相机](http://www.eyefi.com/cameras) 比如佳能 5D Mark III、7D Mark II 等机型都不带 Wi-Fi 功能，但是都是 CF/SD 双卡槽，可以将照片同时存进两张卡中。考虑到 Eyefi Mobi 卡的速度以及容量不及 CF 卡。所以我设置在 Eyefi Mobi 卡中存储 JPEG 格式，在 CF 卡中存储 RAW 格式，JPEG 格式更适合手机分享到社交网络，RAW 格式适合后期编辑，十分方便。我在佳能相机中每拍下一张照片都会同时存储 JPEG 和 RAW 格式的照片至两张卡（相机中设置为“同时记录”即可），即使是使用 7D Mark II 的每秒十张连拍也没有丝毫问题，可见这张卡在专业相机上当作副卡是表现不错的，可以快速从手机分享刚刚拍摄的照片。 除此之外，Eyefi Mobi 卡还适合仅有 SD 卡的入门级机型，这些相机没有很快的连拍，这张卡能达到日常需要，也很适合喜欢分享照片的入门级用户。
20 |
21 | ### Eyefi 联动功能
22 |
23 | 兼容 Eyefi 联动功能的相机可以直接配置 Eyefi 卡的设置，同时还能够保证相机关闭后还能够继续传输文件，通过相机的显示屏显示传送进度，或在机器的菜单中直接看到Eyefi的运行情况。 以佳能相机为例，在安装了 Eyefi 卡后，相机设置中就会有一个新菜单选项：
24 |
25 | 
26 |
27 | 
28 |
29 | ## 易用性
30 |
31 | Eyefi Mobi 卡首次使用时，只需要在手机上下载一个软件，在软件中输入这张卡的 ID，待配置完成后，将此卡装入相机中照一张照片，你就会发现手机上立刻就出现了这张照片，使用十分方便。在相机中可以查看此卡的传输状态，以及进度。通常这张卡仅在有新照片的时候无线功能才工作，当图片全部传输完成后，无线功能自动关闭，相机续航能力几乎没有什么变化。
32 |
33 | ## 小提示
34 |
35 | * 如果你的相机是 CF/SD 卡双卡槽，建议你仍然配一个高性能大容量 CF 卡，这样既能达到高速传输，同时还能有 Wi-Fi 功能，而且不用购买容量很大的 Eyefi Mobi 卡，将其当做一枚副卡。而且，请设置“同时记录”，并设置存在 Eyefi Mobi 卡上的照片格式为 JPEG。
36 | * 如果你仅仅是将其当作副卡，那么你不需要在这张卡上保存全分辨率的照片，可以存储尺寸更小的照片，这样可以很大程度上减少手机上的空间占用，使照片更适合分享。（同时，照片中的噪点也少了）
37 | * 这张卡可以存储任何格式的照片，但是只有 JPEG 格式的照片以及 AVI、MP4、MPG、MTS 和 MOV 格式的视频能够被传输到手机，RAW 格式照片不会被传输到手机。
38 | * 如果你的相机只安装 Eyefi Mobi 卡，同时很需要 RAW 格式的照片，又需要将照片传输到手机，那么请选择“同时记录 RAW + JPEG”。
39 |
--------------------------------------------------------------------------------
/source/_posts/2015-05-16-mobile-first-beginning.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: 移动优先 – 起源
3 | tags:
4 | - HTML5
5 | - 响应式设计
6 | id: '1000'
7 | categories:
8 | - - 开发
9 | date: 2015-05-16 13:36:43
10 | languages:
11 | en-US: https://www.ze3kr.com/2015/05/mobile-first-beginning/
12 | ---
13 |
14 | 现有的桌面上的操作系统大多都有浏览器，浏览器可以让我们方便的浏览一个网页。 然而最初的手机浏览器访问网页是很困难的，因为它们分辨率不高、屏幕很小而且浏览器不支持众多前沿的 CSS 以及 JavaScript，使它们没有能力访问桌面版网站。那时的手机访问的网站都是专门为设备大幅度简化的版本，就像这样:
15 |
16 | 
17 |
18 | 不过，直到 iPhone 的发布，这一切都得到了很大的改变。因为 iPhone 上的浏览器 —— Safari 是一个真正的且非常前沿的 Web 浏览器，而且它还支持 HTML5 标准。它配备有几乎和电脑一样的浏览器 —— 以至于它支持 CSS3 和 JavaScript。但是这一切，却是在一个宽度仅有 320 个像素的设备上显示。 然而当一个桌面浏览器宽度缩小到 320 个像素时，它就变的大不一样，当他访问一个没有对它优化的网页时，它就会将其缩放（宽度将缩放至 1/3），以百度新闻为例，若没有适配，则将现实电脑版网站，这样页面的字会很小，但是用户可以通过缩放就能够解决，所以并没有什么问题。然而，百度新闻做了一个专门为 iPhone 的版本，像这样:
19 |
20 | 
21 |
22 | 它能够更好的适应触摸屏，并且没有了字体小的问题，也不需要缩放。但是请要注意，这个页面已经不是刚才的那个页面了，也就意味着百度需要专门重新设计一个为 iPhone 版本的网页，成本是很高的。 然而在 CSS 的帮助下，不需要准备两个网页就可以同时适配电脑和手机，它们加载到的页面相同，但是应用的样式表并不同。例如没有针对移动而优化的 [Wikipedia 导航页](https://www.wikipedia.org/)，iPhone 上的 Safari 访问时将会缩放显示，布局就如同电脑访问一样:
23 |
24 | 
25 |
26 | 然而通过增加的 CSS 样式表（当然还包括 `head` 中的 `viewport`），这个页面在手机上就会完美的显示了，就像下图:
27 |
28 | 
29 |
30 | 像 Wikipedia 导航页这样先根据电脑布局设计，再新增 CSS 使其支持移动设备的网页，就是桌面优先而不是移动优先。而移动优先则正好相反，页面根据手机而设计，然后再让它适配电脑，电脑与手机也是访问同一个页面，这就属于移动优先。由于移动优先的网站是根据手机设计，自 iPhone 发布之后，很多智能手机也使用了前沿的浏览器，所以移动优先的网站自然会使用 HTML5、CSS3 中的众多新特性，大大缩短了一个网页所需要的开发时间。而且移动优先的网站根据手机的高延迟网络而设计，减少了页面大小，无论身处什么网络环境，加载速度都有很大的提升。移动优先的优点众多，这就是导致其流行起来的原因。
31 |
--------------------------------------------------------------------------------
/source/_posts/2015-07-15-mobile-first-2.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: 移动优先 – 速度
3 | tags:
4 | - HTML5
5 | - 响应式设计
6 | id: '34'
7 | categories:
8 | - - 开发
9 | date: 2015-07-15 14:00:25
10 | languages:
11 | en-US: https://www.ze3kr.com/2015/07/mobile-first-2/
12 | ---
13 |
14 | 移动设备上的网速通常并不快，他们通常会有比宽带更慢的速度、更高的延迟，那么移动端的浏览器是如何加载页面的呢？这便是本文要介绍的内容。 其实无论是在移动端还是桌面端加载页面，都会需要以下几个步骤：
15 |
16 | ### 1\. 解析域名
17 |
18 | 域名通常对应着一个 IP 地址，浏览器只有在知道了这个 IP 地址后才能与服务器通讯。为了解析域名，客户端会向 DNS 解析服务器发送一个关于这个域名的请求，就能查询到这个域名的 IP 地址。DNS 解析是存在 “TTL 生存时间” 的，也就是缓存时间，这个内容会被缓存在 DNS 解析服务器上、路由器和客户端上，按照缓存时间存储。DNS 解析服务器通常会由运营商提供，如果存在缓存，那么解析速度则是相当快的。（目前的 DNS 解析是以十分不安全的明文的方式传输的，任何中间人都能破坏或者是修改解析结果）
19 |
20 | ### 2\. 发起请求
21 |
22 | 有了 IP 地址之后，浏览器会与服务器建立 TCP 链接，然后发出一个请求。请求中会包含需要访问网站的域名（得以使 IP 可以给多个域名提供不同内容）、请求方式、网址路径、所能接受的数据，压缩类型和编码方式、 Cookie 以及浏览器信息（能够判断你是否在手机上访问网站）。
23 |
24 | ### 3\. 下载页面
25 |
26 | 浏览器开始下载页面本身，下载页面本身后又会开始下载页面中依赖的其他内容，包括 CSS 、JavaScript 、图片等。随着优先级不同，它们可能是在渲染之前或者之后下载。
27 |
28 | ### 4\. 渲染页面
29 |
30 | 浏览器会等待加载了最重要的依赖内容（也就是在 `head` 部分中的 CSS 和 JavaScript，之后会重点提到）加载完毕后，进行渲染。因为渲染时要依赖这些内容， CSS 也就是我们常说的样式表，这些样式表十分重要，比如百度这个网页：
31 |
32 | 
33 |
34 | 没有 CSS 样式表后，整个网页的布局是 “失控” 的，页面不会以预期的方式被加载，这种体验十分糟糕。没有样式表与有样式表的网页通常是两种完全不同的样子。然而 JavaScript 通常与布局无关，可以放在之后加载，不影响页面样式。
35 |
36 | ## 提升速度
37 |
38 | 网页中的每一个内容都要经历这样的过程，以被客户端得到。只有到了渲染页面这一步时，用户才能够看到页面的内容，在此之前，页面是一片空白。要知道如果一个页面在 3 秒之内都是一片空白，那么多半用户会退出。 移动优先会考虑高延迟移动网络下的用户体验，然而当到了桌面端则也能享受到移动有限带来的速度提升。为了提升速度，有以下几种常用方法：
39 |
40 | ### 将不必要的 JavaScript 放在页面末尾
41 |
42 | 如果 JavaScript 放在末尾，可以在页面被渲染后再加载，大大减少了页面空白的时间。这是最简单，且提升效果最明显的一条。
43 |
44 | ### 使用 CDN
45 |
46 | 使用 CDN 的意思是尽可能把静态文件放在 CDN 服务器上，一个 CDN 包含很多个节点，用户下载 CDN 上的文件时会从物理位置最近或者是相同运营商的节点上下载，如果这个节点上已经有缓存则直接传给用户，如果没有缓存则从最近的数据中心下载并缓存，再传给用户。 我的做法是把网站上所有图片、视频、CSS 样式表和 JavaScript 放在 CDN 上，网站本身不在 CDN 上。这样做能大大减少加载时间，而且成本不大。无论是个人博客还是行业网站，使用 CDN 都很有必要。如果没有钱买自己的 CDN，没关系，你可以免费使用常用开源 CSS 和 JavaScript 的 CDN，官网地址地址：[cdnjs.com](https://cdnjs.com/)。
47 |
48 | ### 妥善利用缓存机制
49 |
50 | 将图片、CSS 样式表和 JavaScript 设置缓存。我习惯于设置相当长的时间（一周、一年等），有的人为了能够经常修改而把缓存期限调小。我在修改文件时会直接换文件目录，这样文件从能保持是最新的。利用好缓存，可以让用户在第二次访问时大大加速。
51 |
52 | ## 总结
53 |
54 | 对于网站速度，既要注重首次启动速度，还要利用缓存提升下一次访问速度。而且应该注意在提升速度的同时也要注重用户体验。
55 |
--------------------------------------------------------------------------------
/source/about/index.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: 关于
3 | id: '575'
4 | tags: []
5 | categories:
6 | - - uncategorized
7 | comments: false
8 | date: false
9 | layout: post
10 | languages:
11 | en-US: https://www.ze3kr.com/about/
12 | adb: false
13 | ads: false
14 | ---
15 |
16 | ZE3kr 是郭泽宇用于发布内容的 ID，发布的内容汇集以科技、摄影为主的原创精选文章、视频、图片、短文和 App 推荐。
17 |
18 | 如果有任何问题，请直接在相关文章下评论，或者在这里[反馈](https://github.com/ZE3kr/guozeyu.com/issues)。
19 |
20 | ## 联系我
21 |
22 | ### 社交网络
23 |
24 | 我使用去中心化的 Mastodon: [`@ZE3kr@tlo.xyz`](https://mastodon.tlo.xyz/@ZE3kr)
25 |
26 | ### 私聊
27 |
28 | 你可以通过这些方式与我私聊。以下方式均可启用端到端加密：
29 |
30 | + iMessage: [i@ze3kr.com](imessage://i@ze3kr.com)
31 | + ✅ 默认端到端加密
32 | + 电子邮件: [i@ze3kr.com](mailto:i@ze3kr.com)
33 | + ⚠️ [安装我的 S/MIME 公钥](/files/ze3kr.pem)并[加密邮件](https://support.apple.com/zh-cn/HT202345)
34 | + Telegram: [@ZE3kr](https://t.me/ZE3kr)
35 | + ⚠️ [启用 Secret Chat](https://telegram.org/faq#q-how-do-i-start-a-secret-chat)
36 |
37 | 如果你知道我的美国手机号，你也可以通过以下方式与我端到端加密私聊:
38 |
39 | + WhatsApp
40 | + ✅ 默认端到端加密，可通过其他联系方式与我核验端到端加密安全代码 (Security Code)
41 | + FaceTime/iMessage
42 | + ✅ 默认端到端加密
43 |
44 | 如果你知道我的美国手机号，你也可以通过以下**不安全**的方式与我联系。你需要知道，这些方式的通信不支持端到端加密，因此**会被监听**：
45 |
46 | + SMS (短信)/MMS (彩信)/电话
47 | + ❌ 非端到端加密
48 | + ⚠️ 可能有运营商资费
49 |
50 | ### 微信?
51 |
52 | 我不使用微信。
53 |
54 | ### 为什么要使用端到端加密?
55 |
56 | 我注重我的隐私，同时我也重视你的隐私。使用不支持端到端加密的聊天方式会导致你我都没有隐私：假如你使用微信这种非端到端加密的聊天软件与我通信，除了你和我之外，[在法律法规规定的情形下，即使未经用户许可，腾讯也会向第三方公开、透露用户个人信息](https://weixin.qq.com/agreement?lang=zh_CN#%E5%85%AD%E3%80%81%E7%94%A8%E6%88%B7%E4%B8%AA%E4%BA%BA%E4%BF%A1%E6%81%AF%E4%BF%9D%E6%8A%A4)。一些组织可能会宣称自己会加密数据，但却不明确使用了 “端到端” 加密。这类软件提供的加密是不完整的，因为服务提供商自己可能有能力解密并读取你的数据。
57 |
58 | ## 订阅
59 |
60 | ### RSS
61 |
62 | 你可以使用 RSS 阅读器订阅本站 (推荐)，本站的 RSS 地址是:
63 |
64 | [`https://www.guozeyu.com/feed.atom`](https://www.guozeyu.com/feed.atom)
65 |
66 | [在 RSS 阅读器中打开](feed://www.guozeyu.com/feed.atom)
67 |
68 | ### Telegram
69 |
70 | 你也可以在 Telegram 上订阅本站的频道: [ZE3krChannel](https://t.me/ZE3krChannel)
71 |
72 | ## 关于版权
73 |
74 | 如无特殊声明，本网站文字、图片、视频部分采用本作品采用[知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议](https://creativecommons.org/licenses/by-nc-sa/4.0/)进行许可。
75 |
76 | ## 隐私策略
77 |
78 | 本网站使用[自建的 Matomo](https://www.guozeyu.com/2016/01/piwik-wordpress/) 件进行统计，会使用一小段匿名 Cookie 以用于标识访客 ID，这段 Cookie 绝不会传送给第三方。
79 |
--------------------------------------------------------------------------------
/source/_posts/2016-10-04-cloudflare-2016-new-feature.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: Cloudflare 的全新功能体验——Load Balancing、Rate Limiting
3 | tags:
4 | - CDN
5 | id: '2031'
6 | categories:
7 | - - 开发
8 | date: 2016-10-04 09:26:00
9 | cover: 
10 | ---
11 |
12 | Cloudflare 在 2016 年末终于增加了两个重磅的功能，分别是：
13 |
14 | * Load Balancing（原名：Traffic Manager）
15 | * Rate Limiting（原名：Traffic Control）
16 |
17 | Load Balancing 支持更加高级的负载均衡功能，并终于支持了大家很需要的跨区域负载均衡功能；Rate Limiting 支持了高级的访问次数限制功能。越来越多的原本需要在服务器上配置的功能，现在在 Cloudflare 上也能进行配置了。（目前这两个功能还属于 Beta 阶段，需要认证用户才能使用）
18 |
19 |
20 | ## Load Balancing
21 |
22 | 此功能可以把 Cloudflare 当作负载均衡器使用，而不需要再在主机提供商上配置负载均衡，[官网介绍](https://www.cloudflare.com/load-balancing/)。目前此功能仅向 Enterprise 账户和部分有资格的用户开放。该功能有两种实现方式，分别如下：
23 |
24 | ### 通过 Cloudflare 的 CDN 实现（Anycast）
25 |
26 | 负载均衡的功能是在 Cloudflare 的边缘服务器上实现，是通过第 7 层反代的方式实现，其实很类似于原本的 CDN 功能，不过回源可以高度定制。源站可以配置多个地区（需手动设置服务器的位置），每个地区也可以配置多个服务器，可以将这些众多服务器设置为一个 Group。将域名指向这个 Group，然后 Cloudflare 的边缘服务器的回源可以根据服务器的地区来**自动**选择最近的源站服务器。这样可以非常有效的降低首字节的延迟，对动态资源速度的提升会有很大的帮助。
27 |
28 | 
29 |
30 | 此外，Cloudflare 还自带了 Health Check 功能，可以当服务器宕机后能够自动更改回源。虽然通过 DNS 的方式也可以实现宕机后切换，但是 DNS 方式毕竟会收到缓存时长影响，若使用 CDN 切换，则可以实现秒级切换。 我的一个 WordPress 站点 tlo.xyz 就使用了这个功能，默认是美国东部和亚洲东部跨区域负载均衡，两者有一者宕机自动切换。如果全部宕机，则 fallback 到 Google Cloud Storage 上的静态页面。你可以观察 https://tlo.xyz 上的 TLO-Hostname 的 Header 来判断是哪一个服务器做的响应。
31 |
32 | 
13 | ---
14 |
15 | 这是一个很值得使用的软件，包含强大的手动自定义功能、分享功能以及惊人的 HDR 合成能力。[前往 App Store 获取](https://apps.apple.com/cn/app/procamera-capture-the-moment/id694647259?at=10lJIS)
16 |
17 | ## 独创的 HDR
18 |
19 | 这个软件内置自己的 HDR，完全不同于系统的 HDR 功能，它的 HDR 堪比在 PhotoShop 上合成后的效果，十分出彩。并且有多种 HDR 格式可供选择，而且可以进行手动 HDR，自己调整 HDR 的亮度，满足所有需求。（HDR 功能需要单独购买）
20 |
21 | ## 强大的自定义设置
22 |
23 | 它支持手动对焦、手动曝光。不仅如此，它还可以调整快门速度、ISO 感光度、白平衡等等，均能实时显示，满足绝大多数照片需要。它的快门速度最高可以设置到 0.5 秒，可以轻松应对夜景（通常，系统的相机是自动曝光，然而它不会照出 0.5 秒长时间快门速度，所以噪点通常很多）。 除此之外，它还可以调整图像格式，它支持保存 JPEG 格式 (可调质量)、无压缩 TIFF 和无损压缩的 TIFF，得到无损的照片。 它可以实时手动调节画面的色温，达到最完美的白平衡。
24 |
25 | 
26 |
27 | 
28 |
29 | 
36 |
37 | ## 后期处理
38 |
39 | 此软件有丰富的后期处理的功能，甚至可以调节曝光曲线等参数，操作十分简便。
40 |
41 | 
42 |
43 | 除此之外，它还有众多滤镜，甚至还能调节每一种滤镜的参数，十分强大。
44 |
45 | 
46 |
47 | ## 定时器
48 |
49 | 这个软件有强大的定时器功能，非常适合高级的自拍或者间隔拍摄。通过后期制作，能够达到 800 万像素的间隔拍摄视频。此功能类似单反上的定时器，十分有用。你甚至不需要为了定时器去购买别的软件了。
50 |
51 | 
52 |
53 | ## 支持 Apple Watch
54 |
55 | 购买此软件后，可以在 Apple Watch 上遥控 ProCamera 进行照相，同时还可以浏览已经拍摄的照片，充分利用 Apple Watch。如你已经拥有一个 Apple Watch，并正在寻找一个可以用 Apple Watch 遥控照相的第三方软件，那么这款软件正是你要找的。
56 |
57 | 
28 |
29 | 此时已经 11:30 了，我还觉得这个是我自己的问题，毕竟我也没收到阿里云任何邮件、电话提醒。于是我登录了阿里云后台，尝试进行重启。此时我没有选择强制关机。结果，关机指令已经执行了 10 分钟，机器仍未关闭。平时我使用 GCP 时，如果关机指令执行超过两分钟，那么就会自动执行强制关机，所以此时执行了 10 分钟的关机就很离谱。然后我就尝试发工单，但没能进入到工单，被转到了在线客服。我向在线客服描述了问题后，无人回复。然后我又尝试发工单，结果工单也是无人回复。只是得到了机器人回复，说在关机时，Windows 会执行系统更新，有时需要 10-15 分钟。请在等待 20 分钟后联系客服。
30 |
31 | 大概又过了半个小时，机器终于成功关闭了，但在尝试多次后，机器无法启动。即便我点了启动，机器也会在一段时间后变成 “已停止” 状态。由于此时我还是以为是我自己的问题，不是阿里云的问题，我以为是刚刚强制关机导致系统损坏了，于是尝试给现有云盘打快照，尝试回滚。但离谱的事又发生了，我发现我根本无法打快照！快照的进度一直是 0%。
32 |
33 | 在 11:55，我终于收到了工单的回复：“您好！阿里云监控发现香港地域某机房设备异常，影响香港地域可用区C的云服务器ECS、云数据库polardb等云产品使用，阿里云工程师已在紧急处理中，非常抱歉给您的使用带来不便，若您有任何问题，请随时联系我们”。此时我才知道，这次的宕机可能不是我自己的问题，我放弃了自己尝试恢复服务。
34 |
35 | 该回复没有提供解决方案，也没有预计的恢复时间，可以说无非就是告诉了我 “这个是我们阿里云的问题”，对于恢复服务没有实质性帮助。
36 |
37 | ## 无力吐槽阿里云
38 |
39 | 本次事件最值得吐槽的地方是，我从未收到阿里云发来的有关通知。直至现在，我在邮箱、短信、站内信中没有收到任何阿里云关于此次服务宕机的提醒。我相信阿里云是有很多监控的，我坚信阿里云早在我发现我的服务出现问题之前，就已经知道了我的服务，以及其他人的服务器出现了问题了。但我却没有收到任何通知。唯一告知我阿里云存在问题的还是我发工单自己问出来的。
40 |
41 | 我觉得阿里云有必要向所有受影响的，以及可能受影响的客户发送相关提醒。在连续宕机了 8 小时，且仍未恢复的情况下，阿里云仍不主动通知客户，我实在是难以怀疑阿里云是否是故意不做通知，试图掩盖问题。
42 |
43 | ## 那还用阿里云吗？
44 |
45 | 会的。作为中国第一大，以及全球也能排的上前几的云服务商，我不怀疑阿里云的技术实力。我现在用阿里云主要是为了阿里云香港的 CN2 精品网，用于数据跨境（价格为 3元/GB）。目前在这方面也没有什么可替代的方案。专线也考虑过，太贵了，买不起。
46 |
47 | 但是，我不会把核心业务放在阿里云上了。放在 AWS 上我更安心一些。本次阿里云香港宕机只影响了我的网站一小会儿，也正是因为我没有把核心业务放在阿里云上。
48 |
49 | ## 本站是如何做到高可用的？
50 |
51 | 很简单，本站在四个地区，使用了四个不同服务商的服务器：
52 |
53 | + 德国 OVH
54 | + 北京 AWS
55 | + 香港 阿里云
56 | + 美国 Google Cloud
57 |
58 | 而且本站是纯静态网站。本站会在构建后，将构建产物分别同步到四个服务器上，没有主服务器的概念。本站通过 GeoDNS，将访客解析到最近的服务器，以降低延迟。在阿里云香港服务器宕机后，只需要停止响应解析即可。原本亚太地区解析到香港，现在亚洲会解析到北京，澳洲会解析到美国，这部分用户就被分流到可用的服务器上了。
59 |
60 | 本站还使用了 Route 53 的 Health Check 功能，可以实现接近实时的监控主机运行状态，在发现运行状态异常时，自动停止响应解析。目前，我的网站会在出现异常后一分钟内检测并识别到，并停止响应解析。相关 DNS 记录的时间设置在了 120 秒，因此服务发生不可用时，用户影响的时间不会超过 3 分钟。
61 |
--------------------------------------------------------------------------------
/source/_posts/2024-10-24-ipad-pro.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: 在 iPad 上运行 macOS? (with Jump Desktop)
3 | date: 2024-10-25 7:00:00
4 | tags:
5 | - 智能设备
6 | categories:
7 | - 科技
8 | languages:
9 | en-US: https://www.ze3kr.com/2024/10/ipad-pro/
10 | ---
11 |
12 | 在读了 [Will Apple EVER consider macOS for iPads?](https://www.reddit.com/r/iPadPro/comments/1gbcy29/will_apple_ever_consider_macos_for_ipads/) 后，我觉得我应该分享一下我在 iPad 上使用 macOS 的经验（kind of）。
13 |
14 | 这是因为我发现，在 iPad 上使用远程桌面应用（在我的情况下，是 **Jump Desktop**）并且在家里有一台 Mac mini，我就不再需要 MacBook Pro 了。让我解释一下：
15 |
16 | 我的 iPad 支持蜂窝网络。使用无限的 5G 蜂窝计划（每月 $11.5-16.5）。当我在家时，我使用 Mac mini 和 Studio Display。当我离开家时，我只带 iPad。如果我需要做一些 iPad 无法处理的事情，我可以直接 “Jump” 到家里的 Mac mini。
17 |
18 | ## 为什么这个组合比 MacBook 更好？
19 |
20 | ### 蜂窝网络
21 |
22 | iPad 支持蜂窝网络，它始终保持联网。而 Mac 可能没有这种功能，尤其当我不在家时。
23 |
24 | 1. 当我打开邮件/信息应用时，iPad 上的邮件已经全部下载完毕。然而在 Mac 上，我需要先连接到 iPhone 的热点或 Guest Wi-Fi，然后等待邮件下载。这可能需要 30 秒到几分钟。
25 | 2. 我可以随时随地通过蜂窝网络将 iPad 备份到 iCloud。然而在 Mac 上，除非我带着 USB 硬盘或者连上家里的 Wi-Fi，否则我无法通过 Time Machine 备份 Mac。（不过，我仍然可以通过第三方应用将 Mac 备份到云端。）
26 | 3. 我还可以通过蜂窝网络备份 Lightroom 照片。使用 USB 3，我可以将所有照片导入 iPad，然后通过 5G 上传到 Lightroom。然后我 Jump 到 Mac mini 上，这些照片已经在 Mac mini 的 Lightroom 中了。Jump 到 Mac 后，我可以做 AI 降噪等处理。完成 AI 去噪后，我可以返回 iPad 的 Lightroom 进行更多操作。
27 | 3. 流媒体、应用体验等。有了蜂窝网络，这些事情都变得更加方便。
28 |
29 | ### 娱乐应用
30 |
31 | 1. Netflix for iPad（或者其他许多流媒体应用）。在飞行前，我可以在 iPad 上下载一堆节目。Mac 上无法做到这一点。有些流媒体网站甚至无法在 Mac 上播放 4K HDR，但可以在 iPad 应用中做到（比如 Paramount，至少曾经是这样）。
32 | 2. 在 iPad 的 OLED 显示屏上流媒体播放效果更好，而且更方便。它更小、更轻，我可以在观看节目时取下键盘。这比 Vision Pro 还要简单。
33 | 3. 阅读书籍。用 iPad 读书比用 MacBook 更自然。
34 |
35 | ### 其他
36 |
37 | 1. 触摸屏和 Apple Pencil。Mac 没有这些功能。而且，当我 Jump 到 macOS 时，我还可以使用触摸屏和 Pencil。
38 | 2. 我家里的 Mac mini 连接了许多外设：两个 4TB 的 SSD 和超过 10TB 的硬盘。它还有千兆网速。当我 Jump 到我的 Mac 时，所有这些外设都可以访问。如果不使用远程桌面，我就必须带上这些外设，而这有丢失的风险，数据安全得不到保障。
39 |
40 | ### 它比 iPad + MacBook Pro 还好：
41 |
42 | 1. iPad 比 MacBook Pro 更轻便。带着 iPad 和 MacBook Pro 一起旅行太重了。
43 | 2. 在旅行中拥有更多设备也很难管理。比如还要给额外的设备充电，我得带更多的线，有时还会忘记给其中一个设备充电。此外，跨两个设备同步也很麻烦。
44 |
45 | ## 我使用的具体配置
46 |
47 | 我使用 [Jump Desktop](https://apps.apple.com/app/id364876095)，因为它也支持流式传输扬声器和麦克风。如果你想通过流体协议传输音频，还需要安装 [Jump Desktop Connect](https://jumpdesktop.com/connect/)。
48 |
49 | ### SwitchResX
50 |
51 | 我使用 [SwitchResX](https://www.madrau.com/srx_download/download.html) 来为我的 Mac 添加新的自定义 iPad 分辨率。当我的 iPad Jump 到我的 Mac 时，Mac 可以切换到 iPad 的分辨率以匹配 iPad 的屏幕。
52 |
53 | 首先，截取你 iPad 的屏幕截图。然后，打开照片应用，读取分辨率。我的 iPad 分辨率为 2420 × 1668：
54 |
55 | 
56 |
57 | 然后，水平方向减去 50 像素。在我的情况下，1668 - 50 = 1618，所以新的分辨率为 2420 × 1618。
58 |
59 | 在 SwitchResX 中，添加该新分辨率。记得选择缩放分辨率。
60 |
61 | 
62 |
63 | 然后保存（Command + S），并重启。在 iPad 上，打开 Jump Desktop，使用这个配置：
64 |
65 | 
66 |
67 | ### 为什么要减去 50 像素？
68 |
69 | 这是因为默认情况下，Jump 不会使用 Home 指示器区域。如果你想使用 Home 指示器区域，你可以在 iPad 上的 Jump Desktop 设置中启用“外观 - 使用 Home 指示器区域”，并且不用减去这 50 像素。
70 |
71 | 我发现我不想使用这个区域，因为我的 Mac 的 Dock 在底部。使用这个区域会影响我点击 Mac 的 Dock。
--------------------------------------------------------------------------------
/source/_posts/2017-01-24-2017-is-a-https-year.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: 2017 年，再看 SSL 和 HTTPS
3 | tags:
4 | - HTTPS
5 | - 安全
6 | id: '2430'
7 | categories:
8 | - - 科技
9 | date: 2017-01-24 15:46:29
10 | languages:
11 | en-US: https://www.ze3kr.com/2017/01/2017-is-a-https-year/
12 | ---
13 |
14 | 一年之前，我发表过一篇文章：[全面 HTTPS 时代即将到来](https://www.guozeyu.com/2015/12/https-everywhere-is-coming/)。到现在，HTTPS 又有什么新变化呢？本文就来一起探索 HTTPS 在 2016 年的变化以及今后的发展可能。
15 |
16 |
17 | ## SSL 和 HTTPS 简介
18 |
19 | HTTPS 是加密了的 HTTP 协议，网址以 `https://` 开头，就代表是使用了这个协议。 HTTPS 相比 HTTP，拥有**全部的**以下特性：
20 |
21 | * **传输数据加密**：与网站之间的通讯无法被中间人（如无线路由器所有者、运营商、在之间线路上的监听者）获取。
22 | * **数据完整性**：保证所传输数据没有被篡改。
23 | * **身份验证**：保证数据是网站所有者提供，而不是第三者提供。
24 |
25 | 由于 HTTPS 要完成身份验证，所以若需要配置 HTTPS，就必须要取得被公认的证书颁发商颁发的证书。
26 |
27 | ## 2016 年
28 |
29 | ### Let's Encrypt，首个真正免费的证书颁发商
30 |
31 | 部署 HTTPS 必须要拥有 SSL 证书，而 SSL 证书的价格区间在每年几百甚至上万元不等，高昂的证书价格成为了部署 HTTPS 的一个重大负担。2015 年末，Let's Encrypt 正式开始公测，可以免费签发多域名的证书，此类证书原先的价格在百元到千元左右。即使是在测试阶段，仅仅 3 个月时间就签发了 100 多万张证书！ Let's Encrypt 的证书使用**自动化部署**，验证、签发过程均通过 API 自动实现，大大缩短了申请证书所需要的时间；同时各种服务提供商也纷纷提供了自动签发 Let's Encrypt 证书的渠道。由于 Let's Encrypt 的出现，确实大大加快了 HTTPS 的普及。
32 |
33 | ### HTTP/2，SPDY 的升级版
34 |
35 | 在 2015 年初，HTTP/2 正式成为标准，紧接着各大浏览器和操作系统纷纷支持：Firefox 36、Chrome 41、iOS 9 & macOS 10.11（Safari 9）、Windows 10（IE 11 & Edge）。紧接着，Cloudflare、CloudFront、UPYUN 这些 CDN 提供商也纷纷支持了 HTTP/2，HTTP 服务器 Nginx 和 Apache 也对其做了支持。 HTTP/2 的出现是为了取代 HTTP 1.1 和 SPDY。HTTP/2 主要是支持了**多路传输**，原本需要合并 CSS 和 JS 文件、为众多的图片准备多个域名的做法，使用了 HTTPS/2 之后就没什么必要了。相比 HTTP 1.1 的每一个数据需要单独的一个连接，HTTPS/2 中网站的所有数据只需要一个连接。
36 |
37 | 
38 |
39 | 由于浏览器会限制连接数量，这就会导致在 HTTP 1.1 中，每次只能同时下载几个文件。多路传输可以让这些文件一块儿传输，大大减少加载时间。
40 |
41 | 
42 |
43 | 
44 |
45 | 然而，这些浏览器里只是针对 HTTPS 站点做了 HTTP/2 的实现。于是想到让网站提高加载速度，又不得不用 HTTPS。所以，HTTP/2 的出现也推进了 HTTPS 的发展。
46 |
47 | ## 2017 年
48 |
49 | ### Google Chrome 放大招，对有无 HTTPS 的网站区别显示：
50 |
51 | 现在，Chrome 已经开始对使用了 HTTPS 的网站显示 “安全” 字样（EV 证书这个地方则显示企业名称）：
52 |
53 | 
58 |
59 | 你也可以在 [Chrome 设置页面](chrome://flags/#mark-non-secure-as)将其调整为 “一律将 HTTP 网页标为不安全”。我推荐所有人都这样设置，因为 HTTP 确实是毫无安全可言！ 相信没有公司愿意让用户看到自己的网站被标记为 “不安全” 吧？浏览器的推进起到至关重要的作用。
60 |
61 | #### 更新 1
62 |
63 | 在最新的 Chrome 58 版本里，非 HTTPS 的密码输入处已经显示这样的信息（此处为 weibo.com 的网站登陆窗口）：
64 |
65 | 
66 |
67 | 经测试，只要主站是 HTTP，即使表单是提交到 HTTPS 页面，也会显示此信息。
68 |
69 | ### Apple 强制要求使用 HTTPS 加密（ATS）
70 |
71 | 2015 年末的时候，苹果就开始实施 ATS，然而开发者仍能找到选项去关闭这个功能。而在 2017 年或之后某个时刻后（具体 deadline 苹果尚未明确给出，不过可以确定的是不开 ATS 审核会逐渐变严格，并要求提供更多的理由），所有新提交的 APP 必须开启 ATS，也就是说新提交的 APP 必须全部使用 HTTPS 内容了。这促使着众多国内厂商去做 HTTPS 支持。
72 |
73 | ## cPanel 虚拟主机自动获取免费 SSL 证书方法
74 |
75 | 本站特别推荐的虚拟主机提供商 [TlOxygen](https://domain.tloxygen.com/web-hosting/index.php?promo=ze3kr) 现在就支持申请免费 SSL 证书了。整个过程十分简单，并且会自动续签！实现方式：自动为虚拟主机安装 acme.sh 软件，然后自动执行安装流程。此外，[TlOxygen](https://domain.tloxygen.com/web-hosting/index.php?promo=ze3kr) 的虚拟主机支持 SSH 访问，所以你也可以自行使用 acme.sh 或者任何其他工具操作。
76 |
--------------------------------------------------------------------------------
/source/_posts/2017-04-08-free-server-monitors.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: 几个免费的服务器监控服务推荐
3 | tags:
4 | - VPS
5 | - 安全
6 | id: '2456'
7 | categories:
8 | - - 开发
9 | date: 2017-04-08 08:00:34
10 | languages:
11 | en-US: https://www.ze3kr.com/2017/04/free-server-monitors/
12 | ---
13 |
14 | 有了服务器监控服务，就能知道网站运行的情况以及在线时间。当服务器出现问题时，便能第一时间收到通知。个人网站运维需要这些服务来保证稳定性。但是，大量的此类服务都是面向企业，导致价格十分昂贵，而且并用不到其所提供的功能。本文就给各位站长推荐几个免费的服务器监控服务。
15 |
16 |
17 | ## 在线率（Uptime）监控服务
18 |
19 | ### StatusCake
20 |
21 | StatusCake 同时提供免费和付费的监控服务。免费版本可以创建无限多个 HTTP(s)、TCP、DNS、SMTP、SSH、Ping 和 Push 的协议监控，监控周期最短为 5 分钟，提醒主要支持 E-mail 和 Webhook 两种方式。免费版本不支持监控服务器配置信息，所以也无需在服务器上安装任何软件。
22 |
23 | 
24 |
25 | 此外，StatusCake 支持 Public Reporting，你可以利用 StatusCake 建立一个监控页面。它还支持将在线率图像及网页嵌入在你自己的网页中，十分方便。
26 |
27 | [注册地址](https://app.statuscake.com/Try/?Plan=FREE)
28 |
29 | ### UptimeRobot
30 |
31 | UptimeRobot 也提供免费的监控服务，支持 HTTP(s)、端口检测、Ping，监控周期最短为 5 分钟。同样不支持监控服务器配置信息，所以也无需在服务器上安装任何软件。最多只能创建 50 个监控，支持 E-mail 提醒。
32 |
33 | 
34 |
35 | 相比 StatusCake，它的监控功能要少，但是 Public Reporting 的页面要漂亮一些。由于 StatusCake 所多的那些功能个人站长也几乎用不到，所以 UptimeRobot 也是 StatusCake 的一个良好的替代。
36 |
37 | [注册地址](https://uptimerobot.com/signUp)
38 |
39 | ### 监控宝
40 |
41 | 监控宝是一家国内的监控服务，长期提供的免费版可以创建 6 个 HTTP(s)、Ping、DNS、FTP、TCP、UDP、SMTP 甚至是使用 SNMP 对服务器性能监控（需要软件），监控周期最短为 15 分钟。如果你需要检测国内到你的主机的速度，或者你的主机在国内，监控宝是一个不错的选择。它的免费监控是从中国内 3 个位置同时监控。它支持 E-mail 和**手机短信**告警。它不支持 Public Reporting，但是可以给分享网站的 SLA 证书。功能相当齐全，就是网站的界面设计比较欠缺。
42 |
43 | [注册地址](https://www.jiankongbao.com/new_signup)
44 |
45 | ## 服务器指标监控服务
46 |
47 | ### Stackdriver
48 |
49 | 最后，就要介绍我最近开始使用的强大的 Stackdriver。Stackdriver 是 Google Cloud Platform（下文简称 GCP）旗下的服务器监控服务，支持监控、调试、跟踪、日志。其中的 Uptime Check 支持 HTTP(s) 和 TCP，监控周期最短为 **1 分钟**。它支持 E-mail 、手机短信和 APP 内告警。它的 Uptime Check 是从全球 6 个地区同时监控，可以看到每一个地区的延迟。用来检测 CDN 的速度肯定会很不错。
50 |
51 | 
52 |
53 | 如果你正在使用 Google Compute Engine（下文简称 GCE） 或者其他 GCP 的服务，那么这个服务还可以帮你记录服务器日志，每月有 5 GB 额度，超出后每 $0.5/GB。此外，它还能进行服务器性能监控，监控服务器各项指标。虽然原本 GCE 面板也能提供 CPU 等信息，但是这个是需要在服务器上安装 Agent，于是就能提供更丰富更准确的信息。安装过程如下：
54 |
55 | ```
56 | curl -O https://repo.stackdriver.com/stack-install.sh
57 | sudo bash stack-install.sh --write-gcm
58 | curl -sSO https://dl.google.com/cloudagents/install-logging-agent.sh
59 | sudo bash install-logging-agent.sh # 谨慎安装，见下文
60 | ```
61 |
62 | 毕竟是 Google 自家的服务，安装不需要任何登陆等操作。安装完毕后就会自动采集数据。它分为两个部分，Stack Monitoring 用于监控服务器指标，包括硬盘存储空间、内存占用（包括 Used、Buffered）等 GCE 默认无法监控到的数据。还有就是 Logging，它可以自动同步日志到 Google 的云端，你可以集中的执行搜索等操作。然而 Logging 这个进程会大概占用 100M 内存，小内存实例谨慎使用。需要注意的是，**只有 Logging 是免费的，Monitoring 是收费的，每月 $8**。 然后，你还可以为某一项指标建立告警，比如我创建了一个当磁盘空间高于 90% 的时候给我发邮件。 它可以创建公开页面分享服务器指标和 Uptime Check 延迟的图标，但是却不能显示在线率，实在是一个奇怪的设计。
63 |
64 | ### Observium
65 |
66 | [Observium](http://observium.org/) 通过 snmp 可以用来监控服务器的各项指标，包括内存、储存、网卡等。它可以[免费安装](http://observium.org/wiki/Installation)在自己的服务器上，需要 MySQL 和 PHP 环境。官网给的是 Apache 的范例，如果你用 Nginx 就不需要安装 Apache。
67 |
68 | 
69 |
70 | 它通过在服务端生成 PNG 来显示图表，所以图表很漂亮精致，但是由于不是矢量图，所以很难做到实时增量更新而且不能精细看到某一个时刻的数值。 Observium 可以轻松的管理许多个服务器。你可以体验[在线 Demo](http://demo.observium.org)。
71 |
--------------------------------------------------------------------------------
/source/_posts/2018-12-07-wordpress-5-0-update.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: WordPress 5.0 更新现已发布，全新编辑器，全新主题
3 | tags:
4 | - WordPress
5 | id: '3651'
6 | categories:
7 | - 开发
8 | date: 2018-12-07 07:14:57
9 | languages:
10 | en-US: https://www.ze3kr.com/2018/12/wordpress-5-0-update/
11 | ---
12 |
13 | WordPress 5.0 正式版已于 2018-12-07 发布，自建 WordPress 用户可以在 WordPress 后台的 Web 管理页面中进行升级。本次更新的最明显的两个特点就是：1. 后台管理使用了全新的编辑器，2. 新增了 2019 年的主题，该主题适配这个全新的编辑器。
14 |
15 |
16 | 这次的 5.0 是一个大版本更新，而不像之前的 4.9、4.8 更新那样，这从版本号就可以看出。
17 |
18 | ## 编辑器
19 |
20 | 这个新的块编辑器（Gutenberg Editor）给人的第一感受就是更加简洁了，这个新的编辑器有着更大的留白。初次使用编辑器的时候会感觉有些不适应，这是因为新的编辑器中没有我们熟悉的工具条了。取而代之的是一个简单的添加块（Add Block）按钮和其他的一些基本操作。
21 |
22 | 在新版的编辑器中，每一个自然段、图片、副标题、引用等都是一个 “块”。你可以为每个块进行自定义操作，如为每个自然段设置不同的字体大小、字体颜色，甚至是背景色和自定义 CSS。而这一切都是通过右侧的 “组件” 工具可视化的实现的。
23 |
24 | 你可以直接拖移块，以实现拖移自然段等效果。
25 |
26 | ### 经典块（Classic Block）
27 |
28 | 新版编辑器兼容老板编辑器。要想使用老款的编辑模式，可以通过插入一个或多个经典块（Classic Block）来实现。这个经典块与新编辑器中的其他块（如自然段块、副标题块等）同等级别。经典块中能包含一个或多个自然段、副标题，对于简单的排版，它可以代替最新的块编辑器。在使用经典块时，你依然能够看到你所熟悉的工具条。
29 |
30 | 
31 |
32 | 经典块截图
33 |
34 | 在编辑以前发布的文章与页面时，默认依然使用原有的编辑模式，即在新的编辑器中包含**一个**经典块。
35 |
36 | ### 支持的原有的块
37 |
38 | 原有的块都是与 HTML 标签对应的，功能相对少一些。经典块用于兼容上一代编辑器。要想使用新特性，你需要学习使用这些新的块。
39 |
40 | * 自然段块（Paragraph）：对应原先的 `