" 低预算能买到的服务器带宽也都是 10Mbps 以内的，RDP 小带宽的体验仍然是很差的 "
---
为何不试试 RustDesk 的 relay 模式？

说个都没提到的点吧：每次发起下载请求前要获取有失效期限的 access token ，发起请求的过程中就可以对来源用户或 IP 做合法性校验（例如是不是重复请求该文件多次、是不是某个时间段内被异常大量的请求、IP 信誉或者 header 存在问题等等，甚至还可以在 js 侧增加 captcha 只有通过验证码的才可以继续执行请求 accees token 过程）

当然，这些可能需要你自己写 nginx 模块实现或者用 apisix 、kong 这类的可以容易实现插件的网关。

个别运营商确实会有某种屏蔽机制在使用。我用移动的 5G 访问不到美西的机器，联通就可以。

基本没见过这么大年纪的。以前有位 Intel 中国过来的最大年纪 40+的同事不知道突然去哪了

才发现有中文版，包含了 Moufiltr 示例，https://learn.microsoft.com/zh-cn/windows-hardware/drivers/hid/keyboard-and-mouse-hid-client-drivers

看了下文档 https://learn.microsoft.com/en-us/windows-hardware/drivers/hid/keyboard-and-mouse-hid-client-drivers
https://learn.microsoft.com/en-us/windows-hardware/drivers/hid/3rd-party-filter-drivers
https://learn.microsoft.com/en-us/previous-versions/ff542379(v=vs.85)

需要实现一个 MouFilter_IsrHook 回调函数，这个函数会在鼠标中断服务例程（ ISR ）被调用时被调用。
可以在这个函数中修改，例如，你可以让函数每隔一段时间只处理一次中断，而忽略其他的中断。这可以通过在函数中添加一个计时器，并在每次处理中断时重置计时器来实现。

理论上能实现，但是细节会很复杂。
但是我怀疑你这是 X-Y Problem 啊，话说你提到的 “一个 1000Hz 回报率的鼠标随便动动就能造成 20%的 CPU 使用率（ CPU：Core i7-7920HQ ” 你确定系统版本、厂商驱动什么的都很正常吗？或者其他什么原因？

CF 可以防御 3-7 层（ OSI 模型）上的 DDoS 攻击，无需人工干预，技术实力全球公认啊。在中国也不会差的，无非是价格问题了。

@Enzoliu CF 也清洗的，只是你通常见到的手段有个前置的人机验证环节（这步骤主要防 CC 攻击），让你觉得那么直接罢了。

没有贬损的意思，你确定二线城市的房价你能接/你愿意接？
我觉得，还是找个女朋友再定。有朋友在帝都工作把房子买到天津了，刚买 2 年就后悔了。
btw：现在接盘一二线城市的房产，35 岁失业了，换不起月供，岂不是芭比 Q 了么。

@hxndg “胡说八道的？恢复私钥？？”
你自己研究吧 https://www.instructables.com/Understanding-how-ECDSA-protects-your-data/#step14

@baobao1270 关于 4 ，你去了解下 Bluetooth 4.2 (LE Secure Connection) 就知道我的逻辑了。

Tor 目前没安全硬伤，有硬伤的是人，例如你在洋葱网络的黑市论坛注册了与 V2EX 上同样的 ID 昵称😂

以前用 Fabricator 协作过，所以都是 fabricator 上的 comments

以前有很多 Read it later 类的服务（部分支持离线阅读）。现在很少听到，怕啥因为需求太小众了？

对于 ECDH+AES 的方案，ECDH 可以用来生成一个共享密钥，然后使用 AES 进行数据的加密和解密。
这种方案的优点：ECDH 的密钥交换速度快，适合于需要频繁交换密钥的场景，而 AES 的加密和解密速度快，适合于需要大量加解密的场景。

ECDH+AES 的缺点：它需要两种不同的加密算法，这可能会增加系统的复杂性和实现难度。

关于对抗量子计算的攻破，已知道的是 ECC 在面对量子计算机的攻击时有概率会被破解。因为量子计算机的构建和实现还在初级阶段，重点是：目前还没有量子计算机能够实现大规模的量子比特控制和稳定性。
因此，如果一个大规模的量子计算机能够实现，并且能够破解 ECC ，那么 RSA 的破解也就不会远了 1 。
微软的研究团队正在研究如何使用量子计算机来破解 ECC ，他们发现，要破解 ECC ，需要的量子比特数量是 RSA 的 6 倍。

针对你提到的“看来各位对密码学都有一定的误解。建议去把 HPKE 的 RFC 仔仔细细读一遍”
我也给你找点反例吧：
1. 性能问题：每次连接都需要进行密钥交换，💡这会增加加密和解密的计算开销，特别是在资源受限的设备上，例如轻量级的物联网设备

2.安全性问题：尽管 X25519 算法在理论上是安全的，但在实际应用中可能存在一些问题。例如，如果在密钥交换过程中随机数值泄露，任何知道该随机数值的人都可以使用该随机数产生签名值恢复私钥。此外，如果同一个用户对两个不同的消息签名时，采用了相同的随机数，则任何人都可以通过两个签名值恢复出私钥。怎么实施保护性措施？
💡除非你假设 OP 一定会科学恰当的使用现代成熟的 TLS 方案。

3.兼容性问题：使用 X25519 算法的设备可能与使用其他加密算法的设备不兼容，这可能会限制它们的互操作性。💡除非你假设了 OP 无所谓自己的学习曲线、也无需考虑后续入方的接入成本。

如果愿意付费的话，inoreader 定制版功能有 [你与同事的每日邮件摘要] 的功能

假如 QPS < 100 ，加解密底层实现是基于 C/C++ 的，盲猜 2c4g 配置够用。