V2EX = way to explore
V2EX 是一个关于分享和探索的地方
Sign Up Now
For Existing Member  Sign In
V2EX  ›  jinliming2  ›  全部回复第 2 页 / 共 60 页
回复总数  1188
1  2  3  4  5  6  7  8  9  10 ... 60  
2025 年 4 月 13 日
回复了 SpaceTimee 创建的主题 程序员 Github 主动屏蔽事件全记录及其绕过
「不屏蔽首次请求,但首次请求之后会屏蔽一段时间的后续请求」
感觉和 GFW 刚开始屏蔽 Google 的行为很像。。。
检查了一下证书,貌似也不是某些可信的 CA 「误签发」了证书做测试。。
https://i.imgur.com/fiopSJD.png
2025 年 4 月 6 日
回复了 xiaoluobo58 创建的主题 Linux 关于 Linux 下动态 PWM 风扇调速
@biglion666 #6 #8 TLP intentionally excludes some settings from the project, notably Fan speed control and Backlight.
写个脚本自动定时 commit --amend 并 push 。
一部分写完,就手动 commit 一次。
后续定时脚本 commit --amend 的时候就会追加到新的 commit 里去。
版本控制也有了,commit 历史也挺清楚。
建议 TRACE 一下规则,看看匹配的对不对
prerouting 链,匹配 TCP/UDP 的源地址是容器的网段,转发到旁路由
2025 年 2 月 23 日
回复了 EndlessJY 创建的主题 程序员 [有偿求助] 频繁出现 499 状态码 求运维大佬!
有确认单个复现用户的日志吗?
因为有些请求是客户端重复操作,后一个请求发起时主动中断了前一个请求,对实际用户来说可能没感知,对服务端来说就是一个请求在没来得及发响应的时候就中断了,报个异常日志。
如果是这个情况的话,那么现象通常是出现中断异常后同一个客户端会在几毫秒内再次发起请求,请求的资源相同,参数可能相同也可能近似(取决于服务类型),出现的次数一般同一个用户不会在一秒内连续出现多次。

回到楼主的问题,加上截图的日志,感觉像是客户端重复请求这个 Progress 接口,有点符合我说的这个特征?
排查的话,可能针对复现的单个用户,跟踪复现时间点前后一段时间的日志,看看特征。
@GuoJikun 其实不用删 fork ,只要迁一个新分支出来,reset 到原仓库的提交,然后把要 PR 的改动 cherry pick 过来就行。
不过最简单的还是在一开始就在新分支开发,原分支仅用于跟踪远程,还可以随时把原仓库的更新 merge 到自己的分支上。
2025 年 2 月 6 日
回复了 yxmyxmyyy 创建的主题 DNS oppo 一加现在也内置 114dns 了
@bclerdx #16 在手机内置 DNS 改不了的情况下,Wi-Fi 可以在路由器上直接拦截指定 IP 、重定向到其他 DNS 服务。
流量怎么劫持到路由器上?
2025 年 2 月 5 日
回复了 yxmyxmyyy 创建的主题 DNS oppo 一加现在也内置 114dns 了
@chairuosen #13 路由器只能劫持 Wi-Fi 的,流量就没办法了
2025 年 2 月 1 日
回复了 kleos 创建的主题 信息安全 来自 ipv6 only 的神秘问题,收到无法解析地址的流量
看着貌似 5.180.253.215 的端口一直是 28000 不变,而 37.114.49.176 的端口一直在变。
sudo lsof -Pi | grep 28000
看看呢?看看本地是不是有这么个进程?
2025 年 2 月 1 日
回复了 xhwdy26 创建的主题 程序员 手机 APP 怎么做到动态切换域名?
用户的网络情况可能是很复杂的,即便是在没有防火墙的国家,也可能会遇到比如连接了需要登录的 Wi-Fi 之类的情况,所有域名解析都会被拦截并跳转到 Wi-Fi 登录页面,所以 ping 、tcp ping 、普通 http 请求都是不可靠的。

所以 #12/#14 正解,但是服务器竞速比较常用的方法是提供一个 http 的 /generate_204 接口(/generate_204 属于事实上的标准,虽然没有定义标准,但大部分网站选择遵守),这个接口没有任何逻辑,仅返回 HTTP 状态码 204 ,且没有 body 。业务需要判断接口返回的状态码是 204 而非其他。
在 /generate_204 正常返回之前,都属于网络未连接的状态,应当以一定时间间隔(通常时间间隔越来越大)重试,直到最先返回的就是最快的。后续定期检查更新网络状态。
2025 年 2 月 1 日
回复了 scienhub 创建的主题 程序员 腾讯云的 nodejs sdk 安装后 85M
@scienhub #26 文档的话,简单看了下他们的 TSDocs 貌似挺详细的?每个字段、函数的含义都有说明,在编辑器里鼠标移上去应该都有文档提示?
也有工具能够根据 TSDocs 生成统一文档站的。
2025 年 2 月 1 日
回复了 scienhub 创建的主题 程序员 腾讯云的 nodejs sdk 安装后 85M
然后,楼主的运行方法,tsc 只是把 ts 转成 js ,还是会依赖 node_modules 的。
按需打包的话,相当于仅保留用到的代码,带上 tree shaking ,最终你用到多少代码就得到多少代码,还会去掉注释,这样 TSDoc 就都没了,最终产物不会很大。
2025 年 2 月 1 日
回复了 scienhub 创建的主题 程序员 腾讯云的 nodejs sdk 安装后 85M
好奇去看了下,src 目录和 tencentcloud 目录是大头。
src 下是 ts 源码,tencentcloud 下是编译过给 Node.JS 用的 CommonJS 代码。
然后里面主要内容在 services 里,有各种服务,平均 100k 左右,整个合起来就那么大。
然后 services 里面具体的有的会带日期命名的多个版本,应该是对应给不同版本的服务用的?如果确实不同版本同时有人用的话,那保留多个版本也还算合理?虽然更常见的做法是拆分不同版本的包,但是对于这种云服务 SDK 来说,我觉得放在一起问题不大。
然后里面最大的文件大部分都是 models 文件,是数据类型字段定义。然后大头是字段的 TSDoc 文档注释。

然后 CHANGELOG 有 5M 大小,内容大头是 commit history 。

src 和 tencentcloud 同时提供我觉得没什么问题,有些人倾向于直接 Node.JS require 使用,就用 tencentcloud 下的 CommonJS ,而有些人倾向于按需打包,用 src 会好一些(用 CommonJS 也不是不行,但 ts 源码更好)。
不过他们 src 下的导出方法有点问题,有多个版本的时候是 import 两个版本,然后 export 一个对象包含两个版本的 key ,这导致按需引用会出问题,总是会把所有版本都导入。
examples 和 tests 目录不算大,大部分库也会带着提供,提供不提供都行的。一般闭源的库会提供,开源的库你可以在项目托管的地方找到,就没必要提供。
CHANGELOG 也是大部分项目都会提供的,但开源的也确实同样没必要。
1  2  3  4  5  6  7  8  9  10 ... 60  
About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Solana   ·   3746 Online   Highest 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 47ms · UTC 05:04 · PVG 13:04 · LAX 22:04 · JFK 01:04
♥ Do have faith in what you're doing.