网络与分布式2017arxiv.org
为什么连接 Wi-Fi 接入点要花这么长时间？
Why Does It Take So Long to Connect to a WiFi Access Point?
进阶 · 约 35 分钟读完前置知识：802.11 基础、无线网络测量、机器学习分类
导读
这篇论文研究 WiFi 连接建立过程为何耗时较长：作者测量了连接各阶段的时延，并通过相关性分析发现，除了信号强度外，知道 AP 型号和手机型号对预测连接建立耗时也很有帮助。基于此，他们提出一种机器学习驱动的 AP 选择策略，相比仅依据信号强度的传统策略，将连接失败率从 33% 降到 3.6%，并把连接建立的时间成本降低 10 倍以上。
HN 关注点：HN 读者对日常设备 WiFi 连接慢、失败原因不透明（如密码错误却只报“连接失败”）有强烈共鸣，同时讨论机器学习是否只是赶时髦、以及快速重连背后的 DHCP 机制。
HN 评论精选
这几条评论里：质疑 2 补充 2
质疑批评 802.11 连接失败缺乏明确的错误原因反馈，设备只能猜测失败缘由。
而且为什么没有像样的“密码错误”响应？在我看来，密码正确时连接就会成功，密码错误时连接就莫名其妙地失败，然后电脑还得自己猜是不是密码错了。事实上我有一次用 MacBook，它提示密码错误，但密码绝对是正确的。我猜是因为它们只能靠猜来推断失败原因。
IshKebab查看英文原文
And why is there no proper 'invalid password' response? It always seems to me like if you have the correct password the connection succeeds and if you have the wrong password the connection just mysteriously fails and the computer has to guess that maybe it was because the password was wrong? In fact I've had a Macbook tell me the password was wrong when it was definitely correct. I imagine it's because they have to guess the failure reason.
质疑质疑机器学习部分是跟风，认为严谨统计分析可得到更简洁的算法。
这项工作很棒，但我觉得机器学习部分只是为赶潮流硬塞进去的。更严谨的统计分析应该能得出更干净的算法，而不必依赖预训练分类器。
zwieback查看英文原文
This is great work but I think the machine learning part is just thrown in for trendiness reasons. More rigorous statistical analysis should lead to a cleaner algorithm without relying on pretrained classifiers.
补充补充资料：推荐关于睡眠唤醒后快速 DHCP 重连机制的解释文章。
这让我想起这篇解释 MacBook（以及其他设备）如何在睡眠唤醒后如此快速地重连 WiFi 的文章：http://cafbit.com/entry/rapid_dhcp_or_how_do
bfirsh查看英文原文
This reminded me of this explanation of how MacBooks (and presumably other devices) manage to reconnect to Wifi so quickly after waking from sleep: http://cafbit.com/entry/rapid_dhcp_or_how_do
补充引用论文摘要核心数据：失败率 33%→3.6%、耗时降 10 倍以上，并点出 AP 与设备型号的预测价值。
> 我们提出一种基于机器学习的 AP 选择策略，相比仅基于信号强度的传统策略，能显著提升 WiFi 连接建立性能，将连接建立失败率从 33% 降至 3.6%，并将连接建立过程 80% 的时间成本降低 10 倍以上。 > 相关性分析发现，虽然信号强度很重要，但知道 AP 型号和移动设备型号对预测连接建立的时间成本有很大帮助。 有意思！
dorianm查看英文原文
> we develop a machine learning based AP selection strategy that can > significantly improve WiFi connection set-up performance, against the > conventional strategy purely based on signal strength, by reducing the > connection set-up failures from 33% to 3.6% and reducing 80% time costs of the > connection set-up processes by more than 10 times. > The correlation analysis finds that though the signal strength is important, > knowing the AP model and mobile device model has great help to predict the > connection set-up time cost. Neat!
历次讨论
- 2017Hacker News 讨论帖218 分 · 60 评
同领域还值得读
Paxos vs. Raft：分布式共识是否已达成共识？
Paxos vs. Raft: Have we reached consensus on distributed consensus?
重新审视了 Paxos 与 Raft 两种分布式共识算法之间的差异，试图在一个统一的框架下比较它们，并论证二者的相似程度远高于通常的认知，许多所谓的差别只是表述层面的。
网络与分布式2020 · 343 分 · 65 评 · 引用 10进阶 · 约 28 分钟编辑精选Stellar 协议：互联网级共识的联邦模型
Stellar Protocol: A Federated Model for Internet-Level Consensus (2016)
提出 Stellar Consensus Protocol（SCP），一种面向互联网级共识的联邦拜占庭协议模型。
网络与分布式2018 · 301 分 · 61 评专业 · 约 90 分钟编辑精选拜占庭将军问题（1982）
The Byzantine Generals Problem (1982)
这篇 1982 年论文提出并形式化了拜占庭将军问题：在分布式系统中，部分节点可能叛变或故障、通信不可完全信任时，忠诚节点如何达成一致行动。
网络与分布式2018 · 290 分 · 77 评进阶 · 约 75 分钟编辑精选Google 变差了吗？对搜索引擎中 SEO 垃圾的纵向调查
Is Google Getting Worse? A Longitudinal Investigation of SEO Spam in Search
对搜索引擎结果中的 SEO 垃圾内容做了纵向追踪：作者团队在一段时间内持续采集 Google、Bing、DuckDuckGo 等引擎针对商品评测类查询的结果，用分类器识别联盟营销…
网络与分布式2024 · 276 分 · 274 评入门 · 约 45 分钟编辑精选使 CRDT 能够容忍拜占庭故障
Making CRDTs Byzantine Fault Tolerant
Martin Kleppmann 等人的论文研究如何让 CRDT（无冲突复制数据类型）抵御拜占庭故障节点，即部分参与者恶意篡改数据时仍能保证一致性。
网络与分布式2022 · 266 分 · 40 评进阶 · 约 90 分钟编辑精选