系统与基础设施github.com编辑精选
在浏览器输入 Google.com 并按下回车后会发生什么？
“What happens when you type Google.com into your browser and press enter?”
2015 — 2016，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是一个著名的 GitHub 协作项目，试图尽可能详尽地回答经典面试题“在浏览器输入 google.com 并回车后发生了什么”，从键盘输入、DNS、TCP 连接一路讲到 HTTP 请求与页面渲染。它多年反复登上 Hacker News 首页，成为网络与系统知识入门的标志性资源。
为什么经久不衰：它把一个看似简单的问题层层拆解到硬件与协议的每个环节，既是绝佳的计算机系统入门材料，也常被用来讨论面试文化的得失，因此经久不衰。
HN 评论精选
这类面试题往往流于形式，且常出现在不重视员工学习的公司。
太喜欢了！这是我最喜欢的“糟糕”面试题之一。大约五年前我在面试中被问到，我的反应是先愣一下，然后问：“你指什么？需要多深的细节？DNS？SYN/ACK？HTTP？”结果我刚讲到 SYN/ACK，对方就打断我进入下一题。同一家公司另一个人在电话面试开场就说“你简历上写会 Linux，那硬链接和软链接有什么区别”，我答上来后他居然很惊讶，说剩下的面试没意义了。我现在把这类面试题视为一个信号：说明这家公司几乎不鼓励在职学习。
cursork查看英文原文
Love it! One of my favourite bad interview questions. I got asked this in an interview ~5 years ago. My response was to look shocked... Pause. Then ask: "What do you mean? What detail do you need? DNS? SYN / ACK? HTTP?" At the point I started talking about syn/acks they just cut me off and moved on to the next question. Same company (different person) started the phone screen with 'oh so your CV says you know linux, what's the difference between a hard link and a soft link' and was shocked when I knew the answer, declaring the rest of the phone interview pretty pointless - he'd obviously had a bad morning and started with his hardest question. I've now learnt to see such interview questions as a sign of a workplace with little-to-no learning on the job. Most places that actively encourage learning don't try such things.
这个问题可以无限拆解，作为知识练习有趣，但工程上未必高效。
这个问题总让我想起《禅与摩托车维修艺术》。作者把工程哲学视为将事物拆解为组成部分的艺术，而他纠结的一个悖论是：某些系统似乎有无穷多种拆分方式，却始终做不出有成效的工作。这个问题就有这种感觉——你可以拆到最细小的离散系统，最后发现收获并不大。这不是说完全没收获，也不代表它不是好面试题，只是从工程角度看并不算高效。
eblume查看英文原文
This question always reminded me of the (excellent) book "Zen and the Art of Motorcycle Maintenance". The author explores the philosophy of engineering as being the art of separating things in to their components. At the risk of spoiling some of the book, a major struggle the author goes through is the paradox that there seems to be an infinite number of ways to split some kinds of systems, with no productive work ever being done. This question feels like that... you can split it down to the tiniest discrete system and you'll find you haven't gained much. That's not to say that you wouldn't gain SOMETHING, nor that it's a bad interview question. I actually like it. It's just not terribly productive, in an engineering sense.
推荐 Quéru 的反向拆解版本，从页面渲染倒推到底层，同样精彩。
Jean-Baptiste Quéru 在 2013 年也写过一篇很好的入门回答，他采用反向思路：从页面显示出来开始，再谈连接、操作系统等，逐层“简化”并深入多个抽象层级，让人体会到这个问题应有的压倒性复杂度。非常值得一读。
felipesabino查看英文原文
There is also a very good introductory answer in this subject by Jean-Baptiste Quéru in 2013 [1] where he takes the revers approach of when the page is displayed, then talks about connection, OS, etc. "simplifying" the answer and going down several levels of abstraction and complexities to give the proper overwhelming sense that this question should impose. It is a very fun text to read and I really recommend it. [1] https://plus.google.com/u/0/+JeanBaptisteQueru/posts/dfydM2Cnepe
这个项目还有很多空白：按键事件链路、Google 服务端、路由路径和 CPU 层面的工作量都值得补充。
到目前为止，还没人补上按键事件如何经过操作系统、窗口系统、应用，最终到达输入框处理代码这一段。Google 那端也值得写：搜索个性化之前，热门查询直接由第一台机器的缓存处理，根本到不了搜索引擎；个性化之后则有 cookie 流量，你的个人档案会从存储中取出用于解读查询。中间你的请求大约经过五到十个路由器，从以太网/WiFi 到 DSL 到光纤再到数据中心内的万兆以太网。你的 google.com 到底在哪？我今天的解析结果是某个 1e100.net 地址，路由经硅谷、圣罗莎、圣何塞才到达 Google 的接入点。还有人该讲讲 CPU 里每核每秒约 30 亿条指令，全都在为你找猫视频。
Animats查看英文原文
So far, nobody has filled in the section on how a key-press event works its way through the OS, up to the window system, to the application, and to the code handling the input text box. Then there's what's happening at the Google end. Before search personalization, popular queries ("google", "Britney Spears") were handled by caches the first Google machine you talked to, and never even reached the search engine. Since search personalization, there's some cookie traffic, and then your personal dossier is retrieved from storage at Google for use in interpreting your query. Then, in the middle, your query probably travels through five to ten routers (try a traceroute) just to get to Google. Packets move from local Ethernet or WiFi to DSL to fiber to bigger fiber to gigabit Ethernet within a Google data center. And where is "google.com" for you? That's hard to find out. For me, today, it's at "nuq04s19-in-f14.1e100.net", wherever that is. My connection routed from Silicon Valley to Santa Rosa to San Jose before reaching a Google point of presence at Equinix in San Jose. Somebody also needs to talk about what's happening in the CPUs, with 3 billion or so instructions per CPU core every second, all devoted to looking up a cat video for you. When you play a cat video, more computation occurs than was done in the history of the world prior to 1940.
历次讨论
同类还值得读
TTY 揭秘（2008）
The TTY demystified (2008)
经典文章深入剖析了 Unix/Linux 中 TTY 子系统的工作原理，包括线路规程、终端驱动、信号与控制字符等机制。
系统与基础设施上首页 11 次 · 2009–2025linusakesson.net编辑精选为什么 GNU grep 这么快
Why GNU grep is Fast
FreeBSD 邮件列表上一篇广为流传的帖子，解释 GNU grep 为什么快：核心在于 Boyer-Moore 字符串搜索算法配合精心优化的内部循环和 I/O，让程序在搜索时“…
系统与基础设施上首页 9 次 · 2010–2022lists.freebsd.orgXplain：为普通人讲解 X11
Xplain – Explaining X11 for the rest of us
《Xplain》是作者（HN 用户 Jasper_）写的一系列 X11 长文，用他在浏览器中重建的 X11 绘图模型做交互演示，讲解 X11 的绘图模型与窗口系统设计。
系统与基础设施上首页 6 次 · 2013–2020magcius.github.io编辑精选旋风教程：为 Linux 创建极小 ELF 可执行文件（1999）
A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux (1999)
breadbox 写于 1999 年的经典教程，主题是如何为 Linux 手工构造并裁剪出体积极小的 ELF 可执行文件。
系统与基础设施上首页 6 次 · 2007–2025muppetlabs.comPostgreSQL 内部原理
The internals of PostgreSQL
《The Internals of PostgreSQL》是一本免费在线书籍，系统讲解 PostgreSQL 的内部实现，包括查询处理、并发控制、WAL、缓冲区管理等核心机制。
系统与基础设施上首页 5 次 · 2017–2025interdb.jp编辑精选