互联网与文化windytan.com
图解拨号上网的声音
The sound of the dialup, pictured (2012)
2015 — 2021，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇文章用图示/频谱把拨号上网时调制解调器握手的刺耳声音拆开，逐段说明拨号、应答与协商过程中发生了什么，并解释为什么这些声音通常会被用户听到。它把一代人熟悉的“上网仪式”转成可读的技术图解。
为什么经久不衰：它既承载怀旧，又直观展示了调制解调器协议与信号处理的巧妙，今天仍是理解早期互联网接入方式的经典材料。
HN 评论精选
老技术支持凭听握手声诊断调制解调器问题，并指出电话线质量常迫使用户降速。
这篇文章刚发表时我就读过，觉得非常有意思；当年在 CompuServe 还存在时，我就是靠听调制解调器的声音来诊断问题，在技术支持这行立足的。我是个老家伙，甚至用过文章提到的那种带声耦合器的 300 波特调制解调器。我听惯了调制解调器握手的演变，却不知道每个部分具体是什么意思，但多年下来把不同问题和不同声音对应起来，也潜移默化地学会了不同芯片厂商的 AT 命令，用来锁定某些模式：设置流控、设置最大/最小波特率、设置各种纠错算法模式。90 年代做技术支持时，我见到的最大问题之一是某些地区的电话线质量：住在偏远地区能稳定跑到 9600 波特就算走运；大城市基础设施老化则可能有信号串扰，能隐约听到别人的通话。这两种情况下，协商序列会反复重启，有时碰巧连上，但更多是失败，直到我们找到合适的 AT 命令把速率锁低。
ceautery查看英文原文
I remember reading this when it came out, and it was fascinating, especially considering listening to modems to diagnose problems is how I made my bones in tech support back when CompuServe was still a thing. I'm an old timer, and have even used a 300 baud modem with an acoustic coupler that the article referred to. I listened to the evolution of modem handshakes, and had no idea what parts meant what, but over the years I correlated different problems to different sounds, and through osmosis learned the various AT commands for different chip manufacturers (the main three I ran across were Hayes/Rockwell, USR, and Motorola) to lock them in certain modes - set the flow control mode (RTS/CTS or X-on/X-off), set the max and min baud rates, and set various error control algorithm modes. Doing tech support for a couple years in the 90s, the biggest problem I saw (beyond the fact that average users were pretty unsophisticated back then), was the quality of telephone lines in certain areas of the country. If you live in the sticks, you're screwed and lucky to achieve 9600 baud with any consistency. If you live in larger cities with crumbling infrastructure, you're likely to have some "signal bleed" (not sure what to call it) where other conversations are faintly audible on your lines. In both of these cases, the negotiation sequence would restart several times, sometimes getting lucky and connecting, but more often failing until we found the right AT commands to lock a lower baud rate and force error correction - MNP? I think that was the magic bullet in most cases. In the end, the phone infrastructure improved greatly just about everywhere, but by then it didn't matter as much, as people started moving to cable modems, typically plugged directly into a desktop computer, running Win 95 and getting hijacked by 0 day exploits to build the first botnets. Good times. Anyway, I'm glad to see this article has held up over time and people still find it interesting.
主张保留可见的底层过程（如握手声、启动日志）作为进度反馈，甚至能激发好奇心。
文章里说，只要在拨号前通过串口发送 ATM0 就能让握手静音。而我认为用户其实被这种仪式感安慰了——从朋友聊天和《电子情书》这类流行文化场景都能看出来。我赞成用计算机底层的原始输出来做进度指示，而不是用不透明的标志或精致动画把视野挡住。比如我希望笔记本和手机启动时像某些 Linux 发行版那样列出 shell 输出。即使多数用户不会完全看懂，快速滚动的文本在表达“正在加载”上并不比动画转圈差。我觉得大多数非技术用户并不排斥这种暴露，甚至有点喜欢；这让他们觉得自己身在间谍片里。有些人永远不会去理解，只把它当成更详细的进度转圈；有些人会慢慢熟悉某些行，出于好奇去搜索，这可能就是点燃他们走上程序员长路的那点火花。
combatentropy查看英文原文
> Why was it audible? Why not, one could ask. [...] > Even then, the idea of not hearing what's happening > on a phone line you're calling on was quite new, > and modems would default to exposing the user to the handshake audio. [...] > > All you had to do to silence the handshake was to send the command ATM0 > down the serial line before dialing. And I think the user was comforted by the ritual, as far as I can tell from conversations with my friends and scenes from pop culture like You've Got Mail. I am for using the computer's own low-level apparatus as progress bars, instead of the opaque logos or polished animated graphics, blocking the view like a royal guard. For example, I wish my laptop and my phone listed the shell's output during boot, like some Linux distros still do. Even though most users wouldn't fully understand it --- and I have to admit that even I don't understand a lot of it --- the quickly scrolling text is no worse than an animated spinner in conveying, "Loading..." I think most users, and I mean nontechnical, are okay with the exposure and even kind of like it. It makes them feel like they're in a spy movie. Some will never try to understand it and will just take it as a more-detailed progress spinner. Some will slowly become familiar with some of the lines, google them out of curiosity, and it may be the spark that lights them down the long trek to becoming a programmer. Isn't that one of our country's goals, to encourage kids to become programmers? Anyway, my point is, I came to programming from graphic design and front-end. I spend a lot of time thinking about user-interface design. But maybe I'm against the grain in wanting some of the architecture to be allowed to hang out. (Does that make me a Brutalist?)
56K 是信号处理的惊人成就；高速数据应像白噪声，并由此批评 SETI 寻找过时的载波信号。
调制解调器能在 64Kb/s 数字化的模拟电话线上跑到 56Kb/s，实在惊人；尤其 T1 载波系统还每隔一个采样偷走一个低位用于控制。这是信号处理的非凡成就。直到 1970 年代中期，人们还认为这在理论上不可能；贝尔实验室曾研究得出结论，模拟电话线的上限是 19Kb/s。调制解调器协商过程能在众多厂商和代际之间工作得那么好，也令人印象深刻。当调制解调器协商到良好的高速模式时，数据听起来像白噪声；这是正确的。任何听起来不像白噪声的调制方案都在浪费带宽。载波和音调消耗能量却不携带有效载荷数据。顺便说，这也是对 SETI 的批评：长期以来 SETI 人群寻找带有巨大固定频率分量的“载波”信号，但载波已经过时；除遗留模拟广播电台外，今天几乎没有大功率发射强载波信号的东西。所以 SETI 是在寻找使用高功率模拟无线电的文明。
Animats查看英文原文
It's amazing that modem speeds reached 56Kb/s over analog lines that were digitized at 64Kb/s. Especially since T1 carrier systems stole one low-order bit in every other sample for control purposes. That's an incredible accomplishment of signal processing. As late as the mid-1970s, it was believed to be theoretically impossible. Bell Labs once did a study that concluded that 19Kb/s was the upper limit for analog phone lines. It's also impressive that the modem negotiation process worked as well as it did, across many vendors and generations of modems. When the modems agree on a good high-speed mode, the data sounds like white noise. That's proper. Any modulation scheme which doesn't sound like white noise is wasting bandwidth. Carriers and tones waste energy but carry no payload data. This, incidentally, is a critique of SETI. For a long time, the SETI crowd was looking for "carriers", signals with a big fixed-frequency component. Carriers are obsolete. Other than legacy analog broadcast stations, almost nothing with high power today transmits a strong carrier signal. So SETI was looking for civilizations that used high power analog radio.
用户靠听握手声分辨 14.4K 与 28.8K 调制解调器，以便挂断重拨碰运气。
大学第一年我在家拨号上网。学校把 14.4Kbps 和 28.8Kbps 调制解调器混接在同一个电话号码上，所以每次随机连到哪一种。在那个年代，数据速率翻倍显然值得挂断重拨，试多少次都行！学校那两种调制解调器的握手声一听就能区分，所以如果听到 14.4K 的握手声，就可以立刻挂断再碰运气。靠听比等握手结束再测下载速率快得多。那么为什么 14.4Kbps 和 28.8Kbps 的握手声不同？乱码数据测试阶段很可能是原因，因为能力不同的调制解调器在这个阶段听起来应该不一样。YouTube 上有很多 14.4Kbps 调制解调器录音，但我找不到 28.8Kbps 的握手录音来做像样比较！也可能不同品牌或型号的调制解调器在进入乱码数据测试之前就能分辨出来。
beloch查看英文原文
"Why was it audible? Why not, one could ask." In my first year of university I used dial-up to connect from home. The university had a mixture of 14.4Kbps and 28.8Kbps modems all tied into the same phone number, so it was random which kind you got. Obviously, doubling your data rate in those days was easily worth hanging up and trying again as many times as it took! The handshaking sound of the two types of modems the university was using were audibly distinct, so you could hang up and try your luck again immediately if you heard a 14.4K modem handshake. Listening was much quicker than waiting for the handshake to finish and then testing the download rate. So, why did a 14.4Kbps modem handshake sound different from a 28.8Kbps modem handshake? The scrambled data test phase seems to be a likely culprit, because modems with different capabilities should sound different in this phase. There are plenty of 14.4Kbps modem recordings on youtube, but I couldn't find a 28.8Kbps handshake recording to do a proper comparison! It might also be that different brands or models of modems could be distinguished from one another before they even got to the scrambled data test.
历次讨论
同类还值得读
如今电脑上几乎所有操作在感知上都比 1983 年更慢（2017）
Almost everything on computers is perceptually slower than it was in 1983 (2017)
2017 年的推文串认为，尽管计算机硬件比 1983 年快得多，日常操作的感知速度却常常更慢：启动、界面响应和网络应用被层层抽象、动画、后台检查与网络依赖拖累。
互联网与文化上首页 5 次 · 2017–2020twitter.com网站肥胖危机
The Website Obesity Crisis
Maciej Cegłowski（idlewords）的经典演讲文稿《网站肥胖症危机》，批评现代网页越来越臃肿：动辄数 MB 的 JavaScript、追踪脚本和广告，把本可以轻…
互联网与文化上首页 5 次 · 2016–2021idlewords.com编辑精选亚马逊那本标价 23,698,655.93 美元的苍蝇书
Amazon’s $23,698,655.93 book about flies
博文讲的是亚马逊上一本关于果蝇的二手书被标到 23,698,655.93 美元。
互联网与文化上首页 5 次 · 2011–2022michaeleisen.org浏览器 User-Agent 字符串的历史
History of the browser user-agent string (2008)
2008 年的经典文章用戏谑的“创世纪”口吻，讲述浏览器 User-Agent 字符串如何从简单的标识演变成层层叠加的伪装：浏览器为了绕过按 UA 分发的网站检测，纷纷把自己伪装…
互联网与文化上首页 5 次 · 2012–2022webaim.org编辑精选最后的问题——艾萨克·阿西莫夫
The Last Question - Isaac Asimov
阿西莫夫最著名的短篇科幻小说《最后的问题》的在线全文。
互联网与文化上首页 5 次 · 2009–2019multivax.com编辑精选