@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 入门，大一就开始上大二才的课，大三直接开始找工作了。

@jim9606 sriov 的 vf 之间是有 switch 的。但是可能需要在固件里配置。可以配置成虚拟 switch 或 vepa 等多种模式。如果是商业用的话比较多见 vepa ，因为要的就是隔离。

@mayli 一定要说的话还真有。rdma 。
但是 virtio 因为完全在内存里，再加上支持超大的 jumbo frame 支持，所以配置得当的话应该还是 virtio 好。前提是 jumbo frame 要开得够大。
软件处理虚拟网络的瓶颈一般在包。因为硬件支持 tso tro ，所以通过硬件走的开销可以相当于处理最大的 jumbo frame 。

处理速度的瓶颈不是复制 payload ，这个全看内存速度。难的是 header match 。用 CPU 去 hash 然后模拟 mac 表 /路由表，这就很耗 CPU 。但是对于硬件 switch 来说完全由专用电路实现。哪怕最便宜的 switch 都可以做到线速。

不懂的东西别瞎买。买你自己喜欢的就好了。车是拿来用的，不是开出去给人看的。为了充面子去买车那就真是纯傻了。

楼上说的大部分车型，我就算不贷款也可以买得起。但是我还是开我的本田，从毕业工作一直开到现在。我老板也是一辆福特了好几年。他一年的 bonus 应该都不止一辆了。

你又没玩过车（不懂），又没这个钱（没经验），除了出名的暴发户车型（知名度高），还能买出啥玩意？
强行贷款买车的事情找你女朋友打听一下就知道了。听完这个事情，你觉得老丈人会怎么想？

如果确实是你链接中的问题的话，可以尝试：
按照文章中的方法禁用 tso
两边都装 Windows

说实话 1G 这个带宽，禁用 tso 应该还是能跑得动的。

1. 加 -P 4 测试多线程性能
2. 检查 CPU 占用，特别是每个核心的占用，如果有单核打满的话可能是一些 offloading 没有启用。TCP 接收端的性能压力比较大。
3. 网线直连，手动设置 IP ，测试。排除交换机 /路由器问题。

@davidx 每年在内部网站上可以领。每 11 个月一个兑换码。
另外，内网商店买各种软件包括第一方游戏都是骨折价。

比起纠结这个，你更需要销售的日志。对库存表的每一个操作都应当有审计记录。这样就算碰到发错货或者无赖买家也有据可查。

@momocraft 表面上旁人无法利用，实际上可能被结合其他漏洞利用。比如不安全的 CA 。
不是必须有 poc 才叫 vulnerability 。
邮件保密可以，但是关闭 issue 之前应当说明理由。关闭之后应当及时私下 follow up 。

@hwdsl2 更好的办法是 grep -o ，同时 grep pattern 严格限制数字字符。这样可以最小化暴露面

@liuxu 感谢你的验证。我这么快就说作者有问题还有另一个原因：这里完全没有必要用 source 。

他已经有了 swan_ver_latest 。完全可以简单地 if [ "$swan_ver_latest" == "expected version" ]
如果想设置全局变量完全可以 export swan_ver_latest=$swan_ver_latest 或者类似物。
想缓存结果也可以直接存到文件，之后再从文件里读一下就完事了。反正 docker 里就这一个程序。一个变量存一个文件也无不可。

而且这查程序版本号这点小事，只要能用好缓存和静态化等功能，服务器上的负载微乎其微。以大多数人的程序流行度，还远不到需要担心服务器性能的程度。

在这脱裤子放屁写这三行，可以说纯粹就是为了用 source ，非蠢即坏。永远不要随便 eval 外部可以控制的数据，这应该是铁则。何况这个 eval 还毫无必要。

我提到 SQL 只是 SQL 注入问题比较常见。希望大家想到注入问题而已。对于 SQL parameterized queries 就是为了解决这个问题，而各大 SQL 软件的手册上都提醒：最简单的办法就是用好 parameterized queries ，别自己设计一套输入验证或者 escaping ，因为自己实现的防注入验证太容易有漏洞了。


@cweijan 为什么不应该批判一番？这些问题我在上学的时候就知道注意了。一个学生都写不出这样的 bug 。SRE 在谷歌是什么？简单来说就是运维。当然实际工作范围要比运维大一点。
换句话说，bash 对他应当是工作内容的一部分，是每天要用的东西。而类似的 bug ，是否还存在于他其他的代码里？如果存在，那他的同事在 code review 中是否指出过？还是说指出过，但他没有改？

好，谁不犯错呢？不小心写了个 bug 也没啥。但是人家都给你指出来了，直接关 issue 这是几个意思？自己往简历 /LinkedIn 上写的项目，用来找工作的项目，能不能上点心？

就像我上面所说：这是一个 G 家 SRE 应有的水平和态度吗？我很失望。

@learningman 这一行反而问题不大。os-release 是通用的系统版本配置文件。https://man7.org/linux/man-pages/man5/os-release.5.html
man page 里的例子就是这样直接 source 使用的

在正常的 Linux 发行版里，/etc/已经合理设置权限，只有 root 或 sudoer 才能修改。如果有人能修改 os-release ，那他何必费这个劲，直接修改 rc.local 或者 init script 还比较方便。