@jybox
#67 加存储的中间节点已经有人实现了，劫持用户请求然后跳转到缓存服务器。
然而缓存服务器上的缓存刷新有问题会导致比如说你请求的是新版软件，返回旧版软件。
而且中间节点如果作恶，你是没有办法监管或者防御的。

#68 能省一点就省一点是没错，现在互联网也是朝这个方向在走的。
你说要省掉中美之间的延迟，对，这个就是 CDN 的用武之地，和中间节点没有一毛钱的关系。
#69 里提到的 Google ，我可以告诉你，全世界没有什么地方是 Google CDN 覆盖不到的。
我就拿我手里的机器测一下到谷歌的速度好了。
俄罗斯 20ms
美东 18ms
美西 1ms
加拿大 22ms
立陶宛 25ms
日本 17ms
你给我举个不能覆盖的例子？大概只有南极科考站了吧。

你可能要提中国。不过中国也是有 Google CDN 的，只不过有关部门表示这是违禁的，不许开罢了。
所以就算你让中间节点去缓存 Google 的资源，结果也只是负责人去坐牢。

其实主要考虑的应该是 roundtrip 的开销吧。和 db 也好 cache 也好都关系不大。
http/2 的话大概也要看你 web server 对协议高级特性的支持程度？

@mhtt 随便按左或者右取消选区，然后 C+/ 直接能注释整行。

@winglight2016 光就是辐射。热也是。

@indexdotphp 不知道够不够用。反正我看了 1050 的价格，再看看当年买的 950 ，已经什么都不想说了。
内存当然是洋垃圾。
2LC ，感觉快绝版了。以后民用都是 3LC 了。（大概已经是了。）

DDR3 到 DDR4 的提升大概不到 5%。
不过买新电脑肯定是上 4 了。
亮机游戏卡看看新出的 1050 ？
ECC 并不那么重要，如果容量能满足需要的话。
通常我们选用 DDR3 ECC 内存主要是因为二手的买起来像不要钱似的。（差不多是$2/GB

TLC 有什么阴影？现在非 TLC 的是少数。

送上门的一般都不需要签。其他地方的不太好说。

我们定机票至少也要提前几个月定。
提前半个月能订到低价票简直是像中了彩票一样。
就说这月初定的机票，只有某一天有一个 600 多的，其他日子都是 1000+，最低也要 800+。
这种正好订到的叫是运气好。

其实并没有办法。任何你程序能读到的信息，全世界人都能读到。

只是简单点还是难点的问题。

这两个结果不都是 123456.789e4 吗？

@lslqtz 互联网正常的中间节点都是交换机路由器。
带大块硬盘的所谓「能缓存资源的中间节点」反而是个少见的东西。

@jybox 中间人攻击的前提是「攻击」。
CDN 本身就应该是用户配置的。
用户配置上私钥的话，中间人缓存是能做到的。
就算不配置私钥，也可以通过两段式加密解决。

至于路由和代理缓存……
对，这才是「中间人攻击」。
HTTPS 就是为了防止这些中间路由和代理窃听数据的。
（我从网站上下载的小黄图，凭什么要给你路由和代理看？
（我下载某某银行的安全控件，凭什么要让移动电信知道？

我猜想你这么说的原因是你认为：
1. 网站管理员不应该负有配置 CDN 的义务；
2. CDN 缓存应该由运营商或者中间路由、代理来做，而且是自动地，和站长无关地做；
3. 静态数据的地址泄露不会影响用户安全。

然而这几种观点和现在互联网上的主流观点是相悖的。

刚刚看到你主题里提到的 Linux 的 GPG 问题。
这你的理解就完全错了。 Linux 的 GPG 根本不是为了解决 HTTPS->HTTP 问题的。
Linux 的 GPG 签名是打包人签名，目的是防止文件在服务器硬盘上被篡改，而不是网络传输过程中被篡改。
和这种机制类似的有代码签名，目的也是防止二进制文件在硬盘上或者安装包里被篡改。
也就是说，他们是没有办法去应用到「网站」上的，因为网站上的文件并不是整个由站长来生成的。

@jybox
「 HTTPS 的中间节点（代理）连 URL 都读不到呀 」
「 SSL 不会对缓存带来问题 中间节点只要有证书便可以轻松实现缓存」

人家都告诉你了还要坚持己见？

@taozhijiangscu 保证在编译阶段把机器搞挂，让阁下免受折磨之苦（ x

Windows SmartGit 用户路过。

@yinmin 多域名证书可以考虑 Let's Encrypt 。

@gushengren 可以播放 != 可以转码。
（当然你这也不是在转码而是在重新封装。）

@1stlulu h264+aac ，目测是可以的。

@Heinz 弄点五毛？

GPU 擅长的是提前载入大量固定数据，然后每秒对这些数据做相同的运算，最后输出到屏幕上。
所以不能用显卡的原因：
1. 你没法提前导入大量数据到显存。
2. 你对一份数据做几百次相同的运算无意义。
3. 你运算的结果不会放到屏幕上。