你刚搬进新公寓，第一时间就把千兆宽带装好了。路由器就摆在客厅正中央，手机显示WiFi信号满格——五格全满，那种让人心安的绿色。你满怀期待地打开测速软件，准备迎接飞一般的网速。 结果：下载速度12Mbps。 不是120Mbps，不是500Mbps，是12Mbps。你检查了宽带套餐，确认确实是千兆；你重启了路由器，问题依旧；你甚至把路由器抱到手机旁边测，速度也没提升多少。信号明明满格，为什么网速却像回到了拨号时代？ 这个问题的答案，藏在你从未关注过的无线协议底层。WiFi信号强度只是冰山一角，真正决定网速的是水面之下的庞然大物。 信号强度≠可用带宽：RSSI和SNR的区别 当你看到手机上的WiFi信号满格时，显示的是RSSI（Received Signal Strength Indicator，接收信号强度指示）。RSSI测量的是你的设备"听到"路由器喊话的音量。 但音量大不代表听得清。 想象你在一场嘈杂的音乐节上，朋友就在你旁边大喊，声音确实很大——但你可能还是听不清他在说什么，因为周围的噪音太强了。WiFi同理：路由器的信号强度可能很高，但如果周围的"噪音"（干扰）也很强，数据传输照样会出问题。 这就是SNR（Signal-to-Noise Ratio，信噪比）的概念。SNR = 信号强度 - 噪声底噪，单位是dB。 SNR如何影响你的网速？ WiFi使用QAM（正交幅度调制）来传输数据。不同的QAM阶数对应不同的数据密度，但对SNR的要求也不同： 调制方式 编码率 所需SNR 每符号比特数 BPSK 1/2 ~5 dB 1 QPSK 3/4 ~13 dB 2 16-QAM 3/4 ~19 dB 4 64-QAM 5/6 ~27 dB 6 256-QAM 5/6 ~32 dB 8 1024-QAM 5/6 ~35 dB 10 你的手机可能显示"连接速度866Mbps"（这是256-QAM、80MHz信道、2×2 MIMO的理论PHY速率），但如果实际SNR只有15dB，系统会自动降级到16-QAM，实际PHY速率可能只有一百多Mbps。 更糟糕的是：路由器显示的"连接速度"往往是峰值PHY速率，不是你当前的实时速率。 它就像汽车仪表盘上的"最高时速280km/h"，但你在堵车的市区实际只能开30km/h。 CSMA/CA：WiFi的"先听后说"困境 有线以太网使用CSMA/CD（载波侦听多路访问/冲突检测），设备边发边听，一旦检测到冲突就停止并重发。但WiFi做不到这一点——无线设备不能同时发送和接收，所以WiFi使用CSMA/CA（载波侦听多路访问/冲突避免）。 CSMA/CA的工作流程是这样的： 设备想发送数据，先侦听信道是否空闲 如果信道空闲持续DIFS时间（分布式帧间间隔），设备可以开始发送 如果信道忙碌，设备进入退避流程：随机选择一个退避时间，倒计时结束后再尝试 问题在于：WiFi是一个共享媒介。 同一信道上的所有设备——你家的路由器、邻居家的路由器、你手机、你平板、你电视、邻居家的所有设备——都在竞争同一个信道的使用权。这就像一群人在一个房间里开会，每个人说话前都要先确认没人正在说话，然后随机等待一段时间再开口。 当设备数量增加时，冲突概率急剧上升。每次冲突后，设备的竞争窗口（CW）会翻倍： 第一次冲突：CW = CWmin 第二次冲突：CW = 2 × CWmin 第三次冲突：CW = 4 × CWmin … 直到达到CWmax 对于802.11a/g/n/ac，默认CWmin=15，CWmax=1023。这意味着一个设备在最坏情况下可能需要等待1023个时隙才能尝试发送。每个时隙虽然只有9μs（802.11a/g/n/ac）或20μs（802.11b），但在高竞争环境下，这种等待会累积成显著的延迟。 ...

2017年元旦凌晨，Cloudflare的DNS服务突然开始大面积失败。用户访问使用CNAME记录的网站时，DNS解析直接报错。工程师们紧急排查后发现，罪魁祸首竟然是一秒钟——一个闰秒。 这不是什么边缘案例。2012年6月30日的闰秒让Reddit、Mozilla、LinkedIn等大量网站同时瘫痪。时间，这个看似简单的概念，在计算机系统中布满了陷阱。 那些你以为是真理的错误认知 Noah Sussman在2012年整理了一份清单，标题就叫《程序员对时间的错误认知》。这份清单后来被不断补充，至今仍是开发者必读。 “一天有24小时”——错。在夏令时结束那天，一天可能有25小时；夏令时开始那天，一天可能只有23小时。 “时间总是向前流动”——错。这正是Cloudflare事故的根因。Go语言的time.Now()不保证单调性，当闰秒插入导致系统时间回退，计算出的往返时间变成了负数，最终触发panic。 “UTC偏移量在-12到+12之间”——错。实际上范围是-12到+14。太平洋上的一些岛国为了和澳大利亚做生意，硬生生把自己的时区设到了UTC+13和UTC+14。这意味着国际日期变更线变得极度曲折。 “每个时区对应唯一的UTC偏移量”——错。印度是UTC+5:30，尼泊尔是UTC+5:45。那多出来的15分钟是因为他们希望首都加德满都的正午时分，太阳正好位于喜马拉雅山顶上方。如果那座山移动了怎么办？这个问题没人想过。 “一个国家的时区永远不会变”——大错特错。2011年12月29日午夜，萨摩亚群岛决定从国际日期变更线的东边跳到西边。他们把时区从UTC-11改成UTC+13，直接跳过了12月30日。那天萨摩亚人醒来就是12月31日，平白无故少了一天。 IANA时区数据库：全人类时间的守护者 你可能从未听说过IANA时区数据库（也叫tzdata、zoneinfo或Olson数据库），但你用的每台电脑、每部手机都在依赖它。 这个数据库由一群志愿者维护，记录了全球每个地区历史上所有的时区变化。为什么需要历史记录？因为时区规则一直在变。每年都有国家修改自己的夏令时政策，调整UTC偏移量，甚至彻底更换时区。 维护流程是这样的：某国政府宣布修改时区规则 → 有人向tzdata邮件列表提交变更 → 维护者审核后合并 → 各操作系统发布更新 → 你的应用最终获得正确数据。 问题在于，从政府宣布到你的应用更新，可能存在数天甚至数周的延迟。2016年土耳其突然取消夏令时，只提前几周通知。很多系统根本来不及更新就出问题了。 更棘手的是：你的应用使用的时区数据版本，可能和数据库里存储数据时使用的版本不同。 这会带来什么后果？ 存UTC就够了？Jon Skeet说你想得太简单 Stack Overflow传奇用户Jon Skeet在2019年写了一篇博客，标题直截了当：《存UTC不是银弹》。 他举了一个例子：假设你在2019年3月帮一个会议组织者注册了2022年7月阿姆斯特丹的会议，开始时间是上午9点。根据当时的时区数据，阿姆斯特丹在7月是UTC+2。 然后，2020年荷兰政府决定从当年10月起永久使用"冬令时"（UTC+1）。时区数据库更新了，但你的数据库里存的是UTC时间——你把"9点阿姆斯特丹时间"转成了UTC时间存储。 问题来了：当规则改变后，那个存储的UTC时间对应的阿姆斯特丹本地时间变成了10点。你的倒计时器会平滑地倒数到0，然后——会议还没开始，因为实际上还有一小时。 核心问题在于：你存储的是"派生数据"，而不是"原始信息"。 正确做法是保存用户告诉你的原始信息：本地时间（9点）+ 时区ID（Europe/Amsterdam）。UTC时间可以作为优化存储，但它应该是可重新计算的派生值。 夏令时转换时的"幽灵时间"和"消失时间" 每年3月第二个周日凌晨2点，美国大部分地区会进入夏令时。时钟直接从1:59:59跳到3:00:00。2:00:00到2:59:59这段时间——从未存在过。 如果你有个定时任务设在这个时间执行，会发生什么？取决于你用的库和数据库，结果可能是：执行两次、执行一次、报错、或者行为未定义。 每年11月第一个周日凌晨2点，夏令时结束。时钟从1:59:59回退到1:00:00。1:00:00到1:59:59这段时间——重复了两次。 如果你在这天凌晨1:30有个会议，是哪个1:30？第一次的还是第二次的？你的应用如何区分？ Noda Time库的作者为此设计了"宽松解析器"（Lenient Resolver），在遇到模糊时间时选择某种策略。但这是否适合你的业务？需要你自己决定。 时区偏移量和时区ID：两个不同的概念 很多人混淆了这两个概念，导致严重的设计缺陷。 时区偏移量是某个时刻相对于UTC的差值，比如UTC+8。 时区ID是一个地理区域的标识符，比如Asia/Shanghai。 为什么这个区别很重要？因为同一个时区ID，在不同的日期和时间，可能有不同的偏移量。上海的冬天是UTC+8，但如果中国实施夏令时，夏天就会变成UTC+9。 反过来，同一个偏移量可能对应多个时区ID。UTC+8同时被中国、新加坡、马来西亚、菲律宾等使用。但这些国家的时区规则历史不同，未来也可能分道扬镳。 存储偏移量而不是时区ID，等于丢失了"这个时间属于哪个时区规则管辖"的信息。当规则改变时，你无法正确重新计算。 各语言的时区处理陷阱 JavaScript的Date对象是个灾难 JavaScript的Date对象设计于网景时代，充满了历史遗留问题。月份从0开始计数——new Date(2024, 0, 1)是1月1日，不是"不存在"的日期。 更严重的是，Date对象内部只存储UTC时间戳，所有本地时间操作都依赖于运行时的时区设置。同样的代码，在服务器和浏览器上可能产生不同结果。 这也是为什么现代JavaScript项目几乎都使用第三方库：date-fns、Luxon、Day.js或js-joda。即使使用这些库，也要小心区分"本地时间"和"带时区的时间"。 Python的pytz和zoneinfo Python 3.9之前，处理时区主要靠pytz库。但pytz有个著名的坑：你不能直接把pytz的时区对象传给datetime构造函数。 # 错误用法 dt = datetime(2024, 1, 1, 12, 0, tzinfo=pytz.timezone('Asia/Shanghai')) # 正确用法 tz = pytz.timezone('Asia/Shanghai') dt = tz.localize(datetime(2024, 1, 1, 12, 0)) Python 3.9引入了标准库zoneinfo，终于解决了这个问题： ...

你刚在远程服务器上执行了一个耗时两小时的数据库迁移脚本，眼看就要完成，切回终端一看——client_loop: send disconnect: Broken pipe。脚本进程随SSH会话一起灰飞烟灭，所有进度化为乌有。 这不是运气问题，而是TCP协议、NAT设备、防火墙三者在幕后精密协作的结果。要彻底解决这个问题，需要理解连接断开究竟发生在哪一层。 那个被你忽视的"空闲"连接 SSH连接本质上是一条TCP长连接。TCP协议设计之初假设的是：连接建立后双方会持续通信。如果一个连接长时间没有任何数据交换，TCP协议栈本身并不会主动断开它——理论上，一条TCP连接可以在没有任何数据传输的情况下永远存活。 但现实世界不允许这样做。 中间的网络设备需要回收资源。NAT路由器需要维护一张连接表，记录内网IP端口到公网IP端口的映射关系。防火墙需要追踪每条通过它的连接状态。这些设备的内存是有限的，不可能为一条"看起来已经死了"的连接永久保留状态条目。 这就是问题的根源：你的SSH客户端和服务器都认为连接还活着，但中间的NAT设备或防火墙已经把这条连接从它的状态表中删除了。 当你再次敲击键盘时，数据包从客户端发出，经过NAT设备——NAT设备翻遍整张表也找不到对应的映射关系，于是这个数据包被悄无声息地丢弃。服务器的TCP栈永远收不到这个包，客户端也永远等不到响应。终端就这样"冻结"了。 TCP Keepalive：为什么默认两小时根本不够用？ TCP协议本身提供了保活机制（TCP Keepalive）。当连接空闲超过一定时间后，TCP栈会自动发送一个保活探测包，对方收到后必须响应ACK。如果连续多次探测失败，TCP栈才会认为连接已断开。 问题在于默认参数。在Linux系统上，这三个关键参数的默认值如下： net.ipv4.tcp_keepalive_time = 7200 # 首次保活探测前的空闲时间（秒） net.ipv4.tcp_keepalive_intvl = 75 # 保活探测之间的间隔（秒） net.ipv4.tcp_keepalive_probes = 9 # 探测失败多少次后认为连接断开 tcp_keepalive_time 默认为7200秒——整整两个小时。这个数值源自 RFC 1122 的规定：保活探测的默认间隔不得少于两小时。 RFC 1122 写于1989年，当时的互联网环境与今天截然不同。文档中解释了为什么选择这么长的间隔： TCP规范本身不包含保活机制，因为它可能：(1)在暂时的网络故障中错误地断开有效连接；(2)消耗不必要的带宽；(3)对于按数据包计费的网络路径产生费用。 这个设计哲学假设的是：如果没有人使用连接，为什么要关心它是否还有效？ 但今天的情况完全不同。NAT无处不在，防火墙广泛部署，连接经过的每一跳都可能有自己的空闲超时。两小时的保活间隔，根本无法阻止中间设备提前清理连接状态。 SSH应用层心跳 vs TCP层保活：哪个更靠谱？ OpenSSH提供了两种保活机制，它们工作在不同层面： TCPKeepAlive（SSH配置中的TCPKeepAlive选项）： 工作在TCP协议层 由操作系统内核实现 使用系统默认的保活参数（默认两小时） 保活包内容为空，不经过SSH加密 可能被中间设备伪造或篡改 ServerAliveInterval / ClientAliveInterval： 工作在SSH应用层 由OpenSSH进程实现 保活包通过SSH加密通道发送，不可伪造 可以在SSH配置中灵活设置间隔 从OpenSSH官方手册的描述可以看出两者的关键区别： Client alive messages通过加密通道发送，因此不可被伪造。TCPKeepAlive启用的TCP保活选项则是可伪造的。当客户端或服务器需要知道连接何时变得无响应时，client alive机制非常有价值。 更实际的区别在于：TCP层保活受系统全局参数控制，而SSH应用层心跳可以针对每个连接单独配置，且不受NAT设备对TCP保活包的干扰。 NAT超时：真正的幕后黑手 网络地址转换（NAT）设备为了节省资源，会清理长时间没有数据传输的连接表项。不同类型的NAT设备，超时时间差异巨大： 设备类型 典型空闲超时 说明 家庭路由器 5-30分钟 视具体型号和固件而定 企业防火墙 15-60分钟 可配置，部分默认较短 云NAT网关 4-20分钟 AWS默认350秒，Azure默认4分钟 运营商CGN 30分钟-2小时 可能违反RFC规定 RFC 5382 明确规定：NAT设备对于已建立的TCP连接，其空闲超时不得少于2小时4分钟。然而现实中，大量NAT实现违反这一规定。有开发者专门编写了测试工具来检测运营商CGN是否合规，结果显示许多ISP的NAT超时只有1小时甚至更短。 ...