你打开浏览器，作原敲下网址，理简按下回车。作原不到一秒，理简一个页面就铺满了屏幕。作原这个过程快到让人麻木，理简但背后其实是作原一套极其精密的“接力赛”。

第一棒是理简DNS。你输入的作原网址是给人类看的，机器只认IP地址——一串数字，理简比如172.217.14.105。作原浏览器得先问DNS服务器：“这个域名对应哪个IP？理简”DNS服务器就像电话总机，它查表、作原转发、理简递归，作原最后告诉你一个地址。这一步通常耗时几十毫秒，但如果你访问的网站没配好DNS，页面就会报“找不到服务器”。我见过不少初创公司，代码写得漂亮，结果域名解析配置错了，用户全被挡在门外——这活像快递员拿到了门牌号，但小区地图画错了。

拿到IP后，浏览器开始跟那台服务器建立TCP连接。这不是直接打电话，而是先“握手”——三次握手。第一次，浏览器说“喂，在吗？”；服务器回“在，你谁？”；浏览器再答“我，我要看页面”。这三句话来回一趟，才算打通了物理通道。为什么非要三次？两次不够吗？不够——两次只能确保浏览器能发、服务器能收，但服务器发的东西浏览器能不能收到，没验证过。这就像你喊了一嗓子，对面应了，但你不知道对面有没有听清你后半句。

连接建立，浏览器立刻扔出一个HTTP请求。这个请求本身就是一坨文本，里面写着“GET / HTTP/1.1”，后面跟着一堆头信息，比如“Host: example.com”、“User-Agent: Chrome/xxx”。服务器收到这坨文本，得解析它，然后决定返回什么。静态网页简单——服务器直接从硬盘里拽出HTML文件，打包成HTTP响应扔回去。但现代网站大多是动态的，服务器得跑一段代码（PHP、Python、Java之类），去数据库里查用户信息、拉取文章列表、计算推荐内容，再把这些数据填进HTML模板里，最后生成一个完整的页面。

这里有个细节容易被忽略：HTTP响应里有状态码。200表示“一切正常”，404是“你要的东西不存在”，500是“服务器自己炸了”。我调试接口时最爱看状态码，它比任何日志都直白——200不一定对，但404一定错。

浏览器拿到HTML后，还没完事。HTML里通常嵌着CSS和JavaScript的链接，浏览器得再发好几个HTTP请求去拉这些资源。每个请求都要走一遍TCP连接——不过现代浏览器会复用同一个连接，叫“keep-alive”，省得反复握手。资源到齐，浏览器开始渲染：解析HTML构建DOM树，解析CSS算样式，执行JS改页面行为。这个过程叫“关键渲染路径”，优化不好，页面就会白屏几秒。

最后一步，是断开连接。TCP四次挥手，双方礼貌告别。但HTTP/1.1时代，连接默认不关，留着给下一个请求用。到了HTTP/2，更是把多个请求塞进同一个连接里，像拼车一样省路费。

整个流程跑完，你看到的是页面，但背后是DNS的查表、TCP的握手、HTTP的请求-响应循环、服务器的代码执行、数据库的查询、浏览器的渲染管线。任何一环慢了，页面就卡；任何一环断了，页面就报错。我见过最离谱的案例：某网站图片全挂了，排查半天，发现是CDN厂商的证书过期，浏览器拒绝加载——不是图片没了，是信任断了。

这套机制从1991年诞生至今，核心没变，只是每个环节都被磨得越来越快。但你按下回车那瞬间，依然是在跟几十年前的协议设计者隔空握手。