V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  ryd994  ›  全部回复第 41 页 / 共 496 页
回复总数  9910
1 ... 37  38  39  40  41  42  43  44  45  46 ... 496  
2022-01-25 17:35:44 +08:00
回复了 3dwelcome 创建的主题 前端开发 有没有人觉得 http 缓存设计的很不合理?
@3dwelcome 你看到我说的 immutable 选项了吗?你喜欢你可以把你所有静态资源设置 immutable ,然后把你的 hash 直接嵌在 URI 里。这样每个 URI 确实就是 immutable 的。

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

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

如果你觉得你的标准可以推翻现有的标准,talk is cheap 。你需要有可用的代码实现,然后写一篇论文来证明你的标准,然后可以提交 rfc 。good luck
2022-01-25 13:42:09 +08:00
回复了 3dwelcome 创建的主题 前端开发 有没有人觉得 http 缓存设计的很不合理?
@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 上使用这两个选项之一,就不会有你说的问题。
2022-01-25 10:22:54 +08:00
回复了 3dwelcome 创建的主题 前端开发 有没有人觉得 http 缓存设计的很不合理?
而且你还可以使用 immutable
2022-01-25 10:12:56 +08:00
回复了 3dwelcome 创建的主题 前端开发 有没有人觉得 http 缓存设计的很不合理?
*如果 你设置 max-age 为最长时间
2022-01-25 10:12:27 +08:00
回复了 3dwelcome 创建的主题 前端开发 有没有人觉得 http 缓存设计的很不合理?
@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 已经过期。然后再在后台和服务器更新。
2022-01-25 02:19:58 +08:00
回复了 3dwelcome 创建的主题 前端开发 有没有人觉得 http 缓存设计的很不合理?
这不就是加 hash 吗?你绕了一圈还不是回来了。
服务器直接把你说的 last-modify 的 tag 加到 css 的 URI 里,你看你得到了什么?
比如 example.com/static/lastmodify_12345678/abc.css

Nginx 识别处理这种 URI 很容易
2022-01-24 02:45:34 +08:00
回复了 foveal 创建的主题 程序员 说说我教女票编程的失败经历
@hertzry 两者不矛盾。看书并不能教会你实操。学的算法工作中大部分情况用不到。学了计算机组成,调优还是得靠经验+瞎猜。
尽信书不如无书。

工作里别管为什么,能用就行,这才叫工程。你这样子要是学了工科不得爆炸?工科里经验公式经验常数太多了。反正也没人知道为什么。反正就是能用。
2022-01-21 15:58:51 +08:00
回复了 moonchild 创建的主题 数据库 操作数据库 update 忘了加 where
只要是人就一定会出错,靠自觉是没用的。生产环境的命令一定要 code review 。即使有 review 也不能保证安全,因为可能俩人都犯傻了。所以还要限速限量,然后规模从小到大,执行一批检查一遍。
这都是无数事故总结出来的经验。
2022-01-20 14:43:58 +08:00
回复了 logiclee 创建的主题 问与答 迫于挂科压力,大一女生如何掌握学习编程的姿势
@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 应该都不止一辆了。

你又没玩过车(不懂),又没这个钱(没经验),除了出名的暴发户车型(知名度高),还能买出啥玩意?
强行贷款买车的事情找你女朋友打听一下就知道了。听完这个事情,你觉得老丈人会怎么想?
2022-01-07 18:12:13 +08:00
回复了 hhacker 创建的主题 宽带症候群 千兆局域网接收/传输速度不对等的问题
如果确实是你链接中的问题的话,可以尝试:
按照文章中的方法禁用 tso
两边都装 Windows

说实话 1G 这个带宽,禁用 tso 应该还是能跑得动的。
2022-01-07 07:51:45 +08:00
回复了 hhacker 创建的主题 宽带症候群 千兆局域网接收/传输速度不对等的问题
1. 加 -P 4 测试多线程性能
2. 检查 CPU 占用,特别是每个核心的占用,如果有单核打满的话可能是一些 offloading 没有启用。TCP 接收端的性能压力比较大。
3. 网线直连,手动设置 IP ,测试。排除交换机 /路由器问题。
2022-01-07 07:48:32 +08:00
回复了 ymyqwe 创建的主题 职场话题 苏州微软的一周年
@davidx 每年在内部网站上可以领。每 11 个月一个兑换码。
另外,内网商店买各种软件包括第一方游戏都是骨折价。
2022-01-06 03:41:23 +08:00
回复了 lipaa 创建的主题 程序员 讨论下 卡密下发 保证不重发 除了不用 redis 还有啥方案
比起纠结这个,你更需要销售的日志。对库存表的每一个操作都应当有审计记录。这样就算碰到发错货或者无赖买家也有据可查。
2022-01-04 10:02:33 +08:00
回复了 devliu1 创建的主题 GitHub 在 github 仓库 指出潜在的安全隐患后 被删 issue
@momocraft 表面上旁人无法利用,实际上可能被结合其他漏洞利用。比如不安全的 CA 。
不是必须有 poc 才叫 vulnerability 。
邮件保密可以,但是关闭 issue 之前应当说明理由。关闭之后应当及时私下 follow up 。
2022-01-04 10:00:07 +08:00
回复了 devliu1 创建的主题 GitHub 在 github 仓库 指出潜在的安全隐患后 被删 issue
@hwdsl2 更好的办法是 grep -o ,同时 grep pattern 严格限制数字字符。这样可以最小化暴露面
2022-01-04 04:47:07 +08:00
回复了 devliu1 创建的主题 GitHub 在 github 仓库 指出潜在的安全隐患后 被删 issue
@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 应有的水平和态度吗?我很失望。
2022-01-03 16:33:54 +08:00
回复了 devliu1 创建的主题 GitHub 在 github 仓库 指出潜在的安全隐患后 被删 issue
@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 还比较方便。
2022-01-03 16:19:32 +08:00
回复了 devliu1 创建的主题 GitHub 在 github 仓库 指出潜在的安全隐患后 被删 issue
swan_ver_latest=$(wget -t 3 -T 15 -qO- "$swan_ver_url")
printf '%s\n' "swan_ver_latest='$swan_ver_latest'" > "$swan_ver_file"
. "$swan_ver_file"

节选三行代码。相信稍有 bash 和或 sql 常识的人都该知道有什么问题。
统计信息可能涉及 gpdr 等 compliance 问题,但是比起上面的问题这已经是小问题了。考虑到 docker 的隔离,影响可能有限。但是如果用 host 网络或者小白瞎挂目录进容器的话就有问题了。总之,这是一个很明显的 bug ,在被人指出后还关 issue 是很不负责任的。

你能做什么?什么都做不了。因为开源软件的授权协议本来就包含了免责声明。作者对用户没有任何义务也不对任何使用的后果负责。你可以考虑 fork 然后修正此问题。这就是开源社区解决不负责任的开发者的方式:fork ,然后比他更负责。

看看 LinkedIn ,好歹也是个 PhD ,毕业后还在业界工作了好几年了。好歹也是谷歌的 sde ,还做过 sre 。G 家的 sre 就这水平?我很失望。
另一方面,LinkedIn 上写的还是 sde 而不是 senior 。PhD 起步,莫不是干了这么多年还没升到 senior ?同龄人应该很多是 principal 了吧?
1 ... 37  38  39  40  41  42  43  44  45  46 ... 496  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1009 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 53ms · UTC 20:21 · PVG 04:21 · LAX 12:21 · JFK 15:21
Developed with CodeLauncher
♥ Do have faith in what you're doing.