【转】 从输入 URL 到页面加载完成的过程中都发生了什么事情？
该问题总结
一。
往浏览器输入URL后给你一个页面，你天天在使用的东西，学过计算机网络的知道是怎么回事，就DNS解析然后页面的回馈，不过要讲好还是有难度。
之前fex团队的nwind专门写过这个问题的博客：
http://fex.baidu.com/blog/2014/05/what-happen/
厉害的地方是将整个计算机体系和硬件都涉及进来，很广很深，太强大了。
然后找到一个StackOverFlow的答案：
what happens when you type in a URL in browser
原链接
http://stackoverflow.com/questions/2092527/what-happens-when-you-type-in-a-url-in-browser
Piskvor的回答：
作一个简单粗暴的描述，假设是简单的HTTP请求，IPV4，没有代理。
1.浏览器查询缓存，如果缓存存在跳到第9步。
2.浏览器询问操作系统服务器的IP地址。
3.操作系统做DNS查询，返回IP地址给浏览器。
4.浏览器打开对服务器的TCP连接（如果是HTTPS协议的话会更复杂）。
5.浏览器通过TCP连接发送HTTP请求。
6.浏览器接收HTTP响应并且可能关掉TCP连接，或者是重新使用连接处理新请求。
7.浏览器检查HTTP响应是否为一个重定向（3xx 结果状态码 ），一个验证请求（401），错误（4xx 5xx）等等，这些都是不同响应的正常处理（2xx）.
8.如果响应可缓存，将存入缓存。
9.浏览器解码响应（例如：如果它是gzziped压缩）。
10.浏览器决定如何处理这些响应（例如，它是HTML页面，一张图片，一段音乐）。
11.浏览器展现响应，对未知类型还会弹出下载对话框。
这里边的每个步骤都可以长篇大论一番，当然还有很多东西与这些步骤平行发生。
（完）
二
从微博上看到看到一个有趣的问题：
从输入URL到页面加载完的过程中都发生了什么事情？
这个问题立刻让我联想起我的数个高中老师。 几乎每段时间，我的诸位高中老师都会强调该科目的重要性， 在我们生活中起到多么深刻复杂的影响。 类似地，在程序员领域，大家会觉得自己做的一部分比较重要； 稍微放大些到企业，每个部门也会觉得自己是公司的重要组成部分。 到了这个问题里，从URL输入到页面加载完成，由不同人说来，就成了完全不同的故事。 你会看到哪些人看到了树木，哪些人看到了森林， 哪些人在充当神，而哪些人又在裸泳。 与其说这是个技术问题，不如说是个心理题。 闲言少叙，且看我的答案。
用户在浏览器输入URL后，至少有2个参与者，1个是浏览器，另1个是远端的服务器。
浏览器
浏览器代表用户向服务器请求一个页面（这就是浏览器被称作用户代理User Agent的原因）， 然后服务器向浏览器返回一个页面。
一个网页通常有很多组成部分。包括直接暴露给用的部分，如：
- 文本。
- 图片。
- 视频。
以及用户不可见的部分：
- CSS文件。
- Javascript文件。
不论是否可见，浏览器不能一次就获取所有的这些页面组成部分（资源）， 它必须要一个个地从服务器请求，并等待返回。 而这些资源未必是在1个服务器上，它们可能分布在多个服务器。
浏览器拿到手的这些资源，也并非是组合好的，像人眼看到的那样。 这些只是凌乱原材料而已，浏览器必须把他们组织好， 让用户看到的，就是网页的设计者设计出来的模样： 导航栏、标签、图片、表格、提交按钮、链接、文字颜色、大小等等。 组成的过程，也先可以笼统地称之为“渲染”。
浏览器利用CSS文件，做诸下事宜： 段落Z的文字用红色晕染，字体放大，加下划线； 图片X放在段落P的左侧，占1/4的空间，右端留2%的空隙； 用Javascript文件，做一些动态效果（如提示你输入等）， 或者往页面里添加/删掉点什么，以及多种多样的与服务器实时交互。
服务器
我们再看服务器一端。看起来它是有求必应的。 你问他要一个资源，他就返回你一个。如果没有，他也会告诉你没有。
服务器可能会有很多分类， 可以一个服务器运行一种服务（如专门提供图片服务）， 也可一个服务器运行多种服务（如同时提供图片和视频服务）， 或多个服务器提供一种服务（如数个服务器组成一个图片服务器集群）。
浏览器将与服务器进行怎样的互动，很大程度上取决于：
1 - 页面自身的复杂度。 如果页面非常简单，可能只需要1个请求。 如果页面非常复杂，可能需要向N个服务器进行X次请求。
2 - 服务器端的部署情况。 如果是一个小型网站，可能只有1台服务器提供所有服务。 如果是一个超大型网站，可能有N台服务器在提供一类服务。
两者之间
浏览器和服务器的关系看起来很简单，一个说“给我”，另一个说“给”。 就如你拧开水管就期待着水流从管道里涌出一般， 似乎只要浏览器开口，服务器就源源不断地输出资源。
任何两个物件要通信，就要确保两者使用相同的语言，或者叫“协议”。 URL这个字串中携带了协议信息，如http、https、ftp等。
不同的协议意味着什么，我想应该由Stevens等的书来进一步解释了。 接下来的重点是，浏览器和服务器必须按协议规定来通信，你来我往都必须符合规范。
然而在两者按章办事前，还有一个重要因素是，浏览器如何找到目标服务器？
这就是“域名系统”所扮演的重要角色了。 和电话通讯录一样，一个姓名（username）对应一个数字串（xxx-xxxx-xxxx）， 在域名系统中，一个域名（Domain）对应一个IP地址。 浏览器和DNSServer你问我答（也要按一个协议来通信）， 能够获取目标服务器的IP，进而通过“协议”通信。
在计算机网络中，似乎在两点之间可以安插无数的中间人而无碍于两者的通信。 就如击鼓传花一般，一站站传递下去，总会达到终点，或回到起点。 以下是个小例子。
我们可以把这个图无限延伸下去，然后在每个节点都需要不同的专家， 然后这些专家会对“URL输入到页面加载完成”做出各种侧重点不一的分析。 从浏览器的内核，到操作系统的组成，到协议栈的分析， 到所有服务器的种类，不同色彩的云端（云计算），总之就是精彩纷呈。 然而，你可以把他们都想象为餐厅里为你提供一道大餐的服务员和厨师。 他们很有趣也很热情，但你吃完饭还是该拍拍屁股走人了 ;-)
（完）
三
- 输入地址
- 浏览器查找域名的
IP地址
这一步包括DNS具体的查找过程，包括：浏览器缓存->系统缓存->路由器缓存... - 浏览器向
web服务器发送一个HTTP请求 - 服务器的永久重定向响应（从
http://example.com到http://www.example.com） - 浏览器跟踪重定向地址
- 服务器处理请求
- 服务器返回一个
HTTP响应 - 浏览器显示
HTML - 浏览器发送请求获取嵌入在
HTML中的资源（如图片、音频、视频、CSS、JS等等） - 浏览器发送异步请求
