因为有人不知道 Netflix 可以开土区，也有人怕跨区被抓。

买卖双方都接受这个价钱就行。人家车主负责付款，还要想办法跨区购买，不应该多收点吗？原价多少是一回事，人家付出多少劳动是另一回事。就像瓶装水，能有多少生产成本？你花钱买的是运输成本。

如果你非得讨论这个的话，还有很多人本来就是免费获取的，那人家就不应该收钱？比如 T-Mobile 会送。又比如信用卡有报销。

1. 这不是推荐信，人家也不一定玩 LinkedIn 。特别是微软很多人是不会跳来跳去的，懒得去登入 LinkedIn 。
2. principal manager 不算啥大佬，都是中层管理，甚至基层管理。大家都是打工的而已。
3. 如果这是申请学校用的推荐信，还这么写的，一般是人家就不想给你写。但是惯例上推荐信又不好写坏话，所以瞎写一句了事。

@lysS 国外结婚不是以民政局登记为准。民政局登记只是一半，拿到一张 marriage license 。婚礼那天才是婚姻生效日。婚礼需要有证婚人，取决于州法规定，通常要求教会神父、法官、持证证婚人等主持婚礼。有些州还需要有旁观者观礼。

又说到买房，也是档案局有记录不是权威，也没有房产证（取决于州法，不一定有）。卖方需要提供证据证明产权，并购买 title insurance ，买方才愿意买。

国外的法规不同，仅此而已。

其实我觉得#17 描述的情况在往国外靠拢：
门诊治各种慢性病和非紧急疑难杂症，预约要十天半个月
urgent care 治各种不危及生命的急症
emergency room 抢救可能危及生命的情况

32+8 是混合双通道，其中 8+8 是双通道，剩下的 24 是单通道
Intel 好几年前就支持了，AMD 我记得近年也有了

没必要买这种杂牌 SATA 卡，买张洋垃圾 sas hba ，价格便宜性能稳定
sas 向下兼容 SATA ，买条一拖四的转换线就能用。这都是小钱。最多再加个风扇，更稳定。

还有，如果 API 不多的话可以用嵌套 location 。这样就不应反复写代理配置，每个 location 里再写一遍 limit 即可。

还有，你这 location 写的什么玩意？/api/这不就是固定匹配，用什么 regex ？（当然你按我上面说的话那还是得用 regex 去捕捉 api 名称）

5 楼的思路是对的。但是第一行忘了加入$binary_remote_addr ，结果就是整个 url 不论 IP 加在一起限速。也没有拆分前缀，往 uri 加额外字符就可以绕过了。要用的话你可以在 location 里用 regex match 然后用 named capture ，捕捉 url 的第一小节。

cf 代理可以用，cf 会设置 x-forwarded-for 和 client-ip ，用好 ngx_http_realip_module ，只信任来自 cloudflare 的 client ip 即可。

挂 cloudflare 是最简单可靠的办法。上 CDN 可能需要少量调试，但是应该不难。而且 cf 对小规模用户免费。
考虑到你说团队不懂 IT ，那很可能你们也没有设置浏览器缓存和使用压缩。它们可以减少很多流量。如果你们上 cf 的话 cf 可以帮你们做这些。如果你们不上 cf 的话可以请人帮忙调整这些设置。

如果你仍然需要大量流量的话，可以再和 azure 讨论批量价格。又或者可以使用欧洲机房的独立服务器。这些都是不限流量的。欧洲到美国的网络质量不差，速度可以接受。

@3dwelcome 你的智商只能两句话看懂一句话,看完一句忘一句吗？
你自己提议加上 hash ，那把 hash 加到 URI 里之后，这个 URI 是不是就是 immutable 的？难不成你同一个 hash 还能变？

和你讨论真是浪费生命。


而你现在发起讨论，但又过于偏执，浪费的不光是你的时间，还有别人有限的生命，而且还是浪费在抬杠上面。

@3dwelcome 你看到我说的 immutable 选项了吗？你喜欢你可以把你所有静态资源设置 immutable ，然后把你的 hash 直接嵌在 URI 里。这样每个 URI 确实就是 immutable 的。

楼上的实测结果你也是完全没看，你如果认为 immutable 解决不了你的问题，拿出实测数据便是。

你真是好大的口气，明明是有现成的解决办法，你非要把之前的标准推翻用你的新标准。
为什么标准变成了现在这样，这不是你能决定的问题。你一直在以“如果互联网让我设计”为前提。然而互联网从一开始就不是谁设计，谁规定的。ietf 也只是参考性的记录。实际上是几个开路人说，诶，咱们就这么办。然后用的人多了，事实上就形成了通行的标准。
HTTP 缓存，不管最初的设计如何，各大浏览器用了这个标准，各大 Web 服务器用了这个标准，那这个标准就是标准。

如果你觉得你的标准可以推翻现有的标准，talk is cheap 。你需要有可用的代码实现，然后写一篇论文来证明你的标准，然后可以提交 rfc 。good luck

@3dwelcome 1. “上面一句浏览器可以本地缓存比对，如果文件缓存里有，就不需要发一条 URL 请求去服务器。”这本就是浏览器的不正确实现。标准最初定义的是 max-age 过期前不必 revalidate 。但是由于各大浏览器都是这样实现，所以最终标准妥协了，变成了 max-age 前需要 revalidate 。

所以，后来加入了两个 cache-control 选项：
stale-while-revalidate ，浏览器立刻使用 cache ，但在后台 revalidate
immutable ，浏览器彻底相信 max-age ，max-age 前完全不 revalidate

如果你在 utctime/file.js 上使用这两个选项之一，就不会有你说的问题。

而且你还可以使用 immutable

*如果 你设置 max-age 为最长时间

@3dwelcome 1. CSS 的 URI 是不是 HTML 的一部分？
如何你设置 max-age 为最长时间，那么浏览器不需要再发请求 revalidate 。也就实现了你的目的。

你建议 script src='file.js' last-modifed-time='utctime
这和 script src='utctime/file.js'
有什么区别？

你还可以使用 stale-while-revalidate ，浏览器会立刻使用 cache ，即使 cache 已经过期。然后再在后台和服务器更新。

这不就是加 hash 吗？你绕了一圈还不是回来了。
服务器直接把你说的 last-modify 的 tag 加到 css 的 URI 里，你看你得到了什么？
比如 example.com/static/lastmodify_12345678/abc.css

Nginx 识别处理这种 URI 很容易

@hertzry 两者不矛盾。看书并不能教会你实操。学的算法工作中大部分情况用不到。学了计算机组成，调优还是得靠经验+瞎猜。
尽信书不如无书。

工作里别管为什么，能用就行，这才叫工程。你这样子要是学了工科不得爆炸？工科里经验公式经验常数太多了。反正也没人知道为什么。反正就是能用。

只要是人就一定会出错，靠自觉是没用的。生产环境的命令一定要 code review 。即使有 review 也不能保证安全，因为可能俩人都犯傻了。所以还要限速限量，然后规模从小到大，执行一批检查一遍。
这都是无数事故总结出来的经验。

@coderluan 问学得好的同学可能也没用，因为人家可能也不知道自己是怎么会的（囧）
有的人上大一才开始学 CS
有的人高中就学完了 CS 入门，大一就开始上大二才的课，大三直接开始找工作了。