坦诚地讲，这个问题题主如果开出悬赏，有解的可能性比较大。否则即使是爱好者很可能也懒得花时间在这上面。

看看有没有又有技术、又感兴趣、又有闲情的大牛上吧。

✅ 避免预设立场的提问
✅ 避免反问式回答
✅ 关注问题本身与解决问题本身

大家都好好说话。

我想说的是，**无论是否超售，都应该是无法简单地通过 free 来判断的。**
市场上的虚拟化架构，hypervisor 声明了多少内存空间，虚拟机里面就会显示多少内存空间。即使宿主机只有 2G，也可以让 hypervisor 声明出一个 64G 内存的虚拟环境出来。操作系统本身没有可靠途径检测“实际可用”的内存大小（非得要检测的话那就是跑实际的 memtest 了）。只不过当虚拟机操作系统开始申请超过实际剩余的空间时，底层会给出报错罢了。反映到操作系统，就是 mem alloc 被拒绝了同时产生 OOM。

把虚拟机的内存分配请求重新映射到物理内存中也是 hypervisor 的作用之一。

我上面没把各个层说得很具体，是因为这里的“层”实在太多了，比如：

系统通电之后，是内存控制芯片对内存相关信息进行检测（存在欺骗的可能）；
系统引导最初，是 BIOS 最先检测内存大小，在检测之前，BIOS 是运行于 ROM 的，并没有 RAM 给它用。所谓的检测，也就是“问一下”内存控制器而已（存在欺骗的可能+1 ）；
引导之后，BIOS 会做一系列的预留与分配，以便把实模式的真实地址映射为操作系统可用的地址，同时保留一部分供硬件使用的区域（存在欺骗的可能+2 ）；
操作系统引导之后，一般操作系统内核也会检测内存大小。检测方式为“问一句 BIOS ”（存在欺骗的可能+3 ）；
执行 free 时，我记得 free 应该是从内核直接读取的内存大小，反映在 shell 中，就是 /proc 里的东西（存在欺骗的可能+4 ）；
（希望有了解底层原理的人帮忙勘误）

看见了吧。云厂商想超售，有无数种方法让你感觉不出来，根本不用明目张胆地用 512M 内存“骗”你。这么骗，简直就是欺负用户智商低下。

我打这段话是对上面回复的同学们的回复。楼主你还是去问问客服吧。

原来好多人都是不用所谓的“进程管理”软件不舒服斯基的主……

公开发行的话，systemctl、sysv-init 走起。
公司批量的话，supervisord 这种老牌的走起。
个人的话，while true; do your_golang_app; sleep 1; done 一把梭-_-😂

我的，无论怎么挣扎，它自己从来不会主动掉，脱毛衣的时候一定掉。
LZ 大可不必担心。我遇到很多人的“掉”是指自己把一只或者两只搞得找不到了（丢三落四），而不是戴在耳朵上突然就发现没了。

@0312birdzhang 我个人会尽量避免自带假设或者预设立场的提问，这对于获得知识并不好。且因为这篇帖子已经预设立场了，所以我只是就事论事讨论这个注释的问题。至于发生这个现象的具体原因，我应该是清楚的（源码级的那种清楚），但 who cares，毕竟这不是这篇帖子提出的问题。

LZ 可以把事情与现象描述具体一点的。
也请做交叉对照实验，比如把下面的 block 移到上面去，把 80/81 端口做个交换，把注释做个交换……再把结论发出来。
先别急着下结论，研究深入一点，最终应该是会对 nginx 的配置、默认值、优先级有一个更深刻的认识。

另附 nginx 关于注释的处理逻辑与函数：
https://github.com/nginx/nginx/blob/34a8b4506a/src/core/ngx_conf_file.c#L692
https://github.com/nginx/nginx/blob/34a8b4506a/src/core/ngx_conf_file.c#L158

配置文件中的以#开头的注释被彻底跳过了，跳过的逻辑：
https://github.com/nginx/nginx/blob/34a8b4506a/src/core/ngx_conf_file.c#L615-L625

没想到大家讨论这么热烈，但是发现存在一个普遍的认识误区：就是把“ end2end 的加密”与“是否可能被 MITM 或第三者解密”做了强关联。还是苹果的宣传牛逼。

我觉得这个问题得从原理上来讲，因为“ end2end 加密”其实只是一个商业宣传术语，而不是一个严格的算法描述。所以纠结这个是没有意义的。

稍微具体一点来说吧。

iMessage 的消息是否只能被两个手机解密，完全取决于 Apple 的具体密钥与交换算法实现。

对于大多数常见的非对称算法，比如 rsa 等：
假如是手机本地生成了自己的 private key 与 publickey，然后相互把这个 publickey 扔给对方，把 privatekey 留在本地。那这种实现方式目前是在数学上被证明安全的。除非有 privatekey，否则第三方无法解密（毕竟还没有人解出 P=NP 不是？）

但是！（老师教了要怎么抓重点吧？）

苹果的 iMessage 实现非常复杂，因为需要多终端解密。那么，可以完全确认的是，苹果的服务器是持有密钥的。

继续从“持有密钥”说下去：

它虽然“持有密钥”，但这个密钥本身也有可能是被加密存储的，并且我倾向于，苹果也是把密钥本身加密存储的（毕竟明文存储用户密钥这种事太沙雕了，和 csdn 有啥两样？）

下面继续解释，为什么 Apple 能支持多终端解密。从上面描述可知，这个问题的关键点就落在了：如何把服务器存储的“被加密”的密钥安全传递到另一个终端上。
还记得在新的苹果设备上登陆 icloud 的过程吗？它必须要用户输入 icloud 密码。那么，假设苹果使用用户的密码作为私钥加密解密那个密钥，那么第三个设备也就拥有用户的 iMessage 私钥了。
整个过程，苹果对用户的私钥内容都一无所知。对用户的密码也一无所知。

这就是苹果声称的“端到端”。实际上这个过程可能比上面要复杂得多，但总的原理都是差不多的。
从这个过程可以看到，即使苹果持有了用户的各种密钥信息，也是可以声称“端到端”的。因为苹果只能看到一堆乱码，MITM 攻击是不可能的，这也是所谓的端到端。

但我想自己杠一下自己：假如苹果想做到能够配合权力机关调查信息，怎么办比较好。

1. 在任何一个交换环节中存着用户的私钥就行了。so easy。但是老爷子的棺材板板可能按不住。

2. 算法上给用户使用被 master 密钥信任的子密钥。由相关单位生成 master 密钥，苹果不持有 master 密钥无法解密内容（责任被撇的干干净净）。用户通过 master 公钥生成子密钥子公钥，加密的内容都是能够被 master 密钥解密的。

3. 还有一些更“优”的针对密钥自身的加密算法，比如 Shamirs Secret Sharing 算法。
https://en.m.wikipedia.org/wiki/Shamir%27s_Secret_Sharing
为什么说更“优”呢？因为它允许对于同一个加密场景同时产生 N 个不同的密钥，要求至少提供 N 个密钥里的任意 M 个，才能够对数据进行解密。好比你的保险柜有 10 把不同的钥匙，你把这些钥匙分发给了 10 个不同的人，然后只有这 10 个人里的至少 X 个人拿出钥匙，才能打开保险箱。
这种场景下，你拿一个密钥，某单位拿一个密钥。你用你的，他用他的。完美。苹果压根懒得解密也无法解密你的数据
或者，你拿一个，苹果拿一个，某单位拿一个，生成密钥的时候设置为至少两个密钥才能解密。更完美：设备上，你和 Apple 共同解密；你喝茶的时候，某单位和你的设备共同解密；你砸了设备的时候，某单位和苹果共同解密。
谁都无法自己单方面解密，然后苹果淡定表示：我们根本无法解密用户数据，第三方也无法单独解密用户数据。完美！

这么说吧，如果你说的端到端是指只有你和对方的设备上能解密，那这是不可能的。

不是实现问题、不是算法问题，更不是技术问题，也不以苹果的意志为转移。

别说 iMessage 这种云服务，连境内合法销售的个人电脑、平板、手机上的 TPM/加密芯片硬件都必须是国内指定的公司生产的，这可是可信计算的基石，NTZ TPM 了解一下？ www.nationz.com.cn
微软的 BitLocker 和苹果的 FileVault 都是军工级别的加密对吧？这些 xxx 位的加密确实是军工级别的不假，但是生成与保管密钥的底层硬件都是这些公司的哦～

你是不是听说美帝解锁不了 iPhone 手机？觉得 iPhone 安全措施牛逼？但是严格按照法规来讲，非国行的里有些硬件是不合法的哦～

我们有非常多的法规和条例对 IDC 进行数据披露方面的规范，比如：
http://www.oscca.gov.cn/sca/xxgk/1999-10/07/content_1002578.shtml

如果 lz 是做过与 IDC 相关、平台相关的工作就非常清楚了，在法律框架下配合并提供数据给执法机构，并不是可选项，而是强制硬性规定的哦。

留意一下，咱们是就事论事。我上面只陈述事实（我觉得对于从业者来说应该是共识了），勿断章取义过分解读哈～

抱歉虽然没回答 iMessage 的问题，但这个细节问题我个人觉得不那么重要了：）

@lijixi 说来惭愧，还真没具体研究过他们家 wol。从睡眠唤醒肯定没问题，节能里就有选项。从关机唤醒还真是没留意到。倒是第一次听到 Apple 的产品带了 IPMI 的，毕竟得靠一套独立于 OS 的专用硬件。

medium 现在已经有点人人喊打的意思了，最近一年看到了非常多的“为什么不要用 medium ”之类的文章。

比如上下俩超级大的固定区域，占了大量内容区；比如内容之外的元素越来越多；比如看个文章总是被 register 打扰；老是侵入性地推荐他们的会员等等。

根据我的经验，虽然他们的电话客服听起来感觉啥都不懂，但是他们的案例和解决方案够全，你一步一步按照他们的说法来，基本上能解决。
——除了一言不合让你恢复出厂设置比较蛋疼，我都是偷偷跳过这个步骤。

买阿婆的产品就要有做甲方的意识。直接一个电话怼着他们问就是了，不用来这云售后！哈哈😄……

楼上说的都用过。
一圈下来还是 ESXi 最省心，省心的同时还最强大，强大的同时还是业界标准，在无数大型数据中心考验过的，vmware 把它的可靠性和性能都优化到骨髓了。关键是，个人非集群环境使用还免费，单机环境下关键功能一个不少。

相比之下，我不知道 unraid 之类的这种套个 kvm 用开源驱动的玩意儿怎么还好意思收钱……

已经 star，这个必须要支持！扫了一眼代码，卤煮基本上把 bashshell 用得炉火纯青了。
建议重新发个，标题得用 “ bashshell 版本快鸟 balabala ”。

之前的版本要么是闭源的，要么是 wine 的，要么是 python 的，那个啥 fastdick 就是 python 的。
你这个更进一层楼，有 bashshell 就好使。我看了下，基本上也就用了 linux 各大发行版默认安装的工具命令。