你在浏览器地址栏敲下一串字符，何通按下回车，访问页面就出现了。网站这过程快得让人习以为常，页面但背后其实是何通一场精心编排的接力赛。
那串字符叫URL，访问统一资源定位符。网站它像一张写着收件地址的页面快递单，只不过收件人不是何通某个人，而是访问互联网上的一台服务器。你输入的网站每个部分都有讲究——https://是运输协议，告诉浏览器该用哪种规则和对方对话；example.com是页面域名，人类好记的何通名字，但机器根本不认这玩意儿，访问它只认IP地址，网站一串类似93.184.216.34的数字。
关键问题来了：浏览器怎么把域名翻译成IP？它先查自己的缓存，没有就去问操作系统，再没有就发出一个DNS查询请求。这个请求会经过层层转递，最后落到某个DNS服务器头上。整个过程大概耗时几十毫秒，你根本感知不到。有次我关了Wi-Fi用手机热点访问一个网站，页面加载明显变慢，打开开发者工具一看，光是DNS解析就花了1.2秒——平时这个数字通常是个位数。
拿到IP地址之后，浏览器开始建立TCP连接。这有点像打电话，得先“喂”一声确认对方在线。三次握手，第一次你说“在吗”，对方回“在，你谁”，你再回“我是浏览器”。三次之后，连接建立。然后浏览器会发一个HTTP请求报文，里面写着“我想看根目录下的默认页面，用GET方法”。
服务器收到请求，开始干活。它可能去查数据库，可能去读文件，也可能直接返回一段写死的代码。响应报文里带着状态码——200代表一切正常，404意味着你找的东西不存在，500是服务器自己出了岔子。我见过最离谱的一次，某个网站首页返回了200，但页面全是乱码，因为服务器把字符编码搞错了。技术规范是死的，但实现它的人会犯错，所以偶尔出现诡异现象太正常了。
浏览器收到响应后开始解析HTML。它遇到CSS就去加载样式，碰到JavaScript就执行脚本，图片链接则异步请求。这个阶段最考验耐心——如果服务器响应慢，页面会白屏好几秒。有回我访问一个国外博客，等了五秒才出现文字，但图片加载花了十五秒，因为那些图片托管在另一个性能极差的图床上。你看，一个页面的加载速度，往往取决于最慢的那个独立资源。
整个过程里有个容易被忽略的细节：现代浏览器会同时打开多个TCP连接，并行下载资源。老的HTTP/1.1协议下，浏览器对一个域名最多开六个连接，多了就排队。这就是为什么很多网站会把图片放在单独的域名下——绕过连接数限制。HTTP/2出来之后这问题缓解了不少，但很多老站点还没升级。
最后一步，渲染引擎把HTML、CSS和JavaScript组合成你看到的像素。布局、绘制、合成，每一步都在毫秒级完成。如果页面里有个无限滚动的列表，浏览器还得不断计算哪些元素该进入视口，哪些该销毁释放内存。这些细节没人会注意到，除非出了问题——比如你滚动时卡顿，或者内存占用飙升到2GB。
整个流程走完，你在屏幕上看到了内容。但这只是开始——你点击某个链接，又触发一次新的URL解析、DNS查询、连接建立、请求发送、响应处理、页面渲染。循环往复，每次点击都是一场微型接力赛。理解了这些，你再遇到网页打不开的情况，就能顺着链路排查：是DNS挂了？是服务器没响应？还是本地网络出了问题？有回我同事说网站打不开，我ping了一下域名，发现解析出来的IP根本不通，换了个DNS服务器就正常了——问题出在他公司配的DNS上，跟网站本身没半毛钱关系。
URL访问页面的本质，就是一次精准的请求与响应。没有魔法，只有协议、地址和无数台机器间的协作。下次按下回车时，你可以想象一下那串字符在光缆里飞驰的画面——它确实在飞，只是你感觉不到而已。