哦确实在攻击者登陆时的验证问题没得到合理解释，截图也应该是拿不到验证码弹窗的

双重认证就是通过可信设备/渠道进行认证，你这设备用于在应用中登陆 apple id ，本身就是可信设备了，自然不需要其他设备或渠道进行认证。

当年在直营店走 AC+修过碎屏的 XSM 阿联酋版，直营店说没同型号备件，指引我到附近一家授权售后走旅行者计划换的屏，最后也说系统原因没实际收费。

非常有价值的发现…

小老弟

没做过 iOS 开发，但我观察 iOS 后台下载似乎是限速的

@Livid 感谢
@cnbatch Rx Overflow 发生在交换设备的高速端口处，按理说只要交换机和端口上游（即 NAS 的网卡和系统）支持并启用（我使用的 ESXi 虚拟化方案和 CX4 网卡，应该都默认启用了），就可以暂停这条链路上的发送了。

启用后确实遏制了万兆口处 Rx Overflow 的进一步增长，但对速度的提升效果没预期那么好。有可能这个时候卡点变成了 AP 的无线链路本身，这里的 Flow Control 行为我就不太能控制了，Unifi App 里自己的 Flow Control 设置似乎是针对它家交换机的。

而且 802.3x 还有另外的副作用，就是会无差别暂停掉整个链路的发送，在多设备重负载场景下对链路稳定性有负面影响。这个特性行为简单，应该是用来减缓一些没有流控和完整性保证能力的简单协议的丢包的。像 TCP 这种传输层协议，最好还是传输层自己做流控的保证，选用合适的拥塞控制算法。

可能是 hairpin nat 配置不正确的问题

我在思考这个贴是不是应该移动到宽带症候群…
@Livid 合适的话 麻烦帮忙移动下

@titanium98118 亲测是不能完全解决的，问题的核心在发送方做合理的拥塞控制。更换 BBR 后我尝试关闭了链路层流控，此时也不会再大量出现 RX Overflow 的现象。也有可能是我链路上某些设备未能正确配置，但排查起来成本太高，不打算细究了。

单槽半高 没啥卡可选

节哀

问问那些做取证的公司吧，没有漏洞可利用的情况下想保留数据解锁是非常困难的

办卡早点去 小心排不到

至今理解不了 CentOS 和 RHEL 好在哪

我喜欢看 因为会有实时反馈 表情的信息量是很大的

EPYC Rome 的垃圾捡一套就行了 非常便宜

*像场