该问题总结

一。

往浏览器输入URL后给你一个页面，你天天在使用的东西，学过计算机网络的知道是怎么回事，就DNS解析然后页面的回馈，不过要讲好还是有难度。

之前fex团队的nwind专门写过这个问题的博客：

http://fex.baidu.com/blog/2014/05/what-happen/

厉害的地方是将整个计算机体系和硬件都涉及进来，很广很深，太强大了。

然后找到一个*的答案：

what happens when you type in a URL in browser

原链接

http://*.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输入到页面加载完成”做出各种侧重点不一的分析。 从浏览器的内核，到操作系统的组成，到协议栈的分析， 到所有服务器的种类，不同色彩的云端（云计算），总之就是精彩纷呈。 然而，你可以把他们都想象为餐厅里为你提供一道大餐的服务员和厨师。 他们很有趣也很热情，但你吃完饭还是该拍拍屁股走人了 ;-)

（完）

三

1. 输入地址
2. 浏览器查找域名的 IP 地址
   这一步包括 DNS 具体的查找过程，包括：浏览器缓存->系统缓存->路由器缓存...
3. 浏览器向 web 服务器发送一个 HTTP 请求
4. 服务器的永久重定向响应（从 http://example.com 到 http://www.example.com）
5. 浏览器跟踪重定向地址
6. 服务器处理请求
7. 服务器返回一个 HTTP 响应
8. 浏览器显示 HTML
9. 浏览器发送请求获取嵌入在 HTML 中的资源（如图片、音频、视频、CSS、JS等等）
10. 浏览器发送异步请求